Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 140
Сегодня уже успел поработать на TypeScript. Впечатления очень хорошие.
Разработчики молодцы и добавили как раз то, чего мне (да и думаю многим другим) не хватало в JS.
Выходной код выходит чистым, его удобно читать.
Плагин для VS 2012 удобен, теперь все плюшки среды разработки доступны и для JS.
Пока ешё не разбирался как настроить автоматическую минификация выходного JS, но надеюсь проблем не возникнет
Советую и вам попробовать, действительно удачное расширение JS.
PS
Если работаете с jQuery, до нужно добавить в начало скрипта ссылку:
///
Исходник взять тут: typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db#samples%2fjquery%2fjquery.d.ts
Разработчики молодцы и добавили как раз то, чего мне (да и думаю многим другим) не хватало в JS.
Выходной код выходит чистым, его удобно читать.
Плагин для VS 2012 удобен, теперь все плюшки среды разработки доступны и для JS.
Пока ешё не разбирался как настроить автоматическую минификация выходного JS, но надеюсь проблем не возникнет
Советую и вам попробовать, действительно удачное расширение JS.
PS
Если работаете с jQuery, до нужно добавить в начало скрипта ссылку:
///
Исходник взять тут: typescript.codeplex.com/SourceControl/changeset/view/d397c54a55db#samples%2fjquery%2fjquery.d.ts
///
Разработчики молодцы и добавили как раз то, чего мне (да и думаю многим другим) не хватало в JS.Какой у Вас опыт с другими языками?
Зависимости никакой?
Плагин для VS 2012 удобен
Так значит оно и для Visual Studio есть, не только для Emacs, Sublime Text и Vim? Отлично, будем надеяться на относительно скорое появление поддержки со стороны ReSharper…
Сори за флуд, резался пример.
Вот ссылка для работы с JS:
/// <reference path=«jquery.d.ts» />
По сути это набор интерфейсов необходимый для типизации фреймворка, поэтому не забывайте на странице подключить используемую версию jQuery.
Вот ссылка для работы с JS:
/// <reference path=«jquery.d.ts» />
По сути это набор интерфейсов необходимый для типизации фреймворка, поэтому не забывайте на странице подключить используемую версию jQuery.
Ох ты! Да это именно то, что я ждал!
Редко когда меня что-то действительно так радует, а в особенности если это что-то от майкрософт.
Спасибо,
премного благодарен.
Редко когда меня что-то действительно так радует, а в особенности если это что-то от майкрософт.
Спасибо,
премного благодарен.
Я конвертировал jQuery в TypeScript! Можно забрать отсюда: code.jquery.com/jquery-1.8.2.js
Теперь разрабатывать WinJS приложения под Windows 8 станет легче
Обьясните как украшатель js, который транслируется в итоге в js может иметь статическую типизацию?
Хотя бы на уровне среды разработки. Вот указываешь как аргумент функции function foo(bar x) { } и работа с x будет подсвечиваться с соответствующими полями и методами. Собственно это то, чего так не хватало в JS
А в чём проблема? Это же условное ограничение, а не расширение функций — проверил на этапе компиляции что типы соответствуют и всё. Разумеется в итоговом js не будет статической типизации.
Уже представляю утиный каст типов. типа Node x = (Node)y; превратится в var x = cast(y, Node);
function TypeCastException(message, typeFrom, typeTo) {
this.message = message;
this.typeFrom = typeFrom;
this.typeTo = typeTo;
}
function cast(objFrom, objTo) {
var success = true;
for (var p in objFrom)
if (!(p in objTo)) {
throw new TypeCastException("Невозможно преобразовать объект к указанному типу", objFrom, objTo);
break;
}
else
if (typeof(objTo[p]) != typeof(objFrom[p])) {
success = false;
break;
}
if (success)
return objFrom;
throw new TypeCastException("Невозможно преобразовать объект к указанному типу", objFrom, objTo);
}
Вот ещё хороший анонс blogs.msdn.com/b/somasegar/archive/2012/10/01/typescript-javascript-development-at-application-scale.aspx. Как сказали уже выше, вся проверка типов происходит во время компиляции, а благодаря небольшим декларативным файлам на TypeScript и полной совместимости с js, можно получить удобство типизации и IntelliSense для всяких готовых js-библиотек вроде работы с dom, winRT и др.
Что-то у меня в мозг не укладывается «язык программирования» и «автодополнение функций» в одно целое.
Вот в C++ есть «автодополнение функций»? Должно же быть где-то, мощный же язык…
Вот в C++ есть «автодополнение функций»? Должно же быть где-то, мощный же язык…
«Серебрянная пуля» последнее время заменяется выражением «для масштабируемых приложений».
Ничего в описании языка не говорит о его пригодности для создания масштабируемых приложений. Не говоря о том, что этого текста нет на странице самого языка.
Ничего в описании языка не говорит о его пригодности для создания масштабируемых приложений. Не говоря о том, что этого текста нет на странице самого языка.
Масштабируемая для разработки. Сейчас используют и синтаксический сахар вроде CofeeScript, всякие ClojureCompiler, и линт, даже трансляторы почти каждого языка есть в js. Во всю эту кашу, которая у каждого своя, в этот процесс сборки, вполне себе встраивается TypeScript, никого ничем не напрягая, хотя бы из-за полной совместимости с js позволяет писать код легче и привычнее большему количеству разработчиков. К серверной масштабируемости и проблемам node.js отношения не имеет.
> Масштабируемая для разработки.
Это я должен был телепатировать из текста?
Где тут говорится про «масштабируемость для разработки»?
Это я должен был телепатировать из текста?
Надмножество TypeScript сделано для того, чтобы реализовать функции, необходимые для разработки и поддержки серьёзных масштабируемых приложений.
Где тут говорится про «масштабируемость для разработки»?
понятно, что там приложили руки маркетологи, вот здесь blogs.msdn.com/b/somasegar/archive/2012/10/01/typescript-javascript-development-at-application-scale.aspx уже из урла всё понятней, как и вообще зачем всё это нужно: )
Today, we’re introducing a new programming language that solves a very specific problem – getting JavaScript development to scale.
Хм, все понятно, для Ruby, CoffeScript, для .NET, TypeScript :)
Ваша пунктуация доставляет, я только с 4 раза правильно прочитал :D
CoffeScript ни как не завязан не ruby. Причем уже давно, ему нужен только js движок и всё. Имхо TS кроме как раздувания кодовой базы не принесет. Сколько помню свою работу с JS, всегда было желание уменьшить количество вводимого кода, а не писать еще больше (типы и прочее)
Не очень понятно, чем хуже вместо
писать, например
Ну а статическая типизация на уровне среды разработки в нормальных IDE реализуется через комментарии в стиле jsdoc.
class Greeter {
//...
}
писать, например
var Greeter = Backbone.Model.extend({
//...
});
Ну а статическая типизация на уровне среды разработки в нормальных IDE реализуется через комментарии в стиле jsdoc.
/**
* @param (Int) myParameter
* @return {String} myReturnValue
*/
function intToString() {
//...
}
Согласитесь, что типизацию в приведенном вами примере нельзя назвать полностью «нормальной», пользуясь вашим же «термином». Хотя, конечно же, норма — это всего лишь овладевшая массами патология )
Я называл «нормальной» не типизацию, я назвал нормальными IDE. WebStorm, например, понимает такие комментарии и обращает на них внимание при автодополнении + показывает ошибки, если передается неверное количество аргументов, либо они не подходящих типов.
На самом деле, я понимаю конечно, что интерфейсы и классы — это привычно и удобно большинству.
На самом деле, я понимаю конечно, что интерфейсы и классы — это привычно и удобно большинству.
Вот именно «паталогия» овладевшая массами, диктует т.н. «правила» из которых и вылупился TypeScript.
Если я сейчас явно скажу, что TypeScript это обертка вокруг pure js в угоду тех, кто привык писать «true OOP», то меня закусают. Написали бы лучше нормальный модульный фреймворк без тормозов и глюков, где разрешили бы вот так (или похоже) организовывать синтаксис. Нет — надо влепить еще одну надстройку. Зачем? js требует именно того синтаксиса, который требует. И никак иначе. Подсветка, подсказки, навигация по методам? Да тот же нетбинс отлично с ней справляется. Как-то почему бы не оставить в покое js?
(только лишь личное мнение)
Если я сейчас явно скажу, что TypeScript это обертка вокруг pure js в угоду тех, кто привык писать «true OOP», то меня закусают. Написали бы лучше нормальный модульный фреймворк без тормозов и глюков, где разрешили бы вот так (или похоже) организовывать синтаксис. Нет — надо влепить еще одну надстройку. Зачем? js требует именно того синтаксиса, который требует. И никак иначе. Подсветка, подсказки, навигация по методам? Да тот же нетбинс отлично с ней справляется. Как-то почему бы не оставить в покое js?
(только лишь личное мнение)
Как же надоели эти неосиляторы яваскрипт.
Неосиляторы ассемблера, пишущие на высокоуровневых языках вас тоже раздражают? Только байткод?
Сравнение ассемблера с высокоуровниевыми языками совершенно неуместно, т к разница между яваскриптом и появляющимися обертками, которые транслируются в яваскрипт, не настолько велика.
Обычно основная проблема кроется в реализации ООП-подхода в яваскрипте, потому как там вместо обычной классовой модели используется делегирующее наследование на базе прототипов.
На мой взгляд лучше освоить прототипы (что не так уж и сложно, вопреки мнению большинства) и разрабатывать на нативном языке, а не плодить уровни абстракций, которые так любят протекать…
Обычно основная проблема кроется в реализации ООП-подхода в яваскрипте, потому как там вместо обычной классовой модели используется делегирующее наследование на базе прототипов.
На мой взгляд лучше освоить прототипы (что не так уж и сложно, вопреки мнению большинства) и разрабатывать на нативном языке, а не плодить уровни абстракций, которые так любят протекать…
Вы совершенно правы по поводу отличий в подходе к наследованию, но любая модель наследования, в любом случае, позволяет создавать уровни абстракции. И они могут «протекать» независимо от используемого подхода.
Во вторых, почему вы думаете, что разработчики не могут освоить прототипное наследование? Думаю, для многих классовое наследование может быть просто удобнее и привычнее. Работа с привычными инструментами влечет ускорение разработки.
Я согласен с тем, что использование классового наследования в JavaScript не имеет большого смысла, но мы же говорим уже о совершенно другом языке, который транслируется в JS.
Во вторых, почему вы думаете, что разработчики не могут освоить прототипное наследование? Думаю, для многих классовое наследование может быть просто удобнее и привычнее. Работа с привычными инструментами влечет ускорение разработки.
Я согласен с тем, что использование классового наследования в JavaScript не имеет большого смысла, но мы же говорим уже о совершенно другом языке, который транслируется в JS.
> почему вы думаете, что разработчики не могут освоить прототипное наследование?
Потому что людям неохота думать. Им подавай ООП в стиле C++/Java, все остальное воспринимается в штыки.
Потому что людям неохота думать. Им подавай ООП в стиле C++/Java, все остальное воспринимается в штыки.
Может прототипированное наследование не удобное?
Хотя нет, вы правы, просто все вокруг дураки.
Хотя нет, вы правы, просто все вокруг дураки.
> Может прототипированное наследование не удобное?
Отмазка, которую я постоянно слышу про прототипное ООП, функциональное программирование, ленивые вычисления и т.п. Людям очень сложно выходить за рамки своей зоны комфорта.
Отмазка, которую я постоянно слышу про прототипное ООП, функциональное программирование, ленивые вычисления и т.п. Людям очень сложно выходить за рамки своей зоны комфорта.
Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.
Есть контраргументы, а не фразы состоящие целиком из воды?
И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)
Есть контраргументы, а не фразы состоящие целиком из воды?
И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)
> Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.
1. Моделируйте задачу так, чтобы несколько уровней наследования не нужно было
2. Используйте extend (за примерами — в тот же ExtJS)
Ну и www.crockford.com/javascript/inheritance.html, особенно Conclusion.
> И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)
Я ничего не приписывал. Я просто написал, что отмазка «не удобно» является всего лишь отмазкой, которая с завидным упорством применяется людьми, которые на секунду выглянули за приделы своего C++-like мирка.
1. Моделируйте задачу так, чтобы несколько уровней наследования не нужно было
2. Используйте extend (за примерами — в тот же ExtJS)
Ну и www.crockford.com/javascript/inheritance.html, особенно Conclusion.
> И не надо мне приписывать того, что я не говорил(ленивые вычисления и т.п.)
Я ничего не приписывал. Я просто написал, что отмазка «не удобно» является всего лишь отмазкой, которая с завидным упорством применяется людьми, которые на секунду выглянули за приделы своего C++-like мирка.
1 — ответ в стиле одной известной IT компании: «Такого функционала нет — значит оно вам не нужно и держите наши продукты правильно» =)
Согласен с вами о необходимости использовать технологии, соответствующие задаче (если вы это имели ввиду), но кажется вы немного утрируете. Например, кому-то удобно ездить в автомобиле домой с работы (если он работает далеко от дома) а кто-то пытается убедить, что «вы из своего автомобильного мирка не видите прелести поездки на велосипеде», работаю в четырех кварталах. Пример натянутый, но суть постарался передать: «программируйте с использованием языка» (с).
Согласен с вами о необходимости использовать технологии, соответствующие задаче (если вы это имели ввиду), но кажется вы немного утрируете. Например, кому-то удобно ездить в автомобиле домой с работы (если он работает далеко от дома) а кто-то пытается убедить, что «вы из своего автомобильного мирка не видите прелести поездки на велосипеде», работаю в четырех кварталах. Пример натянутый, но суть постарался передать: «программируйте с использованием языка» (с).
> 1 — ответ в стиле одной известной IT компании: «Такого функционала нет — значит оно вам не нужно и держите наши продукты правильно» =)
Ну правильно, раз аргументов нет, надо заняться демагогией. Мозгов на понимание, что разные инструменты требуют разных подходов к моделированию задач, не хватило.
> Пример натянутый,
Именно. Любая аналогия, особенно с автомобилями, неверна.
Задам пару вопросов на засыпку:
— почему, когда берется в руки NoSQL, все наперебой кричат, что надо моделировать задачи, исходя из конкретного NoSQL-движка, а не опираясь на знания из мира реляционных баз данных?
— почему, когда берется в руки функциональное программирование, все наперебой кричат, что надо перестроить свое мышление, чтобы начать думать не в императивном стиле
— почему, когда берется в руки Javascript, внезапно виноват Javascript, что там прототипное наследование, и «оно нипанятно»?
Ну правильно, раз аргументов нет, надо заняться демагогией. Мозгов на понимание, что разные инструменты требуют разных подходов к моделированию задач, не хватило.
> Пример натянутый,
Именно. Любая аналогия, особенно с автомобилями, неверна.
Задам пару вопросов на засыпку:
— почему, когда берется в руки NoSQL, все наперебой кричат, что надо моделировать задачи, исходя из конкретного NoSQL-движка, а не опираясь на знания из мира реляционных баз данных?
— почему, когда берется в руки функциональное программирование, все наперебой кричат, что надо перестроить свое мышление, чтобы начать думать не в императивном стиле
— почему, когда берется в руки Javascript, внезапно виноват Javascript, что там прототипное наследование, и «оно нипанятно»?
Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.
Где вы такую глупость взяли? У меня вполне во фреймворке есть 4 уровня:
Geometry => Shape => Rectangle => RoundedRectangleИ оно отлично работает. И никакой сложности. Я даже особо не задумаюсь, если решу добавить ещё один уровень.
Ну что же вы стесняетесь?
Сказали А, говорите Б.
Покажите нам вашу реализацию.
Сказали А, говорите Б.
Покажите нам вашу реализацию.
var Rectangle = LibCanvas.declare( 'LibCanvas.Shapes.Rectangle', 'Rectangle', Shape ...
Дальше можно не продолжать…
Вы подтвердили мои слова.
Аргументируйте.
class Rectangle implements Shape
vs
declare = function (declareName, Parent, params) {
if (prototyping) return this;
params = methods.prepareParams(declareName, Parent, params);
// line break for more user-friendly debug string
var Constructor = function ()
{ return methods.construct.call(this, Constructor, arguments) };
// <debug> - should be removed on production
if (params.name) {
Constructor = new Function('con', 'return {"' + params.name + '": ' +
function(){ return con.apply(this, arguments) }
+ '}["' + params.name + '"];')(Constructor);
}
// </debug>
for (var i = 0, l = mutators.length; i < l; i++) {
mutators[i].fn( Constructor, params[mutators[i].name] );
}
Constructor.prototype.constructor = Constructor;
if (params.declareName) methods.define( params.declareName, Constructor );
return Constructor;
};
// Дальше идет ещё много-много кода
Дальше очевидное объяснять?
Вам сюда исходники Джавы кинуть? Или какого-нибудь Хибернейта? С глупой и бессмысленной фразой «Дальше очевидное объяснять?»
Вы хоть помните с чем не согласились?
Что послужило появление этой ветки?
Что послужило появление этой ветки?
Что послужило причиной*
Ага. Что наследование реализовать в ЖС тяжело.
Не тяжело. Слегка многословно, но хорошая библиотека устраняет эту проблему.
И что?
Зато в ответ я получаю невероятную гибкость.
Не тяжело. Слегка многословно, но хорошая библиотека устраняет эту проблему.
И что?
Зато в ответ я получаю невероятную гибкость.
Ваши слова:
А вот на самом деле мои слова:
Я показал различая сложности?
Показал.
p.s.
Вообще использование библиотеки для реализации базового функционала, мне видеться большим таким костылем. Но увы JS. Именно поэтому я так много смотрю в сторону CoffeeScript, TypeScript и Dart. Нужно для себя сделать выбор.
Ага. Что наследование реализовать в ЖС тяжело.
Не тяжело.
А вот на самом деле мои слова:
Не удобство наследования в JS заключается в сложной реализации более чем 1 уровня наследования.
Я показал различая сложности?
Показал.
p.s.
Вообще использование библиотеки для реализации базового функционала, мне видеться большим таким костылем. Но увы JS. Именно поэтому я так много смотрю в сторону CoffeeScript, TypeScript и Dart. Нужно для себя сделать выбор.
Я показал различая сложности?
Показал.
Ничего вы не показали. Просто кинули кусок кода библиотеки.
Вообще использование библиотеки для реализации базового функционала, мне видеться большим таким костылем.
Для реализации базового функционала в JS достаточно встроенных средств. Для большинства мелких приложений не надо юзать никаких либ.
Это всё-равно, что говорить, что Питон — такой большой костыль потому что в ПХП общение с веб-сервером встроено в язык. И ещё кинуть код Джанго в комметы как «доказательство очевидного».
Или Руби вместо Питона и кинуть код РоР в комменты. А потом добавить: «а пхп это прям в языке есть», Руби/Питон нуждается в костылях.
Почему вы не приводите код, реализующий ключевое слово implements?
Я как бы на то и намекаю, что я не писал ни строчки кода, что бы реализовать implements.
Кстати, забавный момент, когда я писал комментарий, я только раза 2 видел ts и вместо extends, я написал implements. И если на js реализовать extends возможно, то implements…
Кстати, забавный момент, когда я писал комментарий, я только раза 2 видел ts и вместо extends, я написал implements. И если на js реализовать extends возможно, то implements…
> Я как бы на то и намекаю, что я не писал ни строчки кода, что бы реализовать implements.
Не писали вы, писал кто-то другой. Или вам религия запрещает использовать чужие реализации?
> И если на js реализовать extends возможно, то implements…
Они внезапно чем-то сильно отличаются?
JS хорош тем, что в нем можно реализовать много чего: www.crockford.com/javascript/inheritance.html
Не писали вы, писал кто-то другой. Или вам религия запрещает использовать чужие реализации?
> И если на js реализовать extends возможно, то implements…
Они внезапно чем-то сильно отличаются?
JS хорош тем, что в нем можно реализовать много чего: www.crockford.com/javascript/inheritance.html
JavaScript can be used like a classical language, but it also has a level of expressiveness which is quite unique. We have looked at Classical Inheritance, Swiss Inheritance, Parasitic Inheritance, Class Augmentation, and Object Augmentation. This large set of code reuse patterns comes from a language which is considered smaller and simpler than Java.
…
Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.
Не писали вы, писал кто-то другой. Или вам религия запрещает использовать чужие реализации?
Для ts это native statement. Или вы хотите мне привести реализацию JS интерпретатора в коде ассемблера?
Они внезапно чем-то сильно отличаются?
Всем. Вы знакомы с интерфейсами?
> Для ts это native statement.
И?
> Всем. Вы знакомы с интерфейсами?
Чем — всем? С интерфейсами, знаком. И?
И?
> Всем. Вы знакомы с интерфейсами?
Чем — всем? С интерфейсами, знаком. И?
И?
Е! Я ещё много знаю гласных.
Хотите что-то узнать спрашивайте корректно и конкретно.
Чем — всем? С интерфейсами, знаком. И?
Вы похоже не знаете что такое интерфейсы и для чего они нужны, раз спрашиваете и приводите не корректную(в контексте обсуждения элементов языка) ссылку на какую то библиотеку.
> Хотите что-то узнать спрашивайте корректно и конкретно.
Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.
Повторю максимально простым языком:
То, что implements для ts — это ключевое слово, не значит, что где-то за ним не стоит какой-то код. Например, код компилятора/транслятора. Но вас это посему-то не смущает.
Но вот реализация extends, приведенная в этой ветке, вас почему-то смущает. Потому что вы видите ее код? Потому что она реализована в виде библиотеки, а не в виде кода внутри компилятора? Чем она вас смущает?
> Вы похоже не знаете что такое интерфейсы и для чего они нужны, раз спрашиваете
Я задал конкретный вопрос, на который вы так и не смогли ответить.
> приводите не корректную(в контексте обсуждения элементов языка) ссылку на какую то библиотеку.
Ссылку на библиотеку я не приводил. Я привел ссылку на краткое описание того, как в JS можно реализовать как «классическое» (C++-like) наследование, так и другие типы наследования. И, главное, я даже привел цитату, которую вы решили не читать и не понимать:
Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.
Повторю максимально простым языком:
То, что implements для ts — это ключевое слово, не значит, что где-то за ним не стоит какой-то код. Например, код компилятора/транслятора. Но вас это посему-то не смущает.
Но вот реализация extends, приведенная в этой ветке, вас почему-то смущает. Потому что вы видите ее код? Потому что она реализована в виде библиотеки, а не в виде кода внутри компилятора? Чем она вас смущает?
> Вы похоже не знаете что такое интерфейсы и для чего они нужны, раз спрашиваете
Я задал конкретный вопрос, на который вы так и не смогли ответить.
> приводите не корректную(в контексте обсуждения элементов языка) ссылку на какую то библиотеку.
Ссылку на библиотеку я не приводил. Я привел ссылку на краткое описание того, как в JS можно реализовать как «классическое» (C++-like) наследование, так и другие типы наследования. И, главное, я даже привел цитату, которую вы решили не читать и не понимать:
Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.
Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.
Я?! *удивление* Пожалуйста цитату приведите.
То, что implements для ts — это ключевое слово, не значит, что где-то за ним не стоит какой-то код. Например, код компилятора/транслятора. Но вас это посему-то не смущает.
Меня не смущает, т.к. это возможности языка, а не библиотеки.
Напоминаю, что мы сравниваем два языка между собой, а не код трансляторов и интерпретаторов языков.
Я привел ссылку на краткое описание того, как в JS можно реализовать как «классическое» (C++-like) наследование,
У меня нет желания вчитываться в абстрактные полотнища текстов.
Я «прошерстил» текст на наличие упоминания интерфейсов. Там этого не оказалось. Отсюда вывод, что ссылка ни коем образом не коррелирует с контекстом беседы.
И, главное, я даже привел цитату, которую вы решили не читать и не понимать
Зачем мне понимать чьё то мнение про поводу необходимость реализации чего-то в JS? Объясните?
> Напоминаю, что мы сравниваем два языка между собой, а не код трансляторов и интерпретаторов языков.
Напоминаю, что вы не сравниваете, а пытаетесь всех убедить, что C++-like наследование в JS реализовать сложно: habrahabr.ru/post/153077/?reply_to=5250583#comment_5229441
> У меня нет желания вчитываться в абстрактные полотнища текстов.
Я «прошерстил» текст на наличие упоминания интерфейсов.
Интерфейсы приплели только вы. Если для вас наследование ограничивается только и строго реаизацией интерфейсов, извините, о чем мы тут вообще говорим?
> Зачем мне понимать
Именно. У вас не стоит цели что-то понимать
Напоминаю, что вы не сравниваете, а пытаетесь всех убедить, что C++-like наследование в JS реализовать сложно: habrahabr.ru/post/153077/?reply_to=5250583#comment_5229441
> У меня нет желания вчитываться в абстрактные полотнища текстов.
Я «прошерстил» текст на наличие упоминания интерфейсов.
Интерфейсы приплели только вы. Если для вас наследование ограничивается только и строго реаизацией интерфейсов, извините, о чем мы тут вообще говорим?
> Зачем мне понимать
Именно. У вас не стоит цели что-то понимать
Напоминаю, что вы не сравниваете, а пытаетесь всех убедить, что C++-like наследование в JS реализовать сложно: habrahabr.ru/post/153077/?reply_to=5250583#comment_5229441
Там написано совершенно другое. Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи. Про реализацию C++-like наследования придумали вы.
Интерфейсы приплели только вы.
Я написал про интерфейсы. Я вообще завел речь про интерфейсы. Я же вообще стал говорить о их очень сложной реализации в JS(если вообще возможной)
Но вы начали говорить о том, что это можно сделать и приводить непонятные статьи не имеющие к этому никакого отношения. Это стали делать вы, т.к. процитировали мою запись с указанием implements.
P.S.
У вас в интересах стоит лингвистика, но вы умудрились абсолютно переврать смысл написанного собеседником, подменять понятия и вообще наговаривать, вот пример:
Ну вообще-то, это вы задаете вопросы и что-то пытаетесь спорить.
Позор.
> Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи.
Про что я написал, в частности
и
habrahabr.ru/post/153077/?reply_to=5251967#comment_5215845
Более того (повторяюсь) JS позволяет реализовывать различные способы наследования, а не только одну какую-либо концепцию.
Но вы упорно гнете «аааааа хочу интерфейсы».
Хорошо. Хотите. Вы способны ответить на один вопрос, ответа на который вы избегаете уже три сообщения подряд: в чем настолько большая разница между extends и implements?
> Я написал про интерфейсы. Я вообще завел речь про интерфейсы. Я же вообще стал говорить о их очень сложной реализации в JS(если вообще возможной)
Ветка с вашим участием вообще началась тут: habrahabr.ru/post/153077/?reply_to=5251967#comment_5207411 если что.
И началось там не с интерфейсов, а с наследования.
После чего у вас «несколько уровней наследования» ВНЕЗАПНО превратилось строго и исключительно в implements.
> вы умудрились абсолютно переврать смысл написанного собеседником, подменять понятия
Сначала объясните, как у вас «несколько уровней наследования» превратилось в разговор строго и исключительно про implements, а потом поговорим про подмену понятий
Про что я написал, в частности
Because objects in JavaScript are so flexible, you will want to think differently about class hierarchies. Deep hierarchies are inappropriate. Shallow hierarchies are efficient and expressive.
и
habrahabr.ru/post/153077/?reply_to=5251967#comment_5215845
Более того (повторяюсь) JS позволяет реализовывать различные способы наследования, а не только одну какую-либо концепцию.
Но вы упорно гнете «аааааа хочу интерфейсы».
Хорошо. Хотите. Вы способны ответить на один вопрос, ответа на который вы избегаете уже три сообщения подряд: в чем настолько большая разница между extends и implements?
> Я написал про интерфейсы. Я вообще завел речь про интерфейсы. Я же вообще стал говорить о их очень сложной реализации в JS(если вообще возможной)
Ветка с вашим участием вообще началась тут: habrahabr.ru/post/153077/?reply_to=5251967#comment_5207411 если что.
И началось там не с интерфейсов, а с наследования.
После чего у вас «несколько уровней наследования» ВНЕЗАПНО превратилось строго и исключительно в implements.
> вы умудрились абсолютно переврать смысл написанного собеседником, подменять понятия
Сначала объясните, как у вас «несколько уровней наследования» превратилось в разговор строго и исключительно про implements, а потом поговорим про подмену понятий
Мнение авторов какого то портала на счет многоуровневого наследования можете оставить при себе. О нем никто кроме вас не говорит. И зачем вы вообще заговорили не понятно.
Напоминаю, вы начали обращаться ко мне, а не я к вам. Я лишь обобщенно сравниваю два языка.
Вы начали навязывать мне мнение не относящееся к тематике — «возможности языков и сложность реализации конструкций в языка».
Мои слова, которые, вы не хотите читать, похоже:
Тут я говорил, что первоначальный мой тезис был не корректен, т.к. я использовал не правильный statement. И что если с многоуровневым наследованием(которое подразумевается в extends) не все так плохо в JS, то с интерфейсами там действительно проблема.
Где вы тут увидели
я понять не могу.
Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.
Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы. Отсылка к прочтению каких то больших текстов является не только плохим тоном, но и абсолютно не способствует понятию вашей мысли.
Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.
Напоминаю, вы начали обращаться ко мне, а не я к вам. Я лишь обобщенно сравниваю два языка.
Вы начали навязывать мне мнение не относящееся к тематике — «возможности языков и сложность реализации конструкций в языка».
После чего у вас «несколько уровней наследования» ВНЕЗАПНО превратилось строго и исключительно в implements.
Мои слова, которые, вы не хотите читать, похоже:
Кстати, забавный момент, когда я писал комментарий, я только раза 2 видел ts и вместо extends, я написал implements. И если на js реализовать extends возможно, то implements…
Тут я говорил, что первоначальный мой тезис был не корректен, т.к. я использовал не правильный statement. И что если с многоуровневым наследованием(которое подразумевается в extends) не все так плохо в JS, то с интерфейсами там действительно проблема.
Где вы тут увидели
Но вы упорно гнете «аааааа хочу интерфейсы».
я понять не могу.
Ветка с вашим участием вообще началась тут: habrahabr.ru/post/153077/?reply_to=5251967#comment_5207411 если что.
Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.
Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы. Отсылка к прочтению каких то больших текстов является не только плохим тоном, но и абсолютно не способствует понятию вашей мысли.
Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.
> Мнение авторов какого то портала на счет многоуровневого наследования можете оставить при себе. О нем никто кроме вас не говорит.
> И если на js реализовать extends возможно, то implements…
Повторю вопрос, на который вы упорно не хотите отвечать: В чем настолько большая разница между extends и implements?
> Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.
Где?
> Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы.
А ну да, я помню «Зачем мне понимать» ©
> Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.
Я уже написал, несколько раз. Причем подкрепил свое мнение ссылками и аргументами. Вы неспособны пока ответить даже на один простейший вопрос.
Я утверждаю, что реализация более чем 1 уровня наследования в JS сделано очень ну удобно, т.к. оно повышает сложность реализации задачи.
> И если на js реализовать extends возможно, то implements…
Повторю вопрос, на который вы упорно не хотите отвечать: В чем настолько большая разница между extends и implements?
> Проблему с многоуровневым прототипированным наследованием, реализованным в JS, мне кажется, я описал хорошо.
Где?
> Резюме мнения каких то людей, можете приводить где угодно, но не в дискуссии где требуют аргументы.
А ну да, я помню «Зачем мне понимать» ©
> Если же у вас нет желания четко высказать где люди ошибаются, то лучше вообще не писать.
Я уже написал, несколько раз. Причем подкрепил свое мнение ссылками и аргументами. Вы неспособны пока ответить даже на один простейший вопрос.
В ООП, реализованном через классовое наследование не нужно думать? Очень спорное утверждение.
А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше, то м.б. действительно лучше рассмотреть другие альтернативы? Я имею ввиду нормальных во всех отношениях разработчиков. На брейнфаке, к примеру, нужно думать достаточно.
Наследование обязано уменьшить сложность. А думать нужно всегда (мы же с вами на ИТ портале, где люди обычно думают).
А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше, то м.б. действительно лучше рассмотреть другие альтернативы? Я имею ввиду нормальных во всех отношениях разработчиков. На брейнфаке, к примеру, нужно думать достаточно.
Наследование обязано уменьшить сложность. А думать нужно всегда (мы же с вами на ИТ портале, где люди обычно думают).
Это самое наследование, прототипное, в JS было активно используемым далеко не всегда.
Пишу на JS с 1999 года, помню тег .
Ничто особенно не мешало мне и тогда писать нормальные «снежинки».
Пишу на JS с 1999 года, помню тег .
Ничто особенно не мешало мне и тогда писать нормальные «снежинки».
Тег LAYERS
Просто на JS уже пишут гораздо больше чем «снежинки» и текст, летающий за курсором мыши =)
Согласен, но даже сейчас лично мне далеко не всегда нужно наследование.
Точней, обычно оно мне вообще 300 лет не сдалось.
При этом я написал достаточно больших приложений, и уверен, что неплохо понимаю о чем говорю.
По идее, Наследование должно что-то там где-то там «Упрощать».
На мой взгляд кто-то излишне продвинутый когда-то придумал использовать прототипы JS для того, чтобы реализовать «классы». Но, мне продолжает казаться, что они задумывались совсем не для этой забавы. Соответственно, то, что понимается Вами под «наследованием» здесь не является тем что понимается под «прототипированием» мной.
Точней, обычно оно мне вообще 300 лет не сдалось.
При этом я написал достаточно больших приложений, и уверен, что неплохо понимаю о чем говорю.
По идее, Наследование должно что-то там где-то там «Упрощать».
На мой взгляд кто-то излишне продвинутый когда-то придумал использовать прототипы JS для того, чтобы реализовать «классы». Но, мне продолжает казаться, что они задумывались совсем не для этой забавы. Соответственно, то, что понимается Вами под «наследованием» здесь не является тем что понимается под «прототипированием» мной.
Скажите, а вы один работали над этими «большими» приложениями или там была команда хотя бы в человек *дцать?
Там была и есть команда в «дцать».
На последнем проекте активно используется Ext.JS, где как раз и используются все перечисленные методы «классовой деградации».
Естественно, в угоду синтаксису приходится злоупотреблять ими и мне :)
Но я отнюдь не могу сказать, что мне это сильно нравится :)
Т.е., если бы этого не было, я бы как-нибудь бы справился :)
Так же продолжаю массово пользовался jQ, т.к. «free».
Кроме того активно пишу расширения для браузеров, там тоже бывает нужно.
На ранних порах была самодельная библиотека, в которой, конечно же, было «прототипирование» объектов.
Для меня это как по «поворот хрусталика» — просто использовать правильный термин, тогда становится ясно «что подразумевается».
Т.е., мне нужен не Базовый Класс, а именно Прототип Объекта :)
Вот, Вы же, например, знаете, что можно написать:
К сожалению, встречаются кадры, которые, например, могут думать об этой конструкции разное, или вообще о ней ничего не знают.
Т.к. это «разрыв шаблона».
Но думать здесь нечего, это просто есть.
Вот примерно об этом пытаюсь донести.
На последнем проекте активно используется Ext.JS, где как раз и используются все перечисленные методы «классовой деградации».
Естественно, в угоду синтаксису приходится злоупотреблять ими и мне :)
Но я отнюдь не могу сказать, что мне это сильно нравится :)
Т.е., если бы этого не было, я бы как-нибудь бы справился :)
Так же продолжаю массово пользовался jQ, т.к. «free».
Кроме того активно пишу расширения для браузеров, там тоже бывает нужно.
На ранних порах была самодельная библиотека, в которой, конечно же, было «прототипирование» объектов.
Для меня это как по «поворот хрусталика» — просто использовать правильный термин, тогда становится ясно «что подразумевается».
Т.е., мне нужен не Базовый Класс, а именно Прототип Объекта :)
Вот, Вы же, например, знаете, что можно написать:
var myTheBest = function(){
}
myTheBest.SomeProperty = 111;
К сожалению, встречаются кадры, которые, например, могут думать об этой конструкции разное, или вообще о ней ничего не знают.
Т.к. это «разрыв шаблона».
Но думать здесь нечего, это просто есть.
Вот примерно об этом пытаюсь донести.
> В ООП, реализованном через классовое наследование не нужно думать?
Я этого не говорил
> А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше
Этого я тоже не говорил
Я этого не говорил
> А если (по вашим словам) в ООП, реализованном через прототипное наследование, нужно думать намного больше
Этого я тоже не говорил
Так, в том то и дело, что:
это в большинстве случаев и есть признак того, что человек не хочет разбираться.
Разработка на JS, или, если угодно Vanilla.JS может быть не менее, а порой и более быстрой, если принять язык таким, какой он есть.
для многих классовое наследование может быть просто удобнее
это в большинстве случаев и есть признак того, что человек не хочет разбираться.
Разработка на JS, или, если угодно Vanilla.JS может быть не менее, а порой и более быстрой, если принять язык таким, какой он есть.
Я очень хорошо разбираюсь в js, но люблю использоваться coffeescript, т.к. меня банально утомляет писать одни и теже конструкции для ООП-подхода, а весь этот синтаксический шум, который приходит вместе с js просто замыливает код и отвлекает внимание.
Ни в коем случае не критикую js, это прекрасный язык и я люблю его, но его выразительность оставляет желать лучшего.
Кстати пока я не нашел дыр в абстракции, предлагаемой coffeescript, даже такие безумные вещи как «new MyClass args...» не дают течи.
Поправьте меня, если ошибаюсь.
Ни в коем случае не критикую js, это прекрасный язык и я люблю его, но его выразительность оставляет желать лучшего.
Кстати пока я не нашел дыр в абстракции, предлагаемой coffeescript, даже такие безумные вещи как «new MyClass args...» не дают течи.
Поправьте меня, если ошибаюсь.
Немаловажная деталь, автор TypeScript — небезизвестный ru.wikipedia.org/wiki/Хейлсберг,_Андерс, один из основных авторов Dellhi и c#
Microsoft осуществили мою мечту! Статически типизированный JS с модулями!
Последние вести по поводу Javascript выглядят как репортажи с места боевых действий — постоянно появляются все направления развития этого языка и его инструментов. Динамика вокруг языка очень радует.
Ага, каждая пятая новость на хабре — «Посмотрите, у нас есть что-то похожее на js» или «Мы придумали новый транслятор с языка %language_name% на javascript»))
И отлично! Дальше уже Ваш выбор — вникать или пропустить мимо. Главное, что могут найтись заинтересованные люди, которым это может оказаться полезно. Даже если это никогда не пойдет в продакшн, все равно вдохновит других разработчиков, расширит взгляд на язык или просто доставит приятных минут дома за чашкой чая. Just for fun, как говорится :)
JavaScript — это Бейсик сего дня! (В хорошем смысле.)
Не знаю, как остальным, но мне всегда в JS нравилась схожая с С конвертация в bool (если быть точнее, работа оператора if похожая на работу в С).
получается такого не будет и придётся сочинять огород
Удобно было бы иногда использовать встроенный typecast
if (a.field) {
...
}
получается такого не будет и придётся сочинять огород
if (a.field != null && a.field != undefined) {
...
}
Удобно было бы иногда использовать встроенный typecast
Зря так думаете, такая вот конструкция вполне успешно компилируется:
На выходе в js она без изменений.
Как уже было сказано, TypeScript это лишь надмножество JavaScript.
var a = { field: {} };
if (a.field) {
}
На выходе в js она без изменений.
Как уже было сказано, TypeScript это лишь надмножество JavaScript.
Позвольте поправлю, в соответствии со спецификацией,
эквивалентно
так как != null проверяет на 'null' и 'undefined'.
что в строгом сравнении идентично
Первая констуркция совершенно бессмысленна, так как разворачивается в
if (a.field != null && a.field != undefined) {
эквивалентно
if (a.field != null) {
так как != null проверяет на 'null' и 'undefined'.
что в строгом сравнении идентично
if (a.field !== null && a.field !== undefined) {
Первая констуркция совершенно бессмысленна, так как разворачивается в
if ((a.field !== null && a.field !== undefined) && (a.field !== undefined)) {
Маленькая ремарка: правильнее писать не a !== undefined, а typeof a !== 'undefined'.
Так как в первом случае сначала произойдёт попытка получить значение 'a', а уже потом сравнивать с undefined.
После того как значение не будет найдено, в него произойдёт подстановка значения undefined.
typeof a !== 'undefined' не получает значение самой переменной 'a', а просто выясняет принадлежность типа, на который ссылается референс 'a'. В свою очередь может показаться что они эквивалентны, но лишь на уровне реализаций.
Так как в первом случае сначала произойдёт попытка получить значение 'a', а уже потом сравнивать с undefined.
После того как значение не будет найдено, в него произойдёт подстановка значения undefined.
typeof a !== 'undefined' не получает значение самой переменной 'a', а просто выясняет принадлежность типа, на который ссылается референс 'a'. В свою очередь может показаться что они эквивалентны, но лишь на уровне реализаций.
var a = null;
typeof a; //"object"
И тогда проверка typeof a !== 'undefined' валится, если вы работаете с Явой на бэкэнде и вам присылают явные null в ответах :(
не вижу противоречий
отлично отработает ваш случай.
но я бы рекоммендовал всегда писать в случаях если вам нужно проверить есть ли значение писать != null;
typeof a !== 'undefined' && a !== null
отлично отработает ваш случай.
но я бы рекоммендовал всегда писать в случаях если вам нужно проверить есть ли значение писать != null;
Ну я это и имел ввиду, что нельзя все проверки заменить только на typeof a !== 'undefined', надо обязательно проверять на null, если есть вариант, что придет null.
typeof a !== 'undefined' вообще использовать не надо. a != null отлично применяется практически для всего кода.
Мне лично система типов кажется несколько слабой. Скажем, если использовать closure compiler и проставлять везде аннотации, то можно составлять гораздо более интересные конструкции: параметризация Array.<тип>; объединение (тип1|тип2), nullable: тип?; описывать записи {поле: тип, поле2: тип2}. Подробнее описывается в документации.
При желании, CC можно сконфигурировать так, что он не будет компилировать код в случае нарушения типов или классификаторов доступа (аннотации private, @protected и т.п.). Код, при этом, будет оставаться вполне себе исполняемым и без компиляции.
В случае, если без привычного способа объявления классов совсем плохо, то можно использовать Traceur compiler тоже от Гугл, который реализует некоторые из фишечек следующей спецификации JS (те же классы, например) и работает по схожему принципу с Typescript (кросскомпиляция в наиболее поддерживаемое подмножество JS). Тут компиляция, разумеется, уже необходима.
При желании, CC можно сконфигурировать так, что он не будет компилировать код в случае нарушения типов или классификаторов доступа (аннотации private, @protected и т.п.). Код, при этом, будет оставаться вполне себе исполняемым и без компиляции.
В случае, если без привычного способа объявления классов совсем плохо, то можно использовать Traceur compiler тоже от Гугл, который реализует некоторые из фишечек следующей спецификации JS (те же классы, например) и работает по схожему принципу с Typescript (кросскомпиляция в наиболее поддерживаемое подмножество JS). Тут компиляция, разумеется, уже необходима.
В javascript добавляют статическую типизацию, в шарпы наоборот — динамическую. Забавая конвергенция.
>… в то время, как выпуск Dart кажется не вполне подготовленным.
Ибо Dart даже до m1 не дорос ещё.
Ибо Dart даже до m1 не дорос ещё.
у Microsoft есть и другие козыри в рукавах, например Koka
А еще в какой-то степени — ScriptSharp, конвертер C# в JavaScript, который разрабатывает один из архитекторов ASP.NET.
Старый сайт с примерами сломали, новый еще не сделали :(
scriptsharp.com/
Старый сайт с примерами сломали, новый еще не сделали :(
scriptsharp.com/
Насколько я знаю, Script# уже не разрабатывается, но есть альтернатива: www.saltarelle-compiler.com/
Интересно, надо посмотреть…
Еще одно возможное применение TypeScript — причесывать некрасивый JavaScript.
Например, так: gist.github.com/3814708
Например, так: gist.github.com/3814708
Ох если бы они сделали перегрузки еще
Если верить Language Specification, 6.3 Function Overloads, то они их сделали.
Я слепой, не видел спек, только глупый «Learn» ни о чем
На самом деле, как я понял, overloading у них или не до конца реализован, или реализован крайне странно (только на уровне объявления типа функции).
Ну судя по манулу, просто в итоговом коде создастся несколько функций с разными именами, и обращения к этим функциям (к какой из них) разрешаться еще в компайл-тайм, по-крайней мере это самый оптимальный способ
Е-мае… так сложно посмотреть 50 минутное видео?
channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript
(если лень смотреть все перемотайте на 12 минуту — там есть материал про function overload)
channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript
(если лень смотреть все перемотайте на 12 минуту — там есть материал про function overload)
А нет… извините… немного не понял вопрос… то что вы хотите получить можно получить вот так
class TestClass {
someMethod(stringParameter: string): void;
someMethod(numberParameter: number, stringParameter: string): void;
someMethod(stringOrNumberParameter: any, stringParameter?: string): void {
if (stringOrNumberParameter && typeof stringOrNumberParameter == "number")
alert("Variant #2: numberParameter = " + stringOrNumberParameter + ", stringParameter = " + stringParameter);
else
alert("Variant #1: stringParameter = " + stringOrNumberParameter);
}
}
var t = new TestClass()
t.someMethod("a");
t.someMethod(1, "a");Один из больших минусов сейчас — это то, каким образом можно дебажить (так, чтоб ставить брекпоинты в исходном .ts, отслеживать типы и т.д.
Может сокро source maps прикрутят… будет интересно.
А в целом, имхо лучше бы они в IE потехоньку подкручивали ES6. Например те же классы:
wiki.ecmascript.org/doku.php?id=harmony:classes
wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
Просто выходит что TypeScript — это просто чуть чуть улучшенный JS — так почему бы впилить его в IE.
Если сравнить с Dart:, так те намного более координально изменили синтаксис, сделали «нативное» выполнение хоть в одном броузере, обеспечили возможность «дебагинга» исходнгого кода.
Может сокро source maps прикрутят… будет интересно.
А в целом, имхо лучше бы они в IE потехоньку подкручивали ES6. Например те же классы:
wiki.ecmascript.org/doku.php?id=harmony:classes
wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
Просто выходит что TypeScript — это просто чуть чуть улучшенный JS — так почему бы впилить его в IE.
Если сравнить с Dart:, так те намного более координально изменили синтаксис, сделали «нативное» выполнение хоть в одном броузере, обеспечили возможность «дебагинга» исходнгого кода.
import http = module(«http»);
как это транслируется в _браузерный_ жаваскрипт?
как это транслируется в _браузерный_ жаваскрипт?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TypeScript: язык для разработки больших приложений на JavaScript