TypeScript, или могила для JS.

[DIzer]

Чтобы выкинуть яваскрипт на свалку истории...

тоже  маловероятно -  эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...

Это (TypeScript, Dart) не синтаксический сахар.
Также как и Оберон не является синтаксическим сахаром для машкода.

  тогда вы знаете о нем больше чем авторы... считающие его сахаром...  но понятно, что в данном случае я  говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...

[valexey_u]

тогда вы знаете о нем больше чем авторы... считающие его сахаром...  но понятно, что в данном случае я  говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...

Это твое ощущение, что авторы считают его сахаром, или они где-то про это явно пишут?

Если есть язык A и язык B, при этом у B динамическая типизация, а у A статическая, и А транслируется в B, то A не является синтаксическим сахаром для B.

Так вот, Groovy вполне возможно является синтаксическим сахаром для java (потому как тут ситуация обратная, у java статическая типизация, а у груви динамическая). С другой стороны, сахар это или нет определяется не только типизацией, поэтому нужно смотреть подробней.

В случае же TypeScript & JavaScript, первый очевидно не является синтаксическим сахаром для второго.

[DIzer]

тогда вы знаете о нем больше чем авторы... считающие его сахаром...  но понятно, что в данном случае я  говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...

Это твое ощущение, что авторы считают его сахаром, или они где-то про это явно пишут?

Если есть язык A и язык B, при этом у B динамическая типизация, а у A статическая, и А транслируется в B, то A не является синтаксическим сахаром для B.

Так вот, Groovy вполне возможно является синтаксическим сахаром для java (потому как тут ситуация обратная, у java статическая типизация, а у груви динамическая). С другой стороны, сахар это или нет определяется не только типизацией, поэтому нужно смотреть подробней.

В случае же TypeScript & JavaScript, первый очевидно не является синтаксическим сахаром для второго.

