@rodweb1 окт 2013 в 14:57

Нам не нужен ваш кофе

5 мин

71K

CoffeeScript * JavaScript * Веб-разработка *

Перевод

+151

445

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

@AndreyTS 1 окт 2013 в 15:21

А отличная идея — в более широком смысле — вообще запретить окружающим: говорить непонятные мне слова, т.к. «я их не понимаю», оперировать непонятными мне концепциями, т.к. «они мне не знакомы» и т.д. Далеко пойдет автор :)

@dpigo 1 окт 2013 в 15:35

По-моему в контексте статьи ( вопросы и ответы на SO) аналогия не вполне корректна. Ведь если вы спрашиваете о правилах построения предложений на русском, то ответ о таких правилах на языке эсперанто вас не очень устроит. Особенно если их будут пытаться выдать за правила для русского языка.

@AndreyTS 1 окт 2013 в 15:48

Но автор-то даже и спрашивать на эсперанто запрещает. Это вообще, по-моему, за гранью.

Насчет ответов — с одной стороны, соглашусь, на js общепонятнее будет.

С другой стороны — ответ на SO дело добровольное, как и чтение такого ответа. И если человек хочет потратить свое время на ответ, и в качестве «платы» желает популяризовать что-то, например, любимый диалект, почему он не вправе? Не понимаете coffee/typescript/… — пропускайте этот, читайте другие ответы. Давший ответ ничем не обязан вам, чтобы вы ему условия ставили, правда ведь?

@dpigo 1 окт 2013 в 15:54

… и в качестве «платы» желает популяризовать ...

в качестве платы на SO — рейтинг, кстати купите слона, а? (в качестве платы за коммент)

Автор запрещает спрашивать о JS приводя пример на CS и наоборот, потому что JS isnt CS.

@AndreyTS 1 окт 2013 в 15:58

Ну может этот гипотетический популяризатор готов обменять свой рейтинг (который ему не поставят coffee-

@AndreyTS 1 окт 2013 в 16:02

Ну может этот наш гипотетический популяризатор готов пожертвовать своим рейтингом (который ему не поставят нелюбители coffee) на эту фразу. А может, ему любители кофе еще и добавят, кто знает. Слава Богу, это решает сообщество, плюсуя, а не авторитарные личности с призывами «запретить». Спасибо, слон уже есть :)

А как можно спрашивать о JS, приводя пример на CS? Ведь такой вопрос можно автоматом считать про CS, да и все.

@dpigo 1 окт 2013 в 16:07

Ну судя по тому, что автор пишет:

Перестаньте пытаться поработить людей на StackOverflow, отвечая на их JavaScript-вопросы кодом на CoffeeScript. Перестаньте пытаться получить помощь по JavaScript, выкладывая код на Coffee, который мы не понимаем.

такие случаи имеют место быть.

@VolCh 2 окт 2013 в 06:23

Слава Богу, это решает сообщество, плюсуя, а не авторитарные личности с призывами «запретить».

Вот были бы минуса…

@akzhan 1 окт 2013 в 21:26

Эсперанто, в данном случае, — это JavaScript.

@ivv 1 окт 2013 в 15:35

В статье указана конкретная проблема — не нужно пытаться поить и брызгаться. Я лично сталкивался с этой проблемой, и полностью поддерживаю. Не имею ничего против кофе, но уместно его использовать когда остальные члены команды владеют ним, а не когда один человек начинает навязывать. И почему то часто, люди, его использующие, фанатеют и пытаются сделать из других членов команды фанатов, чем тормозят процесс разработки.

@AndreyTS 1 окт 2013 в 16:04

Согласен, в команде конечно же нужно следовать общим политикам, тут и говорить нечего.

@Railsmax 2 окт 2013 в 03:42

В целом верно — но есть одно но: Следуя вашей логике как мы вообще получили ЯВУ(языки высокого уровня)? Условно говоря вся команда пишет с 0 и 1 А я тут такой раз и на ассемблере что-то написал и начал всем говорить что это круто. Это и стало круто — и на вопросы 1010101010101 ??? Мне стали все отвечать ассемблером. А потом прошло время и появился С — и все пошло по тойже схеме. Таким образом я думаю и появляются новые языки программирования, которые мы все сейчас знаем. Так что если сообществу нравится и оно пишет на чем-то — то почему люди не должны писать на кофе? Другой вопрос если человек пишет на кофе и не представляет кто-такой js, НО причем тут coffeescript? Если кто-то чего-то не знает — не надо валить на плохия языки, и вообще соседа — знать или не знать решаешь сам. И многие из нас стали забывать как выглядит в ассемблере написанный нами код…

@differentlocal 2 окт 2013 в 04:38

Неверный принцип выбора технологий, совсем неверный.

Выбирать технологии под знания *всей* команды — это прямой путь к отставанию от прогресса. «Мы этого не знаем» — это вообще не аргумент. Аргумента может быть два:

— Нам эта технология подходит (и тогда мы ее изучаем и используем)
— Нам эта технология не подходит (и тогда мы ее в этом проекте не используем, даже если знаем)

Команда, которая будет пытаться иметь равные компетенции и избегать вещей, непонятных хоть кому-то из ее членов будет хранически на несколько лет отставать от актуальных технологий, т.к. пока нечто новое узнают и освоят (без пинков, как я понимаю) *все* — пройдет очень много времени.

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

@Railsmax 2 окт 2013 в 05:10

А какие есть проекты где js подходит а кофескрипт внезапно не подходит? Имхо кофескрипт это просто удобная штука, которая заменяет чистый js. Я так понимаю что кофескрипт это не технология а просто удобство, вдобавок к технологии js(в данном контексте)

@VolCh 2 окт 2013 в 06:31

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

@Railsmax 3 окт 2013 в 06:26

Вопрос в том, действительно ли она удобная

Ну раз народ использует — то наверное удобная. Конечно могут быть мазахисты, но не все же ))

А если удобная, то не достигается ли это удобство ценой (значимой) потери эффективности.

Конечно любой интерпритатор на выходе напишет == или хуже чем знающий человек ручками. Этот момент даже и не оспаривается. С другой стороны а на сколько хуже(время отработки кода с учетом что его стало больше на пару килобайт, байт) js, который выдаст coffeescript? Я пологаю в 99% случаев разница пренебрежительна мала и действильно не играет роли на данном этапе развития хардваре и скорости интернета. Возможно у меня не такие проекты были за время существования кофескрипта, но ниразу проблем с его использованием не было в плане эффективности(Конечно никто не говорит о минифицированных js библиотеках и тому подобных вещах — просто обычные веб проект со своей внутренней логикой)

@VolCh 3 окт 2013 в 07:44

Ну раз народ использует — то наверное удобная.

На их проектах это может быть удобно, на других нет.

разница пренебрежительна мала и действильно не играет роли на данном этапе развития хардваре и скорости интернета.

Как минимум есть нетоповые смартфоны и планшеты с медленной мобильной связью.

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

@Mrrl 3 окт 2013 в 08:58

Выбирать технологии под знания *всей* команды — это прямой путь к отставанию от прогресса. «Мы этого не знаем» — это вообще не аргумент. <...>
Специалистов нужно слегка подталкивать к развитию своих знаний и навыков, даже если им этого не особо-то и хочется, но в проекте это нужно.

А нельзя ли тот же принцип применить и к читабельности кода? Чтобы не заставлять каждого писать так, чтобы было с первого взгляда понятно любому дураку, а «слегка подталкивать» остальных к умению быстро понять код любой сложности?

@horlon 2 окт 2013 в 09:44

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

@Railsmax 3 окт 2013 в 06:32

Простите а комп вы сами собирали? Ну чтоб уж был полный контроль без черных ящиков( конечно можно не знать как собрать руду и выплавить необходимы сплавы — но уж архитектура, пайка сборка и тд это я надеюсь вы сами ) Я это к тому что черных ящиков хватает и если уж предоставляют достатчно хороший ящик так почему бы его не использовать. А если есть желаение убрать черный ящик — можно в него и заглянуть и прояснить что к чему в нем(зачастую ящики пишут несколько человек и не за один два дня, а вы один — отсюда можно заключить что без яшиков сложновато будет)

@horlon 3 окт 2013 в 16:33

Еще не вечер :) Вот подучусь, еще и его соберу :)

@Railsmax 4 окт 2013 в 04:44

Но суть не изменится ) Элементы платы будут покупаться и вообще надо творить материей — ведь предметы это тот же черный ящик))

@horlon 4 окт 2013 в 06:20

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

@Railsmax 4 окт 2013 в 09:52

ОК — При первом результате фотки в студию )) А слудующую жизнь можно классифицировать как черный ящик — надо свою изобретать ))

@horlon 4 окт 2013 в 17:03

Как скажете)

@zag2art 1 окт 2013 в 15:32

Меня зовут Артур, и я поставил "+" Жду камней.

@Nordvind 2 окт 2013 в 07:14

Держите нас в курсе.

@zag2art 2 окт 2013 в 10:31

Карма -3 :)

@Tabasov 1 окт 2013 в 15:33

Ну конечно не так категорично как заявляет автор, и не сказать что я прям супер-пупер-гуру разработчик, но мне тоже ненравится идея «кофеина»

@dimitrimus 1 окт 2013 в 15:54

[offtop] еще бы «не» было написано отдельно, а то только с третьего раза понял, что все-таки «не нравится», а не «нравится» [/offtop]
а в чем его идея?

@sdevalex 1 окт 2013 в 15:41

> Нам не нужен ваш кофе
Отлично, переходите на чай =)

> Как вы собираетесь использовать ES6, когда он выйдет?
Пару коммитов быстро решат проблему, останется только пересобрать все asset. А вообще, просто внезапно ES6 не вкатится, в любом случае его нужно будет включать руками или наоборот отключать специально.

> Что за фигня происходит в скомпилированном JavaScript-коде? Я понятия не имею.
1-2 недели разработки на Coffe сделают вашу жизнь проще, а ящик прозрачней.

> Моё предложение к вам состоит даже не в том, чтобы перестать использовать CoffeeScript
Вообще стоит перестать использовать JS, там больше кода, нужно дольше печатать, тунельный синдром одобряет.

@termi 1 окт 2013 в 16:48

Пару коммитов быстро решат проблему, останется только пересобрать все asset. А вообще, просто внезапно ES6 не вкатится, в любом случае его нужно будет включать руками или наоборот отключать специально.

CoffeeScript, с вероятностью 99%, никогда не будет поддерживать блочную область видимости (let) и разряженные шаблоны деструктуризации (let [a,, b] = [1, 2, 3]; a==1, b == 3), т.к. символ запятой "," означает в CS совсем другое нежели в JS.

А если копнуть глубже, то выясняется, что конструкции for-of из ES6 и for-of из CS сильно отличаются. for-of из ES6 итерируется по объекту используя его встроенное свойство «iterator», тогда как for-of из CS это скорее сахар для for-in. Сильно сомневаюсь, что без ввода дополнительных конструкций языка в CS появится аналог for-of из ES6.

Да и аналога генераторов, по крайней мере в доке на coffeescript.org, я найти не могу.

В таком случае, после внедрения ES6, CS останется в роли догоняющего, и не факт, что майнтейнеры захотят сильно менять язык и быстро вводить новые фичи. В своё время, люди не довольные скоростью развития CS создали LiveScript, а это о многом говорит.

CoffeeScript хороший язык, но я лично предпочту TypeScript или EcmaScript6

@sdevalex 1 окт 2013 в 18:46

Часто используете for-of? Я за два года разработки на коффе ни одного раза, есть удобный each, другого и не надо. И если у объекта есть свойство iterator, то функции перебора будут его использовать. И вообще перебор редко используется, чаще всякие map, every, reduce…

let [a,, b] = [1, 2, 3]
не сильно отличается от CoffeeScript
[a, _, b] = [1, 2, 3]
[a, t, b] = [1, 2, 3] (eсли _ занято underscope.js)

@termi 1 окт 2013 в 23:47

[a, _, b] = [1, 2, 3]

Согласен, но всё-таки смысл в том, что синтаксис деструктуризации отличается в CS и ES6. И это печалит.

Часто используете for-of?

В ES6 for-of /будет/ очень полезный. Особенно в сочетании с итераторами и генераторами. Так что я буду всё больше и больше его использовать.

@XimikS 1 окт 2013 в 15:46

1. Обфусцирован? Компилятор CoffeeScript генерирует код, который отличается от кода, который напишет человек, но он вполне читабельный. Но обфусцированный?! Неа:)

2. Полностью согласен с утверждением, что код на CS нужно дублировать кодом на JS.
Впрочем, не везде, на рельсах например CS есть по умолчанию, и большинство девелоперов-рельсовиков его знает :)

3. Странный наезд на алиас isnt(!==) и конструкцию из VB. Какой то консерватизм, как аргументы против выделения кодом отступами. JS сам по себе не самый легкочитаемый и вообще простой язык с классным синтаксисом. Благо, это исправляется новыми версиями
isnt добавлен в язык для придачи ему большей человечности (пожалуй, как и конструкция из VB), и легко читается, если девелопер хоть чуть-чуть знает английский, это разумная эволюция, а если ваш глаз привык цепляться за = , то любой редактор выделяет isnt совершенно тем же цветом. Ну а то, что автор пихал конструкцию из VB куда не надо и потом весело дебагил — его проблемы.

4. Не знаю где автор увидел черный ящик. Используя диалект языка, предполагается, что девелопер знает этот самый язык, и то, во что выльется подслащенная конструкция. Документация у Coffee очень понятная, читается буквально за пару часов, и даже в IDE лезть не надо, на сайте уже есть интерактивный shell.

Короче, единственный нормальный аргумент — дублируйте код на CS кодом на JS.

@XimikS 1 окт 2013 в 15:54

5. Наезд на ASM.JS показывает непрофессиональность автора: ASM.JS не для написания кода ручками, а для транслирования кода из других языков, например.

@putnik 1 окт 2013 в 16:19

Для написания тоже. Иногда есть отдельные небольшие куски, которые имеет смысл писать на asm.js ради оптимизации.

@Louter 3 окт 2013 в 10:48

Это извращение, поверьте. Сам писал, десяток подводных камней, скорость выросла, но не существенно.
Для написания он предназначен так же, как ваза для забивания гвоздей)

@merlin-vrn 2 окт 2013 в 04:58

Этот последний нормальный аргумент можно продолжить: а раз уж всё равно вам придётся писать на JS, зачем вообще заморачиваться с CS?

@VolCh 2 окт 2013 в 06:34

Используя диалект языка

Разве это диалект, а не другой язык?

@jj_killer 1 окт 2013 в 15:47

Одна из самых ужасных статей, которые попадали на HN с того времени, как я на него подписан. Для тех кто работал с большими проектами на JS очевидно, что язык проектировался не на такие масштабы.

А автор оригинальной статьи настолько невежествен, что даже не знает, что на диалекте asm.js не предполагается ничего писать и уж тем более изучать код транслированный из него. Автор просто ленится потратить от силы две недели на изучение такого просто языка как Coffee. Что уж тогда обвинять людей в том, что они не хотят выучить хоть один функциональный язык для разнообразия.

@agentx001 1 окт 2013 в 16:42

Автор просто ленится потратить от силы две недели на изучение такого просто языка как Coffee.

Не хочу показаться бахвальным, но за три вечера переписал проект на CS, хотя до этого никогда его в глаза не видел. Практика, практика и эта инструкция вам в помощь ;)
P.S.: Чем ему isnt не угодил? Не часто встречаемая конструкция, но вот is not — действительно круто и ёмко выглядит!

@jj_killer 1 окт 2013 в 16:50

Во-первых, его никто не заставляет использовать ее в CS, во-вторых, очень сомневаюсь, что наличие isnt хоть как-то затрудняет чтение кода. Это просто ханжество по поводу синтаксического захара.

@hubhito 1 окт 2013 в 18:35

На самом деле is и isnt очень крутая штука, она оберегает от случающихся даже у опытных программистов проблем с написанием = вместо ==.

@slayerhabr 1 окт 2013 в 22:58

ага, а
struct?.substruct?.field
экономит нервные клетки

@Mithgol 2 окт 2013 в 05:48

