Почему JavaScript не используется для классической разработки приложений (скомпилированное программное обеспечение)? [закрыто]

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

Он предлагает богатый набор функций, таких как:

• Динамическая печать
• Первоклассные функции
• Вложенные функции
• Затворы
• Функции как методы
• Функции как конструкторы объектов
• Прототип на основе
• На основе объектов (почти все является объектом)
• Regex
• Массивы и литералы объектов

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

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

Хотя, насколько мне известно, он используется только в веб-разработке или в существующих программах в качестве языка сценариев.

Только недавно, возможно, благодаря движку V8, он больше использовался для других задач (см. Например, node.js).

Почему до сих пор это относится только к веб-разработке? Что удерживает его от разработки программного обеспечения?

Недавно node.js продвинул разработку на стороне сервера. Итак, теперь можно писать JavaScript для разработки.

Это правда. В истории он не использовался как язык разработки. Но, эй, даже сценарии в клиентской среде (пользовательские агенты) - это тип разработки. Не так ли?

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

От сюда :

Обратите внимание, что все мои аргументы основаны на реальных вариантах использования. Встречные аргументы, которые не могут быть подкреплены примером использования в реальных, полных, интересных, полезных приложениях, недопустимы. Я видел маленькие «языковые демонстрации», которые есть у всех остальных, я видел посты в блоге, подробно рассказывающие о том, как прототипы и динамическая типизация делают какой-то тривиальный маленький пример на несколько строк короче, чем это было бы в C #, но они просто не актуальны к проблемам, с которыми вы сталкиваетесь при написании реального кода, а не микродемонстраций и игрушек. Итак, вот мои проблемы с JS:

а) магия "это". Это так, кроме случаев, когда это так. JavaScript заставляет вас использовать анонимные функции повсеместно, за исключением того, что они всегда теряют надлежащий контекст для переменной «this», так что вы в конечном итоге получаете глупый код типа «var _this = this» повсеместно, а затем используете его внутри ваших обратных вызовов или других функций. В некоторые дни я клянусь, что количество функций, которые мне удается написать, которые не используют переименованное «this», на самом деле меньше, чем число, которое делает.

б) 1 + «1» - 1 = 10. Также «1» + 0 = «10». Да, это на самом деле вызвало ошибки в наших приложениях, где данные, которые должны быть числами, были загружены из файла JSON в виде строки из-за ошибки в другом приложении, и результат был не очень хорошим. Весь наш код загрузки пришлось обновить, чтобы добавить массу преобразований типов повсюду. Когда мне нужно, чтобы что-то было числом, я действительно волнуюсь, просто хочу, чтобы это было число, а не строка, или объект, или ноль, или что-то еще. Lua, который во многих отношениях очень похож на JavaScript, исправил эту проблему, просто не будучи достаточно отсталым, чтобы использовать один и тот же оператор для сложения и объединения строк.

в) глобальные переменные по умолчанию. Поэтому, даже если вы возьмете аргумент, что динамическая типизация просто «проще», потому что вам не нужно думать о объявлениях переменных, JavaScript выбрасывает этот аргумент в окно, заставляя вас ставить 'var' перед новыми идентификаторами повсюду , А потом он молча винит тебя, если забудешь.

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

e) Невозможность создания типов передачи по значению. На самом деле это частая проблема почти на каждом языке, кроме C ++ / D. Для тех, кто использует JavaScript для написания приложений WebGL, взгляните на все библиотеки линейной алгебры для JavaScript. В 3D-приложениях вы почти используете векторы чаще, чем скаляры. Представьте, что каждое целое число в вашем приложении было передано по ссылке, так что «a = 1; b = a; b ++» делало a и b равными 2. Каждый маленький трехкомпонентный вектор является полным полным объектом. Они передаются по ссылке (на самом деле источник почти половины ошибок в нашей игре на WebGL). Они существуют в большом количестве, распределяются по куче и собирают мусор, что оказывает сильное давление на GC, что может и приводит к паузам GC даже в простых играх WebGL, если разработчик не перепрыгнет через нелепо сложные обручи, чтобы избежать создания новых векторов во всех местах, где логично создавать новые векторы. Вы не можете иметь перегрузку операторов, поэтому у вас есть очень большие и некрасивые выражения для выполнения основных операций. Доступ к отдельным компонентам происходит медленно. Объекты изначально не упакованы и, следовательно, невероятно медленно помещаются в буфер вершин, если только вы не реализуете их как экземпляры Float32Array, что в настоящее время приводит в замешательство оптимизаторы V8 и SpiderMonkey. Я упоминал, что они переданы по ссылке? Доступ к отдельным компонентам происходит медленно. Объекты изначально не упакованы и, следовательно, невероятно медленно помещаются в буфер вершин, если только вы не реализуете их как экземпляры Float32Array, что в настоящее время приводит в замешательство оптимизаторы V8 и SpiderMonkey. Я упоминал, что они переданы по ссылке? Доступ к отдельным компонентам происходит медленно. Объекты изначально не упакованы и, следовательно, невероятно медленно помещаются в буфер вершин, если только вы не реализуете их как экземпляры Float32Array, что в настоящее время приводит в замешательство оптимизаторы V8 и SpiderMonkey. Я упоминал, что они переданы по ссылке?

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

