Как стать автором
Обновить

Комментарии 188

Какой-то джаваскрипт для энтерпрайз-задротов. Чтобы жава/сишных программистов сажать писать формочки без переучивания на такой сложный, мутный и непонятный js?
НЛО прилетело и опубликовало эту надпись здесь
Конвертер из Dart в JavaScript написан на Python. Это такой тонкий троллинг?
Он на джаве написан.
Вы в исходники питоновского скрипта то смотрели? Он превращает HTML страницу со вставками Dart в HTML страницу со вставками JS, а для трансляции Dart в JS вызывает написанный на Java dartc.
Dart'Angan.
Dart Vader.
Удивительно, почему до вас никто не пошутил про это?
Трудно быть первым.
А мне понравилось. Ребята молодцы, в нужном направлении движутся.
В каком же?
В направлении возможности писать для веба что-то крупное, минимизируя ошибки и оптимизируя быстродействие. Что они, в общем-то, явно задекларировали.
а, ну да. гугл сказал, что на Dart делается меньше ошибок и больше быстродействие, и мы им поверим на слово.
Дебаг этого счастья будет очень тонким видом извращения.
Обоснуйте
А как вы представляете себе дебаг клиентской части, если она получается ковертером на питоне?
ОК. Разверну мысль.
Поскольку язык (по крайней мере на данном этапе) не поддерживается браузерами «из коробки», гугл решает эту проблему, предлагая транслятор из дарта в джаваскрипт. То есть на стороне разработчика будет дарт, на стороне пользователя (в браузере) стандартный джаваскрипт.
И когда у вас будет ошибка в 105-й строке файла в браузере, это совершенно не означает, что она там же в исходнике в дарте. И искать, откуда что берется простым дебагом… я себе это не представляю, учитывая, что конструкции дарта должны каким-то образом разворачиваться в стандартный джаваскрипт.
То есть многостраничный цикл в джаваскрипте, который работает как-то не так, может оказаться каким-нибудь банальным родным итератором в дарте.
НЛО прилетело и опубликовало эту надпись здесь
Я даже не сомневаюсь, что это в каком-то виде будет. И наверняка появится в web developer для новых версий хрома.
Но я очень боюсь себе представлять, как это будет работать в старых браузерах. Особенно в тех, чье название начинается на I…
НЛО прилетело и опубликовало эту надпись здесь
Думаю так же, как сейчас это происходит в GWT. Будет ключик компилятора, что-то вроде --pretty или --debug=on, при использовании которого js-код не обфуксируется и вообще выглядит максимально понятно. Так как функции и переменные имеют те же названия, а конструкции и выражения выглядят ну почти похоже (ибо сейчас у всех языков синтаксис в стиле С), отлаживать вполне удобно, никаких проблем не возникает.
Плюс плагин в браузере, позволяющий дебаг из среды разработки.
а программы на CoffeeScript как отлаживают? Впрочем, надеюсь, этот язык таки попадёт в браузеры нативно.
Чуть менее чем никак.
Искал информацию по этому вопросу, ничего вменяемого не нашел. Возможно что-то с тех пор и поменялось, если так, пусть меня поправят. Желательно со ссылками на инструменты.
Ну тогда хуже чем CoffeeScript, который тут кое-кто хвалит, не будет.
вы писали на CofeeScript чуть менее, чем нисколько, если думаете, что он не отлаживается.
Может поделитесь ссылкой на хотя бы один инструмент отладки?
если бы мне не было так лень что-то доказывать человеку с убеждением «не пробовал, но осуждаю», то я бы вам привёл сопоставление кода на CoffeeScript и его же, транслированного на JS. только умственно отсталый не сможет сопоставлять одно с другим.

вопреки распространённым заблуждениям, CoffeeScript не сжимает код, он даже комментарии на месте оставляет. ужиманием занимаются уже перед деплоем всякие uglifier'ы типа YUI и Closure.
Зачем все эти сложности, если можно было ограничиться ссылкой на дебаггер вашего любимого CoffeeScript для, например, IE8? Это заняло бы меньше времени и места, чем ваш комментарий о том, как вам лень и некогда.

Или вы как и ваш коллега ниже по треду тоже не знаете, что такое дебаг и чем это отличается от «сопоставления кода»?
нет никаких дебаггеров и не надо. CoffeeScript — это не отдельный язык. это модификация синтаксиса, которая позволяет скобочки лишний раз не писать.

попробуйте хоть раз его, а потом начинайте уже здесь демагогию про дебаг.
А, ну так бы сразу и сказали, что дебаггеров не надо. Стало бы ясно, что спор с вами не имеет смысла, потому как вы элементарно не пользуетесь важнейшим для разработчика инструментом.
Не надо заниматься софистикой. Какой дебаггер для JS используете Вы? Вот он же используется для CoffeeScript. Что в фразе «это модификация синтаксиса, которая позволяет скобочки лишний раз не писать» не понятно? Чукча писатель?
Эту модификацию синтаксиса поддерживают браузеры?
Вы вообще представляете как работает дебаггер?
ну так попробуйте для начала провести отладку кода встроенным дебаггером в IE, к примеру.

