dangreen 29 мая 2014 в 22:56

Еще один язык, транслируемый в JavaScript — ColaScript

3 мин

9.7K

JavaScript*

-5

Комментарии 55

neJa 29 мая 2014 в 23:08

Зачем?

+14

dangreen 29 мая 2014 в 23:09

Все написано в статье.

-1

Nikobraz 29 мая 2014 в 23:26

просто у человека, скорее всего первым ЯП был C, и он нанес тяжелейшую психическую травму.

+22

EasyX 30 мая 2014 в 18:30

Ой, зря вы так. Классика же.

НЛО прилетело и опубликовало эту надпись здесь

Nikobraz 29 мая 2014 в 23:54

Надо MentosScript запилить) Но с asm-подобным синтаксисом, вот это будет МООЩЬ!

+25

AndersonDunai 30 мая 2014 в 12:27

Тогда ко всему этому еще надо VodkaScript.

BasicWolf 29 мая 2014 в 23:24

Вы уж простите, но мне не понравилось. После прочтения Overview сложолось впечатление, что понабирали фишек из CoffeeScript, разбавили типизацией, убрали удобочитаемый синтаксис с отступами и вот вам. Ни коем образом не умаляя проделанной работы, считаю что популярность ColaScript в таком виде не обретёт.

P.S.
Вы знакомы с ClojureScript? Идеология у него полностью отлична от CoffeeScript, что совсем не мешает ему расти и развиваться.

rock 29 мая 2014 в 23:34

В статье про сам язык ничего не написано.
Опциональная типизация — штука хорошая, но подобная, которая не выдает ошибку даже в момент компиляции, к черту ни сдалась:

String str = {}; // => var str = {};

Языка как такового еще нет. Даже сахар для классов (из-за отсутствия которого большинство и берут язык, компилируемый в js) только в планах.
Все примитивно и громоздко. Посмотрите, например, LiveScript, пропустив примеры (могут отпугнуть) и сразу перейдя к сахару.

Ashot 29 мая 2014 в 23:39

Я наоборот так реагирую на компилируемые в JS языки.

+16

sferrka 29 мая 2014 в 23:49

Расскажите, пожалуйста, о результатах работы — что кроме, понятное дело, удовольствия от создания использования собственного языка это дало?
Какие моменты разработки ускорило? Упростило совместную работу или чтение кода? Что-то конкретное, что могло бы замотивировать попробовать язык. Возможно у вас есть проект с успешно внедренным ColaScript или это просто академическая наработка? Вы один разрабатываете и какие планы на поддержку и развитие — сколько времени вы готовы уделять и на что живете при этом?
Вы пишите, «not always valid-javascript is valid-colascript». Как быть с другими библиотеками?

По поводу языка:
1. Название не понравилось — слишком похоже на Coffee + еще и реклама сомнительного напитка.
2. Во Future не понравилось «HTML and CSS stuff». ИМХО, разрыв мозга при чтении кода, строку читать без разделителя еще и с переносами строк. Однако в строке multiline неплохо.
3.isset clone порадовали, однако это решено практически в любом фреймворке.
4. Большое количество для возможного создания именованной функции не понравилось — читать код очень неудобно.

Вообще, трудно судить о читабельности кода без конкретных рецептов, но с виду слишком много всяких конструкций языка.

dangreen 29 мая 2014 в 23:59

Про первые несколько вопросов я ничего не скажу, так как сам в статье написал что пока на практике пользоваться языком не стоит, писав статья надеялся заручиться чьей то поддержкой, помощью.

Вы один разрабатываете и какие планы на поддержку и развитие — сколько времени вы готовы уделять и на что живете при этом?

Один, все что сейчас есть написано за месяц, темп сбавлять не планирую. Я студент, подрабатываю фрилансом — сайты верстаю.

Вы пишите, «not always valid-javascript is valid-colascript». Как быть с другими библиотеками?

