Я терпела это долго и честно, но наконец не выдержала.
Может, вместе разберемся? Итак, предположим, кто-то решил создать _новый_ язык сценариев.
И, скажем, он называет его Руби.
Попробуем понять, зачем это вообще нужно делать? Чего мы ожидаем от языка сценариев? Все это, на мой взгляд, вполне очевидно, но желающие могут, конечно, повозиться.
Например, описать преимущества и недостатки можно примерно так: Минусы: - новый синтаксис, требующий изучения; — низкая производительность по сравнению с нативным кодом; Плюсы: — автоматический сбор мусора; - синтаксический сахар; — типизация во время выполнения; — расширяемость объектов во время выполнения.
Как это.
Таким образом, создатель скриптового языка сначала _отказывается от производительности_ ради других преимуществ.
Это очень важное архитектурное решение и мы к нему вернемся позже.
При создании нового языка сценариев вам необходима связь между виртуальной машиной (виртуальной машиной, на которой выполняется сценарий) сценария и внешним миром.
Нужны модули, библиотеки, фреймворки и прочие реализации, простите меня за это старое русское слово.
При обсуждении возможностей того или иного скриптового языка приверженцы скриптовых культов могут обсуждать следующие совершенно разные темы: — о синтаксисе и удобстве самого языка (например, встроенный eval()); — об удобной реализации определенного функционала, который реализуется определенной библиотекой (например, регулярными выражениями или встроенным веб-сервером); — о скорости выполнения вычислений «внутри» ВМ (например, сортировка массива); — о скорости совершения звонков с ВМ во внешний мир (библиотеку, ОС) (например, запись в файл).
Итак, вот оно.
Только первый пункт имеет отношение к языку сценариев.
Только его.
Все остальное связано с реализацией.
Не к самому языку.
Если скриптовый холивар не говорит о первом пункте, то тогда ему следует отметить, что он говорит уже не о языке, а о платформе: конкретной реализации скриптового языка на конкретной ОС или на конкретной ВМ.
Первая диссертация.
Преимуществом скриптового языка не может быть наличие библиотек, реализующих тот или иной функционал.
Все это зависит исключительно от реализации скриптового языка.
Возьмем, к примеру, эту статью: habrahabr.ru/blogs/ruby/69314 Здесь описывается реализация www-сервера в Ruby. Но что на самом деле здесь дает Руби? Смотрите, я только что написал www-сервер на JavaScript: вар www_server = новый веб-сервер ('127.0.0.1', 3456); Он принимает запросы и доставляет файлы.
Ты веришь в это? И у меня есть такая реализация WWW-сервера.
И теперь вы знаете, что JavaScript — хороший язык и на нем легко создавать веб-серверы, верно? Знаешь или не знаешь? Кстати, Doom 4 тоже будет легко запускать на JavaScript. Ну, когда выйдет. Смотри сюда: вар doom4 = новый Doom4(); Круто, правда? В следующих бутылочках мы продолжим знакомство с javascript, а сейчас возвращаемся к нашей теме.
Давайте теперь возьмем конкретно Ruby. Извините, оно упало мне на колени, но в принципе это мог быть любой другой язык.
Например, я читаю о возможностях Ruby и немного охренел.
D0.92.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D0.BE.D1.81.D1.82 .
D0.B8_Рубин " Он имеет краткий и простой синтаксис, на который частично повлияли Ada, Eiffel и Python. Позволяет обрабатывать исключения в стиле Java и Python. Позволяет переопределять операторы, которые на самом деле являются методами.
Полностью объектно-ориентированный язык программирования.
Не поддерживает множественное наследование, но вместо него можно использовать концепцию «миксинов», основанную в этом языке на механизме модулей.
Содержит автоматический сборщик мусора.
Он работает для всех объектов Ruby, включая внешние библиотеки.
Поддерживает замыкания с полной привязкой к переменным.
" Хм.
Чего из этого нет в JavaScript? Ну, может быть, переопределение операторов.
И? О чем весь этот шум? «В Ruby есть множество оригинальных решений, которые редко встречаются в распространенных языках программирования.
Добавлять методы можно не только к любым классам, но и к любым объектам.
Например, к некоторой строке можно добавить произвольный метод».
JavaScript: «Любая конструкция в Ruby возвращает значение.
Например:" Гыйыгыгы.
Предупреждение(а? "а": "б"); «Работа с массивами — одна из сильных сторон Ruby. Они автоматически изменяют размер, могут содержать любой элемент, а язык предоставляет мощные инструменты для их обработки».
Ну тут даже говорить не о чем.
JavaScript просто сносит Ruby. Намба, тезис второй.
Синтаксис и возможности JavaScript полностью превосходят другие языки сценариев, они _независимы от реализации_, но уже являются частью языка.
Небольшие преимущества, обеспечиваемые синтаксическим сахаром конкурентов, быстро сводятся на нет eval(), JSON, аргументами и другими приятными функциями JavaScript. Я не большой эксперт в скриптовых языках.
Пожалуйста, покажите мне, как использовать eval() в PHP, Ruby, Python. Существует ли значение null, обладающее особыми свойствами? Могу ли я работать с переданными аргументами любой функции как с массивом аргументов? Могу ли я создать объект с данными и методами, написав: var o = { животное:'dog', Dead: false, kill: function() { if (!this.dead) this.dead = true; } } Напишите пожалуйста примеры.
А может быть я чего-то упорно не понимаю и есть какие-то тайные знания о тайных возможностях этих скриптовых языков, которые постигли лишь немногие просвещенные? И большая просьба — примеры того, что НЕЛЬЗЯ сделать на JavaScript. За основу берем Ecma-262. Что вы можете написать в других скриптах, чего просто невозможно сделать в JavaScript? Сейчас я просто хамски пройдусь по реализациям этих скриптовых языков.
Вот где JavaScript может отдохнуть.
Самое интересное наступает, когда вы начинаете запускать множество сценариев одновременно.
А потом оказывается, что хвалёные скриптовые машины быстро или медленно умирают. Небольшая разборка выявляет интересную деталь — разработчики этих скриптовых языков по какой-то странной и загадочной причине сосредоточились на производительности.
Сразу! Их настолько увлекли эротические фантазии, связанные с удивительным новым синтаксисом, что никому не пришла в голову простая идея: они должны с самого начала предоставить реализацию, позволяющую быстро выполнять множество скриптов.
В результате читаем: Рубин: 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 1.8 — один из самых медленных языков программирования, используемых в практике веб-разработки».
PHP. php.russofile.ru/ru/translate/unsort/optimizing/#01 «Сценарий PHP загружается в Zend Engine и компилируется в опкод. Код операции можно оптимизировать с помощью дополнительного оптимизатора Zend Optimizer. В зависимости от скрипта это может увеличить скорость выполнения PHP-скрипта до 50%.
Раньше после выполнения опкод уничтожался.
„ Лирическое отступление.
Разве это не блестяще? Ну кто-кто в целом мире мог подумать, что скомпилированные скрипты можно кэшировать? Ну, ты, должно быть.
Билл Гейтс, наверное.
Или двое Врат сразу.
Надеюсь, вы понимаете, над чем именно я иронизирую? Вот по этому: «был», «были недостатки, которые устранили», «раньше была полная хрень».
Я не понимаю, зачем начинать с дрянной производительности.
Ну объясните мне! Пожалуйста! Зачем тогда создается новый язык сценариев? Хорошо, допустим, вы предлагаете свой новый супермодный скриптовый язык для домашнего использования и написания студенческих работ. Тогда я понимаю - производительность не имеет значения.
Но если вы предлагаете использовать свой язык для динамической генерации контента загруженного веб-сайта, то у меня есть сильное подозрение, что производительность является _самым_важным_ критерием.
Так что следующий тезис не имеет никакого отношения к JavaScript, это очередная порция яда по отношению к другим.
Бесплатная диссертация по Намбе.
Реализации новых скриптовых языков изначально не содержали оригинального архитектурного решения, которое позволяло бы выжать из них максимальную производительность: многопоточное выполнение, пулы общих внутренних структур (контекстов выполнения, например), предварительная компиляция, кастомная компиляция из промежуточный байт-код. Однако большинство этих языков были предложены специально для секторов, связанных с большими нагрузками, например, веб-серверов.
И поэтому довольно забавно читать, как PHP используется для обработки веб-запросов.
Сразу хочу спросить - а может мне стоило взять Бейсик? Это также предусмотрено сценарием.
И работает он медленно.
Получилось немного сумбурно и, возможно, местами немного резковато.
Надеюсь, никто не принял мои комментарии на свой счет и не обиделся.
Я буду рад найти истину вместе с вами.
Теги: #JavaScript #ruby #python #php #Chulan
-
Максимальные Меры Безопасности
19 Oct, 24 -
Компании Видеонаблюдения В Дубае
19 Oct, 24 -
Электрические Сети Могут Привести К Эре 5G
19 Oct, 24 -
Как Мы Участвовали В Slush 2015 (Хельсинки)
19 Oct, 24 -
Копирование Структуры Таблицы В Ms Sql 2005
19 Oct, 24 -
Новая Версия V8 Будет На 50% Быстрее
19 Oct, 24 -
Colocall.net Полностью Упал
19 Oct, 24