Вы не отвечаете на мой ответ :). Я вполне нормально отлаживаю Coffee в браузере. Потому что как уже неоднократно выше писали, он очень чисто транслируется в JS. И отладка Coffee ничем от отладки JS не отличается. Меняется только синтаксический сахар. И без компрессора – меняется очень чисто, практически строка в строку. Но Вам же все равно, что я пишу, мистер тролль? :)
вы отлаживаете JavaScript. который очень похож но мягко говоря не такой. и даже в родном джаваскрипте бывает сложно вести отладку когда дело касается анонимных функций, коллбэков и прочего.
А что будет в случае вложенных итераторов Coffee, думать не хочется.

И весь смысл отладки именно в том, что вы шаг за шагом идете по исходному коду, параллельно отслеживая состояние приложения. И если у вас между исходным кодом и реальным дополнительная прослойка, сей процесс становится или затрудненным или вообще невозможным.
Впрочем, подозреваю, что хитрыми плагинами к IDE или Firebug это можно решить, но примеров мне ни вы ни гугл не дали.
у меня ощущение, что вы элементарно не пользуетесь более важным для разработчика инструментом, чем дебаггером, — мозгом.
Мозг подсказывает не пользоваться поделиями, весь смысл которых в том, чтобы «скобочки не писать».
Хотя если вы синтаксис JavaScript не освоили, можете заменять его подобными костылями. Игрушка в целом забавная. Хоть и бесполезная.
чем и подтверждаете мою правоту.
Отлаживать CoffeeScript вполне нормально. А все потому что он следует идеологии «It's just JavaScript». Генерируемый JS код очень понятен, и так как структура языка по сути не меняется, найти нужное место в CoffeeScript Не составляет труда. Конечно по номеру строки не совпадает, но это терпимо.
Вы уверены, что правильно понимаете значение слов «отладка», «дебаггер», «точка остановки» и т.д.?
Отлаживать CoffeeScript вполне нормально. А все потому что он следует идеологии «It's just JavaScript». Генерируемый JS код очень понятен, и так как структура языка по сути не меняется, найти нужное место в CoffeeScript Не составляет труда. Конечно по номеру строки не совпадает, но это терпимо.
Отлаживать CoffeeScript вполне нормально. А все потому что он следует идеологии «It's just JavaScript». Генерируемый JS код очень понятен, и так как структура языка по сути не меняется, найти нужное место в CoffeeScript Не составляет труда. Конечно по номеру строки не совпадает, но это терпимо.
ну вот теперь понятно!)
А мне ещё одного раза не хватило :)
А не заслушать ли нам теперь начальника транспортного цеха?
Насчет дебага. Я решил пройти их туториал, и первый шаг в www.dartlang.org/docs/getting-started/ — поменять значение переменной.

Я поменял ее на «ыыы».

Я прошу прощения, но я получаю натуральный хуй :)
Пруфпик: habrastorage.org/storage1/86606ed3/db82f87c/24328acf/b6617fc3.png :)
Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.

В итоге теряется и динамичность кода, и возможность строгой проверки на этапе компиляции.

Вообще синтаксис отдалённо напоминает то, как должна была бы выглядеть Java в случае покупки Sun'а Google'ом. А так, подозреваю, грядут очередные судебные иски.

Ориентация очень подозрительная. Из Dart'а будут компилировать в JavaScript, и получится опять GWT.
Чем не угодил CoffeeScript, и зачем решили пожертвовать возможностью дебага (пока не будут написаны плагины, аналогичные GWT'шным для всех популярных редакторов) — не понятно.

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

По типизации код явно делится на два класса: если пишем протоитп или которокий кусок кода, не влияющий на быстродействие — можно и var использовать. А если у нас продакшн, которым занимается куча людей — пишем типы и получаем дополнительные надёжность/документацию/быстродействие.

CoffeeScript я не знаю, но глянул на вскидку — питонообразные отступы, отсутствие декларирования переменных, не то что типизации и классов. Лично я на это что-то крупное писать не стану — мне не охота кроме всего прочего ручками проверять ещё не забыл ли я где-то инициализировать кусок структуры данных, и не сунул ли я имя функции в виде строки вместо ссылки на неё.
Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.

C# тоже позволяет, и ничего.
извините, но не надо путать неявно типизированные переменные, объявленные через ключевое слово var и
>не типизированный код или строго типизированный или смешанный

C# только строготипизированный c возможностью явной или неявной типизации.
нетипизированный совсем другое.
С недавних пор у нас есть dynamic. Не совсем полноценный, но мы его любим всё равно)
а кто ж его не любит) однако от этого C# не перестает быть строготипизированным.
вы видели какой получается с использованием dynamic?
во-первых, переменной присваивается тип object
во-вторых, в данном подходе используется позднее связывание, которое опирается на возможности CLR 4. это уже не просто синтаксический сахар.