г) Динамическая типизация. Да, я готов начать этот спор. Вы начинаете замечать это чаще всего, как только перестаете писать маленькие веб-приложения или веб-страницы и начинаете писать большие приложения, в которых у вас действительно есть данные, которые сохраняются дольше, чем один щелчок мыши или цикл запроса / ответа: добавьте неправильный тип объекта к массив для последующей обработки и последующий сбой из-за отсутствующего метода или члена в совершенно ином фрагменте кода, чем там, где была настоящая ошибка. Веселые времена. Да, Java заставляет статическую типизацию казаться злой. Нет, Java / C # / C ++ - не единственный способ статической типизации. Вывод типа, неявная привязка интерфейса и т. Д. Дают вам все преимущества «простой в обращении и не много нажатий клавиш» динамической типизации без всех ошибок. Фактически, второй по популярности веб-язык - ActionScript 3 - статически типизирован, хотя в остальном он идентичен JS / ECMAScript. Кроме того, я получаю больше сбоев от приложений Python на моем рабочем столе Fedora, чем от приложений C / C ++ (на самом деле, ни одно из приложений C / C ++ на моем рабочем столе не работает, теперь, когда я об этом думаю). Отсутствие исключений для членов == так проще разрабатывать и поддерживать приложения, верно?

з) скорость. Да, большое количество разработчиков с очень плохой задницей приложило немало смехотворных усилий для того, чтобы сделать JS почти наполовину быстрее, чем компилятор с низким классом C, который мог бы написать один колледж Junior за несколько лет. месяцы. И LuaJIT находится в той же лодке, что и JS с точки зрения фундаментальных языковых ограничений, но в любом случае ему удается работать лучше, чем любая реализация JavaScript. Люди, которые не понимают, что на самом деле делают все JS-оптимизации в V8Я хотел бы заявить, что JS может делать удивительные вещи по скорости, но реальность такова, что все эти оптимизации в основном просто «очень-очень стараются проанализировать код, чтобы выяснить типы для переменных, а затем скомпилировать его, как слегка отсталый статически типизированный компилятор языка сделает это ". Да, и есть трассировка, но затем трассировка также работает на статически типизированных языках (и работает лучше из-за отсутствия необходимости в средствах защиты типов в сгенерированном машинном коде). На самом деле, ни одна из этих оптимизаций whizbang не была изобретена JS или для нее; большинство было взято из исследовательских JVM (Java - это зло!) или классических ООП-языков (прототипы потрясающие!).

я) IntelliSense даже не возможно. Хотите посмотреть, какие методы существуют для этой переменной, которая есть в строке 187 файла foo.js в вашем текстовом редакторе? Печалька. Проследите код, пока не выясните, где он был инициализирован, затем проследите код, чтобы выяснить, что на нем находится его прототипом. И потом надеюсь, что нет кода, динамически изменяющего прототип за вашей спиной. На самом деле, просто запустите его в браузере и установите точки останова, потому что узнать что-либо полезное о значении любым другим способом в принципе невозможно для любой базы кода больше, чем сайты toy_web_app.html, которые апологеты JavaScript используют для прославления простоты и простоты JavaScript. Некоторые редакторы кода очень стараются сделать лучше, и почти что-то вроде успеха получается в действительно простых случаях, иногда, однажды.