Этим я хотел сказать что компилировать js как cs не стоит, подключать без проблем можно любой js код: @require "jquery.js" — компилятор определяет по расширению файла как ему следует парсить исходинк.

2. Во Future не понравилось «HTML and CSS stuff». ИМХО, разрыв мозга при чтении кода, строку читать без разделителя еще и с переносами строк. Однако в строке multiline неплохо.

ReactJS'ом вроде люди пользуются, смотря на это решил позаимствовать и это.

novoselov 30 мая 2014 в 00:12

boolean aliases: True/False = on/no
o_O

+12

extempl 30 мая 2014 в 09:17

Тогда уж лучше, как в Objective-C: YES/NO

dangreen 30 мая 2014 в 09:52

вырвали из контекста просто, вот все алисасы:
true == yes == on
false == no == off

lolmaus 30 мая 2014 в 01:11

Обзор фич на Github очень скомканный. Местами непонятно, как пользоваться предложенным синтаксисом. Местами непонятно, что получится в результате. И непонятно, какие фичи есть в других языках, а какие уникальны.

Сделайте, пожалуйста, сравнительную таблицу синтаксисов и фич.

dangreen 30 мая 2014 в 09:33

Местами непонятно, как пользоваться предложенным синтаксисом.

Подскажите какими местами и я постараюсь поправить.

Местами непонятно, что получится в результате. И непонятно, какие фичи есть в других языках, а какие уникальны.

Хорошо, приведу пример перевода и подпишу что и от куда взято.

-1

lolmaus 30 мая 2014 в 01:13

А LiveScript видели? Очень богатый на фичи язык, и сами фичи очень интересные.

dom1n1k 30 мая 2014 в 01:56

CoffeeScript мне не нравится — там того пресловутого сахара столько, что в заднице слипается.
Мне кажется, что максимальная краткость != наилучшая читаемость. И что если полностью отказаться от слов в языке, в глазах будет рябить от спецсимволов. Сахар должен быть в меру.

У вас вроде бы не так радикально.
Но… нет ощущения целостности и единства стиля. Возможно, по причине не слишком аккуратной доки.

P.S. Кстати, а кто рисовал логотип? Неплохой леттеринг.

extempl 30 мая 2014 в 09:20

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

Вы, наверное, с Ruby не работали.

Прелесть coffeescript'а в том, что он даёт вам возможность использовать сахар, но не заставляет это делать. Для того, чтоб его адекватно воспринимать, нужно на нём писать хотя бы с месяц.

VasilioRuzanni 30 мая 2014 в 11:27

Ну проблема CoffeeScript не в том, что слишком уж сложно читается (хотя да, сложнее, чем чистый JS, несмотря на меньшее количество кода).
Я отказался в итоге от любимого Coffee из за недостаточной популярности — люди хотят видеть JS, иметь возможность его менять, читать, и так далее. То же касается большинства языков, компилируемых в JS. Не, у CoffeeScript достаточно сторонников, но все же очень многие его не очень жалуют.

dom1n1k 30 мая 2014 в 15:30

Как это не заставляет? Там разве можно вмеcто дурацкой (дурацкой потому, что она нормально не видна и в глазах рябит от спецсимволов) стрелочки написать нормальное слово function?

-2

extempl 30 мая 2014 в 15:46

Ну понятно дело, что не всё. Объявление функций, точки с запятыми и ещё некоторые основные отличия — неизменяемы. Однако там туева куча опциональных знаков и подходов.

dangreen 30 мая 2014 в 09:35

P.S. Кстати, а кто рисовал логотип? Неплохой леттеринг.

Это шрифт Dancing Script

xamd 30 мая 2014 в 13:38

Согласен с вами, писал на vanilla js, потом перешел на coffeescript, а потом опять вернулся к native. Просто только с опытом приходит осознание самого языка: чем он является, а чем нет. Я думаю нет смысла переубеждать автора в том, правильно ли писать на препроцессорах к js или нет, тут каждый находит свою истину.

