> -- AVC писал(а):
> На примере скольких программ? И каких именно?(Может быть, эти данные доступны по указанной ссылке, но у меня на работе нет доступа к ЖЖ.  )Вообще, что-то я сомневаюсь, чтобы краткость делала ребусы/шифровки понятными. Не зря тут АПЛ поминали.P.S. Оберон делает ставку на простоту базового языка и возможность его расширения за счёт процедур, а не роста числа токенов и синтаксических правил (т.е. не за счёт усложнения языка).

А pdf можете скачать?
http://infoscience.epfl.ch/record/13858 ... 09coco.pdf

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