?

Log in

No account? Create an account

Previous Entry | Next Entry

Clojure at Echo

Originally posted by tonsky at Clojure at Echo
Провел в команде опрос на тему Кложи. Опрошено три респондента с 4-5 месячным опытом использования (основные разработчики нашего clojure-driven продукта) и двое с 1-2 месячным (переключились на другой проект). Результаты анонимизированы и подсокращены до смысловой части.

Насколько сложно читать?

— Несложно, дело привычки
— Читать сложнее Эрленга
— Python (2,3) < Java, Erlang (4) < Clojure(6,7)
— Примерно Ruby (без Rails)
— Очень зависит от автора

Насколько сложно писать?

— Очень легко
— Легче, чем в ООП языках
— Меньше кода, только суть
— Упирается в понимание кода
— Проблем с отладкой не возникает (отладочная печать она и в Африке отладочная печать)

Как быстро начинает получаться писать что-то полезное?

— Неделя
— Недели две
— От недели и больше
— С учетом, что есть опыт в ФП

Наиболее сложные области

— Concurrency примитивы
— Двухсторонний interop
— Meta параметры
— Идеология

Стала ли Clojure естественным, «своим» языком?

Все: Пока нет, но потенциально да.

Полезно

— Гибкость, лаконичность
— Особенно чувствуется при переключении на другой язык
— Скорость написания кода («опа-опа и готово»)
— Java—библиотеки
— Синтаксис удобен для файлов конфигурации

Раздражает

— Скобки (1 чел.)
— Привязанность к Java (2 чел.)
— Непрозрачность кода из-за макросов (2 чел.)
— Медленный старт, тяжеловесность платформы (2 чел.)

Общее впечатление

— Писать на Clojure очень легко. Видимо поэтому мы так много пишем и переписываем то, что пишем.

— Большая неограниченная свобода. Можно писать как угодно и в любом стиле. Код становится зеркалом разработчика.

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Наиболее полезные ресурсы

clojure.org
clojuredocs.org
— The Joy of Clojure
— Clojure Programming
— Programming Clojure


От себя (lionet). Вот этот пункт — ключевой:

— Clojure идеально подходит для соло проектов и достаточно плохо подходит для командной разработки.

Именно из-за особенностей влияния среды на командную работу, в Echo на серверной стороне использует в основном Erlang, и только в тех местах, где активный народ принципиально прётся от какой-то альтернативной технологии (i.e., OCaml, Clojure) написано на них.

Tags:

Comments

(Deleted comment)
ko_bx
Mar. 26th, 2013 12:26 pm (UTC)
Ну, мне лично выглядит (в разрезе питона) как ненужный костыль и недоджава поверх питона, хотя, конечно, трудно спорить с фактом наличия трудноуловимых глюков.

Из моего опыта даже один тупой функциональный тест для фичи проходится по почти всем функциям, тем самым согласовывая return-type'ы и прочее, и вы вот написали, что вроде и тесты у вас есть, в общем выглядит очень подозрительно.

Ну и, собственно, а что, если функция умеет возвращать и None, и list и QuerySet? А что, если в тестах вы захотите, чтоб она MagicMock вернула? Ну и по 2 строчки на каждую функцию, которые и так по 3-4 строчки в основном.. Короче я бы убежал от такого кода, честно.
(Deleted comment)
lionet
Mar. 26th, 2013 05:03 pm (UTC)
Да, вот, некоторое время назад натолкнулся на такой идио-полиморфизм (идиото-полиморфизм?). Когда функция возвращает строку, если ей дали строку, и список, если ей дали писок.

Что бы вы думали? Список из одного элемента приводит к возврату строки, и всё взрывается.

http://code.google.com/p/python-bitly/issues/detail?id=5

Edited at 2013-03-26 05:03 pm (UTC)
ko_bx
Mar. 26th, 2013 08:41 pm (UTC)
> Оно и есть костыль. Лично я предпочел бы объявление типов как в java

Тогда уж лучше на java писать, хоть во время компиляции получите эти проверки.

> вы уверены, что все возможные случаи использования API будут покрыты тестами?

Я не очень понимаю, как это относится к теме декораторов с псевдо-типами. Ни то ни другое не даёт никаких гарантий. Уверенность -- да, но не полную, конечно же.

> Вы уверенны в качестве тестов?

Конечно нет. (На удивление полезный) показатель -- покрытие кода (выражений) тестами. Инструмент борьбы с качеством -- код-ревью (не только тестов). Приятный момент заключается в том, что ответственность за отсутствие тестов держит тот, кто писал оригинальный код (и не покрыл его тестами), а не тот, кто что-то сломал своим рефакторингом (он не виноват, т.к. все тесты работают).

> А если в основном на пол-экрана? Или на экран? И это на саму только логику, без комментариев.

Ну, снова таки, для меня если функция на экран -- это "красный цвет". В целом, если функция на пол экрана и больше, то я согласен, что с такими декораторами хоть как-то спокойнее. Но я бы дробил функцию на более мелкие скорее, их и тестировать (при необходимости) проще.
(Deleted comment)
lionet
Mar. 27th, 2013 07:14 am (UTC)
> гораздо больший, чем объявление типа в сигнатуре функции

хм. how come? поясни.

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

ну а это вообще неправда. man CI. это примерно как говорить, что компилятор можно вызывать по желанию.
ko_bx
Mar. 27th, 2013 09:51 am (UTC)
Куда-то не туда уходит дискуссия. В общем, я согласен, что с сигнатурами вероятность ошибок меньше. Тем не менее это страх и ужас какой-то. Можно еще много разных драконьих правил придумать (например, можно взять и чистый ("утопический") TDD практиковать). Но как-то из моего опыта, при наличии нормальных тестов это никуда не клеится и оправдать сложно.

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

Оно настолько же по желанию насколько и сигнатуры типов. И я примерно представляю как всё можно автоматизировать более-менее.

> Тогда не используй питон: в его дистрибутиве полно функций на пол экрана и более. И это при его компактном синтаксисе.

Какая-то ошибка в логике, одно из другого не следует.
(Deleted comment)
ko_bx
Mar. 27th, 2013 10:36 am (UTC)
> Енто был сарказм. Намекалось, что если для тебя пол экрана-экран уже красный цвет, то python, в дистрибутиве которого такого кода достаточно, тоже приобретает красноватый оттенок с вытекающим к нему недоверием.

Да, к сожалению есть такое. Да и с наименованиями там не очень как-то консистентно (то camelcase, то в одно слово всё), и много еще с чем. А джангу вообще лучше не открывать, приходится отключать как минимум линтеры и pep8-проверки всякие, ужас просто (и функции там по 2-3 экрана нечитаемые -- норма).