От проблем с написанием «=» вместо «==» можно и другим способом избавиться, не переходя с JavaScript на другой язык.

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

@merlin-vrn 2 окт 2013 в 06:10

как говорится, «от перестановки слагаемых»…
if (5=q) — опа, ошибка синтаксиса, lvalue нельзя присвоить
if (5==q) — то, что мы хотели написать

@Mithgol 2 окт 2013 в 06:51

А вот этой RTL-практики я избегаю, потому что меняется шило на мыло. (Ценою ловли ошибок становится некоторое падение читаемости.)

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

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

@VolCh 2 окт 2013 в 07:18

От перестановки мест слагаемых сумма не изменяется. К «читать справа налево» это отношения не имеет. А, имхо, читаемость даже повышается, если вместо q стоит сложное выражение.

@burjui 2 окт 2013 в 16:01

Ставить сложные выражения прямо в условный оператор — моветон. Всё равно лучше вынести в отдельную переменную с содержательным именем. Что касается условий Yoda-style, то я их не использую, т.к.:
1) Никогда не ошибаюсь с = вместо ==
2) Если всё же ошибусь, компилятор ругнётся
3) Снижается читабельность: всё же приучать себя читать «5 равно x» как «x равно 5» — это как дать себе в глаз, а потом класть туда лёд

@grossws 2 окт 2013 в 11:26

if(b = a) { ... }

вместо

if(b == a) { ... }

и всё…

Yoda-expressions помогают только пока одним из элементов сравнения не является lvalue.

@merlin-vrn 2 окт 2013 в 11:46

да :(

@bubuq 3 окт 2013 в 07:19

У меня частенько написано if(а=б), и это именно то, что я имею в виду, так что Хинт не всегда поможет.

@merlin-vrn 3 окт 2013 в 07:27

Зря вы так пишете.

@bubuq 3 окт 2013 в 08:34

Ну как. Я просто знаю, что у меня в коде на CS только 'is' и 'isnt', и знак равенства может обозначать только присваивание, и у меня нет рефлекса воспринимать это как сравнение.

@merlin-vrn 3 окт 2013 в 08:36

Это потому, что вы один работаете над проектом. Когда разработчиков несколько, приходишь к выводу, что лучше написать три строки, но в которых ошибка видна сразу, чем одну мудрёную и вот с такими неочевидными местами.

@khim 1 окт 2013 в 19:32

А автор оригинальной статьи настолько невежествен, что даже не знает, что на диалекте asm.js не предполагается ничего писать и уж тем более изучать код транслированный из него.

Неа. Автор статьи настолько невежественен, что начинает своё повествование со ссылки на реальный код из реального проекта, который реально руками написано на asm.js.

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

@gaelpa 2 окт 2013 в 10:34

А вы в С-коде ассемблерные вставки никогда не встречали?
Надо заметить, что повествующий автор указал ссылку на асм.js реализацию математического по сути алгоритма, который без асм.js был бы записан в том коде абсолютно точно так же (за исключением специфичных определений типов переменных).

@khim 2 окт 2013 в 16:39

Ага. И обращения к элементам массива тоже писались бы как H[j<<2>>2]? Ню-ню.

@gaelpa 2 окт 2013 в 20:15

Хм, а как бы вы по-другому записали это выражение?

@khim 2 окт 2013 в 23:29

В нормальных языках как бы принято его записывать как H[j] всё-таки. Или если уж так хотите указать тип, то H[j|0]. Но H[j<<2>>2], извините, ни в какие ворота не лезет.

@gaelpa 3 окт 2013 в 01:12

Я, если честно, не очень понял смысл этой операции в контексте индекса массива, но похоже на сброс двух старших битов.
В спеках asm.js указано, что таким маневром можно привести выражение к signed, однако это делается и через |0.
Сомневаюсь, что алгоритм вычисления хэша использует массив на 4 гигабайта и в старших двух битах может оказаться что-то существенное.
Может кто знает в чем тайный смысл?

@Mrrl 3 окт 2013 в 08:42

Вопрос в том, какого типа j. Если знаковый — то это распространение старшего бита на два следующих. В применении к индексу массива — довольно бессмысленная операция. Если беззнаковый, то на не RISC платформах дешевле написать эквивалент H[j&0x3FFFFFFF].
Кстати, кто-нибудь понял, что там за константы? 1518500249 = sqrt(2)*2^30, 1859775393 = sqrt(3)*2^30. Но что такое 1894007588 и 899497514?
Я немного сомневаюсь, что код был написан руками. В лучшем случае — отредактирован. Впрочем, я не знаю JS, так что, возможно, всё не так.

@Mrrl 3 окт 2013 в 11:21

Но что такое 1894007588 и 899497514

Вопрос снимается, всё очевидно… но почему они такие? В описании алгоритма даются без объяснения.

@grechnik 4 окт 2013 в 12:31

Потому что это константы из определения SHA-1?

@Mrrl 4 окт 2013 в 12:43

Хорошо, но в более развёрнутом виде вопрос выглядит так. Почему в определении SHA-1 выбрали именно константы sqrt(k)*2^30 для k=2,3,5,10? Есть ли за этим какие-нибудь математические доводы, или просто разработчикам это показалось хорошей идеей? Приводится ли где-нибудь выражение этих констант через квадратные корни, или люди должны догадываться сами? Быстрый поиск ничего про происхождение констант не дал.

@grechnik 4 окт 2013 в 12:52

Википедия говорит, потому что какие-то константы были нужны, а если константы брать «с потолка», могут возникнуть подозрения на бэкдор.

The constant values used are chosen as nothing up my sleeve numbers: the four round constants k are 2³⁰ times the square roots of 2, 3, 5 and 10.

@Mrrl 4 окт 2013 в 13:02

Спасибо. Не заметил этой фразы. Надо будет взять это объяснение на вооружение — тогда никому не придёт в голову искать секретные соотношения между параметрами.

@khim 3 окт 2013 в 15:40

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

Неа. Похоже на asm.js. Вот тут же уже писали: если этого не сделать, то asm.js будет считать, что вы обращаетесь к байтам, а не к 32битным int'ам.

@Mrrl 3 окт 2013 в 16:23

Это ещё один довод в пользу того, что код писался не вручную. Если бы его писал человек, то сразу бы работал с учетверёнными переменными i,j,k и константами смещений, и не пришлось бы каждый раз писать <<2. Код стал бы несколько понятнее.

@khim 3 окт 2013 в 17:59

О боги! Я понимаю, что «доктор сказал в морг — значит в мог», но есть же какие-то пределы. Вот как раз написание кода человеком к таким ужасам и проводит.

Компилятор автоматически порождает учетверённые переменные потому как у него это не индекс в масиве, а совсем даже наоборот: «адрес переменной». А чтобы получить-таки индекс в мессиве адрес переменной положено делить на 4 (комиляторы в asm.js обычно складывают все переменные в один массив). На чём в результате и настаивает asm.js.

А человеку, знаете ли, свойственно оперировать индексами, а не учетверёнными индексами. Louter (с хабра) написал точно такой же код, только с <<3>>3 вместо <<2>>2) в своей статье.

@Mrrl 3 окт 2013 в 19:43

Если человек полез на этот уровень оптимизации, то работать с учетверёнными индексами ему ничего не стоит. Когда в ассемблере ещё не было этих новомодных [eax+ebx*4], то люди нормально работали и с удвоенными-учетверенными индексами, и с адресами — в отличие от компиляторов, которые по любому поводу тупо считали адрес через сдвиги и сложения.

@khim 3 окт 2013 в 20:01

Если человек полез на этот уровень оптимизации, то работать с учетверёнными индексами ему ничего не стоит.

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

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

Вы бы ещё про компиляторы Фортрана 60х годов вспомнили! Современные компиляторы, как бы, самую малось поумнели и уже давным-давно такого не делают.

@Mrrl 3 окт 2013 в 20:18

Так современные процессоры сами умеют умножать индекс на 4 в пределах одной команды. И компиляторам работать с адресами больше не нужно, они предпочитают индексы. И получается эффективнее.
А что касается той статьи — вы что, серьёзно думаете, что там приведена настоящая программа? С такой строчкой:

tp[(i << 3) >> 2] = +(+2 * tp[((i - 1) << 3) >> 3]);

Судя по тексту статьи, на неё будет выдан type error с требованием сдвига на 3 бита.

@Mrrl 3 окт 2013 в 20:26

В ссылке на настоящую программу этой ошибки уже нет. Тогда непонятно, почему было не пустить циклы с шагом 8. И быстрее, и кода набирать меньше.

@khim 3 окт 2013 в 21:29

Именно потому что что это человек писал! Он сначала написал это на JavaScript'е, а потом начал переписывать на asm.js. Получилось то, что получилось. А для того, чтобы писать нормально прямо на asm.js нужно гораздо дольше с ним общаться и эти программы будут ещё дальше от JavaScript'а — об чём, собственно, и статья.

@khim 3 окт 2013 в 21:27

Смотря какие процессоры. ARM и MIPS, к примеру, не умеют. Насчёт индексов — по разному бывает, иногда компилятору удаётся от них избавиться.

А в статье — да, там есть в конце настоящая программа.

@homm 1 окт 2013 в 15:56

Если батхерт по поводу Кофе еще как-то обоснован, то при чем тут asm.js, вообще не понятно.

@khim 1 окт 2013 в 19:34

Вы на ссылку кликали? Там asm.js написанный руками. И как вы, спрашивается, будете подобный проект поддерживать? И сильно вам помогут заявляния о том, что asm.js — это просто подмножество JS, если у вас в проекте такое встретится?

Ну откуда берётся мода критиковать статьи их не читая?

@homm 1 окт 2013 в 19:40

Ну наверное кто-то пишет руками asm.js, разработчики трансляторов в него, например. Какое это имеет отношение к coffescript и прочим? Что, на stackoverflow кто-то ответы на asm.js оставляет?

@khim 1 окт 2013 в 19:45

Пока нет, ну так со времени его создания не прошло ещё и года.

@Azzie 2 окт 2013 в 14:32

Это примерно так же, как, увидев рукописную ассемблерую вставку, заявить что «С++ — говно, смотрите во что он транслируется! Как вы будете это поддерживать?!!!111».
Автор элементарно не понял к чему там это.

@khim 3 окт 2013 в 15:47

Автор как раз понял, это вы не поняли. Я не видел ни одного человека, который бы считал, что C с ассемблерными вставками — это просто C. Нет, это другой язык и для его понимания нужны другие книжки (нужна документация на ассемблер, как минимум). Но я видел кучу народу, которые «бьют себя пяткой в грудь» и вопят, что asm.,js — это «всего-навсего JavaScript» и потому можно одновременно катить баллоны на Google за то, что он добавляет в Chrome свои вещи, которые никто больше не поддерживает (например HTML5 filesystem) и при этом добавлять поделки подобные asm.js в свой браузер ни с кем ни о чём не советуясь.

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

@VolCh 2 окт 2013 в 06:36

если на SO ответить на вопрос с CoffeeScript кодом на JS, то вопрошающий будет удовлетворён

То есть вы предполагаете, что тот, кто пишет на CS обязан знать JS?

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

@VolCh 2 окт 2013 в 07:22

Думаю, такие люди есть уже. Те, кто, скажем, начал учиться (веб-)программировать недавно и начал с RoR.

@bubuq 3 окт 2013 в 07:32

Если человек освоил такую не самую легковесную платформу, как RoR, документация к которой занимает мегабайты текста, описывающие тысячи методов, неужто он не способен прочесть один листок доков про CS за 15 минут?

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

Прошёл год, пока я более или менее уверенно стал себя ощущать в экосистеме RoR. За это время успела смениться мажорная версия. А вот когда появился CS, я переписал все свои клиентские части на нём и подумал, а ведь жаваскрипт-то классный язык, как оказалось! И ушёл с RoR на ноде.

@homm 3 окт 2013 в 07:38

Все мимо. Разговор про людей, знающий cs, но не знающих js.

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

@homm 3 окт 2013 в 09:43

Мне все равно. Я лишь указал, что комментарий bubuq был не по адресу.

@VolCh 3 окт 2013 в 07:52

Я про людей, которые начали изучение программирования с RoR, включая CS, а ни строчки на JS и не написали ни разу.

@inook 2 окт 2013 в 09:30

Это Вы еще Ember.js не видели, там сплошная магия.

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

@spmbt 1 окт 2013 в 16:06

@konsoletyper 1 окт 2013 в 16:13

Тем временем с Coffee всё наоборот. Что за фигня происходит в скомпилированном JavaScript-коде? Я понятия не имею. Для меня это чёрный ящик. Я не люблю чёрные ящики. Они чёрные и форме куба. И это всё, что я знаю о чёрных ящиках, они ничего не говорят мне о том, что происходит внутри. Написание JavaScript-кода автоматически означает, что у нас есть полный контроль над тем, что мы делаем, и это дорогого стоит

Я бы предложил автору статьи срочно выкинуть свою Linux/Windows/Mac, ведь это чёрные ящики. JavaScript тоже надо выкинуть, ведь v8/spidermonkey/любой_другой_движок написаны на C/C++, которые тоже чёрные ящики, ведь они генерят непонятный ассемблерный код. В общем, всегда же есть сердцу любимый ассемблер, на нём и надо писать, как в старые времена. И ассемблер запускать с магнитной ленты из монитора, никаких ОС.

@L3333437 1 окт 2013 в 19:13

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

@Razaz 1 окт 2013 в 16:14

В выходные как раз переводил проект с JS на TypeScript. Получилось быстро и код, генерируемый компилятором, весьма чистый и аккуратный. Плюс нормальный тайп чекинг и интеллисенс. Единственное, что пока не хватает это protected при наследовании.
Причем если уж смотреть на ES6, то порт будет просто элементарным… но это имхо канешн…

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

@akzhan 1 окт 2013 в 21:31

git bisect?

@asci 2 окт 2013 в 07:24

неужели IDE не научились контролировать отступы? Одним пробелом ведь не обойдется, надо либо 2 либо 4.

@merlin-vrn 2 окт 2013 в 07:29

Пайтоновские IDE очень даже научились контролировать отступы :) как и те, которые поддерживают yaml, jade и прочие подобные языки.

@Azy 2 окт 2013 в 13:54

смените ваш текстовый редактор на человеческую IDE

@rodweb 3 окт 2013 в 09:15

Можно поинтересоваться, что это за IDE/редактор?

@Azy 3 окт 2013 в 09:16

Pycharm. Подозреваю что остальные от IDEA (WebStorm, PHPStorm etc) имеют ту-же функциональность.

@VolCh 3 окт 2013 в 09:17

Угу, имеют.

@Yanzay 1 окт 2013 в 16:36

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

@AleksDesker 1 окт 2013 в 16:57

I am as mad as hell, and I am not gonna take this anymore!

@orcy 1 окт 2013 в 16:57

Немного не согласен с тем что JavaScript это такой белый ящик, а CoffeeScript это такой черненький. Если у coffee нет проблем с синтаксисом, то черным ящиком он может быть только с точки зрения производительности, но вообще говоря сам JavaScript является таким черным ящиком где разные браузеры показывают разную производительность (например есть две альтернативные конструкции для достижения одной цели, в разных браузера будет выигрывать либо одна либо другая конструкция).

С основным тезисом я правда согласен, т.к. сам я кстати coffeescript решил не осиливать.

@mahnunchik 1 окт 2013 в 17:01

Автор, а что в вашем понимании черный ящик?

@Mithgol 1 окт 2013 в 17:11

Не думаю, что Nicolas Bevacqua читáет Хабрахабр.

@AleksDesker 1 окт 2013 в 17:15

Позволю себе ответить за него — не очевидные: поведение компилятора, внутреннее устройство функций, конструкций языка и т.д. (Это не упрек в сторону кофе, я его не знаю чтобы судить, но это то, от чего мне становиться страшно, когда я слышу его критиков и причина моего незнания)

@mahnunchik 1 окт 2013 в 17:24

Извиняюсь, пропустил первые строчки поста.

В оригинале забавен вот этот комментарий:

well, since javascript is the new assembler, no wonder people HAVE to use something more sane :)

