Comments 117
Хороший список, но хотя бы примеры про пиво на стене.
а haxe?
Эх, я как раз хотел писать, даже в черновиках набросал :)
Странно, что Opal не замечал ни разу, спасибо.
Хотя, могу попробовать:
Скрытый текст
Диалект CoffeeScript, который стремиться быть более радикальным и практичным, а также служит испытательным стендом для фич, которые могут быть в будущем добавлены в CoffeeScript.
Принципы Coco:
Учитывать семантику и идиомы JavaScript
Умереть во имя DRY
Perl вместо Ruby
Меньшее количество ключевых слов, знаков препинания, выявление ошибок не во время исполнения, а во время компиляции
Куд-кудах!
Новые возможности:
Необъвляющее присваивание (nondeclaring assignment) :=
Присваивает значение существующей переменной, при попытке присваивания несуществующей выдаст ошибку компиляции:
…
Принципы Coco:
Учитывать семантику и идиомы JavaScript
Умереть во имя DRY
Perl вместо Ruby
Меньшее количество ключевых слов, знаков препинания, выявление ошибок не во время исполнения, а во время компиляции
Новые возможности:
Необъвляющее присваивание (nondeclaring assignment) :=
Присваивает значение существующей переменной, при попытке присваивания несуществующей выдаст ошибку компиляции:
a = 1; new -> a := 2; b = 3
...
x := 0
Syntax Error: assignment to undeclared variable "x" on line 1
…
Странно, что Opal не замечал ни разу, спасибо.
Хотя, могу попробовать:
Наверное, для этого стоит делать отдельный проект, как, например TodoMVC
Чтобы показать реализации на всех альтернативных языках.
Но у яваскрипта есть свои заковырки. Прототипная модель объектов, динамиеские типы, колбек-функции, всё это, можно сказать, на любителя.
Даже отпало желание читать дальше. Ну я еще худо-бедно могу понять неприязнь к прототипам (да у многих с ними проблемы), я могу понять про типизацию (тем, кто не писал ни на чем кроме шарпа или явы, бывает тяжело перестроится). Но коллбек функции-то чем не угодили? Только синхронность, только хардкор?
Ну вот, например, Kaffeine как раз реализует асинхронность без колбеков.
Про типизацию имеется в виду неявное приведение видов, когда
Коллбэки проблемы в том, что асинхронный код с кучей вложенных коллбэков очень трудно читать. Посмотрите IcedCoffeeScript и поймёте о чём речь (то есть мы разворачивает коллбычный код в линейный, а язык сам всё правильно свертнёт).
Плюс у JavaScript проблема с
Плюс в JS ещё куча минусов чисто по синтаксису (отсутствие foreach и компактного синтаксиса получения подстроки вида
== может вести себя непредсказуемо. Поэтому, например, в CoffeeScript == заменяется ===о.Коллбэки проблемы в том, что асинхронный код с кучей вложенных коллбэков очень трудно читать. Посмотрите IcedCoffeeScript и поймёте о чём речь (то есть мы разворачивает коллбычный код в линейный, а язык сам всё правильно свертнёт).
Плюс у JavaScript проблема с
var и областью видимости — очень легко забыть и испортить глобальные переменные. В CoffeeScript весь код идёт в локальной области видимости (то есть все файлы вкладываются внутрь (function() { … })();) и интерпретатор сам объявляет новые переменные.Плюс в JS ещё куча минусов чисто по синтаксису (отсутствие foreach и компактного синтаксиса получения подстроки вида
string[0..-3]). При всём моём уважении к JS, этот язык делался второпях за 2 недели.ну от проблем с областью видимости спасает «use strict»; + программист на js который уже не может скоуп написать — уже клиника какая-то. foreach есть в каждой второй библиотеке или реализуется копипастом за 5 сек (если вы конечно не относитесь к той категории людей. которые из принципа все делают на vanilla js и каждый раз с нуля). Получение подстрок — сахар, который так же далеко не во всех языках есть, да и положа руку на сердце — довольно специфическая задача (как то раза 2 или 3 встречалась)
Все перечисленный вами foreach’и гораздо более громоздкие, чем:
for i in array
console.log(i)
`use strict` не спасает от засорения глобального пространства — вам ещё нужно вложить всё в анонимную функцию.
Но я согласен, что у этих проблем есть различные решения (тот же strict-режим или куча библиотек), но альтернативные языки — просто один из этих способов. Он даёт самые эффективные показатели (короткую запись foreach, резкое сокращение не информационных символов в языке, тотальное решение проблемы забытого var без единого лишнего символа), но из-за этого имеет несколько сайд-эффектов. Например, вам нужен компилятор и отладка упрощается.
Впрочем, эти сайд эффекты часто проще подавить (ведь преимущества очень большие) — компиляторы красиво и бесшовно интегрируют с фреймоврками, а проблема отладки решается внедрением SourceMap.
Впрочем, эти сайд эффекты часто проще подавить (ведь преимущества очень большие) — компиляторы красиво и бесшовно интегрируют с фреймоврками, а проблема отладки решается внедрением SourceMap.
У нас какие-то разные JS. У меня в нём даже два форича (не считая подобных конструкций): for each… in и .forEach.
'use strict'
не нравятся коллбеки — не пишите коллбеками
var a = 'somestringlast'
a.substr(-3, 3);
arr.forEach и for (var prop in coll)
for (var i in col) — проход по объекту, а не массиву.var coll = [1,2,3,4,5,6,7,8,9];
for (var i in coll) { console.log(coll[i] * 2)}
Как-то так попробуйте
Массивы — это частный случай объектов в JS. Но:
и всё сломается :). Например, arguments — это как раз такой хакнутый массив.
Нормальный foreach идёт только по цифрам (то есть в зависимости от array.length), а не по всем свойствам объекта.
var coll = [1,2,3,4,5,6,7,8,9];
coll.verificated = 1;
for (var i in coll) { console.log(coll[i] * 2)}
и всё сломается :). Например, arguments — это как раз такой хакнутый массив.
Нормальный foreach идёт только по цифрам (то есть в зависимости от array.length), а не по всем свойствам объекта.
А в других языках вы часто динамически цепляете свойства к массивам?
Я, например, стремлюсь к чистоте типов, и если нужен массив в структуре, то это будет струкрута с массивом-свойством, но никак не массив с прицепленными свойствоми структуры (объекта).
Я, например, стремлюсь к чистоте типов, и если нужен массив в структуре, то это будет струкрута с массивом-свойством, но никак не массив с прицепленными свойствоми структуры (объекта).
Например, arguments — это как раз такой хакнутый массив.
Кстати, на самом деле это совершенно не так.
«не нравятся коллбеки — не пишите коллбеками» — а как вы будете писать неблокирующий код на Node.js без коллбэков? ;)
Использую более функциональный подход. Конечно, от коллбеков совсем нельзя избавится, но я пока что не вникал в работу бибилиотек типа async и не слишком им доверяю.
Можете привести пример, где функциональный подход позволяет избавиться от коллбэка после выполнения AJAX-запроса или после получения данных из БД, ;)
var setView = function (data) {
console.log(data);
}
var parseRespone = function (res) {
if (res.some && res.data) {
setView(res.data);
}
}
var makeRequest = function (params) {
if (config.ajax) {
reqAjax(params, parseResponse);
} else {
reqSoсket(params, parseResponse);
}
}
Например как-то так. Опять таки, не везде и не всегда можно отказаться от анонимных колбеков. Но если правильно проектировать, то во многих местах можно. Более того, такой подход может облегчить внедрение [T|B]DD
То что вы сохранили коллбэки в переменные не избавляет вас от коллбэков :D.
Ну тогда прошу меня простить. По другому я не понимаю работу асинхронных кусков кода.
Например, что предлагает IcedCoffeeTea:
В JS это было бы:
То есть IcedCoffeeTea (Эта функция ещё есть в Ruby, Go и C#) сворачивает вложеные коллбэки в линейный код.
await $.get(url, defer json)
console.log(json)
В JS это было бы:
$.get(url, function(json) {
console.log(json)
});
То есть IcedCoffeeTea (Эта функция ещё есть в Ruby, Go и C#) сворачивает вложеные коллбэки в линейный код.
не вижу особых преимуществ, все те же анонимные коллбеки. если не нравится скобочки писать — можно использовать сниппеты
Вы неправильно поняли код — там нет никаких анонимных функций, после AJAX-вызова идёт обычный код на той же строке. Интерпретатор помнит, что вы пометили переменную json, как асинхронную. И если вы не обращаетесь к ней, то код после AJAX-вызова выполняется пока этот вызов параралелльно идёт. Но как только вы обратитесь к асинхронной
defer-переменной, То интерпретатор поймёт, что вас уже нужен результат этого AJAX-запроса И остановит ваш код, пока результат не будет получен.Про типизацию имеется в виду неявное приведение видов, когда == может вести себя непредсказуемо
Вообще-то == всегда ведёт себя предсказуемо.
Плюс у JavaScript проблема с var и областью видимости — очень легко забыть и испортить глобальные переменные.
У JS нету такой проблемы. Может, у вас и есть, а в JS всё очень красиво и прозрачно — вы сами указываете область видимости переменной. А вот в кофе-скрипте как раз такая проблема есть. Ты думаешь, что пользуешь локальной переменной, а кто-то её объявил в глобальной области и всё.
Ну, допустим, такой код:
# full closure
->
# a lot of code here
a = 13
# a lot of code here
# some local function
callback = ->
b = 25
a = 14
a + b
# a lot of code here
Хотелось бы, чтобы в фукнции был локальная область видимости. А нет, a берётся из глобальной и это хорошо видно в скомпиленной версии:
(function() {
var a, callback;
a = 13;
return callback = function() {
var b;
b = 25;
a = 14;
return a + b;
};
});
Это бага в спецификации языка, которая поощряет непонятные ошибки. В JS же такой ошибки нет — ты сам определяешь, какие переменные в локальной области видимости.
Это уже аргумент интереснее. Но дело в том, что поведение CoffeeScript — совершенно стандартное поведение большинства языков программирования, где не объявляют переменные.
В php тоже интересное решение — все переменные считаются локальными, а притащить их из скоупа родителя можно через use. На практике это менее удобно. В любом случае решение из JS наименее расположено к ошибкам, как бы там ни было в других языках.
Я не полностью понял, почему JS наименее предрасположен к ошибкам. Там главная идея, что вы вручную управляете областью видимости. Но у меня у самого было (и в Интернете множество примеров), когда случайно забытый var приводил к отладке длинною в 30 минут.
Я думаю, от случайно забытого вара может спасти хорошая иде.
Но легче найти ошибку «не объявили переменную в локальной области», чем «объявили ещё хрен знает где, потому она тут не объявляется».
Но легче найти ошибку «не объявили переменную в локальной области», чем «объявили ещё хрен знает где, потому она тут не объявляется».
IDE не спасает ;) — там логическая ошибка, машина не может знать, может быть вы действительно хотите использовать глобальную переменную.
Используйте JSLint приязанный к IDE или редактору кода и он будет вам напоминать о всех локальных забытых переменных. Более того, локально переопределенная переменная может даже помочь в оптимизации.
может быть вы действительно хотите использовать глобальную переменную.
Простите, это как? О, о
Глобальную переменную можно использовать, но не изменять внутри локального кода. Тогда никаких ошибок не будет.
В любом случае, файлы в хорошем проекте небольшие — и идея большинства языков в том, что вы контроллируете файлы (например, БЭМ избавляет между конфликтами имён классов только между файлами, но не в одном файле).
Меня одного пугает этот зоопарк и компиляция слона в бегемота? Понятно, когда язык программирования компилируется в байткод, но когда он компилируется в другой язык — это мне кажется неестественным (оставляя ORM в сторонке, там другой случай).
Это еще что, люди бинарный код компилируют в с++ :)
Формально декомпиляция — это тоже компиляция.
Формально декомпиляция — это тоже компиляция.
А какой выбор, если есть только JavaScript, а хочется большего?
Мигель предлагал встраивать Mono в браузеры, емнип, но, конечно, отказались.
Мигель предлагал встраивать Mono в браузеры, емнип, но, конечно, отказались.
JS — это, своего рода, «ассемблер» веба. Ниже него для веб-страниц ничего нет.
JS — это, своего рода, «ассемблер» веба. Ниже него для веб-страниц ничего нет.
Именно так я говорю про Java применительно к JVM (программировать на чистой Java (лично я использую Scala) мне кажется очень своеобразным занятием, требующим большого терпения). И в этом случае вполне понятно как использовать другие языки, а вот с заменой JS лично мне не совсем ясно как это всё стыкуется. Оно ставится модулем к web-серверу и конвертирует на лету? Или надо предварительно прогонять *.js и смешанные *.html файлы через компилятор? Или как-то иначе?
Кстати, а кто-то ещё помнит старый добрый Visual Basic Script? ;)
IcedCoffeeScript вкусная штука, не знал… попробую. Может, послужит для меня толчком для перехода на кофе.
А мне все эти надстройки очень не нравятся. Уже сколько раз сталкивался с такой ситуацией. Пишешь что-то, натыкаешся на мелкую проблему. Гуглишь решение и оно оказывается на CoffeScript.
И сидишь как дурак в него смотришь и не понимаешь что тут вообще происходит.
Или еще лучше целая библиотека написана. Что ж мне ради какой-то мелочи CoffeScript интегрировать в проект?
Вопщем лучше пусть эти вещи остаются в академических кругах.
И сидишь как дурак в него смотришь и не понимаешь что тут вообще происходит.
Или еще лучше целая библиотека написана. Что ж мне ради какой-то мелочи CoffeScript интегрировать в проект?
Вопщем лучше пусть эти вещи остаются в академических кругах.
Они уже не в академических кругах. Кофискрипт является стандартным в Ruby on Rails начиная с третьей версии. Сделайте себе одолжение, прочтите синтаксис. Вдруг понравится.
CoffeeScript это больше, чем сахар. Он меняет ваш стиль программирования. Если мне нужен массив функций, или функция, возвращая функцию, то на ванильном яваскприпте я три раза подумаю, буду ли я хотеть продираться через эти скобки, а на кофе даже и думать не стану. А оператор ".?" просто спасает сотни строк тупого кода:
вместо
Вплоть до иллюзии иной раз, что пишу на хаскелле.
CoffeeScript это больше, чем сахар. Он меняет ваш стиль программирования. Если мне нужен массив функций, или функция, возвращая функцию, то на ванильном яваскприпте я три раза подумаю, буду ли я хотеть продираться через эти скобки, а на кофе даже и думать не стану. А оператор ".?" просто спасает сотни строк тупого кода:
a?.b?.c?.dвместо
var _ref, _ref1;
if (typeof a !== "undefined" && a !== null) {
if ((_ref = a.b) != null) {
if ((_ref1 = _ref.c) != null) {
_ref1.d;
}
}
}
Вплоть до иллюзии иной раз, что пишу на хаскелле.
>>
Мне кажется, тут вы переборщили:
var _ref, _ref1;
if (typeof a !== "undefined" && a !== null) {
if ((_ref = a.b) != null) {
if ((_ref1 = _ref.c) != null) {
_ref1.d;
}
}
}
Мне кажется, тут вы переборщили:
if (typeof a !== "undefined" && a !== null && a.b && a.b.c) {
a.b.c.d;
}
А оператор ".?" просто спасает сотни строк тупого кода:
Если у вас настолько странный код, что вы не знаете содержимое объектов, то от этого поможет маленькая библиотека:
atom.object.path.get(a, 'b.c.d')
Но лично у меня очень редко появляется ситуация, когда я не знаю, есть ли такое свойство внутри объекта или нету.
Вы не поверите, у меня настолько странный код, что даже в переменных бывают разные значения!!1
Переменные на то и переменные, чтобы в них были разные значения. Но если вы не знаете приблизительное содержание объектов и приходится «догадываться» об этом — это вообще странность.
Это вы ерунду изволили сказать.
Я всегда знаю лишь приблизительное содержание объекта. В «b» у меня коллбэк, который вернет «хороший» расширенный объект (у которого есть свойство «d») — если сможет. Или плохой (если мы на Маке, например ;-)).
Очень частый контракт, если пользоваться js как задумано, а не как «плохим синтаксисом для процедур».
Я всегда знаю лишь приблизительное содержание объекта. В «b» у меня коллбэк, который вернет «хороший» расширенный объект (у которого есть свойство «d») — если сможет. Или плохой (если мы на Маке, например ;-)).
Очень частый контракт, если пользоваться js как задумано, а не как «плохим синтаксисом для процедур».
Да и неясно, в чём сущностное различие между
Переменная и переменная.
a = 42
б = { бум: { пам: 43 } }
Переменная и переменная.
Да, но TheShock, насколько я понял, говорит, что в этом случае вы знаете, есть у вас
б.бум.пам, или только б.буб.парам. Мол, тогда проверка б?.. бум?.. пам? и не нужна. Я привел жизненный пример, когда очень даже нужна.Я привел жизненный пример, когда очень даже нужна.
Я прошу прощения, но я не увидел жизненного примера.
Лично я, в огромедном приложении, использовал atom.path в двух местах:
создать глобальный объект в неймспейсе, например
declare( 'LibCanvas.Enginex.Hex.Projection', {});
Неймспейс необходимо создать если его нет.
Или для того, чтобы получить item в многоуровневой локализации:
lang.get('editor.units.tanks')
В локализации этого индекса может пока не быть — надо заменить на заглушку или дефолтный, но тогда приём из КофеСкрипта тоже не подходит.
Извините, но я искренне не понимаю, где на практике, а не в фантазиях может понадобиться этот сахар.
a = JSON.parse(нечто_со_стороны)
Просто у вас практика одна, а у других другая.
Опять фантазии
Я постоянно работаю со сторонними API. Facebook, VK, GoogleMaps, YaMaps, несколько приватных. Ни в одном из них в ответ на JSON не приходил непонятный объект с неизвестными полями.
Если это публичный апи — можете привести пример, пожалуйста?
Я постоянно работаю со сторонними API. Facebook, VK, GoogleMaps, YaMaps, несколько приватных. Ни в одном из них в ответ на JSON не приходил непонятный объект с неизвестными полями.
Если это публичный апи — можете привести пример, пожалуйста?
Поля известны. Неизвестно, инициализированные ли.
Блин, ну вы можете мне реальный пример показать то, а не кормить абстракциями? =))
API: Zanox, LinkShare, AW ProductServe и так далее. Могут вернуть не то, может таймаут случиться. И вообще, вера в то, что ваш API всегда возвращает то, что ожидается, сродни вызову eval() для чужого кода.
Отсутствие контроля входящих данных не может считатся приветствуемой практикой. Всегда возвращали, а вдруг раз, и не вернули, и ваша программа вылетает — в лучшем случае.
Да и без API хватает применений.
m[2] существует или нет?
P.S. В процессе этой дискуссии на хабре появился разметчик кода CoffeeScript ;)
Отсутствие контроля входящих данных не может считатся приветствуемой практикой. Всегда возвращали, а вдруг раз, и не вернули, и ваша программа вылетает — в лучшем случае.
Да и без API хватает применений.
m = строка.match(/(o)(o)/)m[2] существует или нет?
n = m?[2]P.S. В процессе этой дискуссии на хабре появился разметчик кода CoffeeScript ;)
Можем.
navigator.showGrowl?("We are able show you an example. Does you browser, though?")
Лично я, в огромедном приложении…
Я согласен с bubuq’ом: практики бывают разные.
Давайте я попробую подробнее про свой жизненный пример.
У меня есть объект, который, помимо прочего, зависит от плагинов в браузере. Например, если мой плагин установлен — этот объект сможет показать (ну пусть growl, для конкретики). Если не установлен — элегантно сплюнем что-нибудь в console.log. А если и консоли нет — ну тогда промолчим.
Я оборачиваю всю эту логику в инстанс Logger’а. А потом пишу
logger?.presenter?.present?.message. Если нет логгера — вывалились из первого «?.», если вообще нет презентеров — из второго. Если презентер есть, но хреновый — из третьего. Или какой-нибудь платформо-зависимый код в самом плагине. Или в Node.JS.
console?.log 'i love ie'
На разбор объекта параметров метода тоже библиотека? Спасибо. +1 лишний байт в кофе, ~+40 байт на конечный js и ~1,6кб на библиотеку… даже не знаю что выбрать. А велосипедов на типовые задачи, думаю, у всех хватает.
Кстати, es6.
Кстати, es6.
Спасибо. +1 лишний байт в кофе
ложь какая. каждый ваш
console?.log 'i love ie'
Это ничто иное, как
if (typeof console !== "undefined" && console !== null) {
console.log('i love ie');
}
в итоговом коде, т.е. лишних 60 байт.
Скомпрессированная «console-cap» весит 827 байт, т.е. уже тринадцатый console?.log в коде оставляет Coffee предсказумо в заднице.
ну спасибо за необоснованное обвинение во лжи. читаем внимательно:
ладно, чуть больше 50 (фигурный скобок и отступов в конечном js у себя не вижу), что сути не меняет.
и gzip отменили?
хотя не суть важно.
~+40 байт на конечный js
ладно, чуть больше 50 (фигурный скобок и отступов в конечном js у себя не вижу), что сути не меняет.
и gzip отменили?
хотя не суть важно.
чуть больше 50
57 =) Но да, «чуть больше 50», а уж тем более "~+40" звучит солиднее))
if (typeof console !== "undefined" && console !== null)
А почему вы свой коффее считаете гзипнутым и обфусцированным, а библиотеку считаете полной? Для красного словца? Отличная попытка манипулировать мнением окружающих. Вот стата по библиотеке:
before 1669
after compression 827
compression ratio 50 %
after compression and gzip 461
compression and gzip ratio 72 %
Но у неё есть дополнительное преимущество:
Код начинает работать «из коробки». Т.е. все «console.log» внезапно перестают ломать IE и не нужно менять весь код. И забытый знак вопроса не сломает нам ослика.
57 =)Убираем ненужные пробелы — получаем 48, жмем ведь
свой коффееУ меня нет ни одного проекта на кофе, а на js хватает. но данный оператор — однозначный плюс кофе.
почему вы свой коффее считаете гзипнутым и обфусцированным, а библиотеку считаете полнойМногократное повторение if (typeof console !== «undefined» && console !== null) ?) 1,7кб этого счастья сжалось gzip'ом до 81 байта.
Мне откровенно наплевать как работать с консолью — привел пример, один из многих, где этот оператор бы пригодился.
Я тоже больше люблю js, но и в кофе есть вкусные вещи, какие, надеюсь, попадут в будущие реализации js.
Потратить 30 минут и изучить синтаксис CoffeeScript, как мне кажется, не так долго. А профиты сразу будут — не будете смотреть как баран на новые ворота на куски CoffeeScript кода.
А вы не задумывались о том, что если библиотека написана на CoffeeScript, то она, внезапно, может быть скомпилирована в JavaScript? Или для Вас это разрыв шаблона? :)
PS. В rails уже относительно давно CoffeeScript используется по умолчанию вместо JS, вроде никто не жалуется сильно.
А вы не задумывались о том, что если библиотека написана на CoffeeScript, то она, внезапно, может быть скомпилирована в JavaScript? Или для Вас это разрыв шаблона? :)
PS. В rails уже относительно давно CoffeeScript используется по умолчанию вместо JS, вроде никто не жалуется сильно.
Да не то что бы разрыв, просто хочется открыть код, понять как работает а не просто взять готовое решение.
Ведь изначально я полез искать чужое решение потому что сам свое не придумал или мне мое не нравится.
Вот поэтому хочется всегда посмотреть как это сделал другой программер. Ну и выходит что меня той возможности лишили. Ну или я сам себя лишил нежеланием понимать CS :D
Ведь изначально я полез искать чужое решение потому что сам свое не придумал или мне мое не нравится.
Вот поэтому хочется всегда посмотреть как это сделал другой программер. Ну и выходит что меня той возможности лишили. Ну или я сам себя лишил нежеланием понимать CS :D
Какая-то скотина написала то, что мне нужно — на дотнете, а не на любимой джаве?
Ну вы хоть диалог то читайте. CS — ето CoffeScript а не C Sharp
Я-то хоть читаю. Откройте словарь на букве «А» и поищите там слово «аллегория».
окок :) недопонял. Не все программисты понимают аллегории, гиперболы и метафоры )
Не, ну просто действительно мне ваша претензия показалась странной. Создали люди синтаксический сахар, подмешивают его себе в кофе. Никого, казалось бы, не трогают.
И тут вы ;-)
«Я не понимаю, что за херню вы тут понаписали, перепишите все на ассемблере».
И тут вы ;-)
«Я не понимаю, что за херню вы тут понаписали, перепишите все на ассемблере».
У CS есть вполне объективные минусы.
Мое непонимание не единичный случай. Вот неплохая статья. По ней так и сквозит: сложен для понимания.
Ну и да, я не спорю, CS хорош. Дает много прикольных штук, но я как бы боюсь пробовать наркотики. Т.е с одной стороны я знаю что это вроде как в кайф, но с другой я знаю к чему это приводит. И поэтому я пожалуй откажусь. Все, не мешайте мне осуждать наркоманов! :D
Мое непонимание не единичный случай. Вот неплохая статья. По ней так и сквозит: сложен для понимания.
Ну и да, я не спорю, CS хорош. Дает много прикольных штук, но я как бы боюсь пробовать наркотики. Т.е с одной стороны я знаю что это вроде как в кайф, но с другой я знаю к чему это приводит. И поэтому я пожалуй откажусь. Все, не мешайте мне осуждать наркоманов! :D
У Javascript нет альтернатив. Все, что тут перечислено — лишь разноуровневый сахар, в результате которого люди думают меньше.
Если так посмотреть, то и C++ — это сахар поверх C ;).
JavaScript тоже не напрямую в процессоре выполняется и он тоже заставляет людей думать меньше.
Ну не стоит так категорично. Лично для меня CoffeeScript является удобным инструментом, упрощающим и читаемость, и скорость написания кода. Но уж если думать лень, отказ от «сахара» думать никак не заставит.
UFO just landed and posted this here
> ClojureScript
> Напоминает Lisp
Clojure is a dialect of Lisp (via clojure.org/)
ClojureScript is a new compiler for Clojure that targets JavaScript (via github.com/clojure/clojurescript#readme)
Т.е. ClojureScript — это компилятор диалекта лиспа в JavaScript.
Так-то!
> Напоминает Lisp
Clojure is a dialect of Lisp (via clojure.org/)
ClojureScript is a new compiler for Clojure that targets JavaScript (via github.com/clojure/clojurescript#readme)
Т.е. ClojureScript — это компилятор диалекта лиспа в JavaScript.
Так-то!
CoffeeScript это небольшой язык, который компилируется в Javascript. Рубистам он кажется похожим на руби, питонистам он похож на питон, и конечно же, он похож на яваскрипт.Я вот пайтонист, а мне он всё равно кажется похожим на Руби.
Тогда вам стоит посмотреть Brython
Забавно, но это не Пайтон :) Это какое-то крошечное его подмножество, да ещё и с парсингом на стороне клиента, что меня лично удручает, так как приходится клиенту грузить ещё и интерпретатор. Как баловство — отлично, зачёт, но использовать это я бы не стал.
А ещё вспомнилась прекрасная статья: habrahabr.ru/post/150594/
А мы вот используем кофескрипт и на сервере и на клиенте, и, скажу я вам, это очень удобно.
Поправка: Dart пока не работает в общей сборке Google Chrome, только в специальной сборке под названием Dartium, который поставляется вместе с Dart SDK.
Полагаю незаслужено забыты: JavaScript++ (http://jspp.javascript.am/) и JSX (http://jsx.github.com/)
Мне вот в JS всего хватает, кроме сахара вокруг типов и интерфейсов. Посмотрел на TypeScript, все хорошо, но я так понимаю в скомпилированном виде там проверка типов не осуществляется. Ну и зачем оно мне такое нужно?
Sign up to leave a comment.
Альтернативы для JavaScript