Я долго и честно терпел, но, наконец, не выдержал. Может мы вместе можем разобраться?
Итак, предположим некто решил создать _новый_ скриптовый язык. И, допустим, называет его Ruby. Давайте попробуем понять — зачем вообще это нужно делать? Что мы ожидаем от скриптового языка? Все это, на мой взгляд, достаточно очевидно, но желающие могут и похоливарить, конечно. Например, можно расписать преимущества и недостатки примерно так:
Минусы:
— новый синтаксис, требующий изучения;
— невысокая производительность в сравнении с native-кодом;
Плюсы:
— автоматическая сборка мусора;
— синтаксический сахар;
— runtime-типизация;
— runtime-расширяемость объектов.
Примерно так. Таким образом, создатель скриптового языка первым делом _отказывается от производительности_ ради других преимуществ. Это очень важное архитектурное решение и мы вернемся к нему позже.
При создании нового скриптового языка — нужна связь VM (виртуальная машина, испольняющая скрипт) скрипта и внешнего мира. Нужны модули, библиотеки, фреймворки и прочие имплементации, простите мне это старинное русское слово. Рассуждая о возможностях того или иного скриптового языка, приверженцы скриптовых культов могут обсуждать следующие совершенно различные темы:
— о синтаксисе и удобстве самого языка (например, встроенный eval());
— о удобной реализации некоего функционала, который реализуется некоей библиотекой (например, регулярные выражения или встроенный веб-сервер);
— о скорости выполнения вычислений «внутри» VM (например, сортировка массива);
— о скорости выполнения вызовов из VM во внешний мир (библиотеку, ОС) (например, запись в файл).
Так вот. К скриптовому языку имеет отношение только первый пункт. Только он.
Все остальное имеет отношение к реализации. Не к самому языку.
Если скриптовый холиварщик рассуждает не о первом пункте, то ему следует тогда отметить, что он рассуждает уже не о языке, а о платформе: конкретной реализации скриптового языка на конкретной ОС или на конкретной VM.
Первый тезис. Преимуществом скриптового языка не может являться наличие библиотек, которые реализуют тот или иной функционал. Все это зависит исключительно от реализации скриптового языка. Возьмем, например, эту статью:
habrahabr.ru/blogs/ruby/69314
Здесь описывается реализация www-сервера на Ruby.
Но что здесь, собственно, от Ruby?
Вот смотрите я только что написал www-сервер на JavaScript:
var www_server = new WebServer('127.0.0.1', 3456);
Он принимает запросы и отдает файлы. Верите? А у меня есть такая вот реализация ввв-сервера. И теперь вы знаете, что JavaScript — хороший язык и на нем легко создавать веб-сервера, да? Вы знаете или не знаете?
Кстати, на JavaScript также легко запустить будет Doom 4. Ну, когда он выйдет. Вот смотрите:
var doom4 = new Doom4();
Клево, правда? В следующих бутылках мы продолжим знакомство с javascript, а теперь возвращаемся к нашей теме.
Берем теперь уже конкретно Ruby. Уж, извините, попался мне под руку, но это мог быть и любой другой язык, в принципе.
Вот, например, я читаю возможности Ruby и слегка офигеваю.
ru.wikipedia.org/wiki/Ruby#.D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D0.B8_Ruby
"
Имеет лаконичный и простой синтаксис, частично разработанный под влиянием Ада, Эйфель и Python.
Позволяет обрабатывать исключения в стиле Java и Python.
Позволяет переопределять операторы, которые на самом деле являются методами.
Полностью объектно-ориентированный язык программирования.
Не поддерживает множественное наследование, но вместо него может использоваться концепция «примесей», основанная в данном языке на механизме модулей.
Содержит автоматический сборщик мусора. Он работает для всех объектов Ruby, в том числе для внешних библиотек.
Поддерживает замыкания с полной привязкой к переменным.
"
Кхм. А чего из этого нет в JavaScript? Ну разве что переопределения операторов. И? Ради чего весь шум?
«В Ruby есть немало оригинальных решений, редко или вообще не встречающихся в распространённых языках программирования. Можно добавлять методы не только в любые классы, но и в любые объекты. Например, вы можете добавить к некоторой строке произвольный метод.»
JavaScript:
«Любая конструкция в Ruby возвращает значение. Например:»
Гыыыгыгы.
alert( a? «a»: «b»);
«Работа с массивами — одна из сильных сторон Ruby. Они автоматически изменяют размер, могут содержать любые элементы и язык предоставляет мощные средства для их обработки.»
Ну тут даже говорить-то не о чем. JavaScript просто выносит Ruby.
Тезис намба два. Синтаксис и возможности JavaScript полностью превосходят другие скриптовые языки, причем они _не зависят от реализации_, а уже являются частью языка. Небольшие преимущества, который дает синтаксический сахар конкурентов, быстро оказываются задавленными eval(), JSON, arguments и прочими приятными возможностями JavaScript.
Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python. Есть ли там null, обладающий особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом arguments? Могу ли я создать в них объект с данными и методами, написав:
var o = { animal:'dog', dead: false, kill: function() { if (!this.dead) this.dead = true; } }
Пожалуйста, напишите примеры. А то может я что-то упорно не понимаю и есть какие-то секретные знания о секретных возможностях этих скриптовых языков, которых постигли немногие просветленные?
И большая просьба — примеры того, чего НЕЛЬЗЯ сделать в JavaScript. Берем Ecma-262 за основу.
Чего можно написать такого в других скриптах, чего ну никак не сделаешь в JavaScript?
Теперь я просто хамски пройдусь по реализациям скриптовых этих языков. Тут уже JavaScript отдохнет.
Самое интересное наступает, когда вы начинаете выполнять много-много скриптов одновременно. И тут выясняется, что хваленые скриптовые машины быстро или медленно умирают.
При небольших разборках выясняется интересная деталь — разработчики этих скриптовых языков по какой-то странной и загадочной причине положили на производительность. Сразу! Их настолько увлекли эротические фантазии, связанные с удивительным новым синтаксисом, что никто в голову-то и не взял простую мысль: следует с самого начала предусмотреть реализацию, позволяющую выполнять быстро много скриптов.
В результате, читаем:
Ruby:
ru.wikipedia.org/wiki/Ruby#.D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D0.B8_Ruby
«Интерпретатор Ruby на сегодняшний день имеет следующие недостатки...: Невысокая скорость работы. Ruby 1.8 является одним из самых медленных из используемых в практике веб-разработки языков программирования»
PHP.
php.russofile.ru/ru/translate/unsort/optimizing/#01
«PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode может быть оптимизирован с использованием необязательного оптимизатора, названного Zend Optimizer. В зависимости от скрипта, он может увеличить скорость выполнения PHP скрипта до 50%.
Раньше, после выполнения, opcode уничтожался. „
Лирическое отступление. Разве не гениально? Ну кто — кто бы во всем мире мог додуматься, что скомпилированные скрипты можно кешировать? Это ж надо быть… Биллом Гейтсом, наверное. Или двумя Гейтсами сразу.
Вы, надеюсь, понимаете над чем именно я иронизирую? Вот на этим: “раньше», «имел недостатки, которые были устранены», «был полным дерьмом до того, как». Я не понимаю — зачем начинать с дерьмовой производительности. Ну поясните мне! Пожалуйста! Ради чего тогда создается новый скриптовый язык?
Ну ладно, допустим Вы предлагаете свой новый супер-модный скриптовый язык для домашнего пользования и написания студенческих работ. Тогда я понимаю — производительность не имеет значения.
А вот если Вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня вот есть сильное такое подозрение, что производительность является _самым_важным_ критерием.
Так что следующий тезис не имеет отношения к JavaScript, это очередная порция яда в отношении прочих.
Тезис намба фри. Реализации новых скриптовых языков изначально не содержали исходного архитектурного решения, позволяющего выжать из них максимум производительности: многопоточное исполнение, пулы разделяемых внутренних структур (контекстов выполнения, например), предварительной компиляции, настроечной компиляции из промежуточного байт-кода. При этом большинство из этих языков предлагалось как раз для сектора, связанного с большой нагрузкой, например, веб-сервера.
И поэтому довольно забавно читать как PHP применяется для обработки веб-запросов. Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…
Вышло несколько сумбурно и местами резковато, возможно.
Надеюсь никто не воспринял мои замечания лично и не обиделся.
Буду рад найти истину вместе с вами.
Итак, предположим некто решил создать _новый_ скриптовый язык. И, допустим, называет его Ruby. Давайте попробуем понять — зачем вообще это нужно делать? Что мы ожидаем от скриптового языка? Все это, на мой взгляд, достаточно очевидно, но желающие могут и похоливарить, конечно. Например, можно расписать преимущества и недостатки примерно так:
Минусы:
— новый синтаксис, требующий изучения;
— невысокая производительность в сравнении с native-кодом;
Плюсы:
— автоматическая сборка мусора;
— синтаксический сахар;
— runtime-типизация;
— runtime-расширяемость объектов.
Примерно так. Таким образом, создатель скриптового языка первым делом _отказывается от производительности_ ради других преимуществ. Это очень важное архитектурное решение и мы вернемся к нему позже.
При создании нового скриптового языка — нужна связь VM (виртуальная машина, испольняющая скрипт) скрипта и внешнего мира. Нужны модули, библиотеки, фреймворки и прочие имплементации, простите мне это старинное русское слово. Рассуждая о возможностях того или иного скриптового языка, приверженцы скриптовых культов могут обсуждать следующие совершенно различные темы:
— о синтаксисе и удобстве самого языка (например, встроенный eval());
— о удобной реализации некоего функционала, который реализуется некоей библиотекой (например, регулярные выражения или встроенный веб-сервер);
— о скорости выполнения вычислений «внутри» VM (например, сортировка массива);
— о скорости выполнения вызовов из VM во внешний мир (библиотеку, ОС) (например, запись в файл).
Так вот. К скриптовому языку имеет отношение только первый пункт. Только он.
Все остальное имеет отношение к реализации. Не к самому языку.
Если скриптовый холиварщик рассуждает не о первом пункте, то ему следует тогда отметить, что он рассуждает уже не о языке, а о платформе: конкретной реализации скриптового языка на конкретной ОС или на конкретной VM.
Первый тезис. Преимуществом скриптового языка не может являться наличие библиотек, которые реализуют тот или иной функционал. Все это зависит исключительно от реализации скриптового языка. Возьмем, например, эту статью:
habrahabr.ru/blogs/ruby/69314
Здесь описывается реализация www-сервера на Ruby.
Но что здесь, собственно, от Ruby?
Вот смотрите я только что написал www-сервер на JavaScript:
var www_server = new WebServer('127.0.0.1', 3456);
Он принимает запросы и отдает файлы. Верите? А у меня есть такая вот реализация ввв-сервера. И теперь вы знаете, что JavaScript — хороший язык и на нем легко создавать веб-сервера, да? Вы знаете или не знаете?
Кстати, на JavaScript также легко запустить будет Doom 4. Ну, когда он выйдет. Вот смотрите:
var doom4 = new Doom4();
Клево, правда? В следующих бутылках мы продолжим знакомство с javascript, а теперь возвращаемся к нашей теме.
Берем теперь уже конкретно Ruby. Уж, извините, попался мне под руку, но это мог быть и любой другой язык, в принципе.
Вот, например, я читаю возможности Ruby и слегка офигеваю.
ru.wikipedia.org/wiki/Ruby#.D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D0.B8_Ruby
"
Имеет лаконичный и простой синтаксис, частично разработанный под влиянием Ада, Эйфель и Python.
Позволяет обрабатывать исключения в стиле Java и Python.
Позволяет переопределять операторы, которые на самом деле являются методами.
Полностью объектно-ориентированный язык программирования.
Не поддерживает множественное наследование, но вместо него может использоваться концепция «примесей», основанная в данном языке на механизме модулей.
Содержит автоматический сборщик мусора. Он работает для всех объектов Ruby, в том числе для внешних библиотек.
Поддерживает замыкания с полной привязкой к переменным.
"
Кхм. А чего из этого нет в JavaScript? Ну разве что переопределения операторов. И? Ради чего весь шум?
«В Ruby есть немало оригинальных решений, редко или вообще не встречающихся в распространённых языках программирования. Можно добавлять методы не только в любые классы, но и в любые объекты. Например, вы можете добавить к некоторой строке произвольный метод.»
JavaScript:
«Любая конструкция в Ruby возвращает значение. Например:»
Гыыыгыгы.
alert( a? «a»: «b»);
«Работа с массивами — одна из сильных сторон Ruby. Они автоматически изменяют размер, могут содержать любые элементы и язык предоставляет мощные средства для их обработки.»
Ну тут даже говорить-то не о чем. JavaScript просто выносит Ruby.
Тезис намба два. Синтаксис и возможности JavaScript полностью превосходят другие скриптовые языки, причем они _не зависят от реализации_, а уже являются частью языка. Небольшие преимущества, который дает синтаксический сахар конкурентов, быстро оказываются задавленными eval(), JSON, arguments и прочими приятными возможностями JavaScript.
Я не большой специалист по скриптовым языкам. Пожалуйста, покажите мне как сделать eval() в PHP, Ruby, Python. Есть ли там null, обладающий особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом arguments? Могу ли я создать в них объект с данными и методами, написав:
var o = { animal:'dog', dead: false, kill: function() { if (!this.dead) this.dead = true; } }
Пожалуйста, напишите примеры. А то может я что-то упорно не понимаю и есть какие-то секретные знания о секретных возможностях этих скриптовых языков, которых постигли немногие просветленные?
И большая просьба — примеры того, чего НЕЛЬЗЯ сделать в JavaScript. Берем Ecma-262 за основу.
Чего можно написать такого в других скриптах, чего ну никак не сделаешь в JavaScript?
Теперь я просто хамски пройдусь по реализациям скриптовых этих языков. Тут уже JavaScript отдохнет.
Самое интересное наступает, когда вы начинаете выполнять много-много скриптов одновременно. И тут выясняется, что хваленые скриптовые машины быстро или медленно умирают.
При небольших разборках выясняется интересная деталь — разработчики этих скриптовых языков по какой-то странной и загадочной причине положили на производительность. Сразу! Их настолько увлекли эротические фантазии, связанные с удивительным новым синтаксисом, что никто в голову-то и не взял простую мысль: следует с самого начала предусмотреть реализацию, позволяющую выполнять быстро много скриптов.
В результате, читаем:
Ruby:
ru.wikipedia.org/wiki/Ruby#.D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82.D0.B8_Ruby
«Интерпретатор Ruby на сегодняшний день имеет следующие недостатки...: Невысокая скорость работы. Ruby 1.8 является одним из самых медленных из используемых в практике веб-разработки языков программирования»
PHP.
php.russofile.ru/ru/translate/unsort/optimizing/#01
«PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode может быть оптимизирован с использованием необязательного оптимизатора, названного Zend Optimizer. В зависимости от скрипта, он может увеличить скорость выполнения PHP скрипта до 50%.
Раньше, после выполнения, opcode уничтожался. „
Лирическое отступление. Разве не гениально? Ну кто — кто бы во всем мире мог додуматься, что скомпилированные скрипты можно кешировать? Это ж надо быть… Биллом Гейтсом, наверное. Или двумя Гейтсами сразу.
Вы, надеюсь, понимаете над чем именно я иронизирую? Вот на этим: “раньше», «имел недостатки, которые были устранены», «был полным дерьмом до того, как». Я не понимаю — зачем начинать с дерьмовой производительности. Ну поясните мне! Пожалуйста! Ради чего тогда создается новый скриптовый язык?
Ну ладно, допустим Вы предлагаете свой новый супер-модный скриптовый язык для домашнего пользования и написания студенческих работ. Тогда я понимаю — производительность не имеет значения.
А вот если Вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня вот есть сильное такое подозрение, что производительность является _самым_важным_ критерием.
Так что следующий тезис не имеет отношения к JavaScript, это очередная порция яда в отношении прочих.
Тезис намба фри. Реализации новых скриптовых языков изначально не содержали исходного архитектурного решения, позволяющего выжать из них максимум производительности: многопоточное исполнение, пулы разделяемых внутренних структур (контекстов выполнения, например), предварительной компиляции, настроечной компиляции из промежуточного байт-кода. При этом большинство из этих языков предлагалось как раз для сектора, связанного с большой нагрузкой, например, веб-сервера.
И поэтому довольно забавно читать как PHP применяется для обработки веб-запросов. Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…
Вышло несколько сумбурно и местами резковато, возможно.
Надеюсь никто не воспринял мои замечания лично и не обиделся.
Буду рад найти истину вместе с вами.