усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Как спорить о языках программирования
усы2
tonsky

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

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

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

У нас же, в программировании, удовольствие сильно переоценено. Очень много заморочек на гладкий и бесшовный «экспириенс», на «красивый» и «лаконичный» код. Как будто красота определяется языком. То есть я не против, но это не может быть единственной selling point и не должно идти в ущерб важным качествам: композируемости, читаемости (даже самоочевидности), устойчивости к внесению ошибок, универсальности. Скажем, столь популярные DSL, когда одна, обычно очень конкретная задача решается очень хорошо, но чуть выйдешь за рамки и вся структура оборачивается очень закостенелой (пример: midje). В Clojure очень хорошо с DSL, но по перечисленным причинам я не привожу это как преимущество. Вообще, бойтесь вещей, которые продают только лаконичную запись и ничего больше. Обычно это достигается серьезными уступками, и как правило в целом того не стоит.

То же самое касается простоты освоения, она сильно переоценена. Глупо игнорировать что-то только потому, что оно выглядит непривычно. Что такое две недели изучения языка, если вы потом будете год делать на нем проект? Лучше день потерять… Многие вещи настолько хорошо подходят под определенные задачи, что стоят того, чтобы с ними разобраться (R, Erlang, Lua). Смешно, но непривычность — одно из сильнейших препятствий к освоению Clojure (lisp-синтаксис, ФП). Кстати, ровно так же глупо думать, что что-то понянто, если оно выглядит привычно. Любой язык или технологию нужно учить, потому что они привносят что-то новое (если не привносят, то они и не нужны). Иллюзия привычности — плохой индикатор, привычки вообще очень мешают развитию.

По этой же причине мне кажутся вредными статьи «как я поставил Go и Rust и что узнал за первые два дня» с выводами. Подобные тексты создают иллюзию понимания, хотя все описанные ощущения и факты, совершенно непонятно, как они сыграют in the long run. Удобные мелочи могут превратиться в катастрофу (например, github-зависимости в Go или сложность Scala, которая не уменьшается со временем), а страшные проблемы могут просто не встречаться в реальной жизни (или окажется, что пытаешься делать неправильно, надо дать организму привыкнуть). Разница как между первым знакомством и браком — какие-то вещи чувствуешь сразу, какие-то понимаешь через год, и скорее всего во всем, что пытался просчитать, ошибся.

Кстати, поучителен в этом смысле пример Clojure, которая создавалась с расчетом на одно применение (макросы, concurrency) а полюбилась за компактный код и структуры данных.

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

Одно из важнейших достижений здесь — REPL и интерактивная разработка. В мозгу человека есть несколько пределов, они достаточно небольшие, что-то порядка 100 мс — человек замечает задержку, 1 секунда — теряет внимание, 10 секунд — переключается на другую задачу (цифры примерные, по памяти). Чтобы не разрывать состояние потока, паузы в цикле обратной связи не должны превышать пары секунд. На границе этих порогов происходит качественный скачок. Скажем, разница в скорости между Java-разработкой (перекомпиляция) и Clojure-разработкой (вычисление прямо в редакторе inline) может составлять больше порядка. Не потому что суммарное время компиляции java-проекта большое (не такое большое), а потому что программист успевает отвлечься. Как живут C++ программисты, у которых проект собирается часами, я не знаю.

Наличие готовых библиотек, по идее, тоже качественно ускоряет работу программиста. Open source иногда называют той самой серебрянной пулей, которая есть. Я лишь хочу дополнить, в контексте оценки годности языков, что огромным плюсом является возможность самому построить нужные библиотеки за короткий срок, за несколько дней. Современные языки, кроме низкоуровневых, обычно неплохо с этим справляются. То есть гнаться можно не только за платформами с кучей кем-то написанного удобрения (nodejs, ruby), но и за языками, где написание нужных вещей — умеренно-тривиальная задача. Я вообще гораздо больше ценю идеи, чем их реализации. У некоторых важных вещей нет реализации — wsgi, REST, CRDT.

