Компания Google представила (http://google-opensource.blogspot.ru/2013/11/dart-10-stable-...) первый стабильный релиз языка программирования Dart 1.0 (http://www.dartlang.org/) и связанного с ним SDK для разработчиков web-приложений. Dart позиционируется как язык структурированного программирования для Web, который в долгосрочной перспективе может стать прогрессивной заменой JavaScript, решающей имеющиеся в настоящее время проблемы с расширяемостью, производительностью и поддержкой разработки сложных приложений.
Для упрощения разработки на языке Dart поставляется SDK (http://www.dartlang.org/docs/sdk/), включающий в себя компилятор dart2js (http://www.dartlang.org/docs/dart2js/), виртуальную машину Dart VM (http://www.dartlang.org/docs/standalone-dart-vm/), пакетный менеджер pub (http://pub.dartlang.org/) и набор библиотек. Для выполнения и отладки приложений на языке Dart, без компиляции в JavaScript, распространяется Dartium - сборка браузера Chromium с интегрированной виртуальной машиной Dart VM. Дополнительно доступен (http://www.dartlang.org/downloads.html) расширенный пакет Dart Editor (http://www.dartlang.org/docs/editor/), в который помимо SDK и Dartium включена специализированная среда разработки на языке Dart.
Язык обладает похожим на Java синтаксисом, не требует явного определения типов и может использоваться для создания серверных и клиентских приложений. Для запуска внутри браузера код на языке Dart может быть преобразован в JavaScript-представление или запущен напрямую под управлением специального JavaScript-интерпретатора Dartboard. Поддерживается (http://www.dartlang.org/articles/embedding-in-html/) встраивание кода на языке Dart в HTML-страницы, используя mime-тип "application/dart". На стороне сервера приложение на языке Dart может быть выполнено внутри специальной виртуальной машины, которая обеспечивает производительность выполнения близкую к компилируемым в машинный код языкам. Виртуальную машину Dart планируется интегрировать в будущие версии браузера Chrome, что позволит выполнять приложения на языке Dart без компиляции в JavaScript.
Язык подходит как для разработки одним программистом небольших скриптов без жесткой структуры, так и для создания высоко масштабируемых больших модульных проектов, поддерживаемых большим коллективом и требующих более явной типизации для того чтобы избежать неразберихи и ошибок. При этом явное задание типов не обязательно, например, можно начать разработку без указания типов, а в дальнейшем при необходимости добавить их (например, изначально написать "var x", а потом заменить на "num x"). Код Dart всегда выполняется только в рамках одного потока, для организации параллельного выполнения предлагается использовать классы с атрибутом isolate. В каждом скрипте используется собственное пространство имён, для использования внешних объектов, функций или переменных следует их явно импортировать при помощи конструкции "import". Все переменные по умолчанию действуют только в пределах текущего скрипта и не экспортируются глобально.Особенности языка Dart:
- Привычный и простой для изучения синтаксис, естественный для программистов на JavaScript, Си и Java.
- Обеспечение быстрого запуска и высокой производительности для всех современных web-браузеров и различных типов окружений, от портативных устройств до мощных серверов;
- Возможность определения классов и интерфейсов, позволяющих использовать инкапсуляцию и повторно использовать существующие методы и данные;
- Необязательное указание типов, использовать или нет статические типы решает разработчик. Указание типов позволяет упростить отладку и выявление ошибок, делает код более ясным и читаемым, упрощает его доработку и анализ сторонними разработчиками.
- Среди поддерживаемых типов: различные виды хэшей, массивов и списков, очереди, числовые и строковые типы, типы для определения даты и времени, регулярные выражения (RegExp). Возможно создание своих (http://www.dartlang.org/articles/optional-types/) типов;
- Для организации параллельного выполнения предлагается использовать классы с атрибутом isolate, код которых выполняется полностью в изолированном пространстве в отдельной области памяти, взаимодействуя с основным процессом через отправку сообщений;
- Поддержка использования библиотек, упрощающих поддержку и отладку больших web-проектов. Сторонние реализации функций могут подключаться в виде разделяемых библиотек. Приложения можно разбить на части и поручить разработку каждой из частей отдельной команде программистов;- Набор готовых инструментов для поддержки разработки на языке Dart, включая реализацию средств динамической разработки и отладки с исправлением кода на лету ("edit-and-continue");
- Возможность создавать однородные системы, охватывающие как клиентскую, так и серверную часть. Использование одного языка и инструментария для клиентских и серверных компонентов упрощает процесс кодирования и избавляет от постоянной смены контекста.URL: http://google-opensource.blogspot.ru/2013/11/dart-10-stable-...
Новость: http://www.opennet.ru/opennews/art.shtml?num=38432
если проспонсировать Mozillовцев, чтобы тоже поддержку Dart'a в Firefox включили ...
Дарт отлично компилится в js. Наличие нативной поддержки на уровне ВМ браузера — только палки в колеса ставить стремительно развивающемуся языку.
Вопрос только - как быстр этот JS в мозилле, а не на V8. Мнится мне, что не особенно.
В мозилле asm.js, пусть под него подстраиваются.
Фееричное удаление гланд через джеппу автогеном.
Мозилла может взять V8 )
Это было бы здравой идеей. Косяки яваскрипта уже достали.
Хочешь чтобы теперь ещё и косяки Dart достали?
Косяки есть везде и всегда. Но яваскрипт это шедевр говноязыка. Теперь, когда первенство проприетарного уг типа ie (и оперы) сведено на нет, самое время продвигать нормальные языки.
Дартс я не знаю нормальный или нет .. пощупаем. Но тенденция радует.
Ниасилил прототипы?
IDE не осиливают прототипы
Согласен. В Dart'е хотя бы есть статическая типизация.
И где же она там?
http://en.wikipedia.org/wiki/Dart_(programming_language)#Runtime_modes
Незачёт. Статическая типизация, это когда тип известен до выполнения. Рантайм чекер никак не катит.
Из вики про типизацию:"Static type-checking is the process of verifying the type safety of a program based on analysis of a program's text (source code). If a program passes a static type-checker, then the program is guaranteed to satisfy some set of type-safety properties for all possible inputs."
Про статическую типизацию в Dart из его спецификации:
Static type annotations are used in variable declarations (including formal
parameters, in the return types of functions and in the bounds of
type variables. Static type annotations are used during static checking (!) and
when running programs in checked mode.
> http://en.wikipedia.org/wiki/Dart_(programming_language)#Runtime_modesэто не статическая типизация, это динамическая типизация с проверками.
Теперь косяки будут не в JS а Dart) Google уже как APPLE - лишь бы чем то выпендриться
Им ещё Dart'овскую VM на своём Rust'е переписывать.
Это как google+, исключительно для сотрудников google?
Учитвая, что Opera перешла на Blink, а разработка Firefox ведётся на деньги гугла, то скоро Dart'а не будет, разве что, в IE и Safari.
...исключительно для браузера chrome
1-й же пример кода на сайте доставляетreturn fib(n-1) + fib(n-2);
А что смущает?
Рекурсия.
Это классический пример кода рекурсии. Понятно, что реальный код так писать никто не будет. Хотя вот оптимизация хвостовой рекурсии у команды Дарта в планах. Конечно же, больше всего этому мешает необходимость компилироваться в js.
> Понятно, что реальный код так писать никто не будет.Малые факториалы тоже через гамму функцию считаешь?
Обязательно, только так.
А летом в гриндерсах ходишь? И саморезы молотком забиваешь?
Забитый саморез держится лучше, чем вкрученный гвоздь.
Оптимизация хвостовой рекурсии - это такая штука, которая вроде как сначала работает, а потом поменяли чуть выражение и бац - чтобы сложить числа отъелась вся оперативка?Это хорошо для исследовательских языков, где зависло - нажал ctrl-C и попробовал по-другому, а в продакшн - нафиг-нафиг.
Ещё и монады прикрутить, ага. Которые в принципе синтаксически очень приятный хаскел по удобству реального применения ставят в один ряд с брейнфаком.
Ничего подобного, более того, например, в Clojure надо явно указывать, что собираешься ее использовать, там вариант "случайности" исключен вообще. В других языках, где нет формального разделения все ложится на программиста, но опять же, для функциональных языков это стандартный паттерн, и ошибки подобного рода достаточно редки. Разработчикам Dart если уж хотят перестраховаться ничего не стоит применить опыт Clojure, чтоб уж наверняка.Монады в неявном виде есть практически во всех современных языках программирования. Эта тема не раз уже обсасовалась со всех сторон. То что в Хаскеле их выделили и дали им названия, не приватизирует их.
>в Clojure надо явно указывать, что собираешься ее использоватьЭто кстати не от хорошей жизни, а от недостатков JVM. Но идея получилась здравая, да.
Сомневаюсь что из-за JVM, потому как в Scala все работает без явного объявления. Хотя я не JVM гик, точно не знаю.
С оф. сайта:In functional languages looping and iteration are replaced/implemented via recursive function calls. Many such languages guarantee that function calls made in tail position do not consume stack space, and thus recursive loops utilize constant space. Since Clojure uses the Java calling conventions, it cannot, and does not, make the same tail call optimization guarantees.
> Сомневаюсь что из-за JVM, потому как в Scala все работает без явного
> объявления. Хотя я не JVM гик, точно не знаю.в jvm нет встроенного механизма для TCO, поэтому надо делать тормозящую чёрную магию. если делать TCO всегда, когда это возможно, то в итоге можно внезапно отхватить нехилые тормоза. поэтому дали возможность явно включать/отключать TCO. если рекурсия точно будет неглубокая, то можно обменять TCO на скорость.
вкратце вот так.
Я только не пойму, что им мешает разворачивать это дело в нормальный цикл - вродде ж несложно.
> Я только не пойму, что им мешает разворачивать это дело в нормальный
> цикл — вродде ж несложно.дано: представление программы в continuation passing style. задача: развернуть это в цикл, не сожрав всю память на копии копий копий копий копий… решишь — поделись нобелевкой. или хотя бы коньяка купи.
Для частого встречающегося случая без continuations - никаких проблем. И этот примитив покроет процентов 80 реального использования TCO.Если у тебя continuations в виде захардкоженных функций (т.е. несколько функций, вызывающих одна другую через TCO, но не приходящих как невесть где вычисленные параметры) - то из них довольно несложно сгенерировать одну итеративную. Еще процентов 10-15 использования закроется. Останется то, что пишут адовые гуру - ну так пусть на хаскель идут или ставят аннотацию какую-нибудь чтобы сказать "я понимаю, что это тормоза".
ты сказал «несложно», а тут вдруг сложности полезли. ладно, «никаких проблем». цепочка вызовов функций, которая может ветвиться и в некоторых местах рекурсивно начинать ту же цепочку с начала. всё ещё «несложно»? а это нормальный функциональный код, вообще-то.сложно TCO в циклы преобразовывать, сложно. «несложно» оно как раз для простейшего использования именно в виде конструкции цикла — так никто почти этого не делает, если в языке явные циклы есть. а в случаях, когда TCO реально помогает писать функциональщину, сразу лезут проблемы.
ну и помимо прочего — межпроцедурный анализ усложняет компилятор. причём усложняет бестолково, потому что циклы народ и так будет писать при помощи циклических конструкций, а на чём-то более-менее сложном анализатор всё равно поднимет лапки кверху.
Цепочка как раз совершенно тривиально разруливается - собираем весь код из неё в одной функции, дальше чуток магии с флагами, чтобы эмулировать отсутствие goto (или нужный опкод есть в JVM? хз). И анализ получается довольно простой. Вот где это действиельно сломается - это когда где-то в рантайме будет определяться, какую функцию отдать аргументом, который будет потом использован для tail call. И да, это нормлаьный функциональный код. Но поскольку людей, думающих таким образом, примерно на пару порядков меньше, чем тех, кто рвется писать на функциональщине, то такого кода мало, и для него можно оставить существующее поведение. Обычно же фанаты начинают переписывать функционально даже то, что императивно пишется проще и читбельнее.Впрочем, в одной вещи я ошибся - решил, что в Clojure нет нормального цикла. А он есть.
> Цепочка как раз совершенно тривиально разруливается - собираем весь код из неё
> в одной функциидорогой, ты в своём уме вообще? ты хоть немного представляешь эти мегапортянки в случае более-менее систематического использования таких штук?
> или нужный опкод есть в JVM?
есть, естественно: без него циклы плохо получаются.
> поскольку людей, думающих таким образом, примерно на пару порядков меньше, чем
> тех, кто рвется писать на функциональщине, то такого кода мало, и
> для него можно оставить существующее поведение.речь у нас началась, напомню, с твоего утверждения, что tail calls несложно разворачивать в нормальные циклы. я закономерно удивился.
kawa, если у меня не ложная память, пытается кое-как преобразовывать. с let у неё получается (да почти все современные схемы let разворачивают в обычный цикл), а с остальным не шибко, особенно с tco. там они трамплины, вроде бы, городили.
"Монады в неявном виде" - это как?
int main() (как и все прочие функции) - это, в общем-то, по сути и есть монада последовательного выполнения.
вы прочитали комментарий человека, жестоко покусаного хаскелем. теперь ему везде мерещатся монады.
Похоже на то
> Похоже на тонет, просто остутствие благоговейного трепета перед страшными словами позволяет понимать, что они означают и что за ними скрываются обыденные вещи :)
но я так понимаю некоторые личности тут настроены на то, чтобы тупо пофлеймить :)
простите, что делают? :)
> простите, что делают? :)какое из русских слов вызвало затруднение?
>> простите, что делают? :)
> какое из русских слов вызвало затруднение?Не понимаю причины столь внезапной агрессии.
>>> простите, что делают? :)
>> какое из русских слов вызвало затруднение?
> Не понимаю причины столь внезапной агрессии.это потому, что ты агрессию сам выдумал, и теперь хочешь, чтобы я пояснил тебе, зачем ты её выдумал. я не знаю.
ок, будем считать твоё высказывание про "мерещится" твоей неумелой шуткой
ну, спасибо. даже от сердца отлегло.
Это однозначно неделя языков программирования))
красивое перспективное описание, пойти учит что-ли ? [:-))
++!
вот как выйдет dQuery так и примемся
Оно там нафиг не нужно. Dart c DOM элегантно работает и без жабоскриптовых костылей типа jQuery.
А при компиляции в JS так же элегантно достает костыли?
Что-то не слишком громко заявлено о кроссбраузерности полученного таким образом кода. Может, с ней есть "небольшие проблемы"?
Нет, туда просто забивается много костылей.
google:// Hello world на языке Dart, скомпиленный в js, занял 17259 строк
[::||||||||||||||::]-же дикий. Оно уже давно пофикшено.
К сожалению как бы хорошо он не работал с DOM все равно нужна куча костылей и проверок на браузер. Иначе обычный AJAX запрос превратится в адъ. И т.д. и т.п.
Ура. Отличная вещь. Еще бы побольше библиотек для server-side разработки и вообще будет красота. НЕмного правда вымораживает _ вместо private, но это все мелочию
для сервер-сайда у гугла есть Go
Go тоже интересная вещь, но все таки Dart позиционируется как язык для server/client-side разработки, а не только как замена js в браузере.
> Ура. Отличная вещь. Еще бы побольше библиотек для server-side разработкиДля сервер сайда надо очень много разных библиотек, такое годами копится...
>НЕмного правда вымораживает _ вместо privateОни тоже упоролись, как и разработчики Angular? Как тогда работать с ключами MongoDB (которые именуются _id?
Сначала они запилили gwt с компилятором в javascript, вроде бы не прокатило толком. Решили с другого конца заехать и запилили dart с компиляцией в javascript и потенциальным серверсайдом. Прием все это очень похоже на яву, прямо таки очень-приочень. Спрашивается, зачем? Неужели хотят оракл выдавить и место занять? Корпорация добра замахивается аднака.
Посмотрите на вопрос не через призму мемов.
Фирма, достаточно мощная, чтобы самой делать себе инструменты разработки, не только делает эти инструменты общедоступными, но и тратится на их пиар. Если то, в чем было удобно работать программистам Гугля, станет отраслевым стандартом - нам-то с вами от этого явно хуже не станет. Если Гугль еще и найдет возможность получить с этого профит - ну, и славно!
"Да не хулится ваше доброе".
Перетащив массу программистов на свои разработки гугль получает контроль над ними, а дальше, как кривая вывезет. Можно много чего придумать и просто сказать "так будет"...как сейчас оракл делает. Причем я не ругал, а констатировал. В любом случае никакой апач и прочие не могут конкурировать с ораклом и гуглем...ну еще красношапка есть с мелкософтом. Так что это все ругать как на дождь орать, что он пошел :) Факт остается фактом, гугль метит в контроллеры следующего витка развития веба...а он состоит в простой мысли "расстрелять зоопарк". Сейчас будет рождаться следующий, универсальный, сквозной фреймворк для разработки клиент-сервера. Если заметите, очередь в цари уже выстроилась :)
Мне написать весь список проектов которые Гуугл похоронил/поддерживат в полуживом состоянии/выкинул сообществу?
Вы просто представить себе не можете, какую армию профессионалов сейчас контролирует, казалось бы, скромный ботаник Бьярне Страуструп... Бойтесь быть его врагом!!!
Причем, обратите внимание. Красношапка выкатила цейлон (он имеет свой sdk и утилиты и компилируем в javascript), гугл выкатил дарт и го, окракл выкатил invoke dynamic на jvm что бы платформа цвела.Знаете почему? Чуют все, что ява приказывает долго жить и обратная совместимость не дает ей развиваться. Потому то и начали потихоньку рынок делить, будущий рынок, скоро программисты Ынтерпрайза с явы побегут, остается понять куда и присоединиться :)
> Чуют все, что ява приказывает долго житьСтранное заявление на фоне новостей "Андроид продается от 1 000 000 аппаратов в день" и "Количество приложений для достигло миллиона".
> и обратная совместимость
> не дает ей развиваться.Проклятая совместимость - не дает развиваться. Видимо истории с Python 3, D 2.0, Perl 6 и т. д., никого ничему не учат.
так усе, на ведроиде зацветет дарт, поверх далвика.
> ... скоро программисты Ынтерпрайза с явы побегутХа-ха! Ну ты пошутил :) Да не "скоро", а уже лет 10 как бегут - только пятки сверкают! Сейчас бегут уже те тормоза, кому ноги по горло промочило - опомнились.
Дотнет - вот куда им всем дорога, пусть хоть на старости лет поживут спокойно.
какой Иксперт у нас в треде! senior developer, небось, автор кода, систем и архитектур.(присмотрелся повнимательней) ой, извините, я обознался. это просто говорящая жопа.
хорошо бы задуматься - а зачем собственно пиар нужен? какие комерческие цели это решает?
У популярных языков, бывает, вдруг появляются наработки в виде библиотек и решений, позволяющих сократить затраты на разработку. Так что Гуглю интересно, чтобы его рабочий инструмент был широко известен и популярен.
Это как раз понятно.Гуглу нужны хорошие качественые веб-приложения (не только свои), чтобы пересадить людей с натива. Логично, что для этого нужны приличные инструменты. А джаваскрипт для больших приложений - это ад кромешный.
Ну и оказать давление для стандартизации Дарта, конечно.
Поделки гугла никаким стандартом стать не могут, потому как не доживают до написания даже черновика
Корпорация Добра не может писать код прямо в яваскрипте, корпоративная магия исчезает когда клиент может просто посмотреть код, пусть и обфускаченый, (или не просто посмотреть а и улучшить или слямзить ;-) ). Вот они и защищают свою интелектуальную собственность.
Чушь.Чем разбирать миниммизированный JS - легче свой написать.
Пример vbscript'а в IE их ничему не научил?
То было давно и конкурировало на одном уровне развития, а это как замена устаревшему языку идёт.
> замена устаревшему языку идёт.Ну если в возможность убедить мозиллу это сделать я еще поверю, то вот MS тут выступит стояночным тормозом ручного типа.
IE уже просто аниме трупак
Ты это расскажи нашему правительству которое обязывает пользоваться интернет сервисами поддерживающими только ie. Я сейчас на работе массово делаю дангрейд до ie 8 так как площадка http://www.sberbank-ast.ru/ поддерживает только ie 7-8.
http://www.sberbank-ast.ru/Page.aspx?cid=2193>операционная система MS Windows 2000, XP, Vista или Windows 7;
>Internet Explorer версии 7.0. либо 8.0;
То были забавные уши, вылезшие из общесистемного интерфейса active scripting и COM, из времён, когда мс пытался что-то делать. Каждый разработчик языка реализовавший интерфейс IActiveScript и взаимодействие с OLE-типами - засовывал в wsh, asp, IE поддержку своего языка. Например ActivePerl.
VBScript использовался в основном в HTML Application (Этакий тизен прошлого тысячелетия), - там где взаимодействие с COM преобладало над DOM. А это - хрень какая-то, концепт языка более лучшего чем яваскрипт.
это искромётная шутка про polymer.dart и речь начальника цеха полимерных покрытий.
А плагин к IDEA кто-нибудь пользует? У меня в PyCharm на попытку запустить скрипт выдает 'Error running dartcons.dart: Cant find Dart executable\: {0}', хотя в настройках плагина пути к SDK прописаны, и версию плагин правильную показывает.
плохо пользовал. ты компрессы попробуй, горчичники…
Я пользую и в IDEA и в PhpStorm. Все работает на отлично.
Использовал с phpstorm 6, полет нормальный. Хотя он умеет только подсвечивать синтаксис. Поодержки отладки нет.Я вообще не понимаю зачем гугл наступает на эти грабли под названием Eclipse еще раз. Они уже делали Android SDK на его основе, потом перешли на IDEA. Eclipse же дико неудобный после того как попользоваться ide от JetBrains.
Есть там поддержка отладки.
И все равно без фреймворков обеспечивающих поддержку единообразного доступа к источникам данных (включая рест) и связку их с визуальными компонентами (и сами визуальные компоненты, кстати, тоже) практическая ценность дарта на клиентской стороне не велика.... а в AngularDart и polymer.dart, упомянутых в статье, этого вроде как и нет.
Есть же WebUI для визуальных компонентов. С REST, Ajax, WebSockets оно умеет работать и очень даже хорошо. А какой еще доступ к данным может быть на клиентской стороне? Вот нормальных ORM-ов на стороне сервера действительно не хватает.
Думаю,скоро до них дойдет и они таки напишут UI на чистом канвасе. И получат гарантироанно кроссплатформенную предсказуемую работу.Ну а доступы и ресты - штука не такая сложная, не гуглы - так кто-то другой нарисует.
Не все так просто. Обозначу несколько проблем (на самом деле их куда больше):- для приложений подгружающих свои части (например, визуальные компоненты) требуется асинхронная загрузка ресурсов, дабы гарантировать что ресурс доступен прежде чем к нему будет осуществлена попытка доступа; в случае же, если определение ресурсов декларативно (на уровне синтаксиса программы), реализация такого механизма становится весьма нетривиальной задачей. Я вот знаю только один такой механизм - в dojo toolkit. Возможно есть и другие, но их в любом случае очень немного. В тулкитах на дарте такого механизма скорее всего пока нет, а без него серьезное веб-приложение очень трудно написать
- визуальным компонентам сложнее кнопки, требуются источники данных. Причем эти источники могут быть как локальные (данные в разметке, бд браузера и т. д.) так и сетевые. Реализовать же единый дееспособный интерфейс с учетом требований кросс-браузнерости (а также политики одного источника) не так просто как может показаться. Потребуется много времени и усилий как со стороны программистов, так и со стороны тестеров, потому что это нифига не проще орма
- сложным веб-приложениям требуются механизмы уровня контроллера. Я имею ввиду управления сценами, переходами между сценами, маршрутизацию запросов и т. д. Полагаю, что этого в тулкитах под дарт тоже нет пока. А это значит, что те же мобильные веб-приложения отдыхают в стороне.
Не, на самом деле, я уверен, что все это с течением времени появится: то, что ява-скрипт гуано мамонта - верный залог этого. Но это случится явно не сегодня, тут много времени и усилий нужно.
>- сложным веб-приложениям требуются механизмы уровня контроллера. Я имею ввиду управления сценами, переходами между сценами, маршрутизацию запросов и т. д. Полагаю, что этого в тулкитах под дарт тоже нет пока. А это значит, что те же мобильные веб-приложения отдыхают в стороне.man Rikulo
Думаю, что всё будет проще. Не будет ни маршрутизации, ни чего-то подобного. Будет XML или JSON, описывающий построеие интерфейса, и отрисовка всего и вся на канвасе так, как делается на десктопе или на андроиде. Благо, в отличие от веба, всё это сто лет как отработано и может быть портировано со вполне разумными усилиями.С подгрузкой всё решается ещё проще - если у тебя два десятка стандартных контролов, лежащих в CDN гугла - не имеет значения, как они велики и не затормозит ли при первой подгрузке - потому что потом они будут лежать в кэше вообще всегда.
Ну а картинки предварительно подтянуть, если они в XML отмечены - явно не проблема.
>не имеет значения, как они велики и не затормозит ли при первой подгрузкеНа самом деле еще как имеет!
Потому что окончание этой подгрузки - есть событие. А если у тебя в на уровне тулкита нет механизмов обеспечивающих отработку (например по колбэку) этого события, то вероятность попытки инициализации кода которого _еще нет_ приближается к 100%. На практике, это значения null там, где должны быть объекты.
Вот пример реализации такого механизма на дожо:
<script type="text/javascript">
require([
"dojo/parser",
"xxxx/myApp/myApp",
"dojo/domReady!"
],
function(parser, app){
parser.parse().then(function(instance){
new app.init();
});
});
</script>Если бы дожо не поддерживал асинхронную загрузку (в том числе и через CDN) модулей через механизм require, то инициализация приложения не прокатила бы вообще - поскольку не было бы гарантий, что вызов new app.init() будет произведен после загрузки модуля "xxxx/myApp/myApp", а не до того или во время того.
Да, безусловно можно обойтись без модулей вообще, или вызывать чем-то-там-свое-на-коленке-писанное... Но зачем бы мне была нужна такая радость, а? Тут вот я совершенно точно знаю, что _сперва_ будет подгрузка, а _потом_ будет инициализация. Это мне обеспечивает тулкит. А в дартавских тулкитах есть ли что наподобие этого? Вопрос интересный. Но скорее всего - нет, ведь им без году неделя жизни.
require можно было и по короче продемонстрировать. А вот проблему подняли годную. Онолитеги радуются появлению в яваскрипт всякого бреда, на подобие классов, свойств. В то время как действительно важные проблемы, описанные и частично решенные у Фланагена так и остаются за бортом.
Какой DOM? Оно надо - бороться с несовместимостями? Тупо страница, состоящая из нескольких <script> и одного <canvas>. Ну плюс декор какой-то, не относящийся к работе приложения.Дальше прилетает с CDN (а точнее - давно прилетел и лежит в кэше) ком из дарт-скриптов мегабайта на три или на десять, который и рисует на этом канвасе контролы и обеспечивает их гарантированно одинаковую работу где угодно. Ресурсы приложения подтянуть и понять, когда загрузка заврешилась - как-то никто аяксовые события не отменял.
Вот это и будет в конце концов. Потому что нефиг городить сложное, если можно обойтись грубой силой.
Это Вы ActiveX(Java applet, Flash, SilverLight) описали?
require решает проблему разрешения ссылок при организации деления на модули при их динамической (и асинхронной) загрузке. Из кеша файлы загружаются так же непоследовательно как и по http.
В общем что-то не ту проблему Вы увидели и решили.
Из кэша можно подождать пока загрузится вообще всё - через require, или ещё что-то - в любом случае там на 20 строк JS дел, если дерево зависимостей не обрабатывать, а при определенной организации модулей (и если не париться задержками на загрузку из сети) его обрабатывать не надо. Но можно и красиво сделать, всё равно там код несложный, особенно если не пытаться всё решать на стороне клиента, а генерировать спсок загружаемых модулей на серверной стороне. В общем, мелочи всё это, решаемые на уровне приложения совершенно тривиальным образом и в куче вариантов.А основные проблемы сейчас - невменяемый DOM и боксовая модель, которые для приложений в принципе малопригодны, и несомвместимость браузеров, которая при нынешней модели развития будет всегда. Первое даёт высокую связность, второе - гору костылей. Логичный вариант ухода - именно на саомстоятельную отрисовку. Вопрос ровно в том, чтобы эта отрисовка достаточно эффективно работала. Тогда можно закостылить только малую часть браузера, а layout-движок использовать тот, который для формочек предназначен, а не для простынь-документов неизвестной структуры.
Вы не имеете опыта программирования на javascript
> Думаю,скоро до них дойдет и они таки напишут UI на чистом канвасе.это да, я с нетерпением жду, когда в программе, по сути являющейся одним гигантским layout engine на её скриптовом языке начнут писать layout engines. а TCO тут нет.
Учитывая, что эта layout engine уже мега гигантская и при этом напрочь не приспособлена для формирования интерфейсов приложений - всё рано до этого дойдёт. Особенно при том, что на таких объемах спек различий между реализациями не быть не может в принципе - соблазн выкинуть к чертям 90% костылей будет очень велик.
фишка в том, что «основной» layout engine при этом никто не выкинет — хотя это самое логичное. собрать всех идиотов с их «веб-приложениями» и выделить им отдельную платформу, на которой «веб-приложения» перестанут быть как идиотизмом, так и «веб», а станут просто сетевыми. кто сказал «java web start»?!
Угу, именно так.И кто-то еще сказал "Flex" :-)
просто праздник языков программирования какой-то
>выполняется в браузерах на базе движка V8 на 42-130% быстрееТ.е. в два раза медленнее в худшем и в 1.3 раза быстрее в лучшем случае - маркетинг такой маркетинг.
Читайте внимательнее.Это в 1.4 раза быстрее в худшем и в 2.3 раза быстрее в лучшем случае.
А теперь внимательно посмотрите на график. Пусть из новости это не понятно, но это результат бенчмарка DeltaBlue. Зелёная линия посередине - JavaScript, та что ниже - Dart компилированный в JS, та что выше - Dart в своей VM. Чем выше - тем быстрее. Как вы можете видеть - Dart компилированный в JS в худшем случае в два раза медленнее JS, в лучшем - в 1.3 раза быстрее.
Не смущает, что по горизонтальной шкале - даты? Это, вообще-то, картинка, на которой показано, до каких высот в оптимизации они дошли.
Но цифры 42-130% были взяты именно из этой таблички. Я ж не виноват, что новость так дезинформирует.
https://www.dartlang.org/performance/
Будь у Дарта хоть тысяча преимуществ над жабоскриптом, Дарт не взлетит - слишком поздно они проснулись. Когда только эта жабо-зараза ещё начала распространяться, уже тогда мы предупреждали: язык - отстой, годится только для однострочных действий, в продакшене такое чмо нафик не нужно! Но нет, запилили аж десять версий, а теперь на те - оказывается, он плохой! Клоуны...
мнение говорящей жопы очень ценно для мира.
> мнение говорящей жопы очень ценно для мира.Да и ты тоже она самая....
> Да и ты тоже она самая….но я хотя бы знаю, что «многоточие» состоит из трёх точек. а тебя даже такой простой вещи научить не смогли.
Блин ещё один супер-пупер язык для коллекции.
Но почему-то выживают только самые мутные и костыльные.
Вот почему, вздыхает фермер Иван, трактора в магазине такие красивые и блестящие, а в деревне все ездят на грязных да ржавых, да с приваренными косилками и привязанными боронами. Дураки!
Да, есть такой бяда.
Но если говорить о вэб-дизайне/браузерном скриптинге то возникает большая проблема:
Если взять весь зоопарк браузеров - они даже html/css стандарты по разному понимают, а клиент "хочет" чтоб сайт одинаково выглядел как на 6-м осле так и на модных хромых/операх/ойфоновских сафари итп. Что делает разраб - берёт то, что работает более-менее везде и лепит костыли для кривых браузеров.
Мораль сей басни такова - к большому сожалению пока не будет нормальной поддержки во всех "мажорных" браузерах новым, правильным и вкусным технологиям не жить.
ЗЫ Разраб просто не будет терять время на написание одной и той же хрени 2 раза - один раз на модном языке для нормальных браузеров и второй например на жабаскрипте для ослов и прочего непотребства.
потому что изначально надо было сделать бинарные форматы и жёстко специфицировать всё поведение. и вместо языка выкатить спеки VM. и сейчас всё было бы лучше, быстрее, проще и красивей.а теперь уже поздно: слишком много говна наделали.
+100500
но говорят, что когда-то давным-давно некий дядя сказанул :"640K ought to be enough for anybody.".
Вот так и живём с бородой 100летней давности и дрожа из-за "backward compatibility".
> но говорят, что когда-то давным-давно некий дядя сказанул :"640K ought to be
> enough for anybody.».причём дядя этот был журношлюхой, но приписал своё высказывание вовсе другому дяде.
> +100500
> но говорят, что когда-то давным-давно некий дядя сказанул :"640K ought to be
> enough for anybody.".
> Вот так и живём с бородой 100летней давности и дрожа из-за "backward
> compatibility".Главная максима ИТ гласит: "Совместимость важнее производительности".
> Главная максима ИТ гласит: «Совместимость важнее производительности».именно поэтому, наверное, у нас нет ни того, ни другого.
Ну всё! Теперь осталось вытеснить хромиумом все остальные браузеры!
> Ну всё! Теперь осталось вытеснить хромиумом все остальные браузеры!А это не составит труда.
Вообще-то, как ни странно, его в последние пару месяцев IE чуток отпихнул. Каким чудом - убей, не пойму.
> Вообще-то, как ни странно, его в последние пару месяцев IE чуток отпихнул.
> Каким чудом — убей, не пойму.так ишак нумер 11 вышел же.
Чудо простое: веб-дизайнеры всего мира сразу начали его использовать... для поиска новых проблем, которые принес очередной выкидыш MS.
> "Язык обладает похожим на Java синтаксисом, не требует явного определения типов..."как это феерично...
Дай-то Бог, чтобы что-нибудь такое уже наконец взлетело.JS, может, не так и страшен, если рассматривать его абстрактно от того, для чего он применяется. Даже в чём-то интересен, пожалуй. И прототипы красоты не лишены. Но для того, для чего он применяется в вебе, он совершенно неподражаемо ужасен, и почти весь код на нём напоминает попытку сложить слово "вечность" из четырёх букв: Ж, О, П и А.
> Дай-то Бог, чтобы что-нибудь такое уже наконец взлетело.
> JS, может, не так и страшен, если рассматривать его абстрактно от того,
> для чего он применяется. Даже в чём-то интересен, пожалуй. И прототипы
> красоты не лишены. Но для того, для чего он применяется в
> вебе, он совершенно неподражаемо ужасен, и почти весь код на нём
> напоминает попытку сложить слово "вечность" из четырёх букв: Ж, О, П
> и А.Язык и кодеры - не синонимы.
Кодеры-то всякие, а вот язык... Чтобы его в больших проектах беспроблемно применять его надо сильно заморить на манер непринятого ECMAScript 4, а чтобы это еще и в браузерах жило, а не скреблось в корчах... даже не знаю, что нужно - навреное, действительно тупо байткод и низкоуровневый интерфейс - вот тебе события ввода, вот канвас, вот устройства - вперед. ну нельзя обойьтись без горы костылей и несовместимостей на таких монстрах, как нынешние браузеры с их развесистым API.
Язык это откровенно провоцирует. Сам по себе, повторюсь, он вполне логичен. Но там, с одной стороны, не хватает массы привычных механизмов (классов без плясок с бубном, наследования без искусственной его имитации и т.п.), зато есть масса непривычных (прототипы, специфическое разрешение областей видимости...). Плюс, будучи чисто динамическим языком, он не так уж хорошо годится для оптимизации скорости. Конечно, с ним теперь чудеса делают, но с более подходящим языком чудес было бы больше.Имеет ли такой язык право на существование? Имеет, конечно. Его небезынтересно выучить, на нём прикольно попрограммировать, от того же C/C++ он так забавно отличается по концепциям, что кругозор волей-неволей расширяет.
Но годится ли такой язык для сугубо утилитарного программирования, например, GUI? Да плохо он для этого годится. И, пожалуй, лучшее доказательство -- посмотреть на любой вменяемый JS-фреймворк для написания сложного GUI. Скажем, лет пять назад я плотно имел дело с ExtJS, ныне Sencha ExtJS, и с Dojo. Стоит вчитаться, как там эмулируют наследование, вот уж где вечность из четырёх букв-то! И ведь видно, что хотят получить именно наследование, но готового механизма в языке нет. Именно такую ситуацию (почти все пользователи нуждаются в неком механизме, а в языке его нет) я и называю "язык не подходит для этих задач".
> Но годится ли такой язык для сугубо утилитарного программирования, например, GUI? Да
> плохо он для этого годится.Алан Кей в удивлении чешет затылок.
Алан Кей, как бы, не эквивалентен среднему быдлокодеру. А именно этим средним нужно клепать в разумные сроки иногда довольно сложные приложения. И тут JS адски неудобен (вместе с DOM, конечно), хотя костылить его как только не пытались. Вон, последний писк - reactive фреймворки, начавшиеся с AngularJS, с биндингами, иногда даже двусторонними. Концепций много - толку мало...Ну и Smalltalk, как ни крути, умер. Полагаю, во многом - как раз из-за своей даской динамичности, которая в продакшне скорее вредна, чем полезна. Можешь сравнить с джавой, которая уродлива со всех сторон, но "правильно" уродлива.
> Алан Кей, как бы, не эквивалентен среднему быдлокодеру.так, пардон, это не «язык не подходит» тогда, это быдлокодер не подходит. так и следует писать: «быдлокодер плохо подходит для создания GUI».
> Ну и Smalltalk, как ни крути, умер.
вот тут разработчики squeak, pharo, seaside, aida, swazoo, etc… и поставщики коммерческих смолтолков очень удивились своей высокой продуктивности из могилы. это я уже не говорю о том, что есть весьма навороченый, например, диалект смолтолка, который компилируется в машинный код через си (интересный проект, кстати).
> из-за своей даской динамичности, которая в продакшне скорее вредна, чем
> полезна.«в продакшене» она совершенно перпендикулярна. а вот hotpatching — очень, очень вкусен. эрланговцы тебе расскажут, какая это прелесть, спроси.
> Можешь сравнить с джавой, которая уродлива со всех сторон, но
> «правильно» уродлива.да не в этом дело совсем. но тут начинается совсем уже другая сказка.
Не, язык сменить как-то проще чем взять каких-то других былокодеров на место существующих. И, что характерно, с какими-нибудь дельфями, жабой, WPF или Qt и прилагающимися языками они вполне справляются с задачей.А твои примеры я сейчас погуглю, конечно, но то, что я ни про один и не слышал никогда, наводин на подозрения, что это какая-то экзотика. Мой любимец перл и то чуть-чуть живее, хотя тоже трупак, конечно.
И нет, в продакшне излишняя гибкость на фиг не нужна обычно. Нужно "от сих до сих" (правда, дя каждой области - пределы разные), а что за пределами - чтобы сделать было нельзя или чтобы валилось с ошибкой, крайне желательно - на этапе статического анализа. А хотпатчинг (я сам на эрланге маленько писал, если что) - он на самом деле мало где актуален. Обычно либо у тебя хилая системка из одной машины и ты её для патча спокойно выведешь из эксплуатации на некоторое время, либо у тебя балансировка и много хостов, тогда тем более по одному апдейтить не проблема ни разу. Это если веб, конечно - но сейчас кругом веб, да и для других сервисов оно актуально.
А как можно осмысленно скомпилировать насквозь динамический смаллтолк в машинный код - я вообще не понимаю.
> А твои примеры я сейчас погуглю, конечно, но то, что я ни
> про один и не слышал никогда, наводин на подозрения…что ты не интересуешься смолтолком.
> И нет, в продакшне излишняя гибкость на фиг не нужна обычно.
ещё раз тебе говорю: спроси у эрланговцев, «излишняя» ли гибкость hotpatching. спроси у них также, почему они обламываются делать extensive logging и дебаг-интерфейсы.
хинт: а зачем? какая проблема при необходимости подгрузить нужный модуль в работающий сервер, поковырять в оном сервере кишки и модуль выгрузить?
> крайне желательно — на этапе статического анализа.
нормальный объектный язык крайне сложно так проанализировать. даже в strongtalk типизация опциональная.
> хотпатчинг (я сам на эрланге маленько писал, если что) — он
> на самом деле мало где актуален. Обычно либо у тебя хилая
> системка из одной машины и ты её для патча спокойно выведешь
> из эксплуатации на некоторое время, либо у тебя балансировка и много
> хостов, тогда тем более по одному апдейтить не проблема ни разу.проблема в том, что ты рассматриваешь хотпатчинг только как средство «обновить сервер». а это далеко не так. хотпатчинг — это ещё и офигенно мошная система интроспекции, что позволяет, например, на лету по нужным параметрам профилировать рабочий сервер, а не искуственную фигню. при этом не обязательно ни заранее прописывать, что профилируешь, ни перезапускать сервер, ни держать его постоянно в состоянии «собираем профили». это ОЧЕНЬ круто, вообще-то.
> Это если веб, конечно — но сейчас кругом веб, да и
> для других сервисов оно актуально.не обязательно веб — сетевой ресурс просто. они разные бывают.
> А как можно осмысленно скомпилировать насквозь динамический смаллтолк в машинный код —
> я вообще не понимаю.а динамику никто и не забирает, она вся на месте. на, любопытствуй: http://piumarta.com/software/cola/
это практически смолтолк, написаный сам на себе и с биндингами к паре библиотек (которые — биндинги — делаются при помощи вкраплений сишного кода прямо в исходник на смолтолке, благодаря компиляции «через си»). весьма любопытный подход.
Тьфу, блин. Ттак перечисленное тобой - это сами смаллтолки плюс веб-тулзы. Неудивительно, что я их не знаю. И что? Покажи хоть что-то большое/успешное, что на нем написано. И сравни даже с тем же трупом перла, на котором будет эдак на три порядка больше абсолютно живых систем - и то трупом он от этого быть не перестаёт.
> Покажи хоть что-то большое/успешное, что на нем написано.так, с ходу — сайт GSOC2010, например. по сайтам seaside и aida походи, там тоже ссылки есть. внутренние системы вполне пишут. не превращайся в похаписта, пожалуйста.
Вот-вот, если для умеренно качественного решения типовой задачи, не требующей семи пядей во лбу, нужен разработчик высшего класса, это и есть "нетехнологично". То есть язык не подходит.
нужен разработчик, который умеет пользоваться вилкой и ложку несёт не в ухо, а в рот. но для тебя — я понимаю — это «семь пядей во лбу».
> Плагины с поддержкой Dart также подготовлены для...Список лучших IDE есть, спасибо Google!
Осталось малость, выбрать лучшего из лучших...))
До языка Fart уже недалеко.
нaписaл уже 10К строк, очень неплохо.
в сaмом деле похож нa яву но тольно снaружи, внутри используются динaмические
в отличие от явы типы.
javascript удобен когдa пишешь тысченку строк, a потом все стaновиться
слишком зaпутaнным.
Радует отличная документация языка Dart. Для начинающих отличный туториал. Информацию на русском тоже найти достаточно просто http://cultofdigits.com/dart-language/