Хэл Фултон - Программирование на языке Ruby

То, что Ларри Уолл говорил о языке Perl, остается справедливым: «Когда вы хотите что-то выразить на маленьком языке, оно становится большим. А когда вы пытаетесь выразить то же самое на большом языке, оно становится маленьким». Это верно и в отношении английского языка. Если биолог Эрнст Хэккель смог всего тремя словами выразить глубокую мысль «онтогенез повторяет филогенез», то лишь потому, что эти слова с весьма специфическим смыслом были в его распоряжении. Мы соглашаемся на внутреннюю сложность языка, потому что она позволяет избежать сложности в отдельных высказываниях.

Переформулирую этот принцип по-другому: «не пишите 200 строк кода, когда достаточно 10».

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

Конечно, не нужно забывать предупреждение Эйнштейна о простоте. Если расположить краткость слишком высоко в списке приоритетов, то получится совершенно загадочный код. Согласно теории информации, сжатые данные статистически похожи на белый шум. Если вы видели код на С или APL либо регулярное выражение — особенно плохо написанные, то понимаете что я имею в виду. «Просто, но не слишком просто» — это ключевая фраза. Стремитесь к краткости, но не жертвуйте понятностью.

Трюизмом следует считать мысль о том, что краткость в сочетании с понятностью — это хорошо. Но тому есть причина, причем настолько фундаментальная, что мы часто о ней забываем. А состоит она в том, что компьютер создан для человека, а не человек для компьютера.

В старые добрые дни все было почти наоборот. Компьютеры стоили миллионы долларов и пожирали многие киловатты электричества. Люди же вели себя так, будто компьютер - божество, а программисты - его скромные жрецы. Час машинного времени стоил дороже часа личного времени.

Когда компьютеры стали меньше и дешевле, приобрели популярность языки высокого уровня. Они неэффективны с точки зрения машины, зато эффективны с позиции человека. Ruby — всего лишь одно из последних достижений на этом пути. Некоторые даже называют его языком сверхвысокого уровня (VHLL — Very High-Level Language). Хотя этот термин еще не получил четкого определения, я думаю, что он оправдан.

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

Мы сейчас говорим о смещении парадигмы: от машиноцентрической к человекоцентрической. На мой взгляд, Ruby дает великолепный пример человекоцентрического программирования.

Теперь я хочу взглянуть на вопрос под несколько иным углом. В 1980 году вышла чудесная книжка Джеффри Джеймса «Дао программирования» (Geoffrey James, The Tao of Programming). Каждая строчка из нее достойна цитирования, но я ограничусь лишь одной выдержкой: «Программа должна следовать "закону наименьшего удивления". Что это за закон? Все просто: программа должна отвечать пользователю так, чтобы вызывать у него как можно меньше удивления». (Конечно, если речь идет об интерпретаторе языка, то пользователем является программист.)

Не знаю, Джеймс ли придумал термин «закон наименьшего удивления», но я впервые узнал его из упомянутой книги. Этот закон хорошо известен и часто цитируется в сообществе пользователей Ruby. Правда, обычно его называют «принципом наименьшего удивления» (Principle of Least Surprise, POLS). Лично я упрямо придерживаюсь акронима LOLA — Law of Least Astonishment.

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

Конечно, одна проблема остается: разные люди удивляются разным вещам; не существует всеобщего согласия о том, как «должен» вести себя объект или метод. Но мы можем стремиться быть последовательными и находить веские обоснования принимаемым проектным решениям, а каждый человек должен тренировать собственную интуицию.

Кстати, Мац как-то заметил, что «принцип наименьшего удивления» должен относиться и к нему как к дизайнеру. Чем больше ваше мышление походит на его, тем меньше удивления будет вызывать Ruby. И смею уверить, подражание Мацу большинству из нас пойдет только на пользу.