Comments 39
Жуткий технический троллинг дополненный извинениями за общую неприспособленность сервера к решению задач. А в целом идея интересная.
Особенно порадовало сравнение js с перлом :)
Особенно порадовало сравнение js с перлом :)
>> а также некоторая необычность самой идеи яваскрипта на server-side
Jscript.NET существует как минимум с 2000 года, то есть уже девять лет, так что «необычной» эту идею назвать никак нельзя
msdn.microsoft.com/en-us/library/ms974588.aspx
Jscript.NET существует как минимум с 2000 года, то есть уже девять лет, так что «необычной» эту идею назвать никак нельзя
msdn.microsoft.com/en-us/library/ms974588.aspx
Javascript на сервере существует ещё раньше, как минимум с 1998 года — была такая штука — Netscape Server. Но это не очень важно, потому что широко Javascript никогда на сервере не применялся и не применяется в настоящий момент.
Кстати, погуглите v8cgi, г-н Велосипедист :)
А вот и не правы вы. Уже применяется, и даж фрейморк есть. Погуглите фреймворк racoon и сайт господина keeto.
На счет рассуждений о применении яваскрипта, полностю с вами согласен. Я уже писал коментарий в другом топике о том, что если wm (себто виртуальная машина, в которой выполняется код) реализована грамотно, то любой язык мона использовать как на сервере так и в клиенте. Лично меня привлекает огромная гибкость яваскрипта, а появление v8 дало мне надежду, что давняя моя, так сказать, мечта, о яваскрипте, наконец-то обретает облик реальности.
На счет рассуждений о применении яваскрипта, полностю с вами согласен. Я уже писал коментарий в другом топике о том, что если wm (себто виртуальная машина, в которой выполняется код) реализована грамотно, то любой язык мона использовать как на сервере так и в клиенте. Лично меня привлекает огромная гибкость яваскрипта, а появление v8 дало мне надежду, что давняя моя, так сказать, мечта, о яваскрипте, наконец-то обретает облик реальности.
ну тогда можно сказать, что широко применяться он так и не будет, даже в контексте появления темы этого топика
Не вижу прямой логической связи. В конце 1940х годов можно было сказать, что человек никогда не летал и не летает в космос. Но следовало ли бы из этого, что никогда и не полетит?..
Все старые решения, типа MS Jscript, Netscape Server страдали большим недостатком. Они были платными и довольно дорогими. А вот то, что в области server-side Javascript появляются новые решения не наводит ли вас на какие-то мысли?
Даже в Mozilla озаботились стандартизацией будущего серверного Javascript, собирая наработки в будущий черновик стандарта: https://wiki.mozilla.org/ServerJS. Конечно, это дело не ближайших двух-трёх лет, но в будущем…
Так что — может быть будет Javascript на серверах, может быть нет… Если бы использовался, это было бы любопытно — хорошо когда есть много разных технологий, и есть из чего выбирать. :)
Все старые решения, типа MS Jscript, Netscape Server страдали большим недостатком. Они были платными и довольно дорогими. А вот то, что в области server-side Javascript появляются новые решения не наводит ли вас на какие-то мысли?
Даже в Mozilla озаботились стандартизацией будущего серверного Javascript, собирая наработки в будущий черновик стандарта: https://wiki.mozilla.org/ServerJS. Конечно, это дело не ближайших двух-трёх лет, но в будущем…
Так что — может быть будет Javascript на серверах, может быть нет… Если бы использовался, это было бы любопытно — хорошо когда есть много разных технологий, и есть из чего выбирать. :)
Радует, что и встроенный perl необязателен :-)
По-моему, хорошо, когда каждый элемент системы занимается своим делом. nginx хорошо отрабатывает относительно простые вещи, для всего остального есть как минимум FastCGI.
По-моему, хорошо, когда каждый элемент системы занимается своим делом. nginx хорошо отрабатывает относительно простые вещи, для всего остального есть как минимум FastCGI.
jaxer?
не спешите вы Perl хоронить…
Да я, собственно, и не спешу — я сам программист на Perl с довольно большим стажем. На пессимистичные мысли в отношении будущего Perl меня наводит то, как он развивался последние 10 лет. И даже то, что происходит сейчас (выпуск 5.10.0, 5.10.1), может лишь отсрочить агонию. Конечно, полностью ( как люди ) языки умирают редко, но несколько сотен человек по всему миру, поддерживающие легаси-приложения погоды уже не сделают.
Вообще-то параллельно с веткой 5.10 разрабатывается совершенно новый Perl 6, идеи у него местами очень революционные, а местами просто заимствуют хорошие идеи у других языков. «Легаси-приложения», их доля занимает очень серьёзное место в мире, постоянно совершенствуються модули Perl.
Сейчас внедряется новая очень удобная и логичная модель ООП. Прогресс полным ходом у Perl идут вобщем.
А нормальных разработчиков для языков программирования обычно не больше десятка, так что сотни Perl'а, это очень хорошо.
Я сижу у них в IRC, каждый день выходят и модифицируются 10ки модулей, и причём нововведений море. Perl и его коммьюнити — удивительные люди с удивительными решениями
Сейчас внедряется новая очень удобная и логичная модель ООП. Прогресс полным ходом у Perl идут вобщем.
А нормальных разработчиков для языков программирования обычно не больше десятка, так что сотни Perl'а, это очень хорошо.
Я сижу у них в IRC, каждый день выходят и модифицируются 10ки модулей, и причём нововведений море. Perl и его коммьюнити — удивительные люди с удивительными решениями
Perl 6 я, извините, Perl-ом считать отказываюсь. Даже Python и Ruby имеют с Perl 5 больше общего, чем Perl 6. А вот новая объектная модель (если вы имеете в виду Moose) — это да, это конечно здорово… было бы, если бы оно не так сильно тормозило и не жрало столько памяти.
Впрочем, посмотрим. Я буду искрене рад, если Perl продолжит активно развиваться и совершенствоваться. Допилят интерпретатор, оптимизируют под Moose, чтобы оно не стартовало по 5-10 секунд… :) Может даже VM прикрутят, да тот же Parrot. И станет всем хорошо. :)
Впрочем, посмотрим. Я буду искрене рад, если Perl продолжит активно развиваться и совершенствоваться. Допилят интерпретатор, оптимизируют под Moose, чтобы оно не стартовало по 5-10 секунд… :) Может даже VM прикрутят, да тот же Parrot. И станет всем хорошо. :)
Ну вообще-то Ruby и впрямь имеет много общего с Perl ибо он от него произошёл =)
Moose, я про неё говорил, очень шустро развивается и оптимизируется, я думаю в ближайшее время статью бенчмарк накрапать на эту тему (прежде всего самому интересно). Кстати, 5-10 секунд НЕ СТАРТУЕТ у меня core 2 duo 6850… на нём вообще меньше секунды.
Parrot уже работает, Rakudo тоже очень бурно развивается.
Perl 6 — не смотря ни на что на Perl 5 очень похож и отрицания не вызывает.
Moose, я про неё говорил, очень шустро развивается и оптимизируется, я думаю в ближайшее время статью бенчмарк накрапать на эту тему (прежде всего самому интересно). Кстати, 5-10 секунд НЕ СТАРТУЕТ у меня core 2 duo 6850… на нём вообще меньше секунды.
Parrot уже работает, Rakudo тоже очень бурно развивается.
Perl 6 — не смотря ни на что на Perl 5 очень похож и отрицания не вызывает.
5-10 секунд он не стартует, только потому что у вас, видимо, иерархия объектов не очень большая и сложная. Просто написание use Moose уже увеличивает время запуска почти до секунды (0.6-0.8.). А с большой и… творческой системой объектов, у меня он стартует секунды за две-три на 4-ядерном проце с 8 гектарами. У коллег, которые Moose используют ещё активнее, вроде барьер в 5 секунд уже пройден.
А насчёт Perl6 у меня есть много отдельных, и не очень печатных слов… Тамошние регекспы меня когда-то сломили. :(
А насчёт Perl6 у меня есть много отдельных, и не очень печатных слов… Тамошние регекспы меня когда-то сломили. :(
Добавлю: под рукой есть Devel::REPL (это шелл для Perl навороченный, активно использующий Moose), это он у меня запускался с задержкой чуть меньше секунды, с последней версией Moose вообще мгновенно стартует
Я считаю что язык на котором возможно описать новую модель ООП, причём для самого себя, способен на на всё что угодно, уже одно это вызывает уважение. Производительность Moose конечно же хуже чем родная ООП, но:
1. как я понимаю он написан на pure Perl, т.е. без сишных вставок, думаю в скором времени это поправят
2. хуже уже не в разы, а на некоторое количество процентов
3. удобство и красота модели просто поражают
Про Perl 6, мне лично изменения в регэкспах нравятся, теперь с помощью них в декларативном стиле можно целые языки описывать и не только. Правда от классической модели они прилично отошли, что будет крайне непривычным поначалу.
Я считаю что язык на котором возможно описать новую модель ООП, причём для самого себя, способен на на всё что угодно, уже одно это вызывает уважение. Производительность Moose конечно же хуже чем родная ООП, но:
1. как я понимаю он написан на pure Perl, т.е. без сишных вставок, думаю в скором времени это поправят
2. хуже уже не в разы, а на некоторое количество процентов
3. удобство и красота модели просто поражают
Про Perl 6, мне лично изменения в регэкспах нравятся, теперь с помощью них в декларативном стиле можно целые языки описывать и не только. Правда от классической модели они прилично отошли, что будет крайне непривычным поначалу.
UFO just landed and posted this here
UFO just landed and posted this here
Идея конечно интересная, но если пофиксить интерфейс XMLHTTPRequest на HTTPD будет лучше
Во-первых, вы сильно ошибаетесь — серверная сторона для JS — далеко не новость. Есть POW (plain old webserver), который каждый может интегрировать в Fx — есть соответствующий плагин; есть и решения от Microsoft — в ASP Server-Side Jscript.NET выполняется на стороне сервера. Да и вообще, читайте литературу: впервые Javascript появился на сервере сразу после того, как он вообще появился на свет — в веб-сервере Netscape Enterprise 2.0 в 1996 году.
Во-вторых, Nginx — действительно не то решение, которое бы сделало SSJS широко используемым.
Во-вторых, Nginx — действительно не то решение, которое бы сделало SSJS широко используемым.
необычность самой идеи яваскрипта на server-side.
почему же необычна? mod_js для апача давно существует: www.modjs.org
— V8, предположительно, намного быстрее, чем уже существующий интегрированный Perl;
Все предположения в топку — только тесты покажут, кто прав.
И это не шутка. Многие гуру говорят против «оптимизации ради оптимизации», требуя только реального, подтвержденного результата.
Все предположения в топку — только тесты покажут, кто прав.
И это не шутка. Многие гуру говорят против «оптимизации ради оптимизации», требуя только реального, подтвержденного результата.
во-первых я всецело считаю что javascript вполне заслуженно занимает место «скриптовый язык для web», ибо есть куча наработок под него и очень удачных, но не более того:
присоединяюсь к Ogra к вопросу о производительности, добавлю только:
1. у javascript нету многопоточности, вообще (насколько я в курсе) и не предвещается, т.е. в век где уже corei7 по 8 процессоров позволяет нагружать, это не очень серьёзно
2. очень медленно работает ООП
3. медленно работает с массивами особенно с многомерными
теперь по остальным вопросам
По поводу асинхронности, в Perl есть!!! некоторое количество!!! (не один), для организации асинхронности, которые могу поспорить работают быстрее и настраиваються и кодятся намного проще и естественнее чем, если похожий функционал городить в javascript
По поводу XMLHTTPRequest это жирнейшая прослойка, которая хороша в плане унификации для web и несостоятелна для всего остального
По поводу современности и стандартизации:
в javascript нету ничего чего бы нельзя было воплотить на Perl,
а вот в Perl куча вещей которые javascript будут неподвластны всегда =) (ибо иначе он превратиться в Perl)
а теперь главное:
1. отсутствие в javascript strict синтаксиса делают его плохим языком для более менее приличных и мощее приложений
2. невысокая производительность + ограничение по интерфейсам с внешними программами вообще не очень хорошо
3. сложное ООП (не надо только шашкой махать и кричат что оно лучьше всех, я знаю некоторое количество людей которые зарабатывают деньги программируя на javascript (не на нём одном конечно), так вот дай боже есть один из них более-менее понимающий что и как там делать)
4. опять же у него нету ничего для задач не связанных с манипулированием DOM =) т.е. придётся написать ТУЧУ «велосипедов» и учитывая что опыта и наработок в этой области нету в основном они будут ужасного качества
присоединяюсь к Ogra к вопросу о производительности, добавлю только:
1. у javascript нету многопоточности, вообще (насколько я в курсе) и не предвещается, т.е. в век где уже corei7 по 8 процессоров позволяет нагружать, это не очень серьёзно
2. очень медленно работает ООП
3. медленно работает с массивами особенно с многомерными
теперь по остальным вопросам
По поводу асинхронности, в Perl есть!!! некоторое количество!!! (не один), для организации асинхронности, которые могу поспорить работают быстрее и настраиваються и кодятся намного проще и естественнее чем, если похожий функционал городить в javascript
По поводу XMLHTTPRequest это жирнейшая прослойка, которая хороша в плане унификации для web и несостоятелна для всего остального
По поводу современности и стандартизации:
в javascript нету ничего чего бы нельзя было воплотить на Perl,
а вот в Perl куча вещей которые javascript будут неподвластны всегда =) (ибо иначе он превратиться в Perl)
а теперь главное:
1. отсутствие в javascript strict синтаксиса делают его плохим языком для более менее приличных и мощее приложений
2. невысокая производительность + ограничение по интерфейсам с внешними программами вообще не очень хорошо
3. сложное ООП (не надо только шашкой махать и кричат что оно лучьше всех, я знаю некоторое количество людей которые зарабатывают деньги программируя на javascript (не на нём одном конечно), так вот дай боже есть один из них более-менее понимающий что и как там делать)
4. опять же у него нету ничего для задач не связанных с манипулированием DOM =) т.е. придётся написать ТУЧУ «велосипедов» и учитывая что опыта и наработок в этой области нету в основном они будут ужасного качества
далее:
у Perl есть модули и наработки на все случаи жизни накопившиеся за 20 лет
для него легко писать дополнения на C/C++
И опять же есть Jaxer, который чудес не показал (хотя идея интересная =) )
Так что я думаю что ребята впустую тратят время, вместо того чтобы изобретать «велосипеды», лучше бы что-нибудь полезное сделали
И ещё, Nginx очень хорошо себя зарекомендовал как легковесный web-сервер, чем больше его накачивают дополнительным функционалом (который есть у других продуктов), тем медленнее и сложнее он становиться. Так что лучше развивать то, что действительно стоит усилий, а не подготавливать платформу для «велосипедов» имеющую достаточно мощных конкурентов.
у Perl есть модули и наработки на все случаи жизни накопившиеся за 20 лет
для него легко писать дополнения на C/C++
И опять же есть Jaxer, который чудес не показал (хотя идея интересная =) )
Так что я думаю что ребята впустую тратят время, вместо того чтобы изобретать «велосипеды», лучше бы что-нибудь полезное сделали
И ещё, Nginx очень хорошо себя зарекомендовал как легковесный web-сервер, чем больше его накачивают дополнительным функционалом (который есть у других продуктов), тем медленнее и сложнее он становиться. Так что лучше развивать то, что действительно стоит усилий, а не подготавливать платформу для «велосипедов» имеющую достаточно мощных конкурентов.
Писал на скорую руку, потому есть много недочётов, просьба — за это сильно ногами не пинать.
Окей, не могу не согласиться с вашими доводами. А насчёт производительности — надо подумать, как можно было бы сравнить Perl и V8. Может быть подобрать какой-то набор полу-математических тестов, которые можно будет относительно быстро реализовать и на Perl и на JS.
напишите многопоточный краулер dmoz или yaca — и тестируйте сколько влезет… а да забыл ведь в я скрипте нет поддержки многопоточности :)
ИМХО если яваскрипт и станет популярным (хотябы как питон или перл сейчас) языком для серверных решений — то произойдет это явно не в ближайшие 20-30 лет
ИМХО если яваскрипт и станет популярным (хотябы как питон или перл сейчас) языком для серверных решений — то произойдет это явно не в ближайшие 20-30 лет
UFO just landed and posted this here
во-первых тут про serverside JS говорят
во-вторых chrome работает в несколько процессов, а вот ваш код на JS? нет, речь об этом шла. И ни о каком IPC речи даже нет (насколько я в курсе)
про гирс я не в курсе, если кто пользовался пусть пишут
во-вторых chrome работает в несколько процессов, а вот ваш код на JS? нет, речь об этом шла. И ни о каком IPC речи даже нет (насколько я в курсе)
про гирс я не в курсе, если кто пользовался пусть пишут
UFO just landed and posted this here
большинство кода на перле (и не только) работает в один поток, большинство многопоточности это ничего иное как разделенные процессы которые синхронизируются через интерфейсы
В императивных языках большинство кода работает в один поток ибо так эффективнее. Речь идёт о том, что в JS это невозможно и ничего для этого нет, а в Perl это уже давно реализовано. И пока в JS поддержки многопоточности нету опять же речи о производительности выше чем у Perl быть не может для многих задач.
для того чтобы обновить js-V8 на сервере не надо ждать годы как это на происходит клиенте.
не понял к чему это
но вот даже с инертностью клиентских платформ js развивается намного быстрее чем перл. в js есть конкуренция между реализациями, есть ли такое в перле? 20 лет на одном месте топчется. кое как появилось utf8 но зато есть «многопоточность».
Немного необоснованное утверждение. Последние изменения в языке были в 2005, 2006 и 2008 году, остальные улучшения выходят не чаще чем раз в полгода и направлены на увеличение производительности, которая не сильно удовлетворительная и на данный момент. В Perl разработчики разделились на 2 фронта, одни разрабатывают совершенно новый Perl 6, причём очень бодрыми темпами, другие допиливают Perl 5. И наряду с этим постоянно (ежедневно, я выше писал) обновляются и пишуться новые и старые модули для обоих языков.
кстати в v8 нету ООП как таковой, это так погреть вам душу. но в перле ее вроде тоже нет )
Душу мне это НЕ ГРЕЕТ, ибо я не против JS, а против изобретений «велосипедов» в областях где их и так уже предостаточно.
У Perl ООП лет 7 уже как есть точно, и сейчас как я написал выше разрабатывается новая модель очень интересная и стройная.
javascript strict — раньше необходимости в этом небыло но сейчас уже есть задачи где это нужно. некоторые пытаются прикрутить питон на клиент, но скорее всего это будет реализовано в js.
Чтобы претендовать на server-side язык, обязательно должно быть, да и просто не повредит
Просто вместо того чтобы развивать сильные стороны различных технологий и языков многие люди делают невероятное количество бесполезной работы (как в этом случае например (JS server-side)) и в результате получится, что новая волна таких же энтузиастов в будующем увидев каким сложным и медленным станет JS изза этих нововведений. Будут продвигать какой нибудь новый легковесный молодой язык. Вместо этого я думаю лучьше закреплять то что есть: оптимизировать фреймворки, улучшать производительность языков, на базе их придумывать что-то новое (как например Moose в Perl, или мощный и удобный ExtJS в JS), а не делать «мартышкин труд» изобретая «новый» server-side язык.
В императивных языках большинство кода работает в один поток ибо так эффективнее. Речь идёт о том, что в JS это невозможно и ничего для этого нет, а в Perl это уже давно реализовано. И пока в JS поддержки многопоточности нету опять же речи о производительности выше чем у Perl быть не может для многих задач.
для того чтобы обновить js-V8 на сервере не надо ждать годы как это на происходит клиенте.
не понял к чему это
но вот даже с инертностью клиентских платформ js развивается намного быстрее чем перл. в js есть конкуренция между реализациями, есть ли такое в перле? 20 лет на одном месте топчется. кое как появилось utf8 но зато есть «многопоточность».
Немного необоснованное утверждение. Последние изменения в языке были в 2005, 2006 и 2008 году, остальные улучшения выходят не чаще чем раз в полгода и направлены на увеличение производительности, которая не сильно удовлетворительная и на данный момент. В Perl разработчики разделились на 2 фронта, одни разрабатывают совершенно новый Perl 6, причём очень бодрыми темпами, другие допиливают Perl 5. И наряду с этим постоянно (ежедневно, я выше писал) обновляются и пишуться новые и старые модули для обоих языков.
кстати в v8 нету ООП как таковой, это так погреть вам душу. но в перле ее вроде тоже нет )
Душу мне это НЕ ГРЕЕТ, ибо я не против JS, а против изобретений «велосипедов» в областях где их и так уже предостаточно.
У Perl ООП лет 7 уже как есть точно, и сейчас как я написал выше разрабатывается новая модель очень интересная и стройная.
javascript strict — раньше необходимости в этом небыло но сейчас уже есть задачи где это нужно. некоторые пытаются прикрутить питон на клиент, но скорее всего это будет реализовано в js.
Чтобы претендовать на server-side язык, обязательно должно быть, да и просто не повредит
Просто вместо того чтобы развивать сильные стороны различных технологий и языков многие люди делают невероятное количество бесполезной работы (как в этом случае например (JS server-side)) и в результате получится, что новая волна таких же энтузиастов в будующем увидев каким сложным и медленным станет JS изза этих нововведений. Будут продвигать какой нибудь новый легковесный молодой язык. Вместо этого я думаю лучьше закреплять то что есть: оптимизировать фреймворки, улучшать производительность языков, на базе их придумывать что-то новое (как например Moose в Perl, или мощный и удобный ExtJS в JS), а не делать «мартышкин труд» изобретая «новый» server-side язык.
Немного необоснованное утверждение. Последние изменения в языке были в 2005, 2006 и 2008 году, остальные улучшения выходят не чаще чем раз в полгода и направлены на увеличение производительности, которая не сильно удовлетворительная и на данный момент.
Это я про Javascript писал, если что
Это я про Javascript писал, если что
UFO just landed and posted this here
Sign up to leave a comment.
ngxv8