В списке рассылки разработчиков языка программирования Tcl представлен (https://groups.google.com/forum/#!topic/comp.lang.tcl/mo_7jZ...) проект NaTcl (http://wiki.tcl.tk/NaTcl), в рамках которого выполнена работа по адаптации среды для запуска Tcl-скриптов внутри веб-браузера, позволяющая создавать выполняемые на стороне клиента web-приложения не только на языке JavaScript. NaTcl предоставляет приложениям прямой доступ к DOM-дереву объектов браузера, поддерживает обработку событий, предоставляя похожий на JavaScript арсенал средств.
Интеграция Tcl с браузером выполнения благодаря использованию наработок проекта Native Client (http://code.google.com/p/nativeclient/), в рамках которого компанией Google развивается платформа для создания универсальных web-приложений, написанных на языке C/C++ и использующих специальный API для выполнения свойственных web-приложениям действий. При помощи Native Client можно организовать (http://www.opennet.me/opennews/art.shtml?num=29671) выполне...URL: http://www.theregister.co.uk/2011/04/14/tcl_on_native_client/
Новость: http://www.opennet.me/opennews/art.shtml?num=30279
Обалдеть!
Еще бы Lisp прикрутили и Erlang :)
> Обалдеть!
> Еще бы Lisp прикрутили и Erlang :)И Brainfuck !!!
> Обалдеть!
> Еще бы Lisp прикрутили и Erlang :)А вы видите такого в этих вариантах, которые вы предложили?
Если вы каких-то языков не знаете, это еще не значит, что эти языки такие плохие.
Я наоборот, только за, и считаю эти языки полезными.
Какие из проблем Javascript в целом и DOM в частности решает этот проект?
Наоборот, к проблемам Javascript добавляются еще и проблемы TCL :)
> Наоборот, к проблемам Javascript добавляются еще и проблемы TCL :)Проблемы есть в любых языках.
Просто вы скорее всего о них не знаете, и просто так от балды решили написать.
От всех проблем javascipt :-)А если серьёзно - оторвать веб-приложения от JS было бы очень вкусно. Начиная с идеологических соображений - не стоит навязывать один вариант действий всем - и заканчивая тем, что JS, вообще-то, язык с проблемами - одни "точки с запятой по умолчанию" чего стоят.
Но основной плюс, конечно - то, что сама идея NaCl потихоньку распространяется. Всё же лучше, когда html-документ четко отделен от приложения, и раз flash не сумел завоевать достаточную популярность в этом плане - возможно, NaCl сможет.
>JS, вообще-то, язык с проблемами - одни "точки с запятой по умолчанию" чего стоят.Не могли бы вы развернуть свою мысль. Чем не угодила точка с запятой в качестве разделителя операций?
Ну а по теме, количество кодеров js превышает кодеров tcl на несколько порядков. В свое время не получили распространение VBScript и PerlScript, не смотря на поддержку в древних браузерах. А ведь на то время куда более распространенные языки. Как по мне мертворожденный проект.
Интерпретатор JS автоматически вставляет точку с запятой по своему усмотрению (как найдет место, где оператор МОЖЕТ оканчиваться, но необязательно это делает), благодаря чему повышается риск ошибок. Плюс любители стиля BSD идут лесом, только K&R.
Вообще после изучения JS у меня осталось впечатление, что ECMA сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности": typeof (null) == object, опасный оператор with, почти бесполезны
> Интерпретатор JS автоматически вставляет точку с запятой по своему усмотрению (как найдет место, где оператор МОЖЕТ оканчиваться, но необязательно это делает), благодаря чему повышается риск ошибок.Ну в случае с автоподставлением ";" и смесью разделителей строк - допустим это не очень хорошо.
Хотя это еще надо посмотреть с точки зрения трансляции - может все еще не так страшно.> Плюс любители стиля BSD идут лесом, только K&R.
http://ru.wikipedia.org/wiki/ECMAScript
<цитата>
Учёт этой особенности языка при выработке стандарта оформления кода может помочь избежать ошибок. Играет роль выбор стиля отступов. В частности, широко распространённые сейчас стили Олмана и Уайтсмита, а также стиль Хорстмана и стиль GNU для кода JavaScript являются менее предпочтимыми, нежели стили K&R, 1TBS, BSD KNF или баннерный стиль."
</цитата>Как-то непонятно, кто именно "идет лесом".
И что именно считать стилем BSD? Олмана или BSD KNF?
А также, что конкретно мешает писать в других стилях?> typeof (null) == object,
А здесь-то в чем проблемы? Это полностью соответствует ОО-концепции.
null - это тоже такой объект. Все правильно.> опасный оператор with, почти бесполезны
Согласен, with там правда "плохой". В visual basic и то лучше. :(
> Вообще после изучения JS у меня осталось впечатление, что ECMA сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности":
Все таки чтобы заявлять такое, вы все-таки пока указали слишком мало недочетов. Либо нужно показать, в каких языках подобных проблем меньше.
> Все таки чтобы заявлять такое, вы все-таки пока указали слишком мало недочетовЯ говорю о своем впечатлении, а не утверждаю, что язык абсолютно плох. Он как раз понравился мне, в нем реализованы интересные идеи ООП, но несколько пакостных моментов забыть никак не могу. Как показывает практика, язык вполне юзабелен и популярен, вот только могло бы быть и получше.
> Как-то непонятно, кто именно "идет лесом".
> И что именно считать стилем BSD? Олмана или BSD KNF?
> А также, что конкретно мешает писать в других стилях?return
{
myProperty: "myValue"
}Вот такой - по-моему, олмановский. В данном случае разбор оператора return закончится в первой же строке, т.е. совсем не так, как можно было бы предположить.
> А здесь-то в чем проблемы? Это полностью соответствует ОО-концепции.
> null - это тоже такой объект. Все правильно.Технически-то он является, но, учитывая его особое назначение, могли бы сделать исключение, ИМХО. Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом, хотя по логике означает отсутствие какого-либо значения.
> Я говорю о своем впечатлении, а не утверждаю, что язык абсолютно плох.А я тоже не говорил про "абсолютно плох".
Тем не менее я считаю, что было выявлено недостаточно проблем именно для того заявления, которое вы сделали, а не для "абсолютно плох".> Он как раз понравился мне, в нем реализованы интересные идеи ООП, но несколько пакостных моментов забыть никак не могу. Как показывает практика, язык вполне юзабелен и популярен, вот только могло бы быть и получше.
Мне тоже не нравятся "пакостные моменты" в языках. И я перебрал много языков, в надежде найти что-нибудь "получше" (еще начиная с C++). Но везде какие-нибудь да есть пакостные моменты.
Вообще, чем более популярен язык, тем больше "пакостных моментов" из желания угодить всем.
Чем менее популярен - либо вообще не подходит, либо пакостных моментов почти нет (в синтаксисе и семантике) - но хуже поддержка, стабильность, интеграция, библиотеки и т.п.> Вот такой - по-моему, олмановский. В данном случае разбор оператора return закончится в первой же строке, т.е. совсем не так, как можно было бы предположить.
Наверное таки да. Надо будет мне этот момент повнимательнее изучить.
>> А здесь-то в чем проблемы? Это полностью соответствует ОО-концепции.
>> null - это тоже такой объект. Все правильно.
> Технически-то он является, но, учитывая его особое назначение, могли бы сделать исключение, ИМХО.А вот здесь я с вами по-прежнему не согласен.
Это именно не технически.
Это именно семантика ОО-модели. Все есть объекты, включая типы, синглтоны, безтиповые константы, функции, код, даже операторы языка и т.д. и т.п. - это я не о JS, это как должно быть.> Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом, хотя по логике означает отсутствие какого-либо значения.
Если не являются, то плохо. Но насколько мне известно - являются.
Надо будет мне этот момент еще раз изучить.А как именно это проявляется, что они не объекты?
P.S. Планирую на JS перейти, в связи его развитием как полноценного языка, не привязанного к браузеру.
>> Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом, хотя по логике означает отсутствие какого-либо значения.
> Если не являются, то плохо. Но насколько мне известно - являются.
> Надо будет мне этот момент еще раз изучить.Посмотрел. Все правильно - являются.
Только там у них иерархия типов не совсем чистая.
Как в старых ОО-языках.Базовые типы не являются наследниками типа Object.
И там получается два типа для строк, один базовый, другой наследуется от Object.Жаль. :( Но жить можно. :)
Зато там очень "слабая" базовая модель (что есть хорошо), это позволяет легко "усиливать" ее в более частные случаи, не переделывая основу.
Поэтому большинство фреймворков легко реализуют свои собственные объектные модели.
(Поскольку единственно верной модели не существует.)В "слабой" модели JS - его сила.
Его удобно использовать, как метаязык.
>Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом.Это внезапно, но не вижу в этом проблемы абсолютно. Просто такая фича.
Один из моментов, который очень хочется исправить в JS ― это перегруженный оператор '+'. В сочетании с динамической типизацией и нюансами в неявном приведении типов, возникают сюрпризы и необходимости приводить типы явно.
>>Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом.
> Это внезапно, но не вижу в этом проблемы абсолютно. Просто такая фича."То не баг, то фича". Где-то я уже это слышал. )
На самом это все-таки проблема, если тщательно разрабатывается концептуальная модель какой-то задачи в теснй привязке к конкретному ОО-языку. А когда просто колбасится код, это конечно не проблема.
Однако снова внезапно они таки обратно являются. Просто модель слегка "поломана".
(Я об этом выше уже написал)> Один из моментов, который очень хочется исправить в JS ― это перегруженный оператор '+'. В сочетании с динамической типизацией и нюансами в неявном приведении типов, возникают сюрпризы и необходимости приводить типы явно.
Потому как операторы там тоже выпадают из ОО-модели. И служат лишь "синтаксическим сахаром" для новичков, которые дальше арифметики обычно не вылазят.
По мне так, если нужны полноценные операторы, то нужно брать языки с выводом типов и перегрузкой. А иначе операторов максимально избегать. И пользоваться методами.
Семантика важнее синтаксиса (при проектировании).
Хотя кодировщики очень любят синтаксис, это да.
>"То не баг, то фича". Где-то я уже это слышал. )Я тоже слышал и что?
Поясню. Это не баг типа Null или модели языка, это фича оператора typeof. Введена думаю для совместимости с каким-нибудь лохматым браузером. Если не нравится, можно определить собственную функцию, которая будет возвращать 'null'(надеюсь ваша OOP религия не запрещает этого делать =)>Потому как операторы там тоже выпадают из ОО-модели.
Да, но вы все о своем наболевшем, а моя проблема не в этом. Перегружать операторы я не хочу, и без этого язык достаточно сложный, хотя в JS 2.0 возможно будет и это счастье для ОО ортодоксов. =)
>>"То не баг, то фича". Где-то я уже это слышал. )
>
> Я тоже слышал и что?Да ничего, просто прикололся.
> Поясню. Это не баг типа Null или модели языка, это фича оператора typeof.
Ну я свое мнение сказал, а вы как хотите. Это часть объектной модели.
И typeof в ОО-языках - это не просто оператор, который выводит тип якобы только для сведения. Взаимосвязь типов - это не следствие фич оператора typeof, а наоборот, вывод оператора typeof - это следствие взаимосвязи типов (и объектов).
> Введена думаю для совместимости с каким-нибудь лохматым браузером.
Нет, не поэтому. Я объяснял уже выше. Просто в JS используется так сказать "старая школа", когда базовые типы не наследуются от типа Object.
> Если не нравится, можно определить собственную функцию, которая будет возвращать 'null'(надеюсь ваша OOP религия не запрещает этого делать =)
Во-первых, при чем здесь null? С null там все в порядке - это объект.
Во-вторых, если я знаю ООП и в состоянии объяснить откуда что берется - при чем здесь религия?>>Потому как операторы там тоже выпадают из ОО-модели.
>
> Да, но вы все о своем наболевшем, а моя проблема не в этом.Вас я в виду нигде и не имел.
"Мое" - это скорее функционально программирование. Хотя JS чистым ФЯ не является, мне он нужен для других целей.Просто так уж получилось, что ОО-модели я тоже знаю (а зная ФП и математику, в ООП разобраться не трудно), и если уж мне попадается ОО-язык, я его модели использую на "полную катушку".
> Перегружать операторы я не хочу, и без этого язык достаточно сложный, хотя в JS 2.0 возможно будет и это счастье для ОО ортодоксов. =)
А я этого и не рекомендовал.
Я лишь сказал, что если нужны операторы с полноценной поддержкой типов, то лучше использовать другие языки. А в javascript достаточно и методов.
>И typeof в ОО-языках - это не просто оператор, который выводит тип якобы только для сведения. Взаимосвязь типов - это не следствие фич оператора typeof, а наоборот, вывод оператора typeof - это следствие взаимосвязи типов (и объектов).Все так, но в качестве исключения в JS для типа Null выдает строку 'object'.
>Во-первых, при чем здесь null? С null там все в порядке - это объект.
А здесь заблуждаетесь, null принадлежит типу Null, который является тем, что вы называете старой школой, то есть не наследует от Object, иначе у него были бы свойства и методы от Object, а их нет.
Ну и на всякий случай спецификацию смотрите в разделах 4.3 и 8. Плюс к тому 11.4.3 про typeof.>Я лишь сказал, что если нужны операторы с полноценной поддержкой типов...
Просто вы это писали в ответ на мое недовольство оператором +, который может и сложение чисел и конкатенцию строк, мне оно не удобно. Только и всего, хочу отдельный оператор для конкатенции, а + только для сложения. =)
>>И typeof в ОО-языках - это не просто оператор, который выводит тип якобы только для сведения. Взаимосвязь типов - это не следствие фич оператора typeof, а наоборот, вывод оператора typeof - это следствие взаимосвязи типов (и объектов).
> Все так, но в качестве исключения в JS для типа Null выдает строку 'object'.Не знал.
Точнее я сейчас посмотрел - там typeof просто тупо выдает строки, а не ссылки на объекты типов.
(Сам тип - это тоже объект, точнее так должно быть в соответствии с религией^W моделью).Так что правильно говорить, что это не фича оператора typeof, а что typeof сам по себе является фичей, а не частью религии^W модели. То есть он ее не ломает, он в нее просто не входит.
>>Во-первых, при чем здесь null? С null там все в порядке - это объект.
> А здесь заблуждаетесь, null принадлежит типу Null, который является тем, что вы называете старой школой, то есть не наследует от Object, иначе у него были бы свойства и методы от Object, а их нет.Нет, не заблуждаюсь. Object - это просто имя некоторого типа. Если некоторые типы не наследуются от Object - это не значит, что объекты этого типа не являются полноценными объектами в соответствии с религией^W моделью.
Просто у них разные метатипы.
"Старая школа" конечно менее изящная, но общая логика не ломается, просто является более "заковыристой".И с null и его типом Null, пока по-прежнему все в порядке, он просто входит в комплект базовых типов.
Если я что-то новое об этом не узнаю.> Ну и на всякий случай спецификацию смотрите в разделах 4.3 и 8.
> Плюс к тому 11.4.3 про typeof.Мне спецификацию сейчас было лень искать, я глянул на javascript.ru
Как я уже сказал выше, typeof просто возвращает строки, а не сами типы.
Он просто весь целиком "из другой оперы".Поэтому то, что что он ведет себя с null как-то по-другому, на общую модель вообще никак не влияет.
>>Я лишь сказал, что если нужны операторы с полноценной поддержкой типов...
> Просто вы это писали в ответ на мое недовольство оператором +, который может и сложение чисел и конкатенцию строк, мне оно не удобно.
> Только и всего, хочу отдельный оператор для конкатенции, а + только для сложения. =)Так я говорю, не следует ожидать многого от операторов, если они не поддерживают общую модель типов языка, а только некоторые частные случаи.
> Просто вы это писали в ответ на мое недовольство оператором +, который может и сложение чисел и конкатенцию строк, мне оно не удобно.Только и всего, хочу отдельный оператор для конкатенции, а + только для сложения. =)
Собственно ваша жалоба на операторы имеет непосредственное отношение ко всей "религии".
Просто в ОО-ЯП "старой школы" базовые типы именно для того и предназначены, чтобы с ними работали операторы.
Кроме того, для базовых типов и Object-производных обычно реализованы разные стратегии компиляции и выделения памяти.
Именно так устроены, например, C++ и java.
Однако в C++ есть перегрузка операторов, но нет полноценного вывода типов.
> Интерпретатор JS автоматически вставляет точку с запятой по своему усмотрению (как найдет место, где оператор МОЖЕТ оканчиваться, но необязательно это делает)Непризнанный анонимус, ты не думал, что дело в том что ты не знаешь по каким правилам это делается, а зря.
Спасибо за ссылку
Жалко и страшно за наших кодеров, которые учатся писать по хабру. Почитайте что ли оригинал, там хотя бы по большей части понятно, что автор сказать хотел http://inimino.org/~inimino/blog/javascript_semicolons
Хотя он все равно не прав и точку с запятой надо ставить везде.
> сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности"Исторически так и сложилось, в общем-то
Вынужден вас огорчить, но в Tcl тоже, как и в множестве других скриптовых языков, конец строки ограничивает отдельную команду (если не предпринять специальные меры для продолжения).
В Tcl это не настолько неудобно, он ведь "Tool Command Language" - командный язык, напоминающий shell, а команда располагается в одной строке, т.е. для программиста это более-менее логично, а вот JavaScript здорово напоминает C, для которого это не характерно
Ну так это исключительно проблема тех, кто [слаще морковки не едал] кроме C языков не видал. Языков, в которых конец строки является значащим, едва ли не больше, чем тех, в которых обратное.
> одни "точки с запятой по умолчанию" чего стоят.как раз точки с запятой это не проблема
http://test-semicolon.narod.ru/
а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
>> одни "точки с запятой по умолчанию" чего стоят.
> как раз точки с запятой это не проблема
> http://test-semicolon.narod.ru/Это все-таки проблема, потому что может вызвать неоднозначность.
И сравнения с Python там совершенно неуместны.В любом случае это надо трансляцию анализировать для таких суждений.
А не с помощью таких быдлокодерских тестов, где авторы сами не понимают, о чем рассуждают. Только сами язык позорят.
> а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
Ну и какие это проблемы?
Нужен другой язык? Так берите другой язык.
какая такая неоднозначность?что такого неоднозначного в
function test_semicolon_core() {
return
true;
};> И сравнения с Python там совершенно неуместны.
неуместно потомучто в Python кроме ";" если и другие аспекты (например в Python косая-черта перед знаком-новой-строки -- вместо этой конструкции в ECMAScript используется просто знак-новой-строки) ...
...но в целом для общего представления -- думаю вполне сгодиться
> какая такая неоднозначность?
> что такого неоднозначного в
>
> function test_semicolon_core() {
> return
> true;
> };
>Мда... Видимо у вас неоднозначное понимание самого понятия "неоднозначность".
>> И сравнения с Python там совершенно неуместны.
> неуместно потомучто в Python кроме ";" если и другие аспекты (например косая-черта перед знаком-новой-строки) ...То есть именно в этом вы видите основные отличия Python от JS.
> ...но в целом для общего представления -- думаю вполне сгодиться
"И так сойдет!" - девиз быдлокодеров.
Не надо путать "общее представление" с представлением принципиально неправильным.
> То есть именно в этом вы видите основные отличия Python от JS.у вас какаято хитрая игра слов
да -- всё верно -- языки различаются меду собой различными аспектами .. и ИМЕННО В ЭТИХ РАЗЛИЧНЫХ АСПЕКТАХ -- их основное различие ...
...что вам тут показалось странным?
>> То есть именно в этом вы видите основные отличия Python от JS.
>
> у вас какаято хитрая игра словГде?
> да -- всё верно -- языки различаются меду собой различными аспектами ..
и ИМЕННО В ЭТИХ РАЗЛИЧНЫХ АСПЕКТАХ -- их основное различие ...
Это все равно что сказать, что основное различие в различных различиях.
Тавтология.> ...что вам тут показалось странным?
То что "косую черту" поставили, как первое отличие, после ";".
> "И так сойдет!" - девиз быдлокодеров.очень интересно спорить с человеком который говорит "вы гавно" ("вы быдлокодер") , но никак это не обосновывает
Я ЧТОЛЕ ВИНОВАТ В ТОМ ЧТО ECMASCRIPT ИНТЕРПРЕТИРУЕТ ИНСТРУКЦИИ -- ТАК КАК ОНА ИХ ИНТЕРПРЕТИРУЕТ?
(если вы намекаете на то что я не правильно объяснил как оно их интерпретирует -- тык я и не заявлял ПРО ВСЮ ШИРИНУ изложения. Я РАССКАЗАЛ ПРО ОСНОВЫ а дальше разбирайтесь сами... НО КАК МИНИМУМ ЗНАЙТЕ ХОТЯБЫ ОСНОВЫ)
>> "И так сойдет!" - девиз быдлокодеров.
> очень интересно спорить с человеком который говорит "вы гавно" ("вы быдлокодер") ,Я нигде не говорил "вы быдлокодер"
> но никак это не обосновывает
А вот как раз я указал некоторые критерии.
То есть опять получается все наоборот.
> Я ЧТОЛЕ ВИНОВАТ В ТОМ ЧТО ECMASCRIPT ИНТЕРПРЕТИРУЕТ ИНСТРУКЦИИ -- ТАК КАК ОНА ИХ ИНТЕРПРЕТИРУЕТ?
Ой как громко!
Каким образом вы связали интерпретацию инструкций с вашей виной (или ее отсутствием)?> (если вы намекаете на то что я не правильно объяснил как оно их интерпретирует
Почему вы решили, что я именно на это намекаю?
> -- тык я и не заявлял ПРО ВСЮ ШИРИНУ изложения.
Что такое "ширина изложения"?
> Я РАССКАЗАЛ ПРО ОСНОВЫ а дальше разбирайтесь сами... НО КАК МИНИМУМ ЗНАЙТЕ ХОТЯБЫ ОСНОВЫ)
То есть то, о чем вы говорили вы считаете основами?
Вы думаете, что если писать капсом, то будет более убедительно?
>> а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
> Ну и какие это проблемы?
> Нужен другой язык? Так берите другой язык.каким образом я могу взять другой язык? :-)
...у менято возникает ощущение что W3C меня гвоздями прибило к ECMAScript :-D
> а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
>> Ну и какие это проблемы?
>> Нужен другой язык? Так берите другой язык.
> каким образом я могу взять другой язык? :-)
> ...у менято возникает ощущение что W3C меня гвоздями прибило к ECMAScript :-DНу так попробуйте оторваться от W3C.
"Keep it simple, stupid!" (C)
Что вообще для вас такое язык?
> А не с помощью таких быдлокодерских тестов, где авторы сами не понимают, о чем рассуждают.если "авторы" не умничают цытатами из спецификации ECMAScript это ещё не обозначает что они не знают о чём рассуждают
...сложно выразитсья любой дурак может, а ты попробуй попростому чтото объяснить
вот я представил ПРОСТОЙ тест .. и после этого ПРОСТОГО теста всё сразу становиться ясно... а теперь можешь умничать сколько хочешь :-)
Вы просто путаете сложность/простоту с трудностью/легкостью(понятностью).Большинство понятного для большинства обычно бывает очень сложным.
А простые вещи большинству бывают непонятны.А вот спецификации ECMAScript авторам этого теста действительно почитать было бы полезно.
И спецификации Питона в том числе.
> А вот спецификации ECMAScript авторам этого теста действительно почитать было бы полезно.
> И спецификации Питона в том числе.тоесть -- вы всёже щитаете что разделение инструкци через ";" в ECMAScript -- ближе к C/C++ чем к Python?
# p.s.: то что не точ-в-точ никто и не спорит (в этих трёх языках -- разные механизмы)... но к чему ближе -- к C/C++ или к Python?
>> А вот спецификации ECMAScript авторам этого теста действительно почитать было бы полезно.
>> И спецификации Питона в том числе.
> тоесть -- вы всёже щитаете что разделение инструкци через ";" в ECMAScript -- ближе к C/C++ чем к Python?А вы "щитаете". что если есть неоднозначность в разделени инструкций и строк, то это делает язык ближе к C/C++?
> # p.s.: то что не точ-в-точ никто и не спорит (в этих трёх языках -- разные механизмы)...
Очень ценное наблюдение, что они не "точ-в-точ".
А разные "механизмы" могут быть даже в разных реализациях одного языка.> но к чему ближе -- к C/C++ или к Python?
Вы считаете это самым главным фактором - быть ближе к C/C++ или к Python?
Оторвать веб от JS конечно было бы неплохо. Но смотря какими методами.
Tcl, насколько я знаю, интерпретируемый язык, и если пихать в браузер ещё один интерпретатор, то лучше пусть веб останется в руках js. Другое дело если он будет компилится в код для этой NaCl и отдаваться с сервера уже скомпиленым, тогда это была бы хорошая идея, и думаю tcl не был бы последним языком на котором реализовали этот webAPI(?) для NaCl.
> Оторвать веб от JS конечно было бы неплохо. Но смотря какими методами.А меня гораздо больше радует, что JS сейчас от веба отрывают.
> Tcl, насколько я знаю, интерпретируемый язык, и если пихать в браузер ещё один интерпретатор, то лучше пусть веб останется в руках js.
Все равно все к этому придет.
Точнее, я думаю, сами браузеры не смогут до бесконечности пухнуть и поддерживать все-все-все протоколы, которые есть в вебе. И все вернется опять к более узко-специализированным клиентам. Как сейчас происходит распад концепции ПК на микропроцессорные системы более специализированного назначения.
Точнее, настольный ПК становится скорее инструментом профессионалов, а пользователи переползают на менее универсальные всякие там смарт-буки.
Так же и универсальные веб-клиенты постепенно станут не массовыми, а профессиональными инструментами.
> Другое дело если он будет компилится в код для этой NaCl и отдаваться с сервера уже скомпиленым, тогда это была бы хорошая идея, и думаю tcl не был бы последним языком на котором реализовали этот webAPI(?) для NaCl.
А это все мелкие частности.
Ну, сам тикль - он на любителя. Основной интерес - что привлекается внимание к NaCl лишний раз. Ну и есть ценители, которые считают, что у тикля масса преимуществ переддругими языками - может они и правы, не знаю.
Новые тормоза для браузеров, новые глюки и дыры в браузерах
На Tcl нефтяные платформы вполне работают, и ничего. В нем изначально встроен механизм песочниц - подчиненных интерпретаторов, в которых потенциально опасные команды не работают или перехватываются. Вообще сам язык очень простой, что снижает количество нюансов к минимуму
Осталось только NaCl стандартизировать на *всех* платформах/браузерах.
В Хром да Фирефокс встроят - уже половина аудитории, останется написать стандарт. HTML5 как утвержденный стандарт, кажется, еще не существует, но вряд ли это кому мешает реализовывать его фичи
В Мозилле и ИЕ тикль встраивался ещё много лет назад. http://www.tcl.tk/software/plugin/Хром просто слишком молодой браузер. Теперь и в нём есть тикль.
>Осталось только NaCl стандартизировать на *всех* платформах/браузерах.И что тогда произойдет?
И тогда веб будет избавлен от необходимости писать всё на JS. Взамен этого можно будет спокойно выбирать для проекта тот язык, который наиболее подходит для данного случая. Я уж не говорю о том, что это даст возможность даже из того же JS пользоваться готовыми эффективными библиотеками на массе языков - начиная с вычислений и заканчивая шифрованием с желаемым алгоритмом. Даст возможность эффективного парсинга разнообразных wire-форматов вроде Msgpack, что упрощает взаимодействие с уже написанным софтом. Также это даст возможность легкого портирования нативных приложений - так, как сейчас происзодит в андроиде: берём натив, прикручиваем к нему морду на жабе - вуаля, порт готов. Deadbeef именно так на андроиде работает, к примеру.
Классный язык. Вот только не мешало бы сунуть в него пару удобств, например, сделать слегка более лаконичным синтаксис для списков/словарей
люжка дёгтяhttps://bugs.launchpad.net/ubuntu/+source/chromium-browser/+... [ http://bit.ly/gKEgVq ]
Зато как здорово он будет , по Tcl-евски, тормозить в современных браузерах... Ностальгия!
> Зато как здорово он будет , по Tcl-евски, тормозить в современных браузерах...
> Ностальгия!Это не проблема языка, это проблема реализации.
Да и tcl сейчас уже давно не тормозит.
Хм. Вообще-то Tcl встраивают в браузеры уже более десяти лет (начало разработки 97 год). http://www.tcl.tk/software/plugin/ В тикле даже режимм специальный безопасный есть, чтобы запускать скрипты без угрозы локальным файлам и другим данным.Новость же, я так понимаю, о том, что, появилась ещё одна реализация встравивания Tcl, теперь и для Chrome.
safe tcl старше Джавы. Sun в свое время решала что продвигать Java или safe TCL/TK выбрала Java. Печально для тех кто морды писал на Tk...
"Java должен сгинуть" (с)Веление времени.А вообще - чем больше будет инструментов, тем лучше.
Tcl? Лучше бы Lua встроили.