таки да - хотя внимательно я в документацию не всматривался.. но прямо говорится - что программа на одном есть программа на другом, и наоборот...
далее...  было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП  (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....

[valexey_u]

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

Это из той же серии, что C++ это то же что и Си, ибо C++ может быть транслирован в Си (формально это будет программа на Си), а большенство Сишных прог могут быть собраны С++ компилером. Но при этом С++ код оттранслированный в Си не является вменяемым кодом на Си, а Сишная прога не является вменяемой прогой на С++. Между прочим, тут можно C++ заменить на Оберон - ничего не изменится.

Так вот, как ты из js-кода получишь код на TypeScript (со строгой статической типизацией)?

далее...  было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП  (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....

Там из TypeScript'a генерируется (компилируется/транслируется) читабельны js-код. И да, знание двух ЯП обязательно. Также как и в случае Оберона обязательно знать асм.

[DIzer]

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

Это из той же серии, что C++ это то же что и Си, ибо C++ может быть транслирован в Си (формально это будет программа на Си), а большенство Сишных прог могут быть собраны С++ компилером. Но при этом С++ код оттранслированный в Си не является вменяемым кодом на Си, а Сишная прога не является вменяемой прогой на С++. Между прочим, тут можно C++ заменить на Оберон - ничего не изменится.

Так вот, как ты из js-кода получишь код на TypeScript (со строгой статической типизацией)?

далее...  было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП  (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....

Там из TypeScript'a генерируется (компилируется/транслируется) читабельны js-код. И да, знание двух ЯП обязательно. Также как и в случае Оберона обязательно знать асм.

1. Алексей.. я же сказал... что НЕ ВЧИТЫВАЛСЯ
2. ЗАЧЕМ - если задача НЕ ТРЕБУЕТ спуска на уровень железа- а подавляющее большинство js - задач именно такого уровня...  -проще  ECMA комитету выпустить несовместимый со старыми версиями JS - как Питон...- аргументация - изменилась реальность (функциональная нагрузка на js )

[Geniepro]

Чтобы выкинуть яваскрипт на свалку истории...

тоже  маловероятно -  эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...

Это (TypeScript, Dart) не синтаксический сахар.
Также как и Оберон не является синтаксическим сахаром для машкода.

Таки да:

TypeScript is a syntactic sugar for JavaScript. TypeScript syntax is a superset of Ecmascript 5 (ES5) syntax. Every JavaScript program is also a TypeScript program. The TypeScript compiler performs only file-local transformations on TypeScript programs and does not re-order variables declared in TypeScript. This leads to JavaScript output that closely matches the TypeScript input. TypeScript does not transform variable names, making tractable the direct debugging of emitted JavaScript. TypeScript optionally provides source maps, enabling source-level debugging. TypeScript tools typically emit JavaScript upon file save, preserving the test, edit, refresh cycle commonly used in JavaScript development.

[valexey_u]

Чтобы выкинуть яваскрипт на свалку истории...

тоже  маловероятно -  эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...

Это (TypeScript, Dart) не синтаксический сахар.
Также как и Оберон не является синтаксическим сахаром для машкода.

Таки да:

TypeScript is a syntactic sugar for JavaScript. TypeScript syntax is a superset of Ecmascript 5 (ES5) syntax. Every JavaScript program is also a TypeScript program. The TypeScript compiler performs only file-local transformations on TypeScript programs and does not re-order variables declared in TypeScript. This leads to JavaScript output that closely matches the TypeScript input. TypeScript does not transform variable names, making tractable the direct debugging of emitted JavaScript. TypeScript optionally provides source maps, enabling source-level debugging. TypeScript tools typically emit JavaScript upon file save, preserving the test, edit, refresh cycle commonly used in JavaScript development.

Увы, но писавший это просто не понимает что такое синтаксический сахар.

А совместимость снизу вверх (любая js-прога явлется и typescript прогой) не превращает typescript в синтаксический сахар для js.

[DIzer]

Увы, но писавший это просто не понимает что такое синтаксический сахар.

А совместимость снизу вверх (любая js-прога явлется и typescript прогой) не превращает typescript в синтаксический сахар для js.

Вот именно по этому я  говорю, что не вчитывался особо в эту писанину - евангилисты от языка еще не боги... но одно можно сказать... они ХОТЕЛИ сделать сахар - и почему , мне лично понятно ( я попробовал это здесь объяснить).

[Peter Almazov]

"Every JavaScript program is also a TypeScript program."

Неубиваемо...

[valexey_u]

Увы, но писавший это просто не понимает что такое синтаксический сахар.

А совместимость снизу вверх (любая js-прога явлется и typescript прогой) не превращает typescript в синтаксический сахар для js.

Вот именно по этому я  говорю, что не вчитывался особо в эту писанину - евангилисты от языка еще не боги... но одно можно сказать... они ХОТЕЛИ сделать сахар - и почему , мне лично понятно ( я попробовал это здесь объяснить).

Чтобы не распугать жабаскриптописателей :-) Чтобы подчеркнуть обратную совместимость лишний раз.

[DIzer]

Чтобы не распугать жабаскриптописателей :-) Чтобы подчеркнуть обратную совместимость лишний раз.

Может быть, но лично я думаю, что не так все запущено...  грамотно ограничивая JS - ИМХО вполне можно понизить его до подмножества с автоматической строгой типизацией- другое дело что много "наворотов" уйдет при этом..

[vlad]

Может быть, но лично я думаю, что не так все запущено...  грамотно ограничивая JS - ИМХО вполне можно понизить его до подмножества с автоматической строгой типизацией- другое дело что много "наворотов" уйдет при этом..

Не-не. Не работает. Говорю это как хардкорный сиплюсплюсник, который знает, что такое ограничения/соглашения/правила для получения нормального кода на C++. Все ограничения/соглашения/правила и прочие придумки типа тотальных юниттестов и JS-линтов позволяют выдавать продукт на жабаскрипте, но с ощущением постоянной борьбы и боязни наступить на грабли. Там такие врожденные дефекты, что никакими протезами (или отрезанием чего-либо) не вылечить. Притом, что протезы приходится делать из того же жабаскрипта - это как пытаться строить ажурную башню из говна. Можно очень хитрыми придумками пытаться придать прочность конструкции, но оно все равно рушится, потому что это говно. Только закопать.

[vlad]

В этом плане гугл лучше. Да даже apple лучше.

Согласен с Geniepro - если M$ удастся продавить свою поделку в виде native поддержки, то в конечном итоге всем будет только лучше. Потому что даже с M$-спецификой оно будет лучше жабаскрипта. В то же время только у M$ достаточно "давления", чтобы сдвинуть дело из "локального оптимума", в котором сейчас находится связка браузер-ЯП.

[DIzer]

Не-не. Не работает. Говорю это как хардкорный сиплюсплюсник, который знает, что такое ограничения/соглашения/правила для получения нормального кода на C++. Все ограничения/соглашения/правила и прочие придумки типа тотальных юниттестов и JS-линтов позволяют выдавать продукт на жабаскрипте, но с ощущением постоянной борьбы и боязни наступить на грабли. Там такие врожденные дефекты, что никакими протезами (или отрезанием чего-либо) не вылечить. Притом, что протезы приходится делать из того же жабаскрипта - это как пытаться строить ажурную башню из говна. Можно очень хитрыми придумками пытаться придать прочность конструкции, но оно все равно рушится, потому что это говно. Только закопать.

Влад - боюсь вы говорите немного про другое -  про попытки ЭФФЕКТИВНО (экономия ресурсов, максимальная производительность) решать низкоуровневые задачи высокоуровневым способом= здесь же задачи высокоуровневые, и подобный подход всего лишь ограничивает "свободу реализации" - впрочем это просто "поверхностные"  соображения , я привожу их потому, что технически не вижу ничего мешающего сделать это...

[valexey_u]

В этом плане гугл лучше. Да даже apple лучше.

Согласен с Geniepro - если M$ удастся продавить свою поделку в виде native поддержки, то в конечном итоге всем будет только лучше. Потому что даже с M$-спецификой оно будет лучше жабаскрипта. В то же время только у M$ достаточно "давления", чтобы сдвинуть дело из "локального оптимума", в котором сейчас находится связка браузер-ЯП.

Гугл играет в браузерно-инетном мире сейчас много бОльшую роль нежели MS (если мы про интернет говорим, а не внутрикорпоративные извращения). Собственно, пожалуй, даже Apple больше чем MS там сейчас роляет.