@AleksDesker 1 окт 2013 в 17:30

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

@can3p 1 окт 2013 в 17:27

Я не понял, как ES6 должен сломать coffeescript. Все спецификации ecmascript обратно совместимы, и уже это гарантирует, что с кодом на coffeescript ничего не случится.

Ну а в целом странный пост. Язык завоевал популярность, по читаемости сгенерированного js-кода он один из лучших, там нечего расшифровывать. И как бы ни хотелось автору или кому-то еще, coffeescript есть и будет. Постить скомпилированный coffeescript — тоже не самая хорошая идея, т.к. не очень красиво будет, и уж тем более не очень понятно, т.к. наружу вылезет куча внутренних переменных.

По поводу «не заставляйте меня учить ваш язык». Возможно и стоило поучить, благо спецификация у языка миниатюрная, заодно стало бы понятно, почему другие программисты его использовать любят.

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

@AleksDesker 1 окт 2013 в 17:51

Прочитайте про автора: «I started building all kinds of web applications using C#, and developed a great interest in JavaScript,» человека который пришел в фронтенд через Си сложно заподозрить в слепом невежестве, скорее наоборот он подозревает фанатов кофе в таковом и боится, что они побегут по граблям которые уже давно известны в других языках и решил потроллить чутка, чтоб решить стоит обратить на этот кофе внимание или он исключительно для дикарей, которым не интересны perfomance, отладка, поддержка и т.п.

@ivan_kolmycheck 3 окт 2013 в 11:04

пришел в фронтенд через Си

Сишарп — это не Си, не надо путать. ;)

@vitvad 1 окт 2013 в 17:52

Согласен с автором статьи.
Почему большенство пишет, что он не хочет учить CoffeeScript? Мне кажется идея его поста не в этом. Любой хороший разработчик побежит учить новый диалект если это сохранит ему время и поможет ему (все мы лентяи). Мне кажется большенство js-разработчиков интересовались и пробовали Coffee, но не всем нравится его синтаксис и не всем он полезен. И я один из них. Я сделал несколько проектов на Coffee, но я все же предпочту чистый JS (я говорю о синтаксисе, а не использовании библиотек и фреймворков).

<вброс>
Когда только начал интересоваться Coffee. Меня до глубины души поразила конструкция вида:

# Conditions:
number = -42 if opposite

она мне до сих пор снится в кошмарах.
</вброс>

Очень интересно было бы посмотреть на результаты такого опроса (поиском не нашел):

В проектах используется преимущественно:
— TypeScript
— CoffeeScript
— Другой диалект (Caffeine) например
— Только Хардкор! JavaScript

Если я буду начинать проект буду писать на:
— TypeScript
— CoffeeScript
— Другой диалект (Caffeine) например
— Только Хардкор! JavaScript

У кого есть это самое, сделайте пожалуйста.

@AleksDesker 1 окт 2013 в 17:58

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

@vitvad 1 окт 2013 в 18:02

не путайте диалекты языка с библиотеками и фреймворками. jQuery тут не причем.

@AleksDesker 1 окт 2013 в 18:10

Де-юре это библиотека, но де-факто, судя по размеру влияния оказываемого на исходный код — вполне себе диалект.

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

@AleksDesker 1 окт 2013 в 18:19

В этом и есть часть претензии автора: «What? It's not non-sense, it's beautiful! It's JavaScript.», что его позиционируют именно как тот же JS, а не как что-то неведомое. Так что если уж сравнивать, то должен быть этот пункт.

@termi 1 окт 2013 в 23:54

Я может быть сейчас скажу что-то крамольное, но, по моему, jQuery больше не нужен. По крайней мере в новых проектах, где используется декларативный подход, jQuery только мешает. Да, я понимаю, что во многих декларативных фреймворках jQuery используется «по капотом» — ну так пусть он там и остаётся. Раздражает, когда люди продолжают использовать $.proxy, $.each, $.inArray и иже с ними.

@AleksDesker 2 окт 2013 в 11:21

Что значит не нужен, что опять по пол страницы для создания XMLHttpRequest писать? $.each мне не нужен, но я не могу представить современный сайт, в которой можно обойтись без jQuery, не переписывая существующих там функций для всяких полезных свистелок.

@termi 2 окт 2013 в 11:47

Что значит не нужен, что опять по пол страницы для создания XMLHttpRequest писать?

Ну зачем вы так утрируете?

let xhr = new XMLHttpRequest({anon: true});//anonymous request
xhr.open("GET", "api.site.com");
xhr.responseType = "json";
xhr.onload = function(){
    xhr.response;//this is JSON object
}
xhr.send();

Посылает анонимный запрос и получает ответ в JSON формате. Да, я согласен, что этот код без полифилов работать не будет, да и вызов `open` избыточен, но это не пол страницы.

В современных web-приложениях больше необходим socket.io и подобные, чем $.ajax.

Что ещё остаётся?
$.css — менять стили в js-коде это быдлокод, нужно пользоваться css-классами
$.[add/remove/toggle]Class — node.classList.[add/remove/toggle] удобнее и быстрее, да и менять классы в js-коде это моветон — нужно использовать БЭМ модификаторы, методов работы с которыми в jQuery нету.
$.bind и $.trigger — это полный провал и в версии 2.0 они их не улучшили. Можно продолжать использовать только по привычке, и то, с декларативным подходом, вам не понадобится /часто/ использовать $.bind
Выбор ($.find) и манипулирование DOM-элементами ($.append, $.after и т.д.) — эти функции должен предоставлять Декларативный фреймворк, а то, что он «по капотом» использует jQuery не должно вас волновать.

Остаётся только $.Deferred, но его хотят добавить в следующую версию DOM4 API, поэтому он будет поддерживаться браузерами нативно.

Я не говорю, что нужно прекратить использовать jQuery, нет. Просто большинство декларативных фреймворком предоставляют API отличное от jQuery и говорить, что jQuery это неотъемлемая часть языка (тут я утрирую и преувеличиваю, но всё же) это неправильно.

@AleksDesker 2 окт 2013 в 12:02

Понятно, вопрос только в терминологии, просто ваше: «Давайте использовать фреймворк, у которого jQuery внутри» для меня не значит: «jQuery больше не нужен».

@ainu 2 окт 2013 в 12:33

XMLHttpRequest не кроссбраузерный. Сейчас, конечно, времена не те, но изначально приходилось два разных объекта создавать. Кроме того, если необходимо создавать два разных запроса, то необходимо создавать два разных экземпляра класса, в каждом из которых используется свой XMLHttpRequest.
В общем, там подводных камней то ещё количество. Решением может быть своя мини-библиотека, да, но jQuery сейчас весит меньше некуда.

@vitvad 1 окт 2013 в 18:00

В дополнение к опросу, еще было бы не плохо видеть, кроме использования, в проектах вопрос:

Я знаю синктаксис и могу писать проекты на: (Checkbox'ы)
— JavaScript (просто для сравнения, а вдруг кто-то может только на Coffee писать)
— CoffeeScript
— TypeScript
— другой диалект

@jj_killer 1 окт 2013 в 18:00

А что не так с конструкцией? Издавна используется в руби и всех там радует, собственно оттуда и перешла в CS. Если не знаете в каких случаях ее применяют, не значит, что она плоха.

@vitvad 1 окт 2013 в 18:12

Я писал на Pascal, C/C++, Delphi, PHP, JS, сейчас начинаю учить Python. Могу ошибаться но ни в одном из этих языков я не видел подобных конструкций. Для меня вобще дико видеть в ЯП конструкцию вида: определение-условие (statement-condition). Для меня более логично выглядит условие-определение. Никто не мешает не использовать такие конструкции, но наверное именно по этому мне Ruby тоже не нравится. ^{мое субъективное мнение}

Назовите еще один ЯП, где используется такая конструкция?

@jj_killer 1 окт 2013 в 18:25

Ну, это вы читая видите определение-условие, транслятор видит как условие-определение. Пример применения, собираем длинную строку, предположим uri:

uri  = "http://"
uri += site_name
uri += "/"
uri += resource
uri += utm_source unless admin?

Удобно, код читаемый и простой (даже unless), легко поддерживается.

Собственно определение (присвоение, биндинг и т.д.) это тоже действие, и ничем не отличается от:

do_this if that

@vitvad 1 окт 2013 в 19:26

Ну мы же с вами не трансляторы. Транслятору можно скормить и такое:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
------.--------.>+.>.
А ну да...

По поводу удобства использования, давайте наверное оставим эту тему, вам удобно мне нет.

Включая C, Python, PHP, JS.

Можно примеры такого кода на перечисленных языках?
JS:

 var a = some || "data";

не в счет, это не тоже самое что


var a = some if(some)

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

uri  = "http://"
uri += site_name
uri += "/"

... еще много строк

uri += resource
uri += utm_source unless admin?

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

тернарный условный оператор

даже Wiki дает определение логическое выражение ? выражение 1 : выражение 2

@jj_killer 1 окт 2013 в 19:31

Зависит от кода, тут вам ветки не нужны. Admin тут вполне определен (true или false).

@jj_killer 1 окт 2013 в 19:59

Мне кажется, что я, наверное, неточно выразился, раз не только вы меня неправильно понимаете. Смотрите, классическое определение: логическое выражение ? выражение 1 : выражение 2, вы просто убираете выражение 2 и у вас остается логическое выражение ? выражение 1, формой чего и является do_this if that. Варианта выражение 2 нету, ни null, ни false, ни undef. Выражение 1 просто не выполняется.

@homm 1 окт 2013 в 20:05

вы даже неправильно понимаете эту конструкцию

> Выражение 1 просто не выполняется.
Дак в этом и проблема. Потому что до того, как «вы просто убираете выражение 2» Выражение 1 всегда выполняется.

@jj_killer 1 окт 2013 в 20:07

Если логическое выражение правдиво, если ложно, выполняется выражение 2.

@homm 1 окт 2013 в 21:38

Вы правы, тут я фигню написал. «that ? do_this» и «do_this if that» отличаются порядком следования выражений.

@homm 1 окт 2013 в 19:28

В чем удобство? В том, что выглядит красиво, все ровно в столбик? Любой человек, бегло взглянув на этот кусок, будет уверен, что url всегда собирается из 5 частей. Это очень опасная конструкция.

@jj_killer 1 окт 2013 в 19:30

Ага, в этом удобство. И если не перегружать этим код, то все очень приятно и всем понятно. Не вижу причины не использовать это.

@homm 1 окт 2013 в 19:33

> Ага, в этом удобство.
Дак это не удобство, а красота. Вам лучше заняться рисованием, в таком случае.

> и всем понятно
При беглом взгляде непонятно.

@jj_killer 1 окт 2013 в 19:34

Взрослые слова, взрослого мужчины!

@jj_killer 1 окт 2013 в 18:35

О, да, на вопрос где еще. Везде где синтаксис разрешает использовать тернарный условный оператор. Включая C, Python, PHP, JS. Только это не везде считается хорошей практикой из-за возможной неоднозначности. В Руби неоднозначность просто разрешают убрать (else).

@homm 1 окт 2013 в 19:22

Ну вот видите, вы даже неправильно понимаете эту конструкцию. Это не тернарный оператор с опущенным else, это вывернутое на изнанку условный оператор. Т.е.
a = b if that
означает
if that a = b
а не
a = that ? b : null

Такого нет в перечисленных вами языках.

@jj_killer 1 окт 2013 в 19:27

Python:

a = "b" if 1 > 0 else "c"

@homm 1 окт 2013 в 19:31

Езе раз: вы даже неправильно понимаете эту конструкцию.

 a = b if that

означает

if that
  a = b

а не

a = (b if that else null)

@vasachi 1 окт 2013 в 19:45

Поменяйте null на undefined, и будет ровно то же самое.

@homm 1 окт 2013 в 19:49

А так?

a = c
a = b if that

И так?

killAllHumans() if that

Что, ровно то же самое?

@jj_killer 1 окт 2013 в 19:47

Собственно выбросьте else, потому что если do_this if that, если that не истинно ничего не выполниться. Я изначально не говорил, что это тернарный оператор, это был пример определение-условие.

@homm 1 окт 2013 в 19:52

> Собственно выбросьте else

Откуда? Из вашего примера на Питоне?

>>> a = "b" if 1 > 0
SyntaxError: invalid syntax

>>> Назовите еще один ЯП, где используется такая конструкция?
>> Везде где синтаксис разрешает использовать тернарный условный оператор.
> Я изначально не говорил, что это тернарный оператор.

Что, простите?

@jj_killer 1 окт 2013 в 19:55

Вопрос изначально стоял в том, что: a = b if that больно уж дивно, а = b if that else this, нет. Я не совсем понимаю, почему первый вариант это странно и ужасно, а второй с гораздо более сложной логикой, очень даже ок.

@homm 1 окт 2013 в 20:02

Ну потому что вы не понимаете принципиальных различий этих конструкций.

Во втором варианте написано «а ровно». Справа написано чему: «тому или тому». При любом исходе выражение «а ровно» будет исполнено.

В первом варианте тоже написано «а ровно», но на самом деле «а может и не равно, и вообще я передумал, эта строчка ничего не делает». Хорошо когда выражение состоит из трех слов. Но потом оно разростается, условие переносится на вторую или третью строчку.

Никто не спорит, что «а ровно тому или тому» это проще и удобнее чем «если что-то то а равно тому, иначе а ровно другому», но тут другая история.

@jj_killer 1 окт 2013 в 20:04

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

@homm 1 окт 2013 в 20:06

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

@jj_killer 1 окт 2013 в 20:10

Ну как по мне, так оба этих выражения одинаково предсказуемы. Я никогда не испытывал проблем ни с одним из них.

@homm 1 окт 2013 в 20:19

А вам надо неприменно испытать проблемы? У конструкции есть объективный недостаток: она затрудняет чтение кода. Выше я вам написал «Любой человек, бегло взглянув на этот кусок кода, будет уверен, что url всегда собирается из 5 частей». Это просто есть, спорить тут бесполезно. Разве этого недостаточно, чтобы её не использовать?

@jj_killer 1 окт 2013 в 20:23

Если вы пишете на руби, то ничего подобного вам в голову не прийдет. Потому что руббист отлично понимает, что если do_this if that, то это trailing conditional или statement modifier (простите, не уверен как правильно перевести). С вполне предсказуемым поведением. Ничем не хуже:

if that
  do_this
end

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

@jj_killer 1 окт 2013 в 20:30

Ну если вы не пишете на языке который позволяет использовать trailing conditional'ы вы и не увидите такого кода.

@merlin-vrn 2 окт 2013 в 06:08

Вы всё время апеллируете к руби в духе «раз в руби есть, значить и в других можно».

Тут проблем две: во-первых, не факт, что то, что хорошо в руби, хорошо в других случаях. А во-вторых, не факт, что это хорошо в руби.

Вообще я лично не принимаю никак апелляцию к руби. Я нахожу его синтаксис трудно воспринимаемым. Ну, т.е. «в руби отлично видно» — неправда, ничего там не видно.

Можно, пожауйста, видеть обоснование нереального удобства этой фичи (с trailing conditional) без привлечения руби?

@jj_killer 2 окт 2013 в 06:16

Потому как CoffeeScript изначально писался с оглядкой на опыт Руби. И то что вы при этом не принимаете апелляцию к Руби, лично ваша проблема. Автор CS (не забываем, что он еще и автор Backbone с Underscore) когда создавал язык, решил перенести все, что он считает хорошим из Руби в CS.

Я и Джереми Ашкеназ считаем, что все отлично видно, как и десятки тысяч других людей. Никто вам ничего не навязывает, никто не всучивает вам CS и не проплачивает это, сообщество само решает принимать технологию или нет.

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

@merlin-vrn 2 окт 2013 в 06:46

if (cond) x=y

Где здесь три строки? А это — как раз точная копия вашего x=y if(cond). Только здесь сразу видно, с первых двух символов, что это условие. А теперь сравнте с x=y.lf(cond). Легко визуально отличить от trailing-условия? В нормальном случае такой путаницы вообще возникнуть не могло.
Я вообще не понимаю, почему в этой ветке появилось сравнение с тернарным оператором, когда trailing condition являются обычным условным выражением.

Представьте себе, как один человек диктует номер телефона другому, а тот его сразу же набирает: «один… два… два… три… семёрки...» — в подавляющем большинстве случаев будет набрана неправильная тройка. «Семёрки» и есть «trailing» выражение, меняющее смысл предыдущего выражения. Плохо, никто в здравом уме так не делает даже в обычной речи, где некоторые вольности допускаются. Зачем же это допускать в языке программирования, где вольностей хотелось бы поменьше?

@jj_killer 2 окт 2013 в 06:58

Я уже отвечал на эти вопросы, таких проблем не возникает в реальном коде. Сравнение с trailing condition появилось потому, что это однострочник такой же как и trailing condition, только без else (это тоже уже обсудили).

Насчет номера телефона глупый приммер, взрослые люди читают текст не по буквам и не по слогам. Но это уже вопрос к лингвистам. Я вообще читаю код по строкам (если это не Лисп).

Я бы хотел прояснить оди вопрос. Вы, не писав на языке, утверждаете, что это не удобно? То есть, например, чтобы мне заявить, что мне не нравится язык, не достаточно посмотреть и субьективно оценить, как что. Вот Python, мне понадобилось почти два года чтобы понять, что Руби мне ближе и удобнее. Я не совсем понимаю, когда вы приходите и говорите, что это ужасно. Почему тут не отписался ни один рубист, и не сказал, что trailing condition это ужас?

Не находите, полученный в боях опыт, стоит больше, чем субъективные убиждения?

@homm 2 окт 2013 в 07:14

> таких проблем не возникает в реальном коде
Не правда.

Насчет номера телефона очень правильный пример.

> Я вообще читаю код по строкам
Охотно верю. Именно по этому вы можете не испытывать проблем с trailing condition, но скорость чтения кода от этого страдает.

> Вы, не писав на языке, утверждаете, что это не удобно?
Я например утверждаю что это без разницы тому, кто пишет и сильно затрудняет чтение тому, кто читает.

> Почему тут не отписался ни один рубист, и не сказал, что trailing condition это ужас?
Так же как не отписался ни один рубист и не поддержал вас.

@jj_killer 2 окт 2013 в 07:15

У меня нет сил больше спорить, удачи всем вам.

@merlin-vrn 2 окт 2013 в 07:27

Я уже отвечал на эти вопросы, таких проблем не возникает в реальном коде. Сравнение с trailing condition появилось потому, что это однострочник такой же как и trailing condition, только без else (это тоже уже обсудили).

Однострочник — конечно, похоже. Но суть-то разная. Так-то и вызов функции, и возврат результата функции — тоже однострочники, вы же с ними на этом основании не сравниваете trailing condition?

Я видел ваше обсуждение, полное непонимания того, чем trailing condition отличается от тернарного оператора. И тут оно опять. В том и дело, что сравнивать нужно логически сходные конструкции, а не похожие по форме.

Взрослые люди в большей части мира читают слева направо. Тут ниже Мицгол раскритиковал даже выражение типа if (5==q) (как средство гарантии защиты от путаницы межу == и =), мол, «сами слева направо читайте». Ваше условие в конце ещё лучше. Почему оно в конце, когда при выполнении строки проверяется первым (и следовательно, это первое, на что нужно обратить внимание при чтении этой строки)?

А рубистам просто невгодно писать, что какая-то конструкция руби — это плохо, это ж надо признать неидеальность своего любимого инструмента :)

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

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

