Комментарии 182
Что по этому поводу думают Microsoft, Apple, Mozilla?
Apple подаст в суд за плагиат)
«Dart — один из многих языков, которые компилируются в Javascript, и этим многое сказано. Я не думаю, что Dart станет родным для браузеров» сказал в январе 2012 Eich, CEO Mazilla.
это было в начале 12 года, где Dart еще не выигрывал js в показателях… если Dart не станет мейнстримом, то ничего не изменится в отношении js
Я может упускаю что-то, но как он может стать мейнстримом, если его не будет в мейнстриме «браузеров» (одного хрома мало)?
Очень просто, он компилируется в JavaScript и дефакто уже сейчас поддерживается всеми браузерами. При этом фичи в него внедрять легче и быстрее чем в JavaScript, т.к. Dart не зависит от реализации его в браузерах.
Если честно, то мы неправильно рассматриваем браузеры: нам нужно смотреть не на браузер, а на движок!
Если движок WebKit, в котором как компонент присутствует JavaScriptCore, добавляет в себя транслятор или VM (а гугл в числе разработчиков этого WebKit), то Дарт будет практически везде. Начиная от наших любимых Хрома и Оперы и заканчивая всякой гадостью типа Интернет@ mail.ru и Яндекс.Браузер (а вот последние 2 браузера особенно играют роль в том плане, что обыкновенный юзер случайно его установил, а вот удалить уже никак… придется пользоваться… — что-то типа «одно неловкое движение и у вас ЯндексБар!»)!
А вот насчет IE у меня сомнения)))
Если движок WebKit, в котором как компонент присутствует JavaScriptCore, добавляет в себя транслятор или VM (а гугл в числе разработчиков этого WebKit), то Дарт будет практически везде. Начиная от наших любимых Хрома и Оперы и заканчивая всякой гадостью типа Интернет@ mail.ru и Яндекс.Браузер (а вот последние 2 браузера особенно играют роль в том плане, что обыкновенный юзер случайно его установил, а вот удалить уже никак… придется пользоваться… — что-то типа «одно неловкое движение и у вас ЯндексБар!»)!
А вот насчет IE у меня сомнения)))
Никакой язык другой не станет родным, но достаточно будет внедрить asm.js в браузеры и можно будет смело реализовывать для браузеров какие угодно языки не уступающие в производительности JS.
Не совсем понятно, как asm.js поможет реализовывать «какие угодно языки». Прежде всего он ограничен в семантике самим JavaScript. Допустим хотите вы в свой язык добавить эффективный
Далее даже в рамках JS asm.js ограничен фактически арифметикой и работой с typed arrays. Иными словами, если вам допустим хочется реализовать язык со сборкой мусора, вам нужно реализовать сборщик мусора на asm.js. Попробуйте теперь с таким сборщиком мусора потягаться с GC встроенным в JS VM (который часто весь из себя параллельный и написан на вылизанном C++). Тоже самое относится к другим частям динамического языка: многие части реализации для пиковой производительности нуждаются с достаточно низкоуровневых примитивах, а asm.js не позволяет вам ни получить доступ к таким примитивам, ни опереться на реализацию JS VM, которая уже использует эти примитивы для оптимизации самого JS (как пример: inline caches для оптимизации доступа к полям).
int64 или simd тип… JS нативно такого не поддерживает, как результат нужно сидеть и ждать пока TC-39 пропихнет такие типы в стандарт JS и пока их правильно и оптимально поддержат во всех реализациях.Далее даже в рамках JS asm.js ограничен фактически арифметикой и работой с typed arrays. Иными словами, если вам допустим хочется реализовать язык со сборкой мусора, вам нужно реализовать сборщик мусора на asm.js. Попробуйте теперь с таким сборщиком мусора потягаться с GC встроенным в JS VM (который часто весь из себя параллельный и написан на вылизанном C++). Тоже самое относится к другим частям динамического языка: многие части реализации для пиковой производительности нуждаются с достаточно низкоуровневых примитивах, а asm.js не позволяет вам ни получить доступ к таким примитивам, ни опереться на реализацию JS VM, которая уже использует эти примитивы для оптимизации самого JS (как пример: inline caches для оптимизации доступа к полям).
Авторы asm.js планируют внедрить сборку мусора: habrahabr.ru/post/171561/.
Я знаю. К сожалению, нигде не написано каким именно образом они это планируют. Основная проблема заключается в том, что непонятно каким образом «аннотировать» переменные составных / ссылочных типов. Для примитивных числовых типов они полагаются на coercions, а уже со строками возникает проблема. Аннотация в форме
Моя позиция по отношению к asm.js проста: развивайте или JIT, или нормальные языковые средства (например, аннотации типов или статически типизированный байткод), или и то и другое вместе, но ради бога не нужно пытаться просунуть слона через игольное ушко под видом нитки.
""+a выглядит весьма сюрреалистично. Моя позиция по отношению к asm.js проста: развивайте или JIT, или нормальные языковые средства (например, аннотации типов или статически типизированный байткод), или и то и другое вместе, но ради бога не нужно пытаться просунуть слона через игольное ушко под видом нитки.
НЛО прилетело и опубликовало эту надпись здесь
Могу ошибаться, но по моим ощущениям, Microsoft об это думает две вещи: ES6 и TypeScript.
Недавно встретил в книжном магазине Лондона:
Автор книжки сейчас активно постит в своем блоге всякие эксперименты с Dart-ом.
И все равно Dart без JS существовать не сможет???
Сможет, почему б не смочь.
Транслятор в джаваскрипт ему нужен, чтобы браузеры, не поддерживающие Dart нативно, смогли корректно отображать страницы с Dart.
Транслятор в джаваскрипт ему нужен, чтобы браузеры, не поддерживающие Dart нативно, смогли корректно отображать страницы с Dart.
В настоящее время предполагается два способа исполнения Dart-программ:
— с использованием VM
— с промежуточной трансляцией в javascript
я имел в виду, что без js дело не обойдется, если только VM не будет устанавливаться неявно в каждом браузере, а не только браузерах от google
— с использованием VM
— с промежуточной трансляцией в javascript
я имел в виду, что без js дело не обойдется, если только VM не будет устанавливаться неявно в каждом браузере, а не только браузерах от google
Джаву в браузерах это не остановило. Плагин Дарта спасет отца русской демократии.
Пока Гугл не докажет, что без этого никуда, браузеры с места не рыпнутся… Хотя может я и ошибаюсь
А зачем ему это доказывать? Большой брат на столько большой, что может не смотреть на остальных. Просто возьму и добавят в Chome.
Просто гугл выпустит плагины поддержки Dart к Firefox и IE. Технически это несложно, хотя домохозяек жалко.
Домохозяйки уже и так на Chome сидят. Наблюдаю вокруг этот процесс и только диву даюсь. Пиар чего либо через этого гиганта влияет даже на домохозяек.
Где это вы таких продвинутых домохозяек видите, если не секрет? Все домохозяйки с которыми я сталкивался пользовались FireFox, или, в особо запущенном случае, IE.
Да вот наблюдаю ситуацию вокруг. Как ни крути для многих обычных пользователей «поисковик» и «интернет» синонимы. Стоит только убрать из стартовой страницы поиск и у людей стопор «нет интернета». И когда этот поисковик говорит им, юзайте вот этот клевый браузер от нас, а знакомые it-шники подтверждают, что браузер то действительно хороший, то они таки начинают его использовать. Уже не говоря о ситуации когда эти самый it-шники изначально ставят пользователю этот браузер.
За аналогами ходить далеко не нужно. Давайте вспомним, где был android каких нибудь 5 лет назад. Малоюзабельная игрушка от гугла. Но он платформу двигал и развивал. И таки отхватил довольно приличный кусок мобильного пирога. В тот момент когда контора решит, что новый язык готов к внедрению в массы он будет массово внедрен. И совершенно не важно, хотим мы этого или нет.
За аналогами ходить далеко не нужно. Давайте вспомним, где был android каких нибудь 5 лет назад. Малоюзабельная игрушка от гугла. Но он платформу двигал и развивал. И таки отхватил довольно приличный кусок мобильного пирога. В тот момент когда контора решит, что новый язык готов к внедрению в массы он будет массово внедрен. И совершенно не важно, хотим мы этого или нет.
Яндекс браузер они используют. А фаерфокс используют молодешь, которая его давно юзала. Как и оперу.
Ну так это просто.
Гуглу нужно только сказать всем, что он делает +1 к PageRank для всех страниц с кодом на Dart'е внутри.
Через неделю (максимум) 90% сайтов будут использовать Dart.
:)
Гуглу нужно только сказать всем, что он делает +1 к PageRank для всех страниц с кодом на Dart'е внутри.
Через неделю (максимум) 90% сайтов будут использовать Dart.
:)
Если гугл сможет продемонстрировать какие-то супер-возможности доступные при наличии поддержки dart (но не имеющие аналогов в других технологиях) — то dart сможет (пусть и не сразу) стать компонентом по умолчанию в других браузерах. Ну и карма гугла как высокотехнологичной компании несомненно поспособствует популяризации.
Темной стороны язык этот, изучать его не думаю я
Разве видите вы что-то плохое в силе стороны тёмной?
Подтверждаю.
dart
darth
Know the difference!
darth
Know the difference!
НЛО прилетело и опубликовало эту надпись здесь
Ждем исследований и откровений, как именно Dart приведет Google к мировому господству.
Товарищи, да пусть будет Dart. Если например писать на ClojureScript то становится совершенно до фени, что там работает в качестве бэкенда (платформы).
НЛО прилетело и опубликовало эту надпись здесь
Крупные клиентские приложения будет определенно писать удобнее на Dart или похожем по идеологии языке. Ведь язык предоставляет статическую типизацию, контроль типов на этапе компиляции и нормальную модульную систему. Он также имеет свою VM и официальные модули, с помощью которых Dart можно использовать как ассинхронный сервер Backend (по типу node.js), при этом он быстрее V8.
Главное чтобы Google не бросил Dart, как бросал многие свои проекты.
Главное чтобы Google не бросил Dart, как бросал многие свои проекты.
Не знаю, кто и почему так считает.
JS медленнее сопоставимого C-кода примерно в 2-5 раз, никто с этим не спорит (соответственно, заявленные цифры для Дарта выглядят правдоподобно). Однако это верно для любых других динамически типизируемых языков со сборкой мусора, однако ж никто вроде не собирается хоронить Python и Ruby с пользу C# и Go. Редкое веб-приложение упирается в скорость работы js, а не рендеринга DOM и/или графики.
Google не забросит Dart, поскольку финальная цель — заменить JS и пересадить всех веб-разработчиков на свою инфраструктуру — обещает настолько крутые плюшки, что Google, очевидно будет форсить Дарт до упора.
JS медленнее сопоставимого C-кода примерно в 2-5 раз, никто с этим не спорит (соответственно, заявленные цифры для Дарта выглядят правдоподобно). Однако это верно для любых других динамически типизируемых языков со сборкой мусора, однако ж никто вроде не собирается хоронить Python и Ruby с пользу C# и Go. Редкое веб-приложение упирается в скорость работы js, а не рендеринга DOM и/или графики.
Google не забросит Dart, поскольку финальная цель — заменить JS и пересадить всех веб-разработчиков на свою инфраструктуру — обещает настолько крутые плюшки, что Google, очевидно будет форсить Дарт до упора.
Проблема JS не в скорости, я просто сравнил node.js и io модуль из Dart. Проблема JavaScript в самом языке, сказки про непонимание прототипной модели уже надоели, прототипы и отсутствие даже опционального контроля типов приводит к убогой поддержке JS в IDE. Если брать даже PHP, то и в том больше контроля над типами и кодом, можно например указать какого класса объекты нужно передавать в метод. Когда я смотрю на код в JS, я не понимаю, что передавать в функцию, надо лезть постоянно в документацию и благо к методу есть комментарии.
Что уж говорить, если в новый стандарт ECMAScript 6 хотят включить классы.
Что уж говорить, если в новый стандарт ECMAScript 6 хотят включить классы.
> Проблема JavaScript в самом языке, сказки про непонимание прототипной модели уже надоели
Интересно, в чём же состоят «сказки»; многие кодеры действительно не понимают прототипную модель.
> прототипы и отсутствие даже опционального контроля типов приводит к убогой поддержке JS в IDE
Попробуйте воспользоваться какой-нибудь нормальной IDE. Например, WebStorm.
> Когда я смотрю на код в JS, я не понимаю, что передавать в функцию, надо лезть постоянно в документацию и благо к методу есть комментарии.
Попробуйте посмотреть на какой-нибудь нормально написанный код. Если типы аргументов из кода неясны — этот код написан плохо, и аннотация типов не больно-то поможет.
> Что уж говорить, если в новый стандарт ECMAScript 6 хотят включить классы.
Движков «классов» для JS уже написано примерно вагона полтора без всякого ECMAScript 6, используйте любой, раз уж прототипы кажутся непонятными.
Интересно, в чём же состоят «сказки»; многие кодеры действительно не понимают прототипную модель.
> прототипы и отсутствие даже опционального контроля типов приводит к убогой поддержке JS в IDE
Попробуйте воспользоваться какой-нибудь нормальной IDE. Например, WebStorm.
> Когда я смотрю на код в JS, я не понимаю, что передавать в функцию, надо лезть постоянно в документацию и благо к методу есть комментарии.
Попробуйте посмотреть на какой-нибудь нормально написанный код. Если типы аргументов из кода неясны — этот код написан плохо, и аннотация типов не больно-то поможет.
> Что уж говорить, если в новый стандарт ECMAScript 6 хотят включить классы.
Движков «классов» для JS уже написано примерно вагона полтора без всякого ECMAScript 6, используйте любой, раз уж прототипы кажутся непонятными.
> Интересно, в чём же состоят «сказки»
Как IE нужен обычно для скачивания нормального браузера, так мне не попадался сколь-нибудь серьёзный проект, где прототипная модель использовалась бы иначе, чем для создания классоподобной системы. Ну и зачем тогда, спрашивается, вообще нужны эти прототипы?
> Попробуйте посмотреть на какой-нибудь нормально написанный код
node.js — это нормальный код? Но тут не только из кода, а даже из документации зачастую вообще непонятно, чего передавать в аргументах и как оформлять коллбэки. Вот например:
fs.read(fd, buffer, offset, length, position, callback)
Там в доках есть комментарии, но из них понятно далеко не всё. А теперь смотрим, что происходит при использовании TypeScript:
export function read(fd: string, buffer: NodeBuffer, offset: number, length: number, position: number, callback?: (err: Error, bytesRead: number, buffer: NodeBuffer) => void): void;
Ну совсем ведь другое дело! И для любого типа я могу «развернуть» его описание. Всё сразу как на ладони.
Как IE нужен обычно для скачивания нормального браузера, так мне не попадался сколь-нибудь серьёзный проект, где прототипная модель использовалась бы иначе, чем для создания классоподобной системы. Ну и зачем тогда, спрашивается, вообще нужны эти прототипы?
> Попробуйте посмотреть на какой-нибудь нормально написанный код
node.js — это нормальный код? Но тут не только из кода, а даже из документации зачастую вообще непонятно, чего передавать в аргументах и как оформлять коллбэки. Вот например:
fs.read(fd, buffer, offset, length, position, callback)
Там в доках есть комментарии, но из них понятно далеко не всё. А теперь смотрим, что происходит при использовании TypeScript:
export function read(fd: string, buffer: NodeBuffer, offset: number, length: number, position: number, callback?: (err: Error, bytesRead: number, buffer: NodeBuffer) => void): void;
Ну совсем ведь другое дело! И для любого типа я могу «развернуть» его описание. Всё сразу как на ладони.
> так мне не попадался сколь-нибудь серьёзный проект, где прототипная модель использовалась бы иначе, чем для создания классоподобной системы.
Ну, мы в API Я.Карт не используем никаких классовоподобных фреймворков, только свои врапперы над augment/extend
> node.js — это нормальный код?
Нормальный код, но плохой пример. Node.js очень низкоуровневый фреймворк, его интерфейсы плохо понятны без документации, независимо от наличия/отсутствия типизации.
> Но тут не только из кода, а даже из документации зачастую вообще непонятно, чего передавать в аргументах и как оформлять коллбэки. Вот например: fs.read(fd, buffer, offset, length, position, callback)
И вам неясно, какие типы у аргументов? о_О
А что тут можно истолковать двояко?
> А теперь смотрим, что происходит при использовании TypeScript: export function read(fd: string, buffer: NodeBuffer, offset: number, length: number, position: number, callback?: (err: Error, bytesRead: number, buffer: NodeBuffer) => void): void; Ну совсем ведь другое дело! И для любого типа я могу «развернуть» его описание. Всё сразу как на ладони.
Правда? И что же оказалось, как на ладони? Как было неясно, что fd — это файловый дескриптор, который надо получать через open, так и осталоссь неясным, и даже ещё больше запуталось, поскольку указание типа String у файлового дескриптора попросту лишнее, какая разница, что он из себя представляет.
Ну, мы в API Я.Карт не используем никаких классовоподобных фреймворков, только свои врапперы над augment/extend
> node.js — это нормальный код?
Нормальный код, но плохой пример. Node.js очень низкоуровневый фреймворк, его интерфейсы плохо понятны без документации, независимо от наличия/отсутствия типизации.
> Но тут не только из кода, а даже из документации зачастую вообще непонятно, чего передавать в аргументах и как оформлять коллбэки. Вот например: fs.read(fd, buffer, offset, length, position, callback)
И вам неясно, какие типы у аргументов? о_О
А что тут можно истолковать двояко?
> А теперь смотрим, что происходит при использовании TypeScript: export function read(fd: string, buffer: NodeBuffer, offset: number, length: number, position: number, callback?: (err: Error, bytesRead: number, buffer: NodeBuffer) => void): void; Ну совсем ведь другое дело! И для любого типа я могу «развернуть» его описание. Всё сразу как на ладони.
Правда? И что же оказалось, как на ладони? Как было неясно, что fd — это файловый дескриптор, который надо получать через open, так и осталоссь неясным, и даже ещё больше запуталось, поскольку указание типа String у файлового дескриптора попросту лишнее, какая разница, что он из себя представляет.
И что же оказалось, как на ладони?
Сигнатура коллбека?
> Ну, мы в API Я.Карт не используем никаких классовоподобных фреймворков
Я ради интереса даже пошел посмотреть как эта документация выгладит. Открыл
api.yandex.ru/maps/doc/jsapi/2.x/ref/reference/Balloon.xml
И обнаружил, что
Возникает вопрос. Зачем лукавим? Почему столь антагонистичны языку, который предлагает: вот настоящие классы, вот настоящие аннотации типов (которые заметим в той же самой документации на API откуда-то получились, причем скорее всего из комментариев, а не из кода). Хочется настоящее наследование, одинаковое во всех либах, а не на ручной тяге где смысл слова «расширяет» меняется от либы к либе — пожалуйста. И т.д.
Я ради интереса даже пошел посмотреть как эта документация выгладит. Открыл
api.yandex.ru/maps/doc/jsapi/2.x/ref/reference/Balloon.xml
И обнаружил, что
Balloon понимаешь ли «расширяет IDomEventEmitter». А если кликнуть на это, то дальше узнаем, что IDomEventEmitter он-то «расширяет IEventEmitter. интерфейс объекта, генерирующего „DOM-события“». т.е. вроде как классовоподобных фрейморков нет, а терминология имеется. Тут вам и конкретные объекты, и интерфейсы нарисовались, при том, что в самом-то JS никаких интерфейсов нет.Возникает вопрос. Зачем лукавим? Почему столь антагонистичны языку, который предлагает: вот настоящие классы, вот настоящие аннотации типов (которые заметим в той же самой документации на API откуда-то получились, причем скорее всего из комментариев, а не из кода). Хочется настоящее наследование, одинаковое во всех либах, а не на ручной тяге где смысл слова «расширяет» меняется от либы к либе — пожалуйста. И т.д.
> т.е. вроде как классовоподобных фрейморков нет, а терминология имеется.
Не «вроде как», а так и есть. Почему бы вдруг нам её не использовать?
> Зачем лукавим?
Никакого лукавства, просто я написал про одно (использование классовоподобных фреймворков, а ля Class.create из Prototype или Ext.class() из Sencha/ExtJS), а вы мне пишете про другое — накладывание дополнительных парадигм поверх языка.
Действительно, в JavaScript нет интерфейсов, но как это мешает нам придерживаться такой парадигмы? Мы рассматриваем интерфейсы как такой же паттерн программирования, как и, скажем, абстрактные фабрики (которых из коробки в JS тоже как бы нет).
Не «вроде как», а так и есть. Почему бы вдруг нам её не использовать?
> Зачем лукавим?
Никакого лукавства, просто я написал про одно (использование классовоподобных фреймворков, а ля Class.create из Prototype или Ext.class() из Sencha/ExtJS), а вы мне пишете про другое — накладывание дополнительных парадигм поверх языка.
Действительно, в JavaScript нет интерфейсов, но как это мешает нам придерживаться такой парадигмы? Мы рассматриваем интерфейсы как такой же паттерн программирования, как и, скажем, абстрактные фабрики (которых из коробки в JS тоже как бы нет).
Лукавство я вижу в том, что мы наворачиваем абстракции на голый JS (OOP эмуляция и/или терминология, типы в комментариях), потому что это нам помогает в разработке, но при этом когда нам предлагают язык, в котором ничего не нужно накручивать и все и так понятно и работает, мы говорим «фу, да зачем! можно же жить за уровнями эмуляции». Мне это непонятно.
Ну а я не вижу никакого лукавства.
При работе со сложной и распределённой предметной областью мы используем практически все доступные нам парадигмы. Ту часть, которая хорошо описывается как классы и интерфейсы — мы описываем как классы и интерфейсы. Где-то у нас есть и MVC-подобные структуры, фабрики и прочие паттерны, а где-то мы фактически работаем в терминах «описываем предметную область уот таким JSON-ом». JS позволяет это делать — использовать нужные парадигмы там, где это необходимо.
JS породил, пожалуй что, максимальное количество фреймворков со своей филосософией. Вот jQuery, в котором нет ни классов, ни прототипов, зато есть чайнинг и jQuery.fn.extend. Вот Node.js, опять же (почти) без классов и прототипов, но с полностью асинхронной парадигмой. Вот декларативные фреймворки, типа AngularJS. Вот полностью ОО-фреймворк Ext JS.
Вот эта гибкость и мультипарадигменность и есть основной плюс JS, именно поэтому он и стал lingua franca интернета. Dart же ограничен одной ОО-парадигмой.
Но я против Dart-а не поэтому — а потому, что он в чистом виде представляет собой попытку Гугла пересадить весь веб на его (Гугла) стек веб-технологий. А это плохо, независимо от достоинств и недостатков самого Дарта.
При работе со сложной и распределённой предметной областью мы используем практически все доступные нам парадигмы. Ту часть, которая хорошо описывается как классы и интерфейсы — мы описываем как классы и интерфейсы. Где-то у нас есть и MVC-подобные структуры, фабрики и прочие паттерны, а где-то мы фактически работаем в терминах «описываем предметную область уот таким JSON-ом». JS позволяет это делать — использовать нужные парадигмы там, где это необходимо.
JS породил, пожалуй что, максимальное количество фреймворков со своей филосософией. Вот jQuery, в котором нет ни классов, ни прототипов, зато есть чайнинг и jQuery.fn.extend. Вот Node.js, опять же (почти) без классов и прототипов, но с полностью асинхронной парадигмой. Вот декларативные фреймворки, типа AngularJS. Вот полностью ОО-фреймворк Ext JS.
Вот эта гибкость и мультипарадигменность и есть основной плюс JS, именно поэтому он и стал lingua franca интернета. Dart же ограничен одной ОО-парадигмой.
Но я против Dart-а не поэтому — а потому, что он в чистом виде представляет собой попытку Гугла пересадить весь веб на его (Гугла) стек веб-технологий. А это плохо, независимо от достоинств и недостатков самого Дарта.
Вот вы же замечательно иллюстрируете, зачем Dart нужен: называете кучу фреймворков и чество говорите, что объектные модели в них разные. (Даже в node.js, которая совсем почти не ОО есть util.inherits). Зачем? Какое в этом преимущество? Да никакого.
Нет, Dart представляет собой попытку предоставить разработчикам удобный инструмент разработки. Разработчик не цветок, который можно из одного горшка в другой пересадить лопаткой. Ему подавай преимущества и плюсы. Все остальное — это чистая конспирология из разряда «инопланетяне уже здесь, надевайте шапочку из фольги».
а потому, что он в чистом виде представляет собой попытку Гугла пересадить весь веб на его (Гугла) стек веб-технологий.
Нет, Dart представляет собой попытку предоставить разработчикам удобный инструмент разработки. Разработчик не цветок, который можно из одного горшка в другой пересадить лопаткой. Ему подавай преимущества и плюсы. Все остальное — это чистая конспирология из разряда «инопланетяне уже здесь, надевайте шапочку из фольги».
> Зачем? Какое в этом преимущество? Да никакого.
Вы не видите преимущества в возможности в рамках одной платформы использовать разные парадигмы или даже разные сочетания парадигм? Ну а я вижу. Я даже как-то про это высказывался:
habrahabr.ru/post/147896/
> Нет, Dart представляет собой попытку предоставить разработчикам удобный инструмент разработки.
Удобство, прямо скажем, весьма сомнительное. Дарт не блещет ни особой понятностью, ни удобством разработки. Единственное его «преимущество» — классово ориентированное ОО вместо прототипного.
> Все остальное — это чистая конспирология из разряда «инопланетяне уже здесь, надевайте шапочку из фольги».
Считайте как хотите.
Все инициативы Гугла типа «просто дать людям более удобный инструмент» нацелены на привязку пользователей к сервисам Гугла. См. Chrome, Android, YouTube, etc. Для меня очевидно, что и Dart сделан за тем же.
Вы не видите преимущества в возможности в рамках одной платформы использовать разные парадигмы или даже разные сочетания парадигм? Ну а я вижу. Я даже как-то про это высказывался:
habrahabr.ru/post/147896/
> Нет, Dart представляет собой попытку предоставить разработчикам удобный инструмент разработки.
Удобство, прямо скажем, весьма сомнительное. Дарт не блещет ни особой понятностью, ни удобством разработки. Единственное его «преимущество» — классово ориентированное ОО вместо прототипного.
> Все остальное — это чистая конспирология из разряда «инопланетяне уже здесь, надевайте шапочку из фольги».
Считайте как хотите.
Все инициативы Гугла типа «просто дать людям более удобный инструмент» нацелены на привязку пользователей к сервисам Гугла. См. Chrome, Android, YouTube, etc. Для меня очевидно, что и Dart сделан за тем же.
Я вижу преимущества в мультипарадигменности. Я не вижу преимуществ в том, чтобы каждая вторая библиотека изобретала свою собственную несовместимую эмуляцию одной и той же парадигмы под названием ОО. Это перевод бумаги.
Dart на мой взгляд не менее мультипарадигмен чем JavaScript. Я даже могу нарисовать prototype chain на Dart, представляете? Только отличие от JS в том, что наиболее часто используемая парадигма — обычное советсткое ОО с классами — нет нужды рисовать, оно уже встроено.
Можете привести пример «непонятности», так чтобы было менее понятно чем JS? Мне очень интересно.
Dart на мой взгляд не менее мультипарадигмен чем JavaScript. Я даже могу нарисовать prototype chain на Dart, представляете? Только отличие от JS в том, что наиболее часто используемая парадигма — обычное советсткое ОО с классами — нет нужды рисовать, оно уже встроено.
Дарт не блещет ни особой понятностью, ни удобством разработки.
Можете привести пример «непонятности», так чтобы было менее понятно чем JS? Мне очень интересно.
> Я не вижу преимуществ в том, чтобы каждая вторая библиотека изобретала свою собственную несовместимую эмуляцию одной и той же парадигмы под названием ОО.
Ну а я как разработчик проекта на несколько миллионов строк вижу очень много преимуществ в мультипарадигменности JS.
> Dart на мой взгляд не менее мультипарадигмен чем JavaScript. Я даже могу нарисовать prototype chain на Dart, представляете?
Попробуйте вот такой фокус на Дарт провернуть:
> Можете привести пример «непонятности», так чтобы было менее понятно чем JS? Мне очень интересно.
habrahabr.ru/post/130589/
Ну а я как разработчик проекта на несколько миллионов строк вижу очень много преимуществ в мультипарадигменности JS.
> Dart на мой взгляд не менее мультипарадигмен чем JavaScript. Я даже могу нарисовать prototype chain на Dart, представляете?
Попробуйте вот такой фокус на Дарт провернуть:
var DerivedClass = function () {
if (condition) {
BaseClass1.call(this);
} else {
BaseClass2.call(this);
};
> Можете привести пример «непонятности», так чтобы было менее понятно чем JS? Мне очень интересно.
Что, 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); }
И он не производит впечатления простоты и понятности.
habrahabr.ru/post/130589/
Я не вижу преимуществ в том, чтобы каждая вторая библиотека изобретала свою собственную несовместимую эмуляцию одной и той же парадигмы под названием ОО.Ну а я как разработчик проекта на несколько миллионов строк вижу очень много преимуществ в мультипарадигменности JS.
Заметьте: вы взяли одно предложение из моего комментария, а отвечаете на другое. Ответ на то предложение, которое вы взяли мог бы звучать так: «а я как разработчик проекта на несколько миллионов строк вижу очень много преимуществ в том, что у нас 10 разных эмуляций ОО в этих нескольких миллионах строк.»
Только ведь скорее всего это не так и вы обязаны использовать один единственный способ эмуляции ОО по внутреннему стандарту кодирования. Какой-нибудь
y.inherit.Попробуйте вот такой фокус на Дарт провернуть:
Было бы удобнее провернуть этот фокус, если бы вы объяснили конечную цель, конкретный пример использования. Потому что в зависимости от конечной цели я этот фокус по разному проворачивать буду. (Интересно еще пропустят ли вам такой код через ревью в ваш миллион строк и что будет написано в документации: расширяет один из классов в зависимости от фазы луны?).
Статическое приближение может выглядеть так:
class DerivedClass {
factory DerivedClass () {
return condition ? new _DerivedClass1() : _DerivedClass2();
}
}
class DerivedClassImpl { }
class _DerivedClass1 extends BaseClass1 with DerivedClassImpl
implements DerivedClass { }
class _DerivedClass2 extends BaseClass2 with DerivedClassImpl
implements DerivedClass { }
// new DerivedClass
динамическое приближение может выглядеть так:
class DerivedClass {
final base;
DerivedClass() : base = condition ? new BaseClass1() : new BaseClass2();
noSuchMethod(invocation) => reflect(base).delegate(invocation);
}
какое из приближений больше подходит по вашу конечную цель зависит от цели.
Я смотрю на вот этот туториал:
Давайте для начала уберем все фичи которые в JavaScript недоступны, оставив разве что интерполяцию, которая будет и в JavaScript в ES6.
class Greeter {
var prefix;
Greeter(prefix) { this.prefix = prefix; }
greet(name) {
print('$prefix $name');
}
}
понятно или непонятно? JavaScript код будет выглядеть а-ля
function Greeter(prefix) { this.prefix = prefix; }
Greeter.prototype.greet = function (name) { console.log(this.prefix + ' ' + name); };
какой код более явно говорит новичку: вот класс и вот метод? мне почему-то кажется, что первый. а потом можно шаг за шагам другие фичи накрутить (сокращенную запись конструкторов, именнованные конструкторы и тд).
| Нет, Dart представляет собой попытку предоставить разработчикам удобный инструмент разработки. Разработчик не цветок, который можно из одного горшка в другой пересадить лопаткой. Ему подавай преимущества и плюсы.
В таком случае лучше смотреть на TypeScript, который предлагает те же самые преимущества и нацелен на развитие JavaScript в web до ES6.
Dart же — это ещё один язык, который не несет никаких дополнительных преимуществ, лишь заставляет разработчиков учить ещё больше.
Меня и так уже тошнит от разнообразия языков, которые позволяют делать одно и то же.
В таком случае лучше смотреть на TypeScript, который предлагает те же самые преимущества и нацелен на развитие JavaScript в web до ES6.
Dart же — это ещё один язык, который не несет никаких дополнительных преимуществ, лишь заставляет разработчиков учить ещё больше.
Меня и так уже тошнит от разнообразия языков, которые позволяют делать одно и то же.
лучше смотреть на TypeScript, который предлагает те же самые преимущества и нацелен на развитие JavaScript в web до ES6
Во-первых, не все в TypeScript — это ES6. Основная фича — система типов, это не ES6.
Во-вторых, основываясь на JavaScript, вы JavaScript и получаете на выходе со всеми вытекающими семантическими прибамбасами. Кому-то иногда хочется честной чистой семантики, а не винегрета.
А так, конечно, что нравится, от чего не тошнит, то и следует использовать.
| Во-первых, не все в TypeScript — это ES6
Соглашусь, но при редакции черновиков ES6, корректируют и TypeScript для совместимости.
| система типов, это не ES6
Извините, не понял. Система классов появляется, о каких типах вы говорите?
Или вы про type hinting?
| Кому-то иногда хочется честной чистой семантики, а не винегрета.
Что вы имеете в виду, можно пример, а то я не понимаю. Просто, если взять вкусовщину, синтаксис Dart мне кажется в некоторых моментах — анархичным. Например объявление свойств класса:
Dart
class A {
int x;
A([this.x]);
}
и TypeScript
class A {
constructor (public x:number) {}
}
| А так, конечно, что нравится, от чего не тошнит, то и следует использовать.
Я немножко про другое говорил. :)
Меня тошнит что у нас в отрасли большое количество технологий и инструментов, которые друг-друга дублируют.
Соглашусь, но при редакции черновиков ES6, корректируют и TypeScript для совместимости.
| система типов, это не ES6
Извините, не понял. Система классов появляется, о каких типах вы говорите?
Или вы про type hinting?
| Кому-то иногда хочется честной чистой семантики, а не винегрета.
Что вы имеете в виду, можно пример, а то я не понимаю. Просто, если взять вкусовщину, синтаксис Dart мне кажется в некоторых моментах — анархичным. Например объявление свойств класса:
Dart
class A {
int x;
A([this.x]);
}
и TypeScript
class A {
constructor (public x:number) {}
}
| А так, конечно, что нравится, от чего не тошнит, то и следует использовать.
Я немножко про другое говорил. :)
Меня тошнит что у нас в отрасли большое количество технологий и инструментов, которые друг-друга дублируют.
Извините, не понял. Система классов появляется, о каких типах вы говорите?
Система типов из-за которой TypeScript называется TypeScript, а не просто ES6Script :-) Глава номер 3 в спецификации TypeScript называется Types и начинается словами
TypeScript adds optional static types to JavaScript. Types are used to place static constraints on program entities such as functions, variables, and properties so that compilers and development tools can offer better verification and assistance during software development.
Что вы имеете в виду, можно пример, а то я не понимаю.
Конечно, можно. Например, в Dart есть только одно значение, которое обозначает отсутствие чего-то —
null, а в JS их два null и undefined. Если я попробую обратится к полю, которого нет я получу исключение, а не undefined. Если я попробую прочитать за границей массива, я опять же получу исключение, а не undefined. Если я умножу null на 10, я не получу в тихую NaN, а опять же получу исключение. Иными словами там где JavaScript (и TypeScript) замалчивают ошибки (которые потом приведут к развалу в другом месте), Dart не замалчивает ничего. Ну а дальше семантические различия пошли. В Dart массив это массив, а не непонятно что (потенциально даже дырявое) и т.д.
синтаксис Dart мне кажется в некоторых моментах — анархичным
Мне не совсем понятно, что здесь анархичного. Может вы хотели сказать архаичным? Я бы не сказал, что
A(this.x); это совсем уж архаично. К тому же подход TypeScript для Dart не работает, потому что в Dart у класса может быть несколько конструкторов, поэтому лучше поля объявлять в теле класса, а не в сигнатуре конструктора.
которые друг-друга дублируют
Я бы не сказал, что Dart кого-то дублирует особо, ни как язык, ни как платформа.
| Глава номер 3 в спецификации TypeScript
Спасибо, значит все же type hinting. И если мы уберем из TS «статическу» типизацию, то получим ES6. Что как раз очень правильно в плане обучаемости программистов (не плодим новых сущностей и выигрываем)
| Конечно, можно. Например, в Dart есть только одно значение, которое обозначает отсутствие чего-то — null, а в JS их два null и undefined.
На сколько я понимаю Dart в случаях когда в JS возвращается undefind, генерируется исключение. Но в TS в этих случаях транслятор выбрасывает предупреждение. В таком случае, TS нивелирует, частично, эту семантическую проблему JS.
| Глава номер 3 в спецификации TypeScript
Спасибо, значит все же type hinting. И если мы уберем из TS «статическу» типизацию, то получим ES6. Что как раз очень правильно в плане обучаемости программистов (не плодим новых сущностей и выигрываем)
| Конечно, можно. Например, в Dart есть только одно значение, которое обозначает отсутствие чего-то — null, а в JS их два null и undefined.
На сколько я понимаю Dart в случаях когда в JS возвращается undefind, генерируется исключение. Но в TS в этих случаях транслятор выбрасывает предупреждение.
| Мне не совсем понятно, что здесь анархичного. Может вы хотели сказать архаичным? Я бы не сказал, что A(this.x); это совсем уж архаично.
Почему идентификатор экземпляра фигурирует в интерфейсе класса — это анархия, чистой воды.
Я полазил по документации и там, насильно втиснуто this в определения параметров методов и функций(normalFormalParameter). Я не особо то хорошо ориентируюсь в Dart, там можно указывать в функциях в качестве параметра функции свойство экземпляра? Если нет, то косяк в синтаксисе.
| Я бы не сказал, что Dart кого-то дублирует особо, ни как язык
Т.е. он не создан, что бы быть заменой JS?
| ни как платформа.
Не знаю вообще про это ничего, поэтому говорить не буду.
Спасибо, значит все же type hinting. И если мы уберем из TS «статическу» типизацию, то получим ES6. Что как раз очень правильно в плане обучаемости программистов (не плодим новых сущностей и выигрываем)
| Конечно, можно. Например, в Dart есть только одно значение, которое обозначает отсутствие чего-то — null, а в JS их два null и undefined.
На сколько я понимаю Dart в случаях когда в JS возвращается undefind, генерируется исключение. Но в TS в этих случаях транслятор выбрасывает предупреждение. В таком случае, TS нивелирует, частично, эту семантическую проблему JS.
| Глава номер 3 в спецификации TypeScript
Спасибо, значит все же type hinting. И если мы уберем из TS «статическу» типизацию, то получим ES6. Что как раз очень правильно в плане обучаемости программистов (не плодим новых сущностей и выигрываем)
| Конечно, можно. Например, в Dart есть только одно значение, которое обозначает отсутствие чего-то — null, а в JS их два null и undefined.
На сколько я понимаю Dart в случаях когда в JS возвращается undefind, генерируется исключение. Но в TS в этих случаях транслятор выбрасывает предупреждение.
| Мне не совсем понятно, что здесь анархичного. Может вы хотели сказать архаичным? Я бы не сказал, что A(this.x); это совсем уж архаично.
Почему идентификатор экземпляра фигурирует в интерфейсе класса — это анархия, чистой воды.
Я полазил по документации и там, насильно втиснуто this в определения параметров методов и функций(normalFormalParameter). Я не особо то хорошо ориентируюсь в Dart, там можно указывать в функциях в качестве параметра функции свойство экземпляра? Если нет, то косяк в синтаксисе.
| Я бы не сказал, что Dart кого-то дублирует особо, ни как язык
Т.е. он не создан, что бы быть заменой JS?
| ни как платформа.
Не знаю вообще про это ничего, поэтому говорить не буду.
Что как раз очень правильно в плане обучаемости программистов
И неправильно, как я уже заметил, если мы хотим получить новую вычищенную семантику.
Но в TS в этих случаях транслятор выбрасывает предупреждение
Да ну? Транслятор может статически определить, когда вы выходите за границы массива или случайно передаете
nullв какую-то функцию? Я уж не говорю о том, что вы можете забыть что-то типизировать и тогда у вас там будет
Any, про который транслятор ничего не знает.Почему идентификатор экземпляра фигурирует в интерфейсе класса
В Dart это (как и в CoffeeScript) сокращенная запись для
A(x) { this.x = x; } иначе конструкторы будут много boilerplate кода содержать, который будет только и делать, что копировать параметры в поля.Т.е. он не создан, что бы быть заменой JS?
Зависит от того, как вы понимаете слово «замена».
Он создан для того, чтобы его могли использовать там где сейчас используют JavaScript и при этом иметь определенные удобства, которых JavaScript лишен.
Понятие «дублирует» обычно подразумевает определенную эквивалентность, однако Dart и JavaScript не эквивалентны в семантическом плане. Если бы они были эквивалентны, то Dart бы не был лучше, чем JavaScript.
| И неправильно, как я уже заметил, если мы хотим получить новую вычищенную семантику.
При чем тут семантика и кривая обучаемости?
| В Dart это (как и в CoffeeScript) сокращенная запись для A(x) { this.x = x; } иначе
Т.е. семантика тут вообще «сумашедшая»?
| Он создан для того, чтобы его могли использовать там где сейчас используют JavaScript и при этом иметь определенные удобства, которых JavaScript лишен.
Дублирование в том контексте, который описал я, это использование в одних и тех же условиях для одного и той же задачи. Dart хочет быть заменой JS с более приятным для программиста свойствами.
При чем тут семантика и кривая обучаемости?
| В Dart это (как и в CoffeeScript) сокращенная запись для A(x) { this.x = x; } иначе
Т.е. семантика тут вообще «сумашедшая»?
| Он создан для того, чтобы его могли использовать там где сейчас используют JavaScript и при этом иметь определенные удобства, которых JavaScript лишен.
Дублирование в том контексте, который описал я, это использование в одних и тех же условиях для одного и той же задачи. Dart хочет быть заменой JS с более приятным для программиста свойствами.
Басня про рака, лебедя и щуку… Это скорее минус, чем плюс. Я например, когда собираюсь что-то писать на JS, выбираю несколько библиотек, каждая из которых выполняет свою задачу. Огромная проблема, что одна наворотила собственный oop-фреймворк, другая использует чистые прототипы, у другой особенный способ модулизации, и так до бесконечности. В итоге выходит какой-то франкенштейн.
Вы так спорите, будто Гугл сейчас почитает ваши комментарии и решит, стоит ли дальше развивать Dart. Просто появился новый язык. Это и не плохо, и не хорошо. Просто оно так есть. Это же прогресс.
так мне не попадался сколь-нибудь серьёзный проект, где прототипная модель использовалась бы иначе, чем для создания классоподобной системы. Ну и зачем тогда, спрашивается, вообще нужны эти прототипы?
Если не ошибаюсь, то например в Angular.js для создания дочернего scope используются прототипы. Думаю на нем уж точно есть серьезные проекты.
Прототипы иногда бывают очень удобными.
Я хочу ограничить передачу в метод или функцию по типу или классу. Что я для этого должен делать в JS? На каждом чихе расставлять проверки внутри функций на приходящие данные, пришел массив
Многие кодеры используют классовую модель, следовательно все обертки над прототипной моделью будут работать медленнее, чем чистый прототипный код, из-за проверок в runtime. Dart избавляет нас от этой проблемы, т.к. все проверки он выполняет в compile-time, поэтому классы в Dart работают ни-чуть не медленнее прототипов в JS.
{x: 10, y: 20} или объект Point(x: 10, y: 20), а может позволить функции обрабатывать и то и другое? Писать на каждый такой чих юнит-тест, который проверяет такие базовые вещи? И постоянно испытывать дискомфорт от того, что где-то забыл вставить проверку на приходящий параметр в функцию.Многие кодеры используют классовую модель, следовательно все обертки над прототипной моделью будут работать медленнее, чем чистый прототипный код, из-за проверок в runtime. Dart избавляет нас от этой проблемы, т.к. все проверки он выполняет в compile-time, поэтому классы в Dart работают ни-чуть не медленнее прототипов в JS.
> Я хочу ограничить передачу в метод или функцию по типу или классу. Что я для этого должен делать в JS? На каждом чихе расставлять проверки внутри функций на приходящие данные, пришел массив {x: 10, y: 20} или объект Point(x: 10, y: 20), а может позволить функции обрабатывать и то и другое? Писать на каждый такой чих юнит-тест, который проверяет такие базовые вещи? И постоянно испытывать дискомфорт от того, что где-то забыл вставить проверку на приходящий параметр в функцию.
В чистом JS — ничего. Динамически типизируемые языки — для тех, кто не испытывает дискомфорт от отсутствия явных указаний типов.
> Многие кодеры используют классовую модель, следовательно все обертки над прототипной моделью будут работать медленнее, чем чистый прототипный код, из-за проверок в runtime.
А многие не используют, пишут на Pure JS и не испытывают никаких проблем.
Я не совсем понимаю, какое имеет к теме обсуждения ваше неприятие прототипных динамически типизируемых языков. Чистый JS может быть использован для написания масштабных проектов, несмотря на ваше неприятие.
В чистом JS — ничего. Динамически типизируемые языки — для тех, кто не испытывает дискомфорт от отсутствия явных указаний типов.
> Многие кодеры используют классовую модель, следовательно все обертки над прототипной моделью будут работать медленнее, чем чистый прототипный код, из-за проверок в runtime.
А многие не используют, пишут на Pure JS и не испытывают никаких проблем.
Я не совсем понимаю, какое имеет к теме обсуждения ваше неприятие прототипных динамически типизируемых языков. Чистый JS может быть использован для написания масштабных проектов, несмотря на ваше неприятие.
Я не спорю что может, но он увеличивает трудо-затраты и вероятность ошибок из-за через чур динамичной природы языка.
Динамически-типизируемые и прототипно-орентированные языки позволяют существенно сократить затраты в ситуациях, когда вы оперируете широкой предметной областью с множеством уникальных и разноплановых сущностей (что, в частности, является нормальной ситуацией для веб-приложений) за счет быстрого прототипирования и упрощённой разработки.
Разумеется, минусы вытекают из плюсов, и js-подобные языки плохо работают для сильно-типизированных и бедных на уникальные объекты предметных областей.
P.S. «Чересчур» пишется только так, и никак иначе.
Разумеется, минусы вытекают из плюсов, и js-подобные языки плохо работают для сильно-типизированных и бедных на уникальные объекты предметных областей.
P.S. «Чересчур» пишется только так, и никак иначе.
Динамически типизируемые языки — для тех, кто не испытывает дискомфорт от отсутствия явных указаний типов.
Как минимум в области браузерного программирования альтернатив нет толком. То есть JS для всех, но для части он доставляет излишний дискомфорт компенсирующийся только кроссбраузерностью и кроссплатформенностью, но она с типизацией никак не связана.
Положим, до недавнего времени альтернатив было как минимум две — Java и Flash. Их отмирание явно свидетельствует о том, что JS таки оказался куда удобнее.
Их отмирание свидетельствует только о том, что наличие плагинов (проприетарных, к тому же) оказалось менее удобно, чем их отсутствие. Ваш кэп.
Не совсем. Тот же Flash использовался для медийной рекламы почти повсеместно, несмотря на то, что поставлялся проприетарным плагином. Т.е. (а) инструмент использовался прежде всего там, где был удобен, (б) проприетарность плагина никого не пугала, раз уж сервисы не боялись доверять ему самое дорогое — источник доходов. И умирать флэш начал, когда html/js стал предоставлять достаточно инструментов, чтобы делать то же самое без флэша.
Не JS оказался удобнее, а встроенный в браузеры язык. А JS повезло, что встроили его.
т.к. все проверки он выполняет в compile-time
это не совсем так или даже совсем не так
class Point {
var x, y;
Point(this.x, this.y);
}
class Doge { }
bar(Point p) => p.x * p.x + p.y * p.y;
baz() => bar(new Point(1,2)) / bar(new Doge());
это абсолютно валидный Dart код, который при компиляции в JavaScript, конечно, ругнется что
Doge это совсем не Point, но развалится-то он все-равно во время исполнения при попытке взять x с объекта типа DogeВключаем в Dart проверку типов (по-моему она по-умолчанию включена) и он не скомпилирует вам этот код.
Нет. Тут совершенно другая философия за Dart стоит: неправильная типизация не должна мешать вам запустить программу. Иными словами Dart все-таки динамически типизированный язык.
Вы действительно можете проверку типов вы включить (checked mode называется). Но работает она опять же во время исполнения. Если она включена
Конечно же, dart2js и dart_analyzer используют аннотации типов и сообщают вам предупреждения в местах, где вы нарушаете типизацию. Но предупреждения — это не ошибки.
Вы действительно можете проверку типов вы включить (checked mode называется). Но работает она опять же во время исполнения. Если она включена
T x; x = y; фактически превращается в T x; assert(y == null || y is T); x = y;, т.е. в примере выше при попытке вызвать bar(new Doge()) случится исключение, говорящее что Doge нельзя присваивать в переменную типа Point. Но оно случится во время исполнения, а не во время компиляции.Конечно же, dart2js и dart_analyzer используют аннотации типов и сообщают вам предупреждения в местах, где вы нарушаете типизацию. Но предупреждения — это не ошибки.
У Dart есть Checked mode, вот тут описано www.dartlang.org/articles/optional-types/, если его включить, все проверки будут выполняться. И будут происходить ошибки, а не предупреждения, не в браузере, а в момент компиляции в JS. Поэтому Dart предоставляет выбор, использовать ли проверку типов или нет уже ваше дело. Но сама структура языка позволяет сделать эту проверку типов на этапе компиляции, а не выполнения.
вот тут описано
Да, там написано:
If you run a program in checked mode, the system will automatically execute certain type checks when passing in parameters, when returning results, and when executing assignments. If the checks fail, execution will stop at that point with a clear error message.
[...]
Essentially, checked mode is like running your program under the debugger with watchpoints that run a subtype check on every assignment, return, and so on.
Поверьте мне, я знаю как она работает не понаслышке, т.к. я работаю над Dart :-)
Да это немного огорчает. Т.е. проверок во время компиляции вообще не происходит? Я имею ввиду dart2js.
Ну почему, он вам покажет предупреждения, там где вы типизацию нарушаете, выбор ваш добиваться 0 предупреждений при компиляции или словить ошибку во время исполнения. Это полностью соответствует тому, что типы вообще можно не писать.
А почему это предупреждение? Это для того чтобы избавится от приведения типов, по типу
... as {type}? Потому что философия такая. Хочется динамически типизированный язык программирования, на котором можно быстро прототипировать (типы под ногами не мешаются), но при этом с возможностью добавить типы для описания интерфейсов для средств разработки и т.д. Посмотрите в секцию Overview в том документе, на который вы сослались. Он эту философию описывает.
О, и не сориентируешься так по нику :) Вот даже какой-то «спец» по виртуальной машине Dart-а нашелся, который отминусовал :)
Можете поделиться каким-нибудь интересным инсайдом относительно ближайших планов по развитию, выходящих за рамки «будем работать над стабильностью и производительностью»?
Можете поделиться каким-нибудь интересным инсайдом относительно ближайших планов по развитию, выходящих за рамки «будем работать над стабильностью и производительностью»?
Статическая анотация типов не есть статическая типизация
Упорство Гугла в форсинге этого Дарта заслуживает лучшего применения.
После того как они сделали браузер номер 1 и мобильную платформу, которая хоть как-то может тягаться с iOS — я не удивлюсь если дарт через пару лет заткнёт js. Хотя могут и порохоронить, тут 50 на 50.
Гугл сделал Firefox? O RLY? :)
Побуду занудой, но в чём браузер номер 1?
Только не надо давать статистику на gs.statcounter.com, чью статистику подсчёта уже рассматривали(http://habrahabr.ru/post/140473/) на habrahabr.ru.
Только не надо давать статистику на gs.statcounter.com, чью статистику подсчёта уже рассматривали(http://habrahabr.ru/post/140473/) на habrahabr.ru.
Браузер №1 в желании позиционировать себя как браузер №1.
Я так и думал.
Попробуешь попросить адекватных доказательств, так сразу гадят в карму, молча.
Попробуешь попросить адекватных доказательств, так сразу гадят в карму, молча.
Эта статистика показывает лишь запросы по сайтам Wikimedia.
При чём именно запросы, а не уникальные пользователи. Т.е. Chrome — это браузер номер 1 в запросах к сайтам Wikimedia?
При чём именно запросы, а не уникальные пользователи. Т.е. Chrome — это браузер номер 1 в запросах к сайтам Wikimedia?
Да. И субъективно это достаточно репрезентативно для всей Сети.
Опять же, это статистика не уникальных пользователей — это раз.
И субъективно, она вообще не репрезентативна для всей сети.
И субъективно, она вообще не репрезентативна для всей сети.
А причем тут уникальные пользователи или нет? Разве утверждается, что Хром — браузер номер 1 по уникальным пользователям?
Прочитайте мой вопрос ещё раз: habrahabr.ru/post/202340/#comment_6988970
> субъективно
> репрезентативно
Теперь давай выберем что-то одно.
> репрезентативно
Теперь давай выберем что-то одно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Оно уже есть в стандартной поставке SDK Dart: api.dartlang.org/docs/channels/stable/latest/dart_io.html
НЛО прилетело и опубликовало эту надпись здесь
Ну не факт конечно, есть еще множество аналогов node.js, вот например: vertx.io/, поддерживается js, java, ruby, python, groovy. А для GO не станет, это компилируемый язык, хотя да, это немного странно что области применения Dart и Go пересекаются.
Какой же он конкурент Node.js, если он весь синхронный?
Никто не отменял, что JS тоже развивается и развиваются его VM.
Видится мне, что Dart может стать хорошей альтернативой (а конкуренция — это хорошо), но что полностью заменить его — это маловероятно.
К тому же маловероятно что Mozilla и Microsoft сделают нативную поддержку.
Видится мне, что Dart может стать хорошей альтернативой (а конкуренция — это хорошо), но что полностью заменить его — это маловероятно.
К тому же маловероятно что Mozilla и Microsoft сделают нативную поддержку.
Как минимум у него название звучит круто и мотивирует посмотреть что за фрукт.
Если интересно сравнение Яваскрипта с популярными альтернативами, включая Coffeescript, Typescript и Dart, посмотрите на реализацию алгоритма Дейкстры на каждом из языков.
Киллерфича?
Си-подобный синтаксис, статичные типы данных и скорость выполнения.
Лично мне этого достаточно.
Лично мне этого достаточно.
А антикиллерфича — несовместимость со всей имеющейся экосистемой JS-библиотек. Можно попрощаться с jQuery и всеми ее плаигнами/виджетами, Prototype.js, d3.js, three.js, Angular.js и всеми остальными полезностями.js.
Писать все с нуля и создавать свою экосистему.
Писать все с нуля и создавать свою экосистему.
Я не совсем в курсе, но в новости среди прочих упоминается некий пакет под названием AngularDart. Может быть все-таки есть какой-то способ привязываться к коду на JS?
НЛО прилетело и опубликовало эту надпись здесь
www.dartlang.org/samples/#using_javascript_from_dart
Но вообще, да, все постепенно перепишется, только уже под Polymer. jQuery там как-то особо уже не нужен. AngularDart вот уже почти переписался.
Но вообще, да, все постепенно перепишется, только уже под Polymer. jQuery там как-то особо уже не нужен. AngularDart вот уже почти переписался.
Вы кроме статьи этой об Dart или его экосистеме что-то знаете? Видимо нет.
jQuery в Dart не нужен, так как все вещи есть в родном API www.dartlang.org/articles/improving-the-dom/
Короче из того что вы назвали есть в Dart. Ну дам там не jQuery, потому что это не Javascript а Dart и пакет называется html. Но если вы ознакомитесь с API api.dartlang.org/docs/channels/stable/latest/ и уже существующими пакетами pub.dartlang.org/, то увидите что Dart уже в шею дышит Javascript и шея эта нативная поддержка браузерами.
А если уж слишком надо что-то из Javascript импортировать то есть api.dartlang.org/docs/channels/stable/latest/dart_js.html
jQuery в Dart не нужен, так как все вещи есть в родном API www.dartlang.org/articles/improving-the-dom/
Короче из того что вы назвали есть в Dart. Ну дам там не jQuery, потому что это не Javascript а Dart и пакет называется html. Но если вы ознакомитесь с API api.dartlang.org/docs/channels/stable/latest/ и уже существующими пакетами pub.dartlang.org/, то увидите что Dart уже в шею дышит Javascript и шея эта нативная поддержка браузерами.
А если уж слишком надо что-то из Javascript импортировать то есть api.dartlang.org/docs/channels/stable/latest/dart_js.html
> Dart уже в шею дышит Javascript и шея эта нативная поддержка браузерами.
Flash тоже в свое время дышал в ту же шею (и куда ближе, надо сказать). Но не срослось.
А у Dart пока совершенно мизерная доля рынка, так что я бы погодил с прогнозами. И еще надо посмотреть, что там получится с Dart vs TypeScript.
Flash тоже в свое время дышал в ту же шею (и куда ближе, надо сказать). Но не срослось.
А у Dart пока совершенно мизерная доля рынка, так что я бы погодил с прогнозами. И еще надо посмотреть, что там получится с Dart vs TypeScript.
Flash тоже в свое время дышал в ту же шею (и куда ближе, надо сказать). Но не срослось.
В том что не срослось виновата только adobe (проприетарщина с кучей критичных дыр, тормозами и 1.5 поддерживаемыми ОС никак не могла стать всеобщим стандартом). Такая же история с Java — кроме убогих аплетов она толком не использовалась и практически не развивалась (и тоже куча дыр и тормоза, а еще забавно что в конце 2013 года автоматического обновлятора для x64 до сих пор нет).
«1.5 поддерживаемых ОС» стали критичными только тогда, когда появилась первая действительно массовая ОС, не входящая в это число — iOS. Причем Адоби наверняка были бы и рады сделать флэш под неё, но так кто ж им даст.
У Dart в этом смысле все несколько получше за счет трансляции в JS. Но есть мнение, что в обозримом будущем трансляция так и останется основным режимом (все-таки хром хоть и вышел на первое место, но в сумме Firefox+IE+Safari его перевешивают с большим отрывом, а там никто Dart VM прикручивать не собирается — разве что Firefox, но и то вряд ли). Соответственно, скорость работы оттранслированного кода и станет baseline, и никто не будет реально полагаться на тот выигрыш в производительности, который дает статическая типизация в сочетании с VM.
А при таком раскладе у Дарта нет каких-то принципиальных преимуществ перед TypeScript. При том, что последний — это чистое надмножество ES6, и все фичи, которые между ними общие, и выглядят, и работают одинаково, и из TypeScript всегда можно сделать чистый ES6, просто выкинув все объявления и аннотации типов, без потери семантики — а вот в Dart свои велосипеды (это, кстати, к вопросу о стандартах). А те, кому совместимость не интересна, могут вообще отказаться от сишного синтаксического наследия, и сразу уйти на CoffeeScript.
У Dart в этом смысле все несколько получше за счет трансляции в JS. Но есть мнение, что в обозримом будущем трансляция так и останется основным режимом (все-таки хром хоть и вышел на первое место, но в сумме Firefox+IE+Safari его перевешивают с большим отрывом, а там никто Dart VM прикручивать не собирается — разве что Firefox, но и то вряд ли). Соответственно, скорость работы оттранслированного кода и станет baseline, и никто не будет реально полагаться на тот выигрыш в производительности, который дает статическая типизация в сочетании с VM.
А при таком раскладе у Дарта нет каких-то принципиальных преимуществ перед TypeScript. При том, что последний — это чистое надмножество ES6, и все фичи, которые между ними общие, и выглядят, и работают одинаково, и из TypeScript всегда можно сделать чистый ES6, просто выкинув все объявления и аннотации типов, без потери семантики — а вот в Dart свои велосипеды (это, кстати, к вопросу о стандартах). А те, кому совместимость не интересна, могут вообще отказаться от сишного синтаксического наследия, и сразу уйти на CoffeeScript.
Мне (вполне возможно, что пока) что-то не захотелось сразу же все бросить и на Dart переходить. Как-то не очень веско прозвучало…
Не вижу фичи в статической типизации, равно как и в си-подобном синтаксисе.
А бывает одна киллерфича?
Хотя, в принципе, можно сказать, что это системный подход к созданию набора инструментов для разработки комплексных веб-приложений:
Немного сумбурно, но как-то так мне это видится.
Хотя, в принципе, можно сказать, что это системный подход к созданию набора инструментов для разработки комплексных веб-приложений:
- современный прагматичный язык — синтаксически очень узнаваемый, из коробки асинхронность, Futures, Streams, каскадный оператор, интерполяция строк, краткий синтаксис функций, конструкторы-фабрики, dictionary-style опциональные аргументы (писать вроде больше, но читабельность потом, на мой взгляд, действительно выше), модульность, инструменты тестирования, весьма богатый SDK, tree shaking, пакетный менеджер, опциональная типизация, которая с одной стороны даст возможность быстро прототипировать, на заморачиваясь на типы, а с другой — построить надежную систему с хорошо прописанными интерфейсами (за счет типизации) взаимодействия между компонентами. Эта же типизация позволяет создавать гораздо более продвинутые IDE, помогающие в разработке. Т.е. с одной стороны ничего супер-нового, но в том и прагматичность — собрали хорошо зарекомендовавшие себя практики и реализовали именно их в первую очередь.
- производительность — а над Dart VM работают инженеры из команды V8, который в общем-то в свое время задал тренд заботы о производительности в javascript. Про SIMD опять же не забыли.
- помимо прагматичного акцента на уже зарекомендовавших себя практиках, они не забыли и про развитие. Помимо «jQuery» из коробки, получите Polymer.dart, AngularDart. Т.е. ShadowDOM и т.п. Разработчики Angular тоже молодцы — не просто тупо портировали, а похоже сразу реализуют там примерно то, что хотели бы видеть в следующих версиях AngularJS. Там только html-template часть практически таже самая, внутренности другие — иерархия инжекторов, разделение на компоненты (изолированный scope, ShadowDOM), директивы, контроллеры (немного другой там акцент с контроллерами), иерархичный роутинг (правда не знаю, что на это больше повлияло — может нехватка времени и просто уже частично заюзали существующее стороннее решение :) ), ну и Dart сам по себе оказал влияние на то, как это все устроено.
- ну и внутри у себя они все это, как минимум, на одном реальном проекте обкатывают — вроде CRM какую-то пишут.
Немного сумбурно, но как-то так мне это видится.
Вот интересно, я когда рассматривал Dart, возникла дилемма, что использовать Polymer.dart или AngularDart, ведь библиотеки очень похожи по назначению, и обе пишутся в google, не очень понятно, какую выбирать…
Честно говоря, на мой взгляд, не такие уж они и похожие. Polymer.dart — больше для разработки компонент. В Angular — это только одна из частей. Angular — это фреймворк для создания приложений, который представляет собой комлекс инструментов (DI, директивы/компоненты, фильтры, валидация, контроллеры, сервисы, тестирование). Хотя даже если сравнивать Polymer с директивами/компонентами в Angular, в последнем они гибче. Там идеология директив — это, фактически, mixin-ы, примеси поведения. В Polymer можно либо новый компонент создать, либо расширить существующий, про примеси там только думают.
Хотя за Polymer-ом я не особо сильно слежу, а вот AngularDart пока еще сыроват. В общем-то они еще и по фичам с AngularJS не совсем сравнялись (0.9.1, 0.9.2).
Хотя за Polymer-ом я не особо сильно слежу, а вот AngularDart пока еще сыроват. В общем-то они еще и по фичам с AngularJS не совсем сравнялись (0.9.1, 0.9.2).
Вот это уже аргументы.
НЛО прилетело и опубликовало эту надпись здесь
Уже есть дата, когда Гугль дропнет поддержку и свернёт развитие этого языка?
Принимаю ставки через сколько лет Гугл закроет этот проект.
Превосходная альтернатива VBScript. И очень вовремя, все-таки сейчас 1997 год, MSIE вытесняет Netscape. Очевидно, что будущее именно за такими нестандартными решениями, как VBScript и DartScript.
Вставлю свои субъективные 5 копеек. Я, наверное зря, ожидал красивый язык с интересным синтаксисом, а получилось что-то явоподобное, что на фоне того же их Go смотрится странно. В целом интересно, занятно, если будет популярно буду пользоватся — он как минимум не хуже JS, а объективно местами и лучше. В любом случае сейчас в этом сегменте очень плотная конкуренция. Это на руку нам простым разработчикам, значит бурная эволюция фронта неизбежна, а там гляди и мечта в виде «One language to rule them all» сбудется(я про Server/Client side язык).
Кто-нибудь уже пишет транслятор из Scala в Dart? :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google выкатила замену Javascript — язык Dart