Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Октябрь 01, 2012, 07:40:06 pm
-
Microsoft представила новый ЯП для веб-браузеров: TypeScript. Разработчик этого языка - не безизвестный Hejlsberg (автор-cоздатель Turbo Pascal, архитектор Delphi и C# с LINQ).
Отличается от js сий новый язык наличием статической типизацией (впрочем, она опциональна), модульностью (прям реальнео модули есть) и наличием классов, интерфейсов и прочего привычного ООП-программисту.
Пример программы:
module Sayings {
export class Greeter {
greeting: string;
constructor (message: string) {
this.greeting = message;
}
greet() {
return "Hello, " + this.greeting;
}
}
}
var greeter = new Sayings.Greeter("world");
var button = document.createElement('button')
button.innerText = "Say Hello"
button.onclick = function() {
alert(greeter.greet())
}
document.body.appendChild(button)
Язык, как и его реализация - полный опенсорс. Также имеется плагин к MSVS.
Официальный сайт проекта (где можно сразу поиграться с языком не устанавливая чего-либо):
http://www.typescriptlang.org/
Да, компилируется он конечно же в JavaScript, то есть никакие плагины к браузерам ставить не придется.
Ссылки по теме:
http://www.linux.org.ru/news/internet/8291250
http://techcrunch.com/2012/10/01/microsoft-previews-new-javascript-like-programming-language-typescript/
-
Неплохо.
-
http://techcrunch.com/2012/10/01/microsoft-previews-new-javascript-like-programming-language-typescript/
Глянул - вроде неплохо все, на первый взгляд. С поправкой, конечно, на то, что это должно эффективно ложиться на жабаскрипт.
-
http://techcrunch.com/2012/10/01/microsoft-previews-new-javascript-like-programming-language-typescript/
Глянул - вроде неплохо все, на первый взгляд. С поправкой, конечно, на то, что это должно эффективно ложиться на жабаскрипт.
Но у него есть фатальный недостаток - это порождение Microsoft'a. Следовательно там будет жесткий крен в сторону именно мелкософтверных платформ (в том числе и браузера, который очень своеобразно понимает JavaScript, следовательно кодогенерация будет с учетом этого своеобразия, что не здорово). Причем как с точки зрения разработки так и с точки зрения целевых платформ.
В этом плане гугл лучше. Да даже apple лучше.
-
Надеюсь, они скоро добявят патчами поддержку в IE, а там и огнелисы с хромами будут вынуждены подтянуться... Может даже опера осилит...
-
Надеюсь, они скоро добявят патчами поддержку в IE, а там и огнелисы с хромами будут вынуждены подтянуться... Может даже опера осилит...
Нафига?
-
Надеюсь, они скоро добявят патчами поддержку в IE, а там и огнелисы с хромами будут вынуждены подтянуться... Может даже опера осилит...
Нафига?
Чтобы выкинуть яваскрипт на свалку истории...
-
Надеюсь, они скоро добявят патчами поддержку в IE, а там и огнелисы с хромами будут вынуждены подтянуться... Может даже опера осилит...
Нафига?
Чтобы выкинуть яваскрипт на свалку истории...
А зачем поддержка в браузерах для этого? Оно без того отлично работает.
-
А зачем поддержка в браузерах для этого? Оно без того отлично работает.
Что бы ещё лучше работало...
-
Для нормальной отладки.
-
Для нормальной отладки.
Как я понял, они предлагают отлаживать в вижуал студии...
-
А зачем поддержка в браузерах для этого? Оно без того отлично работает.
Что бы ещё лучше работало...
Чтобы еще лучше работало, надо для браузеров разработать нормальный низкоуровневый язык в который транслировать с высокоуровневых.
-
Чтобы еще лучше работало, надо для браузеров разработать нормальный низкоуровневый язык в который транслировать с высокоуровневых.
Идея не прижилась... возьмите жавку с ее байткодом... не прошло.. возможно по причине параноидальных "соображений безопасности "
-
Чтобы выкинуть яваскрипт на свалку истории...
тоже маловероятно - эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...
-
Чтобы выкинуть яваскрипт на свалку истории...
тоже маловероятно - эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...
Это (TypeScript, Dart) не синтаксический сахар.
Также как и Оберон не является синтаксическим сахаром для машкода.
-
Чтобы выкинуть яваскрипт на свалку истории...
тоже маловероятно - эта хрень(я так понял - синтаксический сахар) - что то на вроде groovy над жавкой - по итогам груви не заменил жаву...
Это (TypeScript, Dart) не синтаксический сахар.
Также как и Оберон не является синтаксическим сахаром для машкода.
;) тогда вы знаете о нем больше чем авторы... считающие его сахаром... но понятно, что в данном случае я говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...
-
;) тогда вы знаете о нем больше чем авторы... считающие его сахаром... но понятно, что в данном случае я говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...
Это твое ощущение, что авторы считают его сахаром, или они где-то про это явно пишут?
Если есть язык A и язык B, при этом у B динамическая типизация, а у A статическая, и А транслируется в B, то A не является синтаксическим сахаром для B.
Так вот, Groovy вполне возможно является синтаксическим сахаром для java (потому как тут ситуация обратная, у java статическая типизация, а у груви динамическая). С другой стороны, сахар это или нет определяется не только типизацией, поэтому нужно смотреть подробней.
В случае же TypeScript & JavaScript, первый очевидно не является синтаксическим сахаром для второго.
-
;) тогда вы знаете о нем больше чем авторы... считающие его сахаром... но понятно, что в данном случае я говорю про ощущения и привожу весьма грубые (на грани фола) аналогии...
Это твое ощущение, что авторы считают его сахаром, или они где-то про это явно пишут?
Если есть язык A и язык B, при этом у B динамическая типизация, а у A статическая, и А транслируется в B, то A не является синтаксическим сахаром для B.
Так вот, Groovy вполне возможно является синтаксическим сахаром для java (потому как тут ситуация обратная, у java статическая типизация, а у груви динамическая). С другой стороны, сахар это или нет определяется не только типизацией, поэтому нужно смотреть подробней.
В случае же TypeScript & JavaScript, первый очевидно не является синтаксическим сахаром для второго.
таки да - хотя внимательно я в документацию не всматривался.. но прямо говорится - что программа на одном есть программа на другом, и наоборот...
далее... было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....
-
таки да - хотя внимательно я в документацию не всматривался.. но прямо говорится - что программа на одном есть программа на другом, и наоборот...
Это из той же серии, что C++ это то же что и Си, ибо C++ может быть транслирован в Си (формально это будет программа на Си), а большенство Сишных прог могут быть собраны С++ компилером. Но при этом С++ код оттранслированный в Си не является вменяемым кодом на Си, а Сишная прога не является вменяемой прогой на С++. Между прочим, тут можно C++ заменить на Оберон - ничего не изменится.
Так вот, как ты из js-кода получишь код на TypeScript (со строгой статической типизацией)?
далее... было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....
Там из TypeScript'a генерируется (компилируется/транслируется) читабельны js-код. И да, знание двух ЯП обязательно. Также как и в случае Оберона обязательно знать асм.
-
таки да - хотя внимательно я в документацию не всматривался.. но прямо говорится - что программа на одном есть программа на другом, и наоборот...
Это из той же серии, что C++ это то же что и Си, ибо C++ может быть транслирован в Си (формально это будет программа на Си), а большенство Сишных прог могут быть собраны С++ компилером. Но при этом С++ код оттранслированный в Си не является вменяемым кодом на Си, а Сишная прога не является вменяемой прогой на С++. Между прочим, тут можно C++ заменить на Оберон - ничего не изменится.
Так вот, как ты из js-кода получишь код на TypeScript (со строгой статической типизацией)?
далее... было бы странно увидеть нечто другое.. ибо политика параноидальной безопасности ТРЕБУЕТ - что бы на клиента передавался ЧИТАБЕЛЬНЫЙ код... в том случае если будет передавать код ДРУГОГО языка... будет какашка- мы будем иметь необходимость в знании ДВУХ ЯП (пусть даже одного х..го а второго не очень) вместо одного.. - и не очень очевидно стоит ли возможность полноценной отладки такого гемора....
Там из TypeScript'a генерируется (компилируется/транслируется) читабельны js-код. И да, знание двух ЯП обязательно. Также как и в случае Оберона обязательно знать асм.
1. Алексей.. я же сказал... что НЕ ВЧИТЫВАЛСЯ
2. ЗАЧЕМ - если задача НЕ ТРЕБУЕТ спуска на уровень железа- а подавляющее большинство js - задач именно такого уровня... -проще ECMA комитету выпустить несовместимый со старыми версиями JS - как Питон...- аргументация - изменилась реальность (функциональная нагрузка на js )
-
Чтобы выкинуть яваскрипт на свалку истории...
тоже маловероятно - эта хрень(я так понял - синтаксический сахар) - что то на вроде 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.
-
Чтобы выкинуть яваскрипт на свалку истории...
тоже маловероятно - эта хрень(я так понял - синтаксический сахар) - что то на вроде 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.
-
Увы, но писавший это просто не понимает что такое синтаксический сахар.
А совместимость снизу вверх (любая js-прога явлется и typescript прогой) не превращает typescript в синтаксический сахар для js.
Вот именно по этому я говорю, что не вчитывался особо в эту писанину - евангилисты от языка еще не боги... но одно можно сказать... они ХОТЕЛИ сделать сахар - и почему , мне лично понятно ( я попробовал это здесь объяснить).
-
"Every JavaScript program is also a TypeScript program."
Неубиваемо...
-
Увы, но писавший это просто не понимает что такое синтаксический сахар.
А совместимость снизу вверх (любая js-прога явлется и typescript прогой) не превращает typescript в синтаксический сахар для js.
Вот именно по этому я говорю, что не вчитывался особо в эту писанину - евангилисты от языка еще не боги... но одно можно сказать... они ХОТЕЛИ сделать сахар - и почему , мне лично понятно ( я попробовал это здесь объяснить).
Чтобы не распугать жабаскриптописателей :-) Чтобы подчеркнуть обратную совместимость лишний раз.
-
Чтобы не распугать жабаскриптописателей :-) Чтобы подчеркнуть обратную совместимость лишний раз.
Может быть, но лично я думаю, что не так все запущено... грамотно ограничивая JS - ИМХО вполне можно понизить его до подмножества с автоматической строгой типизацией- другое дело что много "наворотов" уйдет при этом..
-
Может быть, но лично я думаю, что не так все запущено... грамотно ограничивая JS - ИМХО вполне можно понизить его до подмножества с автоматической строгой типизацией- другое дело что много "наворотов" уйдет при этом..
Не-не. Не работает. Говорю это как хардкорный сиплюсплюсник, который знает, что такое ограничения/соглашения/правила для получения нормального кода на C++. Все ограничения/соглашения/правила и прочие придумки типа тотальных юниттестов и JS-линтов позволяют выдавать продукт на жабаскрипте, но с ощущением постоянной борьбы и боязни наступить на грабли. Там такие врожденные дефекты, что никакими протезами (или отрезанием чего-либо) не вылечить. Притом, что протезы приходится делать из того же жабаскрипта - это как пытаться строить ажурную башню из говна. Можно очень хитрыми придумками пытаться придать прочность конструкции, но оно все равно рушится, потому что это говно. Только закопать.
-
В этом плане гугл лучше. Да даже apple лучше.
Согласен с Geniepro - если M$ удастся продавить свою поделку в виде native поддержки, то в конечном итоге всем будет только лучше. Потому что даже с M$-спецификой оно будет лучше жабаскрипта. В то же время только у M$ достаточно "давления", чтобы сдвинуть дело из "локального оптимума", в котором сейчас находится связка браузер-ЯП.
-
Не-не. Не работает. Говорю это как хардкорный сиплюсплюсник, который знает, что такое ограничения/соглашения/правила для получения нормального кода на C++. Все ограничения/соглашения/правила и прочие придумки типа тотальных юниттестов и JS-линтов позволяют выдавать продукт на жабаскрипте, но с ощущением постоянной борьбы и боязни наступить на грабли. Там такие врожденные дефекты, что никакими протезами (или отрезанием чего-либо) не вылечить. Притом, что протезы приходится делать из того же жабаскрипта - это как пытаться строить ажурную башню из говна. Можно очень хитрыми придумками пытаться придать прочность конструкции, но оно все равно рушится, потому что это говно. Только закопать.
Влад - боюсь вы говорите немного про другое - про попытки ЭФФЕКТИВНО (экономия ресурсов, максимальная производительность) решать низкоуровневые задачи высокоуровневым способом= здесь же задачи высокоуровневые, и подобный подход всего лишь ограничивает "свободу реализации" - впрочем это просто "поверхностные" соображения , я привожу их потому, что технически не вижу ничего мешающего сделать это...
-
В этом плане гугл лучше. Да даже apple лучше.
Согласен с Geniepro - если M$ удастся продавить свою поделку в виде native поддержки, то в конечном итоге всем будет только лучше. Потому что даже с M$-спецификой оно будет лучше жабаскрипта. В то же время только у M$ достаточно "давления", чтобы сдвинуть дело из "локального оптимума", в котором сейчас находится связка браузер-ЯП.
Гугл играет в браузерно-инетном мире сейчас много бОльшую роль нежели MS (если мы про интернет говорим, а не внутрикорпоративные извращения). Собственно, пожалуй, даже Apple больше чем MS там сейчас роляет.
-
Гугл играет в браузерно-инетном мире сейчас много бОльшую роль нежели MS (если мы про интернет говорим, а не внутрикорпоративные извращения). Собственно, пожалуй, даже Apple больше чем MS там сейчас роляет.
Ну тогда все, капец - продолжаем жрать кактус :)
-
Гугл играет в браузерно-инетном мире сейчас много бОльшую роль нежели MS (если мы про интернет говорим, а не внутрикорпоративные извращения). Собственно, пожалуй, даже Apple больше чем MS там сейчас роляет.
По этому и вдвойне интересно - хватит ли у них силенок "продавить" дартс... С Андроидом , почти вышло - но там были "не вспаханные нивы"
-
Гугл играет в браузерно-инетном мире сейчас много бОльшую роль нежели MS (если мы про интернет говорим, а не внутрикорпоративные извращения). Собственно, пожалуй, даже Apple больше чем MS там сейчас роляет.
По этому и вдвойне интересно - хватит ли у них силенок "продавить" дартс... С Андроидом , почти вышло - но там были "не вспаханные нивы"
Самое забавное не то что с Андроидом вышло, а что с Chrome вышло - ведь они заши на уже вспаханное и плотно засеянное поле (IE, и, главное FF уже был у всех подряд. у яблочников уже был Safari).
-
Кстати, если отвлечься от новизны TypeScript'a, то присмотревшись повнимательней, видно что это ЭТО ЖЕ ОБЫЧНЫЙ ActionScript!!111
В нем тоже опциональная статическая типизация. Он тоже имеет и умеет class и interface, он тоже является диалектом ECMAScript'a.
-
Самое забавное не то что с Андроидом вышло, а что с Chrome вышло - ведь они заши на уже вспаханное и плотно засеянное поле (IE, и, главное FF уже был у всех подряд. у яблочников уже был Safari).
мм.. тут вот какое дело, я абсолютно точно помню что ощущение (как пользователя) хром даже ранних версий давал иное , нежели сформировавшиеся конкуренты на рынке.. однако, сформулировать его затрудняюсь - ИМХО это и было ключом к успеху, а поскольку такие вещи к "надежно прогнозируемым" не относятся, то насколько я помню даже в руководстве Гугла в эту идею никто не верил, а рассматривал как очередной технический проект (в общую копилку опыта).
-
Кстати, если отвлечься от новизны TypeScript'a, то присмотревшись повнимательней, видно что это ЭТО ЖЕ ОБЫЧНЫЙ ActionScript!!111
В нем тоже опциональная статическая типизация. Он тоже имеет и умеет class и interface, он тоже является диалектом ECMAScript'a.
по этому и нужен не snapshot , а нормальный анализ.. интересно кто-нибуть из почетных хабрложцев сделает это...
-
Кстати, если отвлечься от новизны TypeScript'a, то присмотревшись повнимательней, видно что это ЭТО ЖЕ ОБЫЧНЫЙ ActionScript!!111
В нем тоже опциональная статическая типизация. Он тоже имеет и умеет class и interface, он тоже является диалектом ECMAScript'a.
по этому и нужен не snapshot , а нормальный анализ.. интересно кто-нибуть из почетных хабрложцев сделает это...
Наврятли. Там редко вменяемые статьи по ЯП.
-
Влад - боюсь вы говорите немного про другое - про попытки ЭФФЕКТИВНО (экономия ресурсов, максимальная производительность) решать низкоуровневые задачи высокоуровневым способом= здесь же задачи высокоуровневые, и подобный подход всего лишь ограничивает "свободу реализации" - впрочем это просто "поверхностные" соображения , я привожу их потому, что технически не вижу ничего мешающего сделать это...
А можете привести примеры низкоуровневых задач и высокоуровневых задач?
Я в программировании новичок, совсем краем уха слышал подобные понятия, но было бы очень неплохо на пальцах понять, чем одно отличается от другого.
-
Влад - боюсь вы говорите немного про другое - про попытки ЭФФЕКТИВНО (экономия ресурсов, максимальная производительность) решать низкоуровневые задачи высокоуровневым способом= здесь же задачи высокоуровневые, и подобный подход всего лишь ограничивает "свободу реализации" - впрочем это просто "поверхностные" соображения , я привожу их потому, что технически не вижу ничего мешающего сделать это...
А можете привести примеры низкоуровневых задач и высокоуровневых задач?
Я в программировании новичок, совсем краем уха слышал подобные понятия, но было бы очень неплохо на пальцах понять, чем одно отличается от другого.
Низкоуровневая : Практически любая задача которая требует, работы с внутренней структурой переменных и данных ( точнее низкоуровневыми моделями -последовательность байт и битов), архитектурой системы на уровне подсистем нижнего уровня (работа с физическими устройствами).
Высокоуровневая : работа с программными компонентами - например , реализацией DOM браузера - в том же js... визуальные и высокуровневые компоненты .NET, WPF....
-
Чем, в идеале, можно было бы заменить JS?
Расширение HTML, CSS? Или отдельный новый стандартизированный скриптовый язык?
-
Кстати, смотрите какой классный фреймворк для js нашел: http://vanilla-js.com/
По моему, он решает бОльшую часть проблем при программировании под браузер. А главное - он намного шустрее чем тот же jQuery.
-
:D
-
Кстати, смотрите какой классный фреймворк для js нашел: http://vanilla-js.com/
По моему, он решает бОльшую часть проблем при программировании под браузер. А главное - он намного шустрее чем тот же jQuery.
У меня на любую комбинацию запчастей выдает "Final size: 0 bytes"
Столько же и грузит.
-
Впечатлило. 25 в сжатом виде, 0 байт в расжатом. Напоминает архиватор, который я писал. Тот упаковывал любые данные в 1 байт (и распаковывал).
-
Примеры вообще не впечатлили (Vanilla JS).
-
А мне показалось что там просто тонкий стеб над голым жабаскриптом ;)
-
Очень даже возможно. Во всяком случае, этот вариант делает логичным некоторые странные вещи, встречающиеся на той странице.
-
А мне показалось что там просто тонкий стеб над голым жабаскриптом ;)
да нет - не тонкий, а самый что ни на есть жестокий (в особенности впечатлил список пользователей ;D )- и место сообщению Алексея в категории "юмор" - мне интересно , считают ли авторы клики идиотов , пытающихся закачать сие творение...
-
А мне показалось что там просто тонкий стеб над голым жабаскриптом ;)
Скорее стеб над фреймворками :-) Также отлично демонстрирует эффект плацебо.
-
и место сообщению Алексея в категории "юмор"
В юморе был бы эффект не тот :-)
-
Особенно впечатляет обширный раздел документации к Vanilla JS. :)