и к тому же, по вашей логике, например, благодаря LINQ, C# стал языком структурированных запросов? не совсем полноценный, но все же?
* какой код *, конечно же
По моей логике C# — гибридный язык, в котором существует возможность динамической типизации посредством специального псевдо-типа dynamic, работающего благодаря появившейся в .Net DLR. Также в нем присутствует возможность писать структурированные запросы в SQL-подобном синтаксисе при помощи глубоко интегрированного Linq.
Вы позабыли предмет этой дискуссии. Я лишь утверждаю, что на C# можно писать смешанный код, как статически типизированный, так и динамически (позднее связывание, аля динамическое разрешение типа на этапе выполнения, не важно, как оно там реализовано на уровне IL — через object с атрибутом, или еще как-то), и в этом нет ничего плохого, только все нужно к месту применять.
Я лишь утверждаю, что на C# можно писать смешанный код, как статически типизированный, так и динамически

наконец, пришли консенсусу.
почему началась наша дискуссия? правильно из-за утверждения
>Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.

C# тоже позволяет, и ничего.

просто нетипизированный язык != язык с динамической типизацией.
C# является строготипизированным языком со статической и динамической типизацией (опустим ее реализацию)
НЛО прилетело и опубликовало эту надпись здесь
Думаю вся суть в тому, что разработчик может «ускорить выполнение кода» (с потенциальной возможностью компилироваться), добавив статические типы. Прототипирует по-быстрому, а релиз/АПИ идет со статическими типами. Помоему, это удобно.
Может и добавят что-то. Но вообще-то если они сделают хорошую шуструю систему обмена событиями (а похоже на то), то событийная архитектура будет ничуть не хуже функциональной.
Ждем первого фреймверка с названием Vader
А чего все паникуют? JS никто не убирает из браузеров, не нравится, не используйте. Прям я смотрю все js-профи и отлично умеют его готовить.
НЛО прилетело и опубликовало эту надпись здесь
Разработать с нуля в 2011 такой унылый язык, это нужно постараться.
НЛО прилетело и опубликовало эту надпись здесь
Тогда времена были дикие, можно понять.
Это вы под драфту спецификации поняли? Вообще-то язык ещё в разработке, и, к примеру, куски FP в него добавить особых проблем нет (как сделанов D, например). Но уже понятно то, что на этом можно будет просто писать, в отличие от шаманства с JS, в котором подводных камней чуть ли не больше, чем в плюсах.
Есть мнение (далеко не только моё), что FP в D добавлено на редкость неудачно.
Я бы даже сказал, случайно.
По какому критерию вы предлагаете судить? Действительно, давайте обсуждать не текущее положение, а то светлое будущее которое когда то наступит.
Прочитаете JavaScript: The Good Part, поймете что на нем тоже можно просто писать.
Для веб не прокатит. Есть cofeescript.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я не кричу. Но пока, действительно, мне не нужно. Если доведут до нужного уровня, то можно пользоваться. А слепо верить в то, что это круто, потому что это сделал google, нет желания.
А вообще складывается ощущение, что его придумали программисты не_понимающие_javascript.
НЛО прилетело и опубликовало эту надпись здесь
Я бы сказал не «наоборот», а «еще и потому что». Тут, мне кажется, связано и с проблемой не понимания прототипного программирования — все привыкли к классам, и с недостатками javascript, связанная с областью в которой этот язык используется.
НЛО прилетело и опубликовало эту надпись здесь
Что-то не очень понимаю почему он «унылый» и «для веб не прокатит» и так далее.
С радостью начну его использовать.
мы и не сомневались. повесьте на будку самоубийств логотип Google, и она станет самым популярным семейным развлечением.
Оно в далвик-то умеет компилироваться, или это не решение проблемы Android-а с джавой, а просто еще один язык что бы был?
Причём тут Dalvik, если это язык для веб-разработки (замена JS)?
Хм, вроде и ни при чём, но идея хороша… Джава тяжеловесна всё-таки в написании, а вот эта штука- на вид как раз.
Java сейчас будет тяжеловата по судебным издержкам, а разработчики уже на Андроид и маркет подсели, и как-нибудь теперь переживут смену языка.
Java сейчас будет тяжеловата по судебным издержкам, а разработчики уже на Андроид и маркет подсели, и как-нибудь теперь переживут смену языка.
А что именно его делает специфичным для этой роли и непригодным к замене Java на Андроиде? Если уж Си и Окамл в js давно компилируются, то почему бы этому не компилироваться в Dalvik?
Пока браузеры не начнут поддерживать его нативно — толку в нем не густо, т.к. есть тот же CoffeeScript, как тут уже заметили. Хотя, конечно, это лучше чем GWT.

