К сожалению, доля web-ui растет, а альтернатив js в этом плане практически не предвидится. Я думаю для многих js разработчиков наступал момент, когда код превращается в некого монстра, навигация по которому представлялась нетривиальной задачей, а запоминание методов и их параметров у используемых классов превращалось в нехилую тренировку памяти. Немного помогают хорошие IDE с интелисенсом, но только немного.
[javascript]
function f(x) {
x. // интелисенс?
}
[/javascript]
А в групповой разработке все осложняется тем, что код непрерывно правят несколько человек и время от времени неизменно затрагиваются публичные инфтерфейсы. На всех серьезных рефакторингах практически ставится крест, а это означает одно — либо стоимость внесения фич идет по экспоненте либо фичи просто перестают добавляться и проект начинает медленно умирать или переписываться с нуля.
Вполне логичный постулат — "тесты нас спасут" тоже работает плохо. Потому, что в вышеописанной функции надо тестировать не поведение с f("hello world"), а вызывать ее по всему коду с реальными параметрами. Потому, что тесты сильно увеличивает кодовую базу которую тоже требуется поддерживать. Потому, что тестировать код на асинхронных событиях сама по себе сложная задача.
Сейчас стали как грибы появляться компиляторы всего чего угодно в javascript: Java, C#, F#, IL и т.д.
Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Чем он будет лучше того же websharper? Да тем, что скомпилированный js будет практически идентичен исходному коду (просто рассахареный исходник). Тем, что интеграция с любыми внешними js фреймворками будет абсолютно прямой и прозрачной. Для чего-то типы можно будет описать (типа хидера в C), для чего то забить на типизацию.
Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Здравствуйте, Ziaw, Вы писали:
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Теоретически возможен, только это чудо уже не будет яваскриптом, и, следовательно, будет совместимо только с самим собой, да и то частично
Кроме того, у нас всё равно останется тонна проблем, начиная с отсутствия стандартных библиотек/UI-фреймворка (только давайте не будем про canvas и меню на css) и заканчивая привязкой к принципиально нетипизируемому DOM.
А если мы явно разделим язык для логики и язык для декларативного описания ui/привязки к логике, то результат будет слишком сложным для большинства веб-дизайнеров, и, наоборот, слишком примитивным по сравнению с "взрослыми" явой и дотнетом.
Здравствуйте, Ziaw, Вы писали:
Z>[javascript] Z>function f(x) { Z> x. // интелисенс? Z>} Z>[/javascript]
Зачем вы передаете большие объекты?
Если таки надо передать большой объект -- пишите JsDoc-и, знакомый говорил что смог нормально настроить еклипс -- он подсвечивал поля как надо (у меня не получилось )
Z>Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Ограничение областей видимости (куча маленьких файлов и все в псевдомодулях). Сборка джаваскриптовых файлов при сборке приложения и подключение уже результата (не всегда простая задача).
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации.
CoffeeScript, Cappuccino, GWT -- чего только не придумают люди лишь бы не учить JavaScript. Кстати, тот же CoffeeScript не решает проблему с динамической типизацией, а просто прячет некоторые приемы которые приходится писать вручную, то есть фактически просто синтаксический сахар.
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Помимо "детских проблем" (не эффективная трансляция) и не понятный код-результат (переменные с подчеркиваниями и индексами или просто однобуквенные):
Код не нативный -- в сложных ситуациях будет сложно внести изменения и переносить их. То есть написание JavaScript-кода, скорее всего исключаеться. Уменьшается контроль над кодом.
Ухудшается возможность оптимизаций под каждый браузер: код может быть оптимизирован там где не надо и не оптимизирован там где надо.
Еще Один Язык, который прийдется выучить разработчикам, при том далеко не факт что он будет понятен кому-то кроме автора языка (проблема ДСЛ-ей). JavaScript учить все равно прийдется, ибо "философски" разработка на JavaScript и той же Java или C# очень отличается.
Что забавно, даже изобретая "правильный" язык, автор упорно топчется по граблям скриптовых языков. Из оф. документации:
class C {
static var x : Int;
var x : Int;
function new() {
{
// x at this point means member variable this.x
var x : String;
// x at this point means the local variable
}
}
}
Здравствуйте, Ziaw, Вы писали:
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Z>Чем он будет лучше того же websharper? Да тем, что скомпилированный js будет практически идентичен исходному коду (просто рассахареный исходник). Тем, что интеграция с любыми внешними js фреймворками будет абсолютно прямой и прозрачной. Для чего-то типы можно будет описать (типа хидера в C), для чего то забить на типизацию.
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг над всей абсурдностью сегодняшних веб-технологий.
Я Haxe использую для компиляции во Flash. Очень приятный язычок, а компилятор значительно лучше, чем ActionScript'овский (как по скорости получаемого кода, так и по скорости компиляции). IDE с автокомплитом и прочими плюшками уже есть (FlashDevelop).
Отличная идея по моему.
Незнаю как там haxe — а в любом случае сейчас любой приличный фреймворк имеет свой собственный недо-js-компилятор (google-closure, dojo). Да и сам этим озаботился для своего fw. Правда пока что всё забросил подальше.
Z>К сожалению, доля web-ui растет, а альтернатив js в этом плане практически не предвидится. Я думаю для многих js разработчиков наступал момент, когда код превращается в некого монстра, навигация по которому представлялась нетривиальной задачей, а запоминание методов и их параметров у используемых классов превращалось в нехилую тренировку памяти. Немного помогают хорошие IDE с интелисенсом, но только немного.
Z>[javascript] Z>function f(x) { Z> x. // интелисенс? Z>} Z>[/javascript]
InteliJ'ные продукты неплохо справляются с интеллисенсом (до определенного момента, естественно).
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Было бы неплохо иметь в JS не обязательно статику, но type hints или type specs, имхо.
Здравствуйте, Sinix, Вы писали:
Z>>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен? S>Теоретически возможен, только это чудо уже не будет яваскриптом, и, следовательно, будет совместимо только с самим собой, да и то частично
Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
S>Кроме того, у нас всё равно останется тонна проблем, начиная с отсутствия стандартных библиотек/UI-фреймворка (только давайте не будем про canvas и меню на css) и заканчивая привязкой к принципиально нетипизируемому DOM.
И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ.
S>А если мы явно разделим язык для логики и язык для декларативного описания ui/привязки к логике, то результат будет слишком сложным для большинства веб-дизайнеров, и, наоборот, слишком примитивным по сравнению с "взрослыми" явой и дотнетом.
Не надо этих наворотов. Язык для декларативного описания UI это html, привязать его к логике уже умеет куча фреймворков и еще большая куча появится.
Здравствуйте, vsb, Вы писали:
vsb>Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
Если бы, да кабы. Я не вижу даже движения в эту сторону.
vsb>Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг над всей абсурдностью сегодняшних веб-технологий.
+1 только никто не желает отливать против ветра и я их понимаю.
Здравствуйте, Ziaw, Вы писали:
Z>Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
? Ну, тогда это не тру — как же ошибки приведения типов?
Z>И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ.
В языке со строгой типизацией — это тонна писанины и прооверок, спасает или паттерн-матчинг, или поздний биндинг, вы же сами пишете:
Именно. Ни о какой полной статике речь идти не может, динамика должна быть в шаговой доступности. Нужны и type hints и type specs и мощный вывод.
Кроме того, как насчёт библиотек? Будем их все вызывать через dynamic? Писать к ним врапперы? Портировать? Воистину,
Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг
Z>Не надо этих наворотов. Язык для декларативного описания UI это html, привязать его к логике уже умеет куча фреймворков и еще большая куча появится.
А вот тут я категорически не согласен. В HTML даже лэйауты документов не всегда нормально можно описать — когда у нас был последний холивар div vs table? Если речь пойдёт о нормальном UI — где контейнеры, докинг, контролы, биндинг, драг-дроп, декларативное описание анимаций и прочее-прочее-прочее? Пока что html как язык описания UI не дотягивает даже до ранних дельфи/vbasic-а. И, такими темпами, ещё лет 10 дотягивать не будет.
Единственное преимущество html — то, что веб-браузеры сейчас не пихают только в чайники (хотя в разделочную доску уже засунули). И нет, это не делает html+js хорошим средством для разработки UI.
Посмотрите сами: весь успешный веб-софт занимается одним и тем же — развлекает несколько сотен миллионов людей, которым скучно на работе. Редкие исключения сильны в первую очередь уникальным контентом или серверной составляющей.
Скажете, гугль, wolphram|alpha, wiki, слешдот, твиттер и прочая-прочая популярны из-за html-я? Зачем играть в культ карго и упорно тащить html туда, где ему делать нечего?
Здравствуйте, Ziaw, Вы писали:
Z>Сейчас стали как грибы появляться компиляторы всего чего угодно в javascript: Java, C#, F#, IL и т.д.
Z>Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Существование и достаточная популярность таких же трансляторов для питона:
Показывает что дело не только и не столько в динамической типизации.
Скорее виноваты другие особенности JavaScript и его общая далекость от мейнстримных языков вообще.
Здравствуйте, Sinix, Вы писали:
S>Единственное преимущество html — то, что веб-браузеры сейчас не пихают только в чайники (хотя в разделочную доску уже засунули).
Здравствуйте, Sinix, Вы писали:
Z>>Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
S>А, типа такого
? Ну, тогда это не тру — как же ошибки приведения типов?
Сейчас с ними тоже никак. Ты смотришь с точки зрения ортодоксальной типизации. А я хочу ее использовать только там, где она меньше мешает, чем помогает. Проверки на соответствие типу для выполнения в рантайме придется писать явно.
Z>>И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ. S>В языке со строгой типизацией — это тонна писанины и прооверок, спасает или паттерн-матчинг, или поздний биндинг, вы же сами пишете:
Настолько строгой типизации не нужно. Dom узел это dom узел, а не div|table|h1.
S>
S>Именно. Ни о какой полной статике речь идти не может, динамика должна быть в шаговой доступности. Нужны и type hints и type specs и мощный вывод.
S>Кроме того, как насчёт библиотек? Будем их все вызывать через dynamic? Писать к ним врапперы? Портировать? Воистину, S>
S>Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг
S>
Еще раз. Динамика никуда не девается, она остается в шаговой доступности. Джаваскрипт тут не в роли ассемблера, а в роли основного языка. Просто припудрен сахаром и конструкциями помогающими выводу типов. Если ты хочешь описать сигнатуру метода $.ajax() — пожалуйста, если не хочешь, компилятор попробует вывести сам либо переделает в динамику.
S>А вот тут я категорически не согласен. В HTML даже лэйауты документов не всегда нормально можно описать — когда у нас был последний холивар div vs table? Если речь пойдёт о нормальном UI — где контейнеры, докинг, контролы, биндинг, драг-дроп, декларативное описание анимаций и прочее-прочее-прочее? Пока что html как язык описания UI не дотягивает даже до ранних дельфи/vbasic-а. И, такими темпами, ещё лет 10 дотягивать не будет.
Тем не менее в очень большом сегменте альтернативы ему не предвидится. Не надо сгущать краски. Далеко не всем требуется UI в стиле десктопа (контейнеры, докинг), это вообще годится только для ентерпрайз оперденей. А контролы, биндинг и драг-дроп существуют вполне приличные.
Здравствуйте, 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.
) и заканчивая привязкой к принципиально нетипизируемому DOM.
)
