Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 217
Ну почему уже который раз мне говорят, что я прям обязан изучать javascript. Есть много интересных языков и технологий, я и без ваших советов разберусь, что буду изучать, а что нет.
Если вы еще не в курсе: JavaScript победил.
Да тут можно к каждому абзацу такую картинку лепить.
Типичный хейт-спич типично разработчика, который в жизни ничего кроме компилируемых классово-ориентированных языков со статической типизацией не видал, только под них писать и умеет и не испытывает никакого желания попытаться использовать средства и парадигмы иных платформ, а только ищет какую-нибудь приблуду, которая втиснет JS в привычное прокрустово ложе C++/C#/Java, нужное подчеркнуть.
отсутствие intellisense при наборе кода
Динамическая типизация, которая вызывает множество регрессионных ошибок.
Отсутствие модульности.
TypeScript добавляет возможность объявлять модули, классы и интерфейсы. Это позволяет масштабировать разработку сложных JavaScript приложений.
Типичный хейт-спич типично разработчика, который в жизни ничего кроме компилируемых классово-ориентированных языков со статической типизацией не видал, только под них писать и умеет и не испытывает никакого желания попытаться использовать средства и парадигмы иных платформ, а только ищет какую-нибудь приблуду, которая втиснет JS в привычное прокрустово ложе C++/C#/Java, нужное подчеркнуть.
Что дальше? Все совершенно обоснованно. JavaScript не был приспособлен для тех задач, которые на него в последнее время упали
А поподробнее? Для чего JS оказался неприспособлен?
Тяжёлые игры, серверы.
Что «тяжёлые игры, серверы»?
Ну, например, есть всякие системы логистики, системы документооборота (как электронного, так и бумажного), датамайнинг, и тому подобное, особенно интересно все это вместе.
Их наверное можно реализовать на js (почему нет), но это не тот инструмент.
Использовать как обертку — да, как ядро — не уверен. Наверное даже уверен, что нет.
Их наверное можно реализовать на js (почему нет), но это не тот инструмент.
Использовать как обертку — да, как ядро — не уверен. Наверное даже уверен, что нет.
Я так и не увидел подтверждения тезиса «JS не приспособлен для тех задач, которые на него в последнее время упали».
Каких конкретно задач? В чем выражается неприспособленность?
Каких конкретно задач? В чем выражается неприспособленность?
Мне кажется, что ZOXEXIVO, говорил не конкретных задачах, а о том, что в определенных кругах, появилось устойчивое мнение, что такой инструмент как JS — подойдет для решения ЛЮБОЙ задачи.
И многих, кто подбирает инструмент под задачу, удивляет эта уверенность.
И многих, кто подбирает инструмент под задачу, удивляет эта уверенность.
Вероятно, эта уверенность произрастает из того факта, что JavaScript действительно прекрасно приспособлен для очень широкого класса задач, особенно для прототипирования и бета-версий.
Похоже, что и вы крутитесь в определенном кругу задач, где яваскрипт вполне успешно их решает. Только не надо зацикливаться на вебе, не им единым. Хорошо, если вы не понимаете где ява скрипт вообще не подходит, приведу примеры: драйвера для устройств, сложная аналитика (слабо написать свой движок OLAP куба на яваскрипте?), формирование сложных структур в огромном количестве и их анализ, сложные игры (ну хоть дум напишите на яваскрипте — напишете, конечно, но какими усилиями? Или не напишете?), лингвистический анализ… В общем задачи выше среднего уровня без бекэндной поддержки яваскрипт просто сольет.
> драйвера для устройств
svay.com/blog/hacking-rfid-with-nodejs/
> сложная аналитика
Сложная-несложная, но, например, рейтинг а-ля IMDB я писал лично (top-books.info)
> формирование сложных структур в огромном количестве и их анализ
www.mapjs.org/
> сложные игры
media.tojicode.com/q3bsp/
Ещё примеры?
Можно ссылаться на отсутствие инструментов в какой-то области применения или на сравнительно более низкую производительность интерпретируемых динамически типизируемых языков. Однако если говорить о JavaScript как о языке программирования, я в упор не могу понять, какие такие особенности JS как языка программирования могут помешать написать на нём драйвер или OLAP куб. Какие такие есть преимущества у C++ как у языка программирования над JavaScript? Что на нём писать удобнее?
svay.com/blog/hacking-rfid-with-nodejs/
> сложная аналитика
Сложная-несложная, но, например, рейтинг а-ля IMDB я писал лично (top-books.info)
> формирование сложных структур в огромном количестве и их анализ
www.mapjs.org/
> сложные игры
media.tojicode.com/q3bsp/
Ещё примеры?
Можно ссылаться на отсутствие инструментов в какой-то области применения или на сравнительно более низкую производительность интерпретируемых динамически типизируемых языков. Однако если говорить о JavaScript как о языке программирования, я в упор не могу понять, какие такие особенности JS как языка программирования могут помешать написать на нём драйвер или OLAP куб. Какие такие есть преимущества у C++ как у языка программирования над JavaScript? Что на нём писать удобнее?
Системы реального времени невозможно писать в JS, многопоточные приложения (про WebWorker я знаю, он сильно ограничен в функционале, умеет только считать).
Помимо очевидного плюса, что Cи++ быстрее по производительности, Си++ и его инфраструктура заточены под крупные проекты и большие команды. В JS такого и близко нет.
Помимо очевидного плюса, что Cи++ быстрее по производительности, Си++ и его инфраструктура заточены под крупные проекты и большие команды. В JS такого и близко нет.
Почему системы реального времени невозможно написать на JS?
Многопоточные приложения пишутся в ноде из коробки
> Помимо очевидного плюса, что Cи++ быстрее по производительности, Си++ и его инфраструктура заточены под крупные проекты и большие команды. В JS такого и близко нет.
Расскажите, что вы понимаете под «инфраструктура заточена под крупные проекты» и почему инфраструктура JS/Node под них не заточена.
Многопоточные приложения пишутся в ноде из коробки
> Помимо очевидного плюса, что Cи++ быстрее по производительности, Си++ и его инфраструктура заточены под крупные проекты и большие команды. В JS такого и близко нет.
Расскажите, что вы понимаете под «инфраструктура заточена под крупные проекты» и почему инфраструктура JS/Node под них не заточена.
Почему системы реального времени невозможно написать на JS?
Потому что в языке нет ничего для этого. Как контролировать выполнение в реальном времени-то? Что JS вообще знает о своём приоритете в системе? Как узнать за какое гарантированное время выполнится кусок кода? Как узнать за какое время он выполнится, когда интерпретатор обновится?
Многопоточные приложения пишутся в ноде из коробки
Многопоточные приложения в на Пайтоне пишутся, только там GIL всю малину портит. Где в JS мьютексы, аторамные операции?
Расскажите, что вы понимаете под «инфраструктура заточена под крупные проекты» и почему инфраструктура JS/Node под них не заточена.Даже начинать этот разговор не хочу, если честно, конец недели, пятница, не хочу. Если есть хороший программист на Си++ рядом, то спросите его, он наверное даже покажет. Лучше будет, если программист занят в каком-то проекте, где работает пара десятков человек.
несмотря на то, что ваша позиция мне симпатична. В ноде нет многопоточности из коробки, есть event-loop. Много поточность довольно легко активировать с помощью вот такого замечательного npm-пакета (https://github.com/lloyd/node-compute-cluster).
svay.com/blog/hacking-rfid-with-nodejs/
По ссылке мы видим обертку над hidapi, написанной на С. Написать на JS драйвер режима ядра просто невозможно, потому что виртуальная машина не будет работать в режиме ядра.
Это как говоорить, что FirefoxOS написана на JS — миллион строк кода ядра линукса на C, миллион строк кода движка браузера на C++ и несколько (сотен) тысяч строк высокоуровневого кода на JS.
Рейтинг а-ля IMDB я писал лично (top-books.info)
Пользователь ставит оценки и мы получаем рейтинг как среднее арифметическое? А вы точно знаете, что такое сложная аналитика?
www.mapjs.org/
Откройте папочку src в разделе Download. Привет, С++! К тому же я очень сомневаюсь, что обработка действительно тяжелых данных может быть осуществлена на JS. Наличие библиотеки не доказывает ее эффективность.
media.tojicode.com/q3bsp/
Графика десятилетней давности. Это очень крутой и многообещающий протоип. Но не более того.
Ещё примеры?
Да, пожалуйста.
Да, пожалуйста.
Только сперва вы примеры всего того же на TypeScript
А при чем тут TypeScript? Если я правильно понимаю, в этой ветке обсуждается то, что некоторые считают, что JS можно и нужно использовать везде. От веб-браузеров до марсоходов. А другие отсталые личности, вроде меня, утверждают, что нельзя везде совать JS, а кое-где лучше обойтись Java, C++, или даже чистым C.
>> Написать на JS драйвер режима ядра просто невозможно, потому что виртуальная машина не будет работать в режиме ядра.
Тут все относительно — VM можно встроить в ядро(Singularity от МС, например). Можно даже выкинуть возможность запуска бинарников и оставить только скрипты/байткод в качестве исполняемых файлов. Главный вопрос — зачем бы?
оффтоп
Хотя, положить что-нибудь похожее на Erlang/Go в основу ОС было бы забавно. Микроядро, over 9000 процессов, everything is a process и так далее. Ощущается очень даже забавно.
/оффтоп
Тут все относительно — VM можно встроить в ядро(Singularity от МС, например). Можно даже выкинуть возможность запуска бинарников и оставить только скрипты/байткод в качестве исполняемых файлов. Главный вопрос — зачем бы?
оффтоп
Хотя, положить что-нибудь похожее на Erlang/Go в основу ОС было бы забавно. Микроядро, over 9000 процессов, everything is a process и так далее. Ощущается очень даже забавно.
/оффтоп
>svay.com/blog/hacking-rfid-with-nodejs/
не то. Если чел назвал свой скриптик общения с устройством драйвером, не стоит верить ему на слово. Почитайте об устройстве любой операционной системы, о кольцах оси и пр. вещи. Лень заниматься просветительской деятельностью. Да и вызов библиотечки написанной на СИ из яваскрипта как-то мне ничего не говорит о возможностях скрипта. Вызвать ее можно из-под чего угодно и это ни о чем не говорит.
>www.mapjs.org/
Не то. Я снова предлагаю вам написать на яваскрипте OLAP движок без использования скомпилированных библиотек низкого уровня. Скажем чтобы многомерный куб мог выдавать данные по различным срезам (а это поиск по десяткам и сотням параметров) из разнородных записей района сотни миллионов или даже миллиардов штук пусть и размещенных в памяти, но за время не больше 1й секунды, а то и за миллисекунды.
>media.tojicode.com/q3bsp/
насчет игры не знаю, но насколько я знаю, тут используется WebGL, который крутится на GPU, а ява скрипт только использует его как библиотеку. На GPU по умолчанию может крутиться только нативный код. Иначе просто смысла нет. Так что опять не в тему.
В общем, я вижу, что вы не в теме. Не вижу смысла обсуждать с вами эти вопросы. Почитайте книги.
не то. Если чел назвал свой скриптик общения с устройством драйвером, не стоит верить ему на слово. Почитайте об устройстве любой операционной системы, о кольцах оси и пр. вещи. Лень заниматься просветительской деятельностью. Да и вызов библиотечки написанной на СИ из яваскрипта как-то мне ничего не говорит о возможностях скрипта. Вызвать ее можно из-под чего угодно и это ни о чем не говорит.
>www.mapjs.org/
Не то. Я снова предлагаю вам написать на яваскрипте OLAP движок без использования скомпилированных библиотек низкого уровня. Скажем чтобы многомерный куб мог выдавать данные по различным срезам (а это поиск по десяткам и сотням параметров) из разнородных записей района сотни миллионов или даже миллиардов штук пусть и размещенных в памяти, но за время не больше 1й секунды, а то и за миллисекунды.
>media.tojicode.com/q3bsp/
насчет игры не знаю, но насколько я знаю, тут используется WebGL, который крутится на GPU, а ява скрипт только использует его как библиотеку. На GPU по умолчанию может крутиться только нативный код. Иначе просто смысла нет. Так что опять не в тему.
В общем, я вижу, что вы не в теме. Не вижу смысла обсуждать с вами эти вопросы. Почитайте книги.
Так не надо его использовать где-либо, кроме браузера. Все же просто.
Проблема в том, что нет статей от тех, кто знает, как строить архитектуру крупного проекта без модульности и удобного наследования, какие паттерны, приемы и хорошие практики есть в этой области. Лично я не представляю себе, как можно это сделать хотя бы без адекватных модулей.
Я соглашусь, что какой-то материал есть, но он не слишком широко распространен и не всегда отвечает на вопрос «как писать на JavaScript в соответствии с его собственной философией».
По широко распространенным методикам программирования с ориентацией на структурирование кода с помощью классов тонны книг и статей: как построить архитектуру с помощью классов, паттерны ООП с использованием классов и т. д.
Менее распространен материал, как хорошо писать на Python'е или процедурных языках. Но по поводу JS такого очень мало, и многие примеры материала нацелены именно на адаптацию знаний о программировании на языках с классами к ситуации с JS. Например, как организовать похожее на классы наследование, как реализовать те или иные паттерны из GOF. Опять же, многие профессиональные инструменты вроде TypeScript, CoffeeScript или Dart нацелены на то же самое.
Но одновременно с этим часто звучит мнение, что JavaScript просто непонятый и недооцененный. Это пробуждает мой интерес, но я не нашел пока материалов, которые показывали бы как использовать ту самую особенную философию JS во благо.
По широко распространенным методикам программирования с ориентацией на структурирование кода с помощью классов тонны книг и статей: как построить архитектуру с помощью классов, паттерны ООП с использованием классов и т. д.
Менее распространен материал, как хорошо писать на Python'е или процедурных языках. Но по поводу JS такого очень мало, и многие примеры материала нацелены именно на адаптацию знаний о программировании на языках с классами к ситуации с JS. Например, как организовать похожее на классы наследование, как реализовать те или иные паттерны из GOF. Опять же, многие профессиональные инструменты вроде TypeScript, CoffeeScript или Dart нацелены на то же самое.
Но одновременно с этим часто звучит мнение, что JavaScript просто непонятый и недооцененный. Это пробуждает мой интерес, но я не нашел пока материалов, которые показывали бы как использовать ту самую особенную философию JS во благо.
> Но одновременно с этим часто звучит мнение, что JavaScript просто непонятый и недооцененный. Это пробуждает мой интерес, но я не нашел пока материалов, которые показывали бы как использовать ту самую особенную философию JS во благо.
Ваше заявление выглядит несколько странно. Минимального желания достаточно для того, чтобы найти такие материалы — по философии JavaScript и по парадигмам написания проектов на JavaScript.
Must-have набор для любого желающего познакомиться с вопросом — это «JavaScript: The Definitive Guide» Джона Флэнагана, «JavaScript: The Good Parts» Дугласа Крокфорда, «Pro JavaScript Techniques» Джона Резига и «JavaScript Patterns» Стояна Стефанова. Мало какой язык, помимо конечно C/C++ и русского, может похвастаться такой богатой литературой.
Ваше заявление выглядит несколько странно. Минимального желания достаточно для того, чтобы найти такие материалы — по философии JavaScript и по парадигмам написания проектов на JavaScript.
Must-have набор для любого желающего познакомиться с вопросом — это «JavaScript: The Definitive Guide» Джона Флэнагана, «JavaScript: The Good Parts» Дугласа Крокфорда, «Pro JavaScript Techniques» Джона Резига и «JavaScript Patterns» Стояна Стефанова. Мало какой язык, помимо конечно C/C++ и русского, может похвастаться такой богатой литературой.
Зря так категорично.Я например написал большой HTML5 фреймворк- на javascript.
Там более 15000 строк кода. От перевода на typescript он только выиграет. Его легче потом будет использовать.
Там более 15000 строк кода. От перевода на typescript он только выиграет. Его легче потом будет использовать.
Ответ на этот вопрос прямо в первом абзаце. Я до недавнего тоже скептически относился к js. Ниче, отпустило.
Пока в TypeScript не появятся generic типы, я не собираюсь его воспринимать всерьез как язык разработки бизнес-приложений. Зато потом LINQ-подобные тулкиты пишутся за вечер.
Дженерики нужны только в языках со статической типизацией.
И как это реализовать в языках без статической типизации? Генерировать код для каждого класса отдельно?
Подразумевается возможность автокомплита в выражениях, без них и js справляется
var results =
SomeCollection
.Where(c => c.SomeProperty < 10)
.Select(c => new {c.SomeProperty, c.OtherProperty});
Подразумевается возможность автокомплита в выражениях, без них и js справляется
Я и сейчас использую автокомплит в JS, ЧТЯДНТ?:) В WebStorm очень хороший автокомплит, особенно если js-doc прописать.
Мне кажется, вы не уловили идею. Ну, например, я хочу написать метод-расширение, который будет перемешивать любую коллекцию. С обобщенными типами это делается в полпинка. Для js же придется придумывать, как генерировать эти методы для разных типов (не вручную же все это писать). Ну и LINQ туда же.
Дженерики нужны в статической типизации потому, что в C++ вы не можете (пример, конечно, идиотский) передать
Честно говоря, я и правда не улавливаю, как это связано с LINQ, тем более, что подобные библиотеки уже есть.
В JS такой проблемы нет. Если проблема только в интеллисенсе, то можно в js-doc указать, что типа аргумента —
float в метод, который по сигнатуре принимает int. Чтоб не писать два метода, пишут шаблонный метод. Честно говоря, я и правда не улавливаю, как это связано с LINQ, тем более, что подобные библиотеки уже есть.
В JS такой проблемы нет. Если проблема только в интеллисенсе, то можно в js-doc указать, что типа аргумента —
Number, то хороший редактор нам подскажет, что у этого аргумента можно вызвать метод, например, toPrecision. Чтобы перемешать коллекцию, достаточно чтобы у нее было свойство length и оператор доступа по ключу (посмотрите тут реализацию метода _.shuffle)Ок, вы правы, я чушь написал. Если считать, что умный редактор всегда сможет понять SomeCollection.Where(c => c.SomeProperty < 10), то такой уж большой проблемы, наверное, нет.
Как вы в js-doc укажете, что тип результата почти совпадает с типом аргумента? Поймет ли редактор этот факт, если не указать ничего?
function Foo(x) {
var ret = {};
for (key in x)
ret[key] = x[key];
return ret;
}
/**
* @param {X} x
* @return {Y}
*/
function foo(x) {
var ret = new Y;
for (var key in x)
ret[key] = x[key];
return ret;
}И как в вашем случае редактор поймет, что после выполнения следующего кода
объект a имеет поля x и y, а объект b — y и z?
var a = foo({x:10, y:20});
var b = foo({y:30, z:40});
объект a имеет поля x и y, а объект b — y и z?
Если правильно объявить типы X и Y, то нет проблем.
Что значит «типы X и Y»? Обратите внимание уже наконец-то, что функция foo вызывается с разными типами аргументов на входе, и тип возвращаемого значения совпадает с типом аргумента, но не известен на момент написания foo!
Я не пойму никак, вы чего хотите-то от динамического языка, в котором можно на лету и прототип подменить и метод переопределить? Сильный AI еще не создали.
Я хочу, чтобы после написания foo({x:10, y:20}) и нажатия точки мне редактор подсказал, что у данного объекта есть поля x и y. А после написания foo({y:10, z:20}) редактор должен подсказать, что у объекта есть поля y и z.
Для этого не нужен AI, для этого нужен просто некоторый синтаксис, который позволил бы объяснить редактору, что тип выходного значения функции заранее неизвестен, но в точности равен типу входного значения.
Именно этот синтаксис и называется «дженерики». Да, javascript — язык с динамической типизацией, и дженерики его интерпретатору совершенно не нужны. Но для редактора дженерики стали бы неплохой фичей.
Для этого не нужен AI, для этого нужен просто некоторый синтаксис, который позволил бы объяснить редактору, что тип выходного значения функции заранее неизвестен, но в точности равен типу входного значения.
Именно этот синтаксис и называется «дженерики». Да, javascript — язык с динамической типизацией, и дженерики его интерпретатору совершенно не нужны. Но для редактора дженерики стали бы неплохой фичей.
Не вижу практического применения, простите. Приведите более приближенный к реальности пример?
Вам же сверху писали: аналог LINQ из C#.
Задача-минимум — объяснить редактору, что r — коллекция объектов типа Foo.
Задача-максимум — объяснить редактору, что функция, переданная в Where, принимает параметр типа Foo, не добавляя к ней js-doc.
Еще раз подчеркиваю: объяснить нужно редактору. Интерпретатор и так разберется, это очевидно и даже не обсуждается.
var source = [
new Foo(...),
new Foo(...),
new Foo(...),
];
var r = source.Where(function(foo) {...});
Задача-минимум — объяснить редактору, что r — коллекция объектов типа Foo.
Задача-максимум — объяснить редактору, что функция, переданная в Where, принимает параметр типа Foo, не добавляя к ней js-doc.
Еще раз подчеркиваю: объяснить нужно редактору. Интерпретатор и так разберется, это очевидно и даже не обсуждается.
var f = constructors[prompt('enter constructor name')];
var source = [
new f(...),
new f(...),
new f(...),
];
var r = source.Where(function(foo) {...});Как вы объясните это редактору?
Чисто теоретически, придумайте свой синтаксис.
А что в этом коде предполагается дальше делать с коллекцией r, которая теперь содержит элементы неизвестного типа? Собственно, не ясно даже, что может содержаться в функции-фильтре. Скорее всего, дальше весь код будет написан в таком же стиле (вызов других фунцкий из других массивов), и подсказка редактора не понадобится.
С другой стороны, если типы могут быть не любыми, а содержащими некоторое обязательное поле (скажем, id), то это можно объяснить редактору, если объявить массив constructors как что-то вроде {Array}<{Constructor}<T>> where T extends BaseType. Или просто {Array}<{Constructor}<BaseType>>.
С другой стороны, если типы могут быть не любыми, а содержащими некоторое обязательное поле (скажем, id), то это можно объяснить редактору, если объявить массив constructors как что-то вроде {Array}<{Constructor}<T>> where T extends BaseType. Или просто {Array}<{Constructor}<BaseType>>.
если типы могут быть не любыми … extends BaseType
/**
* @param {BaseType[]} f
*/
function filter (foo) {…}
А что в этом коде предполагается дальше делать с коллекцией r, которая теперь содержит элементы неизвестного типа?
Ну вот то-то и оно. Либо мы и так знаем, что там лежит (скажем, это виджеты, и у каждого мы вызываем метод render), либо мы не знаем вообще ничего и тогда вся эта петрушка не имеет смысла.
Имеет. На момент использования метода Where (или, скажем, forEach) мы знаем, что лежит в коллекции, но на момент написания метода — нет.
Один и тот же метод forEach может быть применен как к коллекции виджетов, с целью вызвать метод render, так и к коллекции соединений, с целью разослать сообщение всем получателям.
Как программист, написавший
В то же время, программист, написавший
Один и тот же метод forEach может быть применен как к коллекции виджетов, с целью вызвать метод render, так и к коллекции соединений, с целью разослать сообщение всем получателям.
Как программист, написавший
widgets.forEach(function(widget) { widget.render(); });
connections.forEach(function(connection) { connection.send(message); });
В то же время, программист, написавший
реализацию Array.forEach,
об этом просто не может знать.Array.prototype.forEach = function forEach( callback, thisArg ) {
var T, k;
if ( this == null ) {
throw new TypeError( "this is null or not defined" );
}
// 1. Let O be the result of calling ToObject passing the |this| value as the argument.
var O = Object(this);
// 2. Let lenValue be the result of calling the Get internal method of O with the argument "length".
// 3. Let len be ToUint32(lenValue).
var len = O.length >>> 0; // Hack to convert O.length to a UInt32
// 4. If IsCallable(callback) is false, throw a TypeError exception.
// See: http://es5.github.com/#x9.11
if ( {}.toString.call(callback) !== "[object Function]" ) {
throw new TypeError( callback + " is not a function" );
}
// 5. If thisArg was supplied, let T be thisArg; else let T be undefined.
if ( thisArg ) {
T = thisArg;
}
// 6. Let k be 0
k = 0;
// 7. Repeat, while k < len
while( k < len ) {
var kValue;
// a. Let Pk be ToString(k).
// This is implicit for LHS operands of the in operator
// b. Let kPresent be the result of calling the HasProperty internal method of O with argument Pk.
// This step can be combined with c
// c. If kPresent is true, then
if ( Object.prototype.hasOwnProperty.call(O, k) ) {
// i. Let kValue be the result of calling the Get internal method of O with argument Pk.
kValue = O[ k ];
// ii. Call the Call internal method of callback with T as the this value and
// argument list containing kValue, k, and O.
callback.call( T, kValue, k, O );
}
// d. Increase k by 1.
k++;
}
// 8. return undefined
};Когда мы на момент написания итератора не знаем, коллекцию чего именно мы будем итерировать, на сцене появляется Array.prototype.map
И чем этот map нам поможет? Или вы думаете, что от смены имени метода что-то меняется?
Вот я написал:
Редактор поймет, какого типа элементы массива r? Если не поймет, то разве это хорошо? А если поймет, то это костыль специально для map или решение, применимое в общем случае?
Для случая с костылем:
Костыль по-прежнему работает?
Вот я написал:
var source = [...];
var r = source.map(function(arg) { return new Foo(...);});
Редактор поймет, какого типа элементы массива r? Если не поймет, то разве это хорошо? А если поймет, то это костыль специально для map или решение, применимое в общем случае?
Для случая с костылем:
var map = Function.prototype.call.bind(Array.prototype.map);
var source = [...];
var r = map(souce, function(arg) { return new Foo(...);});
Костыль по-прежнему работает?
А меня вполне устроит, если это не будет возможно объяснить редактору. Хотите вводить хоть весь текст программы через prompt, это ради Бога :)
Но для большинства классических сценариев аналог обобщенных типов — это именно то, что очень хочется видеть в TypeScript.
Но для большинства классических сценариев аналог обобщенных типов — это именно то, что очень хочется видеть в TypeScript.
TypeScript — язык со статической типизацией. Но без поддержки рантайма и библиотек — мало что выйдет. Хотя сделать тип Array в TS принципиально ничего не мешает.
Начали за здравие (JavaScript), окончили за упокой (TypeScript).
TypeScript написан на TypeScript....- это как?
Так же, как компилятор C++ написан на C++.
В связи с чем нельзя доверять скомпилированному коду.
Как и компилятор CoffeeScript написан на CoffeeScript (http://en.wikipedia.org/wiki/Self-hosting)
А почему не CoffeeScript? Он тоже транслируется в JavaScript, а про преимущество статической типизации я бы ещё поспорил. Кроме всего прочего в нём есть маппинг для дебага приложения прямо в браузере.
Не всякий JavaScript предназначен для работы в браузере, бывают и серверные (node.js) решения
Мое личное мнение, но CoffeeScript ушел куда-то в сторону от оригинального Javascript-а. Дополнить синтаксис — одно, менять (иногда кардинально) другое…
Наверно он больше подходит не для программистов C(++/#), Java… ;)
Наверно он больше подходит не для программистов C(++/#), Java… ;)
По личному опыту — очень даже подходит для программистов JS/C++/Java. CoffeeScript выглядит совсем по другому, но на порядок выразительнее и лаконичнее чем обычный JS. Сначала он кажется необычным, но к сахару быстро привыкаешь и это увеличивает скорость разработки и повышает читабельность (чего стоят только значения параметров по умолчанию или циклы).
TypeScript — надмножество JS. Я в проектах брал JS файлы, переименовывал на .ts и правил возникшие ошибки. С CoffeeScript, к сожалению, так не выйдет.
js2coffee.org вам в руки.
Хотя, конечно же, свои проблемы там тоже есть, в частности с классами.
Хотя, конечно же, свои проблемы там тоже есть, в частности с классами.
<notForHolyWar>Скажу очень субъективное. На CoffeeScript, пытался перейти раз пять. Как человек почти все 90-е писавший на С/С++, я до сих пор просто не воспринимаю блоки кода без фигурных скобок. Т.к. работаю над довольно крупными проектами, каждый раз спрашивал себя глядя на код CoffeeScript: «Хочу я каждый день видеть несколько тысяч строк вот этого перед глазами?». Пять раз ответ был отрицательный.
</notForHolyWar>А на TypeScript перешёл за полчаса. Причём местами просто сердце щемило в стиле «Где же ты был все эти годы?!!».
Как человек, который очень любит C++ и программировавший на них конечно поменьше вашего (7+ лет), но всё же могу сказать, что отсутствие скобочек — это действительно очень субьективно: тот же Python без скобочек и ничего :)
А вот чего меня напрягает во всей этой истории с TypeScript — так это именно участие MS — не поймите меня неправильно, я лично против компании ничего не имею, но вот они наверняка будут развивать инфраструктуру разработки только под Windows (насчёт инфраструктуры ни о каком open-source тут и речи быть не может). Понятно, что язык и компилятор — опенсорс, и вроде никто не запрещает развивать обвязку и на других платформах — но практика показывает, что это не очень-то работает без поддержки крупных компаний.
Вот и получится, что опять MS загонит разработчиков под своё крыло и на свои системы…
Скажу честно, как ушёл от Windows на Linux — вздохнул с каким-то облегчением: одна консоль там стОит того, чтобы разработчику уйти от Винды…
А вот чего меня напрягает во всей этой истории с TypeScript — так это именно участие MS — не поймите меня неправильно, я лично против компании ничего не имею, но вот они наверняка будут развивать инфраструктуру разработки только под Windows (насчёт инфраструктуры ни о каком open-source тут и речи быть не может). Понятно, что язык и компилятор — опенсорс, и вроде никто не запрещает развивать обвязку и на других платформах — но практика показывает, что это не очень-то работает без поддержки крупных компаний.
Вот и получится, что опять MS загонит разработчиков под своё крыло и на свои системы…
Скажу честно, как ушёл от Windows на Linux — вздохнул с каким-то облегчением: одна консоль там стОит того, чтобы разработчику уйти от Винды…
JetBrains вполне активно развивает поддержку TypeScript в WebStorm. А уж nodejs и подавно запускается где угодно. Не вижу проблем.
А уж nodejs и подавно запускается где угодно.К сожалению, на Android ещё никто, вроде бы, успешно не запустил. (Проект anode далёк от завершения, например.)
Запускаться-то он запускается, только вот, например, на windows 7 x64 я несколько раз сталкивался с тем, что не мог установить пакеты, точнее они не компилировались. Один из последних — node-canvas. Вообще, последнее время все больше работаю с опен-сорс продуктами и windows все больше тяготит — то это на windows запустить нельзя, то другое, то третье не компилируется, то пятое работает непойми как. И это понятно, люди, которые пишут опен-сорс, делают это в основном не на windows. Поэтому сейчас я пока на виртуалках, но уже чувтвую, что скоро совсем смогу отказаться от платформы win.
Не знаю, я тоже поначалу на питона/руби смотрел как на нечто.
Но потом проникся и щас приходится писать на php и весьма некоторые вещи огорчают.
Так что отсутствие скобок это скорее эволюция.
А так по сути своей этот кофескрипт — больше его даже наверное надо назвать rubyscript — он от руби берёт часть фишек.
Дурацкие браузеры, когда они уже научатся по-дефолту понимать руби/питона? Тот же яваскрипт пусть живёт, но писать на более красивом языке мне больше нравится.
Но потом проникся и щас приходится писать на php и весьма некоторые вещи огорчают.
Так что отсутствие скобок это скорее эволюция.
А так по сути своей этот кофескрипт — больше его даже наверное надо назвать rubyscript — он от руби берёт часть фишек.
Дурацкие браузеры, когда они уже научатся по-дефолту понимать руби/питона? Тот же яваскрипт пусть живёт, но писать на более красивом языке мне больше нравится.
Ну так CoffeeScript, если я не ошибаюсь, — это смесь(в основном) Ruby, Python, Haskell и Erlang.
Всецело поддерживаю. Такое ощущение, что в Майкрософт снова у кого-то NIH синдром причем эти люди не осилили прототипное ООП и динамическую типизацию.
Поживем — увидим, во что это выльется, большевелосипедов языков — больше разнообразия.
Поживем — увидим, во что это выльется, больше
За все время существования JS практика показала что люди довольно слабо осиливают прототипную модель. Чаще всего все сводится к паттернам, которые эмулируют классы и наследование. В TS реши не мудрствовать и запилили генерацию этих самых паттернов.
В ECMAScript 6 будут классы (proposal, реализация уже есть, например, в V8). Разработчики стандарта ECMAScript тоже не осилили прототипное ООП? :)
Сдались под давлением общественности.
Ну так это просто синтаксический сахар. Прототипы никуда не денутся.
Лично для меня ES6 классы — это:
1) декларативное описание иерархическое наследование (как у C/C++/Java)
2) унификация обьявления классов (вместо собственного велосипеда)
Лично для меня ES6 классы — это:
1) декларативное описание иерархическое наследование (как у C/C++/Java)
2) унификация обьявления классов (вместо собственного велосипеда)
Он придуман не Microsoft :)
В TypeScript тоже есть.
Мужик из MS показывал дебаг в IE и в Chrome на html5Camp.
Мужик из MS показывал дебаг в IE и в Chrome на html5Camp.
Такой же маппинг из коробки есть и в TypeScript (речь ведь о source map?)
Для TS тоже есть такое же отображение исходного кода для отладки в броузере.
Я правильно понимаю, что он просто оборачивает модуль в функцию-обертку, при компиляции в JS?
Ну и в чем тогда здесь преимущество? С тем же успехом я сам могу вынести часть кода в отдельный файл .js и назвать его «модулем»…
Ну и в чем тогда здесь преимущество? С тем же успехом я сам могу вынести часть кода в отдельный файл .js и назвать его «модулем»…
А преимущество заключается в intellisence и возможности рефакторинга… Если же по тем или иным причинам в рамках статической типизации станет тесно, то всегда можно добавить пару модулей на чистом js
>>А преимущество заключается в intellisence и возможности рефакторинга
Да, ребята вместо того чтобы реализовать нормально intellisence и возможности рефакторинга в своей IDE (для javascript это действительно сложно, кто ж спорит) просто взяли и наколбасили новый язык, для которого эти фичи в IDE реализовать проще.
Не находите ли вы, что такой подход дурно пахнет?
Да, ребята вместо того чтобы реализовать нормально intellisence и возможности рефакторинга в своей IDE (для javascript это действительно сложно, кто ж спорит) просто взяли и наколбасили новый язык, для которого эти фичи в IDE реализовать проще.
Не находите ли вы, что такой подход дурно пахнет?
Да, оборачивается в обертку, например по схеме AMD. Но тут вся прелесть — в том что в программе подключение выглядит а-ля:
Т.е. многие вложенные скобочки становятся оберткой класса — а не анонимных функций. Эстетика конечно, но удобная.
Вы можете с любым успехом не пользоваться ничем «сахарным», это ведь Ваш выбор.
using Namespace.Module;, которое транслируется в валидные команды.Т.е. многие вложенные скобочки становятся оберткой класса — а не анонимных функций. Эстетика конечно, но удобная.
Вы можете с любым успехом не пользоваться ничем «сахарным», это ведь Ваш выбор.
При указании значения «amd» для опции компилятора TypeScript "--module" из вот такого объявления модуля:
вы получаете AMD модуль для requireJS:
Также есть для этой опции значение «commonjs», которое генерирует код для NodeJS.
Преимущество: более внятный и компактный код.
export module depModule {
export class A {
}
}
вы получаете AMD модуль для requireJS:
define(["require", "exports"], function(require, exports) {
(function (depModule) {
var A = (function () {
function A() { }
return A;
})();
depModule.A = A;
})(exports.depModule || (exports.depModule = {}));
})
Также есть для этой опции значение «commonjs», которое генерирует код для NodeJS.
Преимущество: более внятный и компактный код.
Действительно, по моим наблюдениям многие разработчики обходят JavaScript стороной. Я вижу несколько причин. Во-первых, для многих смена парадигмы после языков вроде C++ или Java дается нелегко. Во-вторых, JavaScript настолько простой и в то же время гибкий, что для написания серьезных приложений на нем надо быть хорошим разработчиком — уметь проектировать, понимать теорию (замыкания, прототипы и пр.), выбирать парадигму разработки в зависимости от задач. Язык здесь не поможет, не накладывает ограничений. (Грубо говоря, это как уметь писать код без отладчика) Наконец, в головах многих разработчиков не на «передовой» технологий JavaScript — это что-то несерьезное, что-то «для веб-формочек».
А жаль, потому как JavaScript потрясающе развивает голову, заставляет мыслить на другом уровне. Да и спрос есть, а кадров мало. Смотрите сколько вакансий. А настоящего JS-ниндзя не найти, проверено на опыте в последние две недели.
TypeScript — очень интересная штука судя по обзорам. Но надо пробовать его на серьезных проектах, а не на небольших примерах. Будет ли там такой же красивый JS-код на выходе? Лично для меня большой минус — привязка к платформе. Как только появятся кроссплатформенные инструменты и плагины для того же Eclipse, можно будет пробовать в рабочем процессе. Или, может быть, уже что-то есть?
А жаль, потому как JavaScript потрясающе развивает голову, заставляет мыслить на другом уровне. Да и спрос есть, а кадров мало. Смотрите сколько вакансий. А настоящего JS-ниндзя не найти, проверено на опыте в последние две недели.
TypeScript — очень интересная штука судя по обзорам. Но надо пробовать его на серьезных проектах, а не на небольших примерах. Будет ли там такой же красивый JS-код на выходе? Лично для меня большой минус — привязка к платформе. Как только появятся кроссплатформенные инструменты и плагины для того же Eclipse, можно будет пробовать в рабочем процессе. Или, может быть, уже что-то есть?
Если на чём-то можно что-то написать, это ещё не значит, что на этом нужно писать.
TypeScript в действии
При наборе кода в VisualStudio доступна богатая подсказка
Самая важная фича, остальное можно не читать!
А серьёзно — описана среда разработки. Из статьи, можно только сделать вывод что MS не потянула сделать нормальную IDE для самого кроссплатформенного языка и пришлось упрощать язык.
И не только MS. Eclipse тоже с javascript не сильно дружит.
А уж такие вещи, как
Может, кто-нибудь знает среды, которые воспринимают подобный код, и не ограничивают программиста в использовании возможностей языка?
function Queue() { };
Queue.prototype.enqueue = function queue_enqueue(...) {...};
var q = new Queue();
А уж такие вещи, как
!function() {
this.foo = ...;
}();
Может, кто-нибудь знает среды, которые воспринимают подобный код, и не ограничивают программиста в использовании возможностей языка?
К сожалению, комплишин, рефакторинги и навигация, все равно очень не точные. Это далеко, что мы имеем в Java или C#. Вообще, же из-за того что язык динамически типизированный, задачи эти в общем случае не разрешимые.
Такие вещи, как
!function() {
this.foo = ...;
}();
Почему же? В Visual Studio очень мощные инструменты для работы с JS. Также поддерживается intellisense и doc-comments, поддерживается интерактивная отладка.
Но это не помогает в борьбе со сложностью самого языка, в отличие от TypeScript. Я в статье обозначил проблемы, на решение которых направлен TypeScript.
Но это не помогает в борьбе со сложностью самого языка, в отличие от TypeScript. Я в статье обозначил проблемы, на решение которых направлен TypeScript.
А вы давно пробовали студией пользоватся для написания javascript?
TypeScript мне нравится, но для полноценности языка — что позволило бы перейти от этапа «дома экспериментирую с новой игрушкой» к полноценному применению — на данный момент не хватает двух вещей:
1. Partial classes. Миксины на идеологию TypeScript ложатся плохо, зато трейты (как в Scala или, внезапно, PHP 5.4) — идеально. И скомпилировать легко: для трейта делается функция-конструктор, выбрасывающая исключение при попытке вызова, с нужными функциями в прототипе; из прототипа же функции копируются в класс, использующий трейт.
2. Generics. Тут, в принципе, вообще достаточно compile time проверки («type erasure» в терминологии TypeScript).
Еще очень хочется await/defer из IcedCoffeeScript, но это противоречит идеологии «комилируемся в очевидный читаемый JS».
1. Partial classes. Миксины на идеологию TypeScript ложатся плохо, зато трейты (как в Scala или, внезапно, PHP 5.4) — идеально. И скомпилировать легко: для трейта делается функция-конструктор, выбрасывающая исключение при попытке вызова, с нужными функциями в прототипе; из прототипа же функции копируются в класс, использующий трейт.
2. Generics. Тут, в принципе, вообще достаточно compile time проверки («type erasure» в терминологии TypeScript).
Еще очень хочется await/defer из IcedCoffeeScript, но это противоречит идеологии «комилируемся в очевидный читаемый JS».
Ах, да. Еще очень не хватает protected. Компилировать придется в загогули вида protected foo -> function $ClassName$foo$, но это я легко переживу :)
Пишите сюда: typescript.codeplex.com/workitem/list/basic
Пока версия 0.8.3, развивается с каждым релизом,
Пока версия 0.8.3, развивается с каждым релизом,
На нём можно создавать веб-приложения (клиент и сервер), в том числе с оффлайн-режимом работы, десктопные приложения (для Windows 8), приложения для смартфонов и планшетов (PhoneGap), расширения для Microsoft Office, SharePoint и Dynamics.Уточнение в скобках насчёт «для Windows 8» можете отставить в сторону. Я упоминал ужé на Хабрахабре про движок
Ну и самая главная фича, от вида которой я чуть не расплакался:
Вы это серьезно? Bли Вы просто никогда не использоволи для JS другой IDE?
Вы это серьезно? Bли Вы просто никогда не использоволи для JS другой IDE?
Конечно несерьезно. Но если серьезно, то далеко не все умеют делать переименование переменных в JS.
TypeScript пока что сыроват, плагин для студии полог глюков, тормозов и время от времени подвешивает студию намертво (разумеется при работе с более или менее большим проектом). Сам компилятор не всегда обратно совместим, и пока что TypeScript подходит лишь для экспериментов. Возможно, что через год он достигнет определенной стабильности.
А как с рефакторингом дела обстоят?
Когда в TypeScript поддержат async, await тогда будет смысл для перехода.
ИМХО, классы в TypeScript не самая полезная фича. Я сторонник того, чтобы программист расширял свою базу знаний о языках и парадигмах программирования.
ИМХО, классы в TypeScript не самая полезная фича. Я сторонник того, чтобы программист расширял свою базу знаний о языках и парадигмах программирования.
Самое прикольное, что в один прекрасный момент, еще одна умная голова решит, что писать на TypeScript сложно, и нужно сделать над ним обертку, и получиться NewSuperTypeScript, и так до бесконечности.
Уж как-то очень много оберток в последнее время развелось, с одной стороны это позволяет программисту использовать более знакомый ему синтаксис, с другой ведет к хаосу.
Уж как-то очень много оберток в последнее время развелось, с одной стороны это позволяет программисту использовать более знакомый ему синтаксис, с другой ведет к хаосу.
Это сделано в микрософте? Нее, пасиба мы лучше coffeescript возьмём.
Подобная ангажированность не к лицу профессиональному разработчику.
Хохохо — если я не использую нечто мелкомягкое, то я — непрофи? Ога, проплата, вперёд.
В тему холивара — большая часть, что ни делается микрософтом, не имеет адекватных инструментов.
Профессионал отличается от поделкина тем, что использует технологии с адекватными инструментами, а не фиксируется на одном вендоре и ангажирует на него.
В тему холивара — большая часть, что ни делается микрософтом, не имеет адекватных инструментов.
Профессионал отличается от поделкина тем, что использует технологии с адекватными инструментами, а не фиксируется на одном вендоре и ангажирует на него.
>Подобная ангажированность не к лицу профессиональному разработчику.
В принципе верно, но есть опасение что TypeScript станет ещё одной MS-only технологией.
В принципе верно, но есть опасение что TypeScript станет ещё одной MS-only технологией.
Как раз в силу того небольшого (хотя на самом деле больше) количества приведенных в статье недостатков JS («Основные недостатки JavaScript:»), использовать его стоит в ограниченных количествах и в легко обозримом количестве кода.
Я, например, нашел способ оптимизации «узких мест» в программе на Ruby с помощью JavaScript V8.
inet777.ru/comments/8441/optimizaciya-kritichnyih-v-skorosti-algoritmov-v-ruby-s-pomoschmzyu-v8
Я, например, нашел способ оптимизации «узких мест» в программе на Ruby с помощью JavaScript V8.
inet777.ru/comments/8441/optimizaciya-kritichnyih-v-skorosti-algoritmov-v-ruby-s-pomoschmzyu-v8
Решил побаловаться
Вставил простенький «продакшн» скрипт в компилятор и тут же получил
The property 'webkitTransform' does not exist on value of type 'MSStyleCSSProperties'
Ага, привет «ИЕ» подход
Ну и кстати зачем все кто не лень пытаются втянуть классы в JS?
Я последнее время очень много программирую на JS и мне больше нравиться «прототипный» подход.
Вставил простенький «продакшн» скрипт в компилятор и тут же получил
The property 'webkitTransform' does not exist on value of type 'MSStyleCSSProperties'
Ага, привет «ИЕ» подход
Ну и кстати зачем все кто не лень пытаются втянуть классы в JS?
Я последнее время очень много программирую на JS и мне больше нравиться «прототипный» подход.
напиши вот это в начале файла
По умолчанию типы для DOM сгенерированы на основе MIDL определений IE, поэтому многих специфичных вещей там нет.
Но вот на Playgound свойство уже поддерживается.
interface MSStyleCSSProperties{
webkitTransform:any;
}
По умолчанию типы для DOM сгенерированы на основе MIDL определений IE, поэтому многих специфичных вещей там нет.
Но вот на Playgound свойство уже поддерживается.
А классы все хотят, потому что они дают инкапсуляцию и более привычное поведение.
Для себя сделал такое заключение.
Основная проблема при понимании реализации ООП в JavaScript — модель наследования. Она отличается от популярних языков.
Все привыкли к иерархическому наследованию, тогда как в JavaScript другая модель — делегирующее наследование.
В JavaScript нет ключевого слова extend, вот тут у многих начинается паника. И вместо того чтоб разобратся с теми возможностями, которые предоставляет JavaScript, они ставят клеймо на язык «недоООП».
Тем не менее на JavaScript можно реализовать и иерархическое наследование. В таких случаях и делают разные обертки для того чтоб не повторять каждый раз одно и тоже. Здесь я поддерживаю предложение синтаксиса классов в ES6.
Основная проблема при понимании реализации ООП в JavaScript — модель наследования. Она отличается от популярних языков.
Все привыкли к иерархическому наследованию, тогда как в JavaScript другая модель — делегирующее наследование.
В JavaScript нет ключевого слова extend, вот тут у многих начинается паника. И вместо того чтоб разобратся с теми возможностями, которые предоставляет JavaScript, они ставят клеймо на язык «недоООП».
Тем не менее на JavaScript можно реализовать и иерархическое наследование. В таких случаях и делают разные обертки для того чтоб не повторять каждый раз одно и тоже. Здесь я поддерживаю предложение синтаксиса классов в ES6.
В таком простом примере после компиляции оказалось 2 уровня замыканий Оо. и ещё адовая конструкция (Shapes || (Shapes = {})). Очень много мусора.
Боюсь думать что же там получится при хоть сколько нибудь сложной логике. И сколько потом ночей придется провести за отлавливанием багов, и над попытками оптимизации.
Боюсь думать что же там получится при хоть сколько нибудь сложной логике. И сколько потом ночей придется провести за отлавливанием багов, и над попытками оптимизации.
Замыкания обеспечиваю инкапсуляцию, другого способа нет. Оптимизировать там ниче не надо, потому что код определений выполняется один раз.
Если почитаете Закаса, то не найдете проблем в том коде, который генерирует TS, если только сами фигню не напишите.
Если почитаете Закаса, то не найдете проблем в том коде, который генерирует TS, если только сами фигню не напишите.
И чего же в этом примере проинкапсулировалось? Point что ли? Который потом был вынесен в открытое свойство. Shapes тоже доступный в глобальной области?
И не надо рассказывать что там могло бы быть больше свойств — тогда бы и результат компиляции был бы более ужасающим.
И не надо рассказывать что там могло бы быть больше свойств — тогда бы и результат компиляции был бы более ужасающим.
(Shapes || (Shapes = {}))А что вас, собственно, неустраивает? Короткая, элегантная и в целом довольно распространенная форма.
чем вас не устраивает (Shapes || (Shapes = {})?
Тем что конструкцию:
var Shapes;
(function(){
/* */
})( Shapes || (Shapes = {}) );
Генерировал TypeScript.
Т.е. мы вроде как для себя позаботились о том чтобы в Shapes что-то было, а то что там уже могли быть свойства и тот же Point ему пофиг.
Бюрократия получается )) Вроде что-то делаем: замыкаем, «инкупсулируем», что многие обычно делают, а нафига это — не знаем. А код всё разрастается.
Я это к тому, что очень много получается бесполезного мусора, КПД низкий.
var Shapes;
(function(){
/* */
})( Shapes || (Shapes = {}) );
Генерировал TypeScript.
Т.е. мы вроде как для себя позаботились о том чтобы в Shapes что-то было, а то что там уже могли быть свойства и тот же Point ему пофиг.
Бюрократия получается )) Вроде что-то делаем: замыкаем, «инкупсулируем», что многие обычно делают, а нафига это — не знаем. А код всё разрастается.
Я это к тому, что очень много получается бесполезного мусора, КПД низкий.
Какой КПД? Это же не руками написанный код, а уже все современные движки умеют делать dead code elimination, так что вообще ничего не случится.
Вообще, победил не JavaScript, как язык программирования, а JavaScript, как виртуальная машина. Дум и эмулятор линукса не были написаны на чистом js заново, а всего лишь транслированы из существующего кода при помощи тулов (emscripten).
Что кроме typescript, компилируется в JS, можно посмотреть вот тут: altjs.org/ И, typescript из этого списка не самое лучшее решение. Мы, пользуемся GWT, и очень довольны. Можем использовать нормальный статически типизированный язык программирования (большие приложения на динамических языках писать очень тяжело), и нормальную библиотеку в отличии от.
Что кроме typescript, компилируется в JS, можно посмотреть вот тут: altjs.org/ И, typescript из этого списка не самое лучшее решение. Мы, пользуемся GWT, и очень довольны. Можем использовать нормальный статически типизированный язык программирования (большие приложения на динамических языках писать очень тяжело), и нормальную библиотеку в отличии от.
Про «победил» это сильное заявление. Мне почему-то кажется, что через пару лет хайп спадёт, как в случае с ruby, например. И все начнут плеваться при упоминании js.
Имею большой опыт работы с одной из реализаций ecmascript, и небольшой опыт работы с нодой. И не могу сказать, что этот опыт меня сильно радует. Я пока что не увидел для себя преимуществ javascript. Простота языка это плюс. Но то ли эта простота размягчает мозги разработчикам, то ли она позволяет включить в разработку проекта людей не готовых для этого. Но в любом случае пока я не видел больших проектов на ecmascript с качественным кодом, который можно было бы без особых усилий поддерживать и развивать.
Вернее видел, но это были проекты, созданные одним человеком, а не командой.
Имею большой опыт работы с одной из реализаций ecmascript, и небольшой опыт работы с нодой. И не могу сказать, что этот опыт меня сильно радует. Я пока что не увидел для себя преимуществ javascript. Простота языка это плюс. Но то ли эта простота размягчает мозги разработчикам, то ли она позволяет включить в разработку проекта людей не готовых для этого. Но в любом случае пока я не видел больших проектов на ecmascript с качественным кодом, который можно было бы без особых усилий поддерживать и развивать.
Вернее видел, но это были проекты, созданные одним человеком, а не командой.
Да, про то что хайп скоро спадет уже лет 10 говорят, но что-то не спадает… Все потенциальные заменители JS вымерли или скоро вымрут, сам JS пробрался уже туда, где о нем и не думали лет 5 назад. Расширение продолжается…
10 про javascript говорят? Да ну бросьте, 10 лет назад он из браузеров не выходил, как мне кажется
Вообще-то он изначально создавался и для использования в качестве серверного языка тоже.
а где он использовался в качестве серверного языка 10 лет назад?
В AppWeb например. Initial release 2003-11-10. Реализация сильно отличается от того, что есть сейчас, но язык именно JS.
Не так популярен — да, но был и есть уже давно.
Не так популярен — да, но был и есть уже давно.
а где он использовался в качестве серверного языка 10 лет назад?
Отличный вброс, двухуровневый, так сказать.
Во-первых javascript не победил. Да, он на слуху последние пару лет, но устройств, платформ и прочего, поддерживающих Java и C больше. Туда же можно отнести рейтинги популярности языков и процентное соотношение количества вакансий.
Во-вторых — не каждому программисту на js нужна типизация, и уж тем более, доверять компании, которая придумала уже 2 замены javascript как-то выглядит слишком самонадеянно, невзирая на все усилия самой майкрософт обелится перед опенсорсом и открытыми стандартами. Может через пару лет, когда хотя бы продукты самой майкрософт будут написаны на typescript.
Во-первых javascript не победил. Да, он на слуху последние пару лет, но устройств, платформ и прочего, поддерживающих Java и C больше. Туда же можно отнести рейтинги популярности языков и процентное соотношение количества вакансий.
Во-вторых — не каждому программисту на js нужна типизация, и уж тем более, доверять компании, которая придумала уже 2 замены javascript как-то выглядит слишком самонадеянно, невзирая на все усилия самой майкрософт обелится перед опенсорсом и открытыми стандартами. Может через пару лет, когда хотя бы продукты самой майкрософт будут написаны на typescript.
В js очень необычная реализация ооп, комуто нравится, комуто нет. И не за что его ругать, есть языки где намного больше странностей.
Прочитал статью — стало интересно. Установил в sublime плагин. Подскажите, как настроить куда выдавать файл, а то сейчас открывается временный файл, с скомпилированным js
Ой. Год sublime использую и не знал о таких возможностях. А автосборку по сохранению не подскажите как настроить?
www.purplebeanie.com/Development/automatically-run-build-on-save-in-sublime-text-2.html
Я вообще-то запускал Sublime раз 5 всего…
Я вообще-то запускал Sublime раз 5 всего…
Так и запишем, не осилили прототипы.
Динамическая типизация, которая вызывает множество регрессионных ошибок.
Отсутствие модульности. Нет ни модулей, ни классов, прототипное ООП рвет мозг тем, кто пишет на C++\Java\C#.
Неочевидное поведение во многих местах.
Aw Jeez, not this shit again…
> Самая большая проблема JavaScript в том, что его придумал не Microsoft.
Самая большая проблема Microsoft в том, что это не он придумал JavaScript
Самая большая проблема Microsoft в том, что это не он придумал JavaScript
> Самая большая проблема CofeeScript в том, что его придумал не Microsoft.
Потому Майкрософт придумал свой.
Потому Майкрософт придумал свой.
Пара замечаний, скорей касающихся формы изложения мыслей, нежели содержания:
Так же, если транслятор TypeScript->JavaScript ещё можно назвать компилятором, то, например, «Java –> JavaScript» — нет.
На сегодняшний день это самый кроссплатформенный язык, доступный для любых устройствЧто такое «самый кроссплатформенный», и что значит для любых устройств? Не говоря уже о скорости работы интерпретируемого языка, на множестве устройств, скорей всего, его никогда не будут использовать. Конечно, далее понятно, что речь именно о приложениях, но всё же, примите во внимание…
Так же, если транслятор TypeScript->JavaScript ещё можно назвать компилятором, то, например, «Java –> JavaScript» — нет.
Это просто офигенно. Как раз требовалось писать на JavaScript, и как раз он вызывал отторжение по указанным причинам.
Спасибо. Будем пробовать.
Спасибо. Будем пробовать.
Все эти споры о том что лучше из семейства js-языков лишь очередной холивар. Пишите код, и не парьтесь
Как там себя Google Dart чувствует?
Dart не взлетел, это уже понятно. Хотя объективно он неплох, просто так вышло.
У TS пока что есть все шансы.
У TS пока что есть все шансы.
Просто это Java
FUD
Кому это понятно?
Что TypeScript, что Dart ещё в preview mode.
Не рано цыплят начали считать?
Dart чувствует себя отлично.
Dart VM работает в 1.5 — 2.5 раз быстрее чем V8.
Dart скомпилированный в JS работает быстрее или не медленнее чем оригинальный JS код.
www.dartlang.org/performance/
Кому это понятно?
Что TypeScript, что Dart ещё в preview mode.
Не рано цыплят начали считать?
Dart чувствует себя отлично.
Dart VM работает в 1.5 — 2.5 раз быстрее чем V8.
Dart скомпилированный в JS работает быстрее или не медленнее чем оригинальный JS код.
www.dartlang.org/performance/
Просто некоторые судят не по скорости, а, например, по IDE, что совсем неправильно.
Не, по блогосфере. Как-то все затихло, создается впечатление, что почти никто не использует вне Google.
Хотя, может, я просто не там смотрю
Хотя, может, я просто не там смотрю
Про IDE я тоже могу ответить :-)
Собственно я над ней и работаю для Dart.
Не знаю есть ли в TypeScript IDE другие рефакторинги кроме Rename, но в Dart Editor есть:
— Rename (всего — переменных, методов, классов, etc)
— Extract Local Variable
— Extract Method
— Inline Local Variable
— Inline Method
Ну и по мелочам — преобразовать метод в getter и наоборот, optional positional parameter to optional named.
Плюс всякие необходимые вещи для навигации — Quick Outline, Type Hierarchy, Call Hierarchy.
Сейчас идёт активная работа над IDE версии 2, с целью сделать всё быстрее.
Собственно я над ней и работаю для Dart.
Не знаю есть ли в TypeScript IDE другие рефакторинги кроме Rename, но в Dart Editor есть:
— Rename (всего — переменных, методов, классов, etc)
— Extract Local Variable
— Extract Method
— Inline Local Variable
— Inline Method
Ну и по мелочам — преобразовать метод в getter и наоборот, optional positional parameter to optional named.
Плюс всякие необходимые вещи для навигации — Quick Outline, Type Hierarchy, Call Hierarchy.
Сейчас идёт активная работа над IDE версии 2, с целью сделать всё быстрее.
Опять двадцать пять. Из ближайшего Visual J#.
Пробовали использовать ts в большом проекте с достаточно объемной клиентской частью написанной на js. Проблема возникла с тем, что в проекте требуется хранить две версии файла: ts и сопутсвующий скомпилированный js. А это как минимум неудобно и требует дополнительных усилий при поддержке системы контроля версий. В нашем проекте мы используем минификацию и обфускацию клиентского кода с помощью Cassette, попробовали компилировать ts файлы на лету, но компилятор предоставленный Microsoft написан на JavaScript'е и использует COM объект WScript, который работает только из командой строки. Все попытки запустить компилятор с помощью скриптого движка например JurassicScriptEngine потерпели неудачу из-за отсутсвия доступа к вышеупомянутому WScript обьекту. В общем у Microsoft получился довольно сырой продукт, не пригодный к использованию в больших проектах.
Хм, gcc тоже запускать можно только из командной строки, но это не мешает компилировать сишные программы. Что мешает запустить cscript.exe в качестве дочернего процесса?
Ничего не мешает, только это командную строка и результатом компиляции опять будет файл на диске, который нужно прочитать и затем удалить. Опять же если таких скриптов не один, а много процесс может занять несколько минут. Нам хотелось, чтобы можно было делать это в просто в памяти, как например компилируется less.
Зато у файлов на диске есть дополнительное преимущество — можно сравнить время модификации .ts и .js-файлов, и если первый не новее второго, то этап компиляции можно вообще пропустить.
Все нормальные системы сборки проектов поддерживают такую возможность «из коробки».
Все нормальные системы сборки проектов поддерживают такую возможность «из коробки».
Речь идет о том, чтобы отказаться от сопутствующих js файлов в принципе, а это сделать с учетом специфики компилятора не возможно.
У вас что за ide\платформа?
ASP.NET MVC, VS 2012
А почему бы не использовать bundle transformer? Отпадает необходимость хранить скомпилированный js. При этом если надо хранить, то студия сама добавляет в source control файлы, полученные при компиляции, а дальше вы можете что угодно делать с помощью build tasks.
Как раз хранить скомпилированный js и не хотелось бы. Мы используем Cassette для бандлинга скриптов. Как и в Bundle Transformer, там есть возможность преобразовывать файлы «на лету» с помощью своей реализации интерфейса IBundleProcessor. Но как я уже говорила, не получилось скомпилировать ts штатным компилятором без создания сопутствующих файлов. Возможно стоит взглянуть на исходники Bundle Transformer'a и посмотреть как это сделано там.
Зачем скомпилированный .js хранить? Компиляция нужна в двух местах:
1) процедура деплоя
2) сборка при отладке (в любой нормальной ide есть возможность это настроить как при изменении .ts, так и по хоткею).
Windows и Visual Studio я в последний раз использовал, когда VS была версии 6.0, но я отказываюсь верить, что там нельзя сделать то, что я за 3 минуты сделал в Linux банальным Makefile и парой настроек в WebStorm.
1) процедура деплоя
2) сборка при отладке (в любой нормальной ide есть возможность это настроить как при изменении .ts, так и по хоткею).
Windows и Visual Studio я в последний раз использовал, когда VS была версии 6.0, но я отказываюсь верить, что там нельзя сделать то, что я за 3 минуты сделал в Linux банальным Makefile и парой настроек в WebStorm.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему вам стоит использовать TypeScript