Непонятно, как планируется поддерживать Dart в IE, и непонятно, зачем нам некроссбраузерный скриптовый язык.

У меня такое ощущение, что в Google очень не любят JS. То GWT, то Dart…
ну почему — есть еще closure
Гугл больше чем кто либо нарвался на сложности написания приложений на JS (это при наличии очень даже квалифицированных специалистов). Может, не зря не любят?
Реально, у JS есть недостатки. Но они есть и у Java, и Python, и вообще у любого языка. Почему такое внимание именно к JS?
Для Java и Python как правило есть алтернативы и если что-то не устраивает, всегда можно использовать что-то другое. Для client-side кода в браузере алтернатив нет (имею ввиду чистый бразуер, без flash/silverlight/java/etc). Именно отсюда ноги растут у GWT, CoffeScript, Pyjamas, а теперь и Dart.
Реально, у JS есть недостатки. Но они есть и у Java, и Python, и вообще у любого языка. Почему такое внимание именно к JS?
Есть возможность пускать прямо dart если он поддерживается браузером и конвертировать в JS если нет.
<html>
  <body>
    <script type='application/dart'>
      void main() {
        HTMLElement element = document.getElementById('message');
        element.innerHTML = 'Hello from Dart';
      }
    </script>
    <div id='message'></div>
  </body>
</html>

Сохраните это в файл с расширением html и откройте любым браузером. У меня Google Chrome не запускает этот дартовский скрипт, а у вас?
Встроенная поддержка Dart в Хроме будет через несколько месяцев.
Если бы за языком не стоял Гугл, мало бы кто обратил на него внимание
Не угадал ни одного слова кроме Google
Весьма хорошо. Давно пора было ввести нормальные классы в JS. А теперь почти Java в моём браузере. Ждем вменяемой реализации в браузере.
Зачем конкретно в JS нужны классы а-ля жава?
У языка хватает недостатков, но, скажем так, альтернативный взгляд на ООП к ним вряд ли относится.

Вообще, зачем из скриптовых языков с таким упорством пытаются сделать жаву?
Получается объединение недостатков обоих подходов — тяжеловесность и ынтырпрайзнутость кода с одной стороны, и при этом заведомо невысокая производительность в виду скриптовости (ну и лишнего слоя абстракции при «компиляции» в JS) и отсутствие compile-time проверок типов с другой стороны.

Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
> Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.

Просто тогда не принято было делать абстрактные фабрики мостов визитёров синглтонов. Сейчас всё сложилось бы иначе!
>Зачем конкретно в JS нужны классы а-ля жава?

За тем, что возможность в рантайме увидеть класс объекта — многого стоит, существенно облегчает отладку (в js же объекты это в сущности такие себе хэш-мапы). Ущербность ООП на прототипах убедительно показывает несметное множество библиотек, делающих ООП в js похожим на ООП в нормальных языках программирования. Хорошая система пакетов (import) тоже must have, что опять-таки иллюстрируется обилием разной степени кривости велосипедов для решения этой проблемы.

>Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.

Не показатель. Флэш тоже в этом направлении движется, стоило только улучшить поддержку HTML Video. Одно дело плагин, прибитый сбоку гвоздями и другое — стандартизовання функция, встроенная в браузер.
Ущербность ООП на прототипах убедительно показывает несметное множество библиотек, делающих ООП в js похожим на ООП в нормальных языках программирования.

Не поясните логическое построение, приведшее вас к такому выводу?
Поясню. Вот почему почти никто сейчас не хочет писать вот так:
javascript.ru/tutorial/object/inheritance

а непременно так
dojotoolkit.org/reference-guide/dojo/declare.html#dojo-declare
или так
www.rogerwilco.ru/2011/04/sencha-extjs.html
или так
qooxdoo.org/documentation/0.7/oo_feature_summary
или так
www.phpeveryday.com/articles/MooTools-Basic-Creating-Classes-MooTools-P919.html

и так далее…

Вот, кстати, наткнулся на показательный пост
www.askdev.ru/jquery/4377/%D0%9E%D0%9E%D0%9F-%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D1%8B-%D0%B2-jQuery/