@merlin-vrn 2 окт 2013 в 08:48

а чем же в CS отличается
if cond then x=y
и
x=y if(cond)
?

В первом случае: если выражение cond вычисляется в «истина», переменная «x» получит значение, равное результату вычисления выражения y. Если выражение cond вычисляется в «ложь», и переменная x была определена, она сохранит значение, иначе она так и будет не определена.

Чем отличается логика второго случая?

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

@merlin-vrn 2 окт 2013 в 09:29

Вы всё-таки определись уже, что и чему соответствует, а то вы пишете:

На всякий случай замечу, что эквивалентом if (cond) x=y в CS является выражение if cond then x=y.

а потом сразу же

Отличается тем, что в первом случае это выражение, возвращающее результат. Т.е. если на JS мы можем написать:

x = test? a: b,

то на CS нужно писать:

x = if test then a else b.

if (cond) в js не возвращает результат. Видите противоречие между вашими же постами? Какой-то из них — ошибка ;)

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

@merlin-vrn 2 окт 2013 в 09:45

Я утверждал следующее: в js

if (cond) statement;

это абсолютно то же самое, что в cs

statement if(cond)

(заметьте, здесь нет никакого else)

Вы зачем-то начали меня поправлять, причём с ошибкой, т.к. if… then из cs нельзя буквально перевести на js — следовательно, это не одно и то же.

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

@merlin-vrn 2 окт 2013 в 10:27

У вас проблемы с логикой.

Утверждение

в js

if (cond) statement;

это абсолютно то же самое, что в cs

statement if(cond)

верно. В чём проблема? В том, что я не говорил про второй вариант? А обязан был? Я нигде не утверждал, что на cs или js это нельзя написать по-другому. Хотите ещё вариант на JS, который будет работать так же? Пожалуйста:
for (var i = 0; (i < 1) && cond; i++) statement;
(тут есть дополнительная переменная — можно это обойти, выбирая в цикле какое-нибудь до этого не использовавшееся имя, и удаляя его после использования — влом это писать, поверьте, возможно).
Что же, теперь и ваше утверждение «неполно».

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

@merlin-vrn 2 окт 2013 в 11:18

С какой стати я должен был про него упоминать? Утверждая «а эквивалентно б», я не обязан писать, что «также возможно написать похожее утверждение с». Я вообще-то для этого и не обязан знать, что существует вариант с. Когда я утверждаю, что а и б — одно и то же, для этого мне совершенно не требуется с.

Кстати, а вы знали, что for можно заменить if? А ещё его (if) можно написать чере while. Не только в js. И что-то я до сих пор ни разу не встречал документации, в которой об этом прямо писали бы в разделе об условных конструкциях, а особенно — сравнивая условные конструкции одного языка и другого. Все авторы этой документации неправы?

Давайте не передёргивать. Изначальное утверждение: то, что в js — if(cond) statement;, в cs — statement if(cond), и наоборот. Это верное и самодостаточное утверждение, не требующее обязательных дополнений, т.к. выполняется абсолютно всегда в корректных для обоих языков случаях. Именно это я утверждал. Ещё я утверждал, что это наоборот не эквивалентно тернарной операции, которую вы снова зачем-то приплетаете. У вас проблемы с различением разных конструкций языка что ли?

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

@merlin-vrn 2 окт 2013 в 11:47

Я не мог подобное утверждать.
Дайте ссылку на это утверждение, пожалуйста.

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

@merlin-vrn 2 окт 2013 в 11:59

Простите, у вас точно проблемы с логикой. Каким обраэом из этого следует, что

в CS условие иначе, чем «statement if(cond)» записать нельзя

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

@merlin-vrn 2 окт 2013 в 12:35

Теперь вы утверждаете, что кто-то не знающий CoffeeScript, прочитал, что кто-то был неприятно поражён некоей конструкцией CoffeScript, и на основании этого всерьёз предположил, что других конструкций там нет, и теперь будет основываться на этом предположении, не проверяя.

Самому не смешно?

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

@merlin-vrn 2 окт 2013 в 12:45

Нет. Я однако ни из чего не делал вывод, будто есть только конечная форма и никаких больше не бывает.
(Моё понимание о CS ограничивается статьёй о deferred и promise, которая была недавно на хабре, и собственно после этой статьи он мне неприятен.)

Я стесняюсь спросить, а какое это имеет отношение к утверждению о том, что trailing-форма — плохо? Даже если бы я сам знал язык, и никогда не её не использовал бы сам, мне неминуемо пришлось бы читать эту форму (и спотыкаться каждый раз об неё). Само по себе наличие такой форме в языке делает его хуже, неважно, есть там другие конструкции на эту тему или нет. Особенно, когда адепты её приводят в пример как очень хорошую и предпочтительную.

@homm 2 окт 2013 в 12:34

> будто в CS условие иначе, чем «statement if(cond)» записать нельзя.
Вы неправильно поняли. Никто из высказавшихся так не считает.

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

@merlin-vrn 2 окт 2013 в 12:48

Одной строки — нет. Десятка строк, из которых одна такая — да, вижу проблему.

@homm 2 окт 2013 в 13:52

Я видел проблему с восприятием строк, которые я видел. Например:

checkOptions = (options) ->
  throw new Error("invalid options") unless options.one
  for option in ['one', 'two']
    value = options[option]
    unless !value or value.match /^\d+x\d+$/i
      throw new Error("invalid options.#{option} ")

Чтение такой функции происходит примерно так: Так функция, принимает аргументы, бросает исключение. Wtf, как бросает исключение? Она вообще не работает? Ах да, долбаный unless.

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

@merlin-vrn 2 окт 2013 в 12:55

Хватит уже передёргивать, то, что я не знал что можно по-другому, не значит, что я думал, будто по-другому нельзя. И никто так не думал.

Давайте, строгая логика. Пока утверждение не доказано, оно не истина. К негативным утверждениям это тоже относится: пока не доказано, что некоторое утверждение неверно, оно не являешься ложным. Я не могу утверждать, что нечто невозможно, на том основании, что я не знал, что именно возможно, а что нет.

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

@VolCh 2 окт 2013 в 06:50

Никто вам ничего не навязывает

Пост как раз о том, что навязывают, лезут с CS туда, куда не просят.

@jj_killer 2 окт 2013 в 07:03

Кто навязывает? Какая-то корпорация, да?

@VolCh 2 окт 2013 в 07:23

Те, кто на нем пишет. Не все, но есть такие.

@homm 1 окт 2013 в 20:34

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

@jj_killer 1 окт 2013 в 20:39

Ну если учесть, что методы в руби редко превышают 30 строк все отлично видно.

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

@youlose 1 окт 2013 в 19:05

Perl

@khim 1 окт 2013 в 19:40

Ну Perl это вообще WORN язык, ему можно.

@youlose 2 окт 2013 в 05:38

Нет, он просто не стал копировать другие языки и выглядит непривычно, но при понимании его синтаксиса и наличии подсветки в IDE, язык очень понятен и удобен.

@JustStas 1 окт 2013 в 19:55

Perl поддерживает оба варианта.

do_something() if ($flag);

if ($flag) do_something();

@AleksDesker 1 окт 2013 в 20:06

Осталось только провести парсинг кода, написанного когда либо на Perl, сравнить частоту использования первого и второго варианта и мы узнаем судьбу CoffeeS (кто уже знает ответ чур не подсказывать!)

@bolk 2 окт 2013 в 03:25

Perl.

(отредактировано) два раза уже Перл назвали, оказывается.

@VolCh 2 окт 2013 в 06:43

Для меня вобще дико видеть в ЯП конструкцию вида: определение-условие (statement-condition). Для меня более логично выглядит условие-определение

Чем дико, чем логично? Цикл с постусловием вам тоже дик и нелогичен?

@merlin-vrn 2 окт 2013 в 06:52

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

А условное выражение в данном случае просто записано вперёд ногами, назад головой, но от этого оно не получило никакого нового логического наполнения. Условие — оно и в африке условие.

@VolCh 2 окт 2013 в 07:28

Так и это по определению отдельная самостоятельная конструкция, а не другая форма записи. По крайней мере в Ruby так.

А что вы скажете на условие типа A B = IF DO_SMTH THEN? :) Тоже дикое и не логичное? Нет, просто другая логика.

@merlin-vrn 2 окт 2013 в 07:41

Нет-нет, не отдельная конструкция. Т.е. да, в конкретном языке, если вы его пишете на бизоне или там antlr, это конечно оформляется как отдельная конструкция. В tcl вообще все конструкции такого вида — это вызов процедуры, т.е.
if {$q == 5} {
x
} else {
}
— это вызов процедуры «if» с аргументами "$q == 5" (сначала произойдёт подстановка переменной q), "\n x\n", «else» и "\n". Можно определить свою процедуру которую назвать «если» и использовать там «иначе» с такой же логикой, как у if, и писать всё по-русски: если {$q==5} { x } иначе { }. Можно определить и так, что ветка «true» будет идти после ветки «false» (как бы if… else… then ...). Постусловием определить нельзя, т.к. первой всегда идёт команда (имя процедуры).

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

@VolCh 2 окт 2013 в 07:47

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

Во-первых в «должно» логики нет. Код пишется для людей, а не для машины. Во-вторых, не удивлюсь если современные процессоры (может по подсказке компилятора, может сами) вычислят все три блока параллельно (если они не зависят друг от друга), а потом просто лишний выбросят и это будет реально быстрее.

@merlin-vrn 2 окт 2013 в 09:06

Не удержался и сделал:

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

#!/usr/bin/tclsh

proc если {args} {
    for {set i 0} {$i < [llength $args]} {set i [expr 1+$i]} {
        if {[string equal "иначе" [lindex $args $i]]} {
            set args [lreplace $args $i $i "else"]
        }
    }
    if {*}$args
}

proc послать {args} {
    puts {*}$args
}

если 0 {послать hi} иначе {послать lo}

Привет любителям 1С :)

@Mrrl 2 окт 2013 в 08:08

А что вы скажете на условие типа A B = IF DO_SMTH THEN?

Ну, оно уж точно выполняется ровно в том порядке, в каком написано. В отличие от прочих обсуждаемых конструкций.

@Mrrl 2 окт 2013 в 06:57

Цикл с постусловием вам тоже дик и нелогичен?

Если бы постусловие проверялось в начале выполнения цикла, то оно было бы нелогично. Но поскольку один раз тело цикла выполняется всегда, то почему бы его не написать до условия (которое находится ровно в той точке программы, в которой выполняется).
А вот третье выражение оператора for… тут можно и подумать, на месте ли оно.

@VolCh 2 окт 2013 в 07:30

Ну да, пример с for более удачно показывает, что не всегда то, что идет вначале обязательно выполняется.

@monolithed 3 окт 2013 в 19:48

На вскидку, таких выражения возможны в Perl, Python, Ruby, Haskell, F# и пр.

@homm 4 окт 2013 в 06:01

В Питоне точно нет. Читайте обсуждение выше.

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

@homm 4 окт 2013 в 08:33

Это другая конструкция. Читайте обсуждение выше.

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

@homm 4 окт 2013 в 10:19

> Ну и что, что другая.
То, что не о ней разговор.

> Конкретно эти инструкции в CS и питоне — эквивалентны.
И что. Не о ней речь.

> Я сейчас не говорю про trailing expression modifier!
Ну и кыш отсюда.

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

@merlin-vrn 4 окт 2013 в 10:26

Она менее кривая, чем в CS. Она не trailing expression. Читая её слева направо, как обычно, не пропустишь и не упустишь факт, что это — условие.

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

@merlin-vrn 4 окт 2013 в 10:32

А, вы про эту конструкцию. Я сразу не понял. Ну она появилась в обсуждении случайно, потому, что у одного из пропонентов CS нет понимания, чем условная конструкция отличается от тернарного оператора, я опять же не вижу, чего его тут обсуждать. Да, этот оператор везде одинаковый, за исключением того, что в половине языков он (expr)?v1:v2, а в другой половине — if expr (then) v1 else v2, более «словесный».

@grossws 4 окт 2013 в 12:22

А в python expr1 if cond else expr2. Не очень он одинаков получается…

Согласитесь, что это не то же, что if cond then expr1 else expr2, который и исполняется слева направо. А не из центра выражения, как в PEP-308.

@homm 4 окт 2013 в 10:46

> Т.е. вы уклоняетесь от ответа
От ответа на что? Вопрос заданный вами в рамках этой дискуссии не относится к этой дискуссии. Если у вас есть вопрос, относящийся к данной ветке, задайте его здесь. Если у вас есть вопрос, относящийся к топику, задайте его отдельным комментарием. Если ваш вопрос вообще не к чему не относится, но вам все равно интересно мое мнение, напишите личное сообщение, в конце концов. Я не хочу просто так разводить флейм.

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

@homm 4 окт 2013 в 12:16

Потому что это принципиально разные конструкции. Читайте выше.

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

@merlin-vrn 4 окт 2013 в 12:37

Плохо и то, и другое.

Условная конструкция чуть хуже, чем тернарный оператор, т.к. используется чаще.

@merlin-vrn 4 окт 2013 в 09:56

Кстати говоря, в этой конструкции в пайтоне всё на своём месте: сначала условие, потом реакция в зависимости от условия. Никаких trailing-условий.

Хотя конструкция так себе, да.

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

@merlin-vrn 4 окт 2013 в 10:29

Я уже тут писал про tcl — ну так в tcl процедура if тоже возвращает результат, правда, обычно, его никто не использует. Но написать что-то вроде set x [if {expr1} {...} {...}] всё равно можно. В пайтоне абсолютно так же.

Само по себе условное выражение здесь — в правильном порядке. То, что оно как оператор в целом может иметь результат — это вопрос другой. Но условие сначала, ветки потом. В естественном порядке. Если ты выучил уроки, можешь идти погулять.

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

@merlin-vrn 4 окт 2013 в 10:33

Да-да, верно, просто ветка так плавно перетекла в обсуждение этой конструкции, что я не сразу заметил.

@MuLLtiQ 4 окт 2013 в 11:19

x = 5 if cond else 3

Читается это так: «Икс присвоить 5 если cond иначе 3». Звучит более-менее естественно. После обыденного "?:" надо привыкнуть, конечно, но это не трудно.

@grossws 4 окт 2013 в 12:08

И какие после этого могут быть наезды на пост-условие?))

По PEP-308 понятно откуда оно берется (как замена cond and expr1 or expr2, но ломает привычный порядок вещей куда сильнее, чем пост-условие.

Всё-таки порядок вычисления «второй операнд, потом первый или третий» — это куда более пи#$ец, чем «второй операнд, потом первый, если это необходимо».

Вспоминается:

Спросите питониста, чем хорош питон, и он вам процитирует ихнюю философию программирования, называемую «The Zen of Python», а в частности:

Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Читаемость имеет значение.
Если реализацию сложно объяснить — идея плоха.

Именно по этому питонисты очень гордятся генераторами.

Например, для того, чтобы двумерный массив array = [[1, 2], [3, 4], [5,]] превратить в одномерный, питонисты пользуются вот таким простым кодом:
[element for subarray in array for element in subarray]
Не правда ли просто, не сложно, не запутанно, читаемо и легкообъясняемо?

А вот несчастные рубисты мучаются с:
array.inject &:+
или
array.flatten
А бедные хаскелисты вообще надрываются:
concat array

@homm 4 окт 2013 в 12:24

> Всё-таки порядок вычисления «второй операнд, потом первый или третий»
> — это куда более пи#$ец, чем «второй операнд, потом первый, если это необходимо».

В случае Питоньего тернарного оператора дело только в порядке вычисления. Да, я согласен что Кофевская конструкция в этом плане правильнее (можете так и записать, что я согласился, что что-то в кофе лучше чем в питоне). Но какое отношение все это имеет к постусловиям?

> превратить в одномерный, питонисты пользуются вот таким простым кодом:

Ну вы может быть таким пользуетсь, а вообще есть sum(array, []).

@grossws 4 окт 2013 в 13:05

В случае Питоньего тернарного оператора дело только в порядке вычисления.

А в случае пост-условия дело в чём, если не в порядке вычисления? Его недостатком называли именно запись операндов не в том порядке, как они вычисляются…

А про цитату — это была шутка, если что. Навеянная кому-то каким-то из туториалов по пайтону, где это было примером того, для чего нужны comprehensions (не знаю соответствующего русского термина).

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

@merlin-vrn 7 окт 2013 в 07:12

Да, это используется в художественных целях. Например, в песне The Beatles — Revoltion есть такой момент, где конец резко меняет смысл всей фразы на обратный.

Это художественные цели. Программирование — не художественные цели, здесь такие украшения неуместны.

@monolithed 4 окт 2013 в 08:27

Если синтаксис требует инструкции else, это не значит что таких выражения нет:

x = 1 if 1 else 2

@homm 4 окт 2013 в 08:32

Читайте обсуждение выше.

@unloved 2 окт 2013 в 11:50

ваш вброс очень удивляет рубистов

@vitvad 2 окт 2013 в 12:12

да уж, вброс удался, дебаты не на жизнь а насмерть :)

Holly war

ваш вброс очень удивляет рубистов

я могу так же сказать — наличие такой конструкции удивляет JS-разработчика (а еще возможно с/с++, php, python, java)

Выше сказали что в Perl есть такая конструкция, спорить не буду ибо языка не знаю… хотя я наслышан о преобразовании типов в Perl.

@unloved 2 окт 2013 в 12:23

он удивляет тем что в руби это стандартная практика

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

@VorontsovIE 1 окт 2013 в 18:33

Мне очень сложно представить человека, который умеет и понимает javascript, и даже способен поставить правильное количество скобочек в коде, но не способен за две минуты понять (не написать, всего лишь понять) питонообразный код. И да, лично мне на порядок труднее читать JS-код на том же Stackoverflow из-за обилия мусора и скобочек десятерной вложенности. Ну и выслушивать такие сентенции от JS-программистов, у которых смысл операторов и конвенции о приведении типов отличается от большинства других языков — по-меньшей мере странно. Как будто каждый обязан знать этот ваш джаваскрипт.
При этом, надо понимать, что у Coffeescript есть базовый синтаксис, который абсолютно тривиален: табуляция, хэши, обычные стрелочки, использование переменных без слова var. А есть всякие жирные стрелочки итп, которые компилируются в более сложный код. Если человек в коде использует подобные навороты — сам виноват, что его неправильно поймут.

@bolk 2 окт 2013 в 03:30

Ну да, каждый обязан знать этот наш JS. Отлаживать всё равно приходится JS.

@RUVATA 2 окт 2013 в 07:55

использование переменных без ключевого слова var

Как раз одно из «сахарных упрощений», ИМХО ненавистных мне явлений, этого диалекта.
В явном определении зоны видимости переменной (принадлежности к [[scope]] того или иного объекта/блока), кроется магия JavaScript, и ИМХО, особенно новичкам нельзя «лизать жопу» в таких опасных местах программирования в целом, в противном случае его код на архитектурном уровне рискует превратиться в шестиствольный пулемет который стреляет работающими газонокосилками исключительно по ногам :)
Эти упрощения не стоят тех допущений которые будут присутствовать в концептуальном знании технологии у кофеинщиков, я подчеркиваю — особенно неопытных / не знающих JavaScript как есть. (для них это нубопуть).
Т.к. изучая/используя язык, спотыкаясь через ключевое слово var (пусть оно надоедает, пуcть оно неудобное), програмист так или иначе будет вынужден изучить теоретическую часть, которая касается областей видимости переменных, и О ЧУДО! он открывает для себя «замыкания»… к нему приходит понимание [[scope]] и прозрение разбивает очки его неведения различного поведения this в объектах и конструкторах. и т.д.
Так он переходит на светлую сторону силы. :)
PS: Я все равно прошелся по мануалу, даже погородил несколько «хелоуворлдов», т.к. понял что от кофе мне ни куда не деться и у него есть и будет много поклонников, и его код так или иначе постоянно попадается на глаза, но лично я уже настолько свыкся с читым JS, что он со всеми своими скобочками и т.д. не вызывает у меня проблем, учитывая возможности современных IDE — он как «открытая книга.» Я все так встану в стан автора, может быть не так радикально, но мне тоже «кофе» не по душе.

@VorontsovIE 2 окт 2013 в 08:16

Слово var в JS, конечно, должно бы приучить к дисциплине. Но JS очень легко прощает подобную ошибку, новичок может даже не понять, что её сделал. Хотя посмотрев пару раз в скомпиленный исходник и посмотрев, как он выглядит, для него станет понятно, что писать это слово надо.
Кофе в таком случае делает как раз безопасные для внешнего мира умолчания, проставляя слово var. И это гут. Ну а вообще, JS — плохой язык для новичка. Работать с ним новичок научится быстро, а вот понять как оно работает и де расставлены капканы он не сможет.
А со stackoverflow вы предлагаете код копировать в IDE, чтобы мне скобочки раскрасили? ;)

@ikido 1 окт 2013 в 18:34

Главный плюс coffeescript -— его в разы проще поддерживать. Кто понимает — тихонько использует и получает +100 к продуктивности, у остальных баттхерт

@ivv 1 окт 2013 в 18:43

а еще нужно букву подправить — подправь, но скомпилируй. Как по мне это уже минус к продуктивности, хотя уверен, что адепты имеют что-то под рукой, что подхватывает изменения и компилит при правках.

@ikido 1 окт 2013 в 18:46

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

@ivv 1 окт 2013 в 18:49

главное что есть выбор, что водить. Мне нравится водить javascript, вам coffeescript — не водить же всем одно и тоже.

@printf 1 окт 2013 в 18:57

А первый же неочевидный баг (расхождение результата и ожиданий) при трансляции будет стоить 200 продуктивности — 100 бонусных, и еще столько же из бюджета проекта.

И хорошо, если это была домашняя страничка собачки знакомого хипстера, а не серьезный бизнес.

@ikido 1 окт 2013 в 19:29

Если у вас лапшекод и кривой workflow то да

@printf 1 окт 2013 в 19:33

Нет, что вы, у нас совершенно идеальный код, а программисты совсем не делают ошибок, вообще никогда.

@VorontsovIE 2 окт 2013 в 08:23

Вы говорите так, будто основная часть багов берется из трансляции… И будто в JS сложно поставить неочевидный баг. Это как ругать езду на велосипеде за то, что ноги могут о педали больно удариться, если неаккуратно ими болтать.

@RUVATA 2 окт 2013 в 08:01

по мне так для того чтобы было удобнее поддерживать лучше взглянуть в сторону инструментов для этого, чем писать на конвертируемом в интерпритируемый :) просто представьте на минутку, как «удобство разработки» коррелировало бы с «адом отладки» не будь у Вас source maps.

@grossws 2 окт 2013 в 11:46

Прекрасно отлаживается по сгенерированному js и без source maps. Все конструкции, в которые компилируется cs, описаны в документации. Никакого rocket science в них нет.

Совсем другое — отлаживать скомпилированный C без листингов…

@VolCh 2 окт 2013 в 11:49

То есть для отладки нужно знать два языка и помнить правила трансляции?

@grossws 2 окт 2013 в 12:16

В этом топике уже неоднократно говорили: для написания кода на CoffeeScript необходимо знать JavaScript.

А правила трансляции там элементарные. По сути, изучение CS сводится к пониманию этих правил.

@xel 1 окт 2013 в 18:42

CoffeeScript не бо́льший чёрный ящик чем LESS.
Бывают конечно действительно мощные однострочники, но большинство кода на coffee отлично транслируются в javascript в голове.

@Oreolek 2 окт 2013 в 02:27

LESS на выходе даёт читабельный валидный CSS для начала. В CoffeeScript есть логика, которую приходится разбирать.

@xel 2 окт 2013 в 05:43

coffeeScript на выходе тоже даёт читабельный валидный javascript.
И в LESS можно тупо следовать css-way, а можно экономить время используя переменные, примешивания, макросы.

toggle = (item) ->
    if (item.enabled == true)
        item.process();
        return item.state;
    else
        item.blink();
        return false;

Это полностью валидный coffeescript.
Да, coffee позволяет отбросить все эти скобочки, точки с запятой, return-ы, использовать алиасы для булевых значений, и автоматически разбираться с областью видимости переменных:

toggle = (item) ->
    if item.enabled == on
        item.process()
        item.state
    else
        item.blink()
        false

Но разве при этом меняется логика? Максимум — синтаксис. Запомнить что вместо this. можно писать @, что return-ы необязательны, а вместо лестницы скобочек — у нас лестница отступов.

@VolCh 2 окт 2013 в 06:56

Вот первая строка ни разу не понятна. Условие тоже не очень: on — это переменная или литерал? А может конструкция языка?

@homm 2 окт 2013 в 08:11

Первая строчка читается так: toggle — это (равно) стрелочка (т.е. функция), принимающая item.

@VolCh 2 окт 2013 в 09:05

То есть

 toggle = function(item) {
 //...
 }

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

@agentx001 2 окт 2013 в 12:16

Скомпилированный вариант

UPD: Почему у меня тег code всегда выдает какую то неведомую херь?

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

@merlin-vrn 2 окт 2013 в 12:37

тег «code» называется неудачно :) он имеет смысл «не добавляй br на месте моих переводов строк», т.е. «я сам написал весь код, не меняй тут ничего».

@bubuq 3 окт 2013 в 07:48

Единственная осмысленная жалоба на кофи, это невозможность задания поименованной функции:

toggle = function myToggle(item) { ... }

На кофи этого написать нельзя.

@MuLLtiQ 3 окт 2013 в 08:06

Вообще не понимаю зачем это нужно. Единственное, для чего это может пригодится — рекурсивный вызов, и то выглядит слишком «сахарно» и излишне. Не припомню ни одного языка где такое есть и чтобы кто-нибудь переживал по поводу отсутствия.

@bubuq 3 окт 2013 в 08:30

Это не единственное. Стек-трейс выводится нагляднее с поименованными функциями, и вполне переживали, как раз по поводу кофи, даже баг открывали.

@MuLLtiQ 3 окт 2013 в 12:30

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

Например

var f2 = function(arg) {
  var f1 = function(arg) {
    if (arg <= 3) {
      throw new Error('Fail');
    }
  };
  f1(arg - 3);
};

f2(5);

> node test.js

/home/user/test.js:4
      throw new Error('Fail');
            ^
Error: Fail
    at f1 (/home/user/test.js:4:13)
    at f2 (/home/user/test.js:7:3)
    at Object.<anonymous> (/home/user/test.js:10:1)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:901:3

@RUVATA 2 окт 2013 в 08:03

лестница скобочек, лестница отступов… неужели есть принципиальная разница?

@VolCh 2 окт 2013 в 09:07

Есть, если привык, что пробелы, табы, переводы строк и т. п. редуцируются до одного «пробельного символа» везде кроме литералов.

@svyatogor 1 окт 2013 в 18:42

Совет автору — потратить максимум 2-3 часа своего времени и разобраться как работает coffeescript! Это несложно, правда. Это всего лишь синтактический сахар к JS, с кучей удобных шорткатов. По сути там нет никакой магии, тот же JS. почти все мапится один в один к js и дебаг не вызывает никаких сложностей

@AleksDesker 1 окт 2013 в 18:49

2-3 часа ничего вам не скажут, о том, с чем вы столкнетесь, если начнете писать фронтенд серьезного проекта на кофе, вопрос не в синтаксисе. Тут год может уйти, до полного понимая, вопрос в том это не понимаете только вы или разработчики кофе тоже, без дискуссии никак.

@VolCh 2 окт 2013 в 06:58

То есть знать нужно два языка? Плюс, если писать на CS, то заморачиваться с компиляцией? И «почти всё» тоже как-то оптимизма не вселяет.

@printf 1 окт 2013 в 19:23

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

Вот этот комментарий выше в треде отлично иллюстрирует статью:

Совет автору — потратить максимум 2-3 часа своего времени и разобраться как работает coffeescript!

Картина художника Алексея Саврасова «Грачи приехали». Совет комментатору — потратить 2-3 часа своего времени и начать юзать VIM mode в Emacs в Haiku OS, писать на ClojureScript и ходить на лыжах по потолку. Компилируемых в JS языков штук двести, не меньше — кто-то правда всерьез считает, что на каждый стоит потратить 2-3 часа?

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

@kambei 1 окт 2013 в 21:57

ну как бы… если что-то критиковать, то да, стоило бы потратить время чтобы разобраться в предмете

@xkesha 2 окт 2013 в 12:09

предмет поста на мой взгляд не сам CS, а назойливость при подаче материалов по этому языку

@MuLLtiQ 2 окт 2013 в 06:48

> есть действительно классные осмысленные вещи, например Kal
Язык и его идея, кстати, действительно очень хороши.
Но с названием у них как-то промах вышел, конечно :)

@anmi 2 окт 2013 в 08:38

