nixp.ru v3.0

28 марта 2024,
четверг,
16:32:52 MSK

17 октября 2012, 13:02

Google выпустила первую версию своего языка программирования Dart

5
Первый год языка Dart
Первый год языка Dart
Иллюстрация с сайта google-opensource.blogspot.com

Минувшим вечером интернет-гигант Google объявил о доступности первой стабильной версии своего нового языка программирования для веб-приложений — Dart.

Язык Dart призван решить некоторые проблемы JavaScript, предлагая веб-разработчикам инструмент для создания хорошо масштабируемых проектов с лучшим уровнем безопасности. Предварительная версия Dart появилась около года назад, и вот теперь состоялся первый стабильный релиз. Что интересно, этот выпуск был представлен вскоре после того, как Microsoft представила общественности свой Open Source-аналог JavaScript, решающий сходные задачи, — TypeScript.

С первым релизом Dart SDK представлены следующие инструменты для веб-разработчиков:

  • более производительная виртуальная машина Dart (в некоторых тестах Octane она превосходит V8);
  • новый транслятор кода Dart в JavaScript;
  • HTML-библиотека для современных веб-браузеров;
  • библиотека для работы с JavaScript-кодом;
  • простой в использовании редактор;
  • новый пакетный менеджер Pub;
  • Dartium — сборка веб-браузера Chromium с встроенной поддержкой Dart;
  • серверная библиотека ввода/вывода;
  • спецификация языка, описывающая семантику Dart.

Постоянная ссылка к новости: http://www.nixp.ru/news/11954.html. Дмитрий Шурупов по материалам google-opensource.blogspot.com.

fb twitter vk
Eleidan

Как удачно подметил кто-то: «каждому программисту — по языку программирования!», — толку от всего этого?

yesint

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

defender

Если компания не предлагает инновации, она обречена на постепенное угасание. Типичный пример — IBM. К тому-же, какие рычаги есть у google дабы заставить использовать Dart? (Как, к примеру, M$ со своим C#). Если и будут пользовать, знать он того стоит (а строгая типизация, как по мне, стоит многого :D). И еще такой момент. Вокруг кричат, что слишком много языков программирования. Но ведь на изучение языка программирования уходит сравнительно маленькое время если знаешь уже 1-3 языка (это как правило). А на изучения всякоразных фреймворков и стандартных библиотек — значительно больше! Чем появление хорошего инструмента (типа Dart) отличается от появления новой библиотеки (для того-же JavaScript)?.. Да, появлением новых стандартных (и не очень) библиотек. А это уже неизбежно… И не важно для какого языка!

rgo

> К тому-же, какие рычаги есть у google дабы заставить использовать Dart?

Chromium. У MS когда-то был IE, но IE потерял свои позиции с тех пор. Вряд ли кто-то, кроме хрома будет уметь работать с dart. То есть хром оказывается в выделенном положении. Сложно сказать сколько процентов в статистике это добавит хрому, но, несомненно, сколько-нибудь да добавит.

defender

Неудачное сравнение. Chromium как-никак open source. Т.е. рычагом давления быть не может. И Chromium нативно работает с Dart. А в SDK есть компилятор в JS

yesint

А в чем инновационность? Имхо, появление таких языков — попытка подставить костыли вместо пересмотра самой архитектуры веб-приложений.  Сейчас все массово ломанулись их писать, а если подумать, то это же ужас — даже на клиенте адская мешанина из HTML, JavaScript, CSS, Flash с костылями под разные браузеры, а на сервере другие языки и тоже обычно все матом ибо на коленке и «бегом-навались-завтра выкатить». Теперь еще Dart добавить, который никем не поддерживается и можно вешаться :)

rgo

А какая разница веб-программисту, что там на клиенте? Не, ну если программист пишет на PHP, то конечно… Но это называется «сам себе злобный буратино». Правда альтернатив хороших практически нет. Все альтернативы php, как правило, исповедуют тот же самый подход php, когда всё веб-приложение зачем-то разбивается на «страницы», и справится с более-менее серьёзным control-flow — это самоубийство. Есть ASP.NET, но он хочет чтобы html был писан вручную, что suxx, поскольку ошибки порождает, да и просто неудобно. Есть weblocks, но у него вместо документации сорцы, а в сорцах настолько продвинутый lisp (в хорошем смысле продвинутый), что надо быть Джоном Маккарти, чтобы понять как weblocks работает и как им пользоваться. Говорят seaside ещё неплох, я как-то интересовался, но не смог найти online документации, только книжку в pdf, которую качать/листать было лень.

Может за последние два-три года и появилось что-нибудь новое, но сильно я сомневаюсь. А гугол идёт правильным путём. Конечные цели его угадать сложно, но у него есть все шансы получить в конечном итоге полноценный фреймворк для веб-разработки. Другое дело, что этим Dart’ом он скорее хром пытается продвинуть, нежели фреймворк создать.

Дмитрий Шурупов

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

Я что-то не понял. Ты современные веб-фреймворки вообще видел? :-)

Или что ты понимаешь под «самоубийством» на примере, скажем, Ruby on Rails?

rgo

>  Или что ты понимаешь под «самоубийством» на примере, скажем, Ruby on Rails?

Ruby on Rails разработан как переосмысление REST подхода php. Это шаг вперёд, но лишь один шаг. Да, ActiveRecord рулит. Но всё равно, в RoR задача первостепенной важности — генерация html’я на выходе, которая сводится к шаблонам и состыкованию кусков html’я. AJAX для Ruby on Rails, если по-хорошему, что-то инородное, потому что для него инороден javascript.

Писать веб-приложения используя непосредственно html — это примерно то же самое, что писать GUI приложение используя Xlib.

rgo

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

1. Никакого html’я, вместо него библиотека виджетов. То есть, не тег table, а виджет Table, который мы создаём как объект, проставляем свойства, выдаём ему модель, которая будет работать как адаптер между Table и нашим внутренним представлением данных. Добавляем Table в общее дерево виджетов, вызываем для корневого виджета метод render. Этот самый table, уже умеет сортировать записи по разным столбцам, разбивать их на страницы, возможно он позволяет выделять одну или несколько записей. Возможно для этого он использует технологии AJAX. Как он это делает нам не интересно, мы можем даже не знать этого. Этот виджет может использовать тег table, а может и не использовать — это его личное дело. Всё что нам надо знать — это внешний API к Table.

2. Никакого SQL’я и прочих NoSQL’ей. Это всё тоже должно инкапсулироваться глубоко-глубоко. В идеале настолько глубоко, чтобы для нас был бы безболезненным переход не только с MySQL на PostreSQL, но так же и переход на что-нибудь типа BerkeleyDB. В идеале, фреймворк должен предлагать объектно-ориентированную базу данных. Умея использовать для постоянного хранения различные бэкэнды.

3. Никакого javascript’а. Все client-side коллбеки мы развешиваем на виджеты в качестве свойств, причём пишем их на том же языке, на котором и серверную часть. Это правда порождает проблемы: не раз в новостях о безопасности я натыкался на упоминание о случаях, когда web-приложение проверяло пару логин/пароль на стороне клиента, и как я понимаю, это прямое следствие подобного подхода, потому что в коде веб-приложения, клиентский код уже не отличается внешним видом от серверного, что может подтолкнуть к ошибке. Но ошибки ошибками, а это удобно. Потому что javascript генерируется в результате компиляции, и поэтому заведомо не содержит кучи глупых ошибок. В частности это гарантированно избавляет от XSS, поскольку код фреймворка, выводя в результате html-код, делает это компилируя внутреннее представление страницы, в котором скомпилированный клиентский код — это объект специального типа, который никак не может получиться «случайно».

4. Continuations. Мы описываем не страницы, а control-flow. Мы пишем приложение, используя подход близкий к подходам используемым при создании классического GUI-приложения. Например, continuations могут быть реализованы при помощи создания thread’ов операционной системы, на каждого клиента по thread’у, последовательные запросы клиента (AJAX запросы, переходы по ссылкам, и пр) обрабатываются одним и тем же thread’ом, и каждый thread работает ровно с одним клиентом. Использование thread’ов может быть весьма неэффективным, но дело в том, что возможны и другие способы добиться того же самого. Которые могут быть во-первых эффективнее, а во-вторых позволять сохранять такой «thread» в бд. Про thread’ы я начал разговор лишь в качестве примера, для того чтобы проще объяснить было.

defender

Типичный подход десктоп-программиста… ТОгда Google NaCl Вам в руки. Плюс порт Qt На NaCl (ну или любой другой фреймворк, авторы которого сподобились портировать на NaCl свои поделья).

rgo

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

То что при этом приходится разговаривать о «виджетах», прямо как в gtk или qt — это прямое следствие схожести задач. Но на базе gtk или qt строить нечто подобное, я считаю пустой тратой времени. Эти фреймворки не рассчитаны на то, что их будут портировать на HTML. Они портируются на win32api, на framebuffer, но на HTTP/HTML… По-моему не выйдет из этого ничего хорошего.

NaCl — это совершенно другой подход. Я говорю о чём-то в стиле weblocks. Никакого нативного кода — зачем он нужен? То есть, конечно же, серверную часть вполне можно скомпилировать и в нативный код, почему бы и нет, если язык позволяет, но зачем нужен нативный код на клиенте? Проводить сложные вычисления? Вот если мне понадобится когда-нибудь, тогда я пожалуй и взгляну на NaCl.

defender

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

перспективней на мой взгляд оставить все как есть кроме одного: выкинуть нафиг HTTP. И внедрить какой-нить StateFull протокол. Вот это ооочень упростит создание приложений.

 

rgo

> Ну, системный программист как раз должен делать KISS. А не авто-мото-вело-фото-теле-радио-сипед.

То есть писать на ассемблере не заморачиваясь на создание C? Или писать под голую железку не создавая операционной системы?

Eleidan

ASP.NET — там уже давно многие Ваши запросы реализованы: те же виджеты, тот же DataSet, тот же «умный» JS (если клиент не поддерживает JS/AJAX — страница приедет из сервера).

Осталось форкнуть ASP.NET и дописать нужное.

rgo

> ASP.NET — там уже давно многие Ваши запросы реализованы

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

 

> Осталось форкнуть ASP.NET и дописать нужное.

Это не нужно. Есть альтернативы.

Дмитрий Шурупов

Параллель с десктоп-программистом тут правильно провели. Специфика веба в том, что стандарт HTML весьма условен из-за зоопарка движков рендеринга в браузерах. Если говорит про сложную, правильную и кроссбраузерную верстку, то до недавнего времени нельзя было сгенерировать такой код, который одинаково отображался бы во всех браузерах. Это искусство верстки, подвластное только людям-профессионалам. К красивым виджетам пришлось бы каждый раз вручную приплетать кучу костылей. А так, фреймворки вообще-то генерят вполне стандартный HTML-код для всех объектов. Но да, его потом всё равно нужно править руками.

С базами данных мне представленное тоже кажется немного утопией. Ну, вообще, есть ORM. Только когда они убегают в далекую абстракцию, скрывая всю силу тех же SQL-запросов, зачастую становятся недоступными специфичные вещи, которые позволяет конкретная СУБД (но серьёзным проектам они вообще-то могут понадобиться — не зря же их придумали!). В общем, каждая такая абстракция даёт свои плюсы, но порой одновременно с этим ещё и ограничивает.

rgo

> Если говорит про сложную, правильную и кроссбраузерную верстку, то до недавнего времени

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

> Это искусство верстки, подвластное только людям-профессионалам.

Да. Именно поэтому и нужен фреймворк. Над которым будут работать те самые профессионалы.

 

> В общем, каждая такая абстракция даёт свои плюсы, но порой одновременно с этим ещё и ограничивает.

 

Да. Я помню, когда я впервые переключился с программирования под DOS на программирование под ОС защищённого режима меня безумно бесило то, что ОС не позволяет мне общаться с железками. Я чувствовал себя как в клетке, будто я пытаюсь сделать простые вещи через жопу, при помощи каких-то костылей. Любая абстракция ограничивает. Но сегодня я привык, и меня уже не сильно напрягает подобное.

defender

Servier-side программисту-то может и по барабану, это да. А хрому в качестве продвижки одного V8 хватает…

yesint

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

defender

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

defender

Ух… И это хорошо на самом деле что там зоопарк (в какой-то мере). HTML нужен дабы задать структуру. Как хорошо он с этим справляется вопрос третий. Можно TeX вместо HTML-ля :D. Каскадные таблицы стилей решают свою задачу. И пишутся отдельным человеком, которому и знать-то о, скажем, JS не обязательно. И ко всему этому прибавлено скриптоложество (в виде JS и пр). Или Вы предлагаете все это засунуть в одну екзосистему-перенедоязык? Дык гуано-то получится еще более вонючее и неповоротливое (как в плане производительности, так и в плане внедрения новшеств). И поддежка будет еще более разноплановая — увеличится кол-во костылей. Мы вона CSS3 сколько ждем чтобы расползся на превалирующее кол-во машин в Сети… А Вы «пересмотреть архитектуру»… Я, конечно, не спорю что физикам надо сказать «спасибо» за HTTP и HTML. Но дык не они предложили применять эту архитектуру повсеместно…

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

Илья Смирнов

Поскольку есть транслятор в JavaScript, т.е. теоретически обеспечивается совместимость со всеми браузерами, а не только с Chrome, становится интересно присмотреться к Dart. Другое дело, как это будет работать на деле. JS-фреймворки преодолевают проблему несовместимоси браузеров через свой внутренний API. А если, к примеру, код JavaScript, сгенерированный транслятором, будет работать только в Chrome, становится неинтересно. Т.е. по идее за этим транслятором должен стоять JS-фреймворк, обеспечивающий работоспособность полученного кода во всех браузерах. Если да — круто, если нет — отстой :)

yesint

Вообще если вдуматься, то это полный ахтунг — строго типизированный язык для выполнения «компилируется» в слабо типизированный :)

Илья Смирнов

Согласен. Только что сам об этом подумал :)

defender

А ничо, что строго типизированный язык компилится в ассемблер, а? Ошибки-то во время компиляции а не во время исполнения…

yesint

Дело не в типизации как таковой. Ассемблер быстрее, а тут быстрый код транслируется в медленный.

defender

 

Ээээм… Чего-же он медленный-то? Ну да, флоаты на нем лучше не решать. Но это из-за принятого в JS стандарта по плавучке… А вообще JS — компилируемый язык. Чего V8 и делает. И исполняет затем нативный код для архитектуры (ну есесно в песочнице). (кстати, получаемый код порой быстрее чем откомпилированный С++. И этот подход  используется очень широко. Тот-же LLVM)

 

yesint

Ну компилируется там только то, что может в принципе компилироваться. Многие вещи физически не предназначены для этого (eval-ы всякие).

На счет быстрее чем С++, то что-то меня терзают смутные сомнения. А LLVM тут немного не в тему — он дает унифицированное промежуточное представление, но все равно потом компилирует в нативный машкод.

defender

ну eval-ы используют только @#$%^-сы :D И чем JS не простейшее представление?..  Идейно то, что промежуточное представление простое почти как двери. Тем не менее, им можно представить большой набор всякоразных языков.

yesint

JS простейшее представление? Чур меня, чур :)

defender

На самом деле язык простой как двери. Там даже инструменты ООП каждый для себя делает :D. И компилятор простой и интерпретатор тожеть. Не даром его куда только не засовывают.

rgo

Задачи компиляции, в данной ситуации сводятся к:

1. Проверка синтаксиса, типизации, возможно глупых ошибок, допустим типа if(a = 2): gcc на это выдаёт варнинг, предлагая либо заменить  a=2 на a==2, либо на (a=2). Примерно так же может поступать компилятор Dart’а.

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

3. Совместимость с браузерами. Мы используем для написания клиент-сайд скриптов то, что удобно нам, даже если это не поддерживается браузерами, но и тем не менее этап компиляции позволяет нам работать с любым браузером, который умеет javascript.

4. Подчастую это позволяет малой кровью добиваться работоспособности AJAX-rich приложения в браузере не поддерживающем javascript: просто код, задуманный программистом как клиентский, выполняется на сервере, и клиенту высылается новая «версия» страницы.

rgo

Да, ещё:

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

defender

4. — X-сервер поверх HTTP??? :D :D :D :D Ню-ню…

rgo

> 4. — X-сервер поверх HTTP??? :D :D :D :D Ню-ню…

=)

Нет. Просто при отсутствии javascript на клиенте, весь этот AJAX редуцируется до без-AJAX’ового подхода, с полной перезагрузкой страницы на каждый запрос.

rgo

Нет, не ахтунг. Типизация проводится статическая. На этапе компиляции. Строго типизированный C, тоже компилируется в слабо-типизированный ассемблер. И ниче?

Дмитрий Шурупов

http://www.dartlang.org/support/faq.html#what-browsers-supported

What browsers do you plan to support as JavaScript compilation targets?

We’re currently aiming to support the following browsers:

 

  • Internet Explorer, latest two versions that are 9 or higher.
  • Firefox, latest two versions that are 7 or higher.
  • Chrome, latest version.
  • Safari, latest two versions that are 5.1 or higher.
  • Opera, latest version that is 12 or higher.

 

Илья Смирнов

И это классно. Перспективность языка Dart для меня стала очевидна. Надо присмотреться к нему поближе :)

kuca

кажется это как-то связано с coffescript…

Дмитрий Шурупов

«Both Dart and CoffeeScript are inspired by JavaScript, and both can be translated back to it. They make different choices, particularly in the flavor of their syntax. As a language we think it’s fair to say that Dart differs semantically from JavaScript more than CoffeeScript does; that may result in a less line-for-line translation, but we believe Dart-generated JavaScript can have excellent size and speed.

If you like CoffeeScript for its more structured feel than raw JavaScript, you may like Dart’s optional type checking.»

// http://www.dartlang.org/support/faq.html#compare-to-coffeescript