Моё мнение — язык (JS) не предоставляет удобных языковых примитивов, на которых удобно писать ООП код. Вот все и изгаляются кто во что горазд. Впрочем, JS тут не один, та же ситуация с Perl и Tcl.
Имхо, JS очень гибок, раз позволяет такие финты на уровне языка. Но, имхо, это именно та гибкость, которая не нужна. Нужно ввести поддержку ООП в язык и привести всё к общему знаменателю. Но, поскольку эволюционным путём (изменение самого JS) это, по понятным причинам, вряд ли выйдет — приходится революционным (Dart).
> Поясню. Вот почему почти никто сейчас не хочет писать вот так:

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

> Моё мнение — язык (JS) не предоставляет удобных языковых примитивов, на которых удобно писать ООП код.

Нет. JS не предоставляет удобных языковых примитивов, на которых удобно писать C++-like ООП код.

JS предоставляет достаточные и вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код.

> Нужно ввести поддержку ООП в язык и привести всё к общему знаменателю.

Кто вам сказал, что в JS нет ООП? Что такое общий знаменатель?

Да, кстати, если вы анчнете говорить про ООП в стиле С++, поспешу вас огорчить: ООП в С++ даже близко не является тем, чем оно должно являться по задумке создателя ООП как такового Алана Кея. Это так, в качестве пищи для размышления.
> Потому что никто не занимается популяризацией JS, как нормального, полноценного языка. Подавляющее большиснтво программистов до сих пор считают его этаким мелким скриптовым языком и пытаются подходить к нему с точки зрения своих колоколен.

Не удобно, вот и не популяризируют. Сваяли свои классовые обертки — и погнали. Уж писателей-то тех JS-библиотек сложно упрекнуть в незнании JS. Стало быть, они спроектировали библиотеки именно так как им было удобно. Использовать (цитирую) вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код, видимо, на практике оказалось не так уж и удобно.

> Что такое общий знаменатель?

Хотя-бы то, что сделал Adobe в AS2 / AS3, для начала. Т.е. упрятать потроха из прототипов поглубже в реализацию. Впрочем, вроде, ECMAScript туда потихоньку движется.

> Да, кстати, если вы анчнете говорить про ООП в стиле С++

Читаем мой корневой в этой теме комментарий:

Весьма хорошо. Давно пора было ввести нормальные классы в JS. А теперь почти Java в моём браузере. Ждем вменяемой реализации в браузере.


В AS3, в отличии от AS2 нет «потрохов из прототипов».
Прототипы там никуда не делись. Их просто действительно очень хорошо упрятали и назвали «ой, это такая старая штука, еще из прошлого»
В AS2 class-driven ООП было реализовано через prototype-driven.
В AS3 — с точностью до наоборот, prototype-driven реализуется на базе class-driven.
Чувствуете разницу?

Прототипы были оставлены скорее всего для формального соответствия ECMA-262.
Adobe пыталась пропихнуть свой диалект жабаскрипта в W3C, но не получилось.
> Adobe пыталась пропихнуть свой диалект жабаскрипта в W3C

Ну и слава богу.

За разъяснение спасибо
> Не удобно, вот и не популяризируют.

Неверно.

> Использовать (цитирую) вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код, видимо, на практике оказалось не так уж и удобно.

Не надо выдавать инерцию мышления за правильные подходы к программированию.

> Хотя-бы то, что сделал Adobe в AS2 / AS3, для начала. Т.е. упрятать потроха из прототипов поглубже в реализацию.

Угу. Убрать из языка собственно сам язык и рассказывать, что как это круто.

> Впрочем, вроде, ECMAScript туда потихоньку движется.

Не движется, и это правильно

> Весьма хорошо. Давно пора было ввести нормальные классы в JS. А теперь почти Java в моём браузере

Ну да. Нет ООП, кроме С++-like, ага
Интересно, как ответом на утверждение «неудобно» может быть «неверно»? Это все-таки субъективное ощущение.
Так и может быть. ЦИтирую то, что вы намеренно опустили:
Не надо выдавать инерцию мышления за правильные подходы к программированию.


Кому-то после С++ и в Руби будет неудобно программировать? Выкинем Руби или натянем на него ООП в стиле С++ в обязательном порядке?
> Вот, кстати, наткнулся на показательный пост
www.askdev.ru/jquery/4377/%D0%9E%D0%9E%D0%9F-%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D1%8B-%D0%B2-jQuery/

Читаем:
В MooTools они есть, а в jQuery приходится пользоваться прототипами, что ужасно не удобно. Был бы очень благодарен, если бы кто-нибудь выдрал классы из MooTools в jQuery… Ну или может есть уже такой плагин для jQuery?


То есть человек, судя по всему, неспособен понять, что такое прототипы, и как ими пользоваться. Ему, видите ли, неудобно, потому что он, видите ли, привык к классам.

