Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 173
Интересно, что имеется в виду, когда эти люди упоминают «проблемы с производительностью, которые есть у всех машин EcmaScript», и как они намерены преодолеть их в самóй конструкции нового компьютерного языка.
Отменят замыкания?
Отменят доступность по умолчанию всех глобальных переменных?
Отменят замыкания?
Отменят доступность по умолчанию всех глобальных переменных?
Замыкания и области видимости можно делать по-разному. В Go есть замыкания, но он работает шустрее EcmaScript. Для оптимизации важнее хорошая система типов, а не отсутсвие замыканий.
Замыкания и глобальные переменные — это далеко не главные проблемы javascript. Duck typing и first-class функции со словарями и кодом внутри — куда как более серьёзные препятствия для ускорения.
Прощай, Goole Closure
Круто. Теперь Google и язык программирования написали. Я с каждым днем все больше удивляюсь этой компании…
Чует моё сердце — не взлетит. Слишком уж большая популярность у JS.
Существует мнение, что она такова, в том числе, и из-за того, что это единственный вариант для использования в браузере.
У Fx есть возможность писать на python. У IE на VisualBasic. У Chrome на C++(???)…
Нужен универсальный инструмент для большинства популярных браузеров. Кроме JS на данный момент ничего нет.
А можно чуть подробнее об этом? Поверхностное гугление говорит лишь о наличие каких-то плагинов. Речь о них?
Там написано, что для программирования на Python нужно самому пересобирать платформу Mozilla (например, как сделано в продуктах Komodo).
Ни о каком программировании на Python в Firefox или Thunderbird (то есть, по определению,в официальных сборках) и речи быть не может, потому что по умолчанию никакого Питона в платформу Мозиллы не вкомпилируется.
Ни о каком программировании на Python в Firefox или Thunderbird (то есть, по определению,
На VBScript, а не Visual Basic.
GWT взлетило, а по сути перекомпиляция Java в Javascript. Если Dash будет поддерживаться специальным модулем для известных серверов (Apache, Tomcat,… ), перекомпиляцией в Javascript и будет поддерживаться несколькими браузерами Firefox, Chrome, Safari.
То еще как взлетит, конечно если результат будет виден. А для результата потребуется действительно быстродействие и модули разработки под IDE, чтобы осуществлять рефакторинг, дебаг, профилирование и т.п.
Задачка, конечно, сложная.
То еще как взлетит, конечно если результат будет виден. А для результата потребуется действительно быстродействие и модули разработки под IDE, чтобы осуществлять рефакторинг, дебаг, профилирование и т.п.
Задачка, конечно, сложная.
>Если Dash будет поддерживаться специальным модулем для известных серверов (Apache, Tomcat,… )
Вы о чем вообще?
Вы о чем вообще?
Конечно Apache тут не при чем, я поторопился, нужен просто модуль на сервере или в момент компиляции проекта, который будет транслировать имеющийся Dash в Javascript. И сервер должен по имени User-Agent или другим признакам отдавать Javascript для браузеров, которые не поддерживают Dash.
Ну примерно так, ведь всем понятно, что всякий, кто и начнет использовать Dash задастся вопросом, как поддерживать браузеры без Dash.
Ну примерно так, ведь всем понятно, что всякий, кто и начнет использовать Dash задастся вопросом, как поддерживать браузеры без Dash.
Компиляция на сервере — это сильно :)
а что, вместо обфускации и минимизации, прямо отдавать байткод
DOM структура документа серверу известна, можно компилировать из любого языка прямо в байткод и грузить в вирт. машину браузера. И пиши себе, хочешь — на Javascript, хочешь на Python, хоть C++ :)
DOM структура документа серверу известна, можно компилировать из любого языка прямо в байткод и грузить в вирт. машину браузера. И пиши себе, хочешь — на Javascript, хочешь на Python, хоть C++ :)
if (Math.random() < 0.5) {
document.write('<b>DOM-1</b>');
}
else {
document.write('<i>DOM-2</>');
}
Сообщите мне DOM-структуру на клиенте, пожалуйста:)
Легко. Через ajax отправляю на сервер DOM структуру и получаю соответствующий код. :)
Вы наверное считаете себя очень остроумным, однако я имел в виду, что в момент компиляции скрипта на сервере DOM-структура документа, куда встраивается скрипт, известна, потому что отдаётся тем же сервером (в широком смысле).
Что там происходит на клиенте после отправки, никакой скрипт, отправленный клиенту, узнать не сможет. Возможно только динамическое определение ситуации, но это очевидно и тривиально.
Поэтому нет никакой разницы, что отправлять — human-readable код на интерпретируемом языке высокого уровня или machine-readable байткод для исполнения в виртуальной машине. Тем более что JIT компиляторы сейчас везде.
Вы наверное считаете себя очень остроумным, однако я имел в виду, что в момент компиляции скрипта на сервере DOM-структура документа, куда встраивается скрипт, известна, потому что отдаётся тем же сервером (в широком смысле).
Что там происходит на клиенте после отправки, никакой скрипт, отправленный клиенту, узнать не сможет. Возможно только динамическое определение ситуации, но это очевидно и тривиально.
Поэтому нет никакой разницы, что отправлять — human-readable код на интерпретируемом языке высокого уровня или machine-readable байткод для исполнения в виртуальной машине. Тем более что JIT компиляторы сейчас везде.
Разница в том, что сервера будут пыхтеть больше и падать от нагрузки, в том случае когда вы не сможете отдавать данные из кэша.
Возьмите любую социальную сеть, куча народу, каждая страница получается уникальной, структуру не закэшить, скриптов заранее не набилдить.
Будем собирать при каждом запросе?
Возьмите любую социальную сеть, куча народу, каждая страница получается уникальной, структуру не закэшить, скриптов заранее не набилдить.
Будем собирать при каждом запросе?
Я вообще всегда считал что основная «фишка» javascript'а в том что он выполняется у клиента. Я отстал от жизни?
Выполняться он в любом случае будет у клиента, а компилироваться может и на сервере. Например, библиотеку а-ля jquery.js можно скомпилировать один раз на сервере и отдавать в байткоде тысячам клиентов, экономя их процессорное время. Вместо этого каждый раз у тысяч клиентов происходит одинаковая работа — JIT-компилятор загружает листинг текстового кода, делает свою работу, выдаёт некий бинарный набор символов, который загружается в виртуальную машину, которая затем начинает его исполнять. Можно сразу грузить бинарные данные, экономя массу времени и электричества :)
Правда, желательно иметь некий механизм верификации, чтобы в процессе передачи данных по сети не произошла подмена, но это уже технические детали реализации. Можно по https устанавливать соединение или передавать hash-код, хотя считать хеши тоже затратная операция…
Правда, желательно иметь некий механизм верификации, чтобы в процессе передачи данных по сети не произошла подмена, но это уже технические детали реализации. Можно по https устанавливать соединение или передавать hash-код, хотя считать хеши тоже затратная операция…
съело
< script type=«application/bin-js» src=«script.bjs» />
< script type=«application/bin-js» src=«script.bjs» />
Пока будет требоваться кросскомпиляция выигрыша в производительности не получится. Т.е. по настоящему преимущество в производительности получиться только когда все основные браузеры станут поддерживать его нативно. Таким образом, производительность никак не повлияет на его популярность.
Стобы Dart/Dash взлетел он должен быть лучшим языком чем JS, причём заметно лучшим, при этом оставаясь простым.
Стобы Dart/Dash взлетел он должен быть лучшим языком чем JS, причём заметно лучшим, при этом оставаясь простым.
>> Чтобы Dart/Dash взлетел он должен быть лучшим языком чем JS
тут даже велосипед не надо изобретать, взять лучшее из существующих языков. Даже не лучшее, а стандартное. Хотя бы ООП нормальный реализовали бы — уже хорошо будет.
А еще лучше сделать клиент-серверный язык. Вот это был бы прорыв.
тут даже велосипед не надо изобретать, взять лучшее из существующих языков. Даже не лучшее, а стандартное. Хотя бы ООП нормальный реализовали бы — уже хорошо будет.
А еще лучше сделать клиент-серверный язык. Вот это был бы прорыв.
В js нормальный ООП если убрать new. Просто необычный. И он проще, т.к. выпадает такой элемент как классы. Поэтому для легкого языка прототипное ООП — преимущество.
У меня некоторый диссонанс от вашего «ООП без классов». Поясните как это возможно, если в ООП центральное понятие — это класс.
>>А в ООП (как собственно следует из названия) центральное понятие это объект
Вы ООП по названию изучали? В классических реализациях вроде C++ или smalltalk или даже Delphi — центральное понятие это именно класс. Объект — это экземпляр класса.
Что касается прототипного программирования, да, в этой концепции есть ряд интересных моментов, тем не менее подавляющее большинство популярных языков реализуют именно класс-ориентированных подход. Почему бы?
Вы ООП по названию изучали? В классических реализациях вроде C++ или smalltalk или даже Delphi — центральное понятие это именно класс. Объект — это экземпляр класса.
Что касается прототипного программирования, да, в этой концепции есть ряд интересных моментов, тем не менее подавляющее большинство популярных языков реализуют именно класс-ориентированных подход. Почему бы?
>>популярность в мире программирования не имеет ничего общего с удобством/интуитивностью/качеством etc.
Эти понятия субъективны, в отличие от популярности. Мне, например, больше нравится реализация ООП в Delphi, хотя я прекрасно понимаю, что по возможностям она проигрывает С++ Т.н. ООП в JS мне лично неудобен и непонятен интуитивно. И все примеры кода на JS в том что я понимаю под качеством очень далеки от идеала, к которому близок тот же С++.
>>Взять например язык Io(который не так далеко ушел от Smalltalk'a)
Вы еще brainfuck вспомните. Кто кроме горстки энтузиастов пишет на этом вашем Ио? Smalltalk вообще язык экспериментальный, никаких серьезных проектов на нем никто не пишет. К слову, smalltalk исповедует именно класс-ориентированный подход.
Эти понятия субъективны, в отличие от популярности. Мне, например, больше нравится реализация ООП в Delphi, хотя я прекрасно понимаю, что по возможностям она проигрывает С++ Т.н. ООП в JS мне лично неудобен и непонятен интуитивно. И все примеры кода на JS в том что я понимаю под качеством очень далеки от идеала, к которому близок тот же С++.
>>Взять например язык Io(который не так далеко ушел от Smalltalk'a)
Вы еще brainfuck вспомните. Кто кроме горстки энтузиастов пишет на этом вашем Ио? Smalltalk вообще язык экспериментальный, никаких серьезных проектов на нем никто не пишет. К слову, smalltalk исповедует именно класс-ориентированный подход.
Так в Smalltalk класс — это объект, который служит шаблоном для создания экземпляров. И любой объект может в динамике создать новый класс… JavaScript в этом плане очень близок Smalltalk. Они оба — prototype based языки.
А привычная Вам система классов, как в Delphi, C++ или Java — попытка оптимизации, при чём относительно громоздкая и неуклюжая. Ну, есть же у нас теперь пример того же Go, где всё сделано намного изящнее.
А привычная Вам система классов, как в Delphi, C++ или Java — попытка оптимизации, при чём относительно громоздкая и неуклюжая. Ну, есть же у нас теперь пример того же Go, где всё сделано намного изящнее.
«Когда я придумывал ООП, я точно не имел в виду С++» © Алан Кей. Не надо называть С++ классической реализацией ООП. От этого котята мрут стаями.
И да, в Смолтолке классы — совсем не те классы, что в С++. Например, так как все — объект, классы тоже объекты. Ну и т.п.
И да, в Смолтолке классы — совсем не те классы, что в С++. Например, так как все — объект, классы тоже объекты. Ну и т.п.
Я и не предлагаю С++ брать за основу. Можно взять C#. Но то что сейчас есть в JS — это бледная тень ООП.
ООП в C# ничем не отличается от ООП в C++, Java и Delphi. У них — один и тот же подход к реализации ООП.
То, что есть в JS, — это не «бледная тень ООП», а просто другой способ реализации ООП. Если вам известен толькоо один подход, не значит, что не существует других, или что другие — это «бледные тени» ;)
То, что есть в JS, — это не «бледная тень ООП», а просто другой способ реализации ООП. Если вам известен толькоо один подход, не значит, что не существует других, или что другие — это «бледные тени» ;)
>>ООП в C# ничем не отличается от ООП в C++, Java и Delphi
С точки зрения JS наверное не отличается. Но есть ряд нюансов и довольно принципиальных. Как множественное наследование, например.
>>это не «бледная тень ООП», а просто другой способ реализации ООП
Ладно, каюсь, смотрю на ООП через призму С++, Delphi и прочих представителей классово-ориентированного подхода. Надо восполнить пробел.
С точки зрения JS наверное не отличается. Но есть ряд нюансов и довольно принципиальных. Как множественное наследование, например.
>>это не «бледная тень ООП», а просто другой способ реализации ООП
Ладно, каюсь, смотрю на ООП через призму С++, Delphi и прочих представителей классово-ориентированного подхода. Надо восполнить пробел.
Не. Вот в Haskell классы — это как раз совсем не ООП. Это именно классы типов.
А при чём тут Си++? В Haskell классы — это вообще не ООП. В чистых функциональных языках не бывает объектов. Классы типов — это именно классы типов, которые используются для контроля и поиска реализаций функций. Максимум, их можно рассматривать, как интерфейсы… Но объектов в Haskell нет, и быть не может, потому что объекты — это сущности с состояними.
Если действительно хороший язык получится и напишут, например, интерпретатор_на_javascript-e/plugin/activex для совместимости, то почему бы и нет)
А ещё три года назад в Google решили создать свой браузер, когда рынок уже был поделен. Ничего, остальные подвинулись.
Я думаю, что стоит упомянуть, что это всего лишь одна из догадок каким будет новый язык. Нигде ещё не было опубликовано каким именно он будет. Один из популярных вариантов, что это будет язык Newspeak, компилируемый в JavaScript, либо исполняемый нативно в браузере. Это следует из того, кто будет выступать с докладом этого языка в понедельник: один из докладчиков — автор Newspeak, а второй занимается V8 JavaScript Engine.
Я так понимаю, что все эти подробности взяты из этой «утечки»: markmail.org/message/uro3jtoitlmq6x7t
главное, чтобы разработчик был бородат :)
(по мотивам)
(по мотивам)
почему-то у меня первая ассоциация с
я очень сомневаюсь, что в осле в ближайшее десятилетие окажется поддержка этого языка. а в этом случае я не вижу в нём никаких серьёзных плюсов относительно CoffeeScript. все равно будем компилить в JS.
я очень сомневаюсь, что в осле в ближайшее десятилетие окажется поддержка этого языка. а в этом случае я не вижу в нём никаких серьёзных плюсов относительно CoffeeScript. все равно будем компилить в JS.
CoffeScript — это всего лишь синтаксический сахар для JavaScript. Когда вы пишите на CoffeScript, то думаете в терминах JavaScript. Когда вы пишете на Dart, то думаете в терминах Dart. Ожидается, что там будут объекты и сообщения между ними, инкапсуляция, система типизации и ещё куча отличий от JavaScript. Может быть это и будет компилироваться в JavaScript, но язык будет совсем другим.
> Когда вы пишете на Dart, то думаете в терминах Dart
я боюсь, что преждевременно делать такие смелые выводы, ещё не увидев язык. В CoffeeScript тоже есть классы, инкапсуляция и типизация, но они тоже сделаны в виде синтаксического сахара к JS и на его же возможностях.
я боюсь, что преждевременно делать такие смелые выводы, ещё не увидев язык. В CoffeeScript тоже есть классы, инкапсуляция и типизация, но они тоже сделаны в виде синтаксического сахара к JS и на его же возможностях.
можете посмотреть официальный мануал jashkenas.github.com/coffee-script/ в разделе Classes, Inheritance, and Super
а что, по-вашему, есть типизация?
я уже привык, что когда говорят про убогость типизации в JS, это обычно означает убогость её прототипной модели. а типизация в классическом её понимании — вот тебе String, вот тебе Integer, всё как у людей.
под инкапсуляцией в CoffeeScript я имел в виду:
1) все скрипты запускаются всегда в (function(){… }).call(this). Это не совсем инкапсуляция, но довольно полезно для неё
2) не помню, ввели они это в master, или нет (мне ни разу не пригождалось), но в нём делали такую вещь, как Class Executable Body. С помощью него можно сделать подобие private-методов.
1) все скрипты запускаются всегда в (function(){… }).call(this). Это не совсем инкапсуляция, но довольно полезно для неё
2) не помню, ввели они это в master, или нет (мне ни разу не пригождалось), но в нём делали такую вещь, как Class Executable Body. С помощью него можно сделать подобие private-методов.
В JS будем компилить для старых браузеров. Т.е. например в chrome будет использоваться нативная версия, которая (по идее) должна работать существенно быстрее.
но ведь всё равно будем компилировать. а тут вполне логичный вывод: если все браузеры поддерживают JS и только хром будет поддерживать Dash, то не проще ли сразу ориентироваться на компилированный JS?
во всяком случае меня сейчас скорость JS вполне устраивает.
во всяком случае меня сейчас скорость JS вполне устраивает.
Возможно, dash будет пригоден для выполнения ресурсоемких задач. JS работает достаточно быстро на тех задачах, которые сейчас решаются с его помощью. Но, например, сложну обработку графики/видео на нем сделать и не пытаются.
Кроме того, вполне возможно что оперативно подтянется firefox. Что даст уже более половины пользователей. А IE… ну, его пользователям не привыкать к тормозам)
Кроме того, вполне возможно что оперативно подтянется firefox. Что даст уже более половины пользователей. А IE… ну, его пользователям не привыкать к тормозам)
если все браузеры поддерживают JS и только хром будет поддерживать Dash, то не проще ли сразу ориентироваться на компилированный JS?
А если
все браузеры, кроме IE, поддерживают Dash, то не проще ли сразу ориентироваться на Dash и компилировать его в JS для совместимости?
Конечно, это при условии, что Dash действительно будет того стоить. Пока ничего не ясно.
знаете, возможно это мы с вами поймём, что
а наши работодатели и коллеги скорее всего не очень. к примеру, я не вижу повсеместного использования border-radius, box-shadow и background: gradient вместо старых-добрых png, хотя их и поддерживают все кроме IE6-7.
если все браузеры, кроме IE, поддерживают Dash, то не проще ли сразу ориентироваться на Dash и компилировать его в JS для совместимости?
а наши работодатели и коллеги скорее всего не очень. к примеру, я не вижу повсеместного использования border-radius, box-shadow и background: gradient вместо старых-добрых png, хотя их и поддерживают все кроме IE6-7.
ie8 тоже не поддерживает :(
Сравнение некорректно. Если есть возможность в IE как бы включить поддержку недостающей технологии, то этим пользуются, если нет, то всё равно париться и уже не имеет смысл использовать border-radius для остальных браузеров.
во-первых, ie7-js.googlecode.com/
а во-вторых, я говорил не о любой возможности использования, а конкретно о возможности использования его без компиляции в JS. проще говоря: зачем мне держать на сервере две версии одного скрипта (на Dash и он же компилированный в JS), если в нормальных браузерах разница производительности в них не заметна, а не нормальные браузеры чистый Dash вообще не поддерживают?
и да, сразу отмечу: я не имею в виду тяжёлые JS-приложения, в которых сейчас заметен недостаток производительности. но не считая игр, я за последний месяц таких просто не встречал, поэтому и пропускаю их.
а во-вторых, я говорил не о любой возможности использования, а конкретно о возможности использования его без компиляции в JS. проще говоря: зачем мне держать на сервере две версии одного скрипта (на Dash и он же компилированный в JS), если в нормальных браузерах разница производительности в них не заметна, а не нормальные браузеры чистый Dash вообще не поддерживают?
и да, сразу отмечу: я не имею в виду тяжёлые JS-приложения, в которых сейчас заметен недостаток производительности. но не считая игр, я за последний месяц таких просто не встречал, поэтому и пропускаю их.
Недавно перевели:
Ну здорово. Только вот компиляция в JS вряд ли сильно поможет в борьбе за производительность. А в остальном пока что фреймворки справляются. Мне больше верится в развитие браузеров в сторону поддержки фреймворков. Интеграция в движок если не всего функционала, то критичных к производительности вещей и как следствие повышение производительности.
Почему же? Если недоступные фишки Дэша будет заменены JS-реализациями, а все остальное почти 1 в 1 транслировано в JS?
Ведь у Google есть очень большой опыт в подобной затее — это GWT. Большинство конструкций Java почти напрямую переводится в JS (ведь GWT работает не с байткодом, а именно с исходниками), что дает практически ту же производительность что и написание сразу JS.
Так что, возможно, не так все плохо будет — можно будет писать на удобном языке, а запускаться будет уже подпиленный JS.
Хотя лично мне вот одну бы штуку — вместо function(x) { return x*x; } такой же как в C# синтаксис — x => x*x и цены небыло бы. Ну и async.
Ведь у Google есть очень большой опыт в подобной затее — это GWT. Большинство конструкций Java почти напрямую переводится в JS (ведь GWT работает не с байткодом, а именно с исходниками), что дает практически ту же производительность что и написание сразу JS.
Так что, возможно, не так все плохо будет — можно будет писать на удобном языке, а запускаться будет уже подпиленный JS.
Хотя лично мне вот одну бы штуку — вместо function(x) { return x*x; } такой же как в C# синтаксис — x => x*x и цены небыло бы. Ну и async.
посмотрите CofeeScript. в нём нормальная конструкция
(x) -> x*xДа я его смотрел, и много раз.
Но проблема в том, что в кофескрипте больше того, что мне не нравится, чем в JS — это и «значимые отступы», и интеллектуальный вывод переменных (а я предпочитаю пусть ошибку выдает, чем само определяет нужно ли объявить переменную или нет) и т.д.
А мне нужно просто чуток подсахаренный JS, c включенным «use strict» :)
Но проблема в том, что в кофескрипте больше того, что мне не нравится, чем в JS — это и «значимые отступы», и интеллектуальный вывод переменных (а я предпочитаю пусть ошибку выдает, чем само определяет нужно ли объявить переменную или нет) и т.д.
А мне нужно просто чуток подсахаренный JS, c включенным «use strict» :)
Замена и трансляция не даст прироста. Ну не бывает так, чтобы наворачиванием еще одного слоя повышалась производительность. Разве что там будут какие-то суровые оптимизации, но мне это представить сложно.
Прирост можно получить только поддержкой со стороны браузера, переложение критичных вещей на браузер (а он там уже может и видеокарту задействовать и много других недоступных инструментов) и в этом месте будет профит. А если что-то транслировать в js, то как оно может быть быстрее js?
Прирост можно получить только поддержкой со стороны браузера, переложение критичных вещей на браузер (а он там уже может и видеокарту задействовать и много других недоступных инструментов) и в этом месте будет профит. А если что-то транслировать в js, то как оно может быть быстрее js?
Очень простой пример то, что есть в GWT что делает некоторые вещи с его использованием быстрее чем напрямую писать на JS (я это как-то на своих докладов по GWT рассказывал) — это то, что он для каждого броузера делает свою версию приложения, идеально «заточенного» под этот броузер.
Т.е. вот возьмем jQuery — там уйма «если ие, то… если фф то ...», а GWT просто просто бутстрапером определит что за броузер, что за язык у пользователя, и отдаст заточенную под комбинацию броузера-язык версию приложения.
И отсутствием ифов и подстановкой строк (не надо искать локализированную версию строки — для русского будет код alert(«привет»), а для англ — alert(«hello»), и достигается большая производительность, если сравнивать с написанием подобного функционала «руками».
А достигается это именно с помощью того, что оно при «компиляции» анализирует, транслирует и подставляет то что нужно.
Т.е. вот возьмем jQuery — там уйма «если ие, то… если фф то ...», а GWT просто просто бутстрапером определит что за броузер, что за язык у пользователя, и отдаст заточенную под комбинацию броузера-язык версию приложения.
И отсутствием ифов и подстановкой строк (не надо искать локализированную версию строки — для русского будет код alert(«привет»), а для англ — alert(«hello»), и достигается большая производительность, если сравнивать с написанием подобного функционала «руками».
А достигается это именно с помощью того, что оно при «компиляции» анализирует, транслирует и подставляет то что нужно.
Я вас понял.
Да, если подстраиваться под окружение — можно выдурить прирост. Но тоже самое ведь можно сделать и сейчас? Определить на серверной стороне браузер и отдать нужный файл.
Облегчение компиляции — да, было бы здорово. Но думаю и это не так сложно реализовать. Не тянет на отдельный «новый язык».
Да, если подстраиваться под окружение — можно выдурить прирост. Но тоже самое ведь можно сделать и сейчас? Определить на серверной стороне браузер и отдать нужный файл.
Облегчение компиляции — да, было бы здорово. Но думаю и это не так сложно реализовать. Не тянет на отдельный «новый язык».
Главный критический изъян JavaScript — он сделан не в Google.
Просто для справки. В своё время шли разговоры о том, чтобы сделать нативную поддержку ActionScript 3 в FireFox.
Просто для справки. В своё время шли разговоры о том, чтобы сделать нативную поддержку ActionScript 3 в FireFox.
какой смысл ActionScript без флеша?
смысл в том, что через AS3 пришел бы революционный стандарт EcmaScript 4 с его нововведениями.
Нет в Ecmascript 4 ничего революционного. ЕМНИП — только попытка сделать из JS очередной C++/Java
а чем Вам не нравится ООП в стиле C++/Java/C#?
даже конкретизирую вопрос: чем ООП на классах хуже ООП на прототипах?
даже конкретизирую вопрос: чем ООП на классах хуже ООП на прототипах?
Почему вы решили, что мне не нравится ООП в стиле C++/Java/C#? ;)
Я просто говорю, что есть разные способы реализации ООП ;)
Я просто говорю, что есть разные способы реализации ООП ;)
ок:)
просто под революционным имел ввиду по сравнению с EcmaScript 3.
просто под революционным имел ввиду по сравнению с EcmaScript 3.
А, стоп :) Я понял, что неправильно понял, в какой ветке нахожусь :)
Против ООП в стиле С++ и проч. я ничего не имею. Я против того, чтобы его насильно запихивали в язык, в котором ООП уже есть, пусть оно и не такое, как в С++ и иже с ним :)
Против ООП в стиле С++ и проч. я ничего не имею. Я против того, чтобы его насильно запихивали в язык, в котором ООП уже есть, пусть оно и не такое, как в С++ и иже с ним :)
Понятно;) Согласен с Вами насчет насильного запихивания, однако в последнее время многие вендоры стараются делать все и вся именно на JS. Взять хотя бы Google с Chrome OS и HP с WebOS. При текущей ситуации создание и далее поддержка, скажем, млн. строк кода на JS станет гораздо труднее и неповоротливее, чем сейчас.
Google говорит, что JavaScript не достаточно мощный для разработки крупных приложений, им нужен язык со статической типизацией и т.д.
Что в этом плане может дать ActionScript:
1. Статическая типизация;
2. Нормальное ООП: соответствующий синтаксис, области видимости, зависимости, интерфейсы и т.д.;
3. Язык основан на EcmaScript, т.е. должен быть прост в изучении для людей с опытом работы на JavaScript;
4. У языка уже есть сообщество: Adobe и флэш-разработчики. Кроме того, уже есть открытый компилятор и среды для разработки (открытые в том числе). Плюс у Mozilla есть некоторый опыт внедрения;
5. Различные плюшки: стандарт E4X, кстати, реализованный Mozilla в SpiderMonkey, векторы и т.д.
Что в этом плане может дать ActionScript:
1. Статическая типизация;
2. Нормальное ООП: соответствующий синтаксис, области видимости, зависимости, интерфейсы и т.д.;
3. Язык основан на EcmaScript, т.е. должен быть прост в изучении для людей с опытом работы на JavaScript;
4. У языка уже есть сообщество: Adobe и флэш-разработчики. Кроме того, уже есть открытый компилятор и среды для разработки (открытые в том числе). Плюс у Mozilla есть некоторый опыт внедрения;
5. Различные плюшки: стандарт E4X, кстати, реализованный Mozilla в SpiderMonkey, векторы и т.д.
В JS нормальное ООП, просто другое. Не надо на всё надевать одну шапку. И да, ООП — не серебряная пуля. Большие проекты и на Erlang пишутся, и на Haskell. Но в целом я с вами согласен, AS3 крутая штука. Только тут надо понимать, что нужно просто обновить JS до следующего стандарта ES. И снова: а надо ли? ExtJS4 неплохо себя чувствует, а что-то мощнее в браузере вряд ли нужно. Google проблему из воздуха делает, им хочется Web OS и анально огородиться, а взлетит ли оно неизвестно.
1. В JavaScript реализовано прототипное программирование, которое сильно отличается от классического Java-стиля.
2. В остальном полностью согласен. JavaScript прекрасно справляется с тем, для чего был создан — создание интерактивности на web-страницах. Зачем создавать из него универсальный комбайн, не понятно. Но если уж так хочется, то можно использовать давно существующие языки.
2. В остальном полностью согласен. JavaScript прекрасно справляется с тем, для чего был создан — создание интерактивности на web-страницах. Зачем создавать из него универсальный комбайн, не понятно. Но если уж так хочется, то можно использовать давно существующие языки.
Гугл специально пытается перенести пользовательский софт в среду веб-браузера по следующим причинам:
— во первых, это создаст очередной ажиотаж разработки софта в НОВОЙ экосистеме. Причем она должна быть НЕ СОВМЕСТИМОЙ с уже созданным софтом под хост-ось (так и будет). И пусть меня называют параноиком, но я четко вижу что в случае с Линукс хостом, который все свободные разработчики хотели бы видеть не в 2% а в 100% железа, это приведет к переписыванию уже существующего под Линукс софта в рамках новой экосистемы. Так же, как уже сегодня идет активное дуплицирование Линуксового софта в Андройде — НОВОЙ экосистеме, которая намеренно сделана НЕ СОВМЕСТИМОЙ со свободным софтом Линукс, т.е. с подавляющим большинством СПО, которое создано на сегодняшний день.
А успех такого переписывания под новую экосистему будет за счет пропаганды Гугла (одной из самых сильных на рынке сегодня) и разыгрывания карты под названием «открытое ПО», которой Гугл хочет переманить опенсорс разработчиков к себе. Это очень грязная игра капиталистов против «социалистического» СПО…
— во вторых, это позволит перенести личные пользовательские данные в сферу сетевых сервисов, т.к. ПО написанное в браузере будет в основном передавать данные через сеть (для анализа и социального инжиниринга). Опять же, СПО сообщество сегодня способно решить большинство задач, которые стоят перед среднестатистическим пользователем. Но! Ввиду пропаганды Гугла, ввиду громадных ресурсов разработки на стороне Гугла, ввиду переманивания разработчков «открытостью», темпы развития Гугловского софта быстро опередят старания независимых сообществ и хомячки подсядут на веб-браузер. Инициатива будет перехвачена. А дальше хозяин — барин…
— в третьих (опять же ИМХО, без доказательств и вызова к полемике), учитывая участие команды ответственной за создание Java c ее виртуальной машиной, можно предположить что число заложенных бомб для «санкционированного взлома» пользовательского софта (поэтому Линукс сообщество и выпиливает Java из систем «чувствительных» ко взлому) в новоиспеченном Dart будет не меньшее. Благо Homeland Security Act позволяет… И конечно же софт будет «открытым», ибо серьезные кодеры, которые знают что к чему в Java, ее просто обходят стороной вежливо прикрываясь «тормозами виртуальной машины»…
— во первых, это создаст очередной ажиотаж разработки софта в НОВОЙ экосистеме. Причем она должна быть НЕ СОВМЕСТИМОЙ с уже созданным софтом под хост-ось (так и будет). И пусть меня называют параноиком, но я четко вижу что в случае с Линукс хостом, который все свободные разработчики хотели бы видеть не в 2% а в 100% железа, это приведет к переписыванию уже существующего под Линукс софта в рамках новой экосистемы. Так же, как уже сегодня идет активное дуплицирование Линуксового софта в Андройде — НОВОЙ экосистеме, которая намеренно сделана НЕ СОВМЕСТИМОЙ со свободным софтом Линукс, т.е. с подавляющим большинством СПО, которое создано на сегодняшний день.
А успех такого переписывания под новую экосистему будет за счет пропаганды Гугла (одной из самых сильных на рынке сегодня) и разыгрывания карты под названием «открытое ПО», которой Гугл хочет переманить опенсорс разработчиков к себе. Это очень грязная игра капиталистов против «социалистического» СПО…
— во вторых, это позволит перенести личные пользовательские данные в сферу сетевых сервисов, т.к. ПО написанное в браузере будет в основном передавать данные через сеть (для анализа и социального инжиниринга). Опять же, СПО сообщество сегодня способно решить большинство задач, которые стоят перед среднестатистическим пользователем. Но! Ввиду пропаганды Гугла, ввиду громадных ресурсов разработки на стороне Гугла, ввиду переманивания разработчков «открытостью», темпы развития Гугловского софта быстро опередят старания независимых сообществ и хомячки подсядут на веб-браузер. Инициатива будет перехвачена. А дальше хозяин — барин…
— в третьих (опять же ИМХО, без доказательств и вызова к полемике), учитывая участие команды ответственной за создание Java c ее виртуальной машиной, можно предположить что число заложенных бомб для «санкционированного взлома» пользовательского софта (поэтому Линукс сообщество и выпиливает Java из систем «чувствительных» ко взлому) в новоиспеченном Dart будет не меньшее. Благо Homeland Security Act позволяет… И конечно же софт будет «открытым», ибо серьезные кодеры, которые знают что к чему в Java, ее просто обходят стороной вежливо прикрываясь «тормозами виртуальной машины»…
Простите, dart — это язык. Не реализация. Более того, ни из чего не следует, что google будет реализовывать его под что-то кроме chrome.
Гугл специально пытается перенести пользовательский софт в среду веб-браузера по следующим причинам:
— во первых, это создаст очередной ажиотаж разработки софта в НОВОЙ экосистеме.
— во вторых, это позволит перенести личные пользовательские данные в сферу сетевых сервисов,
— в третьих (опять же ИМХО, без доказательств и вызова к полемике), учитывая участие команды ответственной за создание Java c ее виртуальной машиной, можно предположить что число заложенных бомб для «санкционированного взлома» пользовательского софта (поэтому Линукс сообщество и выпиливает Java из систем «чувствительных» ко взлому) в новоиспеченном Dart будет не меньшее.
А в-нулевых, потому что перенос пользовательского софта «в среду веб-браузера» — это единственный на данный момент рабочий механизм монетизации труда программистов. Коробочный софт умер, а Google, как первым осознавший и это, и работоспособные альтернативы компьютерному софту, пытается… нет, даже не «захватить новый рынок», а скорее помочь рынку развиться и повзрослей как можно быстрее
а в-минус-первых, главная цель гугла: забаррикадировать свой поисковый бизнес с сопутствующими сервисами от любого рода нападок.
а любого рода нападки возможны только со стороны всех софтверных компаний с более большим возрастом на рынке (читаем MS между строк).
поэтому лучше унести землю из-под их ног. ведь лучшая защита — это атака. тому подтверждение Docs, GMail, Chrome, Android.
а любого рода нападки возможны только со стороны всех софтверных компаний с более большим возрастом на рынке (читаем MS между строк).
поэтому лучше унести землю из-под их ног. ведь лучшая защита — это атака. тому подтверждение Docs, GMail, Chrome, Android.
Коробочный софт умер? Куча компаний, начиная с MS и apple недоуменно смотрят на Ваш комментарий.
> а Google, как первым осознавший и это, и работоспособные альтернативы компьютерному софту
Далеко не они первые. Но даже у них не получается нормально все это дело толкнуть. Проблема даже не в JS vs. Dart. Проблема в том, что нельзя даже сдалеть нормальные табы со сложным контентом без того, чтобы браузер не начинал стонать на reflow и redraw. То есть проблема не в языке, а в DOM'е.
Далеко не они первые. Но даже у них не получается нормально все это дело толкнуть. Проблема даже не в JS vs. Dart. Проблема в том, что нельзя даже сдалеть нормальные табы со сложным контентом без того, чтобы браузер не начинал стонать на reflow и redraw. То есть проблема не в языке, а в DOM'е.
А можно подробней про «бомбы» в JVM?
Google нашел «фатальный недостаток» в JavaScript?) У меня такое ощущение, что Google встал на ту же тропу, на которую встал Microsoft во время браузерных войн с Netscape. Впрочем, Microsoft тогда победили…
Мне кажется, что если дело будет стоящее, то в firefox это будет включено. От кого бы не следовала инициатива. Почему-то я верю, что там смотрят не на источник инициативы, а на суть нововведений.
Ну а у microsoft своя дорожка.
Ну а у microsoft своя дорожка.
скорее всего этот «фатальный недостаток» — отсутствие строгой типизации, из-за чего скорость работы любой программы, скомпиленной JIT или AOT компилятором, будет всегда медленнее.
> скорость работы любой программы, скомпиленной JIT или AOT компилятором, будет всегда медленнее
нет. не любой и не всегда. JIT-компиляторы опирающиеся на type feedback в той или иной его форме (трассировка, inline cache) способны для горячих мест порождать достаточно чистый код, сравнимый с тем, что дают компиляторы для более строго типизированных языков типа C++ или Java.
нет. не любой и не всегда. JIT-компиляторы опирающиеся на type feedback в той или иной его форме (трассировка, inline cache) способны для горячих мест порождать достаточно чистый код, сравнимый с тем, что дают компиляторы для более строго типизированных языков типа C++ или Java.
однако, type feedback JIT-компилятор способен на это лишь либо после нескольких вызовов участка кода, либо после исполнения кода (при профайлинге, например).
и как Вы уже написали
т.е. почти, но не лучше и быстрее.
и как Вы уже написали
способны для горячих мест порождать достаточно чистый код, сравнимый с тем, что дают компиляторы для более строго типизированных языков типа C++ или Java.
т.е. почти, но не лучше и быстрее.
> однако, type feedback JIT-компилятор способен на это лишь либо после нескольких вызовов участка кода
да, это так… и что?
> т.е. почти, но не лучше и быстрее.
«почти» достаточно часто означает «быстрее не переписывая функцию не получится»
вот посмотрите не график: attractivechaos.github.com/plb/plb-lang.png
LuaJIT2 для кода перемножения двух матриц (в лоб, вложенные циклы) дает код который на 0.1s оказывается быстрее того, что дает GCC. JavaScript версия на V8 оказывается как Java. (если в V8 сделать array bounds check elimination, и убрать interruption check на обратной дуге цикла необходимый для поддержки отладчика, то он LuaJIT догонит)
И код (особенно у LuaJIT2, который bounds checkи не вставляет для ffi массивов и не обязан поддерживать прерывание циклов в отличие от V8) получается ну ровно такой как вы руками напишите на ассемблере. Временные floating point значения на xmm регистрах, инварианты циклов вынесены и т.д.
С Sudoku ситуация менее приятная, но опять же V8 быстрее, чем Mono оказывается, которая вообще-то исполняет более строго типизированный байткод. Впрочем я код Sudoku не смотрел, может там есть какие-то низко висящие фрукты для оптимизации.
да, это так… и что?
> т.е. почти, но не лучше и быстрее.
«почти» достаточно часто означает «быстрее не переписывая функцию не получится»
вот посмотрите не график: attractivechaos.github.com/plb/plb-lang.png
LuaJIT2 для кода перемножения двух матриц (в лоб, вложенные циклы) дает код который на 0.1s оказывается быстрее того, что дает GCC. JavaScript версия на V8 оказывается как Java. (если в V8 сделать array bounds check elimination, и убрать interruption check на обратной дуге цикла необходимый для поддержки отладчика, то он LuaJIT догонит)
И код (особенно у LuaJIT2, который bounds checkи не вставляет для ffi массивов и не обязан поддерживать прерывание циклов в отличие от V8) получается ну ровно такой как вы руками напишите на ассемблере. Временные floating point значения на xmm регистрах, инварианты циклов вынесены и т.д.
С Sudoku ситуация менее приятная, но опять же V8 быстрее, чем Mono оказывается, которая вообще-то исполняет более строго типизированный байткод. Впрочем я код Sudoku не смотрел, может там есть какие-то низко висящие фрукты для оптимизации.
ну ffi в LuaJIT2 делается руками — это ничуть не заслуга компилятора, а делать при этом bounds check — было бы совсем неправильно — ведь уже будет известен размер массива, и не придется динамически расширять сам массив.
И код (особенно у LuaJIT2, который bounds checkи не вставляет для ffi массивов и не обязан поддерживать прерывание циклов в отличие от V8) получается ну ровно такой как вы руками напишите на ассемблере. Временные floating point значения на xmm регистрах, инварианты циклов вынесены и т.д.
Руками, но при этом строгой типизации как таковой нету.
А про bounds check я заикнулся к тому, что bounds check elimination даст примерно тот же эффект.
А про bounds check я заикнулся к тому, что bounds check elimination даст примерно тот же эффект.
однако, мы говорим про сами языки и их компиляторы как таковые. а все делать руками и изощряться там, где обычно это и не ожидается, для достижения максимальной производительности, то это не приведет нас к
что никак не вяжется с просмотром сгенерированного ассемблерного кода и т.д.
представьте, чтобы каждый JS-программист разбирался в таких тонкостях, да еще и для каждого браузера отдельно.
Удобство разработки. Будет сохранена динамическая, лёгкая в освоении, не требующая компиляции природа Javascript, которая сделала веб-платформу абсолютным лидером среди программистов-любителей.
что никак не вяжется с просмотром сгенерированного ассемблерного кода и т.д.
представьте, чтобы каждый JS-программист разбирался в таких тонкостях, да еще и для каждого браузера отдельно.
Гугл сделал свой ActiveX, теперь гугл сделает свой VBScript.
История движется по спирали
История движется по спирали
Производительность. Виртуальные машины на Dash не будут иметь тех проблем с производительностью, которые есть у всех машин EcmaScript.
значит будет строгая типизация
… отправилось чуть раньше…
Dash спроектирован таким образом, чтобы было легче использовать дополнительные инструменты для больших серьёзных проектов, которые требуют поддержки, в том числе таких функций как рефакторинг и поиск мест вызова функций.
Что-то мне подсказывает, что этот язык — как новый джейпег для фотографов и прочих людей — т.е. вроде как меньше, только все на херу вертели все новые стандарты данных, когда есть старые и работающие.
Интересно, что может убедить сотни тысяч программистов — не энтузиастов изучать новый язык вместо джаваскрипта?
«I’m sure this new language for web browsers will be as big a succes as the previous new languages for web browsers.» Thijs van der Vossen
Делали бы сразу клиент-серверный язык. Вот это был бы прорыв.
То что не вышло у Microsoft (ASP.NET+Silverlight вроде как неплохо задумано, но реализовано как всегда, и никто не юзает), вполне может получится у гугла, я верю.
То что не вышло у Microsoft (ASP.NET+Silverlight вроде как неплохо задумано, но реализовано как всегда, и никто не юзает), вполне может получится у гугла, я верю.
странно, что офис в Дании. Там очень дорогая рабочая сила, неужели самая квалифицированная?
Ясно — и тут лишь спекуляции сплетнями. Идея видно не ахти, раз прибегают к маркетингу подобного рода: типа взболтать, и когда всё перемешается — представить освободителя, пришедшего в лучах славы, и при отсутствии психологического отторжения нового. А так будет, поскольку к тому времени в мозгу уже должен будет созреть образ идеального языка программирования, и ему имя — Dart, πлять!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подробности о новом языке программирования Google Dart (Dash)