The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Язык Tcl адаптирован для выполнения скриптов внутри веб-браузера

18.04.2011 14:21

В списке рассылки разработчиков языка программирования Tcl представлен проект NaTcl, в рамках которого выполнена работа по адаптации среды для запуска Tcl-скриптов внутри веб-браузера, позволяющая создавать выполняемые на стороне клиента web-приложения не только на языке JavaScript. NaTcl предоставляет приложениям прямой доступ к DOM-дереву объектов браузера, поддерживает обработку событий, предоставляя похожий на JavaScript арсенал средств.

Интеграция Tcl с браузером выполнена благодаря использованию наработок проекта Native Client, в рамках которого компанией Google развивается платформа для создания универсальных web-приложений, написанных на языке C/C++ и использующих специальный API для выполнения свойственных web-приложениям действий. При помощи Native Client можно организовать выполнение обычных бинарных программ в окне web-браузера, ограничив их при помощи специального изолированного окружения.

Из веб-браузеров пока поддерживается только Google Chrome 10. В качестве примера представлено небольшое демонстрационное приложение, представляющее собой переписанный на языке Tcl вариант JavaScript программы "Google Balls", показывающей как можно манипулировать графическими объектами с привлечением HTML5-тега "canvas".

В настоящее время разработчики занимаются адаптацией для работы под управлением Native Client технологии WebTk, что позволит создавать web-приложения с использованием всех возможностей графического тулкита Tk. Конечной целью проекта является обеспечение полной эмуляции всех возможностей Tk при работе внутри браузера.

  1. Главная ссылка к новости (http://www.theregister.co.uk/2...)
  2. OpenNews: Доступен релиз обновленного инструментария Native Client
  3. OpenNews: Для разработки web-приложений на базе Native Client выпущен специальный SDK
  4. OpenNews: Native Client портирован для архитектур ARM и x86-64
  5. OpenNews: Компания Google представила победителей соревнования по взлому Native Client
  6. OpenNews: Компания Google выпустила средство для выполнения бинарных программ в браузере
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30279-tcl
Ключевые слова: tcl, web, nativeclient
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (60) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Анонимка (?), 15:47, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Обалдеть!
    Еще бы Lisp прикрутили и Erlang :)
     
     
  • 2.4, ХРЕН (?), 16:03, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Обалдеть!
    > Еще бы Lisp прикрутили и Erlang :)

    И Brainfuck !!!

     
  • 2.5, Аноним (-), 16:29, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Обалдеть!
    > Еще бы Lisp прикрутили и Erlang :)

    А вы видите такого в этих вариантах, которые вы предложили?
    Если вы каких-то языков не знаете, это еще не значит, что эти языки такие плохие.

     
     
  • 3.15, Анонимка (?), 19:27, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я наоборот, только за, и считаю эти языки полезными.
     

  • 1.2, маммон (?), 16:00, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какие из проблем Javascript в целом и DOM в частности решает этот проект?
     
     
  • 2.3, ХРЕН (?), 16:03, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Наоборот, к проблемам Javascript добавляются еще и проблемы TCL :)
     
     
  • 3.6, Аноним (-), 16:31, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Наоборот, к проблемам Javascript добавляются еще и проблемы TCL :)

    Проблемы есть в любых языках.
    Просто вы скорее всего о них не знаете, и просто так от балды решили написать.

     
  • 2.8, Crazy Alex (??), 18:00, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    От всех проблем javascipt :-)

    А если серьёзно - оторвать веб-приложения от JS было бы очень вкусно. Начиная с идеологических соображений - не стоит навязывать один вариант действий всем - и заканчивая тем, что JS, вообще-то, язык с проблемами - одни "точки с запятой по умолчанию" чего стоят.

    Но основной плюс, конечно - то, что сама идея NaCl потихоньку распространяется. Всё же лучше, когда html-документ четко отделен от приложения, и раз flash не сумел  завоевать достаточную популярность в этом плане - возможно, NaCl сможет.

     
     
  • 3.12, angra (ok), 18:33, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >JS, вообще-то, язык с проблемами - одни "точки с запятой по умолчанию" чего стоят.

    Не могли бы вы развернуть свою мысль. Чем не угодила точка с запятой в качестве разделителя операций?

    Ну а по теме, количество кодеров js превышает кодеров tcl на несколько порядков. В свое время не получили распространение VBScript и PerlScript, не смотря на поддержку в древних браузерах. А ведь на то время куда более распространенные языки. Как по мне мертворожденный проект.

     
     
  • 4.14, Аноним (-), 19:03, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Интерпретатор JS автоматически вставляет точку с запятой по своему усмотрению (как найдет место, где оператор МОЖЕТ оканчиваться, но необязательно это делает), благодаря чему повышается риск ошибок. Плюс любители стиля BSD идут лесом, только K&R.
    Вообще после изучения JS у меня осталось впечатление, что ECMA сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности": typeof (null) == object, опасный оператор with, почти бесполезны
     
     
  • 5.21, pr (?), 20:05, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Интерпретатор 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 сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности":

    Все таки чтобы заявлять такое, вы все-таки пока указали слишком мало недочетов. Либо нужно показать, в каких языках подобных проблем меньше.

     
     
  • 6.36, Аноним (-), 21:01, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я говорю о своем впечатлении, а не утверждаю, что язык абсолютно плох Он как ра... большой текст свёрнут, показать
     
     
  • 7.46, pr (?), 21:59, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А я тоже не говорил про абсолютно плох Тем не менее я считаю, что было выявле... большой текст свёрнут, показать
     
     
  • 8.50, pr (?), 22:17, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрел Все правильно - являются Только там у них иерархия типов не совсем ч... текст свёрнут, показать
     
  • 7.52, filosofem (ok), 22:38, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Кроме того, в JavaScript не все является объектами, есть еще строки, числа и undefined, а вот null внезапно оказывается объектом.

    Это внезапно, но не вижу в этом проблемы абсолютно. Просто такая фича.

    Один из моментов, который очень хочется исправить в JS ― это перегруженный оператор '+'. В сочетании с динамической типизацией и нюансами в неявном приведении типов, возникают сюрпризы и необходимости приводить типы явно.

     
     
  • 8.53, pr (?), 23:06, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    То не баг, то фича Где-то я уже это слышал На самом это все-таки проблема,... текст свёрнут, показать
     
     
  • 9.54, filosofem (ok), 01:44, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже слышал и что Поясню Это не баг типа Null или модели языка, это фича опе... текст свёрнут, показать
     
     
  • 10.55, pr (?), 02:47, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да ничего, просто прикололся Ну я свое мнение сказал, а вы как хотите Это част... текст свёрнут, показать
     
     
  • 11.56, filosofem (ok), 04:43, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Все так, но в качестве исключения в JS для типа Null выдает строку object А з... текст свёрнут, показать
     
     
  • 12.60, pr (?), 21:05, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не знал Точнее я сейчас посмотрел - там typeof просто тупо выдает строки, а не ... большой текст свёрнут, показать
     
  • 12.61, pr (?), 22:02, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Только и всего, хочу отдельный оператор для конкатенции, а только для сложения... текст свёрнут, показать
     
  • 5.34, szh (ok), 20:57, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интерпретатор JS автоматически вставляет точку с запятой по своему усмотрению (как найдет место, где оператор МОЖЕТ оканчиваться, но необязательно это делает)

    Непризнанный анонимус, ты не думал, что дело в том что ты не знаешь по каким правилам это делается, а зря.  

    Вперед http://habrahabr.ru/blogs/javascript/111563/

     
     
  • 6.40, Аноним (-), 21:11, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо за ссылку
     
     
  • 7.49, filosofem (ok), 22:13, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Жалко и страшно за наших кодеров, которые учатся писать по хабру. Почитайте что ли оригинал, там хотя бы по большей части понятно, что автор сказать хотел http://inimino.org/~inimino/blog/javascript_semicolons
    Хотя он все равно не прав и точку с запятой надо ставить везде.
     
  • 5.41, анонимм (?), 21:17, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > сначала накатала полурабочий интерпретер, а потом стандартизировала все его недочеты как "особенности"

    Исторически так и сложилось, в общем-то

     
  • 5.47, gegMOPO4 (ok), 22:02, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вынужден вас огорчить, но в Tcl тоже, как и в множестве других скриптовых языков, конец строки ограничивает отдельную команду (если не предпринять специальные меры для продолжения).
     
     
  • 6.62, Аноним (-), 16:35, 20/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В Tcl это не настолько неудобно, он ведь "Tool Command Language" - командный язык, напоминающий shell, а команда располагается в одной строке, т.е. для программиста это более-менее логично, а вот JavaScript здорово напоминает C, для которого это не характерно
     
     
  • 7.63, gegMOPO4 (ok), 17:12, 20/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так это исключительно проблема тех, кто [слаще морковки не едал] кроме C языков не видал. Языков, в которых конец строки является значащим, едва ли не больше, чем тех, в которых обратное.
     
  • 3.22, Аноним123321 (ok), 20:10, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > одни "точки с запятой по умолчанию" чего стоят.

    как раз точки с запятой это не проблема

    http://test-semicolon.narod.ru/

    а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)

     
     
  • 4.24, pr (?), 20:30, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> одни "точки с запятой по умолчанию" чего стоят.
    > как раз точки с запятой это не проблема
    > http://test-semicolon.narod.ru/

    Это все-таки проблема, потому что может вызвать неоднозначность.
    И сравнения с Python там совершенно неуместны.

    В любом случае это надо трансляцию анализировать для таких суждений.

    А не с помощью таких быдлокодерских тестов, где авторы сами не понимают, о чем рассуждают. Только сами язык позорят.

    > а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)

    Ну и какие это проблемы?
    Нужен другой язык? Так берите другой язык.

     
     
  • 5.28, Аноним123321 (ok), 20:46, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    какая такая неоднозначность?

    что такого неоднозначного в




    function test_semicolon_core() {
        return
            true;
    };


    > И сравнения с Python там совершенно неуместны.

    неуместно потомучто в Python кроме ";" если и другие аспекты (например в Python косая-черта перед знаком-новой-строки -- вместо этой конструкции в ECMAScript используется просто знак-новой-строки) ...

    ...но в целом для общего представления -- думаю вполне сгодиться

     
     
  • 6.31, pr (?), 20:53, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > какая такая неоднозначность?
    > что такого неоднозначного в
    >


    > function test_semicolon_core() {
    >     return
    >         true;
    > };
    >

    Мда... Видимо у вас неоднозначное понимание самого понятия "неоднозначность".

    >> И сравнения с Python там совершенно неуместны.
    > неуместно потомучто в Python кроме ";" если и другие аспекты (например косая-черта перед знаком-новой-строки) ...

    То есть именно в этом вы видите основные отличия Python от JS.

    > ...но в целом для общего представления -- думаю вполне сгодиться

    "И так сойдет!" - девиз быдлокодеров.
    Не надо путать "общее представление" с представлением принципиально неправильным.

     
     
  • 7.35, Аноним123321 (ok), 20:59, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть именно в этом вы видите основные отличия Python от JS.

    у вас какаято хитрая игра слов

    да -- всё верно -- языки различаются меду собой различными аспектами .. и ИМЕННО В ЭТИХ РАЗЛИЧНЫХ АСПЕКТАХ -- их основное различие ...

    ...что вам тут показалось странным?

     
     
  • 8.43, debugger (ok), 21:30, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Где и ИМЕННО В ЭТИХ РАЗЛИЧНЫХ АСПЕКТАХ -- их основное различие Это все рав... текст свёрнут, показать
     
  • 7.38, Аноним123321 (ok), 21:04, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > "И так сойдет!" - девиз быдлокодеров.

    очень интересно спорить с человеком который говорит "вы гавно" ("вы быдлокодер") , но никак это не обосновывает

    Я ЧТОЛЕ ВИНОВАТ В ТОМ ЧТО ECMASCRIPT ИНТЕРПРЕТИРУЕТ ИНСТРУКЦИИ -- ТАК КАК ОНА ИХ ИНТЕРПРЕТИРУЕТ?

    (если вы намекаете на то что я не правильно объяснил как оно их интерпретирует -- тык я и не заявлял ПРО ВСЮ ШИРИНУ изложения. Я РАССКАЗАЛ ПРО ОСНОВЫ а дальше разбирайтесь сами... НО КАК МИНИМУМ ЗНАЙТЕ ХОТЯБЫ ОСНОВЫ)

     
     
  • 8.42, debugger (ok), 21:20, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Я нигде не говорил вы быдлокодер А вот как раз я указал некоторые критерии То... текст свёрнут, показать
     
  • 5.30, Аноним123321 (ok), 20:51, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
    > Ну и какие это проблемы?
    > Нужен другой язык? Так берите другой язык.

    каким образом я могу взять другой язык? :-)

    ...у менято возникает ощущение что W3C меня гвоздями прибило к ECMAScript :-D

     
     
  • 6.33, pr (?), 20:56, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а вот всякие излишние скобочки "(){}" и длинные конструкции -- да -- это проблема :-)
    >> Ну и какие это проблемы?
    >> Нужен другой язык? Так берите другой язык.
    > каким образом я могу взять другой язык? :-)
    > ...у менято возникает ощущение что W3C меня гвоздями прибило к ECMAScript :-D

    Ну так попробуйте оторваться от W3C.
    "Keep it simple, stupid!" (C)
    Что вообще для вас такое язык?

     
  • 5.32, Аноним123321 (ok), 20:56, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А не с помощью таких быдлокодерских тестов, где авторы сами не понимают, о чем рассуждают.

    если "авторы" не умничают цытатами из спецификации ECMAScript это ещё не обозначает что они не знают о чём рассуждают

    ...сложно выразитсья любой дурак может, а ты попробуй попростому чтото объяснить

    вот я представил ПРОСТОЙ тест .. и после этого ПРОСТОГО теста всё сразу становиться ясно... а теперь можешь умничать сколько хочешь :-)

     
     
  • 6.37, pr (?), 21:01, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Вы просто путаете сложность/простоту с трудностью/легкостью(понятностью).

    Большинство понятного для большинства обычно бывает очень сложным.
    А простые вещи большинству бывают непонятны.

    А вот спецификации ECMAScript авторам этого теста действительно почитать было бы полезно.
    И спецификации Питона в том числе.

     
     
  • 7.39, Аноним123321 (ok), 21:08, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот спецификации ECMAScript авторам этого теста действительно почитать было бы полезно.
    > И спецификации Питона в том числе.

    тоесть -- вы всёже щитаете что разделение инструкци через ";" в ECMAScript -- ближе к C/C++ чем к Python?

    # p.s.: то что не точ-в-точ никто и не спорит (в этих трёх языках -- разные механизмы)... но к чему ближе -- к C/C++ или к Python?

     
     
  • 8.44, debugger (ok), 21:36, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А вы щитаете что если есть неоднозначность в разделени инструкций и строк, то... текст свёрнут, показать
     
  • 3.26, ascrzy (?), 20:35, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Оторвать веб от JS конечно было бы неплохо. Но смотря какими методами.
    Tcl, насколько я знаю, интерпретируемый язык, и если пихать в браузер ещё один интерпретатор, то лучше пусть веб останется в руках js. Другое дело если он будет компилится в код для этой NaCl и отдаваться с сервера уже скомпиленым, тогда это была бы хорошая идея, и думаю tcl не был бы последним языком на котором реализовали этот webAPI(?) для NaCl.
     
     
  • 4.29, pr (?), 20:48, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Оторвать веб от JS конечно было бы неплохо. Но смотря какими методами.

    А меня гораздо больше радует, что JS сейчас от веба отрывают.

    > Tcl, насколько я знаю, интерпретируемый язык, и если пихать в браузер ещё один интерпретатор, то лучше пусть веб останется в руках js.

    Все равно все к этому придет.

    Точнее, я думаю, сами браузеры не смогут до бесконечности пухнуть и поддерживать все-все-все протоколы, которые есть в вебе. И все вернется опять к более узко-специализированным клиентам. Как сейчас происходит распад концепции ПК на микропроцессорные системы более специализированного назначения.

    Точнее, настольный ПК становится скорее инструментом профессионалов, а пользователи переползают на менее универсальные всякие там смарт-буки.

    Так же и универсальные веб-клиенты постепенно станут не массовыми, а профессиональными инструментами.

    > Другое дело если он будет компилится в код для этой NaCl и отдаваться с сервера уже скомпиленым, тогда это была бы хорошая идея, и думаю tcl не был бы последним языком на котором реализовали этот webAPI(?) для NaCl.

    А это все мелкие частности.

     
  • 4.59, Crazy Alex (??), 14:52, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, сам тикль - он на любителя. Основной интерес - что привлекается внимание к NaCl лишний раз. Ну и есть ценители, которые считают, что у тикля масса преимуществ переддругими языками - может они и правы, не знаю.
     

  • 1.10, Cybister (?), 18:15, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Новые тормоза для браузеров, новые глюки и дыры в браузерах
     
     
  • 2.17, Аноним (-), 19:55, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На Tcl нефтяные платформы вполне работают, и ничего. В нем изначально встроен механизм песочниц - подчиненных интерпретаторов, в которых потенциально опасные команды не работают или перехватываются. Вообще сам язык очень простой, что снижает количество нюансов к минимуму
     

  • 1.16, Толстый (ok), 19:45, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Осталось только NaCl стандартизировать на *всех* платформах/браузерах.
     
     
  • 2.18, Аноним (-), 19:57, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В Хром да Фирефокс встроят - уже половина аудитории, останется написать стандарт. HTML5 как утвержденный стандарт, кажется, еще не существует, но вряд ли это кому мешает реализовывать  его фичи
     
     
  • 3.48, gegMOPO4 (ok), 22:05, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В Мозилле и ИЕ тикль встраивался ещё много лет назад. http://www.tcl.tk/software/plugin/

    Хром просто слишком молодой браузер. Теперь и в нём есть тикль.

     
  • 2.51, filosofem (ok), 22:18, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Осталось только NaCl стандартизировать на *всех* платформах/браузерах.

    И что тогда произойдет?

     
     
  • 3.58, Crazy Alex (??), 14:48, 19/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И тогда веб будет избавлен от необходимости писать всё на JS. Взамен этого можно будет спокойно выбирать для проекта тот язык, который наиболее подходит для данного случая. Я уж не говорю о том, что это даст возможность даже из того же JS пользоваться готовыми эффективными библиотеками на массе языков - начиная с вычислений и заканчивая шифрованием с желаемым алгоритмом. Даст возможность эффективного парсинга разнообразных wire-форматов вроде Msgpack, что упрощает взаимодействие с уже написанным софтом. Также это даст возможность легкого портирования нативных приложений - так, как сейчас происзодит в андроиде: берём натив, прикручиваем к нему морду на жабе - вуаля, порт готов. Deadbeef именно так на андроиде работает, к примеру.
     

  • 1.20, Аноним (-), 20:01, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Классный язык. Вот только не мешало бы сунуть в него пару удобств, например, сделать слегка более лаконичным синтаксис для списков/словарей
     
  • 1.23, Аноним123321 (ok), 20:25, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    люжка дёгтя

    https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/738331 [ http://bit.ly/gKEgVq ]

     
  • 1.25, Pilat (ok), 20:33, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зато как здорово он будет , по Tcl-евски, тормозить в современных браузерах... Ностальгия!
     
     
  • 2.27, pr (?), 20:36, 18/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато как здорово он будет , по Tcl-евски, тормозить в современных браузерах...
    > Ностальгия!

    Это не проблема языка, это проблема реализации.
    Да и tcl сейчас уже давно не тормозит.

     

  • 1.45, gegMOPO4 (ok), 21:59, 18/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм. Вообще-то Tcl встраивают в браузеры уже более десяти лет (начало разработки 97 год). http://www.tcl.tk/software/plugin/ В тикле даже режимм специальный безопасный есть, чтобы запускать скрипты без угрозы локальным файлам и другим данным.

    Новость же, я так понимаю, о том, что, появилась ещё одна реализация встравивания Tcl, теперь и для Chrome.

     
     
  • 2.64, alexr (??), 02:37, 21/04/2011 [^] [^^] [^^^] [ответить]  
  • +/
    safe tcl старше Джавы. Sun в свое время решала что продвигать Java или safe TCL/TK выбрала Java. Печально для тех кто морды писал на Tk...
     

  • 1.57, iCat (ok), 12:32, 19/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Java должен сгинуть" (с)Веление времени.

    А вообще - чем больше будет инструментов, тем лучше.

     
  • 1.65, Аноним (-), 21:20, 29/04/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Tcl? Лучше бы Lua встроили.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру