Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 435
Насколько я понял, хотят от JS отказаться не из-за самого языка (особенности и традиции етсть в любом, чем JS хуже/лучше), а из-за накладных расходов, которые ограничивают его быстродействие.
Только почему-то нигде не пишут, что это за накладные расходы и почему их нет у той же Java, Python, Go, etc.
«Гоу» лишний в этом ряду, он компилируемый.
Java тоже
Она в байт-код компилируется, как и Пайтон. А «Гоу» — компилируемый.
Байт-код Java давно уже не интерпретируется.
А что с ним происходит дальше? Компилируется в нативный код? Разница есть, конечно, тем не менее, затраты на эту компиляцию всё равно есть.
Они есть только при запуске. Во время долгой работы приложения уже никаких накладных расходов не остаётся.
Скорее, не «в», а «для». Со смешным названием ПиПи :)
JIT в принципе возможен и для Python и для Javascript (и для последнего есть). Вот только беда в том, что из-за динамической природы языка даже JIT породит не самый эффективный код (я писал об этом выше). Кстати, у дефолтной реализации питона есть ещё одна проблема — подсчёт ссылок. Так что, полагаю, всякие IronPython и JPython должны быть пошустрее, ибо они идут поверх среды, где уже есть и быстрый GC и JIT. А с недавних пор ещё и встроенная поддержка динамических языков.
JIT?
Что вы все мне про JIT рассказываете? Разве непонятно чем компилируемый язык отличается от языка, у которого байткод и JIT? Это совершенно разные затраты на старт, это другие оптимизации. JIT ограничен в этом — ему надо компилироваться очень быстро, тут не до оптимизаций кода.
Я вроде не задавался целью перечислять некомпилируемые языки. Я спрашивал, какие такие накладные расходы у JS по сравнению с (список из популярных интернет-языков).
«Гоу» тут всё-таки резко выбивается из ряда.
1) Он не является популярным.
2) Он строго типизированный и статический
3) Он компилируется (например, нет накладных расходов на интерпретацию чего бы то ни было)
1) Он не является популярным.
2) Он строго типизированный и статический
3) Он компилируется (например, нет накладных расходов на интерпретацию чего бы то ни было)
4) он не интернет-язык (если вы имеете ввиду язык для создания сайтов)
Node.js уже вполне себе инструмент для создания сайтов, на котором крутятся очень даже некислые проекты. См. github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
С чего бы? Go подходит для «создания сайтов» даже лучше, чем Python или Java. И уж точно лучше, чем всеми «любимый» PHP. Производительность феноменальная — ближе к C, чем к Java. Потребление памяти значительно меньшее чем у Java. Go, как и Python с Java включён в проект Google App Engine, что тоже свидетельствует в пользу его веб-применимости.
Для Go уже давно созданы и фреймворки, облегчающие создание сайтов (Web.go, Twister.go) и все необходимые библиотеки (для работы с DB, FS).
Для Go уже давно созданы и фреймворки, облегчающие создание сайтов (Web.go, Twister.go) и все необходимые библиотеки (для работы с DB, FS).
Ну, я-то Гоу хорошо знаю, написал на нём не одну тысячу строк. Так вот, подходит он явно хуже. Он очень производительный, правда, но статический, уровень абстракции, следовательно, ниже. Многие вещи на нём просто дольше описывать.
Я знаю, что «Гоу» подключен к ГАЕ, но это пока эксперимент. Это эксперимент хотя бы потому, что язык обещают стабилизировать не раньше следующего года.
Я знаю, что «Гоу» подключен к ГАЕ, но это пока эксперимент. Это эксперимент хотя бы потому, что язык обещают стабилизировать не раньше следующего года.
Я тоже пишу на Go c момента его создания. И пишу на нём именно HiLoad проекты, позволяющие использовать один сервер там, где Java уже потребует два или три. Я понимаю, что это разница в подходах. Олдскульные программисты, к коим я отношу себя, не ленятся описать чуть побольше «на входе», чтобы получить «на выходе» значительно большую производительность.
BTW, у меня не поворачивается язык назвать экспериментом проект, под который уже выпущен GCC-компилятор :) GCCGO вполне можно использовать именно как стабильную ветвь, тем более, что GCC компилирует значительно эффективнее.
BTW, у меня не поворачивается язык назвать экспериментом проект, под который уже выпущен GCC-компилятор :) GCCGO вполне можно использовать именно как стабильную ветвь, тем более, что GCC компилирует значительно эффективнее.
Олдскульные программисты, к коим я отношу себя, не ленятся описать чуть побольше «на входе», чтобы получить «на выходе» значительно большую производительность.Вам важна скорость работы, другим — скорость разработки. В вебе часто важнее последнее. Зарплата программиста выше стоимости сервера, так что проще купить железку, чем нанять программиста.
BTW, у меня не поворачивается язык назвать экспериментом проект, под который уже выпущен GCC-компилятор :) GCCGO вполне можно использовать именно как стабильную ветвь, тем более, что GCC компилирует значительно эффективнее.А у меня не повернётся язык назвать «Гоу» стабильным.
Во-первых, с выходом новой версии частенько приходится что-то менять. В последний раз заменял Split на SplitN.
Во-вторых, есть ещё масса странных мест. Например, зачем-то в CGO структуры выравниваются, чего мне совсем не нужно.
В-третьих, есть ещё раздражающие глюки. К примеру (это место могли и исправить, кстати), если в конце функции return стоит под if/else, то компилятор жалуется, что нет return и не хочет компилировать.
Зарплата программиста выше стоимости сервера, так что проще купить железку, чем нанять программиста.
Ага, и к этому серверу обслуживающий персонал. Которому тоже нужно платить з/п.
Стоимость аренды стойки не сравнима с зп программиста. Там где изменения может внести один быдло-кодер на каком-то скриптовом языке, вам понадобится пара высококвалифицированных программистов на «Гоу».
Ну не знаю насчёт аренды. У нас на серваке в дисковом массиве один диск стоит моих пары з/п. А так даже не знаю по поводу быдлокодеров. Возможно, если проекты серьёзные, то имеет смысл и высококвалифицированных спецов держать. А то быдлокодер так набыдлокодит, что потом больше потеряешь денег, чем на з/п для спецов.
Или вон фейсбук. Построили же себе датацентр. Тут уже не стоимость аренды. Тут и железо дорогое, и программисты крутые нужны. Которые на C++ пишут.
Или вон фейсбук. Построили же себе датацентр. Тут уже не стоимость аренды. Тут и железо дорогое, и программисты крутые нужны. Которые на C++ пишут.
Вам важна скорость работы, другим — скорость разработки. В вебе часто важнее последнее.
99% задач веб-программирования уже давно имеют готовые решения. Я проверял — скорость копипаста одинакова для Python и Go :) Таким образом, задача сводится к наличию программиста, обладающего хорошей памятью и умением использовать open-source решения. Давайте говорить откровенно — почти все задачи веб-программирования сводятся к примитивным CRUD-операциям и работе с темплетами. Т.е. решаются одинаково несложно на любом языке, хоть на C++, хоть на Free Pascal.
Я понимаю, что фрилансерам, клепающим под заказ примитивные проекты на готовых CMS проще и выгоднее подход «быстрой разработки», с передачей постоянных издержек непосредственному заказчику. Но когда разработка делается для собственных нужд, выгоднее платить квалифицированному программисту, чем наращивать серверные фермы и строить колхозников для обслуживания.
Во-первых, с выходом новой версии частенько приходится что-то менять.
А что заставляет вас постоянно обновлять версию?
А у меня не повернётся язык назвать «Гоу» стабильным.
Значит в Google работают инженеры и программисты менее квалифицированные, чем вы :) У них язык поворачивается.
99% задач веб-программирования уже давно имеют готовые решения. Я проверял — скорость копипаста одинакова для Python и Go :)Мой опыт не столь однозначен, правда я использовал другие пары — Гоу и ПХП, в основном.
Если касаться небольших кодовых вставок, скорость разработки порою неразличима, в больших проектах на процедурном подходе близкая (но у ПХП всё равно выше, это ведь не статический язык), на объектном у ПХП сильно выше.
Давайте говорить откровенно — почти все задачи веб-программирования сводятся к примитивным CRUD-операциям и работе с темплетами.Вы как-то сильно всё упрощаете. Вы ещё скажите, что всё равно везде используется два числа — ноль и единица, посмотрите как всё просто.
Я, кстати, сайты на Гоу не делал, у меня другие цели совершенно.
А что заставляет вас постоянно обновлять версию?Постоянно ничего не заставляет, я три версии пропустил. Обновляться же иногда требуется. В языке появляются новые модули, в старых — новые возможности, сторонние модули так же обновляются. Не обновляться нельзя — исправляются баги, упрощаются некоторые вещи.
Значит в Google работают инженеры и программисты менее квалифицированные, чем вы :) У них язык поворачивается.Есть такая поговорка «всяк кулик своё болото хвалит».
За двадцать лет программирования я плотно поработал почти со всеми распространёнными языками. И именно Go оказался для меня наиболее близким к недостижимому идеалу. А вот как люди до сих пор пишут на PHP — диву даюсь. Более мутного языка даже представить себе не могу (а ведь писал даже на эрланге) — с ужасом вспоминаю те несколько лет, когда обстоятельства вынуждали с ним работать.
Наоборот, я усматриваю у большинства программистов привычку излишне раздувать сложность. Представляете, как не повезло тем кодерам, которые работают у меня? Мне-то мозги не запудрить тем, «как это сложно» :) Впрочем, возможно сложными простые задачи делает именно привязанность мышления к шаблонам абстракций?
Вы как-то сильно всё упрощаете. Вы ещё скажите, что всё равно везде используется два числа — ноль и единица, посмотрите как всё просто.
Наоборот, я усматриваю у большинства программистов привычку излишне раздувать сложность. Представляете, как не повезло тем кодерам, которые работают у меня? Мне-то мозги не запудрить тем, «как это сложно» :) Впрочем, возможно сложными простые задачи делает именно привязанность мышления к шаблонам абстракций?
А вот написал бы кто-нибудь про практическое применение гоу в реальных проектах (это и к bolk-у образение)? Так хорошо бы было…
«Обращение», конечно:)
Я писал небольшую заметку: bolknote.ru/2011/06/06/~3258
С той заметки прошло несколько месяцев ещё более интенсивного использования языка, но мнение не изменилось.
С той заметки прошло несколько месяцев ещё более интенсивного использования языка, но мнение не изменилось.
К слову, а кроме GAE как у него с поддержкой на хостингах?
> но статический, уровень абстракции, следовательно, ниже
В этом месте какие-нибудь хаскелисты вымерли от гомерического гогота.
В этом месте какие-нибудь хаскелисты вымерли от гомерического гогота.
Я ничего смешного не сказал. Для меня знание человеком языка Хаскель не является признаком того, что он разбирается в языках и том как они устроены.
Это называется «я ему про Фому, он мне про Ерему».
То, что язык статически типизирован, ничего не говорит об уровнях абстракции. То есть в цитате ниже:
В выделенном слово «следовательно» поставлено неверно, потому что второе из первого не следует
То, что язык статически типизирован, ничего не говорит об уровнях абстракции. То есть в цитате ниже:
Он очень производительный, правда, но статический, уровень абстракции, следовательно, ниже.
В выделенном слово «следовательно» поставлено неверно, потому что второе из первого не следует
Накладные расходы есть как у компилируемых, так и некомпилируемых. Накладных расходов нет только если писать под конкретную CPU-архитектуру на ASM.
Накладные расходы — из-за того, что язык динамически типизированный. Совокупность методов, которые доступны у объекта, известна только в рантайме. Следовательно, эта совокупность и хранится у самого объекта. У той же Java заранее для каждого типа известен точный набор методов. Это значит, что у объекта хранится только его тип. Теперь что происходит при вызове метода у объекта. В случае JavaScript происходит поиск метода по таблице методов. Это ещё учитывая, что надо перебрать все прототипы. В случае Java заранее известна позиция адреса метода в vtable, так что всё разруливается косвенной адресацией со смещением, которая в том же x86 поддерживается нативно.
Задача анализа кода для динамически-типизированных языков в общем случае алгоритмически неразрешима. Поэтому любые оптимизации работают постольку поскольку и рано или поздно во что-нибудь операции. То же верно относительно IDE. Те, кто говорит «IDE для JavaScript» просто никогда не писали в Eclipse или IDEA на Java. Ну или на C# в VS + Resharper
Задача анализа кода для динамически-типизированных языков в общем случае алгоритмически неразрешима. Поэтому любые оптимизации работают постольку поскольку и рано или поздно во что-нибудь операции. То же верно относительно IDE. Те, кто говорит «IDE для JavaScript» просто никогда не писали в Eclipse или IDEA на Java. Ну или на C# в VS + Resharper
Т.е. вся проблема в статической типизации? Из-за неё гугл развёл весь сыр-бор что ли?
Но постойте: полно же серверных языков с динамической типизацией — python (поддерживаемый Гуглом в GAE, между прочим), php, ruby, perl, erlang — и почему-то никто не призывает их хоронить и не заявляет, что они непригодны для больших проектов.
Но постойте: полно же серверных языков с динамической типизацией — python (поддерживаемый Гуглом в GAE, между прочим), php, ruby, perl, erlang — и почему-то никто не призывает их хоронить и не заявляет, что они непригодны для больших проектов.
Ну не знаю. Я просто ответил на вопрос. Лично я не считаю, что основное преимущество статической типизации — это быстродействие. Тут важнее скорость разработки. Не скорость выкатывания рабочего прототипа, как на Python, а полноценный жизненный цикл ПО.
Кстати, про серверные. Если нагрузка большая, то никто не мешает купить сервер помощнее, сделать кластер и т.п. А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…
Кстати, про серверные. Если нагрузка большая, то никто не мешает купить сервер помощнее, сделать кластер и т.п. А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…
> Не скорость выкатывания рабочего прототипа, как на Python, а полноценный жизненный цикл ПО.
Это, мягко говоря, спорное замечание. Я лично очень слабо себе представляю, как динамическая типизация может существенно уменьшить скорость разработки.
> А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…
Упереться в производительность JS в Хроме — практически невозможно. Узким местом всегда будет отрисовка в браузере.
Это, мягко говоря, спорное замечание. Я лично очень слабо себе представляю, как динамическая типизация может существенно уменьшить скорость разработки.
> А вот у пользователя есть его слабенький нетбук или планшет. Который, заметьте, ещё и батарейку кушает. Так что, быть может, что-то тут есть…
Упереться в производительность JS в Хроме — практически невозможно. Узким местом всегда будет отрисовка в браузере.
Это, мягко говоря, спорное замечание. Я лично очень слабо себе представляю, как динамическая типизация может существенно уменьшить скорость разработки.
Если нужно вносить изменения в старый код, то статическая типизация порой спасает. Не ото всего, но от многих бед, свойственных тому же Python.
легко — попробуйте распарсить очень большой JSON (больше 10 — 12 Мб) или использовать что-то типа espeak.js
Зачем использовать espeak.js, если есть нативный JSON.parse?
еще раз ) нативный JSON.parse плохо работает с очень большими (и сложными — меньше сложность, например, массив строк больших, легче) JSON объектами. Включая и серверный, V8 плохо переносит парсинг такого объема JSON-а.
espeak — это пример большого очень скрипта, который тормозит именно обработкой данных, не DOM. Это text-to-speach engine, скомпилированый через LLVM в javascript
espeak — это пример большого очень скрипта, который тормозит именно обработкой данных, не DOM. Это text-to-speach engine, скомпилированый через LLVM в javascript
На сервере у вас есть альтернатива. Тот кусок, где вам важна статическая типизация или производительность вы можете переписать на Java или .Net. Если что-нибудь из этого вам понадобилось в браузере вы можете только смирится и писать на JS.
См. мой коммент выше. Мне неизвестны примеры браузерного приложения, упирающегося в скорость чистого JS, а не отрисовки. Вам, быть может, такие примеры известны?
Вспоминаю только демки на canvas с Box2D. Тормоз там как раз физический движок Box2D, а не canvas. Но в целом да, более серьезных примеров, упирающихся в скорость JS я не знаю. Но плюсы статической типизации — это не только скорость, это еще и контроль. На сегодняшний день, кроме костылей типа GWT воспользоватся статической типизацией нельзя.
P.S. Ни в коем случае не защищаю дарт — я сам в него не особо верю. Считаю, что при текущем разнообразии задач, решаемых в браузере, разумнее всего было бы принять стандарт не на еще один высокоуровневый язык, а на байткод. Плюсы:
1. Если вам нужен новый язык, вы пишите транслятор в байткод, а не ждете, пока поддержку вашего языка добавят во все браузеры.
2. Кроме этого мы можем использовать любой уже существующий язык при наличии транслятора
3. Весь код на этих языках совместим с друг другом. Например, код на JS без костылей сможет использовать библотеку, написанную на Python так, как будто она изначально писалась на JS.
4. Поскольку передаем байткод, а не текст, немного экономится трафик
5. По той же причине отсутствует синтаксический и лексический анализ на клиенте
P.S. Ни в коем случае не защищаю дарт — я сам в него не особо верю. Считаю, что при текущем разнообразии задач, решаемых в браузере, разумнее всего было бы принять стандарт не на еще один высокоуровневый язык, а на байткод. Плюсы:
1. Если вам нужен новый язык, вы пишите транслятор в байткод, а не ждете, пока поддержку вашего языка добавят во все браузеры.
2. Кроме этого мы можем использовать любой уже существующий язык при наличии транслятора
3. Весь код на этих языках совместим с друг другом. Например, код на JS без костылей сможет использовать библотеку, написанную на Python так, как будто она изначально писалась на JS.
4. Поскольку передаем байткод, а не текст, немного экономится трафик
5. По той же причине отсутствует синтаксический и лексический анализ на клиенте
Так напишите транслятор в байт-код для JS, в чем тут проблема. Для прототипного Lua, например, такой транслятор существует => при желании его можно сделать и для JS.
ru.wikipedia.org/wiki/Llvm
LLVM позволяет компилировать программы написанные на языках Си, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end
Не проблема. Код браузеров не читал, но думаю что все JS-движки делают это. Только они делают это каждый по своему и уже после того как скачали себе скрипт. Если этот байткод стандартизовать и разрешить подключать напрямую к тегу <script>, то будет все то, что я описал в прошлом посте.
Что-то подобное предлагал сделать Мигель Де Иказа — всторить Mono в Firefox
Что-то подобное предлагал сделать Мигель Де Иказа — всторить Mono в Firefox
Ну так почему гугл пошел не по простому пути — написать свою виртуальную машину — а по сложному — сделать новый язык и продвинуть в браузер? Выходит же, что и неплох JS, можно и с ним работать.
Я не знаю, я не работаю в Гугле. Уже говорил в другом топике, допустим, Дарт победит, он будет встроен во все бразуеры и будет жить там наравне c JS. Где гарантия что еще через 10 лет не нужен будет третий выскоуровневый язык, чтобы исправить ошибки Дарта? И того, несовместимых между собой высокоуровневых языков в браузере растет. [тут должен быть комикс xkcd про стандарты]
Или сделать это на Флеше :) Или на Яве (про апплеты забыли уже?). Или, если вспоминать решения Гугла скопилировать, используя Native Client в «Хроме».
Флеш и Ява работют не в браузере, а в своих ВМ. На сервере это терпимо, а на клиенте мобильники и планшеты идут лесом. Native Client — он будет работать где-либо кроме Хрома? Как плагин или нативно?
Про ВМ не понял в чём проблема.
Нужны плагины. Если для десктопа это в общем-то, не проблема, то для мобильных и планшетов у нас особо выбора нет. Апплетов и Native Client нет нигде, Флеш есть только на Android и Blackberry.
В процессоре и оперативке. Запустите на телефоне страницу с флешем и посчитайте сколько проживет батарея. Да и оперативки на эти vm нужно _дополнительно_ к движку браузера и js.
И почему же на них пишут-то тогда?
Потому что инфраструктура важнее производительности языка. Фронты множить очень легко.
Потому что инфраструктура важнее производительности языка. Фронты множить очень легко.
Python/GAE может похвастать.
Разные языки программирования существуют потому, что кому-то кажутся удобнее. Мне вот, например, динамически типизированные языки нравятся больше, чем статически типизированные.
В лагере javascript всё плохо просто потому, что прототипная концепция распространена много меньше классовой.
В лагере javascript всё плохо просто потому, что прототипная концепция распространена много меньше классовой.
> «Удобнее» и «нравится» не те аргументы, которые может привести инженер в споре. Вот если бы вы сказали — «динамическая типизация позволяет делать (какая либо уникальная особенность динамической типизации)» или что-нибудь подобное…
Конечно. Зачем тут вообще приводить какие-то аргументы, если про этот холивар сотни страниц написаны. Нас интересует _только_ джаваскриптовая специфика, которая, по мнению гугла, не дает развивать джаваскрипт.
> Мне кажется что прототипы это просто и интуитивно, если человек понимает ООП, то разобраться с прототипами для него не составит особого труда.
Ну а вот разработчикам Dart/coffeescript/cappuccino/etc почему-то так не кажется.
Конечно. Зачем тут вообще приводить какие-то аргументы, если про этот холивар сотни страниц написаны. Нас интересует _только_ джаваскриптовая специфика, которая, по мнению гугла, не дает развивать джаваскрипт.
> Мне кажется что прототипы это просто и интуитивно, если человек понимает ООП, то разобраться с прототипами для него не составит особого труда.
Ну а вот разработчикам Dart/coffeescript/cappuccino/etc почему-то так не кажется.
По-моему, в Dart нет вывода типов, увы. Либо я что-то проглядел.
Переменная без указания типа считается Dynamic, тип определяется в рантайме.
Переменная без указания типа считается Dynamic, тип определяется в рантайме.
Ну вашу фразу можно инвертировать: почему пишут на статически-типизируемых языках?
Что лично для меня — то я не очень люблю динамически-типизируемые языки. Когда я пишу код в IDE я хочу точно знать какие методы у какой переменной. Я хочу быть уверен что многие вещи задокументированы типами в самом коде. Я хочу смотреть на типы и понимать что делает данный метод. И мне не сложно дописать для этого типы.
Насчет быстродействия: иногда это все-таки важно, в том же гугле в-осномном (вроде как) используется java и с++. Хоть конечно для простого проекта это не критично.
Ну и про скорость еще одно соображение: когда разница на порядки (случай не самый частый, но бывает =( ) это становится грустно. И фразой «фронты множить очень легко» не отделаешься.
Да и не весь софт просто «фронты множатся».
Что лично для меня — то я не очень люблю динамически-типизируемые языки. Когда я пишу код в IDE я хочу точно знать какие методы у какой переменной. Я хочу быть уверен что многие вещи задокументированы типами в самом коде. Я хочу смотреть на типы и понимать что делает данный метод. И мне не сложно дописать для этого типы.
Насчет быстродействия: иногда это все-таки важно, в том же гугле в-осномном (вроде как) используется java и с++. Хоть конечно для простого проекта это не критично.
Ну и про скорость еще одно соображение: когда разница на порядки (случай не самый частый, но бывает =( ) это становится грустно. И фразой «фронты множить очень легко» не отделаешься.
Да и не весь софт просто «фронты множатся».
> Ну вашу фразу можно инвертировать: почему пишут на статически-типизируемых языках?
Потому что каждый разработчик/тим-лид выбирает тот язык, который ему удобнее и который лучше (по его мнению) подходит к конкретному проекту.
В конечном итоге скорость языка не так важна, важна инфраструктура. Поэтому я и в недоумении, чем не угодил JavaScript.
Потому что каждый разработчик/тим-лид выбирает тот язык, который ему удобнее и который лучше (по его мнению) подходит к конкретному проекту.
В конечном итоге скорость языка не так важна, важна инфраструктура. Поэтому я и в недоумении, чем не угодил JavaScript.
Никакой проблемы с RTTI прототипов нет.
Можете почитать как эту проблему обходит тот же V8( при появлении нового уникального «класса» он его жестко фиксирует под определённым именем, статически собирая предков, на выходе — vtable )
Насчет типизирования — мышки кололись, но продолжали писать JsDoc
Можете почитать как эту проблему обходит тот же V8( при появлении нового уникального «класса» он его жестко фиксирует под определённым именем, статически собирая предков, на выходе — vtable )
Насчет типизирования — мышки кололись, но продолжали писать JsDoc
не совсем так, «предки» никуда статически не собираются, прямой аналог виртуальный таблицы не строится.
в любом случае возникает много интересных вопросов.
например, как отличить, «настоящий» объект, который используется ООП-стиле, от объекта, который используется как словарь (в JS-то нет полноценных словарей, только объекты с именнованными свойствами). представление оптимальное для словаря не оптимально для «настоящего» объекта и наоборот… приходится действовать эвристически (и всякие фичи типа delete только под ногами мешаются).
в любом случае возникает много интересных вопросов.
например, как отличить, «настоящий» объект, который используется ООП-стиле, от объекта, который используется как словарь (в JS-то нет полноценных словарей, только объекты с именнованными свойствами). представление оптимальное для словаря не оптимально для «настоящего» объекта и наоборот… приходится действовать эвристически (и всякие фичи типа delete только под ногами мешаются).
Никакой проблемы с RTTI прототипов нет.
Run time type information? А я как бы про compile time говорил.
Насчет типизирования — мышки кололись, но продолжали писать JsDoc
А как там с параметрическим полиморфизмом aka generics? Например, я хочу вызвать метод, который возвращает список. Как узнать тип элементов списка?
> В случае Java заранее известна позиция адреса метода в vtable, так что всё разруливается косвенной адресацией со смещением, которая в том же x86 поддерживается нативно.
Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода. и т.д. Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.
Но это, конечно, даже при таком числе недостатков, может быть выгоднее, чем в яваскрипте.
Вообще, Ява на редкость тормозной и неэффективный язык. Чтобы в этом убедиться, достаточно скачать тот же Eclipse и посмотреть, сколько времени он запускается (у меня почти минуту например).
Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода. и т.д. Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.
Но это, конечно, даже при таком числе недостатков, может быть выгоднее, чем в яваскрипте.
Вообще, Ява на редкость тормозной и неэффективный язык. Чтобы в этом убедиться, достаточно скачать тот же Eclipse и посмотреть, сколько времени он запускается (у меня почти минуту например).
Последний аргумент уже много лет доказывает мне что JIT в Java на самом деле приближают его по скорости к С\С++, а технология HotSpot позволяет даже обогнать матерого соперника
Что за наглая неправда. Расскажите мне, какой процессор умеет выполнять байт-код явы? Никакой. Потому в реальности перед вызовом самого метода тратится куча инструкций на чтение и разбор байткода, проверку типа объекта, поиск адреса метода.
Вот как раз Ваша реплика содержит неправду. Инструкции разбираются только при первом вызове. Дальше всегда работает только скомпилированный код. Впрочем, там даже всё несколько сложнее на самом деле, и всё только для одного — чтобы получить более быстрый нативный код.
Более того, если мне не изменяет память, кривокодеры из сан в модуле хранят названия методов и классов из других модулей *текстом* а не каким-то идентификатором, так что там еще дополнительные расходы идут на их преобразование в id метода.
Ну и что, что преобразовывать? Один раз ведь! И то, в самом байт-коде хранятся не строковые идентификаторы, а смещения в constant pool. Их вполне можно использовать в качестве идентификаторов. А то, что метаданные вообще хранятся — это правильно, иначе RTTI идёт лесом.
Только что перезапустил эклипс — он уложился в 15 секунд.
А MSVS сильно быстрее?
А MSVS сильно быстрее?
Перезапуск — не считается, так как там прогрет кеш ОС и она половину данных читает из RAM а не с диска. Такие вещи лучше проверять сразу после загрузки системы. Но в любом случае, 15 секунд на современном многоядерном процессоре, выполняющем миллиарды операций в секунду, чтобы отобразить простое окошечко с текстом и меню — это приемлемо?
Простая программа на Си может запускаться мгновенно, а на Яве — нет. Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску. Вопрос, о чем думали инженеры сана. Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.
Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью. жальЮ я плохо знаком с этой самой явой, уверен, у нее недостатков множество.
Да, все мои комментарии относятся к использованию Java на десктопных рабочих станциях. На выделенном сервере все перечисленное, естественно, не критично.
Простая программа на Си может запускаться мгновенно, а на Яве — нет. Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску. Вопрос, о чем думали инженеры сана. Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.
Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью. жальЮ я плохо знаком с этой самой явой, уверен, у нее недостатков множество.
Да, все мои комментарии относятся к использованию Java на десктопных рабочих станциях. На выделенном сервере все перечисленное, естественно, не критично.
Но в любом случае, 15 секунд на современном многоядерном процессоре, выполняющем миллиарды операций в секунду, чтобы отобразить простое окошечко с текстом и меню — это приемлемо?
Ну, эклипс это ж не только окошечко с текстом.
И при загрузке подгружаются плагины с диска, а дисковым операциям ввода-вывода наплевать на производительность ЦП.
Простая программа на Си может запускаться мгновенно, а на Яве — нет.
Простая программа на Си никому не нужна. Нужна программа, которая умеет что-то делать. Можно подумать, Embarcadero RAD Studio или MS Visual Studio запускаются мгновено.
Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.
Возможно, Гослинг сотоварищи действительно намного глупее вас.
Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью.
А в машинный код какого процессора? Под X86, ARM, MIPS, SPARC или PowerPC? Потому-что сейчас один и тот же jar без перекомпиляции работает и на старой сантехнике, и на айбиэмовских мейнфреймах, и на писюках, и на старых маках.
Ну, эклипс это ж не только окошечко с текстом.
И при загрузке подгружаются плагины с диска, а дисковым операциям ввода-вывода наплевать на производительность ЦП.
Простая программа на Си может запускаться мгновенно, а на Яве — нет.
Простая программа на Си никому не нужна. Нужна программа, которая умеет что-то делать. Можно подумать, Embarcadero RAD Studio или MS Visual Studio запускаются мгновено.
Очевидно, они думали только о том, как бы побыстрее выпустить продукт и захватить рынок, а не отнюдь о совершенстве, качестве и производительности.
Возможно, Гослинг сотоварищи действительно намного глупее вас.
Если бы они ставили перед собой цели сделать качественный продукт, Java код компилировался бы в машинный код и работал с нормальной скоростью.
А в машинный код какого процессора? Под X86, ARM, MIPS, SPARC или PowerPC? Потому-что сейчас один и тот же jar без перекомпиляции работает и на старой сантехнике, и на айбиэмовских мейнфреймах, и на писюках, и на старых маках.
Например, в Яве крайне неэффективный метод загрузки классов — они загружаются по одному (вдумайтесь!) по мере использования, причем из zip-архивов. Причем для работы даже простой программы нужна куча клакссов из rt.jar. На практике это означает огромное число random access обращений к диску.
Во-первых, курим класслоадеры и вообще подробно изучаем архитектуру загрузки классов в JVM и понимаем, почему так сделаны и откуда вообще могут браться классы. Во-вторых, на практике это ничего не означает. Подобные вещи могут свободно кэшироваться. Если что — можно написать свой мегакласслоадер, который работал бы оптимальнее. Вот только я думаю, что инженеры из
откройте для себя excelsior jet
У меня MSVS открывается за 2 секунды, проект подхватывается еще за 2. Эклипс до такого же состояния открывается почти минуту. И то и то стоят на SSD.
Хуже всего, что Eclipse работать просто невозможно, он тормозит. Пишешь себе код — он бац, о чем-то своём задумался секунды на две. Потом повылазили какие-то левые окошки с подсказками, которые уже неактуальны, перехватили нажатия клавиш, которые им не предназначались. Проект средний, 100к строк кода. Ну что за фигня-то в самом деле?
Хуже всего, что Eclipse работать просто невозможно, он тормозит. Пишешь себе код — он бац, о чем-то своём задумался секунды на две. Потом повылазили какие-то левые окошки с подсказками, которые уже неактуальны, перехватили нажатия клавиш, которые им не предназначались. Проект средний, 100к строк кода. Ну что за фигня-то в самом деле?
Ну некоторые ARM'ы вообще-то умеют выполнять байт-код явы.
picoJava — это про процессоры.
у JS есть один фатальный недостаток — отсутствие типизации (хотябы опциональной). Это все, это тяжелый крест на нем. Об этом жаловались разрабы V8 (нельзя нормально оптимизировать байткод), это самый гемор в разработке (все ошибки вылазят только в рантайме :)) ).
но при этом нафига дартс — непонятно. для JS есть несколько нестандартизированных расширений (именно за их счет работает недавно проплывавший тут симулятор линуска под JS, на чистом JS ничего бы не вышло — сам автор у себя на сайте пишет)
но при этом нафига дартс — непонятно. для JS есть несколько нестандартизированных расширений (именно за их счет работает недавно проплывавший тут симулятор линуска под JS, на чистом JS ничего бы не вышло — сам автор у себя на сайте пишет)
Пока ваш коментарий выглядит как будто единственным по комментарием делу. Dart остается динамическим языком, так что споры динамический язык vs статический или Java vs C++ вроде как не к месту. Мне все таки непонятно, неужели все улучшения производительности ожидаются только за счет типов? Гугл и ребята из v8 пока ничего не прояснили.
Причем типизация должна бы включать в себя возможность описания сложных структур с опциональными (но фиксированного типа) полями — примерно как описания Protocol Buffers. Плюс к этому — какой-то способ описания «декларативного duck typing» — чтобы можно было компактно сказать: «принимаю объекты, имеющие float x, float y и метод move(NUM x, NUM y)».
Вторая претензия — способы управиться с асинхронным спагети в коде — к примеру, на базе continuations.
Вторая претензия — способы управиться с асинхронным спагети в коде — к примеру, на базе continuations.
www.youtube.com/watch?v=tCG0aPNvkTs&list=FLwsU3PafdpFFy6SFC4RLklQ&index=26 — вот тут об этом рассказывает разработчик V8.
«Накладные расходы» — это долбаное быстродействие DOM дерева, которое как было тормозным с момента его создания, так и остаётся до сих пор. В великом большинстве случаев затык происходит именно при работе с DOM, а не при мультипроцессорных вычислениях на голой веб-странице. Ну будет Dart, будет он слеплять строки быстрее, а чего толку, когда все это блокируется инициализацией кубиков на страничке.
Угу. XMLDocument в каком-нибудь PHP или Python — тоже пипец какая тормозная штука, но никто же по этому поводу не призывает убить PHP и Python.
Сервер-сайдовый питон использует биндинги к сишным библиотекам (наподобие той же libxml) для парсинга, поэтому со скоростью в этом случае все в порядке. А мы в данном случае говорим о клиентской стороне — здесь уже другие проблемы…
Проход DOM тоже не на JS написан. Тот же самый «биндинг».
Первый проход, при построении — несомненно. А вот любые модификации объектов уже сформированного документа делаются яваскриптом, логично же.
Ровно то же происходит и в любом другом языке.
Не логично. Весь dom сидит в браузере и в его нативных структурах описания.
Внутренности браузера и js — это, к сожалению, два отдельных мира.
Внутренности браузера и js — это, к сожалению, два отдельных мира.
И чего? ну происходят они. Вы считаете, что вызов какого-либо метода DOM или обращение к свойству — это то, в чём недостаёт скорости JS? Он тут совсем ни при чем.
Я и не говорю, что он тут причем-то, я говорю, что любые манипуляции с объектами помимо вызовов методов DOM уже ограничиваются производительностью яваскрипта. Ну да, кэп-mode :)
Я ни разу не замечал, чтобы манипуляции с объектами ограничивались производительностью JS. Пример в студию.
Да не утверждаю я, что манипуляции DOM быстрее или медленнее движка яваскрипта. Я лишь говорю, что вся эта комбинация работает со скоростью самой медленной операции. Как и было уже замечено сверху.
Ну так Дарт здесь ничего не изменит. Зачем тогда уничтожать JS?
Я и не считаю, что надо уничтожать js. То, что делает гугл — это просто переливание пустого в порожнее в данном случае. Ну да, может, чуть более удобный синтаксис и чуть другое внутреннее устройство. Но в остальном это — навязывание стандарта. Я думаю, что они мыслят примерно так: «Выпуск новой версии JS с классами и Java-подобным синтаксисом — дело слишком хлопотное и не сиюминутное, поэтому почему бы не взять и не сделать свой, с преферансом и пианистками? Пусть даже это потребует плагинов к браузеру».
манипуляции с объектами помимо вызовов методов DOM уже ограничиваются производительностью яваскрипта
Какими объектами? В каких случаях? Насколько ограничиваются?
Какими объектами? В каких случаях? Насколько ограничиваются?
Объектами DOM. Вы же не будете утверждать, что DOM служит для чего-то большего, чем базовая перестановка блоков и простейшее обращение к атрибутам? Ну и вот, а в случае любых, например, математических действий с этими объектами, играет роль уже производительность яваскрипта, а не DOM. К лучшему это или к худшему.
Вы что-то всё в одну кучу смешали. То говорите, что не имеете ввиду DOM, то опять какие-то манипуляции «математические» над DOM. Конкретный пример все-таки можно?
Да пожалуйста, например, вычисление и присвоение высоты блока на основе высот окружающих его блоков, с помощью математической функции. Здесь за обращение (get и set) к параметрам блоков будут отвечать DOM-методы, а вот за скорость математического вычисления высоты — яваскрипт. Что непонятно?
Ну так это обычные вычисления, они к DOM отношения не имеют никакого. Можно складывать циферки просто из массива с тем же успехем. И что, вы считаете, что скорость подобноё операции на данный момент никак не является производительной, зависание браузера или что-то ещё, когда вычисляете пару математических формул на JS?
Это всё абстрактные примеры, у меня таких проблем не возникает при подсчёте сумм/разниц чисел и ему подобного.
Это всё абстрактные примеры, у меня таких проблем не возникает при подсчёте сумм/разниц чисел и ему подобного.
Ещё раз, я не говорю, что DOM упирается в производительность яваскрипта или наоборот :) Я лишь говорю, что они решают разные задачи, но конечная производительность приложения зависит именно от скорости их совместной работы, а точнее, самой медленной операции. С чем вы не согласны?
Пример приведёте, какие такие манипуляции с какими объектами затрагивают производительность вычислений на том же V8? Только конкретно, пожалуйста.
И тем не менее, видал я энтерпрайз, написанный на GWT, который тормозил не на DOM. И даже не на взаимодействии с сервером. Просто мог подвисать секунд на 5 и кушать 100% процессора.
Лично меня сразу насторожило, когда Гугл начал разговаривать лозунгами. Как не молодой человек, уже повидал последствия такого общения с аудиторией.
Re: JavaScript и есть язык широкого профиля, от сложных скриптов до сложных приложений. JavaScript — высокоуровневый и чрезвычайно мощный объектно-ориентированный язык
Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…
Q: А как на JS обстоят дела с синхронизацией потоков?
A: Нет потоков — нет проблем.
Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)
Q: JS динамический язык, он наверно чем-то похож на Python?
A: Да. Только очень, очень, очень отдаленно.
Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)
Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…
Q: А как на JS обстоят дела с синхронизацией потоков?
A: Нет потоков — нет проблем.
Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)
Q: JS динамический язык, он наверно чем-то похож на Python?
A: Да. Только очень, очень, очень отдаленно.
Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)
Читаю этот комментарий и вспоминаю рассказ «Срезал».
> Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…
Какое отношение JavaScript имеет к Java?
> Q: А как на JS обстоят дела с синхронизацией потоков?
> A: Нет потоков — нет проблем.
А как там в Дарте дела обстоят с синхронизацией потоков, не напомните?
Реализация потоков на JavaScript давно написана Мозиллой, см. Rhino и Ringo. Подробный разбор здесь.
> Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
> A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)
Вы про клиент-сайд или про сервер-сайд? На серверной стороне нет никаких браузеров. А на клиентской стороне браузер будет всегда, независимо от того, выполняет он Dart или JavaScript.
> Q: JS динамический язык, он наверно чем-то похож на Python?
> A: Да. Только очень, очень, очень отдаленно.
Отличный аргумент! Если язык не похож на питон, то он не годится для high-load приложений, я правильно понял?
> Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
> A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)
Ну вот я знаю Питон, и как это мне должно помешать считать JS высокоуровневым и чрезвычайно мощным объектно-ориентированным языком?
> Ну-ну. Даже между Java 1.4 и java 1.5 лежит пропасть, а уж где JavaScript находится…
Какое отношение JavaScript имеет к Java?
> Q: А как на JS обстоят дела с синхронизацией потоков?
> A: Нет потоков — нет проблем.
А как там в Дарте дела обстоят с синхронизацией потоков, не напомните?
Реализация потоков на JavaScript давно написана Мозиллой, см. Rhino и Ringo. Подробный разбор здесь.
> Q: Отсутствие строгой типизации не будет проблемой при создании больших приложений?
> A: Нет (узким местом будет браузер, который начнет подвисать гораздо раньше)
Вы про клиент-сайд или про сервер-сайд? На серверной стороне нет никаких браузеров. А на клиентской стороне браузер будет всегда, независимо от того, выполняет он Dart или JavaScript.
> Q: JS динамический язык, он наверно чем-то похож на Python?
> A: Да. Только очень, очень, очень отдаленно.
Отличный аргумент! Если язык не похож на питон, то он не годится для high-load приложений, я правильно понял?
> Q: Что делать разработчику, если он не знает ни одного языка кроме JS?
> A: Доказывать всем и вся, что «JS -высокоуровневый и чрезвычайно мощный объектно-ориентированный язык» (ц)
Ну вот я знаю Питон, и как это мне должно помешать считать JS высокоуровневым и чрезвычайно мощным объектно-ориентированным языком?
Срезал так срезал.
Знаете, они хотят сделать свой классический ОО язык, чтобы можно было юзать стандартные шаблоны проектирования, а также юзать MVC. Для многих это — признак крутости.
А тут бац — прототипный язык, да еще и с асинхронным вызовом. Епт, как же я MVC то реализую? О, идея — а сделаю я классический ОО язык…
В прототипном, асинхронном ООП, есть свои шаблоны проектирования (некоторые вы в исх. коде jQuery можете увидеть). Только гуглить придется откровенно долго.
Про разделение логики и представления. На msdn находил хорошее описание реализации для асинхронным языков программирования. Да и книжка старая у меня где-то была. Там про подходы решения задач с инструментами асинхронной обработки.
Я прошу прощения, что не привожу ссылки — нет времени по хистори лазить.
Кстати, прошу взглянуть на QT и Java. И если говорят, что JavaScript убожество, то пусть взглянут на JavaScript и его собрата QScript(в QT). И вот Dart я не могу представить в Java или в QT.
А тут бац — прототипный язык, да еще и с асинхронным вызовом. Епт, как же я MVC то реализую? О, идея — а сделаю я классический ОО язык…
В прототипном, асинхронном ООП, есть свои шаблоны проектирования (некоторые вы в исх. коде jQuery можете увидеть). Только гуглить придется откровенно долго.
Про разделение логики и представления. На msdn находил хорошее описание реализации для асинхронным языков программирования. Да и книжка старая у меня где-то была. Там про подходы решения задач с инструментами асинхронной обработки.
Я прошу прощения, что не привожу ссылки — нет времени по хистори лазить.
Кстати, прошу взглянуть на QT и Java. И если говорят, что JavaScript убожество, то пусть взглянут на JavaScript и его собрата QScript(в QT). И вот Dart я не могу представить в Java или в QT.
Собственно именно так
JS быстрый, удобный, но держать на нём крупный проект просто невозможно. Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.
Это основная причина появляния Dart-а.
JS быстрый, удобный, но держать на нём крупный проект просто невозможно. Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.
Это основная причина появляния Dart-а.
> JS быстрый, удобный, но держать на нём крупный проект просто невозможно.
А ребята из plurk.com и не знали.
> Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.
А нельзя как-то с примерами, где какая схема не работает?
А ребята из plurk.com и не знали.
> Классическая схема работы, построенная на ООП, наследовании, инкапсуляции тут просто не работает.
А нельзя как-то с примерами, где какая схема не работает?
> А ребята из plurk.com и не знали.
Простите, а что именно и в каких объемах у них написано на JavaScript?
Простите, а что именно и в каких объемах у них написано на JavaScript?
Чатег. amix.dk/blog/post/19490
Что, скажете, это не пример high-load веб-приложения?
Что, скажете, это не пример high-load веб-приложения?
не хочу вас сильно огорчать (я сам сильно огорчился, когда узнал :-)), но они обратно на Java перебежали:
amix.dk/blog/post/19577
[в любом случае надо разделять скажем приложения с большой нагрузкой и приложения с большой (архитектурной) сложностью, это две совершенно ортогональные характеристики. например, приложение под большой нагрузкой может быть очень компактным и простым]
amix.dk/blog/post/19577
[в любом случае надо разделять скажем приложения с большой нагрузкой и приложения с большой (архитектурной) сложностью, это две совершенно ортогональные характеристики. например, приложение под большой нагрузкой может быть очень компактным и простым]
Remember that node.js served us well for the past 8 months serving millions of comet notifications each day.
А дальше речь про то, что в V8 нет нормальной реализации тредов, хотя Мозилла давно запилила её в своем Рино. Так что, очевидно, мы сталкиваемся именно с нежеланием самого Гугла допилить V8 до уровня нормального сервер-сайд движка.
У V8 есть изоляты. Хочется использовать потоки? Пожалуйста. То, что node.js не использует изоляты, это их архитектурное решение.
[ну и ECMA-262 не стандартизирует модель многопоточного исполнения с общим состоянием для JavaScript. у SpiderMonkey, например, был режим когда несколько потоков могли существовать в пределах одной VM (с устным условием(!), что они не трогают одни и те же области памяти, иначе бабах!), но он теперь «deprecated», ибо одна головная боль].
[ну и ECMA-262 не стандартизирует модель многопоточного исполнения с общим состоянием для JavaScript. у SpiderMonkey, например, был режим когда несколько потоков могли существовать в пределах одной VM (с устным условием(!), что они не трогают одни и те же области памяти, иначе бабах!), но он теперь «deprecated», ибо одна головная боль].
Кто не работает?
У меня все отлично работает!
Быть может дело не в языке, и не его архитектуре.
А в архитектуре конечного приложения?
У меня все отлично работает!
Быть может дело не в языке, и не его архитектуре.
А в архитектуре конечного приложения?
Код, упомянутый в статье очень хорошо понятен Java и PHP программистам, коих в мире web больше всех, кажется. Для больших проектов реально важно иметь статическую типизацию. Неприятие автором этого утверждения, на мой взгляд, говорит лишь об отсутствии положительного опыта в таких проектах. В больших проектах приходится ограничивать свободу разработчику, чтобы проект не развалился. Уверяю, автоматически обнаружить ошибку на этапе compile time, это лучше, чем писать тест с проверкой типа.
Полагаю, что цель Гугла, создать язык не только для клиентских скриптов, но и для сервера. Единый язык для клиента и сервера позволит создавать веб-фреймворки нового уровня качества, по сравнению с Ruby on Rails и даже GWT.
Полагаю, что цель Гугла, создать язык не только для клиентских скриптов, но и для сервера. Единый язык для клиента и сервера позволит создавать веб-фреймворки нового уровня качества, по сравнению с Ruby on Rails и даже GWT.
>>Код, упомянутый в статье очень хорошо понятен Java и PHP программистам
А так же AS3 и C# программистам. ИМХО, он понятен любому ООП программистe.
Не знаю, как остальные, а я вот в первую очередь хотел бы увидеть от Дарта две вещи — один движок для всех браузеров, пускай на некоторых это даже будет плагин, как сейчас Flash, и родной, привязанный к языку фреймворк для разработки, без геморроя с HTML DOM.
А так же AS3 и C# программистам. ИМХО, он понятен любому ООП программистe.
Не знаю, как остальные, а я вот в первую очередь хотел бы увидеть от Дарта две вещи — один движок для всех браузеров, пускай на некоторых это даже будет плагин, как сейчас Flash, и родной, привязанный к языку фреймворк для разработки, без геморроя с HTML DOM.
> Для больших проектов реально важно иметь статическую типизацию.
Т.е. на питоне, руби, php не пишут большие проекты? И зачем тогда гугл использует Python в GAE?
Вы, видимо, проглядели мысль: инфраструктура важнее языка, и в гугле это отлично понимают.
Т.е. на питоне, руби, php не пишут большие проекты? И зачем тогда гугл использует Python в GAE?
Вы, видимо, проглядели мысль: инфраструктура важнее языка, и в гугле это отлично понимают.
Пишут. Только обслуживать и развивать такие проекты — это ад. Технический долг в таких проектах моментально пересекает критическую черту.
Я не проглядел мысль, что инфраструктура важнее языка, и полностью согласен с этим утверждением. Я не согласен с оценочным суждением языка в статье. Гугл может преследовать любые выгодные ему цели. От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.
Я не проглядел мысль, что инфраструктура важнее языка, и полностью согласен с этим утверждением. Я не согласен с оценочным суждением языка в статье. Гугл может преследовать любые выгодные ему цели. От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.
Я вот все читаю и думаю… а ведь был VisualBasic, единый на сервере и на клиенте…
> Только обслуживать и развивать такие проекты — это ад. Технический долг в таких проектах моментально пересекает критическую черту.
Примеры можно?
> От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.
Речь идёт не просто о хорошем языке, а о полной замене JavaScript, который гугл справедливо называет lingua franca веб-разработки (и который, замечу, никому не принадлежит) на свой Дарт, т.е. об установлении монополии. А это очень, очень плохо.
Примеры можно?
> От хорошего языка и хорошей инфраструктуры выиграют все, не только Гугл.
Речь идёт не просто о хорошем языке, а о полной замене JavaScript, который гугл справедливо называет lingua franca веб-разработки (и который, замечу, никому не принадлежит) на свой Дарт, т.е. об установлении монополии. А это очень, очень плохо.
Можно, на личном опыте. Я люблю досконально изучать основные фреймворки, с которыми работаю. Так вот на Java в Eclipse, спокойно могу сидеть и исследовать код. Всё удобно, всё под рукой и на горячих клавишах. Уходи на любую глубину — не потеряешься.
Затем я столкнулся с Django… Долго я матюгался, пытаясь исследовать код этого фреймворка. Банально — сидишь и гадаешь, а что в этот метод можно передать, а что нет. И вообще, что туда можно передать. Такие вещи просто выводили из себя, а еще и документации к этому методу толку нет.
Затем я столкнулся с Django… Долго я матюгался, пытаясь исследовать код этого фреймворка. Банально — сидишь и гадаешь, а что в этот метод можно передать, а что нет. И вообще, что туда можно передать. Такие вещи просто выводили из себя, а еще и документации к этому методу толку нет.
Какая нафиг монополия? Вот JavaScript это точно монополия.
На данный момент существует 4 активно развивающихся JS-движка.
Движок дарта будет один.
Движок дарта будет один.
Почему вы в этом так уверены? Может тоже их будет 4? Вроде же open-source, не?
Потому что если их будет четыре, гугл зря затевал эту революцию. Я не верю здесь, что за добрыми намерениями гугла не стоит желание править миром.
Хром вот тоже якобы open-source и всем прекрасен. А ещё он оружие против Яндекса. И с Дартом будет то же.
Хром вот тоже якобы open-source и всем прекрасен. А ещё он оружие против Яндекса. И с Дартом будет то же.
Под монополией имелось ввиду, что кроме JavaScript выбора то больше и нету…
JavaScript уже претендует на серверную часть в виде Node.js. Единый язык для клиента и сервера. К чему тут Дарт?
Я был на TechTalk по DART в офисе гугла. Так вот объяснили все весьма наглядно. Так, например, на том же дарте можно написать фронтенд на сервере и клиентский код на дарте, так что получится полноценное веб приложение, написанное на одном языке и взаимодействующее с БД и т.п. с серверной стороны. Предлагаете использовать NodeJS? Я бы не стал.
Почему не стали бы?
Уже придуманы десятки вариантов обхода этой проблемы.
Начиная от promise и закачивания синхронными вариантами вызовов( и никаких проблем ваааще, все по старинке )
Начиная от promise и закачивания синхронными вариантами вызовов( и никаких проблем ваааще, все по старинке )
Уже придуманы десятки вариантов обхода этой проблемы.>> Если их десять и вы о них упомянули значит серебрянной пули тут не существует и все подходы имеют недостатки. Синхронный вызов таким уж точно не является. Дальше большой проект подразумевает множество библиотек. Где такие для нода? node.js это собрать тестовый сервачок для js dev. Исключения больше напоминают фанатизм.
> Дальше большой проект подразумевает множество библиотек. Где такие для нода?
Это сарказм, что ли? Ну вот, множество библиотек: github.com/joyent/node/wiki/modules
Это сарказм, что ли? Ну вот, множество библиотек: github.com/joyent/node/wiki/modules
это вы называете множеством, выкидываем половину библиотек которые реализуют всякие костыли для более менее нормально ооп, mvc и т.п. и остаётся кот наплакал. Я как-то игрался с этим node.js захотелось мне из оракла выборку сделать. Да так что бы по человечски с мапингом, лейзи лоадингом и т.п. Погуглил. нет такой возможности. И таких пробелов там миллионы. Вы действительно счтитаете что на node.js сейчас можно написать высокпроизводительный бекенд, с использованием кучи разных библиотек для агрегации данных откуда угодно. И самое главное БЫСТРО и качественно?
и да забыл добавить версия оракла 9.
А тут, пока что, все по честному.
Нужно нормальный конектор к БД — пинай оракл, если не получиться — пиши сам.
Нода, и язык на котором она написанна тот тут причом?
Нужно нормальный конектор к БД — пинай оракл, если не получиться — пиши сам.
Нода, и язык на котором она написанна тот тут причом?
вот так себе и представил начинается проект, кастомер говорит у меня база данных, а ты ему говоришь так нужно в естимацию заложить попинать оракл или если нет давайте напишем ка сами свой костыль потом пол года будем в нём вылавливать баги, пару раз испортим данные и т.п. Вы в каком мире живете?
А что, для Дарта есть оракловый модуль? Нет.
Что, гуглу написать оракловый модуль к дарту проще, чем к Node.js? Ни разу.
Где здесь проблема _языка_?
Что, гуглу написать оракловый модуль к дарту проще, чем к Node.js? Ни разу.
Где здесь проблема _языка_?
я в реальном живу, с реальными проектами и технологиями. В итоге меньший перфоманс меньше возможностей для масштабирования и распаралеливания и слабая или никакая поддержка даже мейнстримовых задач. Перемножайте это на черти какое ООП. Гугл это и пытается решить. Переписать с джавы или шарпа тот же драйвер будет не сложнее чем забекпортить с джавы 7 на какую-то 1.4, чего не скажешь о node.js
Вы просто не умеете его готовить.
я вам привёл кокретные примеры. Если json из какого-то key-value хранилища отдать. То пишется это на коленке, и я в том числе его пользовал на некоторых POC для себя. Чем дальше тем граблей больше. Всему свое место.
что более конкретного конекторы к разным версиям баз данных в т.ч. не сильно мейнстримовые версии какое нибудь легаси и т.п. Отсутсвие нормального дебага и т.п. blocking IO only etc… etc…
Какой еще оракловый модуль к дарту, если дарт работает в браузере, а оракл на сервере?
Я думаю, Вам стоило минимально разобраться в обсуждаемой теме, прежде чем оставлять такие комментарии.
Я так понимаю, я имею дело с экспертом по языку дарт, который реализовал уже не один десяток проектов на нем, да?
Сарказм?
Думается что вы имеете дело с человеком который знает что Dart можно запустить на серверной стороне по специальной VM.
Ну и как успехи в запуске?
Первое сообщенеи ветки вы так и не смогли прочитать?
На текущий момент дарт парсером питона перегоняется в джаваскрипт. Для клиента. Для сервера ничего в открытом виде вообще не представлено.
Поэтому рассуждать вообще ни о чем. Если будет джава-машина, там поддержка любой БД есть, если парсер на питоне, аналогично.
Выпускать язык совсем в чистом виде… ну Go уже выпустили. Быстро, красиво, с нулевой поддержкой.
Полагаю, до начала холиваров надо хотя бы рабочий вид всего что будет представлять.
Поэтому рассуждать вообще ни о чем. Если будет джава-машина, там поддержка любой БД есть, если парсер на питоне, аналогично.
Выпускать язык совсем в чистом виде… ну Go уже выпустили. Быстро, красиво, с нулевой поддержкой.
Полагаю, до начала холиваров надо хотя бы рабочий вид всего что будет представлять.
да можно. мы, например, написали и используем в продакшине уже год в мишин критиках приложении
Не-не-не. Вы ушли в частности. Проблемы node.js просты:
1. Stop the world GC. Я с трудом себе представляю чтобы зависание всего приложения для работы сборщика мусора в HighLoad'e было нормой.
2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.
3. Молодость платформы. Нестабильность. Слабость библиотек.
3.1. Отсутствие адекватной работы с кодировками. Также и с бинарными данными.
И, все же, да, отсутствие статической типизации плюсом тоже являться не может.
1. Stop the world GC. Я с трудом себе представляю чтобы зависание всего приложения для работы сборщика мусора в HighLoad'e было нормой.
2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.
3. Молодость платформы. Нестабильность. Слабость библиотек.
3.1. Отсутствие адекватной работы с кодировками. Также и с бинарными данными.
И, все же, да, отсутствие статической типизации плюсом тоже являться не может.
спасибо, вы структурировали все что я пытался сказать, ну кроме GC )
> 1. Stop the world GC. Я с трудом себе представляю чтобы зависание всего приложения для работы сборщика мусора в HighLoad'e было нормой.
Это проблема в первую очередь V8, и починить её по факту не хочет именно Гугл. Странно, не находите?
> 2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.
Легче, чем в Python/Ruby/...? Пример в студию. Особенно про «сожрать кучу памяти».
> 3. Молодость платформы. Нестабильность. Слабость библиотек.
Ну, у Дарта здесь никакого преимущества нет.
> 3.1. Отсутствие адекватной работы с кодировками.
Проблемы с кодировками? В моём джаваскрипте??? Пруфпик или не было.
Это проблема в первую очередь V8, и починить её по факту не хочет именно Гугл. Странно, не находите?
> 2. Слишком легко выстрелить самому себе в ногу. Легко наделать лапши из callback'ов. Очень легко сожрать кучу памяти и при этом не понимать где именно происходят утечки.
Легче, чем в Python/Ruby/...? Пример в студию. Особенно про «сожрать кучу памяти».
> 3. Молодость платформы. Нестабильность. Слабость библиотек.
Ну, у Дарта здесь никакого преимущества нет.
> 3.1. Отсутствие адекватной работы с кодировками.
Проблемы с кодировками? В моём джаваскрипте??? Пруфпик или не было.
Про сборщик мусора. Не важно чья это проблема. Важно что она есть.
Про лапшу callback'ов, надеюсь, спорить не будете?
Я расскажу небольшую историю.
Писал я на node.js небольшой картографический сервис и граббер сторонних сайтов был одной из частей. Сам сервис работал неплохо и тут претензий нет. Правда вот явная надобность где-нибудь искать process watcher перед выкатыванием в production напрягала, но, к счастью, до этого не дошло.
Веселье началось при написании граббера. Знаете, я много грабберов написал. Причем на разных языках. Но чтобы так(!!!) выжирать оперативу и при этом не чистить ее сборщиком мусора — это жесть! У меня на vps память заканчивалась просто! Ладно, эту проблему я решил сохранением очереди url'ов и запуск граббера в несколько этапов.
Но тут появилась другая проблема. Из сокета данные читаются блоками. Логично. Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог. Я долго возился, поверьте. Все. После полудня возни я переписал за пару дней вообще весь проект на Java и ни разу не жалею.
Так вот. Про работу с кодировками. Я языке программирования должны четко разделятся текстовые данные и бинарные. А стандартная библиотека везде предполагать, что кодировка текста на входе может быть любой. В том же PHP ничего этого нет. Итогом стало расширение mbstring, с которым проблем хватает (надо примеры приводить или на слово поверите?). В node.js была сделана попытка. Но она оказалась провальной. Я уж молчу про то, что «кодировка» binary — deprecated.
Зрелая и серьезная платформа должна сильно ограничивать программиста, чтобы его код был относительно легко поддерживаемым. В этом плане node.js для серьезной разработки, особенно в команде, не подходит.
Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.
Мне давно нравилась идея запихнуть JS на сервер. Но, к сожалению, вынужден признать, что для серьезных проектов это вряд ли сработает. Слишком рискованно. Рискованно как в плане времени на поддержку кода, так и в плане отладки.
Про лапшу callback'ов, надеюсь, спорить не будете?
Я расскажу небольшую историю.
Писал я на node.js небольшой картографический сервис и граббер сторонних сайтов был одной из частей. Сам сервис работал неплохо и тут претензий нет. Правда вот явная надобность где-нибудь искать process watcher перед выкатыванием в production напрягала, но, к счастью, до этого не дошло.
Веселье началось при написании граббера. Знаете, я много грабберов написал. Причем на разных языках. Но чтобы так(!!!) выжирать оперативу и при этом не чистить ее сборщиком мусора — это жесть! У меня на vps память заканчивалась просто! Ладно, эту проблему я решил сохранением очереди url'ов и запуск граббера в несколько этапов.
Но тут появилась другая проблема. Из сокета данные читаются блоками. Логично. Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог. Я долго возился, поверьте. Все. После полудня возни я переписал за пару дней вообще весь проект на Java и ни разу не жалею.
Так вот. Про работу с кодировками. Я языке программирования должны четко разделятся текстовые данные и бинарные. А стандартная библиотека везде предполагать, что кодировка текста на входе может быть любой. В том же PHP ничего этого нет. Итогом стало расширение mbstring, с которым проблем хватает (надо примеры приводить или на слово поверите?). В node.js была сделана попытка. Но она оказалась провальной. Я уж молчу про то, что «кодировка» binary — deprecated.
Зрелая и серьезная платформа должна сильно ограничивать программиста, чтобы его код был относительно легко поддерживаемым. В этом плане node.js для серьезной разработки, особенно в команде, не подходит.
Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.
Мне давно нравилась идея запихнуть JS на сервер. Но, к сожалению, вынужден признать, что для серьезных проектов это вряд ли сработает. Слишком рискованно. Рискованно как в плане времени на поддержку кода, так и в плане отладки.
> Ладно, эту проблему я решил сохранением очереди url'ов и запуск граббера в несколько этапов.
Не понял. Вы запускали выкачивание мильона урлов одновременно и удивляетесь, что выжиралась память? Сюрприз!
И что, на каком-то другом языке не было этой проблемы?
> Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог.
У меня вот такой код собирает utf-ные строки:
Ни единой проблемы ни разу не было.
А уж работа с кодировками в тех же PHP, Python, Ruby — это вообще какой-то цирк с конями, JS в этом плане монолитен и стабилен.
Для бинарных данных в Node.js существует Buffer — чем он Вас не устроил?
> Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.
Ну уж не более адское, чем в других скриптовых языках.
Не понял. Вы запускали выкачивание мильона урлов одновременно и удивляетесь, что выжиралась память? Сюрприз!
И что, на каком-то другом языке не было этой проблемы?
> Стандартно. Так вот, собрать одну строку в том случае, если один байт UTF-8 символа попал в один блок прочтенных данных, а второй байт — в другой, я не смог.
У меня вот такой код собирает utf-ные строки:
function(res){
res.setEncoding('utf-8');
var data = '';
res.on('data', function (chunk) {
data += chunk;
});
res.on('end', function() { /* Обработка ответа /* }
}Ни единой проблемы ни разу не было.
А уж работа с кодировками в тех же PHP, Python, Ruby — это вообще какой-то цирк с конями, JS в этом плане монолитен и стабилен.
Для бинарных данных в Node.js существует Buffer — чем он Вас не устроил?
> Адское же потребление памяти у JS, фактически, — by design. Ибо надо постоянно кучу областей видимости в памяти держать.
Ну уж не более адское, чем в других скриптовых языках.
Не надо меня держать за идиота, ок?
Урлов там 200-400. Граббер на Java за 30 МБ не вылезает. Причем там и встроенный JS, и XML+XPath. В node.js же на каждую пропарсенную страницу потребление памяти увеличивалось. Я не знаю почему. Важно другое — node.js позволил мне или автору одной из используемых библиотек выстрелить в ногу. А вот Java не позволила.
А вот у меня такой подход для сбора строки не сработал. Почему? Я не знаю. И разбираться не хочу. Точнее, полдня на разборки я уже потратил и больше не намерен. К счастью, я знаю далеко не один язык.
Вы вообще читаете что я пишу? Или это такой тонкий троллинг? Покажите мне многие скриптовые языки, где надо сохранять области видимости. И ничего что в документации черным по белому написано про «кодировку» binary в Buffer'ах: «This encoding method is deprecated and should be avoided in favor of Buffer objects where possible. This encoding will be removed in future versions of Node.»? А если открыть исходники node, то можно увидеть что там много где эти буферы используется…
Платформа для серьезной разработки ценна не своими плюсами. Она ценна меньшим кол-вом минусов и неожиданностей. В JS их немерено. Опять же, к сожалению, т.к. сам JS мне нравится.
У меня ощущение, что я не просто пытаюсь что-то объяснить фанатику, но этот фанатик даже в своей-то платформе разбирается плохо. Хотелось бы ошибаться, но…
Урлов там 200-400. Граббер на Java за 30 МБ не вылезает. Причем там и встроенный JS, и XML+XPath. В node.js же на каждую пропарсенную страницу потребление памяти увеличивалось. Я не знаю почему. Важно другое — node.js позволил мне или автору одной из используемых библиотек выстрелить в ногу. А вот Java не позволила.
А вот у меня такой подход для сбора строки не сработал. Почему? Я не знаю. И разбираться не хочу. Точнее, полдня на разборки я уже потратил и больше не намерен. К счастью, я знаю далеко не один язык.
Вы вообще читаете что я пишу? Или это такой тонкий троллинг? Покажите мне многие скриптовые языки, где надо сохранять области видимости. И ничего что в документации черным по белому написано про «кодировку» binary в Buffer'ах: «This encoding method is deprecated and should be avoided in favor of Buffer objects where possible. This encoding will be removed in future versions of Node.»? А если открыть исходники node, то можно увидеть что там много где эти буферы используется…
Платформа для серьезной разработки ценна не своими плюсами. Она ценна меньшим кол-вом минусов и неожиданностей. В JS их немерено. Опять же, к сожалению, т.к. сам JS мне нравится.
У меня ощущение, что я не просто пытаюсь что-то объяснить фанатику, но этот фанатик даже в своей-то платформе разбирается плохо. Хотелось бы ошибаться, но…
> Stop the world GC.
было бы интересно посмотреть на приложения на node.js, которые страдают от GC. я пытаюсь долгое время добится внятных примеров, из которых бы можно выделить бенчмарки.
тут важно помнить, что a) подавляющее большинство реализаций различных языков имеют в своем составе stop the world коллекторы. b) throughput у stop the world коллектора больше, а overhead для мутатора меньше.
исключения слабораспостранены, тут и azulовский pauseless gc, который только недавно перенесли на обычный хардвер (до этого он крутился на специализированной архитектуре Vega), и G1 (aka Garbage First), который до сих пор считается экспериментальным, тут и старый CMS (aka mostly concurrent garbage collector), который все равно требует остановки всех потоков для завершения цикла сборки мусора (показательная вещь: confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues там открытым текстом говорят «пожалуйста не используйте CMS, если не хотите проблем с производительностью. требуется очень тщательная настройка.»).
было бы интересно посмотреть на приложения на node.js, которые страдают от GC. я пытаюсь долгое время добится внятных примеров, из которых бы можно выделить бенчмарки.
тут важно помнить, что a) подавляющее большинство реализаций различных языков имеют в своем составе stop the world коллекторы. b) throughput у stop the world коллектора больше, а overhead для мутатора меньше.
исключения слабораспостранены, тут и azulовский pauseless gc, который только недавно перенесли на обычный хардвер (до этого он крутился на специализированной архитектуре Vega), и G1 (aka Garbage First), который до сих пор считается экспериментальным, тут и старый CMS (aka mostly concurrent garbage collector), который все равно требует остановки всех потоков для завершения цикла сборки мусора (показательная вещь: confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues там открытым текстом говорят «пожалуйста не используйте CMS, если не хотите проблем с производительностью. требуется очень тщательная настройка.»).
Что вы называете нормальным ООП и как вы это понимаете. А также какие вариации есть ООП.
Дальше mvc. Я уже писал про это. Вы и с DART не сможете нормально реализовать MVC (скорее HMVC получится костыльный). Если в языке подразумевается асинхронность — MVC не реализуем.
Вы бы еще erlang назвали бы недоязыком.
В третьих — node.js еще не в конечной стадии. И если вы его юзаете в продакшене — то это на ваш страх и риск. Это еще очень молодой проект, а уже наезжают на него.
В четвертых. Если у вас используется две БД (Mongo и допустим MySQL), то как вы будете реализовывать хранение кеша приложения(!) с данными БД(надеюсь правильно поймете). Будете очередность запросов делать? Но это две БД, и второй незачем ждать ответа от первой.
В пятых — допустим на сайте, есть форма обратной связи. Вы данные проверяете на сервере и на клиенте. Это нормально. Да вот только вы пишете наверное две проверки на разных языках. В данном случае — я это напишу на одном языке. (при должной структуре и построении приложения — я пишу один интерфейс на сервере, и тот же код, если он серверо-независим, проверит и на клиенте).
Я считаю что на данном этапе развития, на node.js нежелательно писать высокопроизводительное и стабильное приложение. Это и разработчики пока не рекомендуют, т.к. версии 1.0 еще нет! Они работают еще и довольно таки оперативно — не надо их поливать грязью.
Мне нравится возможность исполнять код в созданной песочнице(что позволяет юзать безопасные макрокоманды, которые пишутся на том же JS). Нравится возможность компиляции JS кода возможностями V8. Нравится то — как легко писать модули для него на С (причем там реально очень просто). Если мне по нуждам нужно именно классическое ООП и оптимально для моих задач подходит, я беру PHP|Python|C++ и юзаю их. Если мне node.js подходит — я юзаю node.js.
Поймите правильно — классическое ООП, не подходит при асинхронном подходе к решению задач. Слишком много нарушений постулатов будет.
Кстати, в том же Вконтакте. Они юзают PHP как серверное приложение, НО, для чата юзают ноду. Почему? Просто этот инструмент отлично подошел для решения конкретной задачи.
Ну и еще. Вы с сокетами работали? тогда знаете, как высодно когда код блокирует дальнейшее исполнение, пока не получит необходимые данные с сокетов. Асинхронный стиль отлично подходит для этого.
Респект за то — что хотя бы попробовали и привели пример =)
Дальше mvc. Я уже писал про это. Вы и с DART не сможете нормально реализовать MVC (скорее HMVC получится костыльный). Если в языке подразумевается асинхронность — MVC не реализуем.
Вы бы еще erlang назвали бы недоязыком.
В третьих — node.js еще не в конечной стадии. И если вы его юзаете в продакшене — то это на ваш страх и риск. Это еще очень молодой проект, а уже наезжают на него.
В четвертых. Если у вас используется две БД (Mongo и допустим MySQL), то как вы будете реализовывать хранение кеша приложения(!) с данными БД(надеюсь правильно поймете). Будете очередность запросов делать? Но это две БД, и второй незачем ждать ответа от первой.
В пятых — допустим на сайте, есть форма обратной связи. Вы данные проверяете на сервере и на клиенте. Это нормально. Да вот только вы пишете наверное две проверки на разных языках. В данном случае — я это напишу на одном языке. (при должной структуре и построении приложения — я пишу один интерфейс на сервере, и тот же код, если он серверо-независим, проверит и на клиенте).
Я считаю что на данном этапе развития, на node.js нежелательно писать высокопроизводительное и стабильное приложение. Это и разработчики пока не рекомендуют, т.к. версии 1.0 еще нет! Они работают еще и довольно таки оперативно — не надо их поливать грязью.
Мне нравится возможность исполнять код в созданной песочнице(что позволяет юзать безопасные макрокоманды, которые пишутся на том же JS). Нравится возможность компиляции JS кода возможностями V8. Нравится то — как легко писать модули для него на С (причем там реально очень просто). Если мне по нуждам нужно именно классическое ООП и оптимально для моих задач подходит, я беру PHP|Python|C++ и юзаю их. Если мне node.js подходит — я юзаю node.js.
Поймите правильно — классическое ООП, не подходит при асинхронном подходе к решению задач. Слишком много нарушений постулатов будет.
Кстати, в том же Вконтакте. Они юзают PHP как серверное приложение, НО, для чата юзают ноду. Почему? Просто этот инструмент отлично подошел для решения конкретной задачи.
Ну и еще. Вы с сокетами работали? тогда знаете, как высодно когда код блокирует дальнейшее исполнение, пока не получит необходимые данные с сокетов. Асинхронный стиль отлично подходит для этого.
Респект за то — что хотя бы попробовали и привели пример =)
Что такое нормальное ООП, мнений очень много, холиварных. Но js наверно лидирует по количеству попыток причесать этот язык куда бы то ни было. С этим думаю никто спорить не будет.
И по поводу node.js а почему вы считаете что авторы к примеру не захотят перейти на DART? написан он на с как я понимаю. js роль там… извините. Свичнуться будет не сложно.
И по поводу node.js а почему вы считаете что авторы к примеру не захотят перейти на DART? написан он на с как я понимаю. js роль там… извините. Свичнуться будет не сложно.
Ну просто механизмы разные. node.js придерживается негласного стандарта commonJS, поэтому они и дальше будут развивать свой труд.
Dart это Dart — это еще один ЯП. Я не вижу в нем замены JS. Слишком разные в этих языках подходы к решению задач.
Лично мне просто не нравится то, что его позиционируют как замену. Чувствуется какой-то именно маркетинговый ход если честно….
Как я уже выше писал — в Java можно юзать JavaScript(Rhino), в QT — QScript. И я просто физически не могу представить Dart в этих местах, что уже показывает — что JS, со своей парадигмой, незаменим. Да и зная основной уровень разработчиков, использующих Java или QT — могу сказать, что они знают — где и что им удобнее использовать.
Я когда делаю ремонт — я использую не один инструмент, а набор. И для решения нужной задачи, я беру подходящий инструмент. Я не забиваю отверткой гвозди — это можно но не удобно. я забиваю молотком. Но шурупы я завинчиваю отверткой — молотком — это изврат. И только умелое комбинирование этих инструментов позволяет мне приемлемого результата.
Я прошу прощения — если не понятно написал. Довольно таки сумбурно — но надеюсь поймете правильно мой ход мыслей =)
Dart это Dart — это еще один ЯП. Я не вижу в нем замены JS. Слишком разные в этих языках подходы к решению задач.
Лично мне просто не нравится то, что его позиционируют как замену. Чувствуется какой-то именно маркетинговый ход если честно….
Как я уже выше писал — в Java можно юзать JavaScript(Rhino), в QT — QScript. И я просто физически не могу представить Dart в этих местах, что уже показывает — что JS, со своей парадигмой, незаменим. Да и зная основной уровень разработчиков, использующих Java или QT — могу сказать, что они знают — где и что им удобнее использовать.
Я когда делаю ремонт — я использую не один инструмент, а набор. И для решения нужной задачи, я беру подходящий инструмент. Я не забиваю отверткой гвозди — это можно но не удобно. я забиваю молотком. Но шурупы я завинчиваю отверткой — молотком — это изврат. И только умелое комбинирование этих инструментов позволяет мне приемлемого результата.
Я прошу прощения — если не понятно написал. Довольно таки сумбурно — но надеюсь поймете правильно мой ход мыслей =)
если он будет во всех браузерах, будет заменой так или иначе. Исторически так получилось, что ecma script очутился на клиенте. Я за конкуренцию. Никуда js не денется ещё лет пять так точно. Но если в бразуер протолкнут нечно другое, я за. Что в этом плохого?
я просто про visual basic вспоминаю. Тоже два языка. Впихнули его куда только можно. Сейчас тенденция же выпиливания его пошла.
Пусть лучше развивают то, что есть. И так с трудом, немного утихомирились (тыкаю пальцем в microsoft).
Силверлайты(DotNet), JavaFXы(Java), Flash(AS), HTML5(JS), SVG vs VML, JS vs Dart vs VBScript, h.263 vs Theora, mp3 vs vorbis. Причем мало того что конкурируют, так еще все это до сих пор в ущербном состоянии, причем у каждого браузера, по своему ущербно.
Надоели они уже с этой чертовой войной. Лучше бы допилили до серьезного состояния, что-то одно, а то практически за двадцать лет, банальный HTML4, и тот работает не везде как надо. Банальные локальные хранилища — и те разные! Зоопарк.
Лет через 5 опять будем писать сайты наверное так:
Chrome: Dart + canvas;
IE: VB + силверлайт;
FF: JS + XUL + JavaFX;
MobilePlatforms: JS + HTML5;
Ну и Флеш выскакивать еще где-нить будет
Костыле развитие сопровождаться будет. Сейчас хоть немного, но тенденция идет к развитию линейки JS + HTML5 + CSS3(2d|3d|transform|animate|transition т.д.);
Итак все шатко держится. Пусть хоть в одном стандартизируются. Нам же — разработчикам, потом этот зоопарк развивать(немного аналогия с «Собор и Базар»).
Пусть лучше развивают то, что есть. И так с трудом, немного утихомирились (тыкаю пальцем в microsoft).
Силверлайты(DotNet), JavaFXы(Java), Flash(AS), HTML5(JS), SVG vs VML, JS vs Dart vs VBScript, h.263 vs Theora, mp3 vs vorbis. Причем мало того что конкурируют, так еще все это до сих пор в ущербном состоянии, причем у каждого браузера, по своему ущербно.
Надоели они уже с этой чертовой войной. Лучше бы допилили до серьезного состояния, что-то одно, а то практически за двадцать лет, банальный HTML4, и тот работает не везде как надо. Банальные локальные хранилища — и те разные! Зоопарк.
Лет через 5 опять будем писать сайты наверное так:
Chrome: Dart + canvas;
IE: VB + силверлайт;
FF: JS + XUL + JavaFX;
MobilePlatforms: JS + HTML5;
Ну и Флеш выскакивать еще где-нить будет
Костыле развитие сопровождаться будет. Сейчас хоть немного, но тенденция идет к развитию линейки JS + HTML5 + CSS3(2d|3d|transform|animate|transition т.д.);
Итак все шатко держится. Пусть хоть в одном стандартизируются. Нам же — разработчикам, потом этот зоопарк развивать(немного аналогия с «Собор и Базар»).
На JS там написано много чего: github.com/joyent/node/graphs/languages
Вы не поверите, но даже в V8 часть стандартной библиотеки JS реализовано на JS, а не на C++.
Вы не поверите, но даже в V8 часть стандартной библиотеки JS реализовано на JS, а не на C++.
ИМХО, для чата ВКонтакте лучше всего подошел бы Erlang с уже готовым и более чем известным ejabberd. Ну или без ejabberd, какая разница. Почему они предпочли ноду — лично для меня загадка. Единственный мой вариант — ниасилили/побоялись. Хотя чего тут бояться — непонятно. Что тут ниасилить — тем более.
Для задач такого уровня из существующих языков хорошо подходит только Erlang. На всех остальных разработка раньше или позже превратится в бег по граблям.
Для задач такого уровня из существующих языков хорошо подходит только Erlang. На всех остальных разработка раньше или позже превратится в бег по граблям.
Мы потому тут и общаемся что у разных людей разные вкусы.
Поэтому и есть 10+ различных решений «проблемы node.js» — каждый предлагает свое решение.
Можно подумать что в других языках нет таких случаев( сколько на свете существует шаблонизаторов, баз данных и 3д движков. Зачем? Неужели нет серебряной пули? )
И совсем не понятно что вы подразумеваете под множеством библиотек.
Для ноды их уже много, и ничего не мешает их количество увеличивать.
Поэтому и есть 10+ различных решений «проблемы node.js» — каждый предлагает свое решение.
Можно подумать что в других языках нет таких случаев( сколько на свете существует шаблонизаторов, баз данных и 3д движков. Зачем? Неужели нет серебряной пули? )
И совсем не понятно что вы подразумеваете под множеством библиотек.
Для ноды их уже много, и ничего не мешает их количество увеличивать.
используйте евенты.
вы погуглите про управление потоками в node.js про сравнение performance. node.js увы это детский сад.
Нельзя ли конкретную ссылочку?
гугл наберите node.js vs java или vs python или vs с#. Почти везде раза в два меньше. Кроме того проблемы с памятью кроме того только none blocking only. Это ли все не показатели проекта на коленке или для стартапов, когда важно побыстрее POC а потом уже и переписать на чем. Порог вхождения низкий. Но чем дальше в лес тем больше дров.
Нельзя ли конкретную ссылочку?
и таких ссылок миллионы буквально первые из списка. То что я видел как в пользу нода это сравнение с апачем, который ну мягко говоря слабый конкурент в связи с явными архитектурными изьянами.
Миллионы? Вы, мягко говоря, выдаёте желаемое за действительное.
Если посмотреть хотя бы первую страницу выдачи, то можно увидеть, что цифры сильно меняются в зависимости _от конкретной задачи_ и от прямоты рук разработчика. См., например, blog.mixu.net/2011/01/17/performance-benchmarking-the-node-js-backend-of-our-48h-product-wehearvoices-net/
groups.google.com/group/faye-users/browse_thread/thread/41735035d9880a22?pli=1
Любой инструмент хорош на своём месте.
Если посмотреть хотя бы первую страницу выдачи, то можно увидеть, что цифры сильно меняются в зависимости _от конкретной задачи_ и от прямоты рук разработчика. См., например, blog.mixu.net/2011/01/17/performance-benchmarking-the-node-js-backend-of-our-48h-product-wehearvoices-net/
groups.google.com/group/faye-users/browse_thread/thread/41735035d9880a22?pli=1
Любой инструмент хорош на своём месте.
Имхо, у Гугла куча «классовых» программистов и очень мало гуру яваскрипта (это не только у Гугла, это во всём мире так).
И Гуглу дешевле и быстрее написать один раз свой классовый язык, чем переучивать программистов.
Потому они и придумывают то GWT, то Dart.
И Гуглу дешевле и быстрее написать один раз свой классовый язык, чем переучивать программистов.
Потому они и придумывают то GWT, то Dart.
Эту аргументацию я понимаю. Не понимаю, почему гугл это скрывает и пытается заявить, будто бы JavaScript плох.
Все же думаю что это идет от разработчиков v8, которые не видят возможностей для ускорения своего интерпретатора. Глупо удтверждать что разработчики v8 не разбираются в JavaScript.
Ммм, и что же?
Русский язык (например) тоже используют огромные кучи людей, а грамотно писать способны лишь очень немногие из них. Не вижу противоречия.
Так вот фигово это, что пишут как попало и большинство. Неприятно образованному человеку читать ересь.
Уничтожить русский язык, ввести эсперанто!
Поначалу эсперанто по специальным правилам можно будет транслировать в русский, а потом и от них откажемся, когда появятся нативные носители языка!
Поначалу эсперанто по специальным правилам можно будет транслировать в русский, а потом и от них откажемся, когда появятся нативные носители языка!
Да-да-да, именно.
Подумаешь, каких-то там 400-500 лет и дело в шляпе )
Как пессимистично. Нативные носители эсперанто давно существуют, в том числе довольно пожилые.
Насчет гуру javascript. Над этой вещью (Dart) и в целом Chrome работают два офигенных WebUI программиста — Emil Eklund и Erik Arvidsson. Именно с их кода начался мой путь в мир javascript программирования в бородатом 2000 году. Вот их сайт webfx.eae.net/ Я думаю те кто работал с JS в начале 2000х должны были знать их Tree & Menu controllers.
Я согласен с тем что типизированные данных позволяют в разы лучше оптимизировать «сырые» операции, так как появляется возможность прямой трансляции в оптимизированный код( а для нетипизированных данных переменная всегда какая-то variant обертка )
Но вот я за свою жизнь еще не сталкивался с ограничениями js по скорости(в современных движках), а желанные нативные данные нам, вроде как, подарил webGL через свои типизированные массивы.
Но вот я за свою жизнь еще не сталкивался с ограничениями js по скорости(в современных движках), а желанные нативные данные нам, вроде как, подарил webGL через свои типизированные массивы.
Внесу свои 5 копеек:
1. Код на Dart действительно мало понятен, но я думаю разобраться в нём дело 10-20 минут. Лично я за синт.сахар, особенно после Delphi, где его нет вовсе :)
2. Дин.типизация это конечно круто, но это огромный источник ошибок и, зачастую, малопонятный код, в который надо вдумчиво вчитываться. Стат.типизация намного быстрее, меньше жрёт ОЗУ и помогает писать стабильный код.
3. ООП на прототипах малопонятная странная штука, в которой даже после того как разберёшься будто в дремучем лесу, ИМХО. В тоже время как классическое ООП программистам вбивают «с рождения», да и выглядит оно гораздо яснее, очевиднее.
4. Просьба из умных IDE для JS исключить Netbeans, ибо в этом деле он не идёт ни в какое сравнение с Webstorm. Поддержка минимальная. Про остальные IDE говорить не могу, но я полагаю, что природа js сильно усложняет поддержку языка IDE.
Не знаю, во что вырастет Dart, но я бы не стал петь такие дифирамбы javascript-у :)
1. Код на Dart действительно мало понятен, но я думаю разобраться в нём дело 10-20 минут. Лично я за синт.сахар, особенно после Delphi, где его нет вовсе :)
2. Дин.типизация это конечно круто, но это огромный источник ошибок и, зачастую, малопонятный код, в который надо вдумчиво вчитываться. Стат.типизация намного быстрее, меньше жрёт ОЗУ и помогает писать стабильный код.
3. ООП на прототипах малопонятная странная штука, в которой даже после того как разберёшься будто в дремучем лесу, ИМХО. В тоже время как классическое ООП программистам вбивают «с рождения», да и выглядит оно гораздо яснее, очевиднее.
4. Просьба из умных IDE для JS исключить Netbeans, ибо в этом деле он не идёт ни в какое сравнение с Webstorm. Поддержка минимальная. Про остальные IDE говорить не могу, но я полагаю, что природа js сильно усложняет поддержку языка IDE.
Не знаю, во что вырастет Dart, но я бы не стал петь такие дифирамбы javascript-у :)
> 3. ООП на прототипах малопонятная странная штука, в которой даже после того как разберёшься будто в дремучем лесу, ИМХО.
Ну, а я Ваше ИМХО не разделяю. ООП на прототипах местами намного гибче чем на классах хотя бы потому, что нет нужды в монструозных template.
Ну, а я Ваше ИМХО не разделяю. ООП на прототипах местами намного гибче чем на классах хотя бы потому, что нет нужды в монструозных template.
Если всё свести к новому «простому» языку с нормальным ООП, будут писать все, кому не лень, я и другие просто потеряют свою работу, опять переквалифицироваться :)
Прототипная модель js позволят реализовать большинство фишек ооп. чего вам конкретно хотелось бы видеть из классового ооп в js?
Я знаю, что прототипная модель позволяет… бла бла бла, я и не писал, что она примитивная, но она ни разу не «читабельная», и она не понятная. Именно поэтому в интернете так много гайдов и FAQ разной степени мудрёности про неё, и именно поэтому количество уг-кода на js просто зашкаливает :) Я бы хотел видеть читабельный красивый код, построенный на классах. Хотел бы чтобы разного рода плагины строились хотя бы по одной схеме, по одному механизму. Сейчас каждый лепит во что горазд. Лично я использую примерно такую схему.
Тут выше уже отвечали на этот запрос: миллионы людей говорят по-русски безграмотно и не умеют пользоваться всеми возможностями языка. Давайте запилим эсперанто, но чтобы поначалу транслировать в русский.
Логика где?
Логика где?
Лично я за всеобщий язык. «пользоваться всеми возможностями языка» — почему бы и не пользоваться, вот только что плохого в том, чтобы сделать их удобнее? очевиднее? Какой — уже другой вопрос. Что касается трансляции — тут я согласен, hello world на 17тыщ строк никуда не годится. Но как я понимаю, речь идёт о долгосрочной перспективе.
Ну Вы и налепили
А что конкретно вам не нравится? :) Лично мне гораздо удобнее работать с вот таким горизонтальным кодом, нежели с лапшой из калбеков (аля nodeJS) или лапши из анонимок-событий (как многие пишут на jQuery). Код функций в перемешку с «просто кодом», ИМХО, вообще не читабелен. На javascript-е слишком много разных вариаций структуры, скажем «класса», чего нельзя сказать, к примеру, об php.
PHP? Язык в котором ООП прикручивлаи годами, а потом ещё и про LSB вспомнили тольок опосля. Не стоит его в сравнение ставить даже. А уж вариаций, используя магические методы, можно много понаписать.
Зачем у вас справочники и другая лабуда импортится(extend) в первичный обьект.
Не пойму зачем вы слили все одну кашу-малашу.
Как-то слишком уж самонастраиваемый обьект получается.
Спасибо прототипам, наверное после этого вы их и не любите.
Не пойму зачем вы слили все одну кашу-малашу.
Как-то слишком уж самонастраиваемый обьект получается.
Спасибо прототипам, наверное после этого вы их и не любите.
> Как-то слишком уж самонастраиваемый обьект получается.
Ну это кому как удобнее. Моя любимая «фича» этого языка — гибкость, учитывая специфику задач она часто спасает.
> Спасибо прототипам, наверное после этого вы их и не любите.
Польза от них сомнительна, сложность для понимания относительно большая. Обычно на js не пишут такой сложный код, для которого были бы актуальны преимущества прототипного-ООП перед классичским, но пишут такой, что хотелось бы чего-то простого и понятного, но имеем только мудрёное и нечитаемое. Отсюда и зоопарк.
Ну это кому как удобнее. Моя любимая «фича» этого языка — гибкость, учитывая специфику задач она часто спасает.
> Спасибо прототипам, наверное после этого вы их и не любите.
Польза от них сомнительна, сложность для понимания относительно большая. Обычно на js не пишут такой сложный код, для которого были бы актуальны преимущества прототипного-ООП перед классичским, но пишут такой, что хотелось бы чего-то простого и понятного, но имеем только мудрёное и нечитаемое. Отсюда и зоопарк.
Добавьте, что статическая типизация — это документация и тесты, которые нельзя не написать.
В JS *реально* нужен байткод и полукомпиляция, имхо. Это позволит получить левелап как по размеру кода, так и по быстродействию при начальной загрузке.
Вот это было бы классно ;)
Вот это было бы классно ;)
Вот и мне тоже так показалось. ИМО Гугл играет в микрософт в стремлении привязать разработчиков к своей платформе, чтобы все писали на Go и Dart веб-приложения для Google App Engine (с поддержкой Google Account!), открывали их в Google Chrome и были непременно счастливы. Сравните с Microsoft .NET, Azure, MSIE.
Где мне посмотреть сырцы MSIE, Azure, Microsoft.NET (хотя, поминтся, разработчики выклянчили, вроде сырцы)?
На Go и Dart вы можете писать без привязки к Google. Можете хоть сделать свой App Engine с блекджеком и шлюхами. То, что они делают такие вещи очень правильно.
Ну и просто это удобно, больше то никто ничего не предлагает? Или вы по принципу «назло маме уши отморожу»?
На Go и Dart вы можете писать без привязки к Google. Можете хоть сделать свой App Engine с блекджеком и шлюхами. То, что они делают такие вещи очень правильно.
Ну и просто это удобно, больше то никто ничего не предлагает? Или вы по принципу «назло маме уши отморожу»?
А где посмотреть сырцы Андроида, напомните?
Можно я напомню? source.android.com/index.html
Сырцы Django вам чуть выше в этом посте ничем не помогли, и даже документация (очень приличная) не помогла.
Любая монополия это плохо, даже такая «хорошая» монополия, как Google. Т.е. это, безусловно, лучше, чем MS, но все равно ничего хорошего.
Любая монополия это плохо, даже такая «хорошая» монополия, как Google. Т.е. это, безусловно, лучше, чем MS, но все равно ничего хорошего.
Хорошо, монополия. И что вы предлагаете? Отморозить на зло маме уши? Не поддержать интересные разработки? Загнить под Microsoft с его Windows?
Причем тут документация, даже очень приличная? Я говорю про изучение сырцов фреймворка, когда хочешь понять больше, чем написано даже в самой, самой, самой приличной документации.
Google просто мечтает об эпохе собственной тотальной монополии, как это было у Microsoft в 90е и первую половину 2000х. Собственно похоже, что мы итак движемся в сторону именно этого, когда Google сконцентрирует в своих руках почти все, что связано с отображением или разработкой веба. Google Chrome станет «новым IE» (к счастью, не таким кривым, но монополия от этого лучше не станет), Chrome OS и Android станут «новыми Windows». Процесс вовсю идет и язык «Dart» лишь очередной этап. И несмотря на то, что Google называет себя «корпорацией добра», даже такая «добрая» монополия ничего хорошего не обещает
Монополия это не дуло пистолета, как говорится — не нравиться используйте альтернативу. В чем проблема? Или проблема в том что альтернатива хреновенькая? Google Chrome(Chromium) это отличный браузер. Google делает отличные продукты, поэтому люди их используют или вы не согласны? Я думаю тут каждый второй с хабра Reader-ом пользуется, и другими сервисами. Вот все так боятся монополии, ну так альтернативу предложите, что за ментальность такая ныть постоянно?
Ну, начнем, с того, что я не ною. В моем сообщении нет жалоб — это скорее просто наблюдения. Во-вторых, монополия на то и является монополией, что не предполагает адекватной альтернативы. На данный момент безусловно альтернативы имеются (я же говорил выше, что процесс формирования монополии еще только идет), однако похоже, что со временем их (альтернатив) будет все меньше. В-третьих, не все самое удачное и лучшее является самым популярным.
Я не знаю почему столько сомнений у Вас, но я думаю язык будет намного понятнее большинству программистов знакомых с классовым ООП. Это что касается новичков. Ну так уж сложилось что большинство знают именно классовое ООП и оно намного больше используется, а если еще программист когда либо работал или хотя бы знакомился с статической типизацией то изучение Dart займет от 1 дня до недели, чтоб писать не плохо. И вот скажите в чем тут беда? Я думаю что наоборот это замечательно, так как я отношусь к JS скажем так не холодно не жарко и пишу на нем только из необходимости. Ну если не приживется Бог с ним, но альтернатива то чем плохо? А вот как раз гневные посты против Dart, попахивают некими теплыми чувствами к JS. Если в Dart добавят еще сахар как в Scala то это будет отличный язык ИМХО.
И только матерые Сишники ухмыляются и смеются над этими классами.
в С их никогда не было, и JS без них можно обходиться.
в С их никогда не было, и JS без них можно обходиться.
Вы уж матерый Сишник извините, но сишные либы пишутся очень долго(по несколько лет), пока они становятся стабильными. Если сравнить написать стабильную либу на Си и на Джава, то в второе с первого раза будет и стабильнее и нааамного быстрее(в разработке).
Инфа 100%? А я вот слышал, что Java-программисты пьют много кофе, курят самокрутки, ездят на мотоциклах и отдыхают на островах.
Если всё же говорить серьёзно и по теме, то в инфраструктуре драйверов Linux используется вполне себе ООП без всяких классов и методов, при этом код пишется на C. А «секрет» прост: ООП — это подход, а не конкретная технология, или, боже упаси, синтаксис.
Если всё же говорить серьёзно и по теме, то в инфраструктуре драйверов Linux используется вполне себе ООП без всяких классов и методов, при этом код пишется на C. А «секрет» прост: ООП — это подход, а не конкретная технология, или, боже упаси, синтаксис.
> мне как-то не приходят в голову динамические интерпретируемые языки, которые были бы производительнее V8 JavaScript
shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=v8
SBCL быстрее V8 в разы. А Common Lisp это тоже динамический язык.
Почему нельзя использовать этот опыт для JavaScript? Загадка.
Мне кажется, что Dart окажется не быстрее V8.
shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=v8
SBCL быстрее V8 в разы. А Common Lisp это тоже динамический язык.
Почему нельзя использовать этот опыт для JavaScript? Загадка.
Мне кажется, что Dart окажется не быстрее V8.
делать межязыковые сравнения надо очень аккуратно, осознавая специфику обоих языков.
SBCL выполняет язык с семантикой отличной от JavaScript (сюрприз!), гораздо более строгой и простой для оптимизации, плюс посмотрите на SBCL программы, там везде используются аннотации типов, хинты компилятору и режим оптимизации safety 0, который позволяет ему себя очень аггресивно вести.
SBCL выполняет язык с семантикой отличной от JavaScript (сюрприз!), гораздо более строгой и простой для оптимизации, плюс посмотрите на SBCL программы, там везде используются аннотации типов, хинты компилятору и режим оптимизации safety 0, который позволяет ему себя очень аггресивно вести.
Да SBCL и без хинтов уделает V8 как стоячего. Я его к чему привёл? К тому, что VM проигрывает нативной компиляции.
Потолок производительности JavaScript ещё не достигнут.
А Google и для Dart собирается делать VM.
Потолок производительности JavaScript ещё не достигнут.
А Google и для Dart собирается делать VM.
Что ж тогда регулярные выражения не смогли скомпилировать и тест regex-dna в 12 раз медленнее выполняется, чем на V8? :)
> Да SBCL и без хинтов уделает V8 как стоячего.
Да ну? Оптимизирующий компилятор V8 (aka Crankshaft) дает очень качественный код. Ради интереса засунул в SBCL
против
Два раза дернул (sum 500000 0.2d0) и sum(500000, 0.2).
Результат: SBCL 22ms 19ms, V8 7ms 3ms.
Окей. Если на код, который V8 родил для цикла внутри
i на регистре (eax), sum на регистре (xmm2), f на регистре (xmm1). Многовато бранчей, но это уже накладные расходы на поддержку дебаггера.
Это, конечно, замер погоды в унитазе, но все-таки замер, показывающий, что можно получать очень хороший код и в V8.
Да ну? Оптимизирующий компилятор V8 (aka Crankshaft) дает очень качественный код. Ради интереса засунул в SBCL
(defun sum (n f) (loop for i below n summing (* i f)))против
function sum(n, f) { var s = 0; for (var i = 0; i < n; i++) s += i * f; return s; }Два раза дернул (sum 500000 0.2d0) и sum(500000, 0.2).
Результат: SBCL 22ms 19ms, V8 7ms 3ms.
Окей. Если на код, который V8 родил для цикла внутри
sum посмотреть, то там оказывается все четко: 310 3bc2 cmp eax,edx 312 0f8d1d000000 jnl 347 318 3b2538b8c008 cmp esp,[0x8c0b838] ;; stack check 324 0f82fe000000 jc 584 ;; 330 f20f2ad8 cvtsi2sd xmm3,eax 334 f20f59d9 mulsd xmm3,xmm1 338 f20f58d3 addsd xmm2,xmm3 342 83c001 add eax,0x1 345 ebdb jmp 310 (0x25124036)
i на регистре (eax), sum на регистре (xmm2), f на регистре (xmm1). Многовато бранчей, но это уже накладные расходы на поддержку дебаггера.
Это, конечно, замер погоды в унитазе, но все-таки замер, показывающий, что можно получать очень хороший код и в V8.
Спасибо, правильная статья. Всегда идет конкуренция за разработчиков с целью «привязать» к своей платформе.
Причем вся история софтверных компаний вокруг этого построена.
В принципе, можно говорить, что начинается этап формирование облачной операционной системы, которая будет включать в себя в дополнение к текущей OS еще и инфраструктуру, сервисы типа файловых хранилищ, CDN, почты, календарей и т.п. У MS есть недостатки и не хватает пока обозначенного опыта, но есть продвинутый .NET, который они полностью контролируют. А это козырь. У Гугла есть опыт, но не хватает своего языка для облачной платформы. Дальше будет интересно :)
Причем вся история софтверных компаний вокруг этого построена.
В принципе, можно говорить, что начинается этап формирование облачной операционной системы, которая будет включать в себя в дополнение к текущей OS еще и инфраструктуру, сервисы типа файловых хранилищ, CDN, почты, календарей и т.п. У MS есть недостатки и не хватает пока обозначенного опыта, но есть продвинутый .NET, который они полностью контролируют. А это козырь. У Гугла есть опыт, но не хватает своего языка для облачной платформы. Дальше будет интересно :)
>> или отсутствие for… each
После того как прочитал эту строчку, усомнился в компетенции автора.
После того как прочитал эту строчку, усомнился в компетенции автора.
Так ведь на самом деле с этим проблема. И в удобстве, и в скорости. И в порядке обхода.
Я полагаю, авто имеет ввиду это:
Вместо, к примеру:
К тому же for in обходит ключи в FF так как они были заданы при создании объекта, в то время как в хроме и опере по алфавиту.
for( var name in object )
if( object.hasOwnProperty( name ) )
{
var current = object[ name ];
...
}
}Вместо, к примеру:
foreach( $object as $name => &$current ) { ... }К тому же for in обходит ключи в FF так как они были заданы при создании объекта, в то время как в хроме и опере по алфавиту.
IMHO, у Dart есть(или будут) преимущества над JS.
1 — более строгая типизация. Почти весь wtfjs.com именно о типизации, это однозначно худшая проблема JS.
2 — легковесные процессы(isolates). Это предмет для отдельного холивара, но для меня их плюсы по сравнению с коллбеками очевидны. Если будут нормальные инструменты интроспекции — это уже победа. В LWP-based concurrency мы можем гораздо четче отследить состояние системы и отдельных ее элементов.
Далее, о монополии. По-моему, вы придаете этому слишком большое значение. Microsoft был монополистом в вебе, и что теперь? Теперь они отстают и не могут догнать.
Я хочу сказать, что это естественный процесс, и никого этот итог не минует. Так что, какая разница, кто сейчас монополист? Опять же, Гугл — не худший вариант.
Dart сейчас выглядит вполне вменяемым языком, не лучше и не хуже прочих. Ну нет прототипного ООП, ну и что. Опять же, это исключает изящные решения типа JQuery, что станет для многих минусом.
В любом случае, мы будем писать на том, на чем _актуально_ писать и никто нас не спросит. Если актуальным станет Dart — будем писать на нем, пока не появится что-то лучше.
1 — более строгая типизация. Почти весь wtfjs.com именно о типизации, это однозначно худшая проблема JS.
2 — легковесные процессы(isolates). Это предмет для отдельного холивара, но для меня их плюсы по сравнению с коллбеками очевидны. Если будут нормальные инструменты интроспекции — это уже победа. В LWP-based concurrency мы можем гораздо четче отследить состояние системы и отдельных ее элементов.
Далее, о монополии. По-моему, вы придаете этому слишком большое значение. Microsoft был монополистом в вебе, и что теперь? Теперь они отстают и не могут догнать.
Я хочу сказать, что это естественный процесс, и никого этот итог не минует. Так что, какая разница, кто сейчас монополист? Опять же, Гугл — не худший вариант.
Dart сейчас выглядит вполне вменяемым языком, не лучше и не хуже прочих. Ну нет прототипного ООП, ну и что. Опять же, это исключает изящные решения типа JQuery, что станет для многих минусом.
В любом случае, мы будем писать на том, на чем _актуально_ писать и никто нас не спросит. Если актуальным станет Dart — будем писать на нем, пока не появится что-то лучше.
> 1 — более строгая типизация. Почти весь wtfjs.com именно о типизации, это однозначно худшая проблема JS.
Конечно. Это одновременно и главная проблема, и главное достоинство JavaScript. Тут как бы одного без другого не бывает.
> 2 — легковесные процессы(isolates).
Isolates реализованы в V8. Зачем городить огород и писать новый язык, если всё уже предусмотрено в старом?
> Microsoft был монополистом в вебе, и что теперь?
И теперь мы уже 10 лет расхлёбываем последствия этой монополии.
Конечно. Это одновременно и главная проблема, и главное достоинство JavaScript. Тут как бы одного без другого не бывает.
> 2 — легковесные процессы(isolates).
Isolates реализованы в V8. Зачем городить огород и писать новый язык, если всё уже предусмотрено в старом?
> Microsoft был монополистом в вебе, и что теперь?
И теперь мы уже 10 лет расхлёбываем последствия этой монополии.
> главное достоинство JavaScript
Я, наверное, чего-то не понимаю в жизни. Как этот ад из неявных приведений типов можно считать достоинством?.. Такого ужаса нет нигде, кроме PHP и JS.
У меня есть мнение, что приведения типов должны быть только явными. Чтобы строку нельзя было сравнить напрямую с числом. Чтобы всегда можно было просто и наглядно понять из кода, какого типа переменная.
> Isolates реализованы в V8.
V8 — это всего лишь один из движков. Это не весь JS, более того, я сомневаюсь, что это есть в стандарте. Более того, я сильно сомневаюсь, что Isolates в V8 — то же самое, что и в Dart.
Я, наверное, чего-то не понимаю в жизни. Как этот ад из неявных приведений типов можно считать достоинством?.. Такого ужаса нет нигде, кроме PHP и JS.
У меня есть мнение, что приведения типов должны быть только явными. Чтобы строку нельзя было сравнить напрямую с числом. Чтобы всегда можно было просто и наглядно понять из кода, какого типа переменная.
> Isolates реализованы в V8.
V8 — это всего лишь один из движков. Это не весь JS, более того, я сомневаюсь, что это есть в стандарте. Более того, я сильно сомневаюсь, что Isolates в V8 — то же самое, что и в Dart.
> Я, наверное, чего-то не понимаю в жизни. Как этот ад из неявных приведений типов можно считать достоинством?..
А когда «динамическая типизация» вдруг стала тождественна «неявному приведению типов»?
В неявном приведении типов, конечно, мало хорошего. А вот в динамической типизации — много.
> У меня есть мнение, что приведения типов должны быть только явными. Чтобы строку нельзя было сравнить напрямую с числом. Чтобы всегда можно было просто и наглядно понять из кода, какого типа переменная.
А у меня есть ровно обратное мнение. Но я же не пытаюсь Вам его навязывать. А вот Гугл пытается навязать мне Дарт.
> V8 — это всего лишь один из движков. Это не весь JS, более того, я сомневаюсь, что это есть в стандарте. Более того, я сильно сомневаюсь, что Isolates в V8 — то же самое, что и в Dart.
V8 — именно тот движок, который крутится на сервере (на клиент isolates нафиг не сдались). Аргумент не принимается.
А когда «динамическая типизация» вдруг стала тождественна «неявному приведению типов»?
В неявном приведении типов, конечно, мало хорошего. А вот в динамической типизации — много.
> У меня есть мнение, что приведения типов должны быть только явными. Чтобы строку нельзя было сравнить напрямую с числом. Чтобы всегда можно было просто и наглядно понять из кода, какого типа переменная.
А у меня есть ровно обратное мнение. Но я же не пытаюсь Вам его навязывать. А вот Гугл пытается навязать мне Дарт.
> V8 — это всего лишь один из движков. Это не весь JS, более того, я сомневаюсь, что это есть в стандарте. Более того, я сильно сомневаюсь, что Isolates в V8 — то же самое, что и в Dart.
V8 — именно тот движок, который крутится на сервере (на клиент isolates нафиг не сдались). Аргумент не принимается.
> А когда «динамическая типизация» вдруг стала тождественна «неявному приведению типов»?
А я и не называл динамическую типизацию минусом. Я говорил о строгости типизации, это несколько другое.
> Гугл пытается навязать мне Дарт.
Я так не думаю. Вы, конечно, сделали, какие-то выводы из происходящего, но, по-моему, они преждевременны. Еще слишком рано.
> на клиент isolates нафиг не сдались
Вот тут вы серьезно ошибаетесь, по-моему. Isolates это замена коллбэкам, как модели асинхронного выполнения. Это те самые легковесные изолированные процессы на которых живет Erlang и которые есть в Go. Ладно, не те самые, тут нужно смотреть в реализацию. Но это именно они. И это меня очень радует по массе причин.
> V8 — именно тот движок, который крутится на сервере (на клиент isolates нафиг не сдались)
Я вообще не говорю про сервер. Я никогда не буду пользоваться node.js — религия не позволяет. Я говорю именно о client-side.
А я и не называл динамическую типизацию минусом. Я говорил о строгости типизации, это несколько другое.
> Гугл пытается навязать мне Дарт.
Я так не думаю. Вы, конечно, сделали, какие-то выводы из происходящего, но, по-моему, они преждевременны. Еще слишком рано.
> на клиент isolates нафиг не сдались
Вот тут вы серьезно ошибаетесь, по-моему. Isolates это замена коллбэкам, как модели асинхронного выполнения. Это те самые легковесные изолированные процессы на которых живет Erlang и которые есть в Go. Ладно, не те самые, тут нужно смотреть в реализацию. Но это именно они. И это меня очень радует по массе причин.
> V8 — именно тот движок, который крутится на сервере (на клиент isolates нафиг не сдались)
Я вообще не говорю про сервер. Я никогда не буду пользоваться node.js — религия не позволяет. Я говорю именно о client-side.
> Я так не думаю. Вы, конечно, сделали, какие-то выводы из происходящего, но, по-моему, они преждевременны. Еще слишком рано.
А когда будет поздно?
> Вот тут вы серьезно ошибаетесь, по-моему. Isolates это замена коллбэкам, как модели асинхронного выполнения. Это те самые легковесные изолированные процессы на которых живет Erlang и которые есть в Go. Ладно, не те самые, тут нужно смотреть в реализацию. Но это именно они. И это меня очень радует по массе причин.
И нафиг они сдались на клиенте?
> Я вообще не говорю про сервер. Я никогда не буду пользоваться node.js — религия не позволяет. Я говорю именно о client-side.
Тогда мне непонятен смысл этого спора. От появления Dart на клиенте изоляты не появятся.
А когда будет поздно?
> Вот тут вы серьезно ошибаетесь, по-моему. Isolates это замена коллбэкам, как модели асинхронного выполнения. Это те самые легковесные изолированные процессы на которых живет Erlang и которые есть в Go. Ладно, не те самые, тут нужно смотреть в реализацию. Но это именно они. И это меня очень радует по массе причин.
И нафиг они сдались на клиенте?
> Я вообще не говорю про сервер. Я никогда не буду пользоваться node.js — религия не позволяет. Я говорю именно о client-side.
Тогда мне непонятен смысл этого спора. От появления Dart на клиенте изоляты не появятся.
> От появления Dart на клиенте изоляты не появятся.
Они часть стандарта языка, соответственно, будут на всех поддерживаемых платформах. В частности, client-side пример использования Isolate уже есть(https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/isolate/).
Они часть стандарта языка, соответственно, будут на всех поддерживаемых платформах. В частности, client-side пример использования Isolate уже есть(https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/isolate/).
> Они часть стандарта языка, соответственно, будут на всех поддерживаемых платформах.
Так и V8 сейчас есть на всех поддерживаемых платформах.
Я не понимаю тогда аргумента «V8 — это всего лишь один из движков». V8 распространен сильнее чем Dart и очень нескоро появится платформа с поддержкой Dart и без поддержки V8.
Так и V8 сейчас есть на всех поддерживаемых платформах.
Я не понимаю тогда аргумента «V8 — это всего лишь один из движков». V8 распространен сильнее чем Dart и очень нескоро появится платформа с поддержкой Dart и без поддержки V8.
V8 это реализация стандарта ECMAScript. V8 isolates это внутренняя сущность этой реализации, причем сущность, о которой нет ничего в стандарте и к которой нет интерфейса для выполняемого кода. V8 isolates можно использовать только «снаружи», из приложения в котором работает этот самый V8.
Более того, если даже к V8 isolates был JS-интерфейс, это было бы нестандартным расширением, не поддерживаемым прочими JS-движками. Про нестандартные, хотя и полезные расширения, сразу вспоминаем IE и кучу других примеров.
С Dart абсолютно другая история. Isolates — часть стандарта языка(!), и это самое важное. Они обязаны быть в любой его реализации.
Более того, если даже к V8 isolates был JS-интерфейс, это было бы нестандартным расширением, не поддерживаемым прочими JS-движками. Про нестандартные, хотя и полезные расширения, сразу вспоминаем IE и кучу других примеров.
С Dart абсолютно другая история. Isolates — часть стандарта языка(!), и это самое важное. Они обязаны быть в любой его реализации.
Ну и что, простите?
Есть машина V8, в которой есть изоляты.
Появится какая-нибудь Dart-VM, в которой тоже будут изоляты.
Кому жарко/холодно от наличия/отсутствия изолятов в каких-то других движках?
Есть машина V8, в которой есть изоляты.
Появится какая-нибудь Dart-VM, в которой тоже будут изоляты.
Кому жарко/холодно от наличия/отсутствия изолятов в каких-то других движках?
1 — V8 isolates != Dart isolates. Это вообще разные понятия. В JS вообще нет ничего подобного.
2 — Dart это не один движок, это стандарт(в будущем). В любой Dart VM и в любом компиляторе Dart isolates быть обязаны как часть стандарта.
2 — Dart это не один движок, это стандарт(в будущем). В любой Dart VM и в любом компиляторе Dart isolates быть обязаны как часть стандарта.
В JS нет, в V8 нет. Считайте V8 стандартом и проблема решена.
Складывается ощущение, будто Вы ожидаете появления каких-то других реализаций Dart, не от Гугла.
Складывается ощущение, будто Вы ожидаете появления каких-то других реализаций Dart, не от Гугла.
Тьфу, «в V8 есть», конечно же.
> будто Вы ожидаете появления каких-то других реализаций Dart
А почему бы и нет, собственно? Он не настолько плох. А если «взлетит» — наверняка будут.
> Считайте V8 стандартом
С чего это я должен считать стандартом одну из реализаций? Есть стандарт ECMAScript и это главное. Реализации должны следовать стандарту и все.
А почему бы и нет, собственно? Он не настолько плох. А если «взлетит» — наверняка будут.
> Считайте V8 стандартом
С чего это я должен считать стандартом одну из реализаций? Есть стандарт ECMAScript и это главное. Реализации должны следовать стандарту и все.
> А почему бы и нет, собственно? Он не настолько плох. А если «взлетит» — наверняка будут.
Смысл Дарта — привязать всех разработчиков к гугловой платформе.
Не будет альтернативных реализаций.
> Реализации должны следовать стандарту и все.
Мы, видимо, в разных галактиках живём.
Смысл Дарта — привязать всех разработчиков к гугловой платформе.
Не будет альтернативных реализаций.
> Реализации должны следовать стандарту и все.
Мы, видимо, в разных галактиках живём.
«Должны» != «Следуют». Но они именно «должны», стандарт он в любой галактике стандарт.
> Не будет альтернативных реализаций.
Даже если и не будет — в гугловской реализации будут. Я собираюсь попробовать Дарт в любом случае, и только потом судить.
> Не будет альтернативных реализаций.
Даже если и не будет — в гугловской реализации будут. Я собираюсь попробовать Дарт в любом случае, и только потом судить.
Ну а я собираюсь пробовать V8.
Я совершенно не против существования Дарта, хотя вряд ли буду им пользоваться. Я против гугловской риторики «джаваскрипт плохой, мы хотим его убить».
Я совершенно не против существования Дарта, хотя вряд ли буду им пользоваться. Я против гугловской риторики «джаваскрипт плохой, мы хотим его убить».
Я, в свою очередь, прекрасно понимаю эту риторику и нередко ее разделяю. В JS есть ужасные на мой взгляд вещи — я уже приводил примеры. И «убить» может оказаться проще, чем «переработать до вменяемого состояния».
> В JS есть ужасные на мой взгляд вещи — я уже приводил примеры
Я что-то пропустил?
Я что-то пропустил?
Про строгость типизации я же не просто так говорил, для меня это однозначный минус.
На всякий случай повторюсь — динамическая типизация это нормально. Нестрогая типизация с неявными приведениями типов — ужас.
На всякий случай повторюсь — динамическая типизация это нормально. Нестрогая типизация с неявными приведениями типов — ужас.
кстати, code.google.com/p/jdart/
> нафиг они сдались на клиенте?
Простите, вы сами знаете, что сейчас пишется на клиенте. Это просто другая модель асинхронности, замена коллбэкам.
Лучше это или хуже — субъективный вопрос. Мне ближе и приятнее.
> А когда будет поздно?
Я думаю, что обо всем нужно думать просто вовремя, не рано и не поздно. =)
Простите, вы сами знаете, что сейчас пишется на клиенте. Это просто другая модель асинхронности, замена коллбэкам.
Лучше это или хуже — субъективный вопрос. Мне ближе и приятнее.
> А когда будет поздно?
Я думаю, что обо всем нужно думать просто вовремя, не рано и не поздно. =)
Если isolates те же коллбэки — зачем убивать язык с callback-ами и внедрять язык с isolates? Кому лучше-то стало от этого?
Вам, кажется, слишком нравится JavaScript, чтобы я смог это объяснить. Но я попробую:
1 — борьба с global shared state стоит того. Isolates довольно прозрачно укладываются на OS threads и между ними нет shared state, следовательно нет оверхеда на синхронизацию. То есть, он есть, но он совсем другой.
2 — при наличии нормального средства интроспекции isolates проще отлаживать и профилировать. Тут нет stack trace на 50 вызовов.
3 — если иметь заточенный под акторы GC, вообще начинаются сплошные плюсы. Почитайте, как работает рантайм и GC Эрланга. Если вам после этого не захочется писать на нем, а не на Node.js, вы, извините, фанатик и конструктивной беседы не выйдет.
1 — борьба с global shared state стоит того. Isolates довольно прозрачно укладываются на OS threads и между ними нет shared state, следовательно нет оверхеда на синхронизацию. То есть, он есть, но он совсем другой.
2 — при наличии нормального средства интроспекции isolates проще отлаживать и профилировать. Тут нет stack trace на 50 вызовов.
3 — если иметь заточенный под акторы GC, вообще начинаются сплошные плюсы. Почитайте, как работает рантайм и GC Эрланга. Если вам после этого не захочется писать на нем, а не на Node.js, вы, извините, фанатик и конструктивной беседы не выйдет.
Ок, это всё нереально круто.
Теперь попробуйте придумать десктопное (я уж не говорю — браузерное) приложение, где это всё реально полезно.
Теперь попробуйте придумать десктопное (я уж не говорю — браузерное) приложение, где это всё реально полезно.
Десктопное — как нефиг делать. Торрент-клиент. Да и вообще любое p2p.
Вообще говоря, все, что должно по-полной использовать процессор и хорошо параллелится.
Браузерное — все, активно работающее с XHR, например. Или где там еще активно применяются коллбэки.
Вообще говоря, все, что должно по-полной использовать процессор и хорошо параллелится.
Браузерное — все, активно работающее с XHR, например. Или где там еще активно применяются коллбэки.
p2p вполне пишется на Node.js без особых проблем.
Впрочем, в связи с наличием isolates в V8 предлагаю эту ветку дискуссии закрыть.
Впрочем, в связи с наличием isolates в V8 предлагаю эту ветку дискуссии закрыть.
Вчитался в V8 isolates — все же это несколько не то. Но вполне вероятно станет плюсом в утилизации множества ядер, согласен.
> p2p вполне пишется на Node.js без особых проблем
С этим я никак не могу согласиться, но продолжать действительно не имеет смысла. Слишком сложно убедить человека, что что-то, чего он не пробовал и что кажется сложным для понимания, может сделать его жизнь и жизнь его коллег проще.
> p2p вполне пишется на Node.js без особых проблем
С этим я никак не могу согласиться, но продолжать действительно не имеет смысла. Слишком сложно убедить человека, что что-то, чего он не пробовал и что кажется сложным для понимания, может сделать его жизнь и жизнь его коллег проще.
Хм.
Я разве против Дарта? Нисколько. Нравятся вам изоляты больше, чем колбэки — пишите на них.
А мне больше нравится js. И непонятно, почему я должен в угоду корпорации гугл смириться с его смертью.
Я разве против Дарта? Нисколько. Нравятся вам изоляты больше, чем колбэки — пишите на них.
А мне больше нравится js. И непонятно, почему я должен в угоду корпорации гугл смириться с его смертью.
По-моему, о смерти JS говорить еще очень рано и предпосылки, изложенные вами в статье, мало о чем еще говорят. Гугл это не весь мир. V8 и Chrome — open-source-проекты. Даже если JS будет потеснен, умереть он от этого не умрет.
> И непонятно, почему я должен в угоду корпорации гугл смириться с его смертью.
Потому что у гугл может себе позволить убить JS, если захочет. И сделает это быстрее, чем вы можете себе представить.
Потому что у гугл может себе позволить убить JS, если захочет. И сделает это быстрее, чем вы можете себе представить.
> И нафиг они сдались на клиенте?
Допустим, мне проще иметь 10 акторов(которыми являются isolates) в каждом из которых делается N запросов к серверу, чем иметь 10*N коллбэков, цепляющихся друг за друга.
Это одна из субъективных причин.
Допустим, мне проще иметь 10 акторов(которыми являются isolates) в каждом из которых делается N запросов к серверу, чем иметь 10*N коллбэков, цепляющихся друг за друга.
Это одна из субъективных причин.
> 10 лет расхлёбываем последствия
Из прямых последствий монополии МС — только ИЕ.
С косвенными сложнее, я лучше промолчу, тут можно что угодно написать.
И вообще, ИМХО, гораздо серьезнее последствия намеренного снижения уровня вхождения в разработку. Снижения ценой строгости и культуры. Но эту тему я тоже не буду продолжать.
Из прямых последствий монополии МС — только ИЕ.
С косвенными сложнее, я лучше промолчу, тут можно что угодно написать.
И вообще, ИМХО, гораздо серьезнее последствия намеренного снижения уровня вхождения в разработку. Снижения ценой строгости и культуры. Но эту тему я тоже не буду продолжать.
> Из прямых последствий монополии МС — только ИЕ.
А этого мало что ли?
А этого мало что ли?
Не мало. Но основные проблемы не столько в нем самом, сколько в отношении к нему — его терпели. Да, это отношение можно обосновать самыми разными причинами.
Тем не менее, сейчас он активно вытесняется с рынка. И, я полагаю, скорость вытеснения неудобного продукта с рынка определяется не столько самим продуктом, сколько другими факторами. Скажем, простотой и скоростью доставки продукта-замены конечному пользователю. А в этом за последние 10 лет был значительный прогресс.
Тем не менее, сейчас он активно вытесняется с рынка. И, я полагаю, скорость вытеснения неудобного продукта с рынка определяется не столько самим продуктом, сколько другими факторами. Скажем, простотой и скоростью доставки продукта-замены конечному пользователю. А в этом за последние 10 лет был значительный прогресс.
Господибожемой. Да при чём тут производительность и прототипы. Почитайте wtfjs и подумайте сколько за каждым из постов убитых человекочасов. А потом (только без соплей про обретённую в замен мощь и гибкость) переведите в деньги.
Исходя из вашей логики, C++ не существует.
В C++ можно посмотреть ассемблер на выходе, подумать что в нём не нравиться и сделать так чтобы нравилось. На нём можно при необходимости выжимать из железок абсолютно всё. Я не фан оптимизации и не пишу на C++, но я могу понять людей которые его терпят за такую возможность. А что такого предлагает JS что в нём терпят многие сотни возможностей отстрелить себе ногу я не понимаю.
Когда нужно выжимать абсолютно всё, есть C и asm, а дизассемблировать плюсовый бинарник удовольствие весьма сомнительное и дорогое, но речь не об этом. Отвечал же я на комментарий про wtfjs и «переведите в деньги» — получается, что если «перевести в деньги» все стандартные wtf языка C++, получится сумма гораздо большая, чем в случае с js, но этот фактор никого не останавливает почему-то.
Большая. Но я озвучил выше за что её платят. Не берусь сравнить её с С, но некий смысл прослеживается. За что конкрено платят в JS?
За гибкость, нативную асинхронную модель, динамическую типизацию, замыкания.
Всё, кроме «нативной асинхронной модели» есть в Python, Ruby(хотя я его тоже недолюбливаю), многочисленных LISP'ах, Lua.
Что такое «нативная асинхронная модель» я не знаю :(
Что такое «нативная асинхронная модель» я не знаю :(
Замыкания есть в Python и Ruby? Вот так сюрприз.
Ох, ну это несложно. JS на данный момент широко применяется и работает в примерно 100% браузеров на десктопах и устройствах; это «взрослая» технология с кучей различных реализаций, фреймворков, отладчиков, профайлеров; она активно развивается и обрастает функционалом (всякий local storage, WebGL); существует много качественной литературы, обучающих материалов.
Теперь Dart. За какие-то непонятные преимущества-недостатки (трактовать можно по-разному) перед JS они всерьез предлагают отказаться от всего вообще и писать hello, world-ы по 17 тысяч строк?
Учитывая ооочень спорный характер нововведений, фрагментация браузеров по принципу поддерживаемых скриптовых языков уж точно не стоит того.
Теперь Dart. За какие-то непонятные преимущества-недостатки (трактовать можно по-разному) перед JS они всерьез предлагают отказаться от всего вообще и писать hello, world-ы по 17 тысяч строк?
Учитывая ооочень спорный характер нововведений, фрагментация браузеров по принципу поддерживаемых скриптовых языков уж точно не стоит того.
Прочитал. Я могу ещё пару десятков таких «странных» примеров привести. Дальше что?
Не ничего, всё хорошо. Непредсказуемый результат == это как раз то, что нужно для быстрого и качественного программирования.
По-моему, вот это
Вообще никак не относится к быстрому и качественному программированию. В каком месте Вам внезапно стало плохо из-за странностей с Вашего wtfjs? Давайте реальный пример.
",,," == Array((null,'cool',false,NaN,4));Вообще никак не относится к быстрому и качественному программированию. В каком месте Вам внезапно стало плохо из-за странностей с Вашего wtfjs? Давайте реальный пример.
Реальный пример: при миграции БД произошла ошибка и в один _очень важный счётчик_ записалося 0 вместо 1. Я пишу db.records.update( {_id: <bla-bla-bla>}, {$set: {my_counter: 1}}). Что бы Вы думали? Правильно! Всё нах поломалось!
Почему? Потому что в «мощный объектно-ориентированный язык» не в курсе про целые числа. Ваще. Их нельзя создать, ими нельзя оперировать, их по-человечески нельзя даже отправить наружу.
Теперь все служебные скрипты я пишу на Python.
Почему? Потому что в «мощный объектно-ориентированный язык» не в курсе про целые числа. Ваще. Их нельзя создать, ими нельзя оперировать, их по-человечески нельзя даже отправить наружу.
Теперь все служебные скрипты я пишу на Python.
Какая-то ересь, простите. Почему в Ваш важный счетчик записался 0 вместо 1?
Это не важно. Важно что простой и очевидный способ исправить ошибку привёл к полному обрушению приложения.
Нет уж позвольте. Вы пишете какой-то hate speech в адрес JS типа «язык не в курсе целых чисел» и приводите пример, из которого совершенно очевидно, что проблема либо в реализации db.records, либо в чьих-то кривых руках, но никак не в JS. Давайте разбираться.
Ок. С начала. Есть mongodb, милая такая база данных с одним маленьким дефектом, дефолтная её консоль реализована как JS интерпретатор.
В силу кривизны рук в одну из записей просачивается неверное целое значение, которое надо быстро исправить.
Я пишу просто скрипт, очень простой. Который однако выбивает всё приложение так как пишет вместо целого числа число с плавающей точкой.
Моя позиция:
1. 1 — должно быть целым числом. В любом случае, всегда, это базовое условие для существования добра во вселенной.
2. Если это невозможно из-за совместимости со стандартом 15 летней давности должна быть возможность оперировать с целыми числами хотя бы хреново с конструкциями вроде Integer(2)+Integer(5).
3. Интерпретатор должен предупреждать что собрался проинтерпретировать ввод пользователя чрез жопу.
В силу кривизны рук в одну из записей просачивается неверное целое значение, которое надо быстро исправить.
Я пишу просто скрипт, очень простой. Который однако выбивает всё приложение так как пишет вместо целого числа число с плавающей точкой.
Моя позиция:
1. 1 — должно быть целым числом. В любом случае, всегда, это базовое условие для существования добра во вселенной.
2. Если это невозможно из-за совместимости со стандартом 15 летней давности должна быть возможность оперировать с целыми числами хотя бы хреново с конструкциями вроде Integer(2)+Integer(5).
3. Интерпретатор должен предупреждать что собрался проинтерпретировать ввод пользователя чрез жопу.
И как же конкретно Ваш скрипт выбил Ваше приложение, я всё ещё не могу понять.
Ох, но это проблема mongodb, а не JS.
На каком языке было написано ваше приложение?
Много на чём (: Конкретно падавший компонент на Scala.
То есть получается, что приложение, прочитав из внешнего сторейджа нечто для себя неожиданное, упало. Причем само приложение не на яваскрипте. Так каким боком тут яваскрипт стал объектом вашей ненависти?
Также возникает вопрос — почему ваше приложение не привело данные, полученные из внешнего мира к ожидаемому этим приложением типу, раз уж используемый язык не делает это автоматически?
Также возникает вопрос — почему ваше приложение не привело данные, полученные из внешнего мира к ожидаемому этим приложением типу, раз уж используемый язык не делает это автоматически?
Точно так. См. п. 1 озвученной выше позиции.
Потому что количество комментариев оставленных пользователем — это целое число. Их не может быть 2.5 или 0.349. Если в счётчике дискретных событий любая другая хрень приложение должно упасть и указать на причину ошибки, а не корчить из себя Deep Blue приводя, парся и генерируя случайные числа.
Проблема JS в том, что он а) не позволяет корректно моделировать такие объекты, б) навязывает эту проблему всему окружению.
Потому что количество комментариев оставленных пользователем — это целое число. Их не может быть 2.5 или 0.349. Если в счётчике дискретных событий любая другая хрень приложение должно упасть и указать на причину ошибки, а не корчить из себя Deep Blue приводя, парся и генерируя случайные числа.
Проблема JS в том, что он а) не позволяет корректно моделировать такие объекты, б) навязывает эту проблему всему окружению.
Ниче не понял. Целое число в JS никогда не запишется в дробном виде, если не производить над ним математических операций.
Давайте уже куски сорса. И да, я что-то не понял, если язык со статической типизацией должен спасать от неявных преобразований типов — то что же не спас-то?
Давайте уже куски сорса. И да, я что-то не понял, если язык со статической типизацией должен спасать от неявных преобразований типов — то что же не спас-то?
Вероятно, речь об этом:
(1 + 0.1 + 0.1) * 10
ну и на десерт:
9999999999999999
(1 + 0.1 + 0.1) * 10
ну и на десерт:
9999999999999999
Проблема, видно, возникла при конвертации числа из представления в яваскрипте в представление в BSON. Посколько в яваскрипте нет зоопарка численных типов, mongo логично использовал тип с наибольшим диапазоном значений. Потом пришло приложение за данными, получило float, и рантайм, спасая разработчика от неявных преобразований, положил приложение.
И почему это проблема JS, позвольте полюбопытствовать?
По-хорошему, это, конечно, проблема mongo, раз он такой самостоятельный. Но.
Если бы на другом конце провода был язык с динамической типизацией, никаких проблем не возникло бы. А супер-пупер сэйфовый статический язык тупо лёг. И после этого статическая типизация — зло. Прикольно.
По-хорошему, это, конечно, проблема mongo, раз он такой самостоятельный. Но.
Если бы на другом конце провода был язык с динамической типизацией, никаких проблем не возникло бы. А супер-пупер сэйфовый статический язык тупо лёг. И после этого статическая типизация — зло. Прикольно.
Вы об этом у CheatEx полюбопытствуйте. Я просто разъяснил произошедшее (ну, насколько сам понял).
Ок, встречный вопрос — как должно прореагировать приложение, получив из базы количество сообщений, к примеру, 3.14 или вообще строку «blablabla»? Как мне кажется, лечь — это максимально вменяемая реакция. Альтернатива — молча чудить дальше и предоставить разработчикам с матами через пол-дня возни с матами выковырять проклятую кривую запись.
Окружение (БД) должно по-идее само думать, как это «навязывает». Пресловутый MySQL не даст просто так записать вещественное число в поле INT, даже если окружение очень этого захочет.
А веб-приложение, получившее в get-параметре 'page' строку 'blahblahblah' тоже должно падать?
И в том, и в другом случае мы имеем дело с данными из внешнего источника, неподконтрольного приложению. В одном случае данные портят злонамеренные пользователи, в другом — администратор, по ошибке.
И в том, и в другом случае мы имеем дело с данными из внешнего источника, неподконтрольного приложению. В одном случае данные портят злонамеренные пользователи, в другом — администратор, по ошибке.
М… Есть другие варианты?
Конечно. Отобразить первую страницу результатов, предложить пользователю поиск, и т.п. Что действительно не вариант — так это закрывать сокет, укладывать application server на лопатки прекращая обслуживание тысяч других клиентов и ждать полчаса пока админ проснется. Или вы что-то другое подразумеваете под «падать»?
Принцип надежности ( en.wikipedia.org/wiki/Robustness_principle ) говорит о том, что необходимо принимать любой однозначно интерпретируемый сигнал на входе, но на выходе отдавать все ровно по спеке.
1.0 там, где ожидается целое число интерпретируется однозначно.
Принцип надежности ( en.wikipedia.org/wiki/Robustness_principle ) говорит о том, что необходимо принимать любой однозначно интерпретируемый сигнал на входе, но на выходе отдавать все ровно по спеке.
1.0 там, где ожидается целое число интерпретируется однозначно.
Есть варианты?
Считать данные из базы недоверенными — это всё же слишком, как мне кажется, по крайней мере если мы сами их туда кладём.
Обоснование просто — шанс положить в базу что-то кривое в результате ошибки никак не больше шанса положить это самое кривое из одной перееменной в другую — без всякой базы.
Обоснование просто — шанс положить в базу что-то кривое в результате ошибки никак не больше шанса положить это самое кривое из одной перееменной в другую — без всякой базы.
Обоснование просто — шанс положить в базу что-то кривое в результате ошибки никак не больше шанса положить это самое кривое из одной перееменной в другую — без всякой базы.
Шанс положить в базу что-то кривое (кривое с точки зрения приложения) куда выше, так как к базе имеют доступ и другие приложения. Как правило, приложение в состоянии проконтролировать содержимое собственной памяти (=содержимое своих переменных). С базой это не так.
еще один пост на тему «Какой я умный и какие дибилы работают в гугле».
JavaScript хорош, не спорю. Но его следует уничтожить как минимум за то, что позволяет сделать так:
JavaScript хорош, не спорю. Но его следует уничтожить как минимум за то, что позволяет сделать так:
undefined = 'My cool value';И заодно Си, за то что позволяет сделать так:
#define TRUE FALSE //счастливой отладки, суки...кстати да, C в свое время был также далеко не лучшим (в том числе в архитектурном плане).
Пайтон:
bolk@dhcp-174 ~ $ python
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> True,False=False,True
>>> True
False
Кстати, в EcmaScript 5 так сделать уже нельзя.
Очень хотелось бы ваш доклад услышать/увидеть. Жаль, напрямую физически не смогу поучавствовать.
По поводу того, как они допустили Dart. Не забываем, что разработчикам отдела, могло прийти тех. задание на разработку нового ЯП, отличающегося от JS.
Маркетологам, могло прийти задание — развить план внедрения в продукты google.
Адвокатам — готовиться защищаться от Oracle за марку «JavaScript».
и т.д.
По поводу того, как они допустили Dart. Не забываем, что разработчикам отдела, могло прийти тех. задание на разработку нового ЯП, отличающегося от JS.
Маркетологам, могло прийти задание — развить план внедрения в продукты google.
Адвокатам — готовиться защищаться от Oracle за марку «JavaScript».
и т.д.
имхо, гугл хочет типизацию + возможность делать байт-код (или что-то подобное). во-первых, скорость исполнения. во-вторых, проще писать вебапп с поддержкой оффлайн (гугл давно не хочет делать всякие gears). В-третьих, реализации JS не на 100% совместимы в разных браузерах.
По всей видимости, у них стоял выбор: сделать новый стандарт JS или новый язык. С новым языком проще, ибо патенты, обратная совместимость и много других проблем.
По всей видимости, у них стоял выбор: сделать новый стандарт JS или новый язык. С новым языком проще, ибо патенты, обратная совместимость и много других проблем.
К сожалению, те, кто пишет код очень редко могут называться программистами. Именно поэтому я считаю «светлый» путь не просто сложным, а невозможным. Квалификация специалистов часто слишком низкая, чтобы позволять им вольности.
То же самое относится к функциональной парадигме. Из личного опыта: на потоке в университете было 100 человек, в основном «золотые медалисты», из них 10 поняли, 30 зазубрили билеты. Остальные же получили свой низший проходной балл. Конечно, теперь 90% работают «программистами».
То же самое относится к функциональной парадигме. Из личного опыта: на потоке в университете было 100 человек, в основном «золотые медалисты», из них 10 поняли, 30 зазубрили билеты. Остальные же получили свой низший проходной балл. Конечно, теперь 90% работают «программистами».
Суровых ООПшиков крайне сложно чем-то удивить и уж тем более, доказать, что FP — чище, мощнее и логичнее.
пишу на кофескрипте.
доволен.
доволен.
Это было к этому абзацу:
JavaScript — высокоуровневый и чрезвычайно мощный объектно-ориентированный язык, и именно поэтому все попытки его «улучшить» проваливаются с треском (ну, пока, по крайней мере).
Улучшил же товарищ jashkenas, пусть и надстройкой.
Да так, что в Руби на Рельсах 3.1 теперь Кофескрипт стоит по умолчанию.
Я сам с Дартом не разбирался, но пока так понял, что это как Кофескрипт, только с поставленной целью достижения скоростей выше, чем у Яваскрипта. Сам в Экмаскрипте не разбираюсь, поэтому поверю гугловцам на слово в том, что в Яваскрипте есть какие-то тормоза и пережитки.
Другое дело, что объявление его прошло как-то сумбурно.
Все мечутся с круглыми глазами с возгласами «Что такое Дарт???».
Им бы поучиться искусству презентации у покойного Стива Джобса.
JavaScript — высокоуровневый и чрезвычайно мощный объектно-ориентированный язык, и именно поэтому все попытки его «улучшить» проваливаются с треском (ну, пока, по крайней мере).
Улучшил же товарищ jashkenas, пусть и надстройкой.
Да так, что в Руби на Рельсах 3.1 теперь Кофескрипт стоит по умолчанию.
Я сам с Дартом не разбирался, но пока так понял, что это как Кофескрипт, только с поставленной целью достижения скоростей выше, чем у Яваскрипта. Сам в Экмаскрипте не разбираюсь, поэтому поверю гугловцам на слово в том, что в Яваскрипте есть какие-то тормоза и пережитки.
Другое дело, что объявление его прошло как-то сумбурно.
Все мечутся с круглыми глазами с возгласами «Что такое Дарт???».
Им бы поучиться искусству презентации у покойного Стива Джобса.
> Те, кто пытался использовать JS на серверах, скажут вам, что главная проблема V8 — стабильность работы.
Главная проблема JS на серверах, равно как и на толстых клиентах — спагетти кода обработчиков событий асинхронных коллов, а также высокий риск привнести в приложение «утечки памяти» в виде объектов, неубиваемых через GC. Собсно, ради решения первой проблемы этой проблемы и был создан CoffeeScript.
Главная проблема JS на серверах, равно как и на толстых клиентах — спагетти кода обработчиков событий асинхронных коллов, а также высокий риск привнести в приложение «утечки памяти» в виде объектов, неубиваемых через GC. Собсно, ради решения первой проблемы этой проблемы и был создан CoffeeScript.
Спагетти кода лечится тривиальным фреймворком в 10 строчек, которых изобретено миллион.
Зачем сам язык-то переделывать? Какое отношение имеет внедрение классовой парадигмы к спагетти-коду коллбэков?
Зачем сам язык-то переделывать? Какое отношение имеет внедрение классовой парадигмы к спагетти-коду коллбэков?
Затем, что язык сам по себе сделан с костылями в виде prototype. И, да, дайте ссылку на фреймворк, пожалуйста. А то мужики-то не знают…
с костылями в виде prototype
Ну понятно. Дальше разговор можно не продолжать.
ну хоть один сознался, что не понимает, почему prototype в JS — это костыль =)
>Классы в Java — это костыль.
Звучит как-то толстенько.
Звучит как-то толстенько.
У вас бурная фантазия =)
Главный идеологический инструмент в JS — замыкание, а прототипирование в нем за уши притянуто в угоду скорости выполнения кода и гигантской армии приверженцев канонического ООП.
Главный идеологический инструмент в JS — замыкание, а прототипирование в нем за уши притянуто в угоду скорости выполнения кода и гигантской армии приверженцев канонического ООП.
Я когда в первый раз столкнулся с этими уродцами в виде метаклассов в Lua — неделю ходил, а руки дрожали.
Не понимал почему они не могли сделать нормальные классы, ну что им сложно было? Наверное самые умные?
И переменные которые, если специально не попросить, улетают в глобальную область видимости( а для всех «нормальных» языках это нонсенс )…
Даже как-то собрался переписать внутренности луа чтобы сделано его «нормальным»
… С тех пор прошло 7 лет.
Не понимал почему они не могли сделать нормальные классы, ну что им сложно было? Наверное самые умные?
И переменные которые, если специально не попросить, улетают в глобальную область видимости( а для всех «нормальных» языках это нонсенс )…
Даже как-то собрался переписать внутренности луа чтобы сделано его «нормальным»
… С тех пор прошло 7 лет.
У JavaScript есть всего лишь две проблемы:
— криворукие программисты, которые нам нем пишут (популярная проблема среди многих языков программирования)
— плохая поддержка средами разработки ввиду слишком большой гибкости.
Dart никакую из этих проблем не решает.
— криворукие программисты, которые нам нем пишут (популярная проблема среди многих языков программирования)
— плохая поддержка средами разработки ввиду слишком большой гибкости.
Dart никакую из этих проблем не решает.
1. Модули и библиотеки встроены в язык!
2. Новый язык позволяет избирательно осуществлять совместимость со старым кодом
3. В спецификации Дарта типизация не имеет эффекта в production mode (п. 13.1), в лучшем случае «намёк» кодогенератору
ЗЫ По мне сейчас что Dart, что CoffeeScript, оба транслируются в Джаваскрипт
2. Новый язык позволяет избирательно осуществлять совместимость со старым кодом
3. В спецификации Дарта типизация не имеет эффекта в production mode (п. 13.1), в лучшем случае «намёк» кодогенератору
ЗЫ По мне сейчас что Dart, что CoffeeScript, оба транслируются в Джаваскрипт
Сразу видно специалист по созданию больших онлайн приложений. Куда уж гуглу до вас, с его опытом разработки на javascript проектов уровня google docs и видения проблем такой разработки. И конечно же, GWT сделали от нечего делать, ведь на javascript так просто всё делать, а GWT запили ради прикола.
конечно, GWT вообще не существует: весь код транслируется в JS ручками несчастных индусских детей. =)
А топикстартер — авторитет однозначно, достаточно профайл полистать. Скажите, где можно записаться в очередь за автографом? :D
А топикстартер — авторитет однозначно, достаточно профайл полистать. Скажите, где можно записаться в очередь за автографом? :D
Ваш коммент, очевидно, следует понимать так: всё, что делает гугл, по определению, хорошо и продумано; никто не имеет права указывать гуглу на возможные ошибки; гугл никогда не ошибается.
Мне нравится, что делает гугл, за этим я считаю будущее. Приятно, что ИТ движется вперед и появился достойный конкурент Microsoft. Microsoft спасибо, они выдернули ИТ из командной строки доса. Но на этом и стопанулись. Сейчас примерно тоже время, и гугл сейчас пытается нас выдернуть из очередной «строки доса». И я где надо поддержу, а где надо помогу реальным делом.
скажу Вам больше, MS не только выдернули «ИТ из командной строки доса», но и продолжают развивать.
раскрою свою точку зрения.
как известно, конкуренция всегда на пользу потребителям. так MS явялется одним из тех компаний, которые создают конкуренцию на любом рынке.
другое дело, что это иногда может перерасти в монополию, но этот факт опустим.
итак
1) поиск — Bing
2) облака — Azure
3) браузеры — IE
4) БД — SQL Server
5) IDE — Visual Studio
6) виртуализация — HyperV
7) провайдер почты — Hotmail
8) мобильные ОС — WP7
9) языки и платформы для разработки — .NET
10) Windows ;)
думаю Вы сами прекрасно подберете конкурентов к вышеперечисленным продуктам.
я к тому, что MS цитата
>Но на этом и стопанулись
ни в коем случае.
сколько людей пилит WebKit? в разработке участвуют многие компании, от одной Apple — более 200.
сколько лет пилят? ну если считать от KHTML, то более 10.
вопрос: за какое время MS смогла создать новый IE9, добавив прорисовку страниц на GPU, ускорив обработку JS до уровня V8?
ответ: за 1 год.
и это компания, которая стопанулась?
раскрою свою точку зрения.
как известно, конкуренция всегда на пользу потребителям. так MS явялется одним из тех компаний, которые создают конкуренцию на любом рынке.
другое дело, что это иногда может перерасти в монополию, но этот факт опустим.
итак
1) поиск — Bing
2) облака — Azure
3) браузеры — IE
4) БД — SQL Server
5) IDE — Visual Studio
6) виртуализация — HyperV
7) провайдер почты — Hotmail
8) мобильные ОС — WP7
9) языки и платформы для разработки — .NET
10) Windows ;)
думаю Вы сами прекрасно подберете конкурентов к вышеперечисленным продуктам.
я к тому, что MS цитата
>Но на этом и стопанулись
ни в коем случае.
сколько людей пилит WebKit? в разработке участвуют многие компании, от одной Apple — более 200.
сколько лет пилят? ну если считать от KHTML, то более 10.
вопрос: за какое время MS смогла создать новый IE9, добавив прорисовку страниц на GPU, ускорив обработку JS до уровня V8?
ответ: за 1 год.
и это компания, которая стопанулась?
не преувеличивайте достижения MS:
1. Bing не родился бы, не купи MS Powerset
2. Azure не родился бы, не выкати Amazon свой EC2
3. IE — инновация? (смех в зале)
4. SQL Server — выходец из Sybase
5. VS — один из редких продуктов, созданных целиком в коридорах MS
6. Hyper-V — например, тот же Xen умеет несколько больше, нежели решение от MS.
7. Hotmail, WP7 — улыбнуло
9. .NET — самая сильная и одновременно самая слабая сторона лагеря MS.
10. Windows :)
MS потерялась где-то в 2000-2001 годах, когда рулевые в MS поняли, что благодаря WWW, MS Windows перестала быть доминирующей платформой. Хотя, да, в последние годы MS пытается наверстать упущенное. Но как-то не слишком успешно получается ;)
1. Bing не родился бы, не купи MS Powerset
2. Azure не родился бы, не выкати Amazon свой EC2
3. IE — инновация? (смех в зале)
4. SQL Server — выходец из Sybase
5. VS — один из редких продуктов, созданных целиком в коридорах MS
6. Hyper-V — например, тот же Xen умеет несколько больше, нежели решение от MS.
7. Hotmail, WP7 — улыбнуло
9. .NET — самая сильная и одновременно самая слабая сторона лагеря MS.
10. Windows :)
MS потерялась где-то в 2000-2001 годах, когда рулевые в MS поняли, что благодаря WWW, MS Windows перестала быть доминирующей платформой. Хотя, да, в последние годы MS пытается наверстать упущенное. Но как-то не слишком успешно получается ;)
я сказал, что они создают конкуренцию, но не сказал, что создают везде новые технологии.
тем более, что IE — инновация. действительно смех в зале.
моя мысль в том, что пока куча компаний будет пилить новые языки, новые платформы, MS всегда создаст их аналог и будет им конкурентом.
а по поводу
>.NET — самая сильная и одновременно самая слабая сторона лагеря MS
хотелось бы, чтоб мысль раскрыли.
тем более, что IE — инновация. действительно смех в зале.
моя мысль в том, что пока куча компаний будет пилить новые языки, новые платформы, MS всегда создаст их аналог и будет им конкурентом.
а по поводу
>.NET — самая сильная и одновременно самая слабая сторона лагеря MS
хотелось бы, чтоб мысль раскрыли.
Оценивать надо каждый продукт отдельно, безотносительно своего отношения к компании. У гугла далеко не все продукты достойного качества.
Т.е. все те кто против dart, против движения в онлайн облака — вы примерно как те люди, которые кричали, что dos, круче windows 95. Я конечно слабо помню то время, хотя в фидошках были такие настроения.
Скажу вам по секрету, автор по своей професии работает с проектами на JS уровня гугла.
Dart ориентирован как Better Language Translated to JavaScript внутри Гугла для замены GWT и Google Closure library, стрельнёт он или нет в глобальном масштабе — вопрос второй
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я не верю в Dart