По-моему, пост действительно показателен. Он показывает профнепригодность автора топика по ссылке.
И чем же вас «ынтырпрайзнутость» не устраивает?
Арргх, англичане вы.
Darth Vader, не Dart Vader
А то что Google вместо Googol — тебя не нервирует?
Dart — это слово с определенным значением, которое не пересекается с Вейдером. Google — просто искажение без изначального смысла.
Документация к этому языку должна состоять из одной строчки: «Используй силу, Люк!»
Кому нужны ООП и статическая типизация при написании клиентской части, уже пользуются haXe.
Для тех, кто хочет уже поиграться с новым ЯП и использовать его в качестве сервера, то в примерах есть имплементация HTTP и пример чат сервера и клиента: goo.gl/uAWm6
Как сказал бы Мицгол, «прозреваю Dart.NET». В скором будущем.
Из 5-и букв тоже весело :)
а если попробовать «фяч», то прямо как в жизни
Hello, фяч!

Должно быть что-то другое?
Там было нехорошее слово которое пишут на заборах, честно.
Поменял. Всё работает.

Может, вы что-то не то в гугле искали, и он так «интеллектуально» подставляет?
> Hello, опр!
объясните шутку
Они уже поправили… Это удивительно, но факт, я сам пробовал, вместо кириллицы в зависимости от количества букв он подставлял различные странные слова… Вместо трех букв он подставлял то самое емкое русское слово… Вместо пяти подставлял — «Hello, Говно», вместо семи — «Hello, Русский» и т.д. Это видимо была какая-то неудачная шутка русского офиса или взлом, но это было, а сейчас исправили.
void main() напомнило мне это что то )))
НЛО прилетело и опубликовало эту надпись здесь
Сейчас в трансляторе Dart -> JavaScript не работает twitter.com/#!/DmitrySoshnikov/status/123337606758019072
А что теперь с GWT будет? А примеры серверной части есть?
Ничего не будет, закопают. Давно говорил, что это временный костыль.
Только дарт дарт дарт дарт дарт дарт дарт дарт
Описание классса Date
int month
Returns the month in the year [1..12].

C 1 по 12. Ну наконец-то! :) Работа с месяцами в явскрипте периодически рвет мозг.
Почитал туториалы, так и не понял как область видимости членов класса задается (private, protected, public)
Ага, спасибо.

Но по мне так не очень хорошая идея. Сделали бы лучше традиционно. И непонятно, private оно с подчеркиванием или protected.
Ну вот почему после того как руби уже изобретён и используется, всякие инноваторы пытаются делать свои interface, implements, final? Ну стыдно должно быть уже.
А почему сразу Руби? Оно и до Руби всё было, 25 лет назад в Делфи. И раньше, подозреваю.
Пардон, насчет 25 лет конечно же загнул, но более 15 — точно.
Изящнее руби языка пока не придумали. Дельфи та ещё кака. Даже шарпы получше будут.
Почему даже? шарп великолепный язык. А Руби — каша из решёток собачек и анперсандов.
Тут всё дело в том, что я программировал и на том, и на том, и могу сравнивать. А вы нет. И сравнивать не можете. И решёточек в руби нет.
Я программировал на шарпе и на делфи и на с++ и на многом другом. Руби только пробовал, синтаксисом не проникся и бросил. А решетками там коментарии вроде помечаются.
Ну вот в этом всё и дело. А чтобы проникнуться, достаточно сравнить имплементации простейших задач — fizzbuzz, map-reduce и иже с ними. И всё станет сразу очевидно.
Чем вам кстати Делфи не угодил?
Дельфи уродлив как язык. Тяжёлое наследие паскаля. Он практически ничего не может ведь. А ужасные gui обвесы из-за которых он использовался архитектурно отвратительны.
>>Дельфи уродлив как язык. Тяжёлое наследие паскаля
конкретнее, пожалуйста

>>А ужасные gui обвесы из-за которых он использовался архитектурно отвратительны.
Вы имеете в виду VCL? По нынешним меркам действительно очень бедная библиотека, но архитектурно она очень продумана. Да и откровенных багов я в ней всего пару штук за 8 лет нашел.
Сила архитектуры в возможностях её модификации. VCL мало того что имел уродливые интерфейсы, так ещё и был сильносвязанным и монолитным. Куча антипаттернов была применена при его проектировании. Его писали как хотели вообще.

А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности, чтобы решать задачи без костылей. Дельфи эти особенности и достались.
>>Сила архитектуры в возможностях её модификации
Спорно, скорее сила архитектуры стандартной библиотеки в универсальности предлагаемых архитектурой решений. Зачем нужна стандартная библиотека если её надо модифицировать под задачу?

>>Его писали как хотели вообще
Вы прям срываете покровы :) Я понимаю что сейчас очень популярно хаять Делфи, но все же мне интересно как человеку писавшему на Delphi много лет весьма коммерчески-успешные продукты, конкретные примеры кривизны VCL.