Компилируемых в JS языков штук двести

А CoffeeScript всего на 13 месте по популярности на github. При том что зная JS, Python и Ruby изучение CoffeeScript'а займёт минут 15.

@zayko 1 окт 2013 в 19:37

Меня учили, что программист не должен быть машинисткой.

Как заставить себя изучить CoffeeScript

@Dmitry_f 1 окт 2013 в 19:38

Наконец-то сообщество прозрело.

@Fedcomp 1 окт 2013 в 20:41

Source maps?

@xkesha 1 окт 2013 в 20:48

Солидарен с автором поста,

Недавно был пост о JQuery (про promise и deffered кажеться). Текст того поста ввел в уныние с первого примера на CofeScript…

Помнится, тогда сразу вспомнил про Чука и Гека анекдот (примерный смысл: «себе <дальше не произноситься>»)

Ну и конечно хотел предложить автору поста улучшить статью — для легкости восприятия темы дополнить примерами на языках lisp, С++, добавить пример EJB 1.1 и парочку на ассемблере…

А всем кто против натыкать ссылок на пособия типа «Ассемблер и EJB за 10 часов»

@xkesha 1 окт 2013 в 21:02

P.S. нашел тот волшебный пост habrahabr.ru/post/193598/
заголовок «Ещё раз о Deferred/Promise»
и теги под заголовком «jQuery», «Программирование», «JavaScript»…

@Regis 2 окт 2013 в 01:05

Прекрасная иллюстрация к этому посту!

@Mithgol 2 окт 2013 в 06:48

Анекдот вон тот, как я понимаю.

@xkesha 2 окт 2013 в 11:57

ну да, как-то сам всплыл в памяти при прочтении…

@Zelgadis 1 окт 2013 в 21:01

Пост не читай @ сразу отвечай:

asm.js не предназначен для чтение людьми. Итого мы получаем, что автор ничего не понимает в том как работает JIT и как работает профайлер в любом браузере.

Да и не понятный момент для человека который не знает кофе только один — "-> vs =>" ну и может @.

@homm 1 окт 2013 в 21:16

Мне еще вот что нравится: чтобы функция возвращала результат, не надо писать return. А чтобы не возвращала, надо.

@evindor 1 окт 2013 в 23:01

В CoffeeScript функция возвращает последнее выражение. Если вам не нужно ничего возвращать из функции, то последней строчкой вы можете написать undefined, использовать return не обязательно.

@homm 1 окт 2013 в 23:07

В updefined больше букв.

@evindor 1 окт 2013 в 23:10

Я к тому, что это документированная особенность языка, и конфуза после прочтения документации по CoffeeScript она вызывать не должна.

@VolCh 2 окт 2013 в 07:00

Сразу после прочтения — может быть. А через месяц, два, год?

@evindor 1 окт 2013 в 23:13

Не обращаясь к вам конкретно — в документации к CoffeeScript есть множество примеров трансляции в JavaScript.

Мне кажется, что ноющие насчет чёрных ящиков, отсутствия контроля и всего в таком духе либо не читали документацию, либо плохо разбираются в самом JavaScript, чтобы с достаточной уверенностью понимать, во что транслируется их CoffeeScript код.

@VolCh 2 окт 2013 в 07:03

Основная проблема в посте не в том, во что транслируется свой код, а что подсовывается чужой транслируемый там, где ожидаешь увидеть нетранслируемый.

@meettya 2 окт 2013 в 10:43

лучше null

@xkesha 1 окт 2013 в 21:24

Не понятный момент для человека, который не знает кофе только один (другой) — он не знает ни синтаксиса языка ни семантики.
Речь лишь о том, что не правильно подсовывать примеры на кофе аудитории со знаниями JavaScript и JQuery. Не тратьте мое время приемами бульварной прессы. Поймите, я не знаю кофе и изучение этого языка не входит в список приоритетных для меня задач.

@Zelgadis 1 окт 2013 в 22:49

Лично мне потребовалось 20 минут на изучение CS. Я конечно знал javascript. Я считаю, что проблема с чтение CS может возникнуть только у того, кто пишет на jQuery (а не javascript).

@xkesha 1 окт 2013 в 23:36

>Лично мне потребовалось 20 минут на изучение CS. Я конечно знал javascript.
Поверьте, искренне рад за вас. Если ожидаете что брошусь изучать CS — увы.

> считаю, что проблема с чтение CS может возникнуть только у того, кто пишет на jQuery
Тем более повторюсь: не надо подсовывать CS под видом изучения JS и JQuery, обратите Ваше внимание в этой просьбе и проявляется солидарность с постом автора.

@Zelgadis 2 окт 2013 в 00:26

> Поверьте, искренне рад за вас. Если ожидаете что брошусь изучать CS — увы.

Мне от вас ничего не надо. Мне конечно хотелось бы, что cs-ненавистиники перестали навязывать свое мнение. У нас в компании все на CS пишут, наш код за пределы компании не попадает. Если же это публичная библиотека на CS написана то какое вам дело до этого? Автор захотел так и у вас есть только 2 варианта: закрыть рот и писать на CS или дальше пуская пену не писать.

> Тем более повторюсь: не надо подсовывать CS под видом изучения JS и JQuery, обратите Ваше внимание в этой просьбе и проявляется солидарность с постом автора.

Конечно не надо. На CS должны писать только те кто знает JS. Оригинальный автор же уже показал свою непрофесинональность и неадеватность. О солидарность не может быть и речи.

@xkesha 2 окт 2013 в 02:13

Уважаемый участник, к CS отношусь с нейтралитетом так как незнаком с предметом и пену не пускаю изо рта (вы переборщили).

Повторяю, мной было указано, что действительно вопросы связанные с CS зачастую подсовывают читателю под тематикой JS и JQuery (в этом и демонстрируется солидарность с разделом поста).

У меня сложилось впечатление что вы поклонник CS. Поймите я сказал не о продукте CS а о случаях неправильной подачи CS в статьях в сети (и как правило o подаче CS другими поклонниками). В частности мне пришлось тратить время на отсеивание CS в статье якобы по JS и JQuery. Согласитесь, некорректная информация раздражает.

Если захотите ответить мне- пожалуйста по существу моего замечания (на мыло же приходит).

@Zelgadis 2 окт 2013 в 02:26

Я не про вас говорил о пене.

Я тоже против использования CS в ответе для вопроса о JS. А вот: " В частности мне пришлось тратить время на отсеивание CS в статье якобы по JS и JQuery." уже перебор. Если автор решил использовать CS в своей статье это его право.

@xkesha 2 окт 2013 в 02:32

Не согласен (мое право)

@VolCh 2 окт 2013 в 07:06

Если автор решил использовать CS в своей статье это его право.

Да пускай хоть Брэйнфак использует, вот только зачем статью называть как имеющую отношение к JS?

@VolCh 2 окт 2013 в 07:04

На CS должны писать только те кто знает JS.

Звучит как «На Си должен писать только те, кто знает Ассемблер» :)

@Zelgadis 2 окт 2013 в 07:10

Какое нелепое сравнение. Впрочем достаточно было прочитать чей это комментарий, а дальше и так понятно.

@VolCh 2 окт 2013 в 07:32

Чем оно нелепое?

@Zelgadis 2 окт 2013 в 08:27

Раз, кофе всегда одинаково транслируется (очень важное словно) в джаваскрипт. Си же компилируется по-разному и зависит от это от компилятор и уровня оптимизации. Два, кофе это 1 к 1 маппинг в js. Три, ассемблер это не язык.

Подробнее про номер 2: вы же знаете, что есть архитектуры отличные от x86? Знаете почему си появился, да? Улавливаете или надо продолжить?

@VolCh 2 окт 2013 в 09:14

Раз, кофе всегда одинаково транслируется (очень важное словно) в джаваскрипт.

Всегда-всегда? Разные версии компилятора, разные компиляторы для CS ещё не норма?

Си же компилируется по-разному и зависит от это от компилятор и уровня оптимизации.

Когда-то компилировался в Ассемблер 1 к 1, когда был единственный компилятор.

Три, ассемблер это не язык.

O_o

Улавливаете или надо продолжить?

А слова «аналогия», «метафора» вам знакомы?

@Zelgadis 2 окт 2013 в 18:23

> Всегда-всегда? Разные версии компилятора, разные компиляторы для CS ещё не норма?

Нет. Есть конечно IcedCoffeeScript и LiveScript, но они не называют себя CoffeeScriot.

> Когда-то компилировался в Ассемблер 1 к 1, когда был единственный компилятор.

Да ладно? Даже уровень оптимизации не влиял?

> O_o

Что? Для вас сюрприз, что язык который собирается ассемблером другом? Подсказку — посмотрите перевод слова assembler.

> А слова «аналогия», «метафора» вам знакомы?

Мои любиые слова, но тут кривая аналогия.

Поймите, CS ничего нового в JS не приносит. Это только сахар. Это не ObjC и C и уж точно не C и язык ассеблера.

@VolCh 2 окт 2013 в 18:34

Да ладно? Даже уровень оптимизации не влиял?

А он был в первом компиляторе, который Ритчи и Томсон написали?

Что? Для вас сюрприз, что язык который собирается ассемблером другом? Подсказку — посмотрите перевод слова assembler.

Ассемблером собирается код написанный на определенном языке ассемблера. :)

Поймите, CS ничего нового в JS не приносит. Это только сахар.

А что нового принес Си к ассемблеру? Стали доступны какие-то новые фичи процессора, которые из ассемблера недоступны?

@Zelgadis 2 окт 2013 в 23:38

> А он был в первом компиляторе, который Ритчи и Томсон написали?

А мы сейчас в то время живем? Нет. Значит какое нам дело до того компилятора? Или мы уже считает, что Си не нужен?

> Ассемблером собирается код написанный на определенном языке ассемблера. :)

Собственно это я и хотел написать, но почему-то пропустил часть предложения.

> А что нового принес Си к ассемблеру? Стали доступны какие-то новые фичи процессора, которые из ассемблера недоступны?

Зачем в такие крайности бросаться? Тогда давайте и язык ассемблера называть сахаром.

@VolCh 3 окт 2013 в 05:22

А мы сейчас в то время живем? Нет. Значит какое нам дело до того компилятора? Или мы уже считает, что Си не нужен?

Язык-то уже был, значит мы можем его учитывать в аналогии. Если хотите, то можно уточнить мои слова фразой «когда был единственный компилятор Си в коды процессора PDP» :) И кто говорит, что не нужен? Лезть с ним куда не просят не нужно :)

Зачем в такие крайности бросаться? Тогда давайте и язык ассемблера называть сахаром.

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

@Mrrl 3 окт 2013 в 08:50

Стали доступны какие-то новые фичи процессора, которые из ассемблера недоступны?

Ну, разумеется. Например, malloc. Кто в здравом уме будет писать такое в ассемблерных проектах? А на C — пожалуйста, сразу из коробки.
И не говорите, что malloc выполняется не процессором. Просто это очень сложное заклинание :)

@VolCh 3 окт 2013 в 09:05

:) Не будет, наверное, но она доступна.

@Mrrl 3 окт 2013 в 09:16

Ну, мы-то уже должны понимать, что есть, например, вещи, на которые никогда не хватит времени. И они являются невыполнимыми, хотя физически их выполнению ничего не препятствует. С «доступностью» malloc примерно то же самое. А кроме того, его наличие определяет распределение всего адресного пространства, что для ассемблерного проекта часто будет неприемлемым (памяти много, а трогать не моги — только через malloc. А то, что тебе нужно выравнивание по 2^16 байта — твои проблемы).

@Mrrl 3 окт 2013 в 09:20

Впрочем, думаю, что многие из тех, кто начинал в 80-х, написали хотя бы один malloc на хотя бы одном ассемблере.

@VolCh 3 окт 2013 в 09:20

И даже в 90-х :)

@RUVATA 2 окт 2013 в 08:07

Вам кажется ложным данное утверждение?
Писать на C (Не на С++ или Objective С) не зная асьму даже поверхностно — это смертеподобно и результат такой писанины — УГ.
Вставки жешь в нем, везде…

@Mrrl 2 окт 2013 в 08:10

Сейчас, пожалуй, уже нет. Те, кто должен писать на Си, скорее всего, и с ассемблером знакомы (в какой-то мере). Остальные выбирают другие языки.

@VolCh 2 окт 2013 в 09:15

Не кажется. Сам долго писал на Си не зная ASM 8086. И вставки не использовал.

@Mrrl 2 окт 2013 в 09:29

А были ли тогда разумные альтернативы? Хотя бы С++?

@VolCh 2 окт 2013 в 09:59

Если и были, то все равно выбирал не я. Меня перед фактом поставили — используем TurboC.

@AleksDesker 2 окт 2013 в 01:02

StackOverflow это не место для философских обсуждений, когда нужно лишь уловить общую идею. Часто оттуда вообще напрямую копипастится готовый кусок и допиливается под свои нужды, в подобных ситуациях CS бесполезен и действительно только загрязняет ответ.

@AterCattus 2 окт 2013 в 09:53

Мне вот еще ничего не говорят сходу строчки вида (python и js синтаксис мне понятен):

action = (token, i) ->
      @tokens.splice i, 0, @generate 'CALL_END', ')', token[2]

или

break for [tag], i in @tokens when tag isnt 'TERMINATOR'
@tokens.splice 0, i if i

Еще очень легко с отступами не заметить вместо

doSomething (->
'hello'), 1

какой-нибудь

doSomething (->
 'hello'), 1

и получить совсем не то, что ожидалось.

Примеры взял отсюда. Там еще много интересного.

@amarao 1 окт 2013 в 21:24

Опыт общения с людьми, которые используют coffee меня привёл к простой мысли: его используют те, кто пламенно ненавидит JS и видеть его не хочет, и только суровая правда жизни заставляет их хоть как-то прикасаться к фронт-энду.

Это ситуация совершенно ненормальная, и вызвана она дефицитом фронт-эндщиков. Если бы на рынке было поспокойнее, то каждый бы занимался тем, что любит, и не изобретались бы прослойки в стиле «будем писать на чём угодно, кроме JS».

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

@VolCh 2 окт 2013 в 07:07

и вызвана она дефицитом фронт-эндщиков.

Не только. Иногда ещё дефицитом бюджета.

@RUVATA 2 окт 2013 в 08:13

Оу… спешу Вас обрадовать не только к фронт-энду. Node.JS жешь, на кофе фигачат не покладая рук, учитывая что много «умных дядек», в том числе и не далеких от сохи самой ноды, яростно призывают использовать только чистый JS.

@evindor 1 окт 2013 в 23:08

Использую как CoffeeScript, так и JavaScript, делая выбор в пользу первого на новых проектах.

Аргументы про синтаксис, позволяющий написать ахинею, абсолютно беспочвенны. Ахинею можно написать на любом ЯП, для борьбы с этим существуют соглашения и style guide'ы. Русский, английский style guide по CoffeeScript.

Когда пару лет назад я впервые столкнулся с CoffeeScript на изучение его у меня ушло не больше пары часов. Не понимаю, где там чёрный ящик.

@VolCh 2 окт 2013 в 07:08

Раз пару часов нужно разбираться, то всё же чёрный ящик :) Был бы ящик прозрачный, то и минуты бы не потребовалось :)

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

@evindor 1 окт 2013 в 23:15

При этом у CoffeeScript сообщества совершенно другое отношение.
Многие библиотеки, написанные на CoffeeScript имеют так же документацию и на JavaScript, их авторы без проблем обсуждают в issues на гитхабе код на JavaScript и отвечают на вопросы в стиле «а я вот использую вашу библиотеку с JavaScript, суть моей проблемы такова...»

@evindor 1 окт 2013 в 23:22

Подкреплю свои слова ссылками:

Spine.js, язык документации выбирается справа сверху;
Chaplin.js, переключалка слева

@VolCh 2 окт 2013 в 07:12

Это их выбор, их право. Ну и если документацию на JS предоставляют, то наверное и библиотеку свою на JS предоставляют или хотя бы инструкции как её скомпилировать. Да и вообще предполагается, что JS знают.

@Bright 2 окт 2013 в 03:51