Часто переживают насчет наличия IDE к языку, мол, радикально улучшает производительность. Я бы сказал, зависит от того, какие фичи имеются в виду. За пределами IDE тоже можно жить, и отказ от удобств может положительно влиять на код. Вопрос сложный и даже контринтуитивный, завязан на устройство мозга; иногда, чтобы добиться от него максимальных результатов, полезно его немножко обманывать. Если коротко, то отсутствие IDE наказывает тяжестью за сложный код, а мозг интуитивно ищет более легких путей. Наверное, с очень большой кодебазой работать в IDE эффективнее. Но и писать большие программы — не единственный способ программировать. Мне кажется, что REPL гораздо важнее любых рефакторингов и анализов.

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

В этом смысле, в глобальном, основной критерий оценки, даже оправдания существования того или иного языка, платформы — это создание новых классов систем. Лучшее, что может оправдать почти все остальные недостатки языка, это возможность создавать вещи, которые до этого были принципиально невозможны или близки к невозможным. Примеры: go — сетевые сервисы, transit — быстрая коммуникация browser/server, erlang — неубиваемые сервисы. А вот загвоздка CoffeeScript, например, в том, что он не дает никаких новых качеств. Кстати, в этом разрезе у C# и у Objective-C как языков вполне есть смысл :)

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

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

Интересен подход Erlang-а, который зашел с другой стороны, признав, что ошибки всегда будут, меньше или больше, и научившись адекватно и понимаемо этой ситуацией управлять. Ну они правы оказались, 30 лет прошло, люди примерно всё те же ошибки совершают. Человека тут не исправишь, надо думать над инструментами.

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

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

В этих смыслах одни языки могут подходить лучше, чем другие. Статическая типизация лучше ведет себя с ростом количества кода, избыточные языки лучше масштабируются на большие команды. На Clojure можно строить сложные системы очень быстро, но трудно масштабировать ее за пределы 8–10 человек.

Языки с большим количеством ограничений (например, Erlang) привносят больше дисциплины, помогают держать код в тонусе, он меньше «плывет». Мысленный эксперимент: представьте, что вы взяли некое ядро и отдали двадцати людям работать над ним в течение года. Что получится на выходе, если оно было написано на языке X? А если Y? К примеру, Ruby On Rails решает проблему разбродов и шатаний просто фактом наличия конвенций и соглашений.

Очень мало изучены возможности языков по распространению знаний в команде. Обычно база знаний и коммуникации выносятся за скобки, а в языке оставляют только возможность отдавать машине инструкции. Это сильно неправильно. Программная система — это социальный проект, передача знаний — одна из важнейщих задач команды, код — наиболее естественное место для этого. Как сделать так, чтобы язык помогал введению новых людей в проект? Как сделать так, чтобы через код принятые решения достигли своего адресата через несколько лет? Как отслеживать косвенные взаимосвязи, которых нет в коде явно? Как отделять важные куски кода от второстепенных, принципиальные от ситуационных? Как отмечать ошибочные пути, чтобы другой человек через несколько итераций не повторил ошибку, не внес только что исправленный баг? Было бы очень интересно посмотреть на язык/среду, где распространение знаний о коде является первым приоритетом, наравне с самим кодом. Положительный пример — типы, ведь они выполняют и документирующую функцию. Под предлогом эффективности они заставляют программистов писать о коде больше, чем нужно компьютеру.

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

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

Это транскрипт моего доклада на fby.by, который я делал по новой модели: сначала пост, потом доклад. Вроде удобно

Слайды :P

Я не программист, но поскольку первым же пунктом у тебя стоит отрицание важности эстетики и юзабилити (на которых я специализируюсь) инструмента, я тебе сообщу, что так ты далеко не уедешь. Эмоциональный дизайн вполне может и постоянно бывает единственной selling point, что вполне объяснимо человеческой психологией и психофизиологией. Поэтому строить свою полемику тебе стоит как-то иначе :-) Например: «язык А несомненно имеет эмоциональный дизайн, но давайте рассмотрим его функциональные критерии».
Just saying.

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

Это, кстати и является причиной низкой популярности лиспа и его производных. Из-за избытка пунктуации люди слов не видят.

== Как живут C++ программисты, у которых проект собирается часами, я не знаю.

Зато я знаю. Плохо и не долго. C++ - это вот этот вот парикмахер