>>А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности
Это лирика. Синтаксис паскаля — максимально приближен к естественным языкам, оттого код на нём получается максимально читабельным. Верите, работая много лет в команде разработчиков Delphi мы использовали комментарии только в очень редких нетривиальных случаях. Потому что не было необходимости. Пересев на C++/Qt я такую необходимость ощутил.

PS: я прекрасно знаю конкретные недостатки Delphi и VCL. А вы, похоже, нет.
Конкретные недостатки дельфи я тоже знаю и запарюсь перечислять. Начинается всё от неудобной работы с массивами и строками, а заканчивается «синтаксисом, максимально приближенным к естественным языкам», который настолько избыточен, что основное время написания занимает расстановка бегинов, эндов и варов (в начале функций).

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

Да, я не могу тут описать всей горы недостатков дельфи и vcl, поскольку не писал уже на нём лет 6 и не помню практически ничего. Зато прекрасно помню как мне пришлось дрючиться, чтобы добавить нужную возможность в компонент. Сила любого языка и фреймворка в возможности модафикации. Потому что нельзя охватить весь спектр задач, которые необходимо реализовать. И если задача, выходящая за рамки сценариев требует работы чуть ли не больше, чем написание всей библиотеки компонентов (утрирую), то это говно библиотека, так ведь? Слабая связанность ведёт к повышению мощности бибилотеки. А мощь языка заключается в возможности минимальными силами реализовывать то, что надо. А в дельфи даже рефлексий для этого нет. Да там ничего для этого нет. Не хватает выразительности.
Знаете, клепать формочки на делфи не так уж и удобно, как кажется на первый взгляд. Потому что с таким подходом в конце концов получается бессмысленная каша. Вы видимо и попались в эту ловушку обманчивой простоты.

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

Да, по нынешним меркам язык устарел, но это не повод чтобы закидать его говном. Многое из Делфи возродилось в С#, да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Да нет же, никуда я не попадался. Я понимаю, что на дельфи можно писать приложения любой сложности. На ассемблере, кстати, тоже можно писать приложения любой сложности. Но зачем? И стоят ли затраченные усилия полученных результатов?

> Делфи возродилось в С#,
Поэтому я и шарп не полюбил, кстати. Хотя, должен признать, в шарпе всё не так запущено.

> да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Точно, это вы по begin-end определили? Взгляните на аду, смоллток и эффель и сразу станет ясно, откуда ноги у паскаля.
Ну вероятно, потому что руби держится на силах одного весьма своеобразного японца, который ни с кем особо не хочет делиться любимой игрушкой.
И при всей красоте языка он несет с собой еще и целую гору крайне специфичных решений, которые очень сильно ограничивают его применение.
Руби сейчас держится на силах комьюнити. Японех, конечно, влияет на развитие языка, но всё меньше и меньше. А применение его ограничивают разве что архитектурные решения интерпретатора типа GIL или туповатого GC. Это решается использованием альтернативных интерпретаторов типа JRuby или Rubinius. А синтаксис несёт кучу специфичных решений, которые мало того, что не препятствуют, а ещё и способствуют появлению новых применений.
Комьюнити развивает фреймворки, библиотеки. И это хорошо.
Но ввергающие в ступор проблемы вроде медленного интерпретатора или отвратительной работы с кодировками никуда не исчезают. И вряд ли исчезнут.
И альтернативы, увы, ничего не решают. И тот самый вкуснейший синтаксис и тянет большинство проблем. Когда стоит переписать красивейший код не используя синтаксические примочки руби… и код начинает работать в разы быстрее. Это удручает.
> Когда стоит переписать красивейший код не используя синтаксические примочки руби… и код начинает работать в разы быстрее. Это удручает.

Вы не правильно его готовите. Покажите код до и после. Любой пример. Я покажу, как надо сделать, чтобы было и быстро, и красиво.
попросите примеров у разработчиков твиттера, которые спрыгнули с руби в пользу других языков, потому что у них и быстро и красиво не получилось.
Кстати, это единственные люди, которые зачем-то спрыгнули. Но и у них были проблемы не с языком, а с интерпретатором.
Остальные просто и не запрыгивали. Увы, но стоит выйти на приличную нагрузку, как единственным решением становится покупка большого количества серверов… или уход в другие языки :(
> Ага, не глобальные, а просто мелкие. То что интерпретатор в четыре раза медленнее питона или PHP — это мелочь же :)

И снова путаемся в понятиях. У языка почти нет недостатков. У интерпретатора есть.

Опять же, данные не верные. Пхп медленнее даже руби. А питон быстрее только потому что за него взялся гугл со своими возможностями. Но это не отменяет того факта, что при всей медленности руби тот же ror порвёт на тряпки по скорости любой полноценный фреймворк на пхп или питоне.