Интересен ещё такой момент — почему-то всем, кто начинает изобретать собственный диалект языка, в первую очередь в голову приходит мысль выкинуть скобки.

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

ИМХО, «экономия времени на скобках» — это задача IDE и не надо изобретать никаких новых языков, из которых «выкинули всё лишнее».

Читабельность и предельная определённость кода важнее скорости его набора.

@jj_killer 2 окт 2013 в 03:55

Далеко не все, и зачастую это имеет под собой основания в виде наличия/отсутствия скобок в языке который был основным у автора до этого. Если вам нравятся скобки, пожалуйста, ClojureScript для вас.

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

@norlin 2 окт 2013 в 05:39

Браво! Очень точно выражает мои мысли насчёт CoffeeScript.

@yul 2 окт 2013 в 06:01

Jade, например, выдаёт чистый HTML, который просто использует CSS-селекторы, с помощью синтаксиса, близкого к тому, что мы знаем как Zen Coding.

У автора, конечно, есть право на собственное мнение, но тут явное передергивание. Фактически, Jade также относится к HTML, как CoffeeScript к JS. Разумеется, с поправкой на отличия языка программирования от языка разметки. Пример автора очень простой и 1-в-1 переходит в HTML, но ведь в Jade есть и циклы, и итераторы, и разного рода сокращенные записи. Кто угодно, при желании, может наварганить такого, с чем человеку, знающему только HTML, придется разбираться с мануалом.
Ну еще и заголовок в стиле «я решаю за всех».

@merlin-vrn 2 окт 2013 в 06:11

Но ведь никому не приходит в голову на вопрос о html отвечать кодом на jade?

@Seldon 2 окт 2013 в 06:41

я вот лично не видел где отвечают кодом на кофе по вопросу на JS

@VolCh 2 окт 2013 в 07:14

Даже не Хабре встречается, типа «на CS это пишется так, думаю разберетесь как на JS переписать».

@anmi 2 окт 2013 в 07:45

Я часто отвечаю кодом на haml/slim на вопросы по html. Лень мне эти теги набирать.
И я лично считаю крайне невежественным упрекать меня в подобных действиях.
Тоже самое с кофе. Не понимаешь что написано — скопируй код на сайт кофескрипта и в онлайн компиляторе получи что тебе нужно.

@VolCh 2 окт 2013 в 07:52

Если вы дополняете свой ответ ссылками на онлайн-компиляторы, то ещё куда ни шло. А если даже не удосужились сообщить что это другой язык, то это будет выглядить как на вопрос по асму привести код на Си, даже не сообщив, что это Си.

@yul 2 окт 2013 в 08:37

Это, конечно же, повод для масштабных боевых действий в интернете. Zadolba.li у них нету?

@Yan_Alex 2 окт 2013 в 06:31

Да, кофе скрипт, возможно хорошо, многие знакомые пищат, удобно мол, но я например полноценно этот код уже не смогу эксплуатировать, поддерживать да и возможно пойму не сразу — а время у нас это деньги. Часто использую жквайри, и тут мне придется изучить новый синтаксис, ведь он так же затрагивает и его. Хотя нативный JS остается достаточно гибким языком, а если еще не забывать о дополнительных функциях для работы с массивами(объектами), которые есть в Жквайри (а Жквайри сейчас подключен, если не к каждому первому, то наверно второму точно проекту) и остальных плюшках, то это просто сказка. Говоря проще, я еще ни разу не испытал острой необходимости в том, чтобы JS был «удобнее», собственно зачем тогда плодить сущности без необходимости?

@Yan_Alex 2 окт 2013 в 06:36

Не успел дописать:

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

@Seldon 2 окт 2013 в 06:40

К автору пришла белочка, или ушла (ему виднее).

По теме — бред. Я не пишу на CS, однаком никогда не сталкивался с подобной проблемой. Мне никто не отвечал на воппрос по JS кодом на CS. Я никогда не видел пробелмы в проектах, так как если команда принимает решение писать на кофе, то пишут все, и у них ВСЕ ХОРОШО!.. Никогда не видел ситуации чтобы одна часть команды писала на кофе, а другая на js (причем не понятно как они синхронизируют изменения).

ASM.js создан не для ручкого набирания текста, я не знаю что вы там смотрите не понимая области применения.

Вы когда последний раз писали программу на чистом ассемблере? все пончему-то лучше напишут на С или С++ и никто не против и ереси не несет. Вы скажите что C, C++ однозначно переходят в asm, который потом можно редактировать самому. Да как бы не так! Посмотрите ассмблер выдаваемый современными компиляторами, там столько оптимизаций и ухищрений, что вы не один час будите разбирать его, потому как он ни разу не поход на рукописный.

Я с таким же успехом как и вы могу сказать что node.js бред сивой кобылы, зачем js на сервере, что он там упрощает? Есть прекрасные языки java, c#, python которые чувствует себя на сервере родными. И судя по вашей точки зрения я прав. Ибо помоему серверный js пихают щас куда не поподя, «МОДНО ЖЕ, ЧЁ», не надо писать хороший код, надо писать «модный». Tessel мне одному идея кажется бредовой?

А еще фейсбук компилит php в С, но си кодеры не жалуются и не лезут править откомпилированный С. А еще люди пишут на Scala, но почему-то проблем у java кодеров не возникает.

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

@VolCh 2 окт 2013 в 07:34

А еще фейсбук компилит php в С, но си кодеры не жалуются и не лезут править откомпилированный С.

Но и Си-кодеры на вопросы по PHP кодом на Си (почти) не отвечают. Как и люди пишушщие на Scala, наверное, не отвечают Scala-кодом на вопросы по Java.

@Seldon 2 окт 2013 в 14:51

Я наверное щее раз повторю, таких проблем никогда ни где не видел. Может вы не там и не так вопрос задаете?

@VolCh 2 окт 2013 в 14:53

Я не задаю, но они попадаются на глаза.

@UnknownHero 2 окт 2013 в 07:16

«За то время которое вы потратили на прочтение всех комментариев, можно было выучить Coffee Script и тем самым повысить свою востребованность на рынке» — Ваша Совесть

«Но я буду и дальше читать комментарии и бесполезные статьи» — Ваша Лень

@VolCh 2 окт 2013 в 07:38

Не «выучить», а «прочитать доки».

@UnknownHero 2 окт 2013 в 09:38

Мой мир никогда не станет прежним, спасибо

@Mrrl 2 окт 2013 в 09:48

А когда-нибудь случалось так, что он становился прежним?

@UnknownHero 2 окт 2013 в 12:50

Иногда мой сборщик мусора возвращает меня в прежние состояния.

Я думаю, можно больше не продолжать комментировать мои иронии.

@Keenest 2 окт 2013 в 11:06

Ну на счёт востребованности всё же не соглашусь: выбирая из двух кандидатов, я бы отдал предпочтение более «сильному» javascript-программисту, которого можно легко научить coffee script'у, нежели более «слабому», но знающему CS.

@UnknownHero 2 окт 2013 в 13:06

Слабых сжечь, остальным кофе.

Речь идёт о том, что много проектов уже используют CS. Его изучение не такое уж и длительное. По времени примерно как прочтение поста, его осмысление и прочтение последующих комментов. Конечно я соврал, для нормального владения CS'ом нужно больше времени, но понять основной смысл и вести осмысленные диалоги о проекте можно научится,

Ещё раз, знание языка повысить спрос для имеющихся проектов на CS. Учитывая, что проектов в мире не бесконечно, то это плюс.
Для новых проектов всегда хорош тот язык, которым лучше владеет программист/команда.

Лично для меня, CS действительно желательно использовать только с Ruby.

@AleksDesker 2 окт 2013 в 12:58

Когда я заходил в этот пост у меня была мысль, а не попробовать ли CS на каком-нить мелком сайтике. В посте я не увидел комментов в стиле: «Смотрите посоны, как тут удобно делать то-то и то-то, давно так делаю и никакой попоболи», зато увидел кучу «Вы тупые ленивые болваны»… не убедительно, господа.

@UnknownHero 2 окт 2013 в 13:56

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

@AleksDesker 2 окт 2013 в 16:59

Критика моя в том, что мне не нужна строчка Coffee Script в резюме, я выдаю конечный продукт «под ключ» и не слишком-то посвящаю клиентов в подобные детали. Смысла изучать то, что никогда не будешь использовать не много. Я думаю я не один такой, кому не только шашечки, но и ехать. Так что хотелось бы побольше о том, может ли оно ездить и поменьше про шашечки.

@VolCh 2 окт 2013 в 18:27

я выдаю конечный продукт «под ключ»

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

@Seldon 2 окт 2013 в 14:50

Простите я совершенно не вижу связи между «повысить свою востребованность на рынке» и «выучить Coffee Script»

@dbelka 2 окт 2013 в 08:12

Основной посыл правильный.
Грамотные проекты, любящие CS, выкладывают примеры на JS и на CS.
Конечно, есть куча людей, которым CS тупо не нравится, и заставлять им пользоваться просто неправильно.

Но вот лично мой опыт с CS:
Я потратил ОДИН(!) вечер на изучение coffee. Он на столько прост, что нужно быть очень ленивым, чтобы не открыть один раз доку и не посмотреть синтаксис. Это даже не язык для меня… пишу на CS, подразумевая JS, так что это никакой не «чёрный ящик»… это просто сахар для JS.

@VolCh 2 окт 2013 в 09:18

Ну я тоже изучил синтаксис CS, когда он мне встретился. Через месяц ещё раз. Через полгода ещё раз.

@Weageoo 2 окт 2013 в 09:11

Как по мне, TypeScript выглядит лаконичнее чистого JavaScript или этого вашего CoffeeScript ~~особенно для людей с ООП головного мозга вроде меня~~. А в некоторых местах лаконичнее самого ~~богоподобного~~ C#, напр., ключевое слово constructor — почему нет такого в шарпах, почему мне постоянно надо писать имя класса?

@lalaki 2 окт 2013 в 10:34

человеку с ООП головного мозга не приходится постоянно писать имя класса — он использует фабрики и DI-контейнеры ;)

@Weageoo 2 окт 2013 в 13:04

Ви хотите сказать, что DI-контейнеры избавляют от необходимости постоянно писать классы? Отнюдь, они предназначены для уменьшения связности, а количество классов (и интерфейсов) от этого вряд ли уменьшается. В любом случае реализует интерфейс какой-то конкретный класс.

@lalaki 2 окт 2013 в 10:29

(пишу на CS 2 года — плотно и фронтенд и бэкенд, и с его минусами периодически сталкиваюсь)

По самой теме:
отвечать на CS в тему по JS — имхо действительно невежливо: хочешь помочь — не навреди и не пихай везде «свой путь»; вместо посылания к онлайн-компилятору можешь сам им воспользоваться и выложить в результате JS; судя по теме же, такая пропаганда работает только «в минус», без нужды и не вовремя напрягая JS-программистов

По «JS vs CS»:

а если представить, что сначала был CS, а потом кто-то придумал JS, чтобы устранить недостатки первого — как бы звучало описание преимуществ JS? Кто-то из сторонников JS может такое описание придумать? Насколько оно будет серьезно звучать?
У меня все выглядит смешно, но я-то — сторонник CS:

«function(args)» вместо "(args) ->" — пусть длиннее, зато поймешь, что это функция, даже если в какой-то момент забудешь; смысл "->" трудно запомнить м легко забыть, и приходится лазить в документацию
"{}" четко разделяют блоки и однозначно понятны, даже если вы используете отступ в один символ или пишете в Notepad или Evernote вместо IDE; кроме того, теперь можно с упоением спорить о стиле скобок
и гвоздь программы — слабое сравнение: "==" позволит начинающим разработчикам примерно сравнивать значения, чтобы подкинуть старшим коллегам задачку — действительно ли вы хотели сравнить с приведением типов, или забыли написать "===" (а заодно поможет им заучить табличку приведения — ее должен держать в голове каждый мастер)

@merlin-vrn 2 окт 2013 в 10:33

главный плюс js по сравнению с cs — это c-подобный синтаксис. Сейчас вам возможно непонятно, почему это плюс, но вот если бы оба языка одновременно появились тогда, когда появился js, он бы и победил — этот плюс был сильнее, чем два плюса в c++ :)

@lalaki 2 окт 2013 в 10:50

так я и прошу привести аргумент, показывающий, в какой ситуации этот плюс проявляется _при переходе с CS на JS_: например, «вы как программист на C/C++/PHP/C# скучаете без скобок, function и т.п. в Coffeescript? в Javascript все это возвращается — теперь вы сможете гораздо больше печатать, особенно при рефакторинге, и со стороны будете выглядеть куда серьезнее».

Потому что понятно, что привычки для некоторых имеют значение, и CS кто-то может считать плохим только из-за _отличного_ синтаксиса, но это не объективно, и стоит представить, что было бы, если бы привычка не имела значения. А она в данном случае действительно не имеет, поскольку принципиально ничего не отличается

«Сейчас вам, возможно, непонятно», почему привычка не имеет значения, но если сравнить, насколько синтаксис C/C++ отличался Pascal, тем более, от BASIC и тем более, от asm, но люди все равно на него/с него переходили, станет очевидно, что в случае JS/CS все еще проще.

@merlin-vrn 2 окт 2013 в 11:08

Честно, я не готов гадать по поводу «бы cs появился раньше». Если бы они появились одновременно, победил бы C-подобный вариант. Собственно, он и победил: где-то сейчас VBScript?

JS появился в тот период, когда C, C++, а особенно — Java были главными в индустрии. Всякие паскали, а уж тем более бейсики были в такой же жопе, как и сейчас. Даже название у языка — javascript — уже говорит нам, откуда взялся синтаксис.

Разработчики самого JS, так же, как и первые разработчики на самом JS в то время были лучше всего знакомы с C-подобным синтаксисом. Именно такой вид языка программирования ассоциировался с ынтерпрайзом и так далее. Поэтому, если бы CS появился одновременно с ним или немного раньше, никаких шансов у него не было бы.

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

@Fduch 2 окт 2013 в 11:50

>Собственно, он и победил: где-то сейчас VBScript?
Там же, где и всё, что было не по душе корпорациям, вроде Sun, сидящим в комитетах по стандартам и саботирующим всё, что могло пошатнуть их монополию. Там же, где и VRML, effects, transforms, video.

>бейсики были в такой же жопе, как и сейчас
Вот она, анальная глубина знаний…

>JS появился в тот период, когда… особенно — Java были главными в индустрии
Продолжайте, продолжайте. Мы постараемся не ржать. Рассказывайте дальше про ваш Netscape Livescript.

@Proxmiff 4 окт 2013 в 11:09

А еще до этого MochaScript :)

@VolCh 2 окт 2013 в 10:35

смысл "->" трудно запомнить м легко забыть, и приходится лазить в документацию

Вполне нормальный аргумент, если CS сам не используешь, но время от времени на него натыкаешься там, где не ожидаешь.

Ещё аргумент: JS не требует трансляции.

@lalaki 2 окт 2013 в 10:37

согласен: если не используешь, то и каждый раз придется вспоминать; но здесь же речь — об убеждении «перейти с CS на JS», т.е. аргументе для тех, кто уже пишет на CS. приходится ли им вспоминать это? похоже, нет

@VolCh 2 окт 2013 в 10:42

Про «перейти» я как-то не заметил. Но вот как аргумент за приведение в вопросах про CS ответов на JS по-моему тоже пойдет. То есть кофескриптеру проще понять function(arg) чем джаваскриптеру (arg) ->.

@lalaki 2 окт 2013 в 10:52

С этим абсолютно согласен — это один из железобетонных, по-моему, аргументов, почему отвечать через CS — дурной тон. Это не считая более смутного ощущения, что так делать — дурной тон.

@lalaki 2 окт 2013 в 10:57

Насчет трансляции: если бы изначально был CoffeeScript, то он бы и воспринимался браузерами и тоже не требовал трансляции. А вот с переходом на Javascript возникли бы гораздо большие проблемы, поскольку он в СS не транслируется.

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

@lalaki 2 окт 2013 в 18:24