Этих языков уже наплодили столько, что человек, помысливший нечаянно: "А не стать ли мне программистом?" вдруг видит перед собой это нагромождение и охуевает: "Эт-та... Что, вот это всё надо знать???777" - плюёт, берёт в руки лопату и идёт на стройку. Там всё просто и понятно: тут греби, туда кидай.

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

Интересно, можно знать какой-нибудь ОДИН язык программирования, совершенно не зная других, и при том поддерживать нормальный для своего роста вес, не собирать бычки и не шариться по помойкам, чтобы кушать самому и кормить семью?

Можно, если, например, всю жизнь работать в одной конторе и пилить один продукт. Таких программистов огромное количество.

"А не стать ли мне программистом?" — если возникает такой вопрос, то лучше не надо. В идеале, любым делом стоит заниматься, только если понимаешь, что это твоё, что ты готов этим заниматься даже за копейки. Если из-за денег идти в программирование, то... лучше уж тогда в финансы, в них по определению деньги водятся.

И эта, как правильно произносится "С++" в устной речи? Ну типа транскрипция русскими буквами?

"Сиплюсплюс", ударение на последний слог.

без темы (Анонимно) Развернуть
Рассуждения справедливы для Web программирования, в остальных областях выбор ЯП на 100% определяется платформой. Embeded - только C или CodeSys, остальное лесом. ну и т.п.

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

"фу, в языке нет лямбд"

Конечно, это означает не просто отсутствие лямбд, а всего с этим связанного. Если функции высшего порядка таки есть, то нет понятия скоупа/нет возможности определить функцию, которая видима из одного места? Или все-таки нет функций высшего порядка? Си как-то живёт, и Джава тоже, конечно, но отсутствие концепции влечёт за собой как именно выглядит "канонический" способ решения вопросов и как язык способствует правильному выражению таких решений (правильному=безошибочному) без предыдущего опыта (не видел канонических решений). То же касается других языков, где правильность решений обусловлены договорённостями, традициями в сообществе адептов. Традиции являются эзотерическими знаниями - неочевидны непосвящённым, и встают преградой на пути.

Дело не только в "лямбдах". "фу, в Х-е нет ООП". Как правило, адепты на СО начинают объяснять, что ООП есть, и его можно решить через тайпклассы. Потом приходят более знающие и объясняют, что канонически этот вопрос решается по-другому. Само собой, язык Тьюринг-полный - duh - но это не то же самое, что "there! I told you в Х-е есть ООП!", поскольку средства языка не способствует решению задач через ООП/с помощью наследования, инкапсуляции, вот этого всего - независимо от того, хорошо это или плохо.

Не понятно почему автоматическое управление памятью попало в список подходов уменьшающих ошибки. Оно вообще никакого отношения к количеству ошибок не имеет. Это просто средство языка или платформы. И при использовании этого средства ошибки могут ещё и добавиться.

Часами C++ не компилируют. Дольше всего компилировался Splinter Cell, около 40 минут, на чуть большем Assassins Creed использовали SCU, что давало 18 минут + настроили IncrediBuild. В Яндексе существенная часть кодобазы была разбита на небольшие программы, которые опять же компилировались быстро. Но это нужно только для чистовой сборки, вытягивание из СКВ, например, дольше. При работе пересобирают только измененный файл, а чтобы сократить время линковки, часто линкуют код в dll'и. Поэтому время сборки C++ проекта дольше минуты — признак того, что программисту захотелось пофехтовать. А вот Scala после небольших изменений собирается в среднем дольше, чем C++.

Мой опыт раза в 2 короче, чем у enternet, но почти совпадает. Управление ресурсами в RAII-стиле не вносит дополнительных ошибок в сравнении с GC-управлением, но сильно повышает предсказуемость исполнения и дебажимость.

Про управление знаниями о коде есть идея. Можно описывать, что (и как, где это не совсем тривиально) делает код в вики, цепляя к страничке файл с кодом (взамен его помещения в какую-нибудь иерархию папок). Требует настройки системы сборки и инклюдов, зато позволяет сразу понимать архитектуру системы (корневая страница вики), более и менее важные части, используемые алгоритмы и статьи (в комментарии к коду писать LaTeX-формулы неудобно), историю подходов к реализации. Синхронизация между изменениями кода и такого литературного описания, видимо, остается все же на плечах разработчиков. Как думаете, взлетит?

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

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

