Здравствуйте, Трурль, Вы писали:

K>>Дело то все в том, что простота простоте — рознь. Лисп прост формально (нетипизированное лямбда-исчисление), прост для интерпретации, но не для программиста. Простым для человека язык делает сахар.

Т>

Проблема гораздо серьезнее. Она в том, что представления о читабельности кода черезвычайно субъективны и коренным образом разнятся у разных людей.

(c)Klapaucius

Это не так. Когда приходится по работе просматривать тысячи строк кода за день, становится ясно, что реально влияет на читабельность, а что — ерунда на самом деле. Ну вот, например, вот это

some_function( parm1, parm2 )
{
   code, code, code
}

хорошо, а вот это

some_function (parm1, parm2) {
   code code code
}

плохо. Фокус в том, что для распознавания образов (просто вычленить границы блоков и имена переменных из потока) в первом случае требуется чуть меньше мозговой энергии и концентрации внимания. Не все замечают этот "чуть", но после работы на maintenance в течении нескольких лет (когда приходится много разного кода смотреть) люди обычно это замечают.

Это что касается оформления. А что качается семантики — в целом, правило одно — чем меньше indirection level конструкций, тем проще разобраться в семантике. Свойство макросов, которое обязательно создаст проблему в большом проекте, если о нем забыть — они всегда увеличивают indirection level конструкций. Таким же свойством обладают некоторые не-макросные конструкции языков программирования — например, перегруженные операции. Я это пытался в своих примерах показать.