Alexey Veselovsky писал(а):
Было проведено интересное исследование:
На примере скольких программ? И каких именно?
(Может быть, эти данные доступны по указанной ссылке, но у меня на работе нет доступа к ЖЖ.
)
Вообще, что-то я сомневаюсь, чтобы краткость делала ребусы/шифровки понятными. Не зря тут АПЛ поминали.
P.S. Оберон делает ставку на простоту базового языка и возможность его расширения за счёт процедур, а не роста числа токенов и синтаксических правил (т.е. не за счёт усложнения языка).
В спорах по поводу языков программирования часто встречается аргумент про "поняность" или "непонятность" кода. Подразумевается, что если код более понятен, то его легче сопровождать и развивать.
Важной вариацией на тему понятности кода является вопрос о том, легче ли понимать более короткий код, или краткость кода может предъявлять слишком много требований к читающему. В своём крайнем выражении аргумент звучит так: что лучше, сидеть и целый час корпеть, пытаясь понять, что делают эти компактные пять строчек программы, или же это час можно затратить на то, чтобы не спеша и не напрягаясь разобрать два-три экрана эквивалентного "несжатого" кода.
Разумеется, когда мы говорим о кратком коде, мы не имеем ввиду синтаксическую краткость — отсутствие лишних пробелов, переводов строк, упаковывание повторяющихся последовательностей операций в текстовые макросы, etc. Краткость, которую имеет смысл рассматривать, достигается использованием абстракций более высокого уровня. Например, использование свёрток списков или деревьев вместо ручного их обхода.
Аргумент от Java/C++ программистов — использование слегка более многословного кода позволяет быстрее и эффективнее донести суть алгоритма до читателя кода. Реакция Java программистов на Haskell-код — этот ваш хаскель сложно понимать, ибо в нём нездоровое количество функциональности на единицу текста.
Аргумент от программистов на языках, допускающих написание существенно более коротких программ — короткий код позволяет человеку выражать более высокоуровневые концепции, наверняка более приближенные к предметной области, и поэтому понимание кода происходит быстрее и эффективнее. Реакция Python программистов на Java код — за деревьями не видно леса: большое количество церемоний вокруг простейших вещей напускает ненужный туман на ту мысль, которую программист пытался этим кодом донести.
В итоге, как всегда, каждый остаётся при своём мнении, ибо без каких-либо эмпирических данных противоположные аргументы выглядят одинаково правдоподобно.
Gilles Dubochet в своей статье принимает точку зрения, что код является механизмом обмена информацией — моделями, пониманием предметной области — между людьми. Базируясь на этом, он конструирует две гипотезы, и организует эксперимент, чтобы проверить состоятельность каждой из них.
Гипотеза номер один. Понимание кода улучшается, когда программист читает более компактный код, разумеется, если у программиста и писателя есть более-менее общее понимание предметной области. Возможный вывод из этой гипотезы, если она подтверждается — если программисты знают, что они делают, то компактный код позволяет им понимать более компактный код эффективнее менее компактного.
Гипотеза номер два. Намёки на модель предметной области, выраженные в типах, именах переменных, и т. п., позволяют привязаться к модели предметной области. Например, понятие объединения из реляционной алгебры может быть выражено через функцию по имени join, а может быть через функцию с похожим названием (enhance_with?), но не имеющую названия, взятого напрямую из предметной области.
Gilles дал некоторому количеству испытуемых код на Scala, по-разному реализующий некий набор алгоритмов из реляционной алгебры. Вот такие три варианта были разработанны:
S/G
Sparse/Grounded
Код на Scala, использующий только конструкции, доступные в Java.
Этот код имеет привязки к реляционной алгебре с помощью имён переменных, функций, типов, etc.
D/U
Dense/Ungrounded
Компактный код на Scala, использующий более высокоуровневые конструкции, доступные в Scala. Код не имеет явных привязок к реляционной алгебре.
D/G
Dense/Grounded
Компактный код на Scala, имеющий привязки к реляционной алгебре
Читателям кода давались на ознакомление концепции реляционной алгебры, а затем следовала просьба изучить предлагаемые варианты кода, реализующие некоторые алгоритмы из неё: natural join, left outer join, cartesian product. После вникания в код (обычно испытуемые справлялись с этим за 45-60 минут), испытуемые должны были написать "контракты", которым следует код: списки предусловий и постусловий, которым отвечает логика алгоритмов. Этим проверялась степень понимания кода. Параллельно использовался специальный девайс для слежения за глазами, чтобы понять, какие языковые конструкции привлекают максимум внимания на этапе изучения кода.
[Снимок экрана с кодом, как он был показан испытуемым во время эксперимента, с картой распределения концентрации внимания. Алгоритм слева — S/G, читаемый испытуемым 7, алгоритм справа — D/U, читаемый испытуемым 12. Обратите внимание на то, что фиксация внимания на именах идентификаторов, наблюдаемая для кода в стиле S/G, в коде стиля D/U отсутствует.]
Статья даёт развёрнутую интерпретацию полученных экспериментальных результатов. Попробую дать выжимку. По поводу состоятельности первой гипотезы Gilles замечает следующее:
Цитата:
Экспериментальные результаты показывают, что код на Scala, написанный с использованием продвинутых, абстрактных конструкций, лучше чем код, написанный в стиле, схожем с Java. Разница во времени понимания испытуемыми материала статистически значима, несмотря на малый размер выборки. Касательно достигаемого степени понимания, неформальные замечания, сделанные испытуемыми, дают субъективное подтверждение этому — использование продвинутых конструкций упрощает задачу понимания кода. Интересно отметить, что преимущества использования Scala были видны даже в группе, состоящей из программистов с ограниченным пониманием общих концепций Scala.
[…]
Неожиданностью оказалось наблюдение, что время понимания смысла токена не отличалось, несмотря на разный когнитивное содержание токена. (Шрифт мой — lionet). Если это свойство может быть обобщено, это дало бы дизайнерам языков точную цель: чем короче код, тем лучше. Это также может объяснить, почему языки предметной области (DSL) так эффективны.
По поводу второй гипотезы (привязка к доменной области упрощает восприятие кода) эксперименты не смогли ни подтвердить, ни опровергнуть этого. Испытуемые, которым требовалось создать концептуальную модель того, что происходит, тратили больше времени на чтение привязок к доменной области (имён переменных, etc), чем те, которые составляли более техническую модель кода. В целом можно сказать, что поставленный эксперимент не очень подходил для того, чтобы иметь возможность установить состоятельность второй гипотезы.
).
