Десять лет назад очевидно было то, что JavaScript имеет все шансы, так сказать, править миром. За эту честь сражались и другие платформы — такие, как Java, Flash и Silverlight. Всем этим трём платформам нужны, для работы в браузерах, специальные плагины. Все три меняют HTML-подход к формированию интерфейсов на что-то другое. Это позволило им уйти далеко вперёд от JavaScript в плане возможностей. Например — они умели проигрывать видео, выводить анимацию, рисовать что-то на экране. Всё это другие платформы поддерживали задолго до появления стандартного тега
<video>, механизмов CSS-анимации и HTML-элемента canvas. Но всё это стало причиной их краха. Так, когда в мире начался бум мобильного интернета, и когда это было учтено в HTML, другие платформы оказались не у дел.
Ирония есть и в том, что происходит сейчас. В то самое время, когда JavaScript царствует в мире веб-разработки, появился один проект, вроде бы не особенно масштабный, который, когда-нибудь в будущем, способен стать убийцей JavaScript. То, о чём мы тут говорим, началось с экспериментальной технологии asm.js. Как это может выглядеть? Прежде чем ответить на этот вопрос — давайте немного притормозим и поговорим о современном положении дел.
Транспиляция: то, чем мы пользуемся сегодня
Разработчики, во все времена существования JavaScript, пытались как-нибудь обойти необходимость писать на этом языке. Одним из ранних подходов к решению этой задачи было использование плагинов, выводивших код за пределы браузера. (Этот подход оказался неудачным). Ещё одна идея заключалась в том, чтобы создать инструменты разработки, которые могли бы преобразовывать код. Другими словами — такие инструменты, которые принимали бы код, написанный на более приличном языке, и трансформировали бы его в JavaScript. Это позволило бы разработчикам и пользоваться широчайшей поддержкой, имеющейся у JavaScript, и не связываться с этим языком.
Процесс преобразования кода, написанного на одном языке, в код, написанный на другом, называют транспиляцией. У транспиляции есть некоторые очевидные подводные камни. Высокоуровневые языки обладают разными возможностями, разным синтаксисом, в них используются различные идиомы. Некую строку, написанную на одном языке, не всегда можно равнозначно «перевести» на другой язык. И, даже если это возможно, у такого подхода есть определённые опасности. Что произойдёт, если прекратится разработка вашего любимого транспилятора? А как быть, если транспилятор содержит ошибки? Что если транспилированный код планируется использовать совместно с JavaScript-фреймворками вроде Angular, React или Vue? Как организовать командную работу над проектом в том случае, если в состав команды входят люди, «говорящие» на разных языках программирования?
Инструменты в мире программирования настолько хороши, насколько хороши люди, которые за ними стоят. Это справедливо во многих ситуациях, касающихся разработки ПО.
Поможете отладить страницу? Я написал её на Dart
В наши дни транспиляторы — это весьма распространённое явление. Но сфера их использования часто ограничена одним основным сценарием — обеспечением обратной совместимости.
Разработчики пишут код, используя самые современные возможности JavaScript, а затем применяют транспилятор, вроде Babel, для преобразования своего кода в эквивалентный (но не такой аккуратный) классический JS-код, который работает везде, где только можно. Или, что ещё интереснее, они пишут на TypeScript (современная надстройка над JavaScript, позволяющая пользоваться такими возможностями, как строгая типизация, дженерики, типы, не допускающие наличия значения
null). TypeScript-код транспилируют в JavaScript. В любом случае работа ведётся в закрытой экосистеме JavaScript.Asm.js: первый шаг
Первый проблеск новой возможности появился в обличье asm.js. Это был плод необычного эксперимента, проведённого в 2013 году программистами из Mozilla. Они искали способ запуска высокопроизводительного кода в браузере. Эту задачу можно было бы решить с помощью некоего плагина, но asm.js, в отличие от плагинов, не пытается работать в стороне от браузера. Вместо этого данная технология нацелена на работу в виртуальной машине JavaScript.
В основе asm.js лежит лаконичный, оптимизированный синтаксис JavaScript. Asm.js-код выполняется быстрее обычного JS, так как в нём исключается использование медленных динамических механизмов языка. Однако браузеры, которые умеют работать с asm.js, могут применять к соответствующему коду дополнительные оптимизации, что ещё сильнее повышает производительность. Другими словами, проект asm.js следует золотому правилу, которое заключается в том, что не надо ломать веб. При этом данная технология даёт дорогу будущим улучшениям. Команда Firefox взяла 3D-игру, написанную на C++, события в которой разворачиваются в реальном времени, и запустила её в браузере, пользуясь лишь JavaScript и вдохновляемая лишь собственными амбициями. В этом проекте применялся asm.js и инструмент для транспиляции кода, называемый Emscripten.
Игра, в которой используется движок Unreal, запущенная в браузере
Самое главное в asm.js — это то, что данный проект приводит разработчиков к переосмыслению роли JavaScript. Код, написанный на asm.js, это JavaScript-код, но этот код не рассчитан на то, что читать или писать его будет человек. Вместо этого подобный код создаётся автоматическими средствами (транспиляторами) и передаётся браузеру. JavaScript в данном случае — это носитель сообщения, но не само сообщение.
WebAssembly: новая технология
Хотя на базе asm.js и удалось создать несколько ярких демок, разработчики-практики её, в основном, игнорировали. Для них всё это выглядело лишь как очередной интересный образец технологий будущего. Ситуацию изменило создание WebAssembly (WASM).
Технологию WebAssembly можно считать и преемником asm.js, и чем-то совершенно особенным. Это — компактный бинарный формат инструкций. WebAssembly-код, как и в случае с asm.js, передаётся среде исполнения JavaScript. Этот код ограничен той же «песочницей» и тем же окружением времени выполнения. Кроме того, подобный код тоже компилируется, делается это с учётом организации его эффективного выполнения. Но теперь речь идёт о гораздо более высоком уровне производительности, чем прежде. А браузер, работая с WebAssembly-кодом, может полностью пропустить этап парсинга. Если речь идёт о реализации обычных механизмов (скажем — вычислений, на которые требуется много времени), то WebAssembly оказывается гораздо быстрее простого JavaScript. Производительность WebAssembly приближается к производительности машинного кода.
Упрощённое представление конвейера обработки WebAssembly-кода
Если вам интересно взглянуть на WASM-код, то давайте, для начала, представим, что у нас имеется некая функция, написанная на C:
int factorial(int n) {
if (n == 0)
return 1;
else
return n * factorial(n-1);
}При её компиляции в формат WASM получается следующее:
get_local 0
i64.eqz
if (result i64)
i64.const 1
else
get_local 0
get_local 0
i64.const 1
i64.sub
call 0
i64.mul
endПодобный код, при его практическом использовании, преобразуется в ещё более компактную форму.
Технологию WebAssembly проектировали так, чтобы она могла бы служить целью компиляции. Вручную подобный код не пишут. (Правда, WASM-код всё же можно писать вручную, например для того, чтобы досконально в нём разобраться).
Технология WebAssembly появилась в 2015 году. Сегодня она пользуется полной поддержкой «большой четвёрки» браузеров (Chrome, Edge, Safari и Firefox) на мобильных и настольных платформах. В Internet Explorer WASM не поддерживается, хотя это можно обойти, обеспечив совместимость новой технологии с IE путём преобразования WASM-кода в asm.js-код. (Но если так и сделать — пострадает производительность. Пусть уже IE канет в вечность!)
WebAssembly и будущее веб-разработки
WebAssembly, в стандартном виде, даёт разработчикам средство для создания оптимизированных программ, изначально обычно написанных на C++. Перед нами — мощная возможность, но сфера её использования не особенно широка. Это может оказаться полезным в том случае, если нужно улучшить производительность сложных вычислений. (Например, в проекте fastq.bio WebAssembly используется для ускорения обработки данных секвенирования ДНК). Подобная возможность ценна и для тех, кто занимается портированием на веб-платформу высокопроизводительных игр, или написанием эмуляторов, которые выполняются в браузерах. Если бы возможности по использованию WebAssembly ограничивались лишь подобными сценариями, то эта технология была бы практически такой же восхитительной, каковой она является, но вот «убийцей JavaScript» назвать её было бы нельзя. Однако WebAssembly, кроме прочего, открыла создателям фреймворков возможность встраивать свои разработки в JavaScript-окружение.
Вот здесь наша история делает интересный поворот. WebAssembly-код не может полностью обойтись без JavaScript, так как этот код «заперт» в среде выполнения JavaScript. На самом деле, для работы с WASM-кодом нужно, чтобы вместе с ним выполнялся и некий, возможно — очень небольшой, объём обычного JavaScript-кода. Дело в том, что у WASM-кода нет прямого доступа к странице. Это означает, что такой код не может, не пользуясь JavaScript-слоем, манипулировать DOM или получать события.
Это ограничение, на первый взгляд, может показаться чем-то таким, что противоречит самому смыслу создания WASM. Но талантливые разработчики нашли способ «тайно пронести» свои фреймворки в браузер, пользуясь возможностями WebAssembly. Например, фреймворк Blazor от Microsoft представляет собой миниатюрную реализацию среды выполнения .NET, загружаемую в браузер в виде скомпилированного WASM-файла. Эта среда выполнения отвечает за взаимодействие с JavaScript и даёт разработчику как базовые функции (вроде сборки мусора), так и высокоуровневые возможности (создание макетов страниц, маршрутизация, использование виджетов для построения интерфейсов). Другими словами, Blazor использует виртуальную машину, которая размещается в другой виртуальной машине. Тут перед нами — либо парадокс уровня фильма Кристофера Нолана «Начало», либо — искусный способ создания фреймворков, написанных не на JavaScript, но работающих в браузерах.
Проект Blazor, кстати, это далеко не единственный эксперимент, основанный на WebAssembly. Среди подобных разработок можно ещё отметить, например, Pyodide. Этот проект нацелен на выполнение в браузере Python-кода и даёт в распоряжение всех желающих мощные средства для анализа данных.
Вот это — будущее. Проект WebAssembly, вначале выглядящий как вспомогательное средство, служащее для запуска в браузере фрагментов кода, написанного на C++ или Rust, быстро начали использовать для проведения более масштабных экспериментов. Скоро WASM позволит фреймворкам, написанных не на JavaScript, конкурировать с хорошо зарекомендовавшими себя JavaScript-фреймворками, с такими, как Angular, React и Vue.
WebAssembly сейчас находится на стадии бурного развития. Текущая реализация этой технологии — это то, что называют «минимальным жизнеспособным продуктом». Возможностей такого «продукта» хватает только на то, чтобы его можно было бы использовать в неких важных сценариях, но не на то, чтобы его можно было бы рассматривать как универсальную технологию для веб-разработки. По мере того, как WebAssembly будет использоваться всё более широким сообществом разработчиков, эта технология будет улучшаться. Например, если платформы наподобие Blazor станут популярными — в WebAssembly, скорее всего, добавят поддержку прямого доступа к DOM. Производители браузеров планируют реализовать сборку мусора и многопоточность, а это значит, что средам выполнения не придётся всё это реализовывать самостоятельно.
Если этот путь эволюции WebAssembly выглядит долгим и сомнительным — предлагаю вспомнить уроки, которые нам дал JavaScript. Для начала, мы видели, что если что-то можно сделать средствами JavaScript — то это делается. Далее, мы узнавали о том, что если что-то делается достаточно часто, то производители браузеров прилагают усилия к тому, чтобы это можно было бы сделать лучше. И так далее. Если технология WebAssembly будет пользоваться популярностью, это значит, что она попадёт в «спираль удачи», в цикл постоянных улучшений. Эти улучшения способны привести к тому, что в споре WebAssembly и JavaScript сможет победить WebAssembly.
Часто говорят, что технологию WebAssembly создавали не для того, чтобы она заменила бы JavaScript. Но эта идея применима к любой революционной платформе. JavaScript не проектировали как замену Java-апплетам, встроенным в веб-страницы. Веб-приложения не были рассчитаны на то, чтобы заменить классические настольные приложения. Но новое, как только у него появилась такая возможность, пришло на смену старому.
Уважаемые читатели! Как вы думаете, станет ли WebAssembly убийцей JavaScript?
Комментарии (280)
ekabandit
22.10.2019 12:49Как по мне javascript (ровно как и react) уже набрал свою критическую массу и сдвинуть его будет ой как тяжело.
И я бы не говорил что WebAssembly это убийца, скорей шанс для TC39 увидеть что-то интересноеakuzmin
22.10.2019 17:54+1Последние годы Javascript перенял много фич, которые первоначально появились в Typescript (OOП модель, асинхронные обёртки типа promises и async/await, и многое другое), да и вообще начал быстро развиваться в конструктивном направлении. Вот если когда-нибудь он переймет и основную фичу Typescript — статическую типизацию, то сдвинуть его каким-либо другим языком будет практически нереально.
ekabandit
22.10.2019 18:17Согласен
Но JavaScript перенимает очень медленно, что на типы и не приходится надеятся.
К примеру только сейчас появляется Optional Chaining, который был в CoffeeScript уже больше 5 лет назад
Spaceoddity
22.10.2019 20:39-2А можно на пальцах? Вот чем динамическая типизация хуже статической? Просто это всё как мантра из поста в пост передаётся.
0xd34df00d
22.10.2019 20:43+6Тем, что статическая типизация позволяет узнать, что ваша программа не делает ерунду1 до запуска вашей программы, а динамическая — нет.
1 Для некоторого определения ерунды, которое будет различным для С, хаскеля и идриса, например.
Spaceoddity
22.10.2019 20:46-4Что одновременно сразу резко повышает трудозатраты на разработку. JS ведь стал таким популярным не потому что он так хорош, а что это некий вменяемый компромисс между порогом вхождения в разработку и качеством продукта.
Статическая типизация — это же никакая не панацея.0xd34df00d
22.10.2019 21:07+3Что одновременно сразу резко повышает трудозатраты на разработку.
Не обязательно.
Почему-то я, знающий статически типизированный хаскель, опережаю коллег, знающих питон.
То есть, конечно, время до первого запуска (пусть и заканчивающегося трейсбеком) у них меньше, но время до корректных результатов почему-то меньше у меня.
Статическая типизация — это же никакая не панацея.
Это тоже зависит от типизации.
Просто, ну, не надо о статической типизации судить по языкам типа C++ или Java.
VolCh
23.10.2019 00:58Как и не надо говорить о статичнской типизации как о строгой и мощной системе типов по умолчанию.
p07a1330
23.10.2019 23:12Погодь — так разве Java не язык с строгой статической типизацией?
А в С++ напротив типизация динамическая — привет "*_cast<>" — ам0xd34df00d
23.10.2019 23:21Погодь — так разве Java не язык с строгой статической типизацией?
Она действительно статическая и действительно достаточно строгая. Но она не является выразительной, и она довольно тяжеловесна.
А в С++ напротив типизация динамическая — привет "*_cast<>" — ам
Лол, как будто в джаве кастов нет. И в джаве в рантайме о типах известно поболе, чем в C++.
В языках с динамической типизацией касты (в плюсовом стиле), кстати, не нужны.
p07a1330
23.10.2019 23:45Не, я про приведение типов в Джаве в курсе, как бы.
Другой вопрос, что Джава, емнип, привести класс Person к классу Plane не позволит — классы должны наследоваться. В С++ же с помощью явного приведения можно привести что угодно к чему угодно. Я уж молчу про константы, которые не константы…0xd34df00d
24.10.2019 00:24Другой вопрос, что Джава, емнип, привести класс Person к классу Plane не позволит — классы должны наследоваться. В С++ же с помощью явного приведения можно привести что угодно к чему угодно.
Ну это зависит.
Во-первых, касты в плюсах не дают приводить классы, а только указатели или ссылки на них.
С учетом этого,
static_castтоже не даст, если нет отношения наследования.dynamic_cast— тем более (+ проверит, что там действительно лежат нужные инстансы, в рантайме).
reinterpret_cast— даст, но если у вас по адресу, который вы получили послеreinterpret_cast<Plane*>(Person*)не лежит объекта типаPlane, то у вас в коде UB, и не надо так делать.
const_castтуда же. Код
void danger(const int& bar) { const_cast<int&>(bar) = 10; } void foo() { int var = 42; danger(var); }
вполне валиден, а вот если вы замените
int varнаconst int var, то он перестанет быть валидным. А если после этой замены поменяете телоdangerнаstd::cout << const _cast<int&>(bar);, то снова всё станет в порядке.
potan
23.10.2019 18:45JS стал таким популярным, потому что его поддержали браузеры без дополнительных плугинов.
VolCh
24.10.2019 09:58Потому что он изначально создавался как часть браузера Netscape тогда уж. А "поддержали" значит "Microsoft создала свой очень похожий и почти совместимій язык JScipt как часть своего браузера".
ZXZs
22.10.2019 20:46Чтобы ловить ошибки при компиляции, а не в рантайме, нужна статическая типизация. Да и код интуитивно понятнее будет с типами.
AlexanderTyutin
23.10.2019 10:55Вот здесь вроде ребята на своем опыте хорошо разложили.
habr.com/ru/company/ruvds/blog/468233
akuzmin
23.10.2019 12:15Чтобы когда в проекте из сотен js-файлов наводишь на функцию в своей любимой IDE'шке, и она сразу показывает, что в эту функцию передается.
jhonyxakep
24.10.2019 12:54Современные IDE поддерживают JSDoc формат описаний, в которые можно добавить типы
IvanNochnoy
24.10.2019 16:20+1Есть нюанс: адепы отсутствия типизации не будут писать эти громозкие комменты, так как это противоречит их идеологии, а адептам строгой типипизации типы в комментах не нужны.
whileTrue
23.10.2019 17:53+2Все то что вы перечислили что JS перенял из TS-а это не правда, классы были во времена ES4 (2000-2008), промисы предложили для стандарта ES6 в 2012 когда TS только появился на свет, до этого еще в 2011 были deffered objects в jQuery, async/await взят из C#. TypeScript еще никак не повлиял на развитие синтаксиса JavaScript или на другие части языка, да, он дополняет JavaScript своими типами, областью видимости, интерфейсами, enum-ами, и так далее, но пока что ничего из того что TypeScript предоставляет не было добавлено в стандарт EcmaScript.
akuzmin
23.10.2019 18:05Когда промисы приняли в JS, это было в версии ES6, то есть 2015 год, в TS они уже 3 года как работали, и синтаксис был такой же. Да, async/await взят из C#, но создатель C# и создатель Typescript — это один и тот же человек, Андерс Хайльсберг. То есть, получается, С# имеет влияние на TS, а TS в свою очередь на JS.
VolCh
24.10.2019 10:02Тут надо смотреть не когда приняли, а когда начали реализовывать хотя бы в виде предложений. Если, условно, в релиз TS попало что-то что в ES в stage 3 находится, но предложение в TS появилось только после перехода в stage 3, то тут сложно говорить, что TS повлиял на ES
printf
22.10.2019 13:42Я не верю в полноценное убийство жаваскрипта вебассемблей просто потому, что на JS очень удобно писать glue code, высокоуровневую бизнес-логику. То, что сейчас происходит (ну, начинает происходить) — «тяжелые» библиотеки переползают на WebAssembly (см. например libsodium), высокоуровневый код остается на JS, и все более-менее счастливы.
Многие проекты выработали аналогичную структуру, двигаясь в обратном направлении: начали с «библиотечного» С++, а затем прикрутили сверху скриптовый язык для glue code. В World of Warcraft для скриптинга выбрали Lua, в Qt теперь QML (== жаваскрипт вид сбоку), и так далее.
RPG18
22.10.2019 13:50QML ни разу не легковесный. Разработчикам Qt пришлось писать AOT и JIT компиляторы.
Chamie
22.10.2019 14:28RPG18
22.10.2019 14:33Нет. Они v8 использовали во время бета версии Qt5, но это не переносимо.
Chamie
22.10.2019 14:52А, в Qt Wiki пишут, что там JavaScriptCore.
И в 3rd-party components он указан.
QtRoS
22.10.2019 17:52Сначала использовал, а потом оказалось, что проще написать свой рантайм, чем постоянно переключаться между Qt и V8. В итоге новый QV4 работает и быстрее в задачах фреймворка, и много боли ушло.
eumorozov
22.10.2019 14:31Терзают смутные сомнения. Еще задолго до появления node.js/npm/React и т.п., очень часто можно было услышать мнение, что JS — плохой язык. Сам автор языка изначально хотел другой язык в браузере. Были попытки реализовать другие языки в браузерах, все неуспешные, так как браузеров много, часть с закрытыми исходниками, особенно ранее. Если язык не появится во всех браузерах одновременно, то и пользы никакой от альтернативного языка в браузере нет — никто не станет на нем писать, чтобы отрезать часть пользователей с другими пользователями.
Есть сотни языков лучше Javascript, но в его среде они до сих пор не могли с ним тягаться просто потому что им был закрыт доступ в эту среду по определению.
И вот ситуация наконец начала потихоньку меняться. Лично мне кажется, что будет только к лучшему, если наконец какая-то технология заменит Javascript. У меня какое-то идиосинкратическое неприятие к нему.
А низкий порог входа, увы, означает тонны плохого кода. Javascript, по-моему, относится к категории языков на которых хорошо писать можно, но сам язык и окружение скорее побуждают писать плохо.
smarthomeblog
22.10.2019 14:58ИМХО язык никого не может в принципе побуждать писать плохой код. Лично лицезрел приложение на Java, втиснутое в один класс и в цикле, загружающее рекламу и расписание показа с удаленного сервера и показывающее эту самую рекламу. Кода было экранов на пять. Не язык программирования красит разработчика ;)
eumorozov
22.10.2019 15:04+2Я написал другое: есть языки, которые в принципе не препятствуют написанию плохого кода, даже способствуют. И считаю, что Javascript — такой язык. Плохой код написать на нем проще, чем хороший. Это не значит, что хороший написать нельзя. Это значит, что с плохим придется сталкиваться чаще.
Aingis
22.10.2019 15:16+21) Говнокод можно написать на любом языке.
2) Количество ограничений языка обратно пропорционально developer experience (DX) и скорости разработки. Чем менее удобен язык, тем меньше на нём будут писать.
3) Качество кода, как ни крути, определяется прокладкой между стулом и монитором. Многие не удосужились выучить базовые правила и наработки, но идут всё туда же, критиковать язык.
4) Есть два типа языков: те, которые ругают, и те, которыми никто не пользуется.
impwx
23.10.2019 13:14- Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается. И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.
- Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы, и когда вам на каждый чих нужно лезть в документацию на гитхабе (которая может быть неполной, неактуальной или вообще отсутствовать).
- См. пункт 1.
- Если работаешь с вебом — избежать работы с джиесом, увы, невозможно.
JustDont
23.10.2019 13:42И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.
Вы пишете какой-то поэзией там, где неплохо бы как раз применять точные термины. «Дизайн языка» — это что?
Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде. Концепции DSL (взаимодействие с браузером и документом) в нынешнем JS реализованы очень банально и просто, говнокодить там просто негде. Дополнительные плюшки, «синтаксический сахар» (хотя, строго говоря, не обязательно именно синтаксический), артефакты обратной совместимости — существование этого всего можно просто игнорировать, если вам не нравится качество (скажем, сегодня никто вас не заставляет руками составлять XML из базовых типов, хотя это безусловно возможно сделать). И конкретно для JS на ваше
Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается.
я вам могу просто ответить «Изучайте современный JS. Не изучайте JS десятилетней давности», и вопрос будет исчерпан.
Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы
Возможности IDE и ограничения языка — это две абсолютно разные вещи. Вам писали про второе, а вы ответили первым. Если (чисто как пример) в языке не существует циклов, то никакая IDE вам его не сделает настолько удобным, что вы его предпочтете языку с циклами.impwx
23.10.2019 14:17Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде.
Смешно, что многие из этих базовых концепций работают одинаково во всех остальных языках, но не в джиесе :)
Изучайте современный JS
А что там исправили? Запретили monkey patching объектов, неявное приведение, передачу несовпадающего количества аргументов в функцию, исправили семантику `Foo() / new Foo()`, устранили возможность абсолютно любому скрипту нагадить в глобальную область или подменить функцию стандартной библиотеки? Из полезного добавили разве что приватные поля — да и то с костылями из-за проблем с обратной совместимостью.
Возможности IDE и ограничения языка — это две абсолютно разные вещи.
Кто вам сказал такую глупость? Эти вещи тесно взамосвязаны. Из-за динамической природы языка для джиеса впринципе невозможно реализовать автокомплит\рефакторинги уровня IDEA\R#.JustDont
23.10.2019 14:38А что там исправили? Запретили
Вы тоже из тех, кто возможность выстрелить себе в ногу приравнивает к выстрелу?
Как насчёт того, чтоб просто не стрелять?
И нет, аргумент «в более крутых языках возможностей выстрелить себе в ногу меньше, а поэтому там пишут меньше говнокода» не принимается, пока вы его не докажете. Моя практика показывает, что объем говнокода почти исключительно зависит от общего объема пишущегося кода, а не от языка. Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую. Если в какой-то момент какой-нибудь хаскель станет жутко популярным (впрочем, навряд ли) — мы увидим множество интересных способов отстрелить себе ноги там.
Эти вещи тесно взамосвязаны.
Возможности IDE вытекают из ограничений языка, а не наоборот. Поэтому не стоит на аргумент об ограничениях языка отвечать «а вот IDE оооо!». Я вам писал именно об этом. Вы предпочли этого не заметить, а избирательно процитировать и спорить дальше.impwx
23.10.2019 15:40Как насчёт того, чтоб просто не стрелять?
Для этого надо быть сверхчеловеком, который сам никогда не ошибается, не работает с джунами, не поддерживает легаси и вообще не использует сторонние библиотеки. К сожалению, в реальном мире я таких не знаю.
Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую.
Так это правильный баланс между гибкостью и надежностью. Нет такого языка, который мог бы вообще не дать написать на нем некорректную программу. Однако в той же джаве «целевое» использование объектов заметно проще и короче, чем «нецелевое» с помощью рефлексии, а в джиесе они равнозначны.
Я вам писал именно об этом.
Изначальный постулат был — «ограничения усложняют разработку». Я привел пример того, как некоторые ограничения ее наоборот упрощают. Вашу же мысль я в обоих сообщениях так и не уловил…
0xd34df00d
23.10.2019 16:32+2Вы тоже из тех, кто возможность выстрелить себе в ногу приравнивает к выстрелу?
Я про себя знаю, что я глупый, забывчивый и иногда бываю невыспавшимся. Более того, иногда другие люди бывают невыспавшимися, а ещё иногда два совершенно гениальных и выспавшихся человека не понимают друг друга, и ерунда с выстрелами и спецэффектами происходит на границе взаимодействия их модулей.
Как насчёт того, чтоб просто не стрелять?
Тесты? Как насчёт того, чтобы просто не делать ошибок?
Рефакторинг? Как насчёт того, чтобы сразу писать нормально?
Джаваскрипт на бэкенде? Как насчёт того, чтобы выучить C++ за 21 день и на нём быстро писать?
Если в какой-то момент какой-нибудь хаскель станет жутко популярным (впрочем, навряд ли) — мы увидим множество интересных способов отстрелить себе ноги там.
Он уже достаточно популярен, на самом деле, чтобы не опасаться за наличие работы или отсутствие библиотек. Ну и да, avoid popularity at all costs — это как раз про то, чтобы не идти на компромиссы и необдуманные решения просто ради того, чтобы набрать классы.
Но нет, способов выстрелить в ноги там очень мало. Они есть, но когда я надеваю шляпу C++-программиста, мне даже в голову не приходит считать их чем-то плохим (что? нельзя доказать, что функция всегда завершается? а зачем это в С++?).
JustDont
23.10.2019 16:44+1Я про себя знаю, что я глупый, забывчивый и иногда бываю невыспавшимся.
Мне сложно себе представить, что я от забывчивости или от недосыпа вдруг начну применять в яве рефлексию просто потому что. Или в JS буду на лету патчить прототип.
От таких вещей можно написать нерабочий код, но не говнокод через использование заведомо глубоко небезопасных фич языка. А глупость стоит лечить образованием.
Тесты? Как насчёт того, чтобы просто не делать ошибок?
Рефакторинг? Как насчёт того, чтобы сразу писать нормально?
Джаваскрипт на бэкенде? Как насчёт того, чтобы выучить C++ за 21 день и на нём быстро писать?
Вы передергиваете. Изначальная соль метафоры с «выстрелом в ногу» как раз и заключается в том, что в ногу можно стрелять, а можно не стрелять. И стреляя — нужно осознавать последствия.
Если у языка есть глубоко небезопасные и вообще кривоватые фичи — их можно не использовать. Это совсем далеко не то же самое, что «не делать ошибок». Мне очень странно, что вы тут сделали вид, что не понимаете разницы.
Но нет, способов выстрелить в ноги там очень мало.
Про яву так в свое время тоже говорили. Всерьез говорили.0xd34df00d
23.10.2019 16:52Мне сложно себе представить, что я от забывчивости или от недосыпа вдруг начну применять в яве рефлексию просто потому что. Или в JS буду на лету патчить прототип.
Это на недосып действительно списать труднее. Я же скорее говорил о вещах вроде типов и тому подобного.
Хотя… Иногда от доступа к приватным полям меня останавливало только ключевое слово
privateи правила языка, потому что иначе я его не замечал.
Изначальная соль метафоры с «выстрелом в ногу» как раз и заключается в том, что в ногу можно стрелять, а можно не стрелять. И стреляя — нужно осознавать последствия.
К сожалению, в проектах, которые я пишу, кроме моего кода есть ещё и чужой код, и он даже иногда обновляется. И какую ерунду он там делает, мне верифицировать каждый раз неохота.
Про яву так в свое время тоже говорили. Всерьез говорили.
Однако она действительно является большим шагом вперёд по сравнению с теми же плюсами с точки зрения безопасности.
Ну и да, из этого не следует, что ни в каком языке теперь не будет возможности ограничить себя в подобных выстрелах в ноги.
JustDont
23.10.2019 16:56К сожалению, в проектах, которые я пишу, кроме моего кода есть ещё и чужой код, и он даже иногда обновляется. И какую ерунду он там делает, мне верифицировать каждый раз неохота.
К счастью, для этого придумали средства. От code review до автоматического линтинга с запретом всего, что стоит запретить. Если ими пользоваться — большая часть проблем таки решается.
А если 30 человек фигачат в блокнотах и пушат в мастер — ну, кто ж им доктор.0xd34df00d
23.10.2019 16:59А вы так все библиотеки ревьювите и линтите?
Как убеждаетесь, что они биткоины по-тихому не майнят, например?
JustDont
23.10.2019 17:02Проблема стороннего кода (и пакетных менеджеров, до кучи) вообще ни разу не сопрягается с языком. Вы используете какой-либо чужой код (от библиотек до функций ОС)? А как вы убеждаетесь, что он биткоины не майнит?
И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.0xd34df00d
23.10.2019 17:13+1Сопрягается, и ещё как.
А как вы убеждаетесь, что он биткоины не майнит?
Смотрю на те функции, которые живут в
IO, и которыми я пользуюсь (если это какая-нибудь библиотека на графах или библиотека сортировки массивов, то их вообще нет). Проверяю, что для используемого модуля выводится, что он лежит вSafe-подмножестве. Если это так, то можно дальше даже не смотреть, если не так, то разбираюсь внимательнее (но это на моей практике бывало очень редко).JustDont
23.10.2019 17:39Если это так, то можно дальше даже не смотреть, если не так, то разбираюсь внимательнее (но это на моей практике бывало очень редко).
Вы же понимаете, что вы сейчас описали страну розовых пони вида «мне мало что нужно, а что нужно, то есть в опенсорсе, и в моем языке небезопасные вещи объявляются отдельно»?
Что нисколько не решает проблему в общем виде. С тем же успехом могли бы сказать «я не использую чужого кода» (а моя ОС написана мной самим). Вышли бы те же розовые пони.0xd34df00d
23.10.2019 17:46Нет, не понимаю, потому что я этот подход успешно реализую на практике.
JustDont
23.10.2019 18:09потому что я этот подход успешно реализую на практике
И делаете ошибку выжившего в разговоре вот сейчас.0xd34df00d
23.10.2019 18:13Ваш тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов возможно всегда и не зависит от языка. Я привел контрпример, когда язык вполне даёт возможность гарантировать, что какой-то код так не делает. Для опровержения вашего тезиса одного контрпримера, собственно, достаточно, и ошибки выживших тут ни при чём.
JustDont
23.10.2019 19:32Я привел контрпример, когда язык вполне даёт возможность гарантировать, что какой-то код так не делает.
Вы привели контрпример, в котором сделано множество допущений. Начиная с того, что вам доступен исходный код и вы собираете его сами достоверно надёжными средствами сборки (которые вы тоже собрали сами), в достоверно надёжном окружении (которое вы сами — что? правильно, начиная от самого железа), заканчивая тем, что, дескать, если чо, то вы будете «разбираться внимательнее» (без подробностей).
Ваш тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов возможно всегда и не зависит от языка.
Вы передергиваете. Мой тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов в условиях среднестатистического окружения никак не коррелирует с тем, на каком языке написан ваш (ключевое слово) код.
С «возможно всегда», которое вы сами придумали и которое доблестно попытались развенчать — сами и воюйте, если вам интересно.0xd34df00d
23.10.2019 20:24+1Начиная с того, что вам доступен исходный код
Сторонних библиотек, особенно берущихся с npm/pip/hackage? Да. Да и без этого, я по пальцам могу пересчитать библиотеки, у которых нет исходников и которыми приходилось пользоваться.
Кроме того, code review и линтинг предложили вы сами. Теперь вас это резко не устраивает, и у вас появляются библиотеки с закрытыми исходниками. Ну ок.
вы собираете его сами достоверно надёжными средствами сборки (которые вы тоже собрали сами)
Зачем? Это не нужно для того, чтобы обезопаситься от кривой библиотеки.
И линтеры с кодревью у вас, я так понимаю, достоверно надёжны?
тем, что, дескать, если чо, то вы будете «разбираться внимательнее» (без подробностей)
Да. Например, если Safe не выводится, то смотреть, почему и что мешает, и насколько это оправдано. Ну, то есть, свести потребность к ручному вмешательству и ручному анализу кода к минимуму.
Мой тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов в условиях среднестатистического окружения никак не коррелирует с тем, на каком языке написан ваш (ключевое слово) код.
Давайте ещё раз на него посмотрим, вот он:
И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.
Тут нет ничего ни про какую среднюю статистику окружения. И в словах ваших из того комментария, идущих до этой цитаты, тоже ничего нет про это.
При этом в том же хаскеле
JustDont
23.10.2019 20:54Кроме того, code review и линтинг предложили вы сами.
Как средство борьбы с появлением плохого кода у себя.
Как средство контроля внешнего кода — это такой себе выход, эффективность которого сомнительна в произвольной степени.
Зачем? Это не нужно для того, чтобы обезопаситься от кривой библиотеки.
Затем, что в конечном счете разговор о майнерах и снифферах в контексте «в моем коде этого нет» не имеют ни малейшего практического смысла. Либо майнера и сниффера у вас нет совсем и вы можете гарантировать, что исполняемый код, так или иначе связанный с запуском вашей крутой программы, не несет в себе потенциальных угроз, или это всё пустые разговоры а-ля «в исходниках нет, а прочие проблемы меня не волнуют». Чудесный код, сам по себе не делающий ничего особенного, а-ля, скажем, TeamViewer — может быть использован для множества очень интересных сценариев, если будет написан с определенными уязвимостями.
В контексте этого разговоры «я если чё почитаю код и оценю, насколько в нём всё ок» — это тоже мир розовых поней. Вы не всесильны и не всезнающи.
Давайте ещё раз на него посмотрим
Попробуйте не вырывать предложения из контекста, и всё будет гораздо лучше.0xd34df00d
23.10.2019 21:29Либо майнера и сниффера у вас нет совсем и вы можете гарантировать, что исполняемый код, так или иначе связанный с запуском вашей крутой программы, не несет в себе потенциальных угроз, или это всё пустые разговоры а-ля «в исходниках нет, а прочие проблемы меня не волнуют».
Мы не можем гарантировать отсутствие закладок в компиляторе и ОС, поэтому давайте забьём на любой анализ последнего left-pad. Понятно.
В контексте этого разговоры «я если чё почитаю код и оценю, насколько в нём всё ок» — это тоже мир розовых поней. Вы не всесильны и не всезнающи.
Безусловно. К счастью, пока что во всех случаях, когда я натыкался на unsafePerformIO, unsafeCoerce и тому подобные вещи в коде чужой библиотеки, их удавалось избежать и переписать.
А где-то примерно один раз я вообще от библиотеки отказывался из-за unsafe в коде.
Попробуйте не вырывать предложения из контекста, и всё будет гораздо лучше.
Я специально указал, что (на мой взгляд, конечно же) про среднестатистическое окружение в вашем комментарии ничего не было, а цитировать весь комментарий целиком как-то глупо. Но вы, конечно, можете меня побить одной левой, указав, где конкретно вы об этом говорили.
Хотя это всё пустое, ибо если вы согласитесь, что есть языки, предоставляющие возможности проверять библиотеки без ложноотрицательных (т. е. не нашли ерунду, когда она там на самом деле есть) срабатываний и с очень малой долей ложноположительных срабатываний, то вопрос будет исчерпан сам собой.
JustDont
23.10.2019 21:40Мы не можем гарантировать отсутствие закладок в компиляторе и ОС, поэтому давайте забьём на любой анализ последнего left-pad. Понятно.
Ложная дихотомия.
Я вам о том, что можете заисследовать left-pad, а ваш софт всё равно в итоге будет майнить.
К счастью, пока что во всех случаях, когда я натыкался на unsafePerformIO, unsafeCoerce и тому подобные вещи в коде чужой библиотеки, их удавалось избежать и переписать.
Вы опять взялись за «я делаю всё хорошо и правильно, значит в мире всё окей».
Я специально указал, что (на мой взгляд, конечно же) про среднестатистическое окружение в вашем комментарии ничего не было
В моем комментарии так же не было и «помайнить возможно всегда», на которое вы уже который комментарий пытаетесь наехать с позиций особых лабораторных условий, в которых таки кое-что будет невозможно. А было только лишь «помайнить равновероятно можно в коде на любом языке».
если вы согласитесь, что есть языки, предоставляющие возможности проверять библиотеки без ложноотрицательных (т. е. не нашли ерунду, когда она там на самом деле есть) срабатываний и с очень малой долей ложноположительных срабатываний, то вопрос будет исчерпан сам собой
Как только вы обоснуете это чем-нибудь более интересным, чем «я вот что-то там пишу, и оно у меня пока что не майнило, и я считаю, что и не сможет» — непременно.0xd34df00d
23.10.2019 22:23Я вам о том, что можете заисследовать left-pad, а ваш софт всё равно в итоге будет майнить.
Может. Машина может майнить даже вообще без моего софта, с одной голой ОС. Но я топлю не за это, а за то, что вы можете решить кучу проблем относительно бескровным методом. Новости про то, что в репозиториях npm/pip/etc попался очередной вирус/кейлоггер/троян, проскакивают чуть более систематично, чем хотелось бы, тогда как от этоо защититься легко.
А было только лишь «помайнить равновероятно можно в коде на любом языке».
Нет. Если у вас в типе функции нет
IOи она не использует полтора unsafe-хака (которые может проверять компилятор), то она не может майнить. И вызываемые ей функции не могут майнить. И так далее.
Как только вы обоснуете это чем-нибудь более интересным, чем «я вот что-то там пишу, и оно у меня пока что не майнило, и я считаю, что и не сможет» — непременно.
(надеваю чёрные брюки и белую рубашку, беру The Haskell Report под мышку) Извините, у вас не найдётся минутки, чтобы поговорить о чистоте? Вы что-нибудь слышали о монаде IO?
JustDont
23.10.2019 22:28Но я топлю не за это, а за то, что вы можете решить кучу проблем относительно бескровным методом.
Конечно. Один из таковых методов называется «не пользуемся пакетными менеджерами». К языку отношения не имеет.
Если у вас в типе функции нет IO и она не использует полтора unsafe-хака (которые может проверять компилятор), то она не может майнить. И вызываемые ей функции не могут майнить. И так далее.
Функционально такой же (но плохой и непроверяемый) код на JS, никак не взаимодействующий с внешним миром — равновероятно не может майнить.
Вы упираете в то, что вы можете «просто глянуть на типы» и быть в чём-то там уверенным. Я вам говорю о том, что просто глянув на типы вы можете быть уверенным в чём угодно, но только не в том, что в итоге оно всё не будет майнить. Для серьезного повышения уверенности — вам нужно или писать очень специфический камерный код (но в этом случае вы и на JS можете писать камерный код), или вы так или иначе будете взаимодействовать с чем-то за пределами вашего кода, для чего безопасность вы не обоснуете.0xd34df00d
23.10.2019 22:37Один из таковых методов называется «не пользуемся пакетными менеджерами». К языку отношения не имеет.
Я бы не назвал его бескровным.
Функционально такой же (но плохой и непроверяемый) код на JS, никак не взаимодействующий с внешним миром — равновероятно не может майнить.
А может и майнить. Тайпчекера-то нет, чтобы проверить отсутствие взаимодействия с внешним миром.
Я вам говорю о том, что просто глянув на типы вы можете быть уверенным в чём угодно, но только не в том, что в итоге оно всё не будет майнить.
Почему? Ну, конечно же, при некоторых дополнительных допущениях, ряд которых вы вполне корректно заметили, вроде корректности компилятора, ОС и тому подобных вещей.
JustDont
23.10.2019 22:40А может и майнить.
Ваш мобильник не управляет вами, даже если вы в этом не уверены.
Аналогично, код, который не майнит — не майнит. Проверяете вы ли его тайпчекером, ревьюверами, статанализом, или, наконец, файрволлом.
Мой тезис про равновероятность на разных языках — он всё таки «при прочих равных», а не «на хаскеле у меня один код, а на JS другой, и первый скорее всего не майнит, а второй скорее всего да».0xd34df00d
23.10.2019 22:43Так смысл не в этом. Смысл в том, чтобы поймать код, который майнит, но притворяется, что не майнит.
JustDont
23.10.2019 22:47Смысл в том, что когда вы начнете писать что-то, что взаимодействует с внешним миром — вы больше не сможете сказать, что раз у вас в коде типы норм, то ничего майнить не будет.
0xd34df00d
23.10.2019 22:52Безусловно, тогда мне придётся просмотреть реализацию того, что взаимодействует с внешним миром. Но у меня будут гарантии, что некоторые вещи (на самом деле, практика показывает, большинство) с этим самым внешним миром не взаимодействуют.
Более того, для вещи, которая взаимодействует с внешним миром в виде работы с БД, у меня всё равно могут быть гарантии, что она не читает из файлов или не шлёт запросы по HTTP. Или код, на самом деле взаимодействующий с внешним миром, может сводиться к одной функции на экран текста (свободные монады, это всё).
JustDont
23.10.2019 22:55Безусловно, тогда мне придётся просмотреть реализацию того, что взаимодействует с внешним миром.
Что ничего не гарантирует.
Более того, для вещи, которая взаимодействует с внешним миром в виде работы с БД, у меня всё равно могут быть гарантии, что она не читает из файлов или не шлёт запросы по HTTP.
Но раз уж мы тут довели беседу до таких глубин — то вообще-то отсутствие связей с внешним миром — тоже такой себе гарант невредоносности кода. Код может вредоносить банальным отжиранием ресурсов во время выполнения.0xd34df00d
23.10.2019 22:59Что ничего не гарантирует.
Согласитесь, что лучше, когда гарантии обеспечены только лишь моими глазами в одной функции из 10-100-1000, а не во всех из них, не правда ли?
Но раз уж мы тут довели беседу до таких глубин — то вообще-то отсутствие связей с внешним миром — тоже такой себе гарант невредоносности кода. Код может вредоносить банальным отжиранием ресурсов во время выполнения.
Полностью согласен.
Характеристики производительности, конечно, тоже можно доказывать и выражать в типах, но это совсем не мейнстрим и перебор.
Cerberuser
24.10.2019 05:59Характеристики производительности, конечно, тоже можно доказывать и выражать в типах, но это совсем не мейнстрим и перебор.
Можно на этом месте попросить наводку, где про это почитать поподробнее?
0xd34df00d
24.10.2019 17:18Ну, вы можете формально доказывать, что некоторая функция сделает не более
f(n)шагов для входа длиныn. Информация на эту тему очень разрозненная и на уровне фольклора, но я когда-нибудь соберусь и напишу что-нибудь на эту тему.Cerberuser
24.10.2019 18:20Будем ждать, потому что тема весьма заинтриговала. Честно говоря, надеялся, что уже есть какая-то более-менее внятная литература, но раз так — будем ждать мысли по теме от Вас :)
0xd34df00d
24.10.2019 22:34Ну, с функциями в deep embedding всё понятно — просто берёте и доказываете. С shallow embedding всё, конечно, поинтереснее.
0xd34df00d
23.10.2019 16:27+2«Дизайн языка» — это что?
Наличие/отсутствие неявных преобразований, продуманность системы типов, принцип наименьшего удивления, всё такое.
Я пробовал на питоне писать — куча непоняток и WTF-моментов, связанных с чем-то, что нельзя назвать иначе как дизайн языка.
Базовые концепции всех императивных языков
А зачем ограничиваться только ими?
Если (чисто как пример) в языке не существует циклов, то никакая IDE вам его не сделает настолько удобным, что вы его предпочтете языку с циклами.
Пишу на языках без циклов с наибольшим удовольствием, кстати.
psFitz
23.10.2019 22:51Пишу на языках без циклов с наибольшим удовольствием, кстати.
Это какой?
И как там сделать
while(true){}
?)0xd34df00d
23.10.2019 22:53+1Это какой?
Хаскель, идрис (но последний только как хобби пока что).
И как там сделать while(true){}
infinite = infinite
В идрисе с тоталити чекером никак, но это хорошо: доказуемая продуктивность — полезное свойство.
LborV
22.10.2019 17:36+2Интересно, чем это джаваскрипт способствует написанию плохого кода? Крайне удобный язык и часто им пользуюсь
Kanut
22.10.2019 19:43Я не знаю способствует он или нет. И возможно это просто я один такой везучий. Но почему то на JavaScript мне попадалось и всё ещё попадается гораздо больше плохого(а местами даже просто ужасного) кода чем на других языках.
impwx
23.10.2019 13:21Неявное приведение типов, неконсистентность стандартной библиотеки, легкость monkey-patching'а, отсутствие поддержки приватного состояния (по крайней мере до недавнего времени)… Вот нескольки смачных примеров: https://wtfjs.com/
Aingis
23.10.2019 15:15Неявное приведение типов
Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.
неконсистентность стандартной библиотеки
В каком смысле? Современные браузеры очень консистентны, старые методы работают всегда, благодаря обратной совместимости.
легкость monkey-patching'а,
Не нравится — не используйте. Кто заставляет? В чём проблема языка, что он представляет мощные возможности по расширению?
отсутствие поддержки приватного состояния
Паттерн «модуль» существует столько, сколько существуют замыкания.
Типичные аргументы хейтеров, не прочитавших хоть какую-нибудь документацию. Эффект «утёнка»: «а у нас в языке не так!»eumorozov
23.10.2019 15:20+2Ваши ответы имели бы смысл, если бы все вокруг были бы идеальными людьми:
Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.
Только что делать, если у тебя есть унаследованная база кода, которую написали люди не знающие базовых правил, и в которой используются глобальные переменные, манкипатчинг и т.п.?
А в этом и есть сложность разработки: в основном мы не пишем новый код, а работаем с существующим, написанным скорее всего не нами.
impwx
23.10.2019 15:57Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.
Ну вот сходите по ссылке и посмотрите, сколько из примеров вы сможете полноценно объяснить знанием нескольких базовых правил :)
Современные браузеры очень консистентны
Мой любимый пример: `new Date(2019, 10, 23) == new Date(«2019-10-23»)` дает `false`, попробуйте угадать почему.
Типичные аргументы хейтеров, не прочитавших хоть какую-нибудь документацию. Эффект «утёнка»: «а у нас в языке не так!»
Ровно наоборот: работа с несколькими языками дает возможность сравнить и понять их сильные\слабые стороны, а вот если человек кроме джиеса ничего не знает — то он вполне ожидаемо будет по-утиному оправдывать его недостатки…Aingis
23.10.2019 16:24Ну вот сходите по ссылке и посмотрите, сколько из примеров вы сможете полноценно объяснить знанием нескольких базовых правил :)
Все эти примеры давно разобраны. Могу объяснить любой, который непонятен. Но тут главное даже не это. Никто в здравом уме не будет писать такой код в продакшен, именно поэтому достаточно базовых правил.
Мой любимый пример:
Чего-то тут гадать, базовое правило: два разных объекта (любых непримитивов) никогда не равны друг другу. Даже с одинаковыми значениями. Тоже самое что сравниватьnew Date(2019, 10, 23) == new Date("2019-10-23")даетfalse, попробуйте угадать почему
({} == {}) // falseХотя даты, конечно, весьма своеобразный объект, но это уж так было взято из Java.…дает возможность сравнить и понять их сильные\слабые стороны…
Только вот человек называет сильные стороны слабыми. Причём никто из моих коллег не испытывал с этим никаких проблем.aleksandy
23.10.2019 16:34два разных объекта
Тут скорее всего имелось ввиду, что при передаче аргументов конструктора в виде чисел 10 — это ноябрь.
Тоже самое что сравнивать
({} == {})
А вот сравнение объектов (< или >) выполниить нельзя, а даты — пожалуйста.
impwx
23.10.2019 16:35+1Никто в здравом уме не будет писать такой код в продакшен
С джунами никогда не работали?
два разных объекта (любых непримитивов) никогда не равны друг другу
Окей, немножко усложним:new Date(2019, 10, 23).toString() == new Date("2019-10-23").toString()все еще даетfalse…staticlab
23.10.2019 16:39+1Давайте сразу третий уровень сложности:
new Date(2019, 9, 23).toString() == new Date("2019-10-23").toString() // false
nochkin
23.10.2019 17:05Объясните балбесу в чём тут прикол. Я не понял. Не прикалываюсь, действительно интересно.
В двух примерах это разные даты. Так же тут ещё есть всякие зоны, летнее время и т.д.staticlab
23.10.2019 21:56new Date(2019, 9, 23).toString()Создаётся дата в локальной часовой зоне, причём месяцы нумеруются от 0 до 11, как в
java.util.Date. Получается примерно так:
"Wed Oct 23 2019 00:00:00 GMT+0300 (Москва, стандартное время)"
new Date("2019-10-23").toString()В то же время строка парсится как дата в зоне UTC-0, что соответствует 3:00:00 по московскому времени. Таким образом:
"Wed Oct 23 2019 03:00:00 GMT+0300 (Москва, стандартное время)"
Строки разные, потому что посимвольно не совпадают. QED.
Однако где-нибудь в Лондоне внезапно сравнение вернёт
true:)nochkin
24.10.2019 02:16Вроде логично — сравниваются строки, а не сами даты. Если строки не совпали, то это false.
Почему-то думал, что тут какая-то нелогичная магия, а тут вроде по делу.Free_ze
24.10.2019 14:08Логично ли, что умолчательные таймзоны необоснованно разные?
Aingis
24.10.2019 15:18+1Если подумать, то логично. Обычно парсятся строки в формате ISO вида
"2019-10-24T12:00:00.000Z", в них указан часовой пояс (Zздесь означает UTC+0).
Если создавать дату из конструктора вида
то предполагается работа с пользовательским временем и логично использовать текущую временную зону.new Date(год, месяц, день, час, минуты, секунды);
Работа со временем — сложная область программирования (заблуждения о времени, ещё заблуждения, заблуждения о unix-времени), и это не к языку вопрос, тем более что весьDate— это заимствованные методы.Free_ze
24.10.2019 16:09Ничего не мешало сделать семантику конструкторов консистентной, в ту или другую сторону. Предположения авторов неочевидны для читателя.
весь Date — это заимствованные методы.
Кому какое дело? Эта милая особенность — это на многие годы часть стандартной библиотеки языка.
Ведь даже в Java, на которую, как мне кажется, тут кивают, уже успели добавить адекватную стандартную замену с недвузначными именами (LocalDateTimeиZonedDateTime).
Aingis
23.10.2019 17:42С джунами никогда не работали?
Работал. Но даже непрошедшие испытательный срок таких ошибок не делали. Видимо, они что-то да прочитали про Javascript.
Касательно,Date— это не javascript-way сущность, и потому совсем не показательно с точки зрения языка, не говоря уж про сложность предметной области работы со временем. Вы бы ещё на NaN привели, как это любят.impwx
23.10.2019 18:31+1даже непрошедшие испытательный срок таких ошибок не делали
Остается только позавидовать вашей сверхъестественной везучести, опровергающей закон Мёрфи, и вере в человечество :)
Date — это не javascript-way сущность, и потому совсем не показательно с точки зрения языка
Что она тогда делает в стандартной библиотеке? Почему ее нельзя было сделать javascript-way? Или javascript-way — это собрать некое подмножество хорошо удавшихся вещей, а про остальные сделать вид, будто их не существует?Aingis
23.10.2019 23:26Обратная совместимость не позволяет менять уже существующий стандарт, даже если это неписанный стандарт де факто. Но новые предложения никто не мешает обсуждать, вы может сделать своё предложение и отправить его на рассмотрение в TC39. Именно так язык и развивается. Каждый год выходит новая версия.
aleksandy
23.10.2019 16:36два разных объекта
Тут, скорее всего, имелось ввиду, что 10 — это ноябрь, при передаче аргументов в конструктор в виде чисел.
Тоже самое что сравнивать
({} == {}) // false
zagayevskiy
23.10.2019 14:33Целый один класс на 5 экранов с циклом называть громким именем «приложение» как-то неправильно.
Spaceoddity
22.10.2019 20:42-1Только в период замены — начнётся такая неразбериха… Как лет 10 назад — когда постоянно приходилось выбирать — JS или Flash. Только-только всё устаканилось… Ориентироваться вообще надо сейчас только на один движок — Chromium. Один язык. Одни возможности. И давайте снова революцию устроим?
eumorozov
22.10.2019 20:49+2Нет, спасибо, я не хочу ориентироваться на Chromium с анальными зондами Google, который хочет через него подмять под себя весь интернет, как когда-то Microsoft с IE. Спасибо, один раз уже проходили.
Неразберихи не будет, потому что WebAssembly — универсальный стандарт. Мне как пользователю все равно, на чем написана какая-то социальная сеть — главное, что ее сырцы скомпилированы в WebAssembly, который понимает мой браузер.
А как разработчику мне приятно, что я могу писать на своем любимом языке, а не на том, который мне 25 лет назад навязали без возможности выбора.
VolCh
23.10.2019 06:36Во времена IE3 выбор был же: JavaScript vs Vbscript, это не вспоминая про JScript, Java, ActiveX и Flash
eumorozov
23.10.2019 08:04Это не был выбор, т.к. во-первых, Vbscript поддерживался только IE, во-вторых, лучше уж Js, нежели Visual Basic — чур меня!
Java апплеты всегда были неуниверсальной и адски костыльной технологией (у пользователя должен был быть плагин, и каждый раз при открытии страницы с апплетом, комп замирал на несколько минут пытаясь проглотить жабу).
Flash — дырявая пропиетарщина, и там был по-моему тот же Javascript под капотом.
Настоящей свободы выбора никогда не было.
Witch-hunter
22.10.2019 14:59Вангую, что кода webassembly притрётся, все будут говорить: «Вы знаете, на PHP/Python/Rust/Java/Kotlin/C#/Haskel/Go/ELM/Scala/C++/Ruby очень удобно писать glue code, высокоуровневую бизнес-логику» и никто не будет ничего доказывать, потому как ну и так же всем ясно.
0xd34df00d
22.10.2019 16:47+3на JS очень удобно писать glue code, высокоуровневую бизнес-логику
Ну фиг знает, если бы мне надо было что-то писать под веб, то на чистый джаваскрипт я бы смотрел в последнюю очередь, наверное.
в Qt теперь QML (== жаваскрипт вид сбоку)
Свистопердящие интерфейсы на QML действительно удобно делать, чтобы анимации там, ездило всё везде, летало, переливалось. Делать мощные интерфейсы на нём сложно. Скажем, почтовый клиент или 3D-моделлер какой я бы делать на нём не стал.
QtRoS
22.10.2019 20:04Про QML — ну основное окно 3D редактора точно на C++ пришлось бы делать, а всякие обвязки и менюшки вполне можно на QML. Plasma ведь переписали на нем.
0xd34df00d
22.10.2019 20:44+1Ну, я в своём комбайне часть вещей тоже на QML переделал, типа индикатора погоды или каких-то кнопочек для быстрого запуска (чтобы они там красиво анимировались по мере наведения мышки, скажем). Всему своё применение и назначение.
franzose
23.10.2019 05:59Ну, я в своём комбайне
Вы имеете в виду LeechCraft? :)
printf
23.10.2019 00:22А TypeScript например? Вполне няшевый язык же.
Вообще это вопрос зоны комфорта, я могу запросто eumorozov из треда выше понять, про идиосинкратическое неприятие. У меня с руби такое, прямо соки говн. А к жаваскрипту привык, уже вроде и нормик.0xd34df00d
23.10.2019 04:33
eumorozov
23.10.2019 07:58А к жаваскрипту привык, уже вроде и нормик.
Просто я в веб варюсь где-то с 1998 года. И всегда, когда встречался код на Javascript, у меня волосы вставали на голове дыбом. Javascript развивался, появлялись всякие node.js/react, но каждый раз открывая файл с расширением js или html с тегом
<script>, результат чаще всего такой: «Как можно так ужасно писать?».
Потому это даже не идиосинкразия, это просто мой личный жизненный опыт научил меня всегда подозревать, что в файле .js будет что-то ужасное. Тонны копи-пейста, однобуквенные имена переменных, использование регекспов для поиска пробела в строке (или любой другой задачи связанной с обработкой строк — там где надо и где не надо), 3-4 уровня вложенных условий, и т.д. и т.п.
Javascript был создан с прицелом, чтобы на нем мог писать даже идиот. К сожалению, очень много идиотов и писало, и так часто приходилось это видеть, что возникла устойчивая ассоциация.
bodqhrohro
22.10.2019 15:04+8WA обречён быть нишевым. Ибо JS — не единственное легаси в web. HTML/CSS также преисполнены неочевидных решений, из-за того, что развивались эволюционно. И JS с их замороками отлично интегрируется — взять хоть возможность доступа к элементу по ID тупо через сверхглобальный скоуп, или хэш style с приведёнными в camelCase CSS-свойствами. А уж возможность превратить весь интерфейс приложения в RichText-редактор установкой единственного свойства contenteditable — вообще кошмар в плане учёта нюансов, с которыми приходится бодаться разработчикам браузерных движков.
Родной брат HTML — XML — в своей нише практически убит JSON'ом. Причина — он слишком «текстовый»: отступы смешаны с текстом, есть два независимых средства иерархии (атрибуты и вложенный текст/теги), извращённое экранирование. HTML, в то же время, жив, и страдает не только от этих, но и от большего количества проблем (особенно HTML5, в котором понаразрешали всякую дичь). Особая беда — возможность мешать теги с текстом, что приводит к наличию TextNode, которые не являются полноценными элементами и усложняют написание стилей и обработку событий.
CSS же — как Perl; в нём соседствуют по нескольку способов сделать одно и то же, из разных эпох: строчные/блочные элементы, абсолютное/относительное позиционирование, таблицы, float'ы, flexbox'ы, grid'ы… По отдельности они более-менее предсказуемы, но превращаются в труднопредсказуемый кошмар, если смешаны вместе. И могут серьёзно влиять на производительность рендеринга страницы из-за мелкой оплошности.
В результате имеем ситуацию, когда популярные фреймворки нахлобучивают поверх всего этого инновационные, более строгие технологии. JS уже этим «переболел», многочисленные препроцессорные языки (кроме, пожалуй, TypeScript) умерли, ибо реально стоящие инновации принимаются в стандарт языка, а Babel позволяет использовать их до достижения поддержки установленными у пользователей браузерами. В то же время препроцессоры для HTML (JSX/Pug/Polymer/etc.) и для CSS (SASS/Stylus/CSS-in-JS/etc.) живут и здравствуют.
И пути решения проблемы тут два: либо сделать новый HTML6, даже более строгий, чем XHTML, но сохраняющий всю гибкость современного web, — либо заменить нахрен весь технологический стек, и от web останется одно название (привет Skype и Nokia). Вполне возможно, что это будет сторонняя библиотека, отрисовывающая GUI, например, поверх WebGL, которую позднее включат в браузеры — как это было с LWUIT для J2ME, и как было с fetch и Promise'ами в самих же браузерах. Особенно вероятно, что такая технология «выстрелит», если она будет поддерживать создание интерфейса одновременно для VR/AR и для классических 2D-экранов — HTML/CSS для подобного не подходят вообще.
Зачатком чего-то революционного является AMP, но он слишком ограниченный. Ещё была библиотека DreemGL от Samsung, которая скорее мертва. Возможно также появление WebGL-бэкендов у уже использующихся фреймворков, по аналогии с React Native/Vue Native. Но пока web представляет собой тонну легаси, которое по сути своей не может быть высокопроизводительным и надёжным, несмотря на тонну оптимизаций в движках — замена одного лишь JS на WA ситуацию не спасёт.
nuclight
22.10.2019 16:35+1либо заменить нахрен весь технологический стек, и от web останется одно название
Ставлю на этот вариант в исторической перспективе.
(привет Skype и Nokia).
А что именно у них имеется в виду?
создание интерфейса одновременно для VR/AR и для классических 2D-экранов
Пока что такие интерфейсы не пользуются популярностью, сомнительно, что это нужно.
bodqhrohro
22.10.2019 20:49А что именно у них имеется в виду?
От них остался один лишь бренд. Современный Skype ни технически, ни даже по функциональности не имеет отношения к тому, который был до покупки Microsoft'ом — это перекрашенный MSN Live с поддержкой учёток от Skype, по сути. О Nokia и говорить нечего, все наработки мобильного подразделения (Symbian/Meego/Series 30/Series 40, шрифты, патенты и т.д.) остались у Microsoft; HMD просто паразитирует на известности бренда и продаёт совершенно не имеющие отношения к «той» Nokia мобильники на Android/KaiOS.Пока что такие интерфейсы не пользуются популярностью
Просто их время ещё не пришло. Текущие VR/AR-разработки опережают своё время, как Apple Newton и webOS. Для них пока нет достаточно распространённого высокоскоростного доступа в Интернет, да и сами очки поныне слишком громоздкие — в идеале они должны стать не более громоздкими, чем обычные, чтобы обрести массовость.nuclight
24.10.2019 20:57Просто их время ещё не пришло
Так уже не первое десятилетие говорят...
bodqhrohro
25.10.2019 00:53Велика беда. Нейронкам вон полвека понадобилось, чтобы достичь наконец широкого применения.
epishman
22.10.2019 17:21+1Все что Вы хотите — есть во Flutter/Dart :)
bodqhrohro
22.10.2019 22:00+1Dart слишком давно мёртв, чтобы вышло его зафорсить. Он появился именно как один из «препроцессоров» для JS, в этой роли не взлетел — а сейчас-то у него и подавно весомых преимуществ нет, кроме «языка для Flutter».
А в случае агрессивного форса и замены Android на Fuchsia, Google рискует повторить историю с Windows Mobile/Windows Phone. Подсуетится Samsung с Tizen, китайцы тоже чего-то замутят — и кому станет нужна операционка от гугла?
proninyaroslav
22.10.2019 22:49У гугла есть козырь: обратная совместимость. Также как сейчас можно запустить APK на хромобуках, в фуксии будет нечто аналогичное, если, конечно, она выйдет как конечный продукт. А у майкрософта такой возможности не было, перенести винмобайл приложухи без пальце-ориентированного интерфейса в WP было бы безумием. Они конечно подсуетились с выходом WP10, сделали некий конвертер приложений iOS/Android в WP, даже инстаграм сконвертировали, но как технология дерьмо, да и шанс они свой давно упустили.
bodqhrohro
23.10.2019 17:35обратная совместимость
BB OS 10 и Sailfish OS как-то не особо помогла совместимость с Android-приложениями. Мало того — Google уже ломает совместимость со старыми приложениями в Android, и будет ломать дальше. Странно полагать, что в Fuchsia с совместимостью будет хорошо.в фуксии будет нечто аналогичное, если, конечно, она выйдет как конечный продукт
Этого мало. Android в своё время убил целую кучу операционок, как смартфонных, так и фичерфонных. Причина — открытость и единые дрова, хоть и проприетарные. Проще смешивать в одном аппарате запчасти от разных производителей. Проще войти на рынок, отчего расплодилась тонна Android-ноунеймов, затмившая даже гору MTK-ноунеймов «с телевизором» в 00-х. По этой же причине проще войти на рынок операционкам, основанным на Android или совместимым с ним на низком уровне: YunOS, B2G/KaiOS, Tizen — они выпускаются в виде кастомов, иногда официально в виде дуалбута или вариантов аппарата с разными ОС, также просто в аппаратах на этих ОС переиспользуется железо, которое уже применяется в Android-мобильниках.
В Fuchsia же — полностью не совместимое ни с чем ядро. Соответственно, стоять будет лишь на гугловских девайсах (Pixel или новая линейка), и у тех полутора производителей, которые заинтересованы именно в сотрудничестве с Google и предоставлении гуглосервисов (потому что своих нет). Остальных интересует в первую очередь экосистема драйверов, и тут Fuchsia вообще не конкурент Android. Если Google бросит Android — они скорее подхватят его и общий форк сделают, или возьмут что-то другое линуксовое.
перенести винмобайл приложухи без пальце-ориентированного интерфейса в WP было бы безумием
Вполне вероятно, что ко времени выхода Fuchsia парадигма управления опять изменится.proninyaroslav
23.10.2019 17:50Google уже ломает совместимость со старыми приложениями в Android
Конкретнее? Я не замечал такого.
В Fuchsia же — полностью не совместимое ни с чем ядро
Ну и что? Для рядового девелопера ядро ничего не значит, как я уже сказал выше. Если будет совместимость с уже текущими тулчейнами и приложениями, никто и не заметит изменений. Проблема будет только с вендорами, поскольку явно придётся бекпортировать драйверы, хотя функсия уже содержит в себе стандартный набор драйверов.bodqhrohro
23.10.2019 19:50Конкретнее? Я не замечал такого.
https://developer.android.com/about/versions/marshmallow/android-6.0-changes и аналогично по другим версиям. Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.никто и не заметит изменений
Изменения неизбежны, иначе овчинка выделки не стоит. Fuchsia — не «Android с новым ядром», а принципиально новая ОС. Подобное уже было с Mac OS X: несколько релизов подержали Rosetta для старых приложений, потом выкинули.Для рядового девелопера
Проблема будет только с вендорами
Вы считаете, что девелоперы важнее вендоров? Оно отчасти так, компании подстраиваются под предложение на кадровом рынке. Вот только под что девелоперы писать будут, если Fuchsia станет маргинальщиной, как Windows Phone? Вон орава дельфистов побежала переучиваться, потому что разработка только под десктопную винду стала неактуальной.proninyaroslav
23.10.2019 20:21Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.
Не затрагивают они никого, вы заблуждаетесь. Затрагивают только если у приложения Target API равен или выше 6.0, то есть для новых версий приложений (и то если разраб захочет, или гугл повысит требования в плей маркете). Поэтому старые версии всегда и везде работают так, как и работали до этого.
Вы считаете, что девелоперы важнее вендоров?
Что у гугла, что у майкрософта сильные связи с вендорами. И в общем то WP была далеко не маргинальщиной: на старте она заинтересовала многих вендоров (ибо это сделал именитый майкрософт): htc, samsung, nokia, lg, dell, fujitsu, alcatel, zte, acer, даже prestigio выпустили девайс на WP8. А потом майкрософт допустил две стратегические ошибки: 1) сменили ядро у WP8 (было CE стало NT) и автоматом сделали невозможным обновление WP7 до WP8 2) приложения WP8 не были совместимы с WP7, это можно рассматривать как кидалово относительно новых пользователей WP, которых по сути заставили снова покупать устройства, только уже с WP8, если они хотели апдейты и новые приложения.
Ну а дальше рассказывать нет смысла, такие косяки со стороный майкрософта в новой ОС попросту не привлеки пользователей, а значит и девелоперов тоже, плюс к этому рынок был насыщен андроид-устройствами, и будучи андроид или ios разрабом, необходимо было изучать новые инструменты и языки, чтобы писать на WP, что также мало кого интересовало на фоне низкой доли на рынке. И вины вендоров тут попросу нет, ибо они изначально были заинтересованы данной ОС и выпускали свои девайсы. А перестали выпускать только лишь из-за низкой реентабельности, причины которой рассмотрены выше.
Так что решать вам, кто важнее в данной ситуации — девелопер или вендор.bodqhrohro
24.10.2019 17:49Поэтому старые версии всегда и везде работают так, как и работали до этого
Ну чтобы прямо не запускались — такого вроде нету. Но некоторую функциональность ломают. Например, статистику использования контактов. В менее печальных случаях (например, доступ к общей ФС) может понадобиться выдать приложению права через настройки.
Что у гугла, что у майкрософта сильные связи с вендорами
Были. Сейчас эти вендоры ушли на второй план. Европейские компании продали мобильные направления китайцам, из азиатских некитайцев держат планку только Samsung и худо-бедно LG/Sony.ибо это сделал именитый майкрософт
Ну только это на первых порах и спасало, дав долю рынка чуть выше плинтуса. Для того же приобрели бренд Nokia: многие покупали Lumia из-за верности бренду.и автоматом сделали невозможным обновление WP7 до WP8
Велика беда. Apple на старые айфоны бесконечно новую iOS не портирует, а если и портирует, то она заведомо начинает тормозить, стимулируя купить новый. В Android-зоопарке с обновлениями ещё печальнее. M$ на этом фоне наоборот — выглядят выгоднее, ибо исправились и обеспечили обновление с WP8 до WM10.плюс к этому рынок был насыщен андроид-устройствами
А до этого был насыщен J2ME, Symbian, WM. Чего ж разработчики-то перебежали? Ладно WM умер, но Symbian имел внушительную долю относительно Android/iOS, пока его M$ же не похоронил ради насаждения WP. А китайфоны с Java-машиной выпускаются до сих пор, несмотря на то, что Java ME уже лет пять как с точки зрения девелоперов мертва, даже Opera Mini и Gameloft'овские игры выпускать перестали. С Symbian наоборот: девелоперов-энтузиастов, пилящих софт под старые смартфоны, полно, но вендоров уже нет.proninyaroslav
24.10.2019 18:40Европейские компании продали мобильные направления китайцам
Так это было и во времена WP, сути не меняет.
Велика беда. Apple на старые айфоны бесконечно новую iOS не портирует
У майкрософта нет «магии эпл», поэтому не сработало, тем более для только что вышедшей ОС.
А до этого был насыщен J2ME, Symbian, WM. Чего ж разработчики-то перебежали?
Причин множество, для типичного девелопера/конторы в первую очередь — возможность заработать. А гугл/эпл давал новый на тот момент формат продаж — Android Market/App Store. Мог ли предложить такой формат симбиан/j2me? win mobile сделал это в 2009, но у wm корпоративная направленность, да и сам он был еле живой с падающими 10% рынка, в то время как android/ios поднимались выше и выше.bodqhrohro
24.10.2019 22:49Так это было и во времена WP, сути не меняет.
То времена другие были, гугл ещё худо-бедно держал планку «корпорации добра». А сейчас гайки закручивает, да и США торговыми санкциями грозятся.У майкрософта нет «магии эпл»
А при чём тут Apple, если у Android с обновлениями ещё хуже, но взлететь это ему не помешало?А гугл/эпл давал новый на тот момент формат продаж — Android Market/App Store
Так M$ тоже шмаркет свой открыл. У них ведь беда как раз в том, что пошли по пути Apple, сделав максимально огороженную платформу с дорогими девелоперскими учётками и единым магазином приложений с жёсткой модерацией. И как раз тут «магии» не хватило. Были б пооткрытей к сообществу — может, чего бы и выгорело.
General_Failure
25.10.2019 07:24Майки нормально шли по пути яблок, пока сами себе же не понаставили подножки, выкидывая на помойку один виндофон за другим. Пользователей и разработчиков было далеко не большинство, конечно, но и не полтора гика, гоняющихся за экзотикой.
Возможно, привыкли к успеху десктопной винды, и 5-10% рынка посчитали неудачей.
danial72
23.10.2019 08:40Он очень даже. На серверах, в мобилках, в приятном ламповом фронтенде wrike.
epishman
23.10.2019 08:57Похоже флаттер наоборот на взлёте — полная кроссплатформа — web, мобильники, собственный графический интерфейс по типу Java Swing — кто его знает как все повернется. Flutter ведь заменяет не только джаваскрипт но HTML и CSS.
bodqhrohro
23.10.2019 18:49— Ведь я умный, красивый, в меру упитанный мужчина — ну в полном расцвете сил!
— Да, но на телевидении этого добра хватает без Вас!Этих кроссплатформенных технологий уже и так валом. Qt, Haxe, Kivy, вышеупомянутые React/Vue Native, всяческие web-обёртки типа Cordova. Вот только они либо непригодны для реального использования, либо пригодны лишь чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения. Особенно на iOS, где один хрен для сборки всей этой якобы кроссплатформы нужен пайплайн из макинтошей, XCode, дорогих девелоперских учёток и верификации (для прохождения которой всё равно iOS-специфичные изменения наверняка потребуются). Особого преимущества перед тем, чтобы сразу писать нативно, нет.
transcengopher
23.10.2019 22:58+1чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения
Какая жалость, что большинство софта так и остаётся на стадии прототипа. А вон скайп вообще назад во времени переместился.
bodqhrohro
24.10.2019 21:21А вон скайп вообще назад во времени переместился.
Skype давно мёртв. После его покупки Microsoft'ом бывшие разработчики собрались и создали новый мессенджер — Wire. Microsoft же плавно, чтобы пользователи не заметили, слил Skype с собственным, изначально браузерным, мессенджером — MSN Live!
Но пользователи заметили. После того, как отключили Skype 7 — последнюю нативную версию для Windows — даже закоренелые юзеры, для которых Skype — синоним звонков через Интернет, стали плеваться от тормозной электроноподелки и подумывать о замене.
epishman
24.10.2019 10:45Это понятно, но моя мысль была в другом — flutter предлагает кардинально новый подход к пользовательскому интерфейсу — отсутствие декларативной верстки и декларативных стилей, пересоздание на лету дерева виджетов, совмещение состояния и представления — то есть stateful widget содержит в себе и данные (State) и подчинённые виджеты (View) Это интересно. Плюс BLOC — по сути stackfull стейтмашина. Голову сломать можно пока привыкнешь.
JustDont
24.10.2019 11:58+1flutter предлагает кардинально новый подход к пользовательскому интерфейсу — отсутствие декларативной верстки и декларативных стилей
Да? А мужики, писавшие в ранние нулевые интерфейсы на… да на практически всём, отличном от Delphi — и не знали, что они около 20 лет назад занимались «кардинально новым подходом к пользовательским интерфейсам».
abyrkov
22.10.2019 20:37+1либо заменить нахрен весь технологический стек, и от web останется одно название
Вероятнее всего. Уже сейчас web это не web, а легковестное и мобильное приложение.
Karl_Marx
22.10.2019 15:12Конечно, лет через пять новые фреймворки вытеснят Angular, React, Vue точно так же как они когда-то пришли на замену другим фреймворкам. Эта бесконечная чехарда и фрагментация может закончиться только еще большей фрагментацией с последующей консолидацией и переходом в проприетарную олигополию. С вероятностью 99% WASM или нечто похожее станет основой Web 3.0 где появится конкуренция не просто фреймворков, а проприетарных технологических платформ. А поскольку основные платформы принадлежат крупным вендорам, появятся новые способы монетизации, например, открываешь в 2025 газету «Ведомости», а она написана на Kotlin и требует платную подписку в Google Play, причем Chrome автоматически списывает средства с кошелька читателя.
Zet_Roy
22.10.2019 15:37Что мешает разработчикам добавить в браузер dart? В сайтах где используется js будет включатся js, а на сайтах где используется dart будет включатся dart.
radtie
22.10.2019 16:21+1Так уже было с VBScript, ну и где он?
JustDont
22.10.2019 19:28+1Так уже было с флешем.
Так уже было с сильверлайтом.
И я думаю, на этом еще таки не уймутся, и запилят что-нибудь еще, что благополучно помрёт.
Что мешает разработчикам добавить в браузер dart?
Поддержка не слишком полезных пимпочек в коде браузера имеет вполне себе выразимую в человеко-часах * зарплату в час стоимость. Кто будет оплачивать банкет? Гугл? Гуглу тоже не сдался этот ваш дарт.
Dinver
23.10.2019 10:55Dart вроде как в следующей после андройда, ОС Fuchsia собирались внедрить повсеместно. Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить. Было бы отлично иметь наличие альтернативы js.
JustDont
23.10.2019 11:10Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить.
Он компилируется в js, и в силу этого теперь уже нафиг не нужен в браузерах «прям так». А «протолкнуть как стандарт» гугл его пытался в 2015 через свой хром. Не вышло.
И единственная причина, по которой он живёт в Flutter — это как раз то, что у гугла уже есть компиляция дарта в js с одной стороны и в машинный код для андроида с другой стороны. Если это всё еще и работать будет единообразно, а не как обычно работают такие вещи — то получим очередное <...> Native, позволяющее писать одновременно на мобилки и в веб, в что гугл собственно и целится.
Но это никак не означает, что гуглу нужен именно dart. Flutter — да, dart — лишь потому, что инструментарий уже есть.
psFitz
22.10.2019 21:33+1Не надо дарт( он уродский на фоне js
danial72
23.10.2019 08:39+1В чем его уродство? Он приятный, он типизированный, у него есть настоящие классы. Для него написаны удобные api future и stream.
psFitz
23.10.2019 09:20Против js несомненно.
Но после того как пользуешься красивым ts который к тому же лишён минусов dart — сразу замечаешь кучу косяков.
Если по простому — в Гугл захотели придумать свой синтаксис на многие вещи, чего только стоит приватный метод через _danial72
23.10.2019 10:13+1Никогда не писал на ts. Можно легкий ревью косяков дарта? Просто со своей стороны я не могу этого увидеть.
psFitz
23.10.2019 10:58- Ну например читаемость, он вообще нечитаем против того же ts.
Уже давно по стандарту конструктором называют слово construct, но в dart решили вспомнить php 4 и сделали название класса. - Импорты, что мешало сделать импорты как в ts или том же php? В ts в шторме я просто пишу название класса/функции и мне сразу его подтягивает, в dart я такого не нашел, потому-что там импорты сразу всего файла или модуля и ты импортируешь сразу все, а потом пишешь код. Как require в php.
- Про боязнь разработчиков слов private и protected я писал выше
Это из тех, которые удалось вспомнить в первые пару минут, на деле, раздражающих вещей там намного больше, возможно я избалован ts, но пару месяцев назад забросил изучение flutter из-за dart.
danial72
23.10.2019 11:46Блин, все что ты описал я воспринимаю как приятные фишки. Это особенности языка и привычек уже нврн.
Ps автодополнение лучше всего работает в vs code как и другие фишки, в том числе кодогенераторы. Private и protected уже по привычке в голове на подчеркивание меняетсяpsFitz
23.10.2019 11:52Зачем мне редактор, если я хочу использовать ide?
Зачем мне перегруженный нечитабельный синтаксис c, java без их фишек?
Пописав на ts пару недель понимаешь, что dart и рядом не стоял по комфорту. Весь мир пришел к ts, если бы dart был лучше ts — его бы все использовали в вебе, а так его используют только в flutter по безысходности.beduin01
23.10.2019 11:56> Весь мир пришел к ts
Может хватит за весь мир говорить?
> Dart используют только в flutter по безысходности
Прям настоящая мука. Ага. Стонем и плачем. Вы в начале попробуйте десктопный софт написать или мобильное приложение на своем TS создать, а потом говорите.psFitz
23.10.2019 12:04-1О боже, какие обиды.
Статья про веб, забыли? В мире веба уже давно везде ts.
Зачем мне создавать десктоп, если я говорю за веб?
Да и flutter далеко не заслуга dart, просто его google гвоздями туда прибила, что-бы был "свой язык", ведь каждый нормальный пацан хочет что-бы все пользовались его языком программированияbeduin01
23.10.2019 12:27TS это просто обертка над JS. Проблем JS не решает, зато добавляет главную проблему — необходимость хорошо знать JS перед тем как писать на TS.
VolCh
23.10.2019 13:33Некоторые проблемы JS он как раз решает. Собственно почему и получил такую популярность.
impwx
23.10.2019 13:43Как раз наоборот — TS избавляет от необходимости знать тонкости JS. Вместо неочевидного поведения в рантайме сразу будет ошибка компиляции.
Free_ze
23.10.2019 13:59В реальности это разбивается о взаимодействие с JS или JSON, ибо проверки типов заканчиваются в компайлтайме. Далее отладка идет уже по правилам JS.
JustDont
23.10.2019 14:11В реальности небезопасные обращения к внешним API и отсутствие проверок целостности приходящих данных в любом языке заканчивается в дебаггере в случае любых проблем.
Free_ze
23.10.2019 14:21Ну, тот же дотнет имеет рантаймовые проверки, неправильный каст чего-то неизвестного из вражеской сборки тут же завалится с InvalidCastException, а не будет дрейфовать по приложению в виде какого-нибудь NaN, поганя данные и увеселяя отладку.
Падать при невозможности десериализовать JSON в объект конкретного типа — это тоже задача решенная.JustDont
23.10.2019 14:40Тот же JS (и TS) никак не мешает вам сделать рантаймовые проверки.
Free_ze
23.10.2019 15:10JS (и TS) никак не мешает
Но ведь и не помогает.
Могу добавить рантаймовые проверки. Могу и тестами обложить. А могу забыть, забить или сделать неправильно. Привет суровый JS-рантайм.
Прелесть TS в неявности его проверок, что они создаются и контролируются без прямого участия программиста, просто по факту использования объявленных типов. Но для поддержки развесистых типов в рантайме нужно писать дополнительный код, использовать сторонние средства.
JustDont
23.10.2019 12:10-1Вы в начале попробуйте десктопный софт написать
А ведь в комментах уже написали волшебные буквы «Electron». Пока одни ноют, что это много жрет ресурсов (и правда много) — другие просто запускают свой вебкод в том числе как десктопное приложение, и не жужжат.
или мобильное приложение
React Native (и вам не обязательно писать именно на реакте, есть вещи, которые транспайлят откуда-то еще в react native).
Вы всерьез думаете, что кроме флаттера в мире ничего нет, что ли?beduin01
23.10.2019 12:30Flutter куда проще и универсальнее всех этих Электронов и React Native.
JustDont
23.10.2019 12:55В теории.
Ваше высказывание аналогично, скажем, «Flash куда проще всех этих браузерных хаков под разные браузеры».
Более того, в определенный исторический момент это было вполне себе истинным высказыванием. Что было потом — мы все знаем.beduin01
23.10.2019 13:01То есть вы делаете ставку на JS и Электрон?
JustDont
23.10.2019 13:02+1Я не делаю ставку на очередную попытку вендор-лока, неважно от кого она исходит — от гугла ли, от MS ли, от Adobe ли.
Практика показывает, что вендор-лок для веба (да и не только для веба, на самом деле) просто вреден.
Konstantin0Scheglov
24.10.2019 17:49Честно говоря, эти недостатки выглядят как «а почему не так, как я привык?».
Автоматические импорты были сделаны, не очень давно правда, наверное с год назад. При этом show / hide import combinators не используются. Если необходимо, в IntelliJ есть Quick Assist, который добавляет show с именами символов, которые реально используются в текущей библиотеке из импортированной.
- Ну например читаемость, он вообще нечитаем против того же ts.
staticlab
23.10.2019 11:40-1у него есть настоящие классы
ООП уже давно не модно, теперь предпочитается ФП.
psFitz
23.10.2019 11:43Где предпочитается?
staticlab
23.10.2019 11:52В коммьюнити.
psFitz
23.10.2019 11:57-1Разве что разработчики реакта навязывают фп. Но никто его не использует, особенно в больших проектах. Вы видимо живете в параллельном измерении.
staticlab
23.10.2019 12:06-1Я не про отдельно взятый фронтенд говорю. Это общая тенденция. Популяризируются как чисто функциональные языки (даже здесь в комментариях упомянули Haskell и Idris), так и в существующие ООП-языки перетаскиваются элементы функционального программирования (например, Stream API в Java, pattern matching в C#). А в новых языках ФП вообще из коробки (Rust, Kotlin). За последние лет 5 появилось огромное количество статей типа "Почему вы должны перейти на функциональное программирование" и "Почему ООП не работает".
psFitz
23.10.2019 12:10+1и эти статьи ничего не описали, они взяли ООП не научились им пользоваться и обвинили ООП. Я не знаю никого, кто бы писал сложный проект на ФП, ФП в сложных проектах используется только в очень жестком хайлоад типа вк
Free_ze
23.10.2019 12:18Хайлоад и ФП разве друг друга не взаимоисключают? Стейт мутировать дешевле, чем плодить сущности под каждое изменение.
psFitz
23.10.2019 12:20-1Возможно в некоторых языках так, помню читал доводы от ВК почему они не используют ООП, там оказалось дешевле отказаться от объектов
0xd34df00d
23.10.2019 16:46+1Скомпилированный ФП-код не обязан плодить сущности под каждое изменение. Например, если компилятор вывел, что старую версию структуры данных вы не используете, то её можно мутировать инплейс. А если у вас в языке ещё есть линейные типы и соответствующие аннотации, то компилятору и выводить ничего не надо, достаточно просто проверять типы.
Free_ze
23.10.2019 16:59если компилятор вывел, что старую версию структуры данных вы не используете, то её можно мутировать инплейс
А мы разве не теряем гарантий в многопоточном окружении в этом случае? Обычно это (отсутствие разделяемой памяти между потоками) называют основным преимуществом ФП в сложных системах.0xd34df00d
23.10.2019 17:10+1А как мы их потеряем, если, ну, старая версия не используется? Ни в этом потоке, ни в следующем?
Если я напишу (очень глупую и ненужную, но иллюстративную) функцию
stupidId :: Int -> Int stupidId = go 0 where go acc 0 = acc go acc n = go (acc + 1) (n - 1)
то компилятору очевидно, что старая версия счётчика никогда не используется, и он вполне может свернуть эту рекурсию в один плотный цикл с мутируемым счётчиком.
Собственно, ghc ровно это и сделает, внутренняя функция
goсокмпилируется в
.Lc2lC: testq %rsi,%rsi je .Lc2lI decq %rsi incq %r14 jmp .Lc2lC .Lc2lI: movq %r14,%rbx jmp *(%rbp)
.Lc2lIотвечает за первый «бранч»,.Lc2lC— за второй.
Тут даже ленивость не помеха —
Intв хаскеле такой же ленивый, как и всё остальное, но компилятор может вывести, что во внутреннем «цикле» ленивость не нужна.Free_ze
23.10.2019 17:53А как мы их потеряем, если, ну, старая версия не используется?
Понял о чем вы, спасибо. Наверняка эта оптимизация возможна в большинстве случаев.
VolCh
23.10.2019 13:36+1А вы не путаете функциональное программирование с процедурным? function в PHP иногда может біть функцией в смысле ФП, но прежде всего она процедура
psFitz
23.10.2019 19:45Процедурное программирование может содержать как фп так и ооп, или нет?
VolCh
24.10.2019 13:15+1Академически процедурное программирование прямая противоположность функциональному, а ООП — его развитие. На практике в мультипарадигменных языках эти грани стираются. Например, процедура, написанная как функция позволяет применять к ней ФП подходы, причём само тело функции может как отвечать требованиям ФП, так и не отвечать, но это "Не отвечать" может быть инкапсулировано.
EvgeniiR
23.10.2019 12:34так и в существующие ООП-языки перетаскиваются элементы функционального программирования (например, Stream API в Java, pattern matching в C#). А в новых языках ФП вообще из коробки (Rust, Kotlin).
Только Stream API, pattern matching, лямбы и всё-всё-всё остальное не противоречит ООП, как не противоречит ему иммутабельность, и не противоречит само функциональное программирование ООП.
А если где-то и противоречит, то только в головах людей которые не разобрались ни с первым ни со вторым и до сих пор думают что ООП это про классы/наследование/полиморфизм подтипов или геттеро-сеттеры(наивно зовущиеся инкапсуляцией)staticlab
23.10.2019 12:44Согласен. А что дадут "настоящие классы"?
EvgeniiR
23.10.2019 13:16Согласен. А что дадут «настоящие классы»?
Так можно и без классов, например взять опеределение о том, что ООП это модель параллельных вычислений, и писать себе ООП программы на Erlang/Scala(Akka)/Actix/других решениях для Actor Model.
Но на самом деле лучше брать понятные термины с общепринятыми определениями, или обсуждать конкретные решения в конкретных контекстах, а не пытаться спорить об ООП vs ФП.
Вся мода на ООП/ФП это лишь раздувание хайпа для привлечения внимания к себе/своим проектам
Если что про ООП, actor model и другое от Кея и Армстронга — тутstaticlab
23.10.2019 13:20Однако эта ветка началась с того, что в Dart, в отличие от JS, есть "настоящие классы". Значит для автора ветки "ООП это про классы/наследование/полиморфизм подтипов"?
EvgeniiR
23.10.2019 13:23Однако эта ветка началась с того, что в Dart, в отличие от JS, есть «настоящие классы». Значит для автора ветки «ООП это про классы/наследование/полиморфизм подтипов»?
Ну, в контексте dart/js «настоящие классы» от комментатора выше я понимаю как наличие классов как языковой конструкции в более привычном виде по отношению мейнстрим-языкам вид, а я сюда влез потому что пошли попытки выставить ООП/ФП как преимущество языка.staticlab
23.10.2019 13:33К вам претензий у меня нет, а вот по поводу настоящих классов мне как раз не очень понятно. Современный JS предлагает класс как языковую конструкцию практически в том же виде, как и остальные языки. Сейчас даже приватные поля добавили. Наследование тоже есть, но нет protected. Реализовано это всё на базе прототипного подхода, который аналогичен таблицам виртуальных методов, только доступен программисту напрямую.
Ну а современное "ФП" как исключительно лямбды и т.п. действительно так же далеко от полноценного ФП (на основе теории категорий) как ООП в мейнстримных языках от ООП Алана Кея, в этом вы правы.
VolCh
23.10.2019 13:40Полноценное ФП — это как раз лямбда-исчисление. Если вы про языки типа Хаскеля, то они созданы на базе лямбда-исчисления И теории категорий. Но для ФП она не обязательна, как и сколь-нибудь строгая систем типов.
0xd34df00d
23.10.2019 16:56Если вы про языки типа Хаскеля, то они созданы на базе лямбда-исчисления И теории категорий.
Теория категорий там только является вдохновлением для иерархии классов (kek) в стандартной библиотеке (ну и одним из способов выражать effectful-вычисления).
Языки типа хаскеля созданы на базе типизированных вариантов лямбда-исчисления, и всё. Теория категорий к ядру этих языков не имеет вообще никакого отношения. Хаскель — это лямбдочки + типы, а не лямбдочки + теоркат.
Ну и есть два лагеря ФП-программистов. Одни идут, условно, от лиспа. и им нравится обычное нетипизированное лямбда-исчисление, а другие идут от ML'а и прочего ISWIM, и им типы подавай и вот это вот всё.
Witch-hunter
23.10.2019 12:37Болтовня это всё. Обычно понимание ФП ограничивается заменой for на map/reduce. Кодер, думает, что ФП — это когда функции находятся в модуле, а ООП — это когда функции в виде статических методов. Кроме того, из JS хреновый ФП-язык, нет ни карринга ни пэттерен-мэтчинга, да вообщее ничего, кроме функций первого класса. В остальных ООП языках не лучше. Попрбуйте, например, найти Dependency Injection библиотеку для С#, которая бы внедряла делегаты вместо интерфейсов по соглашению (язык ни причем, но экосистема мыслит в ООП-стиле). Поэтому, в результате, все равно приходится откатываться обратно на ООП если язык изначально не для ФП.
OCTAGRAM
23.10.2019 21:11Как там дела с поддержкой слабых ссылок, деструкторов и всего того, чего так отчаянно не хватает в JavaScript?
prostofilya
22.10.2019 16:01-2Мне интересно, а почему никто не рассматривает в контексте «убийц» такие технологии как python dash или elixir phoenix live view? Да, там внутри javascript и по-настоящему нико не собирается его убивать, но для создания dynamic rich (super mega ultra) web application с данными технологиями вам не нужен javascript, они покрывают очень много юзкейсов и с каждым днём всё больше и больше.
eumorozov
22.10.2019 17:10+1Таких технологиий очень много. Думаю, проблема в том, что в каждом проекте очень часто возникают требования: «Хочу точно такое же, но только с перламутровыми пуговицами». И как только делаешь шаг в сторону, сразу же все удобство пропадает и приходится писать адские костыли.
Lure_of_Chaos
23.10.2019 01:05+1Я, возможно, сейчас напишу ерунду и меня закидают
помидорамиминусами, но, по моему мнению, новая мода всё тащить в Веб — очень плохая.
Т.е., смотрите, у нас были десктопные приложения — сейчас всё делают на веб-технологиях, заворачивая это в Electron. Как результат — это безбожно тормозит, жрёт ресурсы, в т.ч. память (приложение с урезанным, по сравнению с дестопом, функционалом начинает весить гигабайты) Skype, uTorrent, pgAdmin и другие просто вызывают боль.
И причина этого — тяжелое эволюционное наследие: HTML, как ни крути, сильно избыточен и пересыщен фичами, друг друга перекрывающими и пытающимися исправить косяки друг друга. CSS — изобилует исторически сложившимися стандартами. JS также стонет под грузом обратной совместимости. Все 3 основные технологии, со своими костылями, со своим синтаксисом и собственным наследием не могут жить друг без друга, но в одной экосистеме не позволяют друг другу жить хорошо. Браузер как платформа вынужден поддерживать каждый исторический выкидон их развития. Как и в Java, принцип «написано один раз — работает везде» обернулся принципом "выеживаемсяпишем сразу для всех браузеров собственные хаки".
И новые фичи. Да, конечно, очень круто, что для проигрывания видео теперь не нужен Flash, нужно только написать >video< Очень круто, что у нас есть и рисовалка Canvas для рисования любой безумной хрени и для этого не надо строить хитрый DOM, поддержка OpenGL и управления звуком тоже впечатляет. Но за всё надо платить. А платим мы тем, что браузеры тяжелы, неповоротливы и прожорливы, при тяжёлой странице начинают (вынуждены?) дико тормозить.
Почему? Потому что Веб должен был остаться текстовым, но туда потащили сначала SPA-страницы, а затем полноценные приложения.
Как итог, мы имеем технологии, задавленные тяжестью собственного наследия, вынужденные работать в песочнице, ограниченной браузером, а браузер сейчас по сути является целой операционной системой… Работающей внутри еще одной операционной системы.
Ради чего? Ради того, чтобы щелкнуть на ссылку и начать работать с нужным приложением, не проходя процедуру инсталляции? Ради того, чтобы любой, купивший компьютер, мог за несколько часов сваять свое чудо-приложение? Платить каждый раз?
Нет, мой ответ. Мы идем не туда. Честно, я бы предпочел нативные приложения, весящие килобайты и работающие молниеносно. Но для этого надо избавиться от лишнего жира. От избыточности (X)HTML — к более лаконичной разметке вроде JSON или Yaml. От чудаковатового CSS к описательным стилям и раскладкам в том же синтаксисе (JSON\Yaml или какой будет разметка). От не менее странного JS к более строгим (но вместе с тем простым) императивным языкам — и пожалуйста, никакой обратной совместимости!
А еще нам нужно избавиться от браузера. Совсем. Пусть будет тонкий рантайм, который будет понимать свой байт-код, пусть это будет WASM или что-то другое, который будет контролировать разрешения приложений и не давать делать им ничего лишнего — и всё! И пусть он будет частью ОС, а не как сейчас браузер — ОС внутри ОС. Т.е. нам нужна новая ОС, которая заменит браузер, и будет более или менее стандартизирована при своей открытости, как это случилось с Linux и Android.
Революция — завершающий этап эволюции, она нам нужна. Нам нужно не убивать живущее, но нам нужно похоронить наших зомби.
Перемен требуют наши сердца! (ц)
DaneSoul
23.10.2019 01:59+1А что делать с мультиплатформенностью? Есть десктоп с Windows, MacOs, Linux, есть мобильные с Android и iOS — все это разные операционные системы, сильно разные.
Величие современного веба в том, что он работает под ними всеми, именно отсюда растут корни того, что все пытаются в него обернуть.
Вот разрабатываете Вы интернет магазин, например, и что писать нативные приложения под все платформы? Сколько это обойдется в деньгах на разработку и поддержку?
А мне, как посетителю, зачем 100500 приложений на моей десктопной или мобильной машине, если я Вашим магазином может один раз воспользуюсь, а может только прайс полистаю и откажусь от покупки?VolCh
23.10.2019 13:46Добавлю, что не просто есть разные операционные системы, а разные операционные системы разных версий. Пускай даже заявленная обратная совместимость и была бы чистой правдой, но хочется (рынку), чтоб современные фичи ОС приложениями использовались. А это значит что для каждой ОС надо поддерживать минимум несколько версий приложений. Не важно явно, или через проверку доступности фичи в рантайме и переходу к какому-то фоллбэку, если недоступна.
Lure_of_Chaos
24.10.2019 18:33На это я писал:
Т.е. нам нужна новая ОС, которая заменит браузер, и будет более или менее стандартизирована при своей открытости, как это случилось с Linux и Android.
Т.е. нам надо, чтобы Веб был частью ОС, но не в том виде, в котором сейчас — с глубоким стеком не очень подходящих технологий. Т.е. эти технологии были хороши для Веба 1.0, но поскольку он развился и стал действительно сложным — нужно не бесконечно усложнять инструменты, дублируя их функциональность, а интегрировать их друг с другом.DaneSoul
24.10.2019 19:11Т.е. нам надо, чтобы Веб был частью ОС
Не должен быть Веб частью ОС, точно также как не должен быть частью ОС офисный пакет и т.п. прикладные самостоятельные вещи.
Веб должен обрабатываться специализированной программой — браузером, как и сейчас. Проблема не в том, что между ОС и Вебом есть посредник в виде браузера.
но не в том виде, в котором сейчас — с глубоким стеком не очень подходящих технологий. Т.е. эти технологии были хороши для Веба 1.0, но поскольку он развился и стал действительно сложным — нужно не бесконечно усложнять инструменты, дублируя их функциональность, а интегрировать их друг с другом.
А вот с этим соглашусь — современные Веб-стандарты это действительно адская каша из HTML, CSS, JavaScript с кучей легаси, поверх которых еще сидит куча фреймворков, сборщиков и т.п. Вот заменить все это единой стройной интегрированной технологией было бы просто замечательно.
Но для этого должны прежде всего договорится о едином подходе крупные Веб-разработчики, такие как Facebook, Google, Amazon и т.п. и разработчики браузеров — Google, Apple и Mozilla.
megahertz
23.10.2019 05:20JS также стонет под грузом обратной совместимости
Мне кажется вы преувеличиваете.
Lure_of_Chaos
24.10.2019 18:34А об этом в статье. Иначе не было бы криков на протяжении десятков лет, что JS плох.
0xd34df00d
23.10.2019 07:09От избыточности (X)HTML — к более лаконичной разметке вроде JSON или Yaml.
Ну вот yaml тут зря.
Lure_of_Chaos
24.10.2019 18:37Я приплел его сюда только за его лаконичность, чем-то напоминающий питоновскую философию.
Я бы HTML был бы доволен видеть хотя бы таким:
html {
body {
div {
a(«link») {
target = blank
«Main site»
}
}
}
ApeCoder
23.10.2019 10:23Платить каждый раз?
По факту все выбирают платить и поддерживать совместимость. Если ваш подход даст мегапреимущество, это всех завоюет. Но он не дает. Рантаймы и нативные приложения есть и известны, он не вытесняют веб
Lure_of_Chaos
24.10.2019 18:39Совместимость и есть корень всех зол. Если будет хорошая альтернатива, то за какие-нибудь ещ 10 лет она может сменить современный Веб.
JustDont
23.10.2019 10:23+1Честно, я бы предпочел нативные приложения, весящие килобайты и работающие молниеносно.
Вам кто-то С отменил? Пишите. Только не обижайтесь, что пока вы напишете килобайтное и работающее молниеносно приложение (и скомпилируете его везде, куда вам надо) — вы обнаружите, что рынок уже давненько поделен.Lure_of_Chaos
24.10.2019 18:41Мне — нет. Но меня огорчает тенденция всех приложений переписываться под Веб… Мы ведь для этого увеличивали терабайты и гигагерцы? Чтобы иметь то же, что и 20 лет назад, но медленнее и требовательнее?
JustDont
24.10.2019 19:03Чтоб иметь то же, что и 20 лет назад, но разрабатываемое и модифицируемое в течении недель, а не лет.
dagen
23.10.2019 11:28Т.е., смотрите, у нас были десктопные приложения — сейчас всё делают на веб-технологиях, заворачивая это в Electron.
Упущен один очень важный момент. Это просто дешевле и быстрее. Вы думаете, что Facebook и ВК были рады корявиться со своим php? Нет, у них не было выбора. Так что весь ваш пост — это возмущение насчёт того, что вода течёт вниз.
staticlab
23.10.2019 11:43А еще нам нужно избавиться от браузера.
Вот все вы мамкины революционеры такие. Нам нужно, но пусть это делает кто-то другой. Что лично вы сделали для приближения этой революции? Вы уже спроектировали и написали этот самый тонкий рантайм вокруг WASM?
Lure_of_Chaos
24.10.2019 18:45Я обожаю аргументы в стиле «сперва добейся».
Но извините, я не могу за эту короткую жизнь изучить всё и написать всё.
Я пробовал писать фреймворки, библиотеки и т.д. И выкидывал их, когда обнаруживал, что почти одновременно или раньше появлялись аналогичные, и выкидывал свои наработки.
franzose
23.10.2019 13:57А платим мы тем, что браузеры тяжелы, неповоротливы и прожорливы, при тяжёлой странице начинают (вынуждены?) дико тормозить. Почему? Потому что Веб должен был остаться текстовым, но туда потащили сначала SPA-страницы, а затем полноценные приложения.
Нет, не должен был. Эволюция закономерна. Вот то, что эти новомодные фичи используются без ума — это да. Ну так...
Lure_of_Chaos
24.10.2019 18:49Пусть бы простые технологии служили для простых целей, но когда мы начинаем делать что-то совсем другое, то логично и инструменты выбрать другие, а не напичкать стероидами те же.
Sayonji
23.10.2019 06:10На js плохие проги не из-за js, а потому что он для веба. Если бы сайтописцам надо было кодить на хаскеле, они бы говнокодили на хаскеле, и все бы говорили: хаскель такой плохой язык, я на нём много плохих программ видел.
Динамическая типизация же необходима: если у вас серьезный проект, вы можете выбрать язык по вкусу и настроить транспилятор при сборке. А большинство проектов несерьёзные — и в них никому не интересно типизировать json-подобные структуры.0xd34df00d
23.10.2019 07:11А большинство проектов несерьёзные — и в них никому не интересно типизировать json-подобные структуры.
А как вы с ними работаете тогда? Вот когда вы пишете
json["foo"], что вы имеете в виду?
Ведь вы, скорее всего, ожидаете, что по этому ключу будет какое-то значение. Вы, вероятно, ожидаете, что оно будет числовое (или строковое, или ещё какое-то). Так почему бы эти ожидания не зафиксировать в коде явно?
Я всё типизирую на таком (пусть и очень базовом) уровне даже в одноразовой парсилке логов. Помогает в разработке.
printf
23.10.2019 11:50А как вы с ними работаете тогда? Вот когда вы пишете json[«foo»], что вы имеете в виду?
Как бог на душу положит, в самом-то деле. У большинства сайтов ведь практическая функция — отображать на экране текст с картинками, не более. Нет поля в объекте — выведется на сайте пустая строка, или там undefined, всего делов.
Мне из Алиэкспресса каждая вторая посылка приходит с надписью Phone number: +972undefined почему-то. Это, конечно, баг. С другой стороны, покупатель доволен. Продавец доволен. Джек Ма доволен. У этой истории нет морали.
Witch-hunter
23.10.2019 13:04Мне из Алиэкспресса каждая вторая посылка приходит с надписью Phone number: +972undefined почему-то. Это, конечно, баг. С другой стороны, покупатель доволен. Продавец доволен. Джек Ма доволен. У этой истории нет морали.
Хм… я вот подумал, а что будет, если Вам придет письмо с текстом: «Уважаемый undefined, Вам отправлена посылка undefined по адресу undefined»?printf
23.10.2019 14:04Письмо, наверное, придет владельцу ящика undefined@gmail.com :)
В этом случае магазин заработает NaN денег, и тикет в баг-трекере тотчас же засияет новыми красками, и эту штуку быстро-быстро починят.
То, что критично для бизнеса, будут писать на строго типизированных языках, и применять JSON Schema, и всякое дефенсивное программирование, и QuickCheck, и фаззинг, и аудит кода проводить.
А где некритично (т.е. остальные 99% кода) — и так сойдет.
(Всё это, конечно, не относится к хобби-проектам.)
bodqhrohro
23.10.2019 23:03с надписью Phone number: +972undefined почему-то. Это, конечно, баг
Ой ли? Может, просто маска такая. Задачу скрыть номер ведь выполняет, девелоперы просто бахнули что-то вида
if (print_on_posylka) delete nomer.main;— и та-а-ак сойдёт, тикет закрыт за 0.3 c, менеджер доволен. А намудрили бы чего-то сложнее — был бы оверинжиниринг.
VolCh
23.10.2019 14:01В голове типизируем JSON в большинстве случаев, хоть на бэке, хоть на фронте, хоть на JS, хоть на TS, хоть на JS. Есть JSON Schema в теории, но на практике пока формальные проверки на соответствие ей не встроены в язык или хотя бы во флоу разработки, то их дорого выходит поддерживать, чтобы на их основе писать полноценные тайп-гварды.
0xd34df00d
23.10.2019 17:33+1Ну так а почему бы не записать это содержимое головы в исходный код?
VolCh
24.10.2019 13:21Потому что не встроено в язык, формально может и можно сделать это исходным кодом, типа вместо json или yaml использовать JS для описания схем, но это ма-а-аленькая деталь реализации.
psFitz
24.10.2019 12:54Динамическая типизация же необходима: если у вас серьезный проект, вы можете выбрать язык по вкусу и настроить транспилятор при сборке. А большинство проектов несерьёзные — и в них никому не интересно типизировать json-подобные структуры.
Ну не знаю, пописав на ts пол года я теперь даже на проектик в 500 строк возьму ts, а не js, так быстрее, проще, удобнее
VolCh
24.10.2019 13:24TS взять — это одно, а вот обмен с сервером писать так, чтобы приложение падало из-за того, что JSON ответ не проходит честный тайпгвард, который заметил, что id пришёл не числом, а строкой — совсем другое. Вы пишите такие тайп-гварды?
0xd34df00d
24.10.2019 17:19Я — да. Может, они семантику ID поменяли, и теперь там гуид, и парсить в число его глупо или опасно?
Pavenci
23.10.2019 07:56Как только в мире появится технология (язык, фреймворк, что угодно), что позволит одновременно: писать 100% кроссплатформенный код для android,ios,harmonyOS,fuchsia, windows,linux,mac e.t.c., создавать достойный интерфейс либо нативный для каждой платформы либо собственный, иметь низкий порог вхождения и удобный комфортный синтаксис, то эта технология тут же станет самой популярной и все на неё перейдут.
Сейчас такой технологией является web со всеми плюсами и минусами. Кто бы что ни говорил, а мы живем в реальном мире, где никому не хочется реализовывать своё приложение три года, писать на 5 языках, мучиться с кривым GUI чтобы создать удобный и привлекательный дизайн и ещё разбираться в кучи нюансах, о которых уже позаботились разработчики того же браузера. Я тоже очень хочу и жду когда наконец мы сможем писать просплатформенно, быстро, красиво, чисто и без головной боли, да еще чтобы и весило всё в килобайтах, но пока этот день не настал.
Есть же в этом всём нечто прекрасное, чего раньше нельзя было представить: каждый человек способен написать собственное приложение в кратчайшие сроки, работая всего с одним языком и одной средой исполнения. Пусть это приложение будет не без недостатков, но кто вас заставляет его использовать (я сейчас про скайп)? Лично я не представляю свою жизнь без этих приложений: Trello, Postman, Slack, Vscode, Discord, Figma, Avocode. И все они на electron и работают прекрасно, намного упрощают и улучшают мои рабочие процессы)Lure_of_Chaos
24.10.2019 18:54Хм. А не возможно ли оставить плюсы, такие как скорость разработки, легкость сопровождения и кроссплатформенность, и при этом избавиться от минусов в виде требовательности к ресурсам и тормозам в рантайме?
Возможно, кроссплатформенность и есть тот самый неверный критерий, и возможно, нам требуется некий общий знаменатель, т.е. стандарт, который позволит выкинуть побольше хаков для истинной кроссплатформенности.
General_Failure
23.10.2019 08:29Мне интересно — как отреагирует эппл, если вебасм взлетит и станет популярным?
Ведь сейчас у них на телефонах выполняется только то, что одобрено самим эпплом, в том числе и в вебе (все айфонные браузеры — надстройки над сафари)megahertz
23.10.2019 11:11Никак не отреагирует. WASM в iOS Safari поддерживается, доступа к чему-либо за пределом API веб-приложения WASM не дает.
RPG18
23.10.2019 11:39В iOS 13 в вебките был баг WebAssembly BBQ should switch compile mode for size of modules, который ломает реальные проекты. К сожалению до 13.1.3 фикс так и не дошел. workaround загружать asm.js если он есть. Всё бы ничего, только Apple не в первый раз так ломает wasm.
moroz69off
23.10.2019 10:55Очень мило.
Так что же мы всё таки делаем?
Меняем тег
на<marquee>evolution</marquee>
cirCus.Tent(new Revolution(true));,
или не будем?
На самом деле было интересно узнать, что решение моих проблем всё же есть. Огромное количество данных (текстовые файлы csv, более 2 гигов самый маленький), чехарда C# Python, ну и javascript, разумеется, в одном проекте. Так что wasm, мне лично, юзать уже хочется, наверное.Lure_of_Chaos
24.10.2019 18:59Я вижу в WASM намек на правильное направление, а именно — универсальную виртуальную машину, которая позволяет писать хоть на Ассемблере, хоть на Си, хоть на Брейфаке, при этом предлагая хорошую скорость.
Я все-таки хотел бы видеть дальнейшее развитие — что-то вроде WASM, но не в браузере, а в ОС. Но, тогда, конечно, это будет совсем иное, нежели WASM. Даже не предполагаю, какое именно.
bouncycastle
23.10.2019 10:55-1JavaScript от нас скорее всего не уйдет. Google пытались Dart пропихнуть но даже у них не получилось.
Lure_of_Chaos
24.10.2019 19:02Почему «даже». Увы, но у многих языков и технологий, очень даже неплохих, не получается.
Вот пример (немного спорный) На замену C был предложен D, который был намного проще, но, без массовой поддержки так и остался в своей маленькой нише с прочей эзотерикой.
beduin01
23.10.2019 11:08+1Про тонны легаси на JS смешно слышать. Ребята, вы реально верите, что проекты написанные сегодня сохранятся через 7-8 лет в первозданном виде? Да за это время половину помрет, а вторая половина будет переписана и не один раз. Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
JS крайне сложен и запутан. Чего стоит только this и разные приколы типа [] + [] + true. Dart несоизмеримо проще.JustDont
23.10.2019 11:18-2Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
Вы не верите, а я с этим работаю. Но вы и дальше можете не верить.
Кода для веб, прожившего больше 5 лет — море. Прожившего больше 10 лет — тоже очень порядочно.
JS крайне сложен и запутан. Чего стоит только this и разные приколы типа [] + [] + true.
Вы измеряете сложность языка количеством способов отстрелить себе ногу?
А не стрелять — пробовали?
justboris
23.10.2019 13:15Нужно быть очень большим оптимистом, чтобы верить, что какой-то код проживет дольше чем 5 лет.
Примеры:
- Gmail – редизайн ему сделали, а внутри все то же легаси. Подробный анализ был вот тут.
- https://craigslist.org довольно известный своим консервативным дизайном сайт
- https://www.wetteronline.de/ – этот сайт известен тем, что из-за него не получилось добавить в стандарт Array.prototype.flatten, потому что это ломало легаси-библиотеку MooTools, используемую на этом сайте
И это только публичные примеры. Как и JustDont, я периодически сталкиваюсь с легаси в своей работе, вроде кода на jQuery 1.7, требующего обновления.
Timuch
23.10.2019 11:23Насчёт вытеснить — врядли.
Скорее всего WebAssembly возьмёт на себя высокопроизводительную часть приложения.staticlab
23.10.2019 11:48Главное, чтобы накладные расходы от интеропа с Web API через JS не были больше, чем у приложения на чистом JS. А то сейчас WASM если и внедряют, то для реально тяжёлых задач типа графических движков, обработки графики или звука на клиенте, а с ростом популярности начнут применять для достаточно примитивной логики вида "По нажатию кнопки загрузить данные с сервера и показать на экране".
x8core
23.10.2019 13:24Забавно, как люди пытаются бороться с намеренными особенностями языка, создавая даже другие языки, которые конвертируются в Javascript.
EvgeniiR
23.10.2019 13:26Забавно, как люди пытаются бороться с намеренными особенностями языка, создавая даже другие языки, которые конвертируются в Javascript.
Ну так причина же в том что выбора особо не было долгое время, да и сейчас нету, браузеры хотят JS, намеренные особенности или не намеренные не играет роли если они для кого-то являются недостатками
VolCh
23.10.2019 14:08Некоторые "намеренные особенности" создавались совсем не для тех целей, в которых сейчас используется JS. А альтернативы по сути нет, кроме как пытаться спрятать эти особенности под капотом другого языка
Lure_of_Chaos
24.10.2019 19:09Намеренная особенность языка была — сделать очень простой язык, с простой философией, чтобы на нём создавать простые скрипты.
Но для сложных приложений эти особенности начинают мешать. Появляется потребность в фичах более сложных языков, которых в JSнеточень долго не было.
IgorPie
23.10.2019 15:19Лет 10 назад каждый день писали про падение доллара, что вот-вот и все, лет 5 назад мы каждый день читали про «убийц» ipad, теперь про «убийц» js.
Мир попробует перейти на webassembly, если кто из гигантов на него перейдет, что вряд ли.Witch-hunter
23.10.2019 16:15Microsoft обещают Blazor WebAssembly в мае 2020
justboris
23.10.2019 17:37Blazor на WebAssembly – очень спорная штука. Если в случае с JS в браузер тащат только left-pad и другие мелкие недостающие функции, то с случае с Blazor туда потянут полноценную VM со своей реализацией строк, классов и т.д. На скорости загрузки это скажется соотвествующе.
Поэтому Blazor кажется полезным только в очень специфических ситуациях – много тысяч строк кода на C#, и в команде совсем никто не хочет/не может в JS.
Lure_of_Chaos
24.10.2019 19:10Хоронили тёщу — порвали два баяна (ц)
Заголовок (да и общий тон) статьи намеренно чересчур претенциозен.
Nikolai46
23.10.2019 18:59Большая проблема существующего порядка вещей, это то что не существует механизма гарантированной смерти.
Т.е. всё что пишется, тащится и хранится в вебе, может прожить очень долго.
С одной стороны это хорошо, с другой не очень.
Может настанут времена когда браузер, по аналогии с SSL, начнёт отвергать на исполнение сначала неподписанные js файлы, а с этим придёт expiration date в сертификатах.
Вот тогда, будет реальная возможность эволюционировать.Lure_of_Chaos
24.10.2019 19:12А потом мы получим вместо открытого интерпретируемого js компилируемый байт-код… Oh wai~…
OCTAGRAM
23.10.2019 21:57+1JavaScript сейчас берёт на себя груз обеспечения совместимости между версиями. То есть, можно написать if (нечто.ИмяМетода), и так просто и понятно проверить, а есть ли он, этот метод (какова версия реализации). И, соответственно, поработать с той или иной версией реализации. Наследование если на JavaScript делать, наследованные методы автодобавляются в унаследованные экземпляры, и тогда потомкам не обязательно знать, что у них что-то добавилось. Ну, правда, если имена совпали, тогда ой.
А вот если обратиться к нативу, как в WASM, то старые проблемы всплывают вновь. Ими активно занимались все 1990е, а потом вроде как их решила Java. В C++ 98 не вошло ничего из IBM Direct To SOM, Sun OBI, SGI Delta/C++. А когда ближе к концу 2000х, обломав зубы на чисто-Java-браузере HotJar и прочей чисто-джавовости, которые получились как-то не очень, в отличие от Apple CyberDog на SOM и OpenDoc, начали понимать, что Java — это не всё, это вылилось в обновление C++ 2009, но от наработок 1990х там всё так же ни следа. Только в Objective-C сохранились наработки 1990х, и даже были чуть улучшены в 2006м, там это назвали nonfragile ivars.
И вот теперь, получив в руки инструмент WASM, мы осознаём, что всё на том же перекрёстке. Мы так и не пережили 90е. Нам в нативе нужен инструмент сопряжения изменчивых компонент, а его нет. Значит, в роли такого придётся, чтоб был JavaScript. Нам постоянно придётся в него выходить, потому что в WASM решать свои проблемы не умеем. Либо какая-то ВМ заменит шило на мыло. Вместо фигового JS будет очередная фиговая ВМ.
Просто попробуйте начать активно использовать разделяемые библиотеки в EmScripten. Да там даже интерфейсы по типу COM нагородить между независимо собранными wasm — победа. До наследования без проблемы хрупкого базового класса как до Луны пешком. Всё реальное применение WASM скатывается к здоровенным статически собранным блобам, обновляемым как единое целое. Хотя, учитывая, как без фундаментальной научной работы такие проблемы в прошлом решались разрозненными участниками рынка, заинтересованными только в повышении наших на них расходов, но не в улучшении ситуации в целом, мы и впрямь можем дожить до того, чтоб глянуть один твит, нужно будет загрузить 65Мб WASM, ведь тот, что в кеше, успел протухнуть.
CheY
23.10.2019 22:05У меня есть небольшой оптимизм на счёт замены JS чем-то более приятным за счёт доминирования Chrome/Chromium-based. То есть если гугл сильно захочет, и вложится в свой Dart (как пример — я не агитирую за него) по полной, то это будет уже бОльшая часть рынка — миллиарды устройств. После этого останется дождаться падения «стены» на стороне Safari, и тогда все остальные будут вынуждены адаптироваться. То есть в какой-то мере браузерный монополизм может сыграть положительную роль в том, чтобы освежиться и отбросить легаси в виде не самого приятного языка.
i360u
24.10.2019 09:48JS и WASM — это две технологии, которые помогают друг-другу, а не пытаются друг-друга убить. По моему, у аудитории обнаруживается фудоментальное непонимание того, зачем нужен WASM, и почему он не может заменить JS: просто подумайте почему в WASM нет доступа к DOM, неужели просто потому, что было сложно пробросить интерфейс? Нет, все дело в безопасности.
Cerberuser
24.10.2019 10:14Можете пояснить, что (недопустимое с т.з. безопасности) сможет сделать WASM при прямом доступе к DOM, чего не может JS?
i360u
24.10.2019 10:26Если коротко — то DOM — это, кроме прочего, и те самые пользовательские поля ввода паролей и иных конфиденциальных данных. JS — это скриптовой код, ход исполнения которого, можно полностью контролировать в рантайме, блокируя любую нежелательную активность. С высокопроизводительным скомпилированным кодом так не получится, поэтому нужна прослойка. Помимо этого, узким местом в воронке производительности веб-приложения, часто являются сложные вычисления при отрисовке DOM, и вся эта логика работает не на JS, поэтому замена JS на что-то более производительное ситуацию никак не изменит.
psFitz
24.10.2019 10:44Спасибо, я думал к DOM там доступ есть, обычно затраты идут на отрисовку и отслеживание изменений, а расчеты очень редко затратные, тем более расчеты можно вынести в воркер.
RPG18
Сейчас с WebAssembly есть риск, что обновление версии браузера может сломать работу приложения. Из недавнего обновление Safari до 13.