"или сложность Scala, которая не уменьшается со временем",
Сказал Никита, писавший на Scala много лет.

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

>удовольствие сильно переоценено

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

Вон на ror и nodejs уже напрограммировали веселые, упаси бог, я лучше угрюмых почитаю

А все почему, потому что Вирта не уважают. Оберон не используют.

Еще такой вопрос. Мы имеем много языков. Получается, что среда, в которой эти программы будут исполняться, должна понимать все эти языки, или после написания приложения вот это всё каким-то образом надо преобразовать в какой-то более-менее понятный язык уже для исполнения в этой конкретной Венде или Линуксе? Тогда, если смотреть шире, то таки можно писать на любом языке и иметь надежду, что всё будет работать везде?

Да, первый уровень языков - это т.н. нативные языки, исходный код которых превращается в машинный код, понятный процессору (с вызовами функций операционной системы, когда это необходимо). Поскольку винда и линукс имеют разные набор вызовов (API), программы, написанные для одной системы, не станут просто так запускаться на другой. Для переносимости таких программ используют специальные кросс-платформенные библиотеки.

Следующий уровень абстракции - языки, использующие для своего выполнения виртуальную машину - прослойку между ОС и собственно языком. Сюда относятся в первую очередь Java (Java Virtual Machine, JVM) и C# с другими языками семейства .NET (Common Language Runtime, CLR). Программы на этих языках будут работать без особых усилий на любой платформе, для которой есть реализация виртуальной машины.

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

>Удовольствие программиста не имеет отношения к оценке языков. Только при прочих равных, то есть оно где-то в конце списка критериев

>Производительность программиста важна, это наверное один из важнейших факторов, которые мы можем отслеживать, и за которыми имеет смысл гнаться.

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

Процесс и язык все-таки разные вещи.

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

Спасибо! Все это очень интересно и есть о чем подумать.

Вопрос такой: какие это новые качества дает C#, и по сравнению с чем? :-) Нет, я им доволен, но вот о таком аспекте не думал.

Как же, под виндоус фон писать :)

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

Прошу прощения, но тут начинается оффтоп по Om и React. Насколько я понял, шаблоны html для динамически обновляемых кусков в случае применения React/Om становятся не нужны, с моей точки зрения это не очень удобно в плане переноса сверстанного html в приложения равно как и поддержки кода относящегося к UI, все-таки, при использовании директив в каком-нибудь AngularJS шаблон проще редактировать не-программисту, ну и динамический кусок не вырывается из контекста шаблона. Что вы думаете по этому поводу?

Edited at 2014-11-22 20:37 (UTC)

Думаю, что это иллюзия — дизайнер вполне может заглянуть в реакт-код, если понадобится (он же знает js, верно?), да и контекст обычно не сильно важен в html/css, обычно компоненты более изолированы, чем зависимы от окружения

без темы (Анонимно) Развернуть
Я перестал интересовался фича ми языков и спорами о них, потому что практически на любом из них можно сделать то что нужно, в большинстве случаев. Возможно на одном потратил в 2-3 раза больше времени и усилий но в конечном счете сделать можно все равно.

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

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

Edited at 2014-11-23 05:55 (UTC)

Пример ускорения в 10 раз - когда вместо сложной системы управления доступом с ролями и разрешениями ты (каким то магическим способом догадавшись что пользователям она не нужна) решаеш сделать простейшую систему юзер/админ и все.

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

Я к сожалению пока не знаю ответа как это сделать :) если только ставить небольшие эксперименты постоянно как в lean стартапах

Edited at 2014-11-23 06:05 (UTC)

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

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

Это в категорию «подходит ли язык под задачу» попадает.

Я так не смог понять как использовать repl именно для разработки. В ней можно поиграться с языком или библиотекой (да и то, если это требует более 2-3 команд для инициализации, лучше уже записать их в файлик). В ней, если тебе повезло и твоя функциональность выражается в виде каких-то "чистых" функций, которые можно просто вызвать, можно поиграться со своим кодом. Но это надо перезагружать проект в repl, теряя существующее состояние - это уже не пара секунд. Да и в таком счастливом случае можно не тыкаться в одно место снова и снова, а написать серию тестов, которые за тебя это сделают.