Анатолий, при определенном уровне понимания CS очевидно, что в него нельзя автоматически транслировать произвольный JS. Любой инструмент, заявляющий обратное, должен настораживать. Но Js2Coffee так и не заявляет — он "помогает мигрировать на CS", т.е. инструмент — для тех, кто CS уже освоил и просто так себе в ногу не выстрелит.

Держите:

(function(){
    str = '';
    
    if (str == 0 && window.str === str) {
        alert('translated correctly');
    }
    
    else {
        alert('translated wrong');
    }
})()

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

@lalaki 2 окт 2013 в 19:52

Анатолий, а почему это ваш транслятор решил именно эти строки оставить в виде JS?

Плюс получается, он их в CS-то не перевел. Формально — да, достаточно JS заключить в обратные апострофы, и получится вроде бы CS. Но мы же про реальную трансляцию говорим.

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

1) нестрогого сравнения с приведением типов в CS в принципе нет — никакой транслятор вам не транслирует

==

правильно, потому что такой операции в принципе нет в CS.

Это вопрос даже не программирования, а базовой математики: в множестве операций JS существуют операции, не являющиеся результатом трансляции какой-либо операции JS (в частности, нестрогое сравнение) => обратное отображение «трансляция JS -> CS» не определено для них => транслятор создать нельзя

2) создание глобальной переменной без использования window — на самом деле без контекста невозможно определить, будет ли создана глобальная переменная: если пример выше хранить и выполнять как отдельный файл, то будет создана; а если он, например, на сервере автоматически вставляется в другой файл-обертку, в которой

str

уже определена (например, так извращенно собирается какая-нибудь большая библиотечка), то глобальная переменная не будет создана; и никакой транслятор вам runtime-контекст не определит и в одном из двух случаев автоматически ошибется.

@VolCh 2 окт 2013 в 20:09

никакой транслятор вам не транслирует
==
правильно, потому что такой операции в принципе нет в CS.

Неужели нельзя на CS написать функцию (или просто кусок кода), которая будет сравнивать два параметра по всем правилам JS?

@lalaki 3 окт 2013 в 05:17

Действительно, так формально можно сделать — я ошибся.

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

@lalaki 3 окт 2013 в 05:13

он не транслировал эти строки в CS. точно так же все можно обернуть в апострофы и сказать: «транслировано!»

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

@printf 3 окт 2013 в 09:10

Описание преимуществ JS

Запросто, хотя уже и написали про это: JS не требует трансляции, работает в каждом браузере нативно, можно отлаживать без source maps и даже в MSIE (ах, эта восхитительная отладка в MSIE).

Скобочки и стрелочки (или их отсутствие) это предельно несущественно.

@lalaki 3 окт 2013 в 09:17

Вы одно важное условие пропустили: «если бы сначала был CS». То есть поменяем местами JS и CS и представим, что сначала появился и стал нативно поддерживаться браузерами CS, и соответственно трансляция и source maps для него были не нужны. а JS бы появился только через много лет как попытка улучшить CS и требовал всего того же, что сейчас требует CS.

Мог бы вообще JS быть создан в таких условиях? Ради чего, ради каких его преимуществ стали бы на него переходить с CS и мириться со всей дополнительной возней, да еще и преодолевать стандартный консерватизм и нежелание привыкать к новому?

Это не фантазия — это умозрительный эксперимент. Если умозрительно оказывается, что в такой ситуации JS бы и не появился/не набрал популярность, то это повод задуматься фанатикам JS. У меня получается именно так.

@VolCh 3 окт 2013 в 09:22

Как минимум, Си-образность была бы плюсом. Люди вон на Питон не хотят переходить лишь потому что нет скобочек, а непонятные отступы :)

@merlin-vrn 3 окт 2013 в 09:24

Да-да, причём вроде бы вполне адекватные люди говорят по этому поводу «блоки отступами? Я ещё не сошёл с ума».

@VolCh 3 окт 2013 в 09:27

И при этом же эти люди тратят часы и дни на разработку правильного «отступирования» в Си-образных языках, да ещё и на разработку хуков на прекоммит и т. п. в VCS, чтобы коммит с неправильными не прошел :)

@Mrrl 3 окт 2013 в 09:30

Ну да. «Оставьте нам право на ошибку!»

@lalaki 3 окт 2013 в 09:32

Коллега, мне кажется, вы все-таки немного упускаете исходное условие — «если бы изначально был CS»: по-вашему, если бы люди уже привыкли к блокам отступами, они бы стали специально переходить на блоки скобками? С чего бы, при условии, что они уже привыкли?

В нашей реальности мы массово видим людей, которые со скобок переходят на отступы и радуются, и людей, которые сидят на скобках и плюются от отступов, но что-то не видно тех, кто с отступов переходит на скобки и радуется. Почему бы это было в случае перехода с CS на JS? И как бы звучали аргументы создателей JS о скобках?

@printf 3 окт 2013 в 09:41

В нашей реальности

Так то в нашей. Предложенная вами фантазия существенно отличается.

@lalaki 3 окт 2013 в 09:53

Только в одном — что появился CS с самого начала. А вы автоматически считаете, что в реальности, в которой появился CS, люди будут более склонны переходить на скобочки, если изначально привыкли к отступам? Типа, быстрее утомятся от отступов? Или все-таки к ним больше привыкнут?

@printf 3 окт 2013 в 10:00

Давайте будем исходить из того, что у каждого явления есть причина. Синтаксис JS получился таким из-за влияния других популярных языков, а не на пустом месте (то же относится и к нестрогому сравнению, кстати). Популярность — функция от времени.

Вероятнее всего, в 1995 году CS получился бы с Си-подобным синтаксисом.

@merlin-vrn 3 окт 2013 в 12:20

Вероятнее всего, в 1995 году CS получился бы с Си-подобным синтаксисом.

Позволю себе расширить мнение: в 1995 году CS получился бы ровно таким, каким получился JS.

А вы верите в судьбу? :)

@printf 3 окт 2013 в 12:33

Прототипному наследованию было бы неоткуда взяться. Не будем забывать, что CS это синтаксический сахар, у него нет своей системы типов. Транслировался бы он, скорее всего, в Java (не в C++ же).

@Mrrl 3 окт 2013 в 09:51

И как бы звучали аргументы создателей JS о скобках?

Вам больше не нужно следовать навязанному языком разбиению на строки! Используйте строчки любой длины, хоть 30, хоть 300 символов, и располагайте их так, как считаете правильным и логичным! В конце концов, программы пишутся для людей, а не для компиляторов!

@lalaki 3 окт 2013 в 09:56

Эмоциональный заряд цепляет) Только непонятно — строчки в 300 символов — это как раз «для людей, а не для компиляторов»? И скобочки — это тоже для людей, а не для компиляторов?

@VolCh 3 окт 2013 в 12:49

по-вашему, если бы люди уже привыкли к блокам отступами

Скорее они бы привыкли держать в уме контекст текущего языка и в этом отношении. Из мэйнстрима скобки используются навскидку в C, C++, C#, Java, PHP. Хотя, может, больше популярности было бы у Python.

@Mrrl 3 окт 2013 в 09:26

А спроектировать эту ситуацию на Си, который был создан гораздо позже Фортрана и других «алгоритмических» языков, не получится? Ради каких преимуществ Си на него стали бы переходить с Фортрана и Кобола?

@VolCh 3 окт 2013 в 09:29

Более низкоуровневый доступ. Лучшая структурированность. По крайней мере насчет Фортрана. Кобол не помню даже как выглядит. Вроде на Паскаль похож?

@lalaki 3 окт 2013 в 09:34

Давайте сначала с нашей разберемся, не создавая дополнительных сущностей. Спор идет о «JS vs CS», Си ни при чем.

@Mrrl 3 окт 2013 в 09:41

Так ведь «умозрительный эксперимент» проще проводить, рассматривая исторические аналогии и уже известное поведение реальной толпы в этих условиях. И смотреть, в чём отличие ситуации и на что оно может повлиять. Угадывать с нуля — несколько рискованно.

@lalaki 3 окт 2013 в 09:46

Это не аналогия, так как С — это не улучшение Фортрана, и языки не взаимозаменяемы: Фортран — математический язык, используемый и поныне, С — язык общего назначения.

@printf 3 окт 2013 в 09:38

Ничего не пропускал, появился бы CS раньше и транслировался бы в какой-нибудь VBScript, или Java-applet. Это синтаксический сахар же.

фанатикам JS

Ох, ну ясно. Можете не продолжать свой крестовый поход, сэр рыцарь Единственного Правильного Пути.

@lalaki 3 окт 2013 в 09:52

Как из выражения «фанатики JS» следует, что я сам — фанатик CS? Это забавно, ведь у меня самого есть списочек вещей, которые я в CS не люблю, и которых не было в JS.

Например, я путаю операторы итерации по массиву (in) и объекту (of) — ошибок они не вызывают, все только на отладке вскрывается. Или приходится вспоминать, по чему идет итерация в объекте, если указать только одну переменную итерации — по ключу или значению. Ну и еще несколько тонкостей.

@printf 3 окт 2013 в 10:12

А я разве написал где-то «фанатик CS»? Не нужно выдумывать за меня реплики, пожалуйста. Тем более, если бы я хотел сохранить такой формат высказывания и негативную коннотацию, то придумал бы что-нибудь повеселее, например обозвал бы собеседника «CS-макакой».

Только это некультурно, и я стараюсь так не делать.

@lalaki 3 окт 2013 в 11:13

Прошу прощения — почему-то взбрело в голову, что под «рыцарь Единственно Верного Пути» вы и подразумевали фанатика. А на самом деле, оказывается, что-то другое. Но все-таки здорово, что вы стараетесь писать культурно. Тогда стоит обратить ваше внимание на то, что конкретно на мою личность все-таки как раз вы и перешли. Засим предлагаю от моей скромной персоны обратить взор на основную тему.

@meettya 2 окт 2013 в 10:30

Бла-бла-бла — кидалтское нытье и занудство.

Автору стоит вернуться к взрослой реальности.
Не хотите наш CS — ну и xрен с вами! Не нравится ответ на SO на CS — ну и хрен с вами!
Это ваши проблемы и не вам мне указывать где что и на чем писать.
Я же не начинаю ныть, что вот тут книжка по алгоритмам на сях, тут — на лиспе, а тут вообще не пойми чего? Раз оно надо мне, значит и с этим я разберусь.

@ekubyshin 2 окт 2013 в 11:39

такое ощущение, что автор не смог осилить cs или ts, либо тупо лень было вникунть зачем они нужны и как и где их можно применять.

@VolCh 2 окт 2013 в 11:45

Пост не о том, лучше cs или хуже, не об области применимости, а о том, что cs-еры активно лезут с ним там где речь о js и никаких оснований предполагать, что аудитория с cs знакома — нет.

@ekubyshin 2 окт 2013 в 12:02

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

@Fduch 2 окт 2013 в 11:40

Автор пишет фигню, но стоит действительно задуматься, почему появляются такие вещи, как CoffeeScript.

Мне кажется, причина очень проста — форсированный монополизм не всем приятного JavaScript. Стандарт HTML никак не ограничивает авторов скриптов и поддерживает любые языки. Но нативной поддержки чего-то, кроме JS почти нигде нет. Из исключений: Internet Explorer, поддерживает не только JavaScript, но и VBScript. В Chrome, FF, IE на Windows, Mac OS X, Linux с Silverlight-библиотекой Gestalt (http://visitmix.com/work/gestalt/) можно было использовать Python и Ruby для написания скриптов. / script type=«text/python» / и поехали…

К сожалению, многие люди очень консервативны и стремятся всеми силами лишить свободы выбора не только себя, но и всех окружающих. Это касается и производителей браузеров. В результате саботажа и пропаганды «web == JavaScript» браузеры сейчас реально поддерживают только JS. Тем, кто не хочет есть его в сыром виде не остаётся ничего, кроме как компилировать свой код в него. JS — это ASM для web. И в этом его статусе можно винить только его пропонентов, которые искоренили всё остальное.

@SerafimArts 2 окт 2013 в 12:00

Кстати, интересный факт: Если заменить все слова «CoffeeScript» на «JQuery» — статья не потеряет своей смысловой нагрузки =)

@SerafimArts 2 окт 2013 в 12:09

О, благодаря вольным Ctrl+R — я теперь знаю какую можно ещё опубликовать статью: pastebin.com/8sZy8nHg (прошу не судить строго, это лишь набросок) =)

@ekubyshin 2 окт 2013 в 12:12

жжешь

@dbelka 2 окт 2013 в 12:16

Угу, что вы пишете код JS в ответах, я его не понимаю… я просто спросил…

@Finom 2 окт 2013 в 12:55

Я с вами согласен, даже несмотря на то, что сам везде юзаю jQuery за исключением маленьких проектов.

@SerafimArts 2 окт 2013 в 13:24

Потому что оно удобнее для выборки по селекторам, не правда ли? Вопрос на засыпку, готовы ли Вы советовать на StackOverflow использовать JQuery, если с ним код будет действительно чище (и соответственно отвечать на вопросы самим кодом на JQ) и читаемее? Почему подразумевается, что фронт-энд разработчик должен понимать этот JQ синтаксис? =)

@Finom 2 окт 2013 в 13:35

Если вопрос касается jQuery, то да, но, если вопрос общий, то, конечно же, отвечу, используя чистый ДОМ.

@SerafimArts 2 окт 2013 в 13:58

Вы — уникальный человек =)

На моей памяти — большинство говорит, мол, зачем тебе так мучиться, господин добрый топикастер, на JS это 42 строки невменяемого кода, а на JQ — это 4 строки. Видишь как всё просто *далее следует ссылка на мануал и 100500 аргументов в сторону JQuery*.

Просто тема — не только попытка образумить Coffee сообщество со своими подсказками «не в тему», но и повод всё же задуматься, каким образом примерно за 2 года, один из 100500 аналогичных языков, с бешеным синтаксисом, который никто особо-то и не раскручивал — набрал от 6% до 17% (по разным статистикам) от JS сообщества. Всё же это не мало.

Увы, статистику JQuery на 2008 год не нашёл (через 2 года после появления), можно было бы сравнить статистику развития этого популярного фреймворка, с этим «диким» языком =)

@AleksDesker 2 окт 2013 в 13:40

JQ на сегодня фактически промышленный стандарт, но все же не решился бы рекомендовать его тому, кто не просил подобных рекомендаций. Потому что я им пользуюсь не потому что умен и крут, а наоборот потому что слаб духом, ленив и недостаточно хардкорен, чтобы писать только на чистом JS и мне за это стыдно :)

@RUVATA 3 окт 2013 в 07:18

Вечный вопрос компетентности выбранной технологии относительно стоящей задачи.
jQuery — очень хороший инструмент, весьма самобытен, не советовал бы фрон-эндщику начинать знакомиться с client side JS сразу с использования jQuery, к его использованию необходиом приходить через читсый JavaScript, чтобы программист понимал, что он собственно упрощает, представлял себе внутренне устройство уровня абстракции который ему предоставляет фреймворк.

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

@AleksDesker 3 окт 2013 в 11:55

Я бы на вашем месте не стал бояться jQuery, даже для самого что ни на есть боевого проекта. Весь мир им пользуется и грузят его все правильные пацаны из GOOGLE CDN, так что вы можете быть на 90% уверенными, что когда пользователь приходит к вам, jQuery уже лежит у него в кеше. Ну а если refresh даванет или что, так уж подождет, пока эти 30Кб загрузятся, не развалится. Ну и что важнее с perfomance у него все в порядке, можно пару процентов конечно выиграть кое где, если на чистый JS переписывать, но есть риск что вы где-то сами накосячите, сделайте не оптимальное решение и все отбитые проценты тут же улетят. А главное что в большинстве случаев разница просто не настолько велика, чтоб пользователь мог заметить, тормоза могут возникнуть, если, например, на фронтенде надо ворочать большим объемом данных, но это уже значит в консерватории проблема, а не в JQ.

@Louter 10 окт 2013 в 10:31

Обожаю этих правильных пацанов: открываешь сайт и ждёшь пока гугл снизойдёт отдать тебе jQuery…

@AleksDesker 10 окт 2013 в 18:02

Ну сайт-то отдается раньше jQuery, не ждите, почитайте чего-нить там пока.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий