Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 188
Какой-то джаваскрипт для энтерпрайз-задротов. Чтобы жава/сишных программистов сажать писать формочки без переучивания на такой сложный, мутный и непонятный js?
Конвертер из Dart в JavaScript написан на Python. Это такой тонкий троллинг?
Он на джаве написан.
Вы в исходники питоновского скрипта то смотрели? Он превращает HTML страницу со вставками Dart в HTML страницу со вставками JS, а для трансляции Dart в JS вызывает написанный на Java dartc.
Darth JavaScript!
А мне понравилось. Ребята молодцы, в нужном направлении движутся.
Получился ScalaScript
Дебаг этого счастья будет очень тонким видом извращения.
Обоснуйте
А как вы представляете себе дебаг клиентской части, если она получается ковертером на питоне?
ОК. Разверну мысль.
Поскольку язык (по крайней мере на данном этапе) не поддерживается браузерами «из коробки», гугл решает эту проблему, предлагая транслятор из дарта в джаваскрипт. То есть на стороне разработчика будет дарт, на стороне пользователя (в браузере) стандартный джаваскрипт.
И когда у вас будет ошибка в 105-й строке файла в браузере, это совершенно не означает, что она там же в исходнике в дарте. И искать, откуда что берется простым дебагом… я себе это не представляю, учитывая, что конструкции дарта должны каким-то образом разворачиваться в стандартный джаваскрипт.
То есть многостраничный цикл в джаваскрипте, который работает как-то не так, может оказаться каким-нибудь банальным родным итератором в дарте.
Поскольку язык (по крайней мере на данном этапе) не поддерживается браузерами «из коробки», гугл решает эту проблему, предлагая транслятор из дарта в джаваскрипт. То есть на стороне разработчика будет дарт, на стороне пользователя (в браузере) стандартный джаваскрипт.
И когда у вас будет ошибка в 105-й строке файла в браузере, это совершенно не означает, что она там же в исходнике в дарте. И искать, откуда что берется простым дебагом… я себе это не представляю, учитывая, что конструкции дарта должны каким-то образом разворачиваться в стандартный джаваскрипт.
То есть многостраничный цикл в джаваскрипте, который работает как-то не так, может оказаться каким-нибудь банальным родным итератором в дарте.
Думаю так же, как сейчас это происходит в GWT. Будет ключик компилятора, что-то вроде --pretty или --debug=on, при использовании которого js-код не обфуксируется и вообще выглядит максимально понятно. Так как функции и переменные имеют те же названия, а конструкции и выражения выглядят ну почти похоже (ибо сейчас у всех языков синтаксис в стиле С), отлаживать вполне удобно, никаких проблем не возникает.
а программы на CoffeeScript как отлаживают? Впрочем, надеюсь, этот язык таки попадёт в браузеры нативно.
Чуть менее чем никак.
Искал информацию по этому вопросу, ничего вменяемого не нашел. Возможно что-то с тех пор и поменялось, если так, пусть меня поправят. Желательно со ссылками на инструменты.
Искал информацию по этому вопросу, ничего вменяемого не нашел. Возможно что-то с тех пор и поменялось, если так, пусть меня поправят. Желательно со ссылками на инструменты.
Ну тогда хуже чем CoffeeScript, который тут кое-кто хвалит, не будет.
вы писали на CofeeScript чуть менее, чем нисколько, если думаете, что он не отлаживается.
Может поделитесь ссылкой на хотя бы один инструмент отладки?
если бы мне не было так лень что-то доказывать человеку с убеждением «не пробовал, но осуждаю», то я бы вам привёл сопоставление кода на CoffeeScript и его же, транслированного на JS. только умственно отсталый не сможет сопоставлять одно с другим.
вопреки распространённым заблуждениям, CoffeeScript не сжимает код, он даже комментарии на месте оставляет. ужиманием занимаются уже перед деплоем всякие uglifier'ы типа YUI и Closure.
вопреки распространённым заблуждениям, CoffeeScript не сжимает код, он даже комментарии на месте оставляет. ужиманием занимаются уже перед деплоем всякие uglifier'ы типа YUI и Closure.
Зачем все эти сложности, если можно было ограничиться ссылкой на дебаггер вашего любимого CoffeeScript для, например, IE8? Это заняло бы меньше времени и места, чем ваш комментарий о том, как вам лень и некогда.
Или вы как и ваш коллега ниже по треду тоже не знаете, что такое дебаг и чем это отличается от «сопоставления кода»?
Или вы как и ваш коллега ниже по треду тоже не знаете, что такое дебаг и чем это отличается от «сопоставления кода»?
нет никаких дебаггеров и не надо. CoffeeScript — это не отдельный язык. это модификация синтаксиса, которая позволяет скобочки лишний раз не писать.
попробуйте хоть раз его, а потом начинайте уже здесь демагогию про дебаг.
попробуйте хоть раз его, а потом начинайте уже здесь демагогию про дебаг.
А, ну так бы сразу и сказали, что дебаггеров не надо. Стало бы ясно, что спор с вами не имеет смысла, потому как вы элементарно не пользуетесь важнейшим для разработчика инструментом.
Не надо заниматься софистикой. Какой дебаггер для JS используете Вы? Вот он же используется для CoffeeScript. Что в фразе «это модификация синтаксиса, которая позволяет скобочки лишний раз не писать» не понятно? Чукча писатель?
Эту модификацию синтаксиса поддерживают браузеры?
Вы вообще представляете как работает дебаггер?
ну так попробуйте для начала провести отладку кода встроенным дебаггером в IE, к примеру.
Вы вообще представляете как работает дебаггер?
ну так попробуйте для начала провести отладку кода встроенным дебаггером в IE, к примеру.
Вы не отвечаете на мой ответ :). Я вполне нормально отлаживаю Coffee в браузере. Потому что как уже неоднократно выше писали, он очень чисто транслируется в JS. И отладка Coffee ничем от отладки JS не отличается. Меняется только синтаксический сахар. И без компрессора – меняется очень чисто, практически строка в строку. Но Вам же все равно, что я пишу, мистер тролль? :)
вы отлаживаете JavaScript. который очень похож но мягко говоря не такой. и даже в родном джаваскрипте бывает сложно вести отладку когда дело касается анонимных функций, коллбэков и прочего.
А что будет в случае вложенных итераторов Coffee, думать не хочется.
И весь смысл отладки именно в том, что вы шаг за шагом идете по исходному коду, параллельно отслеживая состояние приложения. И если у вас между исходным кодом и реальным дополнительная прослойка, сей процесс становится или затрудненным или вообще невозможным.
Впрочем, подозреваю, что хитрыми плагинами к IDE или Firebug это можно решить, но примеров мне ни вы ни гугл не дали.
А что будет в случае вложенных итераторов Coffee, думать не хочется.
И весь смысл отладки именно в том, что вы шаг за шагом идете по исходному коду, параллельно отслеживая состояние приложения. И если у вас между исходным кодом и реальным дополнительная прослойка, сей процесс становится или затрудненным или вообще невозможным.
Впрочем, подозреваю, что хитрыми плагинами к IDE или Firebug это можно решить, но примеров мне ни вы ни гугл не дали.
у меня ощущение, что вы элементарно не пользуетесь более важным для разработчика инструментом, чем дебаггером, — мозгом.
Отлаживать 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 :)
Я поменял ее на «ыыы».
Я прошу прощения, но я получаю натуральный хуй :)
Пруфпик: habrastorage.org/storage1/86606ed3/db82f87c/24328acf/b6617fc3.png :)
Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.
В итоге теряется и динамичность кода, и возможность строгой проверки на этапе компиляции.
Вообще синтаксис отдалённо напоминает то, как должна была бы выглядеть Java в случае покупки Sun'а Google'ом. А так, подозреваю, грядут очередные судебные иски.
Ориентация очень подозрительная. Из Dart'а будут компилировать в JavaScript, и получится опять GWT.
Чем не угодил CoffeeScript, и зачем решили пожертвовать возможностью дебага (пока не будут написаны плагины, аналогичные GWT'шным для всех популярных редакторов) — не понятно.
Принять участие хочется только в публичной казни.
В итоге теряется и динамичность кода, и возможность строгой проверки на этапе компиляции.
Вообще синтаксис отдалённо напоминает то, как должна была бы выглядеть Java в случае покупки Sun'а Google'ом. А так, подозреваю, грядут очередные судебные иски.
Ориентация очень подозрительная. Из Dart'а будут компилировать в JavaScript, и получится опять GWT.
Чем не угодил CoffeeScript, и зачем решили пожертвовать возможностью дебага (пока не будут написаны плагины, аналогичные GWT'шным для всех популярных редакторов) — не понятно.
Принять участие хочется только в публичной казни.
Синтаксис как раз хорош — где надо компактен, где надо — явно описывается, что происходит. Ну и мои любимые фигурные скобки и точки с запятыми присутствуют :-)
По типизации код явно делится на два класса: если пишем протоитп или которокий кусок кода, не влияющий на быстродействие — можно и var использовать. А если у нас продакшн, которым занимается куча людей — пишем типы и получаем дополнительные надёжность/документацию/быстродействие.
CoffeeScript я не знаю, но глянул на вскидку — питонообразные отступы, отсутствие декларирования переменных, не то что типизации и классов. Лично я на это что-то крупное писать не стану — мне не охота кроме всего прочего ручками проверять ещё не забыл ли я где-то инициализировать кусок структуры данных, и не сунул ли я имя функции в виде строки вместо ссылки на неё.
По типизации код явно делится на два класса: если пишем протоитп или которокий кусок кода, не влияющий на быстродействие — можно и var использовать. А если у нас продакшн, которым занимается куча людей — пишем типы и получаем дополнительные надёжность/документацию/быстродействие.
CoffeeScript я не знаю, но глянул на вскидку — питонообразные отступы, отсутствие декларирования переменных, не то что типизации и классов. Лично я на это что-то крупное писать не стану — мне не охота кроме всего прочего ручками проверять ещё не забыл ли я где-то инициализировать кусок структуры данных, и не сунул ли я имя функции в виде строки вместо ссылки на неё.
Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.
C# тоже позволяет, и ничего.
извините, но не надо путать неявно типизированные переменные, объявленные через ключевое слово var и
>не типизированный код или строго типизированный или смешанный
C# только строготипизированный c возможностью явной или неявной типизации.
нетипизированный совсем другое.
>не типизированный код или строго типизированный или смешанный
C# только строготипизированный c возможностью явной или неявной типизации.
нетипизированный совсем другое.
С недавних пор у нас есть dynamic. Не совсем полноценный, но мы его любим всё равно)
а кто ж его не любит) однако от этого C# не перестает быть строготипизированным.
вы видели какой получается с использованием dynamic?
во-первых, переменной присваивается тип object
во-вторых, в данном подходе используется позднее связывание, которое опирается на возможности CLR 4. это уже не просто синтаксический сахар.
и к тому же, по вашей логике, например, благодаря LINQ, C# стал языком структурированных запросов? не совсем полноценный, но все же?
вы видели какой получается с использованием dynamic?
во-первых, переменной присваивается тип object
во-вторых, в данном подходе используется позднее связывание, которое опирается на возможности CLR 4. это уже не просто синтаксический сахар.
и к тому же, по вашей логике, например, благодаря LINQ, C# стал языком структурированных запросов? не совсем полноценный, но все же?
* какой код *, конечно же
По моей логике C# — гибридный язык, в котором существует возможность динамической типизации посредством специального псевдо-типа dynamic, работающего благодаря появившейся в .Net DLR. Также в нем присутствует возможность писать структурированные запросы в SQL-подобном синтаксисе при помощи глубоко интегрированного Linq.
Вы позабыли предмет этой дискуссии. Я лишь утверждаю, что на C# можно писать смешанный код, как статически типизированный, так и динамически (позднее связывание, аля динамическое разрешение типа на этапе выполнения, не важно, как оно там реализовано на уровне IL — через object с атрибутом, или еще как-то), и в этом нет ничего плохого, только все нужно к месту применять.
Вы позабыли предмет этой дискуссии. Я лишь утверждаю, что на C# можно писать смешанный код, как статически типизированный, так и динамически (позднее связывание, аля динамическое разрешение типа на этапе выполнения, не важно, как оно там реализовано на уровне IL — через object с атрибутом, или еще как-то), и в этом нет ничего плохого, только все нужно к месту применять.
Я лишь утверждаю, что на C# можно писать смешанный код, как статически типизированный, так и динамически
наконец, пришли консенсусу.
почему началась наша дискуссия? правильно из-за утверждения
>Dart дает возможность программисту выбрать создавать не типизированный код или строго типизированный или смешанный.
C# тоже позволяет, и ничего.
просто нетипизированный язык != язык с динамической типизацией.
C# является строготипизированным языком со статической и динамической типизацией (опустим ее реализацию)
Думаю вся суть в тому, что разработчик может «ускорить выполнение кода» (с потенциальной возможностью компилироваться), добавив статические типы. Прототипирует по-быстрому, а релиз/АПИ идет со статическими типами. Помоему, это удобно.
Может и добавят что-то. Но вообще-то если они сделают хорошую шуструю систему обмена событиями (а похоже на то), то событийная архитектура будет ничуть не хуже функциональной.
Ждем первого фреймверка с названием Vader
А чего все паникуют? JS никто не убирает из браузеров, не нравится, не используйте. Прям я смотрю все js-профи и отлично умеют его готовить.
Разработать с нуля в 2011 такой унылый язык, это нужно постараться.
Это вы под драфту спецификации поняли? Вообще-то язык ещё в разработке, и, к примеру, куски FP в него добавить особых проблем нет (как сделанов D, например). Но уже понятно то, что на этом можно будет просто писать, в отличие от шаманства с JS, в котором подводных камней чуть ли не больше, чем в плюсах.
Есть мнение (далеко не только моё), что FP в D добавлено на редкость неудачно.
По какому критерию вы предлагаете судить? Действительно, давайте обсуждать не текущее положение, а то светлое будущее которое когда то наступит.
Прочитаете JavaScript: The Good Part, поймете что на нем тоже можно просто писать.
Прочитаете JavaScript: The Good Part, поймете что на нем тоже можно просто писать.
Для веб не прокатит. Есть cofeescript.
Этого мне достаточно: gist.github.com/1277224
Я не кричу. Но пока, действительно, мне не нужно. Если доведут до нужного уровня, то можно пользоваться. А слепо верить в то, что это круто, потому что это сделал google, нет желания.
А вообще складывается ощущение, что его придумали программисты не_понимающие_javascript.
А вообще складывается ощущение, что его придумали программисты не_понимающие_javascript.
Что-то не очень понимаю почему он «унылый» и «для веб не прокатит» и так далее.
С радостью начну его использовать.
С радостью начну его использовать.
Оно в далвик-то умеет компилироваться, или это не решение проблемы Android-а с джавой, а просто еще один язык что бы был?
Причём тут Dalvik, если это язык для веб-разработки (замена JS)?
Пока браузеры не начнут поддерживать его нативно — толку в нем не густо, т.к. есть тот же CoffeeScript, как тут уже заметили. Хотя, конечно, это лучше чем GWT.
Непонятно, как планируется поддерживать Dart в IE, и непонятно, зачем нам некроссбраузерный скриптовый язык.
У меня такое ощущение, что в Google очень не любят JS. То GWT, то Dart…
Непонятно, как планируется поддерживать Dart в IE, и непонятно, зачем нам некроссбраузерный скриптовый язык.
У меня такое ощущение, что в Google очень не любят JS. То GWT, то Dart…
ну почему — есть еще closure
Гугл больше чем кто либо нарвался на сложности написания приложений на 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 не запускает этот дартовский скрипт, а у вас?
Если бы за языком не стоял Гугл, мало бы кто обратил на него внимание
Waider…
Dart Waider…
Google Dart Waider…
Dart Waider…
Google Dart Waider…
Весьма хорошо. Давно пора было ввести нормальные классы в JS. А теперь почти Java в моём браузере. Ждем вменяемой реализации в браузере.
Зачем конкретно в JS нужны классы а-ля жава?
У языка хватает недостатков, но, скажем так, альтернативный взгляд на ООП к ним вряд ли относится.
Вообще, зачем из скриптовых языков с таким упорством пытаются сделать жаву?
Получается объединение недостатков обоих подходов — тяжеловесность и ынтырпрайзнутость кода с одной стороны, и при этом заведомо невысокая производительность в виду скриптовости (ну и лишнего слоя абстракции при «компиляции» в JS) и отсутствие compile-time проверок типов с другой стороны.
Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
У языка хватает недостатков, но, скажем так, альтернативный взгляд на ООП к ним вряд ли относится.
Вообще, зачем из скриптовых языков с таким упорством пытаются сделать жаву?
Получается объединение недостатков обоих подходов — тяжеловесность и ынтырпрайзнутость кода с одной стороны, и при этом заведомо невысокая производительность в виду скриптовости (ну и лишнего слоя абстракции при «компиляции» в JS) и отсутствие compile-time проверок типов с другой стороны.
Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
> Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
Просто тогда не принято было делать абстрактные фабрики мостов визитёров синглтонов. Сейчас всё сложилось бы иначе!
Просто тогда не принято было делать абстрактные фабрики мостов визитёров синглтонов. Сейчас всё сложилось бы иначе!
>Зачем конкретно в JS нужны классы а-ля жава?
За тем, что возможность в рантайме увидеть класс объекта — многого стоит, существенно облегчает отладку (в js же объекты это в сущности такие себе хэш-мапы). Ущербность ООП на прототипах убедительно показывает несметное множество библиотек, делающих ООП в js похожим на ООП в нормальных языках программирования. Хорошая система пакетов (import) тоже must have, что опять-таки иллюстрируется обилием разной степени кривости велосипедов для решения этой проблемы.
>Жава в браузерах уже была в виде апплетов, да закономерно сплыла на свалку истории.
Не показатель. Флэш тоже в этом направлении движется, стоило только улучшить поддержку HTML Video. Одно дело плагин, прибитый сбоку гвоздями и другое — стандартизовання функция, встроенная в браузер.
За тем, что возможность в рантайме увидеть класс объекта — многого стоит, существенно облегчает отладку (в 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).
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 не предоставляет удобных языковых примитивов, на которых удобно писать C++-like ООП код.
JS предоставляет достаточные и вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код.
> Нужно ввести поддержку ООП в язык и привести всё к общему знаменателю.
Кто вам сказал, что в JS нет ООП? Что такое общий знаменатель?
Да, кстати, если вы анчнете говорить про ООП в стиле С++, поспешу вас огорчить: ООП в С++ даже близко не является тем, чем оно должно являться по задумке создателя ООП как такового Алана Кея. Это так, в качестве пищи для размышления.
> Потому что никто не занимается популяризацией JS, как нормального, полноценного языка. Подавляющее большиснтво программистов до сих пор считают его этаким мелким скриптовым языком и пытаются подходить к нему с точки зрения своих колоколен.
Не удобно, вот и не популяризируют. Сваяли свои классовые обертки — и погнали. Уж писателей-то тех JS-библиотек сложно упрекнуть в незнании JS. Стало быть, они спроектировали библиотеки именно так как им было удобно. Использовать (цитирую) вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код, видимо, на практике оказалось не так уж и удобно.
> Что такое общий знаменатель?
Хотя-бы то, что сделал Adobe в AS2 / AS3, для начала. Т.е. упрятать потроха из прототипов поглубже в реализацию. Впрочем, вроде, ECMAScript туда потихоньку движется.
> Да, кстати, если вы анчнете говорить про ООП в стиле С++
Читаем мой корневой в этой теме комментарий:
Не удобно, вот и не популяризируют. Сваяли свои классовые обертки — и погнали. Уж писателей-то тех 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, но не получилось.
В AS3 — с точностью до наоборот, prototype-driven реализуется на базе class-driven.
Чувствуете разницу?
Прототипы были оставлены скорее всего для формального соответствия ECMA-262.
Adobe пыталась пропихнуть свой диалект жабаскрипта в W3C, но не получилось.
> Не удобно, вот и не популяризируют.
Неверно.
> Использовать (цитирую) вполне удобные языковые примитивы, чтобы удобно писать prototype-based OO-код, видимо, на практике оказалось не так уж и удобно.
Не надо выдавать инерцию мышления за правильные подходы к программированию.
> Хотя-бы то, что сделал Adobe в AS2 / AS3, для начала. Т.е. упрятать потроха из прототипов поглубже в реализацию.
Угу. Убрать из языка собственно сам язык и рассказывать, что как это круто.
> Впрочем, вроде, ECMAScript туда потихоньку движется.
Не движется, и это правильно
> Весьма хорошо. Давно пора было ввести нормальные классы в JS. А теперь почти Java в моём браузере
Ну да. Нет ООП, кроме С++-like, ага
Неверно.
> Использовать (цитирую) вполне удобные языковые примитивы, чтобы удобно писать 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/
Читаем:
То есть человек, судя по всему, неспособен понять, что такое прототипы, и как ими пользоваться. Ему, видите ли, неудобно, потому что он, видите ли, привык к классам.
По-моему, пост действительно показателен. Он показывает профнепригодность автора топика по ссылке.
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
Darth Vader, не Dart Vader
DartFart Framework
Документация к этому языку должна состоять из одной строчки: «Используй силу, Люк!»
Кому нужны ООП и статическая типизация при написании клиентской части, уже пользуются haXe.
Для тех, кто хочет уже поиграться с новым ЯП и использовать его в качестве сервера, то в примерах есть имплементация HTTP и пример чат сервера и клиента: goo.gl/uAWm6
Как сказал бы Мицгол, «прозреваю Dart.NET». В скором будущем.
Поменяйте в примере World на слово из 3-х любых букв кириллицей
www.dartlang.org/docs/getting-started/index.html
www.dartlang.org/docs/getting-started/index.html
Из 5-и букв тоже весело :)
Поменял. Всё работает.
Может, вы что-то не то в гугле искали, и он так «интеллектуально» подставляет?
Может, вы что-то не то в гугле искали, и он так «интеллектуально» подставляет?
> Hello, опр!
объясните шутку
объясните шутку
Они уже поправили… Это удивительно, но факт, я сам пробовал, вместо кириллицы в зависимости от количества букв он подставлял различные странные слова… Вместо трех букв он подставлял то самое емкое русское слово… Вместо пяти подставлял — «Hello, Говно», вместо семи — «Hello, Русский» и т.д. Это видимо была какая-то неудачная шутка русского офиса или взлом, но это было, а сейчас исправили.
void main() напомнило мне это что то )))
Сейчас в трансляторе Dart -> JavaScript не работает twitter.com/#!/DmitrySoshnikov/status/123337606758019072
А что теперь с GWT будет? А примеры серверной части есть?
Только дарт дарт дарт дарт дарт дарт дарт дарт
DAT JS!
Описание классса Date
int month
Returns the month in the year [1..12].
C 1 по 12. Ну наконец-то! :) Работа с месяцами в явскрипте периодически рвет мозг.
int month
Returns the month in the year [1..12].
C 1 по 12. Ну наконец-то! :) Работа с месяцами в явскрипте периодически рвет мозг.
Почитал туториалы, так и не понял как область видимости членов класса задается (private, protected, public)
www.dartlang.org/docs/getting-started/class.html
«You might have expected to see a public keyword in the preceding code, but there's no such thing in Dart. Every type in Dart is public unless its name starts with an underscore (»_")."
«You might have expected to see a public keyword in the preceding code, but there's no such thing in Dart. Every type in Dart is public unless its name starts with an underscore (»_")."
Ну вот почему после того как руби уже изобретён и используется, всякие инноваторы пытаются делать свои interface, implements, final? Ну стыдно должно быть уже.
А почему сразу Руби? Оно и до Руби всё было, 25 лет назад в Делфи. И раньше, подозреваю.
Пардон, насчет 25 лет конечно же загнул, но более 15 — точно.
Изящнее руби языка пока не придумали. Дельфи та ещё кака. Даже шарпы получше будут.
Почему даже? шарп великолепный язык. А Руби — каша из решёток собачек и анперсандов.
Тут всё дело в том, что я программировал и на том, и на том, и могу сравнивать. А вы нет. И сравнивать не можете. И решёточек в руби нет.
Чем вам кстати Делфи не угодил?
Дельфи уродлив как язык. Тяжёлое наследие паскаля. Он практически ничего не может ведь. А ужасные gui обвесы из-за которых он использовался архитектурно отвратительны.
>>Дельфи уродлив как язык. Тяжёлое наследие паскаля
конкретнее, пожалуйста
>>А ужасные gui обвесы из-за которых он использовался архитектурно отвратительны.
Вы имеете в виду VCL? По нынешним меркам действительно очень бедная библиотека, но архитектурно она очень продумана. Да и откровенных багов я в ней всего пару штук за 8 лет нашел.
конкретнее, пожалуйста
>>А ужасные gui обвесы из-за которых он использовался архитектурно отвратительны.
Вы имеете в виду VCL? По нынешним меркам действительно очень бедная библиотека, но архитектурно она очень продумана. Да и откровенных багов я в ней всего пару штук за 8 лет нашел.
Сила архитектуры в возможностях её модификации. VCL мало того что имел уродливые интерфейсы, так ещё и был сильносвязанным и монолитным. Куча антипаттернов была применена при его проектировании. Его писали как хотели вообще.
А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности, чтобы решать задачи без костылей. Дельфи эти особенности и достались.
А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности, чтобы решать задачи без костылей. Дельфи эти особенности и достались.
>>Сила архитектуры в возможностях её модификации
Спорно, скорее сила архитектуры стандартной библиотеки в универсальности предлагаемых архитектурой решений. Зачем нужна стандартная библиотека если её надо модифицировать под задачу?
>>Его писали как хотели вообще
Вы прям срываете покровы :) Я понимаю что сейчас очень популярно хаять Делфи, но все же мне интересно как человеку писавшему на Delphi много лет весьма коммерчески-успешные продукты, конкретные примеры кривизны VCL.
>>А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности
Это лирика. Синтаксис паскаля — максимально приближен к естественным языкам, оттого код на нём получается максимально читабельным. Верите, работая много лет в команде разработчиков Delphi мы использовали комментарии только в очень редких нетривиальных случаях. Потому что не было необходимости. Пересев на C++/Qt я такую необходимость ощутил.
PS: я прекрасно знаю конкретные недостатки Delphi и VCL. А вы, похоже, нет.
Спорно, скорее сила архитектуры стандартной библиотеки в универсальности предлагаемых архитектурой решений. Зачем нужна стандартная библиотека если её надо модифицировать под задачу?
>>Его писали как хотели вообще
Вы прям срываете покровы :) Я понимаю что сейчас очень популярно хаять Делфи, но все же мне интересно как человеку писавшему на Delphi много лет весьма коммерчески-успешные продукты, конкретные примеры кривизны VCL.
>>А паскаль ну просто никакой же. У него не хватает выразительности, не хватает мощности
Это лирика. Синтаксис паскаля — максимально приближен к естественным языкам, оттого код на нём получается максимально читабельным. Верите, работая много лет в команде разработчиков Delphi мы использовали комментарии только в очень редких нетривиальных случаях. Потому что не было необходимости. Пересев на C++/Qt я такую необходимость ощутил.
PS: я прекрасно знаю конкретные недостатки Delphi и VCL. А вы, похоже, нет.
Конкретные недостатки дельфи я тоже знаю и запарюсь перечислять. Начинается всё от неудобной работы с массивами и строками, а заканчивается «синтаксисом, максимально приближенным к естественным языкам», который настолько избыточен, что основное время написания занимает расстановка бегинов, эндов и варов (в начале функций).
Да, в дельфи комментарии не нужны, но не по той же причине, что и руби, а потому что на дельфи не пишется ничего, кроме описания рабты с формочками и окошками. Если бы вы начали там писать хоть сколько-нибудь приличную бизнес-логику — коментарии сразу бы понадобились.
Да, я не могу тут описать всей горы недостатков дельфи и vcl, поскольку не писал уже на нём лет 6 и не помню практически ничего. Зато прекрасно помню как мне пришлось дрючиться, чтобы добавить нужную возможность в компонент. Сила любого языка и фреймворка в возможности модафикации. Потому что нельзя охватить весь спектр задач, которые необходимо реализовать. И если задача, выходящая за рамки сценариев требует работы чуть ли не больше, чем написание всей библиотеки компонентов (утрирую), то это говно библиотека, так ведь? Слабая связанность ведёт к повышению мощности бибилотеки. А мощь языка заключается в возможности минимальными силами реализовывать то, что надо. А в дельфи даже рефлексий для этого нет. Да там ничего для этого нет. Не хватает выразительности.
Да, в дельфи комментарии не нужны, но не по той же причине, что и руби, а потому что на дельфи не пишется ничего, кроме описания рабты с формочками и окошками. Если бы вы начали там писать хоть сколько-нибудь приличную бизнес-логику — коментарии сразу бы понадобились.
Да, я не могу тут описать всей горы недостатков дельфи и vcl, поскольку не писал уже на нём лет 6 и не помню практически ничего. Зато прекрасно помню как мне пришлось дрючиться, чтобы добавить нужную возможность в компонент. Сила любого языка и фреймворка в возможности модафикации. Потому что нельзя охватить весь спектр задач, которые необходимо реализовать. И если задача, выходящая за рамки сценариев требует работы чуть ли не больше, чем написание всей библиотеки компонентов (утрирую), то это говно библиотека, так ведь? Слабая связанность ведёт к повышению мощности бибилотеки. А мощь языка заключается в возможности минимальными силами реализовывать то, что надо. А в дельфи даже рефлексий для этого нет. Да там ничего для этого нет. Не хватает выразительности.
Знаете, клепать формочки на делфи не так уж и удобно, как кажется на первый взгляд. Потому что с таким подходом в конце концов получается бессмысленная каша. Вы видимо и попались в эту ловушку обманчивой простоты.
Я же утверждаю, что на Делфи можно писать приложения любой сложности, и я этим занимался много лет.
Да, по нынешним меркам язык устарел, но это не повод чтобы закидать его говном. Многое из Делфи возродилось в С#, да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Я же утверждаю, что на Делфи можно писать приложения любой сложности, и я этим занимался много лет.
Да, по нынешним меркам язык устарел, но это не повод чтобы закидать его говном. Многое из Делфи возродилось в С#, да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Да нет же, никуда я не попадался. Я понимаю, что на дельфи можно писать приложения любой сложности. На ассемблере, кстати, тоже можно писать приложения любой сложности. Но зачем? И стоят ли затраченные усилия полученных результатов?
> Делфи возродилось в С#,
Поэтому я и шарп не полюбил, кстати. Хотя, должен признать, в шарпе всё не так запущено.
> да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Точно, это вы по begin-end определили? Взгляните на аду, смоллток и эффель и сразу станет ясно, откуда ноги у паскаля.
> Делфи возродилось в С#,
Поэтому я и шарп не полюбил, кстати. Хотя, должен признать, в шарпе всё не так запущено.
> да и на создателя Руби объектный паскаль, как один из ведущих языков того времени, наверняка оказал сильнейшее влияние.
Точно, это вы по begin-end определили? Взгляните на аду, смоллток и эффель и сразу станет ясно, откуда ноги у паскаля.
Ну вероятно, потому что руби держится на силах одного весьма своеобразного японца, который ни с кем особо не хочет делиться любимой игрушкой.
И при всей красоте языка он несет с собой еще и целую гору крайне специфичных решений, которые очень сильно ограничивают его применение.
И при всей красоте языка он несет с собой еще и целую гору крайне специфичных решений, которые очень сильно ограничивают его применение.
Руби сейчас держится на силах комьюнити. Японех, конечно, влияет на развитие языка, но всё меньше и меньше. А применение его ограничивают разве что архитектурные решения интерпретатора типа GIL или туповатого GC. Это решается использованием альтернативных интерпретаторов типа JRuby или Rubinius. А синтаксис несёт кучу специфичных решений, которые мало того, что не препятствуют, а ещё и способствуют появлению новых применений.
Комьюнити развивает фреймворки, библиотеки. И это хорошо.
Но ввергающие в ступор проблемы вроде медленного интерпретатора или отвратительной работы с кодировками никуда не исчезают. И вряд ли исчезнут.
И альтернативы, увы, ничего не решают. И тот самый вкуснейший синтаксис и тянет большинство проблем. Когда стоит переписать красивейший код не используя синтаксические примочки руби… и код начинает работать в разы быстрее. Это удручает.
Но ввергающие в ступор проблемы вроде медленного интерпретатора или отвратительной работы с кодировками никуда не исчезают. И вряд ли исчезнут.
И альтернативы, увы, ничего не решают. И тот самый вкуснейший синтаксис и тянет большинство проблем. Когда стоит переписать красивейший код не используя синтаксические примочки руби… и код начинает работать в разы быстрее. Это удручает.
> Когда стоит переписать красивейший код не используя синтаксические примочки руби… и код начинает работать в разы быстрее. Это удручает.
Вы не правильно его готовите. Покажите код до и после. Любой пример. Я покажу, как надо сделать, чтобы было и быстро, и красиво.
Вы не правильно его готовите. Покажите код до и после. Любой пример. Я покажу, как надо сделать, чтобы было и быстро, и красиво.
попросите примеров у разработчиков твиттера, которые спрыгнули с руби в пользу других языков, потому что у них и быстро и красиво не получилось.
Кстати, это единственные люди, которые зачем-то спрыгнули. Но и у них были проблемы не с языком, а с интерпретатором.
Остальные просто и не запрыгивали. Увы, но стоит выйти на приличную нагрузку, как единственным решением становится покупка большого количества серверов… или уход в другие языки :(
> Ага, не глобальные, а просто мелкие. То что интерпретатор в четыре раза медленнее питона или PHP — это мелочь же :)
И снова путаемся в понятиях. У языка почти нет недостатков. У интерпретатора есть.
Опять же, данные не верные. Пхп медленнее даже руби. А питон быстрее только потому что за него взялся гугл со своими возможностями. Но это не отменяет того факта, что при всей медленности руби тот же ror порвёт на тряпки по скорости любой полноценный фреймворк на пхп или питоне.
> Остальные просто и не запрыгивали. Увы, но стоит выйти на приличную нагрузку, как единственным решением становится покупка большого количества серверов… или уход в другие языки :(
Вот у вас таких ситуаций просто куча была, я полагаю. Иногда приходится и на ассемблере писать. У руби есть своя ниша. К слову, очень объёмная. И она постоянно расширяется.
Блин, вот а фак эм ай райтинг. Вы не видели таких нагрузок и никогда не увидите.
И снова путаемся в понятиях. У языка почти нет недостатков. У интерпретатора есть.
Опять же, данные не верные. Пхп медленнее даже руби. А питон быстрее только потому что за него взялся гугл со своими возможностями. Но это не отменяет того факта, что при всей медленности руби тот же ror порвёт на тряпки по скорости любой полноценный фреймворк на пхп или питоне.
> Остальные просто и не запрыгивали. Увы, но стоит выйти на приличную нагрузку, как единственным решением становится покупка большого количества серверов… или уход в другие языки :(
Вот у вас таких ситуаций просто куча была, я полагаю. Иногда приходится и на ассемблере писать. У руби есть своя ниша. К слову, очень объёмная. И она постоянно расширяется.
Блин, вот а фак эм ай райтинг. Вы не видели таких нагрузок и никогда не увидите.
А как вы собираетесь писать на языке, не используя интерпретатор?
Будь язык сколь угодно совершенным, если под него не будет инфраструктуры, то никто на нем ничего не будет реализовывать.
А на руби медленный интерпретатор, ограниченное предложение хостинга, проблемы с кодировками, специфичность IDE и т.д.
И никакая красота синтаксиса это не компенсирует. Увы. Собственно, Руби практически ровестник PHP, но пропасть в популярности у них катастрофическая. И боюсь, что она не преодолеется, потому как никакой серьезной поддержки за Ruby так и не появилось.
Будь язык сколь угодно совершенным, если под него не будет инфраструктуры, то никто на нем ничего не будет реализовывать.
А на руби медленный интерпретатор, ограниченное предложение хостинга, проблемы с кодировками, специфичность IDE и т.д.
И никакая красота синтаксиса это не компенсирует. Увы. Собственно, Руби практически ровестник PHP, но пропасть в популярности у них катастрофическая. И боюсь, что она не преодолеется, потому как никакой серьезной поддержки за Ruby так и не появилось.
Инфраструктура у руби мощнее, чем у пхп или того же питона. Решения есть для любых задач.
У руби медленный интерпретатор, но он не настолько медленный, чтобы обращать на это внимание. Руби быстрее пхп и догоняет питон местами. И догонит ещё, хотя это не обязательно.
Для рельсов, да и вообще для руби, хостинга сейчас на любой вкус полно. Но люди, которые не имеют отношения к разработке на руби, конечно, ничего не видят.
Проблем с кодировками у руби нет. То есть вообще нет. А у пхп есть. И у питона.
Для руби не нужен иде вообще. Для руби вполне достаточно простого редактора.
Пропасть с пхп преодолевать не нужно. Иначе придут пхпшники и всё изговнякают. Популярность руби не нужна — он уже достаточно популярен у заказчиков и чем меньше индусов в него придёт — тем больше я заработаю.
Поддержки руби, кстати, тоже более чем достаточно.
У руби медленный интерпретатор, но он не настолько медленный, чтобы обращать на это внимание. Руби быстрее пхп и догоняет питон местами. И догонит ещё, хотя это не обязательно.
Для рельсов, да и вообще для руби, хостинга сейчас на любой вкус полно. Но люди, которые не имеют отношения к разработке на руби, конечно, ничего не видят.
Проблем с кодировками у руби нет. То есть вообще нет. А у пхп есть. И у питона.
Для руби не нужен иде вообще. Для руби вполне достаточно простого редактора.
Пропасть с пхп преодолевать не нужно. Иначе придут пхпшники и всё изговнякают. Популярность руби не нужна — он уже достаточно популярен у заказчиков и чем меньше индусов в него придёт — тем больше я заработаю.
Поддержки руби, кстати, тоже более чем достаточно.
Хорошая у вас секта, одобряю! :)
Стараемся ) Слава Матзу! \о
А теперь то же самое, но по-японски! :)
Я не знаю японского. А вы в гости заглядывайте. У нас сеансы периодически, да и вообще весело. Может даже, примете учение Его.
Да я за руби лет семь приглядываю. Язык нравится, но стоит начать применять, сразу натыкаюсь на грабли, которых нет, а все ссылки в гугле ведут на страницы секты, где говорят, что этого нет или это вам и не надо.
Поэтому руби у меня живет в скриптах автоматизации или парсинге. В общем там, где единственный пользователь это я сам.
Поэтому руби у меня живет в скриптах автоматизации или парсинге. В общем там, где единственный пользователь это я сам.
Ну хер знает. Может, вам не везёт просто. + руби относительно можно пользоваться вот только последние 3-4 года.
И да, если адепты говорят, что вам этого не надо — значит действительно этого вам не надо, а есть нормальное решение задачи.
Руби — самодокументируемый язык, поэтому как нельзя лучше подходит для работы командами.
И да, если адепты говорят, что вам этого не надо — значит действительно этого вам не надо, а есть нормальное решение задачи.
Руби — самодокументируемый язык, поэтому как нельзя лучше подходит для работы командами.
Ага. Я как-то пришел на форум с вопросом «у меня есть сервис, который отдает данные в win-1251, что делать». Мне объяснили, что мне это не надо.
А что сервис сторонний и никто его ради меня не будет переделывать в utf-8, всем пофиг. Программисты на руби живут в светлом чистом мире, где все люди братья и пользуются только одной кодировкой. Ну и так далее.
А что сервис сторонний и никто его ради меня не будет переделывать в utf-8, всем пофиг. Программисты на руби живут в светлом чистом мире, где все люди братья и пользуются только одной кодировкой. Ну и так далее.
Задам вам мой любимый вопрос: если вы так знаете и любите Руби, назовите пожалуйста его недостатки. PS: Этот вопрос я задаю всем соискателям на любую технологию.
Основные недостатки в интерпретаторе. Он медленный. Он с GIL, он с туповатым GC. Это решаемо со временем, уже решено даже.
У руби как языка есть пара недостатков — не очень красиво реализована работа с utf и вообще с кодировками, например. Хотя работать можно.
У руби как языка есть пара недостатков — не очень красиво реализована работа с utf и вообще с кодировками, например. Хотя работать можно.
ОК, видно вы не новичок в языке. Больше никаких замечаний к Ruby нет лично у вас?
Вы удивитесь, сколько человек ставит в ступор подобный вопрос о C++/Qt или о Delphi/VCL.
Это вопрос-тест. Профессионал должен знать недостатки своего инструмента.
Вы удивитесь, сколько человек ставит в ступор подобный вопрос о C++/Qt или о Delphi/VCL.
Это вопрос-тест. Профессионал должен знать недостатки своего инструмента.
один раз бы все вставили на борт всех браузеров common lisp и у нас был бы гибкий язык с возможностью отстрелить себе ногу.
> Класс может осуществить несколько интерфейсов
скажите, вас самого не коробит от такого? Или вы просто используете автоматический перевод?
скажите, вас самого не коробит от такого? Или вы просто используете автоматический перевод?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Язык Dart — Structured web programming