> Остальные просто и не запрыгивали. Увы, но стоит выйти на приличную нагрузку, как единственным решением становится покупка большого количества серверов… или уход в другие языки :(

Вот у вас таких ситуаций просто куча была, я полагаю. Иногда приходится и на ассемблере писать. У руби есть своя ниша. К слову, очень объёмная. И она постоянно расширяется.

Блин, вот а фак эм ай райтинг. Вы не видели таких нагрузок и никогда не увидите.
А как вы собираетесь писать на языке, не используя интерпретатор?
Будь язык сколь угодно совершенным, если под него не будет инфраструктуры, то никто на нем ничего не будет реализовывать.

А на руби медленный интерпретатор, ограниченное предложение хостинга, проблемы с кодировками, специфичность IDE и т.д.
И никакая красота синтаксиса это не компенсирует. Увы. Собственно, Руби практически ровестник PHP, но пропасть в популярности у них катастрофическая. И боюсь, что она не преодолеется, потому как никакой серьезной поддержки за Ruby так и не появилось.
Инфраструктура у руби мощнее, чем у пхп или того же питона. Решения есть для любых задач.

У руби медленный интерпретатор, но он не настолько медленный, чтобы обращать на это внимание. Руби быстрее пхп и догоняет питон местами. И догонит ещё, хотя это не обязательно.

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

Проблем с кодировками у руби нет. То есть вообще нет. А у пхп есть. И у питона.

Для руби не нужен иде вообще. Для руби вполне достаточно простого редактора.

Пропасть с пхп преодолевать не нужно. Иначе придут пхпшники и всё изговнякают. Популярность руби не нужна — он уже достаточно популярен у заказчиков и чем меньше индусов в него придёт — тем больше я заработаю.

Поддержки руби, кстати, тоже более чем достаточно.
Хорошая у вас секта, одобряю! :)
Стараемся ) Слава Матзу! \о
А теперь то же самое, но по-японски! :)
Я не знаю японского. А вы в гости заглядывайте. У нас сеансы периодически, да и вообще весело. Может даже, примете учение Его.
Да я за руби лет семь приглядываю. Язык нравится, но стоит начать применять, сразу натыкаюсь на грабли, которых нет, а все ссылки в гугле ведут на страницы секты, где говорят, что этого нет или это вам и не надо.

Поэтому руби у меня живет в скриптах автоматизации или парсинге. В общем там, где единственный пользователь это я сам.
Ну хер знает. Может, вам не везёт просто. + руби относительно можно пользоваться вот только последние 3-4 года.

И да, если адепты говорят, что вам этого не надо — значит действительно этого вам не надо, а есть нормальное решение задачи.

Руби — самодокументируемый язык, поэтому как нельзя лучше подходит для работы командами.
Ага. Я как-то пришел на форум с вопросом «у меня есть сервис, который отдает данные в win-1251, что делать». Мне объяснили, что мне это не надо.

А что сервис сторонний и никто его ради меня не будет переделывать в utf-8, всем пофиг. Программисты на руби живут в светлом чистом мире, где все люди братья и пользуются только одной кодировкой. Ну и так далее.
Ну значит или форум говно или одно из двух. Берётся iconv и всё становится прекрасно и круто.
Задам вам мой любимый вопрос: если вы так знаете и любите Руби, назовите пожалуйста его недостатки. PS: Этот вопрос я задаю всем соискателям на любую технологию.
Основные недостатки в интерпретаторе. Он медленный. Он с GIL, он с туповатым GC. Это решаемо со временем, уже решено даже.

У руби как языка есть пара недостатков — не очень красиво реализована работа с utf и вообще с кодировками, например. Хотя работать можно.
ОК, видно вы не новичок в языке. Больше никаких замечаний к Ruby нет лично у вас?

Вы удивитесь, сколько человек ставит в ступор подобный вопрос о C++/Qt или о Delphi/VCL.
Это вопрос-тест. Профессионал должен знать недостатки своего инструмента.
Руби очень хорошо продуман, он интуитивно понятен. Если у него и есть недостатки, то не гобальные, а просто очень мелкие. Столкнуться с которыми вероятность очень мала. Руби достаточно выразителен, чтобы найти достаточно простое решение любой задачи.

Ага, не глобальные, а просто мелкие. То что интерпретатор в четыре раза медленнее питона или PHP — это мелочь же :)
один раз бы все вставили на борт всех браузеров common lisp и у нас был бы гибкий язык с возможностью отстрелить себе ногу.
Здорово, но читерско.

Во, первых, опция --compile_all роль сыграла, а во-вторых, использование класса вместо простого print.

Эти манипуляции, конечно же, не отменят того факта, что авторы дарта серьёзно и глобально подошли к задаче )
> Класс может осуществить несколько интерфейсов

скажите, вас самого не коробит от такого? Или вы просто используете автоматический перевод?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории