Я долго и честно терпел, но, наконец, не выдержал. Может мы вместе можем разобраться?
Итак, предположим некто решил создать _новый_ скриптовый язык. И, допустим, называет его 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 применяется для обработки веб-запросов. Сразу хочется спросить — может надо было бейсик взять? Он тоже скриптовый. И тоже медленно работает…
Вышло несколько сумбурно и местами резковато, возможно.
Надеюсь никто не воспринял мои замечания лично и не обиделся.
Буду рад найти истину вместе с вами.