усы2

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

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

Previous Entry Поделиться Next Entry
Читабельная Кложа
усы2
tonsky
Обнаглел настолько, что код вставляю скриншотами

http://tonsky.me/blog/readable-clojure/

  • 1
(Анонимно)
Читабельность — это про лёгкость, относительное и варьирующееся. Мне искренне проще читать comp, partial и т.д. по сравнению с анонимной функцией. Относительная природа читабельности подсказывает, что это не статичное качество и что-то, что кому-то неудобно читать сегодня, может стать удобно читать завтра.

Под «концептуально простым» я подразумеваю простое содержание. Я предлагаю фокусироваться на содержании, а не на форме, думать не о читабельности, а о том, насколько просто (распутанно) изложены сущности. let, например, более сложный чем threading macro (или же просто обычная запись в один длинный s-expression), потому что последнее гарантирует линейность операций, в отличие от let.

Так же и high-order functions упрощают изложение, производя конкретные трансформации функций, в отличие от арбитрарно возможных внутри fn.

В заметке это немного присутствует (декаплинг nil/false), но в то же время & {}, которое можно объяснить как запутывание list/map в одну сущность, ты объясняешь с практической точки зрения (сложно вызывать), в то время как это последствие проблемы.

Не соглашусь. Ты говоришь о формальных свойствах конструкций. Если бы дело было только в них, все было бы так, threading over let, higher-order over анонимки. Они действительно меньше свободы дают, легче понять что происходит «в общих чертах». Ну, какие-то данные тредятся. Ну, какие-то функции комбинируются. Эту «форму конструкции» проще считать.

Заковыка в этом «какие-то». В реальном коде, когда его предметно читаешь, важно _конкретно_ что за функция. Не просто «одна функция с одним аргументом скомбинирована с другой функцией с одним аргументом», а что именно за функции: первая вычисляет зарплату, вторая возраст, например. Важно, что в конструкцию приходит именно тип Юзер, а не абстрактный Х. И так далее. Важно, что с ним делаются _правильные_ вещи. И правильность определяется не тем, правильно ли скомбинированы функции по количеству аргументов, а что конкретно это за функции. И при разборе таких конструкций гораздо проще читать их маленькими порциями. Юзер вошел сюда, применилось это, применилось это, вызвалось вон то, сюда записалось, вышел. В идеале каждый шаг отдельно и с намеком на то, что происходит (промежуточные имена, например). Можно и трединг макрос аннотировать комментариями, будет то же самое. Но опять же, то что это именно трединг, т.е. трансформации над одним и тем же объектом, не так важно для нас, как то, _какие именно_ это трансформации и _что именно_ они возвращают.

И еще момент. Трединг сам по себе это не какая-то семантическая конструкция. Он не несет смысла сам по себе. То, что его применили, не сообщает на семантическом уровне никакой новой информации. Это ровно «так случилось, что ряд операций в данном конкретном случае удобно выстраивается и поэтому сокращается до цепочки». Не больше и не меньше.

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

(Анонимно)
Сорри, мутно и расплывчато, но проще не могу объяснить.


Нет, всё здорово и понятно :-)

Кложа как инструмент старается решать проблемы максимально абстрактно. Отсюда функциональность, интерфейсы (а не конкретные типы данных), каплинг nil/false (в том числе для совместимости с хостом, но не только), структуры данных, имплементирующие IFn, и т.д.

Мне кажется, то о чём ты говоришь, лучше решать с помощью clojure.spec, а не трансформируя абстрактный код in-place: clojure.spec гораздо более выразительный инструмент для конкретики, и сможет хорошо описать и шейп структуры данных для юзера, и конкретные трансформации, производимые функциями. clojure.spec отделяет implementation details от intent.

И еще момент. Трединг сам по себе это не какая-то семантическая конструкция. Он не несет смысла сам по себе. То, что его применили, не сообщает на семантическом уровне никакой новой информации. Это ровно «так случилось, что ряд операций в данном конкретном случае удобно выстраивается и поэтому сокращается до цепочки». Не больше и не меньше.


Да, конечно. Трединг семантически эквивалентен любой обычной форме. Всё, что я говорил о threading против let, можно читать как plain s-expression vs let.

  • 1
?

Log in

No account? Create an account