sermon

[thedeemon]

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

Comments

[thedeemon.livejournal.com]

"не скомпилируется" это уже хорошее свойство, сейчас вон даже из С++ собрались второй Раст делать, все туда идут.

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

[pupsikk.livejournal.com]

Много маленьких функций вместе составят точно такую же простыню.

[thedeemon.livejournal.com]

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

Вот даже графики кто-то строил:
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/

А как быть если код не сжимается?

[pupsikk.livejournal.com]

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

Re: А как быть если код не сжимается?

[thedeemon.livejournal.com]

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

[valentin budaev (from livejournal.com)]

А почему такой странный показатель LOC/commit? Не вижу в посте ни одной причины, по которой он должен что-то показывать. Но даже если согласиться, что размер коммита хоть что-то полезное отражает, то сравнивать надо не чистый код, а размер пожатого годным архиватором результата, как минимум, это будет ближе к количеству информации.

[thedeemon.livejournal.com]

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

[valentin budaev (from livejournal.com)]

> (что нам скажет кол-во информации?)

Я рассуждаю так - вопрос плотности информации нас не интересует, т.к. это вопрос синтаксический, во-первых (то есть мы всегда можем взять язык Х и добиться идеальной плотности информации не меняя семантику, только синтаксис, а вопросы синтаксиса - существенно субъективные вопросы) и на собственно "писанину кода" программист время все равно практически не тратит, даже когда язык сильно вербозный. А время он тратит на генерацию информации. Значит, лучше тот язык, что позволяет решить задачу за счет меньшего количества информации (но не за счет ее более эффективного выражения) - и это уже как раз семантика. Значит, надо сравнивать количество_информации/задача, а лок - какой-то странный показатель. Сильно зависит от стиля оформления кода, от длины идентификаторов и прочих спорных вещах. Например, те же длины идентификаторов взять - они как сильно короткие плохо, так и сильно длинные плохо.

> а главное, прийти к согласию о том, как именно сжимать

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

[thedeemon.livejournal.com]

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

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

[valentin budaev (from livejournal.com)]

> были уже разные исследования, где LOC был хорошим показателем (прямым коррелятом) как по скорости разработки, так и по числу ошибок.

Ссылками не поделитесь?

[thedeemon.livejournal.com]

Увы, не сохранил.

[sleepy-drago.livejournal.com]

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