Pull to refresh

Почему я не верю в Dart

Reading time 4 min
Views 8.6K
Признаться, сообщение о разработке в Google языка Dart я встретил с недоумением. Если coffeescript и прочие надстройки я считал просто чьим-то развлечением на досуге, то к Dart-у при всём желании не получается относиться как просто ещё к одной гиковской игрушке.

Сегодняшний пост про грядущее господство Дарта подтолкнул меня к тому, чтобы ясно сформулировать, наконец, почему я считаю Дарт всё равно просто гиковской игрушкой и в чем неправа корпорация Google. Начну, пожалуй, с цитаты:

«Нужна полная замена JS — язык широкого профиля: от простых скриптов, для сложных приложений»

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



В JavaScript есть некоторые очевидные досадные недоработки, типа объявления глобальной переменной без var, дурацкая таблица сравнений или отсутствие for… each. Положа руку на сердце, это вовсе не смертельные недостатки для языка программирования. Главная проблема JavaScript — это малая распространенность прототипного объектно-ориентированного программирования в противовес «классовому» объектно-ориентированному программированию. Стремление сделать из JavaScript «нормальный» язык приводит к каким-то монструозным конструкциям и полностью отбивает желание с ним работать. Стоит отказаться от классовой парадигмы — и работа с JavaScript становится лёгкой и приятной.

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

Я с недоумением отношусь к подобного рода утверждениям:

Но при написании приложений по прежнему остаются определённые проблемы: необходимость без классов/типизации писать приложения можно, но сложно — многие средства, которые позволяют той же Java иметь производительные VM и умные IDE не применимы к JS.


Писать приложения на прототипах ничуть не сложнее, чем на классах, а уж умных IDE для JS уже вагон написан — WebStorm, NetBeans, Eclipse, Comodo, Aptana. WebStorm вполне справляется с такими нетривиальными для JS задачами, как перейти к декларации метода или провести рефакторинг интерфейса класса.

Попробуем внимательно разобрать аргументацию собственно Гугла в пользу замены JavaScript:

Dash is designed with three perspectives in mind:

— Performance — Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have.

— Developer Usability — Dash is designed to keep the dynamic, easy-to-get-started, no-compile nature of Javascript that has made the web platform the clear winner for hobbyist developers.

— Ability to be Tooled — Dash is designed to be more easily tooled (e.g. with optional types) for large-scale projects that require code-comprehension features such as refactoring and finding callsites.

Dash, however, does not require tooling to be effective--small-scale developers may still be satisfied with a text editor.


1. Производительность. Здесь, признаться, аргументация гугла выглядит просто нелепой. Серверный V8 уж точно никак не медленнее Python, который используется в GAE; мне как-то не приходят в голову динамические интерпретируемые языки, которые были бы производительнее V8 JavaScript. Те, кто пытался использовать JS на серверах, скажут вам, что главная проблема V8 — стабильность работы, а вовсе не производительность. Думается, что Гугл мог бы легко допилить V8 до нормального стабильного серверного скриптового языка, но не делает этого. Почему?

Главное же, что меня удивляет в пассаже про производительность JavaScript — это то, что Гугл отлично понимает, что главное — инфраструктура, а не производительность языка. Вспомните, как представители гугла смеялись над Майкрософтом. Секрет производительности гугла — в файловой системе и datastore, а вовсе не в производительности используемых языков программирования. Node.js со своей асинхронной природой, казалось бы, идеально подходит к гугловой архитектуре.

2. Юзабилити. Этот аргумент вообще выше моего понимания — Гугл собирается создать Dart таким же удобным, как JavaScript — так чем в этом месте не устраивает JavaScript?

Что, Dart прост и очевиден для начинающих? Ха-ха три раза. Я смотрю на вот этот туториал:
class Greeter implements Comparable {
  String prefix = 'Hello,';
  Greeter() {}
  Greeter.withPrefix(this.prefix);
  greet(String name) => print('$prefix $name');

  int compareTo(Greeter other) => prefix.compareTo(other.prefix);
}

И он не производит впечатления простоты и понятности. Да, прикольные плюшки, но явно непривычные и нечитаемые для начинающих программистов.

3. Фреймворки. Как я уже писал, тот же WebStorm прекрасно справляется с рефакторингом JS-кода; в любом случае, разработать собственный фреймворк, удобно поддающийся рефакторингу, и добиться его поддержки в IDE — гораздо проще, чем продвинуть язык на замену JavaScript.

Итак, получается, что Dart может быть «лучше» JavaScript только в одном компоненте — он классический классовый объектно-ориентированный язык программирования, а не прототипный. Возможно, с точки зрения далеко идущих планов гугла и лучше, чтобы все языки были похожи друг на друга; с моей — нет, не надо без нужды увеличивать энтропию.

Мне кажется, что задача гугла при внедрении Dart состоит ровно в одном — привязать всю веб-разработку к своему языку, своей платформе и своему фреймворку. Напомню: гугл отлично знает, что главное — инфраструктура, а не язык; поставляя язык «из коробки» вместе со своими инструментами и фреймворками, гугл пересаживает разработчиков на свою инфраструктуру. Никаких объективных причин искать замену JavaScript у гугла просто нет.

Впрочем, исходя из бритвы Хэнлона, можно и предположить, что некая инициативная группа в составе гугла просто не понимает прототипную парадигму и стремится навязать взамен классовую. Тоже не исключено.
Tags:
Hubs:
+100
Comments 435
Comments Comments 435

Articles