Но свои пять копеек я всё же внесу: кофе хорош, но только на каких-то простых или маленьких проектах, над которыми вы работаете один или в небольшой команде. Когда проект содержит сложную логику, на кофе становится тяжелее писать. Тем более мне нравится стандартизирванный код, а опциональность вроде do или () порой смущает. Когда большая команда разработчиков пишет на coffee, все в результате пишут по-разному, и никакие coffeelint тут не помогают(конечно, можно развести из этого холивар, но я не преследую такую цель, это просто моё мнение).

Zibx 30 мая 2014 в 01:59

Расписал какие-то моменты.
1) Зачем нужен этот каскадный оператор, каскады с одной точкой вместо двух работают из коробки и так.
2) Удорожание вызова функций.
3) ` — но зачем? Может лучше «» тогда поддержать?
4) multiline — вот это прекрасно. align goes by closing-quote, а вот это — нет.
5) Реквестирую фичу arr[-1] (предпоследний элемент)
6) isset творит чёрте что. Если переменная задана как null, то она нот сеттед. Реальный нот сеттед будет скорее — try{ var b = a;}catch(e){ // Not setted }
7) ** — паскальный синтаксис, может стоит добавить ещё и ^?
8) Каскадный каскадный оператор чудесен, но синтаксис дик. По сути хотелось бы обычную разновидность apply(extjs)\extend(jquery) с каким-то переходом вверх.

Как уже заметили выше — если типизация есть, то её надо использовать. Для выявления ошибок на уровне компиляции, для некоторой оптимизации функций под конкретные типы.

rock 30 мая 2014 в 03:02

1. С одной точкой цепочки работают только если метод возвращает this. Каскадному оператору на то, что возвращает метод, наплевать.
5. Предпоследний? А последний тогда как? :) В Coco / LS — array[*-1]
6. Полностью согласен, заметил сразу, но из-за такой мелочи комментарий писать было лень. У кофеподобных языков с этим всё замечательно.
7. Тык.

Трэша хватает: чего только стоят эти строчки из clone:

var result, types = [ Number, String, Boolean ];
for (var i in types) if (types.hasOwnProperty(i) && _item instanceof types[i]) return types[i](_item);
if (_item.__proto__ === Array.prototype) {
  result = [];
  _item.forEach(function(child, index, array) {
    result[index] = $_cola_clone(child);
  });
  return result;
}

Поясню:

> for-in + hasOwnProperty для обхода массива.
> Объекты Number, String, Boolean клонируются в примитивы, на примитивы instanceof не работает, они идут дальше.
> Клоном объекта new Boolean(false) будет примитив true.
> Проверка, является ли объект массивом — через сравнение нестандартного свойства __proto__ с прототипом массива — до свидания, IE10-.
> Обход массива теперь уже через forEach — до свидания, IE8- (хотя да, с ними мы уже попрощались). Обычные циклы нонче не популярны.

В общем, весело там.

Zibx 30 мая 2014 в 04:03

Я не разгромить язык пытался, а высказал мыслей.
1. Но что-то адовое есть с двумя точками (кстати, обработан ли кейс у чисел? Сейчас в js оно понятно почему, но wat делает вот так: 2..toString() = (2).toString
5. А последний — arr[], если уж такой синтаксис. Но логичнее -1 ~ синоним [], -2 — предпоследний.

forEach — надо расширять прототип Array — это один из случаев когда расширение — благо.
Собственно избежать трэш можно если генерировать функции клонирования, основываясь на введённой типизации (попутно можно неплохо поддержать asm.js).

rock 30 мая 2014 в 04:28

Так и я по началу ничего громить не собирался, но как код посмотрел… На несколько комментариев решил не разносить.
Добавление forEach — да, благо, сам кой что глобальное, что прототипы встроенных конструкторов расширяет, релизить собираюсь. Только этот метод здесь никто и не добавляет, не к месту он, да и мелочь это по сравнению с остальным.

Zibx 30 мая 2014 в 15:37

Чёрт, я ночью спутал с автором.

vp_arth 30 мая 2014 в 06:46

по поводу индексов массива все верно…
хорошо, если будут работать дополнения(хотя там в любом случае надо чтоб выражения работали):
arr[~0] === arr[-1]: последний
arr[~1] === arr[-2]: предпоследний

dangreen 30 мая 2014 в 09:46

Оператор clone добавлял стиснув зубы, так как код самой функции это по сути костыль, но иногда такой оператор действительно пригождается.
Предлагайсте свою реализацию этой функции )

-1

rock 30 мая 2014 в 16:44

Свою реализацию? Да без проблем. Примерно так, код особо не проверял.
Простое глубокое клонирование структур Array и Object, с учетом прототипа. А в рамках языка большего и не нужно (хотя раньше думал иначе).
Треть — костыли для ES5. Треть — стек для корректного клонирования структур типа var a={}, b={}; a.b=b; b.a=a;.

Скрытый текст

function indexOf(arr, val){
  var $indexOf = Array.prototype.indexOf;
  if($indexOf)return $indexOf.call(arr, val);
  for(var i = 0, l = arr.length; l > i; i++)if(arr[i] === val)return i;
  return -1;
}
var getProto = Object.getPrototypeOf || function(it){
  return it.__proto__ || (it.constructor && it.constructor.prototype) || Object.prototype;
}
var create = Object.create || function(proto){
  var C = function(){};
  C.prototype = proto;
  return new C;
}
function clone(it, stack1, stack2){
  if(it == null || typeof it != 'object')return it;
  stack1 = stack1 || [];
  stack2 = stack2 || [];
  var index = indexOf(stack1, it);
  if(~index)return stack2[index];
  switch(Object.prototype.toString.call(it).slice(8, -1)){
    case 'Array':
      var result = [];
      stack1.push(it);
      stack2.push(result);
      for(var i = 0, l = it.length; l > i;)result.push(clone(it[i++], stack1, stack2));
      return result;
    case 'Object':
      var result = create(getProto(it));
      stack1.push(it);
      stack2.push(result);
      for(var key in it)if(Object.prototype.hasOwnProperty.call(it, key)){
        result[key] = clone(it[key], stack1, stack2);
      }
      return result;
  }
  return it;
}

dangreen 30 мая 2014 в 09:44

5) подумаю над этим
6) isset тварит ровно то что и? в кофе
7) ^ — такой оператор есть в JavaScript

на счет типизиации — наверное я не так выразился на англисков в овервью, но пока типизация это просто синтаксис. Оживлять ее, делать статической — это первое чем я сейчас займусь.

-1

rock 30 мая 2014 в 14:11

6. Всё просто. В кофе код проверки инлайнится в код, у вас используется хэлпер. Но тут проблема — необъявленную переменную нельзя использовать нигде, кроме typeof, а у вас она передается в функцию. В итоге:

foo?       // => false - кофе
isset foo; // => Uncaught ReferenceError: foo is not defined - кола

dangreen 30 мая 2014 в 14:13

Спасибо за разъяснение, подправлю.

dim_s 30 мая 2014 в 08:15

Мое единственное замечание — не делайте вы эти алиасы и возможность написать одно и тоже миллионами способами, пусть все пишут одинаково, ну что за бардак =( хочешь пиши function, хочешь void, мало 2х видов кавычек, пожалуйста — вот тебе третьи.

VEG 30 мая 2014 в 11:50

На самом деле, третий вид кавычек может быть удобным, если в строке активно используются как одинарные, так и двойные кавычки. При возвращении строки в HTML такая ситуация возможна легко. Обратные кавычки тут будут очень удобными.

-1

dim_s 30 мая 2014 в 14:04

Не нужно смешивать html код с обычным кодом, для меня это не очень приемлемо, в крайних случаях есть экранирование, а в html можно использовать и одинарные и двойные кавычки.

VEG 30 мая 2014 в 14:25

Тут в язык встроена подстановка переменных в строки. Наверное, не просто так :) Иногда бывает удобно. Хорошо, когда язык предлагает много разных инструментов на все случаи жизни. Насчёт алиасов true/false согласен, это лишнее. А вот с кавычками фишка мне нравится.

lexkazakov 30 мая 2014 в 08:52

Было бы круто увидеть прямо в статье несколько хэлоуворлдов. Для наглядности.

extempl 30 мая 2014 в 09:16

поиграться с языком вживую вы можете тут

Комментарии в скомпилированном коде нужно было оставить для сравнения. Сейчас там мало что можно быстро и без подсветки найти.

dangreen 30 мая 2014 в 09:53

К сожалению в UglifyJS нету возможности сохранять комментарии.

-1

vp_arth 30 мая 2014 в 12:24

UglifyJS

--comments
Preserve copyright comments in the output. By default this
works like Google Closure, keeping JSDoc-style comments
that contain "@license" or "@preserve". You can optionally
pass one of the following arguments to this flag:
— «all» to keep all comments
— a valid JS regexp (needs to start with a slash) to keep
only comments that match.
Note that currently not *all* comments can be kept when
compression is on, because of dead code removal or
cascading statements into sequences.

Вы используете иной UglifyJS?

dangreen 30 мая 2014 в 12:33

Извините, прочел невнимательно. Теперь в playground'е комментарии сохраняются.

knekrasov 30 мая 2014 в 10:20

но в нем нету сахарного синтаксиса

Честно говоря, меня пугают программисты, которые ставят во главу угла синтаксический сахар. Создавать язык только ради сахара — весьма странная затея. Язык должен помогать решать крупные проблемы программиста, а не помогать писать красивые однострочники.

Zibx 30 мая 2014 в 15:42

Это компилируемый в жс язык. Сахар можно поставить во главу когда понимаешь что вот уже тысячу раз писал получение предпоследнего элемента кодом вида arr[arr.length — 2], а язык позволяет написать arr[-2]. Но я пока не уверен конкретно в этом языке, пока ни один из таких языков не перевесил. Closure разве что я пока не внимательно вчитывался. На одной чаше весов оказывается дебаггинг, встраивание препроцессора в стек разработки, уменьшение скорости работы кода, на другой — скорость разработки.

knekrasov 30 мая 2014 в 22:31

Это понятно. Но непонятно, почему такой подход с собственным языком, который компилируется в другой интерпретируемый язык, возникает, в основном, вокруг JS?

В других языках почему-то такая проблема не встает. Не нравится конструкция, которую пишешь изо дня в день — первый признак повторяющегося кода (или функциональности). Тут уже рукой подать до пересмотра абстракций и DSL.

Так чем же программисты на JS отличаются от остальных?

vp_arth 31 мая 2014 в 09:32

del

VasilioRuzanni 30 мая 2014 в 11:32

Во-вторых, это структурность ( ООП, модули, пакеты… ), которую не так просто достичь на чистом JavaScript. На данный момент существуют 3 языка, обладающие почти всеми перечисленным качествами

Зачем еще один отдельный язык? Пора бы начинать использовать ES6, который все это предусматривает. Google Traceur уже отлично справляется со своей задачей транс-компиляции, и имеет маленький рантайм. Со временем это будет поддерживаться браузерами нативно и необходимость в Traceur отпадет.

VEG 30 мая 2014 в 11:55

Интересная разработка. Не глядя на критику в теме (впрочем, статья у вас действительно получилась «бедная»), всё равно продолжайте разработку. Прогресс часто двигается именно строителями велосипедов, которым удаётся придумать, как сделать привычные вещи удобнее.