Кто он — убийца JavaScript?

Автор оригинала: Matthew MacDonald
  • Перевод
Некоторые языки программирования — это языки, которые любят разработчики. Некоторые языки программирования лишь терпят. Для многих программистов JavaScript попадает в последнюю категорию, являясь языком, который нужно понимать каждому, кто пишет клиентские части веб-проектов, но таким, который никто не обязан любить.

Десять лет назад очевидно было то, что 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?


RUVDS.com
1 472,31
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Похожие публикации

Комментарии 285

    +2

    Сейчас с WebAssembly есть риск, что обновление версии браузера может сломать работу приложения. Из недавнего обновление Safari до 13.

      +3
      Как по мне javascript (ровно как и react) уже набрал свою критическую массу и сдвинуть его будет ой как тяжело.

      И я бы не говорил что WebAssembly это убийца, скорей шанс для TC39 увидеть что-то интересное
        0
        Любое тяжелое легаси непросто забыть, если оно еще нужно)
          +4
          Последние годы Javascript перенял много фич, которые первоначально появились в Typescript (OOП модель, асинхронные обёртки типа promises и async/await, и многое другое), да и вообще начал быстро развиваться в конструктивном направлении. Вот если когда-нибудь он переймет и основную фичу Typescript — статическую типизацию, то сдвинуть его каким-либо другим языком будет практически нереально.
            0

            Согласен
            Но JavaScript перенимает очень медленно, что на типы и не приходится надеятся.
            К примеру только сейчас появляется Optional Chaining, который был в CoffeeScript уже больше 5 лет назад

              –9
              А можно на пальцах? Вот чем динамическая типизация хуже статической? Просто это всё как мантра из поста в пост передаётся.
                +17

                Тем, что статическая типизация позволяет узнать, что ваша программа не делает ерунду1 до запуска вашей программы, а динамическая — нет.


                1 Для некоторого определения ерунды, которое будет различным для С, хаскеля и идриса, например.

                  –10
                  Что одновременно сразу резко повышает трудозатраты на разработку. JS ведь стал таким популярным не потому что он так хорош, а что это некий вменяемый компромисс между порогом вхождения в разработку и качеством продукта.
                  Статическая типизация — это же никакая не панацея.
                    +10
                    Что одновременно сразу резко повышает трудозатраты на разработку.

                    Не обязательно.


                    Почему-то я, знающий статически типизированный хаскель, опережаю коллег, знающих питон.
                    То есть, конечно, время до первого запуска (пусть и заканчивающегося трейсбеком) у них меньше, но время до корректных результатов почему-то меньше у меня.


                    Статическая типизация — это же никакая не панацея.

                    Это тоже зависит от типизации.


                    Просто, ну, не надо о статической типизации судить по языкам типа C++ или Java.

                      +1

                      Как и не надо говорить о статичнской типизации как о строгой и мощной системе типов по умолчанию.

                        +1

                        Безусловно. Поэтому я стараюсь уточнять.

                        0
                        Погодь — так разве Java не язык с строгой статической типизацией?

                        А в С++ напротив типизация динамическая — привет "*_cast<>" — ам
                          0
                          Погодь — так разве Java не язык с строгой статической типизацией?

                          Она действительно статическая и действительно достаточно строгая. Но она не является выразительной, и она довольно тяжеловесна.


                          А в С++ напротив типизация динамическая — привет "*_cast<>" — ам

                          Лол, как будто в джаве кастов нет. И в джаве в рантайме о типах известно поболе, чем в C++.


                          В языках с динамической типизацией касты (в плюсовом стиле), кстати, не нужны.

                            0
                            Не, я про приведение типов в Джаве в курсе, как бы.
                            Другой вопрос, что Джава, емнип, привести класс Person к классу Plane не позволит — классы должны наследоваться. В С++ же с помощью явного приведения можно привести что угодно к чему угодно. Я уж молчу про константы, которые не константы…
                              0
                              Другой вопрос, что Джава, емнип, привести класс 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);, то снова всё станет в порядке.

                        0
                        JS стал таким популярным, потому что его поддержали браузеры без дополнительных плугинов.
                          0

                          Потому что он изначально создавался как часть браузера Netscape тогда уж. А "поддержали" значит "Microsoft создала свой очень похожий и почти совместимій язык JScipt как часть своего браузера".

                          +1
                          JS ведь стал таким популярным не потому что он так хорош, а что

                          … был и остаётся монополистом.

                        +2
                        Чтобы ловить ошибки при компиляции, а не в рантайме, нужна статическая типизация. Да и код интуитивно понятнее будет с типами.
                          0
                          Вот здесь вроде ребята на своем опыте хорошо разложили.
                          habr.com/ru/company/ruvds/blog/468233
                            –1
                            Чтобы когда в проекте из сотен js-файлов наводишь на функцию в своей любимой IDE'шке, и она сразу показывает, что в эту функцию передается.
                              0
                              Современные IDE поддерживают JSDoc формат описаний, в которые можно добавить типы image
                                +1
                                Есть нюанс: адепы отсутствия типизации не будут писать эти громозкие комменты, так как это противоречит их идеологии, а адептам строгой типипизации типы в комментах не нужны.
                            +1
                            Я думал, JS из ActionScript'а тащит фичи. Век живи, век учись…
                              +5
                              Все то что вы перечислили что JS перенял из TS-а это не правда, классы были во времена ES4 (2000-2008), промисы предложили для стандарта ES6 в 2012 когда TS только появился на свет, до этого еще в 2011 были deffered objects в jQuery, async/await взят из C#. TypeScript еще никак не повлиял на развитие синтаксиса JavaScript или на другие части языка, да, он дополняет JavaScript своими типами, областью видимости, интерфейсами, enum-ами, и так далее, но пока что ничего из того что TypeScript предоставляет не было добавлено в стандарт EcmaScript.
                                0
                                Когда промисы приняли в JS, это было в версии ES6, то есть 2015 год, в TS они уже 3 года как работали, и синтаксис был такой же. Да, async/await взят из C#, но создатель C# и создатель Typescript — это один и тот же человек, Андерс Хайльсберг. То есть, получается, С# имеет влияние на TS, а TS в свою очередь на JS.
                                  +2

                                  Тут надо смотреть не когда приняли, а когда начали реализовывать хотя бы в виде предложений. Если, условно, в релиз TS попало что-то что в ES в stage 3 находится, но предложение в TS появилось только после перехода в stage 3, то тут сложно говорить, что TS повлиял на ES

                                +1
                                ООП в JS было с самого начала. Не было именно синтаксиса class, но это уже на вкус и цвет. Мне, к примеру, обычный синтаксис нравится немного больше, чем class.
                                  0

                                  В JS с самого начала была прототипная модель. То, что с помощью синтаксического сахара в виде классов воспроизвели классическое ООП, это другое дело.

                              +4
                              Я не верю в полноценное убийство жаваскрипта вебассемблей просто потому, что на JS очень удобно писать glue code, высокоуровневую бизнес-логику. То, что сейчас происходит (ну, начинает происходить) — «тяжелые» библиотеки переползают на WebAssembly (см. например libsodium), высокоуровневый код остается на JS, и все более-менее счастливы.

                              Многие проекты выработали аналогичную структуру, двигаясь в обратном направлении: начали с «библиотечного» С++, а затем прикрутили сверху скриптовый язык для glue code. В World of Warcraft для скриптинга выбрали Lua, в Qt теперь QML (== жаваскрипт вид сбоку), и так далее.
                                –2

                                QML ни разу не легковесный. Разработчикам Qt пришлось писать AOT и JIT компиляторы.

                                  +1
                                  Но удобный != легковесный. (Ну т.е. легкость использования != простота имплементации.)

                                  Алсо есть же LuaJIT например.
                                    –3

                                    А LuaJIT не заведется на iOS.

                                      +1
                                      Ну и что? QML JIT тоже, только это ведь не относится к предмету дискуссии никоим образом.
                                        0

                                        AOT != JIT. И на iOS он не JIT. QML никогда не позиционировался как язык, для glue code, потому что это декларативный язык разметки нацеленный на UI.

                                    –1
                                    А QJSEngine разве не v8 использует?
                                      0

                                      Нет. Они v8 использовали во время бета версии Qt5, но это не переносимо.

                                      0

                                      Сначала использовал, а потом оказалось, что проще написать свой рантайм, чем постоянно переключаться между Qt и V8. В итоге новый QV4 работает и быстрее в задачах фреймворка, и много боли ушло.

                                    +3

                                    Терзают смутные сомнения. Еще задолго до появления node.js/npm/React и т.п., очень часто можно было услышать мнение, что JS — плохой язык. Сам автор языка изначально хотел другой язык в браузере. Были попытки реализовать другие языки в браузерах, все неуспешные, так как браузеров много, часть с закрытыми исходниками, особенно ранее. Если язык не появится во всех браузерах одновременно, то и пользы никакой от альтернативного языка в браузере нет — никто не станет на нем писать, чтобы отрезать часть пользователей с другими пользователями.


                                    Есть сотни языков лучше Javascript, но в его среде они до сих пор не могли с ним тягаться просто потому что им был закрыт доступ в эту среду по определению.


                                    И вот ситуация наконец начала потихоньку меняться. Лично мне кажется, что будет только к лучшему, если наконец какая-то технология заменит Javascript. У меня какое-то идиосинкратическое неприятие к нему.


                                    А низкий порог входа, увы, означает тонны плохого кода. Javascript, по-моему, относится к категории языков на которых хорошо писать можно, но сам язык и окружение скорее побуждают писать плохо.

                                      +2
                                      ИМХО язык никого не может в принципе побуждать писать плохой код. Лично лицезрел приложение на Java, втиснутое в один класс и в цикле, загружающее рекламу и расписание показа с удаленного сервера и показывающее эту самую рекламу. Кода было экранов на пять. Не язык программирования красит разработчика ;)
                                        +3

                                        Я написал другое: есть языки, которые в принципе не препятствуют написанию плохого кода, даже способствуют. И считаю, что Javascript — такой язык. Плохой код написать на нем проще, чем хороший. Это не значит, что хороший написать нельзя. Это значит, что с плохим придется сталкиваться чаще.

                                          +2
                                          1) Говнокод можно написать на любом языке.
                                          2) Количество ограничений языка обратно пропорционально developer experience (DX) и скорости разработки. Чем менее удобен язык, тем меньше на нём будут писать.
                                          3) Качество кода, как ни крути, определяется прокладкой между стулом и монитором. Многие не удосужились выучить базовые правила и наработки, но идут всё туда же, критиковать язык.
                                          4) Есть два типа языков: те, которые ругают, и те, которыми никто не пользуется.
                                            –1
                                            1. Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается. И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.
                                            2. Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы, и когда вам на каждый чих нужно лезть в документацию на гитхабе (которая может быть неполной, неактуальной или вообще отсутствовать).
                                            3. См. пункт 1.
                                            4. Если работаешь с вебом — избежать работы с джиесом, увы, невозможно.
                                              0
                                              И дело не в криворуких программистах, а именно в концепциях, на которых строится дизайн языка.

                                              Вы пишете какой-то поэзией там, где неплохо бы как раз применять точные термины. «Дизайн языка» — это что?
                                              Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде. Концепции DSL (взаимодействие с браузером и документом) в нынешнем JS реализованы очень банально и просто, говнокодить там просто негде. Дополнительные плюшки, «синтаксический сахар» (хотя, строго говоря, не обязательно именно синтаксический), артефакты обратной совместимости — существование этого всего можно просто игнорировать, если вам не нравится качество (скажем, сегодня никто вас не заставляет руками составлять XML из базовых типов, хотя это безусловно возможно сделать). И конкретно для JS на ваше
                                              Это правда, но то, насколько сильно нужно постараться, чтобы написать не говнокод, от языка к языку сильно различается.

                                              я вам могу просто ответить «Изучайте современный JS. Не изучайте JS десятилетней давности», и вопрос будет исчерпан.

                                              Ничего подобного — сравните developer experience, когда среда сама подсказывает вам все аргументы\поля\методы

                                              Возможности IDE и ограничения языка — это две абсолютно разные вещи. Вам писали про второе, а вы ответили первым. Если (чисто как пример) в языке не существует циклов, то никакая IDE вам его не сделает настолько удобным, что вы его предпочтете языку с циклами.
                                                –3
                                                Базовые концепции всех императивных языков примерно одинаковые и функционируют примерно одинаково везде.
                                                Смешно, что многие из этих базовых концепций работают одинаково во всех остальных языках, но не в джиесе :)
                                                Изучайте современный JS
                                                А что там исправили? Запретили monkey patching объектов, неявное приведение, передачу несовпадающего количества аргументов в функцию, исправили семантику `Foo() / new Foo()`, устранили возможность абсолютно любому скрипту нагадить в глобальную область или подменить функцию стандартной библиотеки? Из полезного добавили разве что приватные поля — да и то с костылями из-за проблем с обратной совместимостью.
                                                Возможности IDE и ограничения языка — это две абсолютно разные вещи.
                                                Кто вам сказал такую глупость? Эти вещи тесно взамосвязаны. Из-за динамической природы языка для джиеса впринципе невозможно реализовать автокомплит\рефакторинги уровня IDEA\R#.
                                                  +1
                                                  А что там исправили? Запретили

                                                  Вы тоже из тех, кто возможность выстрелить себе в ногу приравнивает к выстрелу?
                                                  Как насчёт того, чтоб просто не стрелять?

                                                  И нет, аргумент «в более крутых языках возможностей выстрелить себе в ногу меньше, а поэтому там пишут меньше говнокода» не принимается, пока вы его не докажете. Моя практика показывает, что объем говнокода почти исключительно зависит от общего объема пишущегося кода, а не от языка. Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую. Если в какой-то момент какой-нибудь хаскель станет жутко популярным (впрочем, навряд ли) — мы увидим множество интересных способов отстрелить себе ноги там.

                                                  Эти вещи тесно взамосвязаны.

                                                  Возможности IDE вытекают из ограничений языка, а не наоборот. Поэтому не стоит на аргумент об ограничениях языка отвечать «а вот IDE оооо!». Я вам писал именно об этом. Вы предпочли этого не заметить, а избирательно процитировать и спорить дальше.
                                                    +3
                                                    Как насчёт того, чтоб просто не стрелять?
                                                    Для этого надо быть сверхчеловеком, который сам никогда не ошибается, не работает с джунами, не поддерживает легаси и вообще не использует сторонние библиотеки. К сожалению, в реальном мире я таких не знаю.
                                                    Стала ява чуть более популярной, и вот уже никакая «строгость» не мешает людям сделать рефлексией то, что им компилятор не даёт сделать напрямую.
                                                    Так это правильный баланс между гибкостью и надежностью. Нет такого языка, который мог бы вообще не дать написать на нем некорректную программу. Однако в той же джаве «целевое» использование объектов заметно проще и короче, чем «нецелевое» с помощью рефлексии, а в джиесе они равнозначны.
                                                    Я вам писал именно об этом.
                                                    Изначальный постулат был — «ограничения усложняют разработку». Я привел пример того, как некоторые ограничения ее наоборот упрощают. Вашу же мысль я в обоих сообщениях так и не уловил…
                                                      +4
                                                      Вы тоже из тех, кто возможность выстрелить себе в ногу приравнивает к выстрелу?

                                                      Я про себя знаю, что я глупый, забывчивый и иногда бываю невыспавшимся. Более того, иногда другие люди бывают невыспавшимися, а ещё иногда два совершенно гениальных и выспавшихся человека не понимают друг друга, и ерунда с выстрелами и спецэффектами происходит на границе взаимодействия их модулей.


                                                      Как насчёт того, чтоб просто не стрелять?

                                                      Тесты? Как насчёт того, чтобы просто не делать ошибок?
                                                      Рефакторинг? Как насчёт того, чтобы сразу писать нормально?
                                                      Джаваскрипт на бэкенде? Как насчёт того, чтобы выучить C++ за 21 день и на нём быстро писать?


                                                      Если в какой-то момент какой-нибудь хаскель станет жутко популярным (впрочем, навряд ли) — мы увидим множество интересных способов отстрелить себе ноги там.

                                                      Он уже достаточно популярен, на самом деле, чтобы не опасаться за наличие работы или отсутствие библиотек. Ну и да, avoid popularity at all costs — это как раз про то, чтобы не идти на компромиссы и необдуманные решения просто ради того, чтобы набрать классы.


                                                      Но нет, способов выстрелить в ноги там очень мало. Они есть, но когда я надеваю шляпу C++-программиста, мне даже в голову не приходит считать их чем-то плохим (что? нельзя доказать, что функция всегда завершается? а зачем это в С++?).

                                                        +1
                                                        Я про себя знаю, что я глупый, забывчивый и иногда бываю невыспавшимся.

                                                        Мне сложно себе представить, что я от забывчивости или от недосыпа вдруг начну применять в яве рефлексию просто потому что. Или в JS буду на лету патчить прототип.
                                                        От таких вещей можно написать нерабочий код, но не говнокод через использование заведомо глубоко небезопасных фич языка. А глупость стоит лечить образованием.

                                                        Тесты? Как насчёт того, чтобы просто не делать ошибок?
                                                        Рефакторинг? Как насчёт того, чтобы сразу писать нормально?
                                                        Джаваскрипт на бэкенде? Как насчёт того, чтобы выучить C++ за 21 день и на нём быстро писать?

                                                        Вы передергиваете. Изначальная соль метафоры с «выстрелом в ногу» как раз и заключается в том, что в ногу можно стрелять, а можно не стрелять. И стреляя — нужно осознавать последствия.

                                                        Если у языка есть глубоко небезопасные и вообще кривоватые фичи — их можно не использовать. Это совсем далеко не то же самое, что «не делать ошибок». Мне очень странно, что вы тут сделали вид, что не понимаете разницы.

                                                        Но нет, способов выстрелить в ноги там очень мало.

                                                        Про яву так в свое время тоже говорили. Всерьез говорили.
                                                          0
                                                          Мне сложно себе представить, что я от забывчивости или от недосыпа вдруг начну применять в яве рефлексию просто потому что. Или в JS буду на лету патчить прототип.

                                                          Это на недосып действительно списать труднее. Я же скорее говорил о вещах вроде типов и тому подобного.


                                                          Хотя… Иногда от доступа к приватным полям меня останавливало только ключевое слово private и правила языка, потому что иначе я его не замечал.


                                                          Изначальная соль метафоры с «выстрелом в ногу» как раз и заключается в том, что в ногу можно стрелять, а можно не стрелять. И стреляя — нужно осознавать последствия.

                                                          К сожалению, в проектах, которые я пишу, кроме моего кода есть ещё и чужой код, и он даже иногда обновляется. И какую ерунду он там делает, мне верифицировать каждый раз неохота.


                                                          Про яву так в свое время тоже говорили. Всерьез говорили.

                                                          Однако она действительно является большим шагом вперёд по сравнению с теми же плюсами с точки зрения безопасности.


                                                          Ну и да, из этого не следует, что ни в каком языке теперь не будет возможности ограничить себя в подобных выстрелах в ноги.

                                                            0
                                                            К сожалению, в проектах, которые я пишу, кроме моего кода есть ещё и чужой код, и он даже иногда обновляется. И какую ерунду он там делает, мне верифицировать каждый раз неохота.

                                                            К счастью, для этого придумали средства. От code review до автоматического линтинга с запретом всего, что стоит запретить. Если ими пользоваться — большая часть проблем таки решается.

                                                            А если 30 человек фигачат в блокнотах и пушат в мастер — ну, кто ж им доктор.
                                                              0

                                                              А вы так все библиотеки ревьювите и линтите?


                                                              Как убеждаетесь, что они биткоины по-тихому не майнят, например?

                                                                +1
                                                                Проблема стороннего кода (и пакетных менеджеров, до кучи) вообще ни разу не сопрягается с языком. Вы используете какой-либо чужой код (от библиотек до функций ОС)? А как вы убеждаетесь, что он биткоины не майнит?

                                                                И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.
                                                                  0

                                                                  Сопрягается, и ещё как.


                                                                  А как вы убеждаетесь, что он биткоины не майнит?

                                                                  Смотрю на те функции, которые живут в IO, и которыми я пользуюсь (если это какая-нибудь библиотека на графах или библиотека сортировки массивов, то их вообще нет). Проверяю, что для используемого модуля выводится, что он лежит в Safe-подмножестве. Если это так, то можно дальше даже не смотреть, если не так, то разбираюсь внимательнее (но это на моей практике бывало очень редко).

                                                                    0
                                                                    Если это так, то можно дальше даже не смотреть, если не так, то разбираюсь внимательнее (но это на моей практике бывало очень редко).

                                                                    Вы же понимаете, что вы сейчас описали страну розовых пони вида «мне мало что нужно, а что нужно, то есть в опенсорсе, и в моем языке небезопасные вещи объявляются отдельно»?

                                                                    Что нисколько не решает проблему в общем виде. С тем же успехом могли бы сказать «я не использую чужого кода» (а моя ОС написана мной самим). Вышли бы те же розовые пони.
                                                                      0

                                                                      Нет, не понимаю, потому что я этот подход успешно реализую на практике.

                                                                        0
                                                                        потому что я этот подход успешно реализую на практике

                                                                        И делаете ошибку выжившего в разговоре вот сейчас.
                                                                          0

                                                                          Ваш тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов возможно всегда и не зависит от языка. Я привел контрпример, когда язык вполне даёт возможность гарантировать, что какой-то код так не делает. Для опровержения вашего тезиса одного контрпримера, собственно, достаточно, и ошибки выживших тут ни при чём.

                                                                            0
                                                                            Я привел контрпример, когда язык вполне даёт возможность гарантировать, что какой-то код так не делает.

                                                                            Вы привели контрпример, в котором сделано множество допущений. Начиная с того, что вам доступен исходный код и вы собираете его сами достоверно надёжными средствами сборки (которые вы тоже собрали сами), в достоверно надёжном окружении (которое вы сами — что? правильно, начиная от самого железа), заканчивая тем, что, дескать, если чо, то вы будете «разбираться внимательнее» (без подробностей).

                                                                            Ваш тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов возможно всегда и не зависит от языка.

                                                                            Вы передергиваете. Мой тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов в условиях среднестатистического окружения никак не коррелирует с тем, на каком языке написан ваш (ключевое слово) код.
                                                                            С «возможно всегда», которое вы сами придумали и которое доблестно попытались развенчать — сами и воюйте, если вам интересно.
                                                                              +2
                                                                              Начиная с того, что вам доступен исходный код

                                                                              Сторонних библиотек, особенно берущихся с npm/pip/hackage? Да. Да и без этого, я по пальцам могу пересчитать библиотеки, у которых нет исходников и которыми приходилось пользоваться.


                                                                              Кроме того, code review и линтинг предложили вы сами. Теперь вас это резко не устраивает, и у вас появляются библиотеки с закрытыми исходниками. Ну ок.


                                                                              вы собираете его сами достоверно надёжными средствами сборки (которые вы тоже собрали сами)

                                                                              Зачем? Это не нужно для того, чтобы обезопаситься от кривой библиотеки.


                                                                              И линтеры с кодревью у вас, я так понимаю, достоверно надёжны?


                                                                              тем, что, дескать, если чо, то вы будете «разбираться внимательнее» (без подробностей)

                                                                              Да. Например, если Safe не выводится, то смотреть, почему и что мешает, и насколько это оправдано. Ну, то есть, свести потребность к ручному вмешательству и ручному анализу кода к минимуму.


                                                                              Мой тезис — что майнинг биткоинов, тыринг кошельков и наличие вирусов в условиях среднестатистического окружения никак не коррелирует с тем, на каком языке написан ваш (ключевое слово) код.

                                                                              Давайте ещё раз на него посмотрим, вот он:


                                                                              И абсолютно не важно, на чём это всё написано, и на чем написан ваш код.

                                                                              Тут нет ничего ни про какую среднюю статистику окружения. И в словах ваших из того комментария, идущих до этой цитаты, тоже ничего нет про это.


                                                                              При этом в том же хаскеле

                                                                                0
                                                                                Кроме того, code review и линтинг предложили вы сами.

                                                                                Как средство борьбы с появлением плохого кода у себя.
                                                                                Как средство контроля внешнего кода — это такой себе выход, эффективность которого сомнительна в произвольной степени.

                                                                                Зачем? Это не нужно для того, чтобы обезопаситься от кривой библиотеки.

                                                                                Затем, что в конечном счете разговор о майнерах и снифферах в контексте «в моем коде этого нет» не имеют ни малейшего практического смысла. Либо майнера и сниффера у вас нет совсем и вы можете гарантировать, что исполняемый код, так или иначе связанный с запуском вашей крутой программы, не несет в себе потенциальных угроз, или это всё пустые разговоры а-ля «в исходниках нет, а прочие проблемы меня не волнуют». Чудесный код, сам по себе не делающий ничего особенного, а-ля, скажем, TeamViewer — может быть использован для множества очень интересных сценариев, если будет написан с определенными уязвимостями.

                                                                                В контексте этого разговоры «я если чё почитаю код и оценю, насколько в нём всё ок» — это тоже мир розовых поней. Вы не всесильны и не всезнающи.

                                                                                Давайте ещё раз на него посмотрим

                                                                                Попробуйте не вырывать предложения из контекста, и всё будет гораздо лучше.
                                                                                  0
                                                                                  Либо майнера и сниффера у вас нет совсем и вы можете гарантировать, что исполняемый код, так или иначе связанный с запуском вашей крутой программы, не несет в себе потенциальных угроз, или это всё пустые разговоры а-ля «в исходниках нет, а прочие проблемы меня не волнуют».

                                                                                  Мы не можем гарантировать отсутствие закладок в компиляторе и ОС, поэтому давайте забьём на любой анализ последнего left-pad. Понятно.


                                                                                  В контексте этого разговоры «я если чё почитаю код и оценю, насколько в нём всё ок» — это тоже мир розовых поней. Вы не всесильны и не всезнающи.

                                                                                  Безусловно. К счастью, пока что во всех случаях, когда я натыкался на unsafePerformIO, unsafeCoerce и тому подобные вещи в коде чужой библиотеки, их удавалось избежать и переписать.


                                                                                  А где-то примерно один раз я вообще от библиотеки отказывался из-за unsafe в коде.


                                                                                  Попробуйте не вырывать предложения из контекста, и всё будет гораздо лучше.

                                                                                  Я специально указал, что (на мой взгляд, конечно же) про среднестатистическое окружение в вашем комментарии ничего не было, а цитировать весь комментарий целиком как-то глупо. Но вы, конечно, можете меня побить одной левой, указав, где конкретно вы об этом говорили.


                                                                                  Хотя это всё пустое, ибо если вы согласитесь, что есть языки, предоставляющие возможности проверять библиотеки без ложноотрицательных (т. е. не нашли ерунду, когда она там на самом деле есть) срабатываний и с очень малой долей ложноположительных срабатываний, то вопрос будет исчерпан сам собой.

                                                                                    0
                                                                                    Мы не можем гарантировать отсутствие закладок в компиляторе и ОС, поэтому давайте забьём на любой анализ последнего left-pad. Понятно.

                                                                                    Ложная дихотомия.

                                                                                    Я вам о том, что можете заисследовать left-pad, а ваш софт всё равно в итоге будет майнить.

                                                                                    К счастью, пока что во всех случаях, когда я натыкался на unsafePerformIO, unsafeCoerce и тому подобные вещи в коде чужой библиотеки, их удавалось избежать и переписать.

                                                                                    Вы опять взялись за «я делаю всё хорошо и правильно, значит в мире всё окей».

                                                                                    Я специально указал, что (на мой взгляд, конечно же) про среднестатистическое окружение в вашем комментарии ничего не было

                                                                                    В моем комментарии так же не было и «помайнить возможно всегда», на которое вы уже который комментарий пытаетесь наехать с позиций особых лабораторных условий, в которых таки кое-что будет невозможно. А было только лишь «помайнить равновероятно можно в коде на любом языке».

                                                                                    если вы согласитесь, что есть языки, предоставляющие возможности проверять библиотеки без ложноотрицательных (т. е. не нашли ерунду, когда она там на самом деле есть) срабатываний и с очень малой долей ложноположительных срабатываний, то вопрос будет исчерпан сам собой

                                                                                    Как только вы обоснуете это чем-нибудь более интересным, чем «я вот что-то там пишу, и оно у меня пока что не майнило, и я считаю, что и не сможет» — непременно.
                                                                                      0
                                                                                      Я вам о том, что можете заисследовать left-pad, а ваш софт всё равно в итоге будет майнить.

                                                                                      Может. Машина может майнить даже вообще без моего софта, с одной голой ОС. Но я топлю не за это, а за то, что вы можете решить кучу проблем относительно бескровным методом. Новости про то, что в репозиториях npm/pip/etc попался очередной вирус/кейлоггер/троян, проскакивают чуть более систематично, чем хотелось бы, тогда как от этоо защититься легко.


                                                                                      А было только лишь «помайнить равновероятно можно в коде на любом языке».

                                                                                      Нет. Если у вас в типе функции нет IO и она не использует полтора unsafe-хака (которые может проверять компилятор), то она не может майнить. И вызываемые ей функции не могут майнить. И так далее.


                                                                                      Как только вы обоснуете это чем-нибудь более интересным, чем «я вот что-то там пишу, и оно у меня пока что не майнило, и я считаю, что и не сможет» — непременно.

                                                                                      (надеваю чёрные брюки и белую рубашку, беру The Haskell Report под мышку) Извините, у вас не найдётся минутки, чтобы поговорить о чистоте? Вы что-нибудь слышали о монаде IO?

                                                                                        0
                                                                                        Но я топлю не за это, а за то, что вы можете решить кучу проблем относительно бескровным методом.

                                                                                        Конечно. Один из таковых методов называется «не пользуемся пакетными менеджерами». К языку отношения не имеет.

                                                                                        Если у вас в типе функции нет IO и она не использует полтора unsafe-хака (которые может проверять компилятор), то она не может майнить. И вызываемые ей функции не могут майнить. И так далее.

                                                                                        Функционально такой же (но плохой и непроверяемый) код на JS, никак не взаимодействующий с внешним миром — равновероятно не может майнить.
                                                                                        Вы упираете в то, что вы можете «просто глянуть на типы» и быть в чём-то там уверенным. Я вам говорю о том, что просто глянув на типы вы можете быть уверенным в чём угодно, но только не в том, что в итоге оно всё не будет майнить. Для серьезного повышения уверенности — вам нужно или писать очень специфический камерный код (но в этом случае вы и на JS можете писать камерный код), или вы так или иначе будете взаимодействовать с чем-то за пределами вашего кода, для чего безопасность вы не обоснуете.
                                                                                          0
                                                                                          Один из таковых методов называется «не пользуемся пакетными менеджерами». К языку отношения не имеет.

                                                                                          Я бы не назвал его бескровным.


                                                                                          Функционально такой же (но плохой и непроверяемый) код на JS, никак не взаимодействующий с внешним миром — равновероятно не может майнить.

                                                                                          А может и майнить. Тайпчекера-то нет, чтобы проверить отсутствие взаимодействия с внешним миром.


                                                                                          Я вам говорю о том, что просто глянув на типы вы можете быть уверенным в чём угодно, но только не в том, что в итоге оно всё не будет майнить.

                                                                                          Почему? Ну, конечно же, при некоторых дополнительных допущениях, ряд которых вы вполне корректно заметили, вроде корректности компилятора, ОС и тому подобных вещей.

                                                                                            0
                                                                                            А может и майнить.

                                                                                            Ваш мобильник не управляет вами, даже если вы в этом не уверены.
                                                                                            Аналогично, код, который не майнит — не майнит. Проверяете вы ли его тайпчекером, ревьюверами, статанализом, или, наконец, файрволлом.

                                                                                            Мой тезис про равновероятность на разных языках — он всё таки «при прочих равных», а не «на хаскеле у меня один код, а на JS другой, и первый скорее всего не майнит, а второй скорее всего да».
                                                                                              0

                                                                                              Так смысл не в этом. Смысл в том, чтобы поймать код, который майнит, но притворяется, что не майнит.

                                                                                                0
                                                                                                Смысл в том, что когда вы начнете писать что-то, что взаимодействует с внешним миром — вы больше не сможете сказать, что раз у вас в коде типы норм, то ничего майнить не будет.
                                                                                                  0

                                                                                                  Безусловно, тогда мне придётся просмотреть реализацию того, что взаимодействует с внешним миром. Но у меня будут гарантии, что некоторые вещи (на самом деле, практика показывает, большинство) с этим самым внешним миром не взаимодействуют.


                                                                                                  Более того, для вещи, которая взаимодействует с внешним миром в виде работы с БД, у меня всё равно могут быть гарантии, что она не читает из файлов или не шлёт запросы по HTTP. Или код, на самом деле взаимодействующий с внешним миром, может сводиться к одной функции на экран текста (свободные монады, это всё).

                                                                                                    0
                                                                                                    Безусловно, тогда мне придётся просмотреть реализацию того, что взаимодействует с внешним миром.

                                                                                                    Что ничего не гарантирует.

                                                                                                    Более того, для вещи, которая взаимодействует с внешним миром в виде работы с БД, у меня всё равно могут быть гарантии, что она не читает из файлов или не шлёт запросы по HTTP.

                                                                                                    Но раз уж мы тут довели беседу до таких глубин — то вообще-то отсутствие связей с внешним миром — тоже такой себе гарант невредоносности кода. Код может вредоносить банальным отжиранием ресурсов во время выполнения.
                                                                                                      0
                                                                                                      Что ничего не гарантирует.

                                                                                                      Согласитесь, что лучше, когда гарантии обеспечены только лишь моими глазами в одной функции из 10-100-1000, а не во всех из них, не правда ли?


                                                                                                      Но раз уж мы тут довели беседу до таких глубин — то вообще-то отсутствие связей с внешним миром — тоже такой себе гарант невредоносности кода. Код может вредоносить банальным отжиранием ресурсов во время выполнения.

                                                                                                      Полностью согласен.


                                                                                                      Характеристики производительности, конечно, тоже можно доказывать и выражать в типах, но это совсем не мейнстрим и перебор.

                                                                                                        0
                                                                                                        Характеристики производительности, конечно, тоже можно доказывать и выражать в типах, но это совсем не мейнстрим и перебор.

                                                                                                        Можно на этом месте попросить наводку, где про это почитать поподробнее?

                                                                                                          0

                                                                                                          Ну, вы можете формально доказывать, что некоторая функция сделает не более f(n) шагов для входа длины n. Информация на эту тему очень разрозненная и на уровне фольклора, но я когда-нибудь соберусь и напишу что-нибудь на эту тему.

                                                                                                            0

                                                                                                            Будем ждать, потому что тема весьма заинтриговала. Честно говоря, надеялся, что уже есть какая-то более-менее внятная литература, но раз так — будем ждать мысли по теме от Вас :)

                                                                                                              0

                                                                                                              Ну, с функциями в deep embedding всё понятно — просто берёте и доказываете. С shallow embedding всё, конечно, поинтереснее.

                                                    +2
                                                    «Дизайн языка» — это что?

                                                    Наличие/отсутствие неявных преобразований, продуманность системы типов, принцип наименьшего удивления, всё такое.


                                                    Я пробовал на питоне писать — куча непоняток и WTF-моментов, связанных с чем-то, что нельзя назвать иначе как дизайн языка.


                                                    Базовые концепции всех императивных языков

                                                    А зачем ограничиваться только ими?


                                                    Если (чисто как пример) в языке не существует циклов, то никакая IDE вам его не сделает настолько удобным, что вы его предпочтете языку с циклами.

                                                    Пишу на языках без циклов с наибольшим удовольствием, кстати.

                                                      0
                                                      Пишу на языках без циклов с наибольшим удовольствием, кстати.

                                                      Это какой?
                                                      И как там сделать
                                                      while(true){}
                                                      ?)

                                                        +1
                                                        Это какой?

                                                        Хаскель, идрис (но последний только как хобби пока что).


                                                        И как там сделать while(true){}

                                                        infinite = infinite

                                                        В идрисе с тоталити чекером никак, но это хорошо: доказуемая продуктивность — полезное свойство.

                                                          0

                                                          в некоторых языках без циклов while(true) реализуется с помощью goto

                                                  +3
                                                  Интересно, чем это джаваскрипт способствует написанию плохого кода? Крайне удобный язык и часто им пользуюсь
                                                    0

                                                    Я не знаю способствует он или нет. И возможно это просто я один такой везучий. Но почему то на JavaScript мне попадалось и всё ещё попадается гораздо больше плохого(а местами даже просто ужасного) кода чем на других языках.

                                                      +1

                                                      Неявное приведение типов, неконсистентность стандартной библиотеки, легкость monkey-patching'а, отсутствие поддержки приватного состояния (по крайней мере до недавнего времени)… Вот нескольки смачных примеров: https://wtfjs.com/

                                                        +1
                                                        Неявное приведение типов
                                                        Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.
                                                        неконсистентность стандартной библиотеки
                                                        В каком смысле? Современные браузеры очень консистентны, старые методы работают всегда, благодаря обратной совместимости.
                                                        легкость monkey-patching'а,
                                                        Не нравится — не используйте. Кто заставляет? В чём проблема языка, что он представляет мощные возможности по расширению?
                                                        отсутствие поддержки приватного состояния
                                                        Паттерн «модуль» существует столько, сколько существуют замыкания.

                                                        Типичные аргументы хейтеров, не прочитавших хоть какую-нибудь документацию. Эффект «утёнка»: «а у нас в языке не так!»
                                                          +2

                                                          Ваши ответы имели бы смысл, если бы все вокруг были бы идеальными людьми:


                                                          Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.

                                                          Только что делать, если у тебя есть унаследованная база кода, которую написали люди не знающие базовых правил, и в которой используются глобальные переменные, манкипатчинг и т.п.?


                                                          А в этом и есть сложность разработки: в основном мы не пишем новый код, а работаем с существующим, написанным скорее всего не нами.

                                                            +1
                                                            Зная несколько базовых правил, и не делая явных глупостей, вообще проблем быть не должно.
                                                            Ну вот сходите по ссылке и посмотрите, сколько из примеров вы сможете полноценно объяснить знанием нескольких базовых правил :)
                                                            Современные браузеры очень консистентны
                                                            Мой любимый пример: `new Date(2019, 10, 23) == new Date(«2019-10-23»)` дает `false`, попробуйте угадать почему.
                                                            Типичные аргументы хейтеров, не прочитавших хоть какую-нибудь документацию. Эффект «утёнка»: «а у нас в языке не так!»
                                                            Ровно наоборот: работа с несколькими языками дает возможность сравнить и понять их сильные\слабые стороны, а вот если человек кроме джиеса ничего не знает — то он вполне ожидаемо будет по-утиному оправдывать его недостатки…
                                                              +1
                                                              Ну вот сходите по ссылке и посмотрите, сколько из примеров вы сможете полноценно объяснить знанием нескольких базовых правил :)
                                                              Все эти примеры давно разобраны. Могу объяснить любой, который непонятен. Но тут главное даже не это. Никто в здравом уме не будет писать такой код в продакшен, именно поэтому достаточно базовых правил.
                                                              Мой любимый пример: new Date(2019, 10, 23) == new Date("2019-10-23") дает false, попробуйте угадать почему
                                                              Чего-то тут гадать, базовое правило: два разных объекта (любых непримитивов) никогда не равны друг другу. Даже с одинаковыми значениями. Тоже самое что сравнивать
                                                              ({} == {}) // false
                                                              Хотя даты, конечно, весьма своеобразный объект, но это уж так было взято из Java.
                                                              …дает возможность сравнить и понять их сильные\слабые стороны…
                                                              Только вот человек называет сильные стороны слабыми. Причём никто из моих коллег не испытывал с этим никаких проблем.
                                                                +1
                                                                два разных объекта

                                                                Тут скорее всего имелось ввиду, что при передаче аргументов конструктора в виде чисел 10 — это ноябрь.

                                                                Тоже самое что сравнивать
                                                                ({} == {})

                                                                А вот сравнение объектов (< или >) выполниить нельзя, а даты — пожалуйста.
                                                                  +2
                                                                  Никто в здравом уме не будет писать такой код в продакшен
                                                                  С джунами никогда не работали?
                                                                  два разных объекта (любых непримитивов) никогда не равны друг другу
                                                                  Окей, немножко усложним: new Date(2019, 10, 23).toString() == new Date("2019-10-23").toString() все еще дает false
                                                                    +2

                                                                    Давайте сразу третий уровень сложности:


                                                                    new Date(2019, 9, 23).toString() == new Date("2019-10-23").toString() // false
                                                                      0
                                                                      Объясните балбесу в чём тут прикол. Я не понял. Не прикалываюсь, действительно интересно.

                                                                      В двух примерах это разные даты. Так же тут ещё есть всякие зоны, летнее время и т.д.
                                                                        0
                                                                        new 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 :)

                                                                          +1
                                                                          Вроде логично — сравниваются строки, а не сами даты. Если строки не совпали, то это false.
                                                                          Почему-то думал, что тут какая-то нелогичная магия, а тут вроде по делу.
                                                                            +1
                                                                            Логично ли, что умолчательные таймзоны необоснованно разные?
                                                                              0
                                                                              Если подумать, то логично. Обычно парсятся строки в формате ISO вида "2019-10-24T12:00:00.000Z", в них указан часовой пояс (Z здесь означает UTC+0).

                                                                              Если создавать дату из конструктора вида
                                                                              new Date(год, месяц, день, час, минуты, секунды);
                                                                              то предполагается работа с пользовательским временем и логично использовать текущую временную зону.

                                                                              Работа со временем — сложная область программирования (заблуждения о времени, ещё заблуждения, заблуждения о unix-времени), и это не к языку вопрос, тем более что весь Date — это заимствованные методы.
                                                                                +1
                                                                                Ничего не мешало сделать семантику конструкторов консистентной, в ту или другую сторону. Предположения авторов неочевидны для читателя.

                                                                                весь Date — это заимствованные методы.

                                                                                Кому какое дело? Эта милая особенность — это на многие годы часть стандартной библиотеки языка.
                                                                                Ведь даже в Java, на которую, как мне кажется, тут кивают, уже успели добавить адекватную стандартную замену с недвузначными именами (LocalDateTime и ZonedDateTime).
                                                                    0
                                                                    С джунами никогда не работали?
                                                                    Работал. Но даже непрошедшие испытательный срок таких ошибок не делали. Видимо, они что-то да прочитали про Javascript.

                                                                    Касательно, Date — это не javascript-way сущность, и потому совсем не показательно с точки зрения языка, не говоря уж про сложность предметной области работы со временем. Вы бы ещё на NaN привели, как это любят.
                                                                      0
                                                                      даже непрошедшие испытательный срок таких ошибок не делали
                                                                      Остается только позавидовать вашей сверхъестественной везучести, опровергающей закон Мёрфи, и вере в человечество :)
                                                                      Date — это не javascript-way сущность, и потому совсем не показательно с точки зрения языка
                                                                      Что она тогда делает в стандартной библиотеке? Почему ее нельзя было сделать javascript-way? Или javascript-way — это собрать некое подмножество хорошо удавшихся вещей, а про остальные сделать вид, будто их не существует?
                                                                        0
                                                                        Обратная совместимость не позволяет менять уже существующий стандарт, даже если это неписанный стандарт де факто. Но новые предложения никто не мешает обсуждать, вы может сделать своё предложение и отправить его на рассмотрение в TC39. Именно так язык и развивается. Каждый год выходит новая версия.
                                                                    0
                                                                    два разных объекта

                                                                    Тут, скорее всего, имелось ввиду, что 10 — это ноябрь, при передаче аргументов в конструктор в виде чисел.

                                                                    Тоже самое что сравнивать
                                                                    ({} == {}) // false
                                                            +2

                                                            Даже интересно стало, а какие языки способствуют написанию хорошего кода?

                                                            0
                                                            Целый один класс на 5 экранов с циклом называть громким именем «приложение» как-то неправильно.
                                                            –3
                                                            Только в период замены — начнётся такая неразбериха… Как лет 10 назад — когда постоянно приходилось выбирать — JS или Flash. Только-только всё устаканилось… Ориентироваться вообще надо сейчас только на один движок — Chromium. Один язык. Одни возможности. И давайте снова революцию устроим?
                                                              +8

                                                              Нет, спасибо, я не хочу ориентироваться на Chromium с анальными зондами Google, который хочет через него подмять под себя весь интернет, как когда-то Microsoft с IE. Спасибо, один раз уже проходили.


                                                              Неразберихи не будет, потому что WebAssembly — универсальный стандарт. Мне как пользователю все равно, на чем написана какая-то социальная сеть ­— главное, что ее сырцы скомпилированы в WebAssembly, который понимает мой браузер.


                                                              А как разработчику мне приятно, что я могу писать на своем любимом языке, а не на том, который мне 25 лет назад навязали без возможности выбора.

                                                                –1

                                                                Во времена IE3 выбор был же: JavaScript vs Vbscript, это не вспоминая про JScript, Java, ActiveX и Flash

                                                                  +2

                                                                  Это не был выбор, т.к. во-первых, Vbscript поддерживался только IE, во-вторых, лучше уж Js, нежели Visual Basic — чур меня!


                                                                  Java апплеты всегда были неуниверсальной и адски костыльной технологией (у пользователя должен был быть плагин, и каждый раз при открытии страницы с апплетом, комп замирал на несколько минут пытаясь проглотить жабу).


                                                                  Flash — дырявая пропиетарщина, и там был по-моему тот же Javascript под капотом.


                                                                  Настоящей свободы выбора никогда не было.

                                                            +1
                                                            Вангую, что кода webassembly притрётся, все будут говорить: «Вы знаете, на PHP/Python/Rust/Java/Kotlin/C#/Haskel/Go/ELM/Scala/C++/Ruby очень удобно писать glue code, высокоуровневую бизнес-логику» и никто не будет ничего доказывать, потому как ну и так же всем ясно.
                                                              +3
                                                              на JS очень удобно писать glue code, высокоуровневую бизнес-логику

                                                              Ну фиг знает, если бы мне надо было что-то писать под веб, то на чистый джаваскрипт я бы смотрел в последнюю очередь, наверное.


                                                              в Qt теперь QML (== жаваскрипт вид сбоку)

                                                              Свистопердящие интерфейсы на QML действительно удобно делать, чтобы анимации там, ездило всё везде, летало, переливалось. Делать мощные интерфейсы на нём сложно. Скажем, почтовый клиент или 3D-моделлер какой я бы делать на нём не стал.

                                                                0

                                                                Про QML — ну основное окно 3D редактора точно на C++ пришлось бы делать, а всякие обвязки и менюшки вполне можно на QML. Plasma ведь переписали на нем.

                                                                  +1

                                                                  Ну, я в своём комбайне часть вещей тоже на QML переделал, типа индикатора погоды или каких-то кнопочек для быстрого запуска (чтобы они там красиво анимировались по мере наведения мышки, скажем). Всему своё применение и назначение.

                                                                    0
                                                                    Ну, я в своём комбайне

                                                                    Вы имеете в виду LeechCraft? :)

                                                                      +2

                                                                      УДОЛИ Да.

                                                                        0

                                                                        Читал о нём еще в вашем ЖЖ много лет назад)

                                                                  +2
                                                                  А TypeScript например? Вполне няшевый язык же.

                                                                  Вообще это вопрос зоны комфорта, я могу запросто eumorozov из треда выше понять, про идиосинкратическое неприятие. У меня с руби такое, прямо соки говн. А к жаваскрипту привык, уже вроде и нормик.
                                                                    +1

                                                                    По общению с некоторыми местными знатоками TS — да, клёвая шутка.


                                                                    Правда, я всё равно постараюсь сначала транспилить какие-нибудь другие языки. Вот, например, или вот.

                                                                      –1
                                                                      А к жаваскрипту привык, уже вроде и нормик.

                                                                      Просто я в веб варюсь где-то с 1998 года. И всегда, когда встречался код на Javascript, у меня волосы вставали на голове дыбом. Javascript развивался, появлялись всякие node.js/react, но каждый раз открывая файл с расширением js или html с тегом <script>, результат чаще всего такой: «Как можно так ужасно писать?».


                                                                      Потому это даже не идиосинкразия, это просто мой личный жизненный опыт научил меня всегда подозревать, что в файле .js будет что-то ужасное. Тонны копи-пейста, однобуквенные имена переменных, использование регекспов для поиска пробела в строке (или любой другой задачи связанной с обработкой строк — там где надо и где не надо), 3-4 уровня вложенных условий, и т.д. и т.п.


                                                                      Javascript был создан с прицелом, чтобы на нем мог писать даже идиот. К сожалению, очень много идиотов и писало, и так часто приходилось это видеть, что возникла устойчивая ассоциация.

                                                                  +2
                                                                  «Always bet on JavaScript» ©Brendan Eich
                                                                    +11

                                                                    WA обречён быть нишевым. Ибо 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 ситуацию не спасёт.

                                                                      +1
                                                                      либо заменить нахрен весь технологический стек, и от web останется одно название

                                                                      Ставлю на этот вариант в исторической перспективе.


                                                                      (привет Skype и Nokia).

                                                                      А что именно у них имеется в виду?


                                                                      создание интерфейса одновременно для VR/AR и для классических 2D-экранов

                                                                      Пока что такие интерфейсы не пользуются популярностью, сомнительно, что это нужно.

                                                                        +1
                                                                        А что именно у них имеется в виду?
                                                                        От них остался один лишь бренд. Современный Skype ни технически, ни даже по функциональности не имеет отношения к тому, который был до покупки Microsoft'ом — это перекрашенный MSN Live с поддержкой учёток от Skype, по сути. О Nokia и говорить нечего, все наработки мобильного подразделения (Symbian/Meego/Series 30/Series 40, шрифты, патенты и т.д.) остались у Microsoft; HMD просто паразитирует на известности бренда и продаёт совершенно не имеющие отношения к «той» Nokia мобильники на Android/KaiOS.
                                                                        Пока что такие интерфейсы не пользуются популярностью
                                                                        Просто их время ещё не пришло. Текущие VR/AR-разработки опережают своё время, как Apple Newton и webOS. Для них пока нет достаточно распространённого высокоскоростного доступа в Интернет, да и сами очки поныне слишком громоздкие — в идеале они должны стать не более громоздкими, чем обычные, чтобы обрести массовость.
                                                                          0
                                                                          Просто их время ещё не пришло

                                                                          Так уже не первое десятилетие говорят...

                                                                            0

                                                                            Велика беда. Нейронкам вон полвека понадобилось, чтобы достичь наконец широкого применения.

                                                                        +2

                                                                        Все что Вы хотите — есть во Flutter/Dart :)

                                                                          +1

                                                                          Dart слишком давно мёртв, чтобы вышло его зафорсить. Он появился именно как один из «препроцессоров» для JS, в этой роли не взлетел — а сейчас-то у него и подавно весомых преимуществ нет, кроме «языка для Flutter».


                                                                          А в случае агрессивного форса и замены Android на Fuchsia, Google рискует повторить историю с Windows Mobile/Windows Phone. Подсуетится Samsung с Tizen, китайцы тоже чего-то замутят — и кому станет нужна операционка от гугла?

                                                                            0

                                                                            У гугла есть козырь: обратная совместимость. Также как сейчас можно запустить APK на хромобуках, в фуксии будет нечто аналогичное, если, конечно, она выйдет как конечный продукт. А у майкрософта такой возможности не было, перенести винмобайл приложухи без пальце-ориентированного интерфейса в WP было бы безумием. Они конечно подсуетились с выходом WP10, сделали некий конвертер приложений iOS/Android в WP, даже инстаграм сконвертировали, но как технология дерьмо, да и шанс они свой давно упустили.

                                                                              0
                                                                              обратная совместимость
                                                                              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 парадигма управления опять изменится.
                                                                                0
                                                                                Google уже ломает совместимость со старыми приложениями в Android

                                                                                Конкретнее? Я не замечал такого.

                                                                                В Fuchsia же — полностью не совместимое ни с чем ядро

                                                                                Ну и что? Для рядового девелопера ядро ничего не значит, как я уже сказал выше. Если будет совместимость с уже текущими тулчейнами и приложениями, никто и не заметит изменений. Проблема будет только с вендорами, поскольку явно придётся бекпортировать драйверы, хотя функсия уже содержит в себе стандартный набор драйверов.
                                                                                  0
                                                                                  Конкретнее? Я не замечал такого.
                                                                                  https://developer.android.com/about/versions/marshmallow/android-6.0-changes и аналогично по другим версиям. Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.
                                                                                  никто и не заметит изменений
                                                                                  Изменения неизбежны, иначе овчинка выделки не стоит. Fuchsia — не «Android с новым ядром», а принципиально новая ОС. Подобное уже было с Mac OS X: несколько релизов подержали Rosetta для старых приложений, потом выкинули.
                                                                                  Для рядового девелопера
                                                                                  Проблема будет только с вендорами
                                                                                  Вы считаете, что девелоперы важнее вендоров? Оно отчасти так, компании подстраиваются под предложение на кадровом рынке. Вот только под что девелоперы писать будут, если Fuchsia станет маргинальщиной, как Windows Phone? Вон орава дельфистов побежала переучиваться, потому что разработка только под десктопную винду стала неактуальной.
                                                                                    0
                                                                                    Некоторые изменения, в особенности касающиеся прав доступа, затрагивают и старые приложения.

                                                                                    Не затрагивают они никого, вы заблуждаетесь. Затрагивают только если у приложения 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, что также мало кого интересовало на фоне низкой доли на рынке. И вины вендоров тут попросу нет, ибо они изначально были заинтересованы данной ОС и выпускали свои девайсы. А перестали выпускать только лишь из-за низкой реентабельности, причины которой рассмотрены выше.
                                                                                    Так что решать вам, кто важнее в данной ситуации — девелопер или вендор.
                                                                                      0
                                                                                      Поэтому старые версии всегда и везде работают так, как и работали до этого
                                                                                      Ну чтобы прямо не запускались — такого вроде нету. Но некоторую функциональность ломают. Например, статистику использования контактов. В менее печальных случаях (например, доступ к общей ФС) может понадобиться выдать приложению права через настройки.
                                                                                      Что у гугла, что у майкрософта сильные связи с вендорами
                                                                                      Были. Сейчас эти вендоры ушли на второй план. Европейские компании продали мобильные направления китайцам, из азиатских некитайцев держат планку только 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 наоборот: девелоперов-энтузиастов, пилящих софт под старые смартфоны, полно, но вендоров уже нет.
                                                                                        0
                                                                                        Европейские компании продали мобильные направления китайцам

                                                                                        Так это было и во времена WP, сути не меняет.

                                                                                        Велика беда. Apple на старые айфоны бесконечно новую iOS не портирует

                                                                                        У майкрософта нет «магии эпл», поэтому не сработало, тем более для только что вышедшей ОС.

                                                                                        А до этого был насыщен J2ME, Symbian, WM. Чего ж разработчики-то перебежали?

                                                                                        Причин множество, для типичного девелопера/конторы в первую очередь — возможность заработать. А гугл/эпл давал новый на тот момент формат продаж — Android Market/App Store. Мог ли предложить такой формат симбиан/j2me? win mobile сделал это в 2009, но у wm корпоративная направленность, да и сам он был еле живой с падающими 10% рынка, в то время как android/ios поднимались выше и выше.
                                                                                          0
                                                                                          Так это было и во времена WP, сути не меняет.
                                                                                          То времена другие были, гугл ещё худо-бедно держал планку «корпорации добра». А сейчас гайки закручивает, да и США торговыми санкциями грозятся.
                                                                                          У майкрософта нет «магии эпл»
                                                                                          А при чём тут Apple, если у Android с обновлениями ещё хуже, но взлететь это ему не помешало?
                                                                                          А гугл/эпл давал новый на тот момент формат продаж — Android Market/App Store
                                                                                          Так M$ тоже шмаркет свой открыл. У них ведь беда как раз в том, что пошли по пути Apple, сделав максимально огороженную платформу с дорогими девелоперскими учётками и единым магазином приложений с жёсткой модерацией. И как раз тут «магии» не хватило. Были б пооткрытей к сообществу — может, чего бы и выгорело.
                                                                                            0
                                                                                            Майки нормально шли по пути яблок, пока сами себе же не понаставили подножки, выкидывая на помойку один виндофон за другим. Пользователей и разработчиков было далеко не большинство, конечно, но и не полтора гика, гоняющихся за экзотикой.
                                                                                            Возможно, привыкли к успеху десктопной винды, и 5-10% рынка посчитали неудачей.
                                                                              +1

                                                                              Он очень даже. На серверах, в мобилках, в приятном ламповом фронтенде wrike.

                                                                                +2

                                                                                Похоже флаттер наоборот на взлёте — полная кроссплатформа — web, мобильники, собственный графический интерфейс по типу Java Swing — кто его знает как все повернется. Flutter ведь заменяет не только джаваскрипт но HTML и CSS.

                                                                                  0
                                                                                  — Ведь я умный, красивый, в меру упитанный мужчина — ну в полном расцвете сил!
                                                                                  — Да, но на телевидении этого добра хватает без Вас!

                                                                                  Этих кроссплатформенных технологий уже и так валом. Qt, Haxe, Kivy, вышеупомянутые React/Vue Native, всяческие web-обёртки типа Cordova. Вот только они либо непригодны для реального использования, либо пригодны лишь чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения. Особенно на iOS, где один хрен для сборки всей этой якобы кроссплатформы нужен пайплайн из макинтошей, XCode, дорогих девелоперских учёток и верификации (для прохождения которой всё равно iOS-специфичные изменения наверняка потребуются). Особого преимущества перед тем, чтобы сразу писать нативно, нет.

                                                                                    +2
                                                                                    чтобы быстрее конкурентов настрогать прототип и потом всё равно выпустить нативные приложения

                                                                                    Какая жалость, что большинство софта так и остаётся на стадии прототипа. А вон скайп вообще назад во времени переместился.

                                                                                      0
                                                                                      А вон скайп вообще назад во времени переместился.
                                                                                      Skype давно мёртв. После его покупки Microsoft'ом бывшие разработчики собрались и создали новый мессенджер — Wire. Microsoft же плавно, чтобы пользователи не заметили, слил Skype с собственным, изначально браузерным, мессенджером — MSN Live!

                                                                                      Но пользователи заметили. После того, как отключили Skype 7 — последнюю нативную версию для Windows — даже закоренелые юзеры, для которых Skype — синоним звонков через Интернет, стали плеваться от тормозной электроноподелки и подумывать о замене.
                                                                                      0

                                                                                      Это понятно, но моя мысль была в другом — flutter предлагает кардинально новый подход к пользовательскому интерфейсу — отсутствие декларативной верстки и декларативных стилей, пересоздание на лету дерева виджетов, совмещение состояния и представления — то есть stateful widget содержит в себе и данные (State) и подчинённые виджеты (View) Это интересно. Плюс BLOC — по сути stackfull стейтмашина. Голову сломать можно пока привыкнешь.

                                                                                        +1
                                                                                        flutter предлагает кардинально новый подход к пользовательскому интерфейсу — отсутствие декларативной верстки и декларативных стилей

                                                                                        Да? А мужики, писавшие в ранние нулевые интерфейсы на… да на практически всём, отличном от Delphi — и не знали, что они около 20 лет назад занимались «кардинально новым подходом к пользовательским интерфейсам».
                                                                                +1
                                                                                либо заменить нахрен весь технологический стек, и от web останется одно название
                                                                                Вероятнее всего. Уже сейчас web это не web, а легковестное и мобильное приложение.
                                                                                0
                                                                                Конечно, лет через пять новые фреймворки вытеснят Angular, React, Vue точно так же как они когда-то пришли на замену другим фреймворкам. Эта бесконечная чехарда и фрагментация может закончиться только еще большей фрагментацией с последующей консолидацией и переходом в проприетарную олигополию. С вероятностью 99% WASM или нечто похожее станет основой Web 3.0 где появится конкуренция не просто фреймворков, а проприетарных технологических платформ. А поскольку основные платформы принадлежат крупным вендорам, появятся новые способы монетизации, например, открываешь в 2025 газету «Ведомости», а она написана на Kotlin и требует платную подписку в Google Play, причем Chrome автоматически списывает средства с кошелька читателя.
                                                                                  0
                                                                                  Что мешает разработчикам добавить в браузер dart? В сайтах где используется js будет включатся js, а на сайтах где используется dart будет включатся dart.
                                                                                    +2
                                                                                    Так уже было с VBScript, ну и где он?
                                                                                      +1
                                                                                      Так уже было с флешем.
                                                                                      Так уже было с сильверлайтом.
                                                                                      И я думаю, на этом еще таки не уймутся, и запилят что-нибудь еще, что благополучно помрёт.

                                                                                      Что мешает разработчикам добавить в браузер dart?

                                                                                      Поддержка не слишком полезных пимпочек в коде браузера имеет вполне себе выразимую в человеко-часах * зарплату в час стоимость. Кто будет оплачивать банкет? Гугл? Гуглу тоже не сдался этот ваш дарт.
                                                                                        0

                                                                                        Dart вроде как в следующей после андройда, ОС Fuchsia собирались внедрить повсеместно. Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить. Было бы отлично иметь наличие альтернативы js.

                                                                                          0
                                                                                          Google, единственная компания которая может при желании его протолкнуть его как стандарт и заставить все остальные браузере его добавить.

                                                                                          Он компилируется в js, и в силу этого теперь уже нафиг не нужен в браузерах «прям так». А «протолкнуть как стандарт» гугл его пытался в 2015 через свой хром. Не вышло.

                                                                                          И единственная причина, по которой он живёт в Flutter — это как раз то, что у гугла уже есть компиляция дарта в js с одной стороны и в машинный код для андроида с другой стороны. Если это всё еще и работать будет единообразно, а не как обычно работают такие вещи — то получим очередное <...> Native, позволяющее писать одновременно на мобилки и в веб, в что гугл собственно и целится.
                                                                                          Но это никак не означает, что гуглу нужен именно dart. Flutter — да, dart — лишь потому, что инструментарий уже есть.
                                                                                      0
                                                                                      Он был. См. Dartium.
                                                                                        +1

                                                                                        Не надо дарт( он уродский на фоне js

                                                                                          0
                                                                                          Вот, да, тоже так считаю. Дарт это какая-то жава, но без тех вещей, которые делают жаву полезной.
                                                                                            0

                                                                                            Он ближе к с# идеологически.

                                                                                            0

                                                                                            В чем его уродство? Он приятный, он типизированный, у него есть настоящие классы. Для него написаны удобные api future и stream.

                                                                                              +1

                                                                                              Против js несомненно.
                                                                                              Но после того как пользуешься красивым ts который к тому же лишён минусов dart — сразу замечаешь кучу косяков.
                                                                                              Если по простому — в Гугл захотели придумать свой синтаксис на многие вещи, чего только стоит приватный метод через _

                                                                                                +1

                                                                                                Никогда не писал на ts. Можно легкий ревью косяков дарта? Просто со своей стороны я не могу этого увидеть.

                                                                                                  0
                                                                                                  1. Ну например читаемость, он вообще нечитаем против того же ts.
                                                                                                    Уже давно по стандарту конструктором называют слово construct, но в dart решили вспомнить php 4 и сделали название класса.
                                                                                                  2. Импорты, что мешало сделать импорты как в ts или том же php? В ts в шторме я просто пишу название класса/функции и мне сразу его подтягивает, в dart я такого не нашел, потому-что там импорты сразу всего файла или модуля и ты импортируешь сразу все, а потом пишешь код. Как require в php.
                                                                                                  3. Про боязнь разработчиков слов private и protected я писал выше

                                                                                                  Это из тех, которые удалось вспомнить в первые пару минут, на деле, раздражающих вещей там намного больше, возможно я избалован ts, но пару месяцев назад забросил изучение flutter из-за dart.

                                                                                                    0

                                                                                                    Блин, все что ты описал я воспринимаю как приятные фишки. Это особенности языка и привычек уже нврн.
                                                                                                    Ps автодополнение лучше всего работает в vs code как и другие фишки, в том числе кодогенераторы. Private и protected уже по привычке в голове на подчеркивание меняется

                                                                                                      +1

                                                                                                      Зачем мне редактор, если я хочу использовать ide?
                                                                                                      Зачем мне перегруженный нечитабельный синтаксис c, java без их фишек?
                                                                                                      Пописав на ts пару недель понимаешь, что dart и рядом не стоял по комфорту. Весь мир пришел к ts, если бы dart был лучше ts — его бы все использовали в вебе, а так его используют только в flutter по безысходности.

                                                                                                        –2
                                                                                                        > Весь мир пришел к ts
                                                                                                        Может хватит за весь мир говорить?

                                                                                                        > Dart используют только в flutter по безысходности
                                                                                                        Прям настоящая мука. Ага. Стонем и плачем. Вы в начале попробуйте десктопный софт написать или мобильное приложение на своем TS создать, а потом говорите.
                                                                                                          0

                                                                                                          О боже, какие обиды.
                                                                                                          Статья про веб, забыли? В мире веба уже давно везде ts.
                                                                                                          Зачем мне создавать десктоп, если я говорю за веб?
                                                                                                          Да и flutter далеко не заслуга dart, просто его google гвоздями туда прибила, что-бы был "свой язык", ведь каждый нормальный пацан хочет что-бы все пользовались его языком программирования

                                                                                                            0
                                                                                                            TS это просто обертка над JS. Проблем JS не решает, зато добавляет главную проблему — необходимость хорошо знать JS перед тем как писать на TS.
                                                                                                              0

                                                                                                              Как скажете, видимо вы один это понимаете, а остальные люди просто тупые.

                                                                                                                0
                                                                                                                Почему один? Сообщество Dart крайне быстро растет.
                                                                                                                  +1

                                                                                                                  сообщество flutter быстро растет, а dart появился на год раньше ts и был в забвении пока не запустили flutter.
                                                                                                                  Если бы flutter был на чем-то другом написан — про dart так бы и не вспомнили.

                                                                                                                    0
                                                                                                                    Жалко, что это не оказался kotlin. Была бы бомба)
                                                                                                                0

                                                                                                                Некоторые проблемы JS он как раз решает. Собственно почему и получил такую популярность.

                                                                                                                  0

                                                                                                                  Как раз наоборот — TS избавляет от необходимости знать тонкости JS. Вместо неочевидного поведения в рантайме сразу будет ошибка компиляции.

                                                                                                                    0
                                                                                                                    В реальности это разбивается о взаимодействие с JS или JSON, ибо проверки типов заканчиваются в компайлтайме. Далее отладка идет уже по правилам JS.
                                                                                                                      +1
                                                                                                                      В реальности небезопасные обращения к внешним API и отсутствие проверок целостности приходящих данных в любом языке заканчивается в дебаггере в случае любых проблем.
                                                                                                                        0
                                                                                                                        Ну, тот же дотнет имеет рантаймовые проверки, неправильный каст чего-то неизвестного из вражеской сборки тут же завалится с InvalidCastException, а не будет дрейфовать по приложению в виде какого-нибудь NaN, поганя данные и увеселяя отладку.
                                                                                                                        Падать при невозможности десериализовать JSON в объект конкретного типа — это тоже задача решенная.
                                                                                                                          0
                                                                                                                          Тот же JS (и TS) никак не мешает вам сделать рантаймовые проверки.
                                                                                                                            0
                                                                                                                            JS (и TS) никак не мешает

                                                                                                                            Но ведь и не помогает.
                                                                                                                            Могу добавить рантаймовые проверки. Могу и тестами обложить. А могу забыть, забить или сделать неправильно. Привет суровый JS-рантайм.

                                                                                                                            Прелесть TS в неявности его проверок, что они создаются и контролируются без прямого участия программиста, просто по факту использования объявленных типов. Но для поддержки развесистых типов в рантайме нужно писать дополнительный код, использовать сторонние средства.
                                                                                                                        0

                                                                                                                        С этим есть проблема, да, но можно воспользоваться io-ts.

                                                                                                                  0
                                                                                                                  Вы в начале попробуйте десктопный софт написать

                                                                                                                  А ведь в комментах уже написали волшебные буквы «Electron». Пока одни ноют, что это много жрет ресурсов (и правда много) — другие просто запускают свой вебкод в том числе как десктопное приложение, и не жужжат.

                                                                                                                  или мобильное приложение

                                                                                                                  React Native (и вам не обязательно писать именно на реакте, есть вещи, которые транспайлят откуда-то еще в react native).

                                                                                                                  Вы всерьез думаете, что кроме флаттера в мире ничего нет, что ли?
                                                                                                                    0
                                                                                                                    Flutter куда проще и универсальнее всех этих Электронов и React Native.
                                                                                                                      0
                                                                                                                      В теории.
                                                                                                                      Ваше высказывание аналогично, скажем, «Flash куда проще всех этих браузерных хаков под разные браузеры».

                                                                                                                      Более того, в определенный исторический момент это было вполне себе истинным высказыванием. Что было потом — мы все знаем.
                                                                                                                        0
                                                                                                                        То есть вы делаете ставку на JS и Электрон?
                                                                                                                          +1
                                                                                                                          Я не делаю ставку на очередную попытку вендор-лока, неважно от кого она исходит — от гугла ли, от MS ли, от Adobe ли.

                                                                                                                          Практика показывает, что вендор-лок для веба (да и не только для веба, на самом деле) просто вреден.
                                                                                                                  –1
                                                                                                                  Весь мир пришел к ts

                                                                                                                  Я чет не вижу. TS слишком захламляет код.
                                                                                                                0
                                                                                                                Честно говоря, эти недостатки выглядят как «а почему не так, как я привык?».

                                                                                                                Автоматические импорты были сделаны, не очень давно правда, наверное с год назад. При этом show / hide import combinators не используются. Если необходимо, в IntelliJ есть Quick Assist, который добавляет show с именами символов, которые реально используются в текущей библиотеке из импортированной.

                                                                                                                image

                                                                                                                image

                                                                                                            –3
                                                                                                            у него есть настоящие классы

                                                                                                            ООП уже давно не модно, теперь предпочитается ФП.

                                                                                                              0

                                                                                                              Где предпочитается?

                                                                                                                0

                                                                                                                В коммьюнити.

                                                                                                                  –1

                                                                                                                  Разве что разработчики реакта навязывают фп. Но никто его не использует, особенно в больших проектах. Вы видимо живете в параллельном измерении.

                                                                                                                    0

                                                                                                                    Я не про отдельно взятый фронтенд говорю. Это общая тенденция. Популяризируются как чисто функциональные языки (даже здесь в комментариях упомянули Haskell и Idris), так и в существующие ООП-языки перетаскиваются элементы функционального программирования (например, Stream API в Java, pattern matching в C#). А в новых языках ФП вообще из коробки (Rust, Kotlin). За последние лет 5 появилось огромное количество статей типа "Почему вы должны перейти на функциональное программирование" и "Почему ООП не работает".

                                                                                                                      +2

                                                                                                                      и эти статьи ничего не описали, они взяли ООП не научились им пользоваться и обвинили ООП. Я не знаю никого, кто бы писал сложный проект на ФП, ФП в сложных проектах используется только в очень жестком хайлоад типа вк

                                                                                                                        0
                                                                                                                        Хайлоад и ФП разве друг друга не взаимоисключают? Стейт мутировать дешевле, чем плодить сущности под каждое изменение.
                                                                                                                          –1

                                                                                                                          Возможно в некоторых языках так, помню читал доводы от ВК почему они не используют ООП, там оказалось дешевле отказаться от объектов

                                                                                                                            0

                                                                                                                            Вы про этот пост? Так это ограничение KPHP

                                                                                                                              –1

                                                                                                                              Не про этот, но это тоже имеет значение, они оставили это ограничение потому-что им не нужен был ООП)