Так прелесть в том, чтобы из репла иметь возможность сунуться в работающую систему, и перезагружать её по красивому, сохраняя при желании состояние. Для Clojure Stuart Sierra придумал для этого подход (как его назвать-то?), в ClojureScript связка figwheels + weasel + defonce + component творит чудеса.

без темы (Анонимно) Развернуть

(Анонимно)
> Я несколько лет пропагандирую Кложу

Как успехи? Кто-то ей начал пользоваться?

> Удовольствие программиста не имеет отношения к оценке языков

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

> То же самое касается простоты освоения, она сильно переоценена

Если ты хочешь, что бы твой любимый ЯП был самым популярным он должен быть относительно простым. Посмотри на ЯП которые сейчас не вершине и куда Clojure никогда не добраться. Что бы быть популярным нужно быть a) C-like b) осваиваться максимум за неделю разработчиком с опытом другого C-like языка

> Многие вещи настолько хорошо подходят под определенные задачи, что стоят того, чтобы с ними разобраться (R, Erlang, Lua)

Согласен, поэтому в своей нише они безальтернативны по большей части, хотя вместо Erlang можно использовать C++, Java/Scala или какой-нибудь Go. Erlang слишком нишевый из-за этого не популярный в массе, другие названные могут делать еще много другого, вместо Lua можно встраивать JS, вместо R можно брать Python+Numpy+Scipy+итд.

> Любой язык или технологию нужно учить, потому что они привносят что-то новое

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

> Производительность программиста важна, это наверное один из важнейших факторов, которые мы можем отслеживать, и за которыми имеет смысл гнаться.

Так ты покажи факторы и сравнения, где Clojure однозначно уделывает всех остальных, все что я вижу это рассуждения на тему "Clojure хороший потому что там есть макросы и удобно DSL делать", со стороны смотришь на это и такой "нуу окей, удачи!"

> Одно из важнейших достижений здесь — REPL и интерактивная разработка.

мне кажется какие-нибудь python/ruby/js/php в этом плане уделывают clojure, написал код нажал f5, все работает, никаких тебе jvm компиляций.

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

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

> Часто переживают насчет наличия IDE к языку, мол, радикально улучшает производительность.

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

> А вот загвоздка CoffeeScript, например, в том, что он не дает никаких новых качеств.

Он дает error-prone, более быструю разработку и меньше проблем в продакшене, с другой стороны у него есть и известные недостатки, вполне себе хороший инструмент если так смотреть.

p.s. так какая ниша у Clojure где он уделывает все альтернативы? мне кажется ее не существует, но возможно я ошибаюсь.

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

без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
(Анонимно)
>Я несколько лет пропагандирую Кложу и подустал от этого.
(what (a (surprise! people (dontlike 'skobkoyobstvo))))
=> And never will.

ну да, ну да

(f x y) — много скобок
f(x, y); — мало скобок и других знаков препинания

скобки позволяют редактировать код структурно (paredit), и это дорогого стоит.

без темы (Анонимно) Развернуть
без темы (Анонимно) Развернуть
(Анонимно)
Я несколько раз пытался внедрить лямбды в java-проектах. Первый раз мне сказали что круто и клево, но вот не привыкли так, и давай лучше на циклах с ифами. Второй раз было похоже, хотя лябды уже стали частью языка. Может быть это я дурень и нихера в этом не понимаю, а чтение интернета и книг противопоказаны для меня?

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

На таких людей я и не ориентируюсь, они пускай сидят на своих местах, надо же кому-то будет через 10 лет наследие на Java 1.4 поддерживать

(Анонимно)
Сам писал кстати на более чем 5 языках для продакшена, включая яп с ручным управлением памятью. Поднял более 7 достаточно крупных проектов. Но люди не меняются. Везде люмпены.

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

Чтобы не разрывать состояние потока

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

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

В состоянии потока копание производится быстро и с ювелирной точностью.

Если все начнут думать, что в процессе не так, на этих "всех" вакансий начальников не хватит.

tonsky, а как тебе REPL помогает? А скале вот есть REPL, но проект компилится долго.

?

Log in