Здравствуйте, FR, Вы писали:
FR>Существование и достаточная популярность таких же трансляторов для питона: FR>Показывает что дело не только и не столько в динамической типизации. FR>Скорее виноваты другие особенности JavaScript и его общая далекость от мейнстримных языков вообще.
И в этом тоже. Общую далекость предлагаю исправить сахаром типа кофесрипта.
Здравствуйте, Ziaw, Вы писали:
Z>Сейчас с ними тоже никак. Ты смотришь с точки зрения ортодоксальной типизации. А я хочу ее использовать только там, где она меньше мешает, чем помогает. Проверки на соответствие типу для выполнения в рантайме придется писать явно.
От-от.
[c#]
var duck = (Duck)hunter;
hunter2.Shoot(duck);
[c#]
Или пишем проверки в Shoot (и в прочих методах), или ой. На тру-статическую типизацию это ну совсем не похоже.
Z>Еще раз. Динамика никуда не девается, она остается в шаговой доступности.
Так я только за Вопрос — как быть с существующими библиотеками под яваскрипт?
Z>Если ты хочешь описать сигнатуру метода $.ajax() — пожалуйста, если не хочешь, компилятор попробует вывести сам либо переделает в динамику.
А вот это как раз неправильно. Или у нас статическая типизация везде и мы явно указываем dynamic, когда он нужен, или мы опять скатываемся к тотальному покрытию тестами ради нахождения неверно названной переменной.
Z>Тем не менее в очень большом сегменте альтернативы ему не предвидится.
Угу, но это весьма специфический сегмент — "жертвуем качеством ради массовости".
Z>Не надо сгущать краски. Далеко не всем требуется UI в стиле десктопа (контейнеры, докинг), это вообще годится только для ентерпрайз оперденей.
Из того, что открыто сейчас (студию и ко так и быть опустим) — acrobat reader, golden dict, opera, paint.net, qip — ничуть не страдают от наличия вышеперечисленного. Я бы сказал — наоборот
Здравствуйте, Ziaw, Вы писали:
Z>Еще раз. Динамика никуда не девается, она остается в шаговой доступности. Джаваскрипт тут не в роли ассемблера, а в роли основного языка. Просто припудрен сахаром и конструкциями помогающими выводу типов. Если ты хочешь описать сигнатуру метода $.ajax() — пожалуйста, если не хочешь, компилятор попробует вывести сам либо переделает в динамику.
Создатели PyPy примерно так и сделали создав для питона статически типизированное (вывод типов + аннотации в виде декораторов и вызовов псевдофункций) подмножество питона — RPython.
Z>>Сейчас с ними тоже никак. Ты смотришь с точки зрения ортодоксальной типизации. А я хочу ее использовать только там, где она меньше мешает, чем помогает. Проверки на соответствие типу для выполнения в рантайме придется писать явно. S>От-от. S>[c#] S>var duck = (Duck)hunter;
S>hunter2.Shoot(duck); S>[c#] S>Или пишем проверки в Shoot (и в прочих методах), или ой. На тру-статическую типизацию это ну совсем не похоже.
Строгой (не статической) типизации вполне достаточно. См. Erlang
Здравствуйте, FR, Вы писали:
FR>Создатели PyPy примерно так и сделали создав для питона статически типизированное (вывод типов + аннотации в виде декораторов и вызовов псевдофункций) подмножество питона — RPython.
Вобщем да, это именно то, что не помешало сделать для js.
Здравствуйте, Sinix, Вы писали:
S>От-от. S>[c#] S>var duck = (Duck)hunter;
S>hunter2.Shoot(duck); S>[c#] S>Или пишем проверки в Shoot (и в прочих методах), или ой. На тру-статическую типизацию это ну совсем не похоже.
Это вообще не похоже на статическую типизацию. Для утиной типизации это будет похоже на использование C# dynamic без dynamic.
S>А вот это как раз неправильно. Или у нас статическая типизация везде и мы явно указываем dynamic, когда он нужен, или мы опять скатываемся к тотальному покрытию тестами ради нахождения неверно названной переменной.
Если мы не указываем типы явно и не можем вывести это будет функция params array[object] -> object
S>Из того, что открыто сейчас (студию и ко так и быть опустим) — acrobat reader, golden dict, opera, paint.net, qip — ничуть не страдают от наличия вышеперечисленного. Я бы сказал — наоборот
А из открытых сайтов многие такой подход используют? Фреймворков для эмуляции десктопного UI хватает. В том же extjs есть даже приличное IDE для формоклепания.
Здравствуйте, Ziaw, Вы писали:
Z>Это вообще не похоже на статическую типизацию. Для утиной типизации это будет похоже на использование C# dynamic без dynamic.
Ну да. Я ведь правильно понял, что именно такой подход вы и предлагаете вот тут:
Проверки на соответствие типу для выполнения в рантайме придется писать явно.
?
Z>Если мы не указываем типы явно и не можем вывести это будет функция params array[object] -> object
Ну да. Следовательно, мы можем ошибиться в количестве/типах параметров и (при известном везении) узнать об этом только на третью неделю продакшна
Z>А из открытых сайтов многие такой подход используют? Фреймворков для эмуляции десктопного UI хватает. В том же extjs есть даже приличное IDE для формоклепания.
Да никто почти
Здравствуйте, vsb, Вы писали:
vsb>Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг над всей абсурдностью сегодняшних веб-технологий.
Слишком тонкий.
Я временами гадаю, до какого еще абсурда сможет дойти развитие новейших эффективных технологий. Но моей извращенности для этого не хватает.
Здравствуйте, Sinix, Вы писали:
S>Ну да. Я ведь правильно понял, что именно такой подход вы и предлагаете вот тут: S>
S>Проверки на соответствие типу для выполнения в рантайме придется писать явно.
S>?
Я предлагаю их вообще не писать. Но если уж сильно хочется только статикой тут все равно особо не пахнет.
Z>>Если мы не указываем типы явно и не можем вывести это будет функция params array[object] -> object S>Ну да. Следовательно, мы можем ошибиться в количестве/типах параметров и (при известном везении) узнать об этом только на третью неделю продакшна
Следовательно, надо указывать их там, где компилятор не может вывести.
Z>>А из открытых сайтов многие такой подход используют? Фреймворков для эмуляции десктопного UI хватает. В том же extjs есть даже приличное IDE для формоклепания. S>Да никто почти
Вот и ответ, на сайтах не особо нужны такие вещи. Это в первую очередь информационный ресурс.
Здравствуйте, silverwolf, Вы писали:
Z>> x. // интелисенс?
S>Если таки надо передать большой объект -- пишите JsDoc-и, знакомый говорил что смог нормально настроить еклипс -- он подсвечивал поля как надо (у меня не получилось )
Кстати да, подтверждаю, в IDEA и подсветка, и интелисенс в принципе приемлемо работает
Здравствуйте, Gaperton, Вы писали:
DM>>http://haxe.org/doc/intro
G>Как там на практике с отладкой в браузере и стыковке с популярными фрейморками, вроде ExtJS и Dojo?
Представления не имею. Я из бэкендов haxe только флэш использовал.
Здравствуйте, mymuss, Вы писали:
M>Здравствуйте, silverwolf, Вы писали:
Z>>> x. // интелисенс?
S>>Если таки надо передать большой объект -- пишите JsDoc-и, знакомый говорил что смог нормально настроить еклипс -- он подсвечивал поля как надо (у меня не получилось )
M>Кстати да, подтверждаю, в IDEA и подсветка, и интелисенс в принципе приемлемо работает
Вот, кстати, инструкция "по настройке" для Еклипс. Попробую ишо раз мо заведетсо.
Здравствуйте, vsb, Вы писали:
vsb>Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
Самое смешное, что с этого все начиналось и это все пока еще есть — Java applets. Просто изначально они были направлены не на то (прямой рендеринг вместо манипуляции DOM-om) и реализация хромала по части ресурсов, скорости, совместимости и старта. В новых версиях плагина многое починено (быстрый старт, скорость hotspot-a, исполнение вне процесса). ИМХО нужно немного обновить API и сделать поддержку в IDE для доводки этого до уровеня, скажем, WPF.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, vsb, Вы писали:
vsb>>Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
N>Самое смешное, что с этого все начиналось и это все пока еще есть — Java applets.
Сейчас это лишь один из плагинов, в одном ряду с флэшем и сервелатом. И из этих троих сегодня худший — умеет мало, а стартует долго. Сервелат тоже долго запускается, но там хоть есть ради чего — WPF.
Вопрос — как быть с существующими библиотеками под яваскрипт? 
)