к) нет преимущества. JavaScript даже не особенный по сравнению с другим динамически типизированным языком. Он вообще не способен делать что-либо интересное, что также не может быть сделано Lua, Python, Ruby и т. Д. Ни одна из реализаций JS не является более быстрой, чем LuaJIT или PyPy или другие различные расширенные реализации JIT других динамических процессов. языки. У JS нет плюсов по сравнению с другими общедоступными языками. О, за исключением того, что он работает изначально в веб-браузере без плагина. Что является единственной причиной в мире, почему это так популярно. Фактически, это единственная причина, по которой событие существует, Если кто-то 10 лет назад только что подумал: «Черт, давайте добавим в наш браузер хорошо продуманный и хорошо зарекомендовавший себя язык и заставим других делать то же самое, вместо того, чтобы заставлять всех использовать этот маленький глупый хакджоб, который придумал NetScape». "Интернет будет выглядеть совсем иначе (лучше) сегодня. Представьте себе будущее, если Chrome поместит Python в Chrome как поддерживаемый язык. Или на самом деле, представьте себе: Google добавляет C / C ++ в Chrome как поддерживаемый язык (http://code.google.com/p/nativeclient/).

Почему?

JavaScript - самый неправильно понятый язык

Мы были в мрачной эпохе и до сих пор общему сообществу разработчиков признаем, что JavaScript - это мощный и универсальный язык. Это просто не мейнстрим.

Единственным недавним достижением является то, что node.js стал громким, и люди начинают понимать, что javascript имеет иное применение.

Я следил за разработкой JS & HTML5 для Windows 8, и реакция сообщества .NET была «Боже, почему?».

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

По общему признанию JavaScript не соответствует "современным методам разработки". Для меня JavaScript по-прежнему хакерский язык, который я использую с помощью vim, а интернет - моя документация. Здесь нет IDE, нет инструментов разработки, нет автозаполнения или "intellisense", нет графического интерфейса для перетаскивания.

В мире разработчиков Java и .NET они встроены в свои графические интерфейсы и IDE и не смогут программировать в vim.

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

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

Зачем писать акры JS для записи файла, когда это тривиальная операция в Java / .NET / C / C ++?

С учетом вышесказанного, как уже упоминали другие, node.js и его библиотеки сделали операции на стороне сервера тривиальными, и с ростом популярности node.js его изучение станет навыком для CV, поскольку вы сможете поддерживать / расширять / строить приложения с этим.

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

Я не говорю об этом, чтобы избавиться от JavaScript. Мне очень нравится работать с JS при разработке веб-приложений. Но если посмотреть объективно, у JS есть ряд недостатков по сравнению с другими языками:

• Многочисленные неустранимые недостатки. Многие ошибки были допущены при первоначальной разработке JS. Не нужно перечислять их здесь, они хорошо документированы. Все языки имеют ошибки в первоначальном дизайне, которые позже исправляются. Разница с JS заключается в том, что язык был разработан и выпущен далеко не быстро, и эти ошибки никогда не могут быть исправлены из-за требования обратной совместимости в браузерах.
• Чрезвычайно медленный процесс внедрения улучшений и новых функций. Поскольку все поставщики браузеров должны согласиться и даже по разным политическим причинам хотят замедлить развитие языка. Посмотрите на C #, который на самом деле является более новым языком, чем JS. Когда C # был представлен, у него не было, например. замыкания или функции более высокого порядка, такие как JS, но после нескольких итераций теперь у него есть все это и, кроме того, такие функции, как Linq и асинхронный синтаксис, которым разработчики JavaScript могут только позавидовать.
• Обедневшая стандартная библиотека. Современные языки, такие как Python, Ruby или любые другие, основанные на Java или .net, имеют обширные стандартные библиотеки практически для всего, что вам может понадобиться. В JS вы даже не можете прочитать файл без сторонних библиотек. Вы упоминаете Regex, но все современные языки имеют это и еще тысячи вещей.
• Другие языки догнали несколько преимуществ JavaScript. Такие функции, как замыкания и первоклассные функции, были мощными по сравнению с неуклюжими статическими языками, такими как Java, десять лет назад, но динамические и функциональные языки уже давно имеют эти функции, и даже Java, довольно консервативный язык, добавил это в Java 8.

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

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