Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 143
Эмм… Java апплеты — не то?
Нет. Тут идея вместо JS — языка, в браузерах использовать более низкий уровень — CLI.
На базе CLI можно любой язык исполнять, не только JS, но и C#, F#, Delphi, Python, Ruby.
На базе CLI можно любой язык исполнять, не только JS, но и C#, F#, Delphi, Python, Ruby.
Java Apllet != Java script. На сколько я помню, существует достаточно много апплетов, реализующих веб-приложения. Для них существуют политики безопасности, подпись сертификатами и т.п. Естественно, нужен JRE на компе пользователя, нет такой гибкости, как хочется, но они есть.
Приплыли. Теперь говно код html-страниц будет не только на JS, а ещё на куче не знакомых мне языках
Ага. Возникает вопрос по поводу безопасности и кроссплатформенности.
Что ты курил, Джо?
Что ты курил, Джо?
Кстати, да, потому что сама возможность написать <script language="cil" source="MailApp.dll" /> являет собою мгновенный амбец всей безопасности.
ECMA CLI — кроссплатформенный стандарт, реализация которого есть для всех популярных платформ.
Модель безопасности обкатана на Silverlight/Moonlight.
Соответственно, с этим как раз таки проблем нет.
Модель безопасности обкатана на Silverlight/Moonlight.
Соответственно, с этим как раз таки проблем нет.
Мощный язык для клиента вместо этого ужасного JS… Звучит заманчиво. Может это преддверие революции браузеров и развития Rich Web Applications?! На первый взгляд — действительно здорово… Сделать бы MONO для мобильных платформ и идея кроссплатформенности решилась бы сама собой.
С первого взгляда понравилось, а потом так и представил, как приходит клиент у которого часть скриптов на csharp, часть на С++, Ruby и т.д и т.п.
ИМХО уж лучше пусть будет как есть. А то начнется такая каша, что потом сами рады не будем.
ИМХО уж лучше пусть будет как есть. А то начнется такая каша, что потом сами рады не будем.
Веревка достаточной длины, чтобы выстрелить себе в ногу?
Вообще-то нормальные программисты не пишут код на десяти языках одновременно, хотя это и возможно. Чем тут браузер отличается от обычного софта? С приходом .NET проект может быть легко написан на десятке различных языков. Но это, почему-то никого не пугает.
Тем более, что можно использовать сборки. А сайты визитки, написанные Васей Пупкиным, где и сейчас фотогалерея берет плагины prototype, голосовалки jquery и т.д. сильно не пострадают
Давайте я вам раскажу ситуацию которую я представил:
Есть проект поддержкой которого уже занимались множество программистов. И каждый считает что язык предыдущего ужасный. И пищет свою часть функционала на своем любимом языке.
Сейчас, когда комне приходит клиент, мне нужно только узнать на чем был написан его сайт. А все остально стандартно HTML, CSS, JS. И без разницы prototype, JQuety или MooTools это все равно JS. Без разницы Drupal, Bitrix, WordPress это все равно PHP.
Есть проект поддержкой которого уже занимались множество программистов. И каждый считает что язык предыдущего ужасный. И пищет свою часть функционала на своем любимом языке.
Сейчас, когда комне приходит клиент, мне нужно только узнать на чем был написан его сайт. А все остально стандартно HTML, CSS, JS. И без разницы prototype, JQuety или MooTools это все равно JS. Без разницы Drupal, Bitrix, WordPress это все равно PHP.
По моему мнению программисты пишут на том что идеально подходит для поставленной задачи (по их мнению), в любом случае я к этому стремлюсь. Поэтому, почему мне скажем не использовать для доказательства теорем скажем Prolog, если CIL позволяет. Ну а там где мне нужна производительность C++, почему нет? Стабильность и безопасность почему бы Java не воспользоваться, в общем ничего плохого в этом не вижу.
Да, в общем-то никто не видит. Если только это не означает, что части одного и того же проекта будут написаны на множестве различных языков без особых на то причин (я, конечно, не имею ввиду HTML, XML, Javascript и Flash в одном флаконе, поскольку это смежные языки одной области). Если в вашем проекте будет одна часть на IronPython, другая на C++, третья на C#, а четвертая на Lua… Нет, это, конечно, прекрасно и все просто обзавидуются вашему кругозору, но… Кто потом этот проект будет поддерживать с такой гремучей смесью языков?
Я Вас прекрасно понимаю. Вопрос ведь в качестве кода, никому не захочется поддерживать проект в котором замешанно в адской смеси множество языков. Но если код строгий, не противоречивый, системный. Когда в системе есть строгие зоны ответственности языков программирования (на C++ не пишутся костыли к Java и наоборот), тогда и разобраться в ней не так уж сложно. В любом случае, это себе может позволить только очень мощная компания, со штатом прекрасных специалистов, меня туда не возьмут :)
Останется только один!
(Хайландер)
:)
(Хайландер)
:)
готовить его научитесь.
Хм. Очень и очень интересная идея.
Если встроят в IE9 и, к примеру, Firefox — остальные браузеры никуда не денутся.
Если встроят в IE9 и, к примеру, Firefox — остальные браузеры никуда не денутся.
Ну, ActiveX встроили как-то, «остальные браузеры» не оценили…
Проблема ActiveX все же в том что это платформо-зависимый код. В случае же с CLR — это абсолютно переносимый код. Конечно же в нем будут запрещены managed сборки и т.п.
Опять же, возможность использовать куски кода на C#/IronPython/name it — огромный плюс по сравнению с ActiveX.
Ну и не забываем про быстрый кросплатформенный JIT для CLR реализованый для всех популярных платформ (Win/MacOS/Linux).
Опять же, возможность использовать куски кода на C#/IronPython/name it — огромный плюс по сравнению с ActiveX.
Ну и не забываем про быстрый кросплатформенный JIT для CLR реализованый для всех популярных платформ (Win/MacOS/Linux).
Запрещены… managed сборки? Наверное, вы хотели сказать «unmanaged»?
И куда я засуну MailApp.dll, скажем в netBSD?
Нет, ну вот даже я знаю, что .dll в данном случае, это аналог .jar для жабы. То есть гольный байткод.
и? Одним байткодом сыт не будешь, нужен ещё интерпретатор, библиотеки etc. Или это встраивать в браузер нужно, а тут я вижу такие же холивары ogv vs h264, либо опираться на сторонние плагины, что автоматически означает проблемы при переноске между системами.
.Net runtime — это ISO стандарт. И есть как минимум 1 открытая кросплатформенная реализация — Mono.
Ну я тоже не сторонник этой идеи. Впрочем, горевать тут нечего — само сдохнет.
напомнило Google с его Native Client
А как у Native Client дела с портабельностью?
Уж получше чем у MONO. Там GCC и поддержка LLVM постепенно доростает. А MONO досихпор то там, то тут…
Думаю у MONO будет лучше, потому как NativeClient пока только у Google, а MONO может быть на куда большем числе браузеров.
Ага у гугла ПОКА, а МОНО МОЖЕТ. Тоесть нету его. Гестальт у меня например вообще не работает.
Тем более, что НативКлиент легко svn checkout nativeclient.googlecode.com/svn/trunk/src И кода там не миллион строк.
А учитывая, что Моно не 100% .NET совместим получается сплошное ПОЧТИ и МОЖЕТ.
Тем более, что НативКлиент легко svn checkout nativeclient.googlecode.com/svn/trunk/src И кода там не миллион строк.
А учитывая, что Моно не 100% .NET совместим получается сплошное ПОЧТИ и МОЖЕТ.
У Mono есть Moonlight. Он УЖЕ может.
А совместимость есть, вы что-то путаете. Может не с последней версией (не следил), но с предпоследней — какая разница? Необязательно же в браузерах встраивать все самое последнее.
Да и причем здесь .NET, когда речь идет только о CLI (и, возможно, Silverlight) — это все же не .NET в полном смысле (с рантаймом и прочим).
Развивая идею — можно вообще отдельный рантайм делать для веба (просто зачем, если уже есть наработки?).
А совместимость есть, вы что-то путаете. Может не с последней версией (не следил), но с предпоследней — какая разница? Необязательно же в браузерах встраивать все самое последнее.
Да и причем здесь .NET, когда речь идет только о CLI (и, возможно, Silverlight) — это все же не .NET в полном смысле (с рантаймом и прочим).
Развивая идею — можно вообще отдельный рантайм делать для веба (просто зачем, если уже есть наработки?).
Сильверлайт и его потомок Мунлайт не для WEB, а для Интранет. Мне это тут подробно объяснили уже. А Мигель хочет CLI Везде. В том числе и в Simbian и в Windows Mobile, и iPhone.
От апплета или от Flash это вообще ничем не отличается. Например в флэш компилируют C.
А зачем и наработки, я отвечу. Если у человека в руках молоток, то всё вокруг ГВОЗДИ. Мигель трудится над МОНО. Я лчино считаю, что он каштаны таскает из огня, но тут даже не во мне дело. Мигель кроме МОНО просто ничего не видит. Есть Мунлайт он требует установку плагина. Логично, что если PLUG-IN приклеить суперклеем к браузеру, то он уже не PLUG?
Тоесть взяли и прибили гвоздями CLI. Рантайм, да отдельный можно, но цитируя вас «просто зачем, если уже есть наработки?»
Поэтому америки он не открыл и пока у него МОНО будет ежать за .NET я даже не посмотрю на него и не советую другим. FoxPro, Visual Basic пользователи уже играли в эту игру одновендорных решений
От апплета или от Flash это вообще ничем не отличается. Например в флэш компилируют C.
А зачем и наработки, я отвечу. Если у человека в руках молоток, то всё вокруг ГВОЗДИ. Мигель трудится над МОНО. Я лчино считаю, что он каштаны таскает из огня, но тут даже не во мне дело. Мигель кроме МОНО просто ничего не видит. Есть Мунлайт он требует установку плагина. Логично, что если PLUG-IN приклеить суперклеем к браузеру, то он уже не PLUG?
Тоесть взяли и прибили гвоздями CLI. Рантайм, да отдельный можно, но цитируя вас «просто зачем, если уже есть наработки?»
Поэтому америки он не открыл и пока у него МОНО будет ежать за .NET я даже не посмотрю на него и не советую другим. FoxPro, Visual Basic пользователи уже играли в эту игру одновендорных решений
В статье сказано зачем.
Но если поддержка CLI (или любого другого байткода) будет «из коробки», то это придаст вебу скорость (мне на рюшечки наплевать).
Т.е. на клиенте можно будет выполнять код эффективней (=быстрее, энергоэффективней).
Хотя соглашусь, что Мигелю, скорее всего, просто надоело под каждый браузер/платформу все подгонять :)
И еще, интеграция в браузер, вполне возможно, принесет 3D в веб быстрее, нежели просто через плагины (отчего-то с этим проблемы и у Flash и у Silverlight).
Но если поддержка CLI (или любого другого байткода) будет «из коробки», то это придаст вебу скорость (мне на рюшечки наплевать).
Т.е. на клиенте можно будет выполнять код эффективней (=быстрее, энергоэффективней).
Хотя соглашусь, что Мигелю, скорее всего, просто надоело под каждый браузер/платформу все подгонять :)
И еще, интеграция в браузер, вполне возможно, принесет 3D в веб быстрее, нежели просто через плагины (отчего-то с этим проблемы и у Flash и у Silverlight).
Кстати Джоел Спольски написал уже, что ждем компилятор Руби и Пайтона в JS. У пайтона уже есть пижама. У Руби не в курсе. Вот такой своеобразный CLI
более того, я как раз хотел написать что это -фигня, посравнению с Native Client. Кароче я жду развития NC.
Расскажите мигелю про native client.
Идея стоящая, но требует проработки. На мой взгляд, запускать скомпилированные exe и dll из интернета — это как-то… ломает шаблон что ли)
вот вот, это как пустить козла в огород, в смысле бинарный код в твой веб-браузер
Это уже сейчас происходит во многих браузерах, когда JIT генерит машинный код из Javascript.
Идея Джо в том, что транспортом кода нужно сделать не JS, с его противоречивым наследием, а уровень байт-кода (CIL). С возможностью трансформации (читай компиляции) любых языков в этот самый байт-код (CIL) в том числе на клиенте.
Идея Джо в том, что транспортом кода нужно сделать не JS, с его противоречивым наследием, а уровень байт-кода (CIL). С возможностью трансформации (читай компиляции) любых языков в этот самый байт-код (CIL) в том числе на клиенте.
Не вижу смысла. Завязываться на CLI в текущей реализации Mono… Ну это как-то не очень. И в плане UI всё как-то тоже не радужно. GTK#, ORLY? И как это будет выглядеть в браузере? Да и зоопарк языков ни к чему.
А с чего Джо решил, что javascript ужасен, а ECMAscript недостаточно гибок?
Основные аргументы, на мой взгляд--это 1. стандартизированные библиотеки, которых в JS нет (а аналогов или нет или они менее надежные) и 2. возможность писать на разных языках--кому какой удобней. Ну и статическая типизация для желающих (вот мне она очень нравится:-).
3. Возможность идентичной работы в разных браузерах/платформах.
Правда с мобильными платформами могут возникнуть сложности… С текущей политикой Apple CLI не появится на iPhone.
Правда с мобильными платформами могут возникнуть сложности… С текущей политикой Apple CLI не появится на iPhone.
JS разве не дает такой возможности? О_о
Мне показалось, что даже Apple со всеми ее запретами дала зеленый свет связке «html+css+js» или я не прав?
Мне показалось, что даже Apple со всеми ее запретами дала зеленый свет связке «html+css+js» или я не прав?
Связка «html+css+js» не дает такой возможности.
Какая платформа не дает связке такой возможности?
Вы не понимаете. Связка работает. Но на разных платформах — по разному.
Кажется да, я не понимаю. О каком различии идет речь?
Различие в том, что большинство современных JS-фреймворков содержат специальные изменения для каждого браузера (в тех случаях, когда они требуются). Сейчас разница из-за этого и не заметна пользователю. Но вот с новым HTML5 все сложнее и на каждом браузере страницы (использующие HTML5) отличаются (не всегда фатально, но бывает). Со временем многие вещи утрясутся, но различия всеравно останутся.
С CLI же ситуация иная, если он будет OpenSource (а иначе и не имеет смысла), то, скорее всего, браузеры будут использовать одну и ту же версию фреймворка (виртуальная машина, в принципе, может отличаться), и тогда не будет головной боли у разработчиков.
С CLI же ситуация иная, если он будет OpenSource (а иначе и не имеет смысла), то, скорее всего, браузеры будут использовать одну и ту же версию фреймворка (виртуальная машина, в принципе, может отличаться), и тогда не будет головной боли у разработчиков.
Но это в теории: «в теории нет различия между практикой и теорией, на практике же различия есть».
Ну и CLI это не замена JS. Да и браузеры телефонов (не смартфонов) вряд ли смогут «переварить» CLI в любом виде (они и с JS испытывают проблемы).
Ну и CLI это не замена JS. Да и браузеры телефонов (не смартфонов) вряд ли смогут «переварить» CLI в любом виде (они и с JS испытывают проблемы).
По-моему эти различия абсолютно нормальны и самое главное неизбежны.
А js-фреймворки вполне неплохо справляются с новым уровнем абстракции.
Другое дело, что если CLI будет OpenSource, то одной версией дело точно не ограничится.
А дальше если CLI будет использоваться, то для любых операций потребуется доступ к dom и все идет по новой — фреймворки, доступ к дереву и т.д.
А js-фреймворки вполне неплохо справляются с новым уровнем абстракции.
Другое дело, что если CLI будет OpenSource, то одной версией дело точно не ограничится.
А дальше если CLI будет использоваться, то для любых операций потребуется доступ к dom и все идет по новой — фреймворки, доступ к дереву и т.д.
1. Не совсем понял что имеется ввиду под «стандартизированными библиотеками».
2. Возможность писать на разных языках клиент лично мне видится не самой лучшей идеей. Текущий зоопарк(JS, Flash, Silverlight, Java) уже превращает браузер в черт знает что, а дальше больше (Native, Unity).
3. Да, типизация это замечательно. И писать js с типизацией давно уже можно. Смотрим в сторону GWT и Haxe.
2. Возможность писать на разных языках клиент лично мне видится не самой лучшей идеей. Текущий зоопарк(JS, Flash, Silverlight, Java) уже превращает браузер в черт знает что, а дальше больше (Native, Unity).
3. Да, типизация это замечательно. И писать js с типизацией давно уже можно. Смотрим в сторону GWT и Haxe.
По поводу третьего пункта вы не правы. Писать со статической типизацией на JS нельзя. На Haxe и GWT можно, а на JS нельзя. Haxe и GWT переводят свой код в JS, в котором теряется вся статическая типизация.
Статическая типизация важна не сама по себе, а как один из путей к более быстрой работе веб-приложений на клиенте. Если язык не поддерживает ее (как JS), то он всегда будет медленнее того, который поддерживает, вот и получается, что пишем в GWT и Haxe на языках, которые могут выполняться быстрее, но они переводятся в JS и вся производительность исходит на нет.
Ну а быстрее эти языки, потому что приведения типов происходят один раз на этапе компиляции, а не каждый раз при исполнении. (Это, кстати, одна из причин, почему JS не угнаться за Flash).
Статическая типизация важна не сама по себе, а как один из путей к более быстрой работе веб-приложений на клиенте. Если язык не поддерживает ее (как JS), то он всегда будет медленнее того, который поддерживает, вот и получается, что пишем в GWT и Haxe на языках, которые могут выполняться быстрее, но они переводятся в JS и вся производительность исходит на нет.
Ну а быстрее эти языки, потому что приведения типов происходят один раз на этапе компиляции, а не каждый раз при исполнении. (Это, кстати, одна из причин, почему JS не угнаться за Flash).
Да, в Вашем случае бонусы статической типизации языка исполнения — реализация jit в vm.
Но это же даже не основные бонусы.
Самое главное это типизация в языке описания — бонусы в разработке( особенно больших приложений, особенно в больших командах).
Что ни говори, а «Compile-time error» лучше «Runtime error».
Придумывать велосипеды в тестировании не требуется.
Помимо этого компиляторы GWT и Haxe имеют возможность оптимизровать код, но пока не злоупотребляют этим.
Далее, основная задача js в браузере это не столько работа с памятью, которую и оптимизирует jit, а манипуляция с dom браузера. Вот где собака зарыта.
Отсюда получается, что проект создания jit под js vm уместен в случае применения js за пределами браузера и есть вещи намного важнее jit'а(например gc).
В качестве иллюстрации можно привести node.js и v8.
Но это же даже не основные бонусы.
Самое главное это типизация в языке описания — бонусы в разработке( особенно больших приложений, особенно в больших командах).
Что ни говори, а «Compile-time error» лучше «Runtime error».
Придумывать велосипеды в тестировании не требуется.
Помимо этого компиляторы GWT и Haxe имеют возможность оптимизровать код, но пока не злоупотребляют этим.
Далее, основная задача js в браузере это не столько работа с памятью, которую и оптимизирует jit, а манипуляция с dom браузера. Вот где собака зарыта.
Отсюда получается, что проект создания jit под js vm уместен в случае применения js за пределами браузера и есть вещи намного важнее jit'а(например gc).
В качестве иллюстрации можно привести node.js и v8.
JIT не может избавиться от приведения типов в памяти. Он всеравно это будет делать, может где-то соптимизирует, но полностью «проблему» побороть не сможет.
Поэтому, как только дойдет дело до работы с массивом данных, JS будет резко просаживать производительность, потому что при обращении к каждому элементу придется приводить данные (не известно же — вдруг все элементы массива разных типов), это, правда, уже шаг в сторону Generics.
Поэтому, как только дойдет дело до работы с массивом данных, JS будет резко просаживать производительность, потому что при обращении к каждому элементу придется приводить данные (не известно же — вдруг все элементы массива разных типов), это, правда, уже шаг в сторону Generics.
Видимо он попробовал другие языки, перед тем как вынести такое умозаключение
Хмм… А может вместо CLI предложить JVM(JRE)? А что? Языков тоже тьма. Да и проблем с кроссплатформенностью нет. JRuby, JPython, Scala, Clojure, Groovy…
А не лучше бы просто в браузере сделать JIT для javascript? И быстрее, и особо велосипедов не нужно, и менять странички веберам не нужно.
И самое интересное, что хром и опера уже сделал, и в них javascript действительно летает…
*сделали
Тут речь идет о 10-кратном увеличении производительности, при условии использования строго типизированных языков типо C#
Нууу… Летает — это громко сказано.
Был на gamehaxe.com тест на сравнение производительности JS, Flash, C++.
Тест написан на Haxe и скомпилирован в выше приведенные языки.
Результаты для JS не впечатлили. Flash раза в два быстрее, C++ вообще недосягаем, Думаю C# был бы между Flash и C++.
Улучшить производительность JS с помощью JIT можно, но этому есть пределы, при этом JS никогда не сможет догнать C# в этом плане. Просто из-за различий языков, так же как C# будет медленее C++ (хотя здесь не всегда значительное отставание).
Был на gamehaxe.com тест на сравнение производительности JS, Flash, C++.
Тест написан на Haxe и скомпилирован в выше приведенные языки.
Результаты для JS не впечатлили. Flash раза в два быстрее, C++ вообще недосягаем, Думаю C# был бы между Flash и C++.
Улучшить производительность JS с помощью JIT можно, но этому есть пределы, при этом JS никогда не сможет догнать C# в этом плане. Просто из-за различий языков, так же как C# будет медленее C++ (хотя здесь не всегда значительное отставание).
Дело ведь не в скорости работы скриптов. А в скорости и удобстве разработи.
Вот оно. Раньше значит мы за скорость бились) Писали ассемблерские вставки в код и т.д.(я про былые года разработки на C/C++) А теперь пофиг как там быстро все выполняется, но зато я написал с использованием суперского синтаксического сахара новомодного языка.
Оптимизировать код по скорости работы нужно только тогда, когда это действительно необходимо. Мне все равно, сколько времени занимает отрисовка меню в приложении 5мс или 200мс, если для меня это практически незаметно. Мне также все равно, на C# или С++ написан графический редактор, если скорость его работы меня устраивает (это я про Paint.NET кстати). Если мне удобно использовать Nemerle или Haskel в работе — почему нет?
Вообще-то, CLI быстрее чем Javascript :-/
1. Javascript давно не ужасен. Если пользоваться библиотеками с верху, например prototype — он скорее прекрасен. И создан он идеально для работы с DOM.
2. В последнее время нет никаких проблем с производительностью. У меня даже wave не тормозит на chrome, а это куча js.
3. На интеграцию всего этого уйдет масса времени, а целевая аудитория — кто?
Кароче раздули, имхо. Я за native client от google.
2. В последнее время нет никаких проблем с производительностью. У меня даже wave не тормозит на chrome, а это куча js.
3. На интеграцию всего этого уйдет масса времени, а целевая аудитория — кто?
Кароче раздули, имхо. Я за native client от google.
А что там у нас с патентами на это дело? Не случится ли в один прекрасный день что-нибудь эдакое, что придется или бабло платить или выпиливать из браузера эту фичу?
НЕ ХОТЕТЬ
Это, к примеру, захожу на сайт, а оно мне какой-нибудь IronPython на 10 метров качает.
А потом еще Микрософт всех засудит за патенты и веб превратится в тыкву. Придется снова возвращаться на ftp, gopher и usenet.
Это, к примеру, захожу на сайт, а оно мне какой-нибудь IronPython на 10 метров качает.
А потом еще Микрософт всех засудит за патенты и веб превратится в тыкву. Придется снова возвращаться на ftp, gopher и usenet.
Причем тут IronPython для рантайма?
Кстати, от того, что оно сейчас Java, Flash, SilverLight и прочие плагины качает никто не умер вроде? Оно ведь спрашивает, хотите скачать или нет.
Кстати, от того, что оно сейчас Java, Flash, SilverLight и прочие плагины качает никто не умер вроде? Оно ведь спрашивает, хотите скачать или нет.
Рантайм того же Silverlight — это мегабайт (без системных библиотек). Компилятор IronPython-а думаю будет 500к весить.
Кроме того, можно наиболее популярные языки прямо с браузером поставлять
Кроме того, можно наиболее популярные языки прямо с браузером поставлять
Пока не дочитал до конца, до примечаний, так и не мог понять, причем тут Command Line Interface и браузер…
Мне думается, что в случае с Web лозунг типа «даешь языков хороших и разных» слегка не уместен. И дело не в том, что это «ломает шаблон».
Хорошие знания JS как и хорошие знания Java, как и хорошие знания PHP, Python, Ruby, С#, C++ и т.п. просто так не даются.
Кроме того, в нынешней ситуации есть некоторая ограниченость, надеюсь, многие понимают, что «ограниченость» это не всегда == плохо.
В той же степени в которой она «отнимает возможности», она добавляет желание «бороться и искать, найти и перепрятать» ( (с) — тиха украинская ночь, но сало нужно перепрятать).
Т.е. в итоге качество кода в «такой» «широкой» реализации может сильно пострадать. Конечно, оно сейчас страдает и в JS, когда «за дело» берется «неофит». И, да, понятно, что и «здесь» и «если случится», вроде как будет песочница. Но, скажите, что делать «специалисту» великолепно знающему один язык, когда web-приложение будет написано на другом?
Получается великолепная «замануха» для «разработчиков» и «недо-разработчиков», но полное «вечное доение» для клиентов.
Возможно, конечно, для многих эта «мечта» — панацея.
Но, как кто-то когда-то шутил — «мечтайте осторожней, иногда мечты сбываются».
Хотя идея, конечно — гуд, но может быть отчасти обусловлена тем что, как говорил известный Кролик — «это не узкие двери, это кто-то слишком много ел!»
Меня, например, просто «вымораживает» что те же самые «неофиты» Visual Studio разработчики «по умолчанию» избавлены от необходимости «кодить клиента», а представьте сколько «свободы» даст им «такой» подход!
Хорошие знания JS как и хорошие знания Java, как и хорошие знания PHP, Python, Ruby, С#, C++ и т.п. просто так не даются.
Кроме того, в нынешней ситуации есть некоторая ограниченость, надеюсь, многие понимают, что «ограниченость» это не всегда == плохо.
В той же степени в которой она «отнимает возможности», она добавляет желание «бороться и искать, найти и перепрятать» ( (с) — тиха украинская ночь, но сало нужно перепрятать).
Т.е. в итоге качество кода в «такой» «широкой» реализации может сильно пострадать. Конечно, оно сейчас страдает и в JS, когда «за дело» берется «неофит». И, да, понятно, что и «здесь» и «если случится», вроде как будет песочница. Но, скажите, что делать «специалисту» великолепно знающему один язык, когда web-приложение будет написано на другом?
Получается великолепная «замануха» для «разработчиков» и «недо-разработчиков», но полное «вечное доение» для клиентов.
Возможно, конечно, для многих эта «мечта» — панацея.
Но, как кто-то когда-то шутил — «мечтайте осторожней, иногда мечты сбываются».
Хотя идея, конечно — гуд, но может быть отчасти обусловлена тем что, как говорил известный Кролик — «это не узкие двери, это кто-то слишком много ел!»
Меня, например, просто «вымораживает» что те же самые «неофиты» Visual Studio разработчики «по умолчанию» избавлены от необходимости «кодить клиента», а представьте сколько «свободы» даст им «такой» подход!
Ага, идею понял.
Тоесть получается что каждый браузер с собой будет тащить кучу интерпретаторов, весом, скажем метров на 300+ только для того, что бы вместо JS можно было писать на Python/C++/C#/etc…
Нет, как концепт неплохо, но остается много непродуманных вопросов.
Тоесть получается что каждый браузер с собой будет тащить кучу интерпретаторов, весом, скажем метров на 300+ только для того, что бы вместо JS можно было писать на Python/C++/C#/etc…
Нет, как концепт неплохо, но остается много непродуманных вопросов.
.Net runtime весит 20 метров. Неважно какой код использовали для компиляции в MSIL, он будет одинаково выполняться в Runtime.
Это верно только для <script language=«cil» source=«MailApp.dll» />
А если делать возможным что-то вроде
<script language=«csharp»>
from email in documents.ElementsByTag(«email»)
email.Style.Font = «bold»;
</script>
то уже нужен компилятор С#.
А для того чтобы «Мы могли бы заменить 'csharp' любым существующим open-source компилятором (C#, IronPython, IronRuby и т.д.)» необходимо и все эти компиляторы.
А если делать возможным что-то вроде
<script language=«csharp»>
from email in documents.ElementsByTag(«email»)
email.Style.Font = «bold»;
</script>
то уже нужен компилятор С#.
А для того чтобы «Мы могли бы заменить 'csharp' любым существующим open-source компилятором (C#, IronPython, IronRuby и т.д.)» необходимо и все эти компиляторы.
а у меня Мак… О каком .Net идет речь?
Я так понимаю что идея все-таки несколько не продумана. Для начала надо взвесить целесообразность.: есть яваскрипт, его хватает. Хотите больше? Экшнскрипт и флэш. Еще больше? Ява!
И эти технологии отработаны годами, обкатаны на всех операционках.
Менять что-то, конечно, может и надо, но для начала надо все взвесить и продумать.
Я так понимаю что идея все-таки несколько не продумана. Для начала надо взвесить целесообразность.: есть яваскрипт, его хватает. Хотите больше? Экшнскрипт и флэш. Еще больше? Ява!
И эти технологии отработаны годами, обкатаны на всех операционках.
Менять что-то, конечно, может и надо, но для начала надо все взвесить и продумать.
>Нет, как концепт неплохо, но остается много непродуманных вопросов.
У кого конкретно остается много непродуманных вопросов? Думаю, что Мигель как раз хорошо себе представляет эту затею.
У кого конкретно остается много непродуманных вопросов? Думаю, что Мигель как раз хорошо себе представляет эту затею.
Я тут развлекался недавно, писал компилятор C# на C# с помощью Coco/R.
Исходников было на 3 мегабайта. В бинарном виде около 500К.
Тем более, что AST классы уже в модели кода есть — нужно только прочитать C# текст и преобразовать в AST.
Т.е. в принципе, можно прямо с браузером самые популярные языки ставить.
Исходников было на 3 мегабайта. В бинарном виде около 500К.
Тем более, что AST классы уже в модели кода есть — нужно только прочитать C# текст и преобразовать в AST.
Т.е. в принципе, можно прямо с браузером самые популярные языки ставить.
А я бы хотел нормальные layout-менеджеры из Qt или Gtk+ вместо этого ужаса на дивах и таблицах (особенно, когда смешивают дивы и таблицы).
Попытка в виде XUL уже была.
Ознакомьтесь с CSS3 Flexible Box Layout Module — это то самое и есть.
Согласно caniuse.com, у этого модуля есть поддержка в Firefox и в вебкитных браузерах (Chrome, Safari).
Согласно caniuse.com, у этого модуля есть поддержка в Firefox и в вебкитных браузерах (Chrome, Safari).
У Microsoft была попытка сделать аналог Google WebToolkit. Называлась она Volta и занималась переводом MSIL в JS. Не потянули — теперь хотят в браузер пропихнуть.
Другой вопрос — каких языков вам не хватает в Web? Python/Ruby/PHP — Javascript от них не сильно отличается. С++/С# — есть GWT с поддержкой статически типизированной Java.
Другой вопрос — каких языков вам не хватает в Web? Python/Ruby/PHP — Javascript от них не сильно отличается. С++/С# — есть GWT с поддержкой статически типизированной Java.
Microsoft здесь вообще не причем, всё-таки Microsoft не разрабатывает Mono.
Причины закрытия Volta мне не известны, но сомневаюсь, что причина в том, что не потянули. Я знаю несколько конвертеров MSIL->JS, которые со своей задачей справляются не хуже GWT.
И да, Javascript сильно отличается и от PHP и от Ruby, а GWT — это и есть попытка использования Javascript в качестве CLI, но в силу специфики и истории Javascript'а, преобразование Java в Javascript — это скорее костыль и лишняя прослойка.
Причины закрытия Volta мне не известны, но сомневаюсь, что причина в том, что не потянули. Я знаю несколько конвертеров MSIL->JS, которые со своей задачей справляются не хуже GWT.
И да, Javascript сильно отличается и от PHP и от Ruby, а GWT — это и есть попытка использования Javascript в качестве CLI, но в силу специфики и истории Javascript'а, преобразование Java в Javascript — это скорее костыль и лишняя прослойка.
Microsoft здесь вообще не причем, всё-таки Microsoft не разрабатывает Mono.
Ну не MS, а их партнеры. Разницы особой нет — назовем их собирательно ".NET camp".
Причины закрытия Volta мне не известны, но сомневаюсь, что причина в том, что не потянули. Я знаю несколько конвертеров MSIL->JS, которые со своей задачей справляются не хуже GWT.
Был прототип, который на порядки был хуже как по производительности, так и по объему сгенерированного кода. Я не отрицаю, что есть MSIL>JS конверторы. Только GWT — это не просто конвертор, это коммьюнити и целый набор инструментов: виджеты, среда разработки с дебаггером, сторонние библиотеки. Называть это костылем по крайней мере глупо.
И да, Javascript сильно отличается и от PHP и от Ruby
Чем принципиально отличается то? {} вместо begin..end? Чего Вам в JS не хватает?
> Чем принципиально отличается то? {} вместо begin..end? Чего Вам в JS не хватает?
Вы утрируете.
PHP — динамический язык со средним уровнем ООП.
JS — прототипо-ориентированный, что я в общем-то не считаю ООП в полной мере.
Ruby — динамический с сильно развитым ООП и элементами функциональной парадигмы.
Подходы и способы решения задач в этих языках могут очень сильно отличаться. Скажем, пытаться делать замыкания в PHP — верх безумия. Более того, я даже скажу, что Actionscript очень сильно отличается от Javascript, хотя и то, и то — часть ECMAscript.
А если предположить, что в Web'е на стороне клиента можно будет, например, использовать какой-нибудь Erlang, лично я буду очень рад :-) Для программирования системы, элементы которой работает полностью в асинхронном режиме, он лучше всего подходит.
> Называть это костылем по крайней мере глупо.
Я имел в виду несколько иное. Против GWT я ничего не имею, но сама идея конвертации полноценного ОО-языка в прототипо-ориентированный, чтобы потом это скомпилировалось в промежуточный байт-код, который затем будет выполняться, — лично мне кажется странной.
Вы утрируете.
PHP — динамический язык со средним уровнем ООП.
JS — прототипо-ориентированный, что я в общем-то не считаю ООП в полной мере.
Ruby — динамический с сильно развитым ООП и элементами функциональной парадигмы.
Подходы и способы решения задач в этих языках могут очень сильно отличаться. Скажем, пытаться делать замыкания в PHP — верх безумия. Более того, я даже скажу, что Actionscript очень сильно отличается от Javascript, хотя и то, и то — часть ECMAscript.
А если предположить, что в Web'е на стороне клиента можно будет, например, использовать какой-нибудь Erlang, лично я буду очень рад :-) Для программирования системы, элементы которой работает полностью в асинхронном режиме, он лучше всего подходит.
> Называть это костылем по крайней мере глупо.
Я имел в виду несколько иное. Против GWT я ничего не имею, но сама идея конвертации полноценного ОО-языка в прототипо-ориентированный, чтобы потом это скомпилировалось в промежуточный байт-код, который затем будет выполняться, — лично мне кажется странной.
Вы извините, но у вас каша в голове. «Средний», «в полной мере», «сильно развитый»… Замыкания в PHP — часть языка, о каком безумии речь? Erlang — да! И еще Haskell не помешал бы, правда?
1) Чем функциональная парадигма в Ruby перевешивает JS?
2) Чего вам не хвататет в прототипно-ориентированном подходе?
По-моему из стандартов не надо делать помойку, пихая туда все тренды подряд.
1) Чем функциональная парадигма в Ruby перевешивает JS?
2) Чего вам не хвататет в прототипно-ориентированном подходе?
По-моему из стандартов не надо делать помойку, пихая туда все тренды подряд.
Переводить высокоуровневый строготипизированный код на динамический JS, это как Assembler в BASIC, а потом BASIC JITить на клиенте.
Идея статьи — взять за транспорт не ECMAscript, а ECMA CLI, который может и JS исполнять в том числе.
Т.е. опуститься на один уровень ниже ближе к железу, что даст больше языков и поднимат производительность в -надцать раз.
Идея статьи — взять за транспорт не ECMAscript, а ECMA CLI, который может и JS исполнять в том числе.
Т.е. опуститься на один уровень ниже ближе к железу, что даст больше языков и поднимат производительность в -надцать раз.
Производительность чего — интерфейса? Что у вас там такое, что оно тормозит? Google Wave написан на GWT — все прекрасно работает, как и многие другие приложения Google.
Речь идет не столько о HTML интерфейсах, сколько об универсальной клиентской платформе, которая может вырасти на базе ECMA CLI. Те же плагины для браузера, браузерные и оффлайн приложения.
Я чет не разберу — сейчас какая проблема с написанием «плагины для браузера, браузерные и оффлайн приложения»? И как CLI ваш поможет разработке тех же плагинов, если все браузеры предоставляют разные подходы и API?
Универсальная клиентская платформа растет на базе HTML+JS. Тут ECMAscript откатывали из-за слишком быстрого развития, да H.264 из-за патентов. А вы предлагаете взять и встроить патентованную MS сложнейшую технологию сразу во все браузеры. И ради чего — так и не понятно, чтобы вы на C# могли DOM манипулировать?
Универсальная клиентская платформа растет на базе HTML+JS. Тут ECMAscript откатывали из-за слишком быстрого развития, да H.264 из-за патентов. А вы предлагаете взять и встроить патентованную MS сложнейшую технологию сразу во все браузеры. И ради чего — так и не понятно, чтобы вы на C# могли DOM манипулировать?
К счастью, вся эта затея умрет не родившись. Было время, когда Sun всерьез полагала, что сможет протащить <script language='tcl'>. Результат плачевен.
P.S. Тут сильно не хватает тега «microsoft». И название действительно сбивает с толку.
P.S. Тут сильно не хватает тега «microsoft». И название действительно сбивает с толку.
CLI
HLT
HLT
"<script language=«cil» source=«MailApp.dll»/>" — за.
"<script language=«csharp» source=«ImageGallery.cs»/>" — против.
За, потому что нужен лишь рантайм и неважно чем компилировали.
Против, потому что нужен еще и компилятор, причем такой, чтобы везде одинаково работал, а это дает лишнее утяжеление браузера и повышает вероятность того, что твой код где-нибудь не скомпилится.
К тому же компиляция — процесс не мгновенный (особенно для мобильных платформ).
"<script language=«csharp» source=«ImageGallery.cs»/>" — против.
За, потому что нужен лишь рантайм и неважно чем компилировали.
Против, потому что нужен еще и компилятор, причем такой, чтобы везде одинаково работал, а это дает лишнее утяжеление браузера и повышает вероятность того, что твой код где-нибудь не скомпилится.
К тому же компиляция — процесс не мгновенный (особенно для мобильных платформ).
Блин, Америку открыл. Все это уже давно есть и называется эта штука Silverlight.
CLI — это Command Line Interface. Долго думал, причем тут оно.
а как насчет стандартных библиотек для всех этих языков?
Спасибо автору за хороший перевод.
Идея понравилась, заинтересовался, надо буду следить за развитием этого направления.
IMHO, людям свойственно сопротивляться всему новому :)
Идея понравилась, заинтересовался, надо буду следить за развитием этого направления.
IMHO, людям свойственно сопротивляться всему новому :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Common Language Infrastructure (CLI) для веба