> За этим есть реальный логический смыслЛогического смысла нет. Но почему обязательно смысл должен быть логическим? Ты никогда не задумывался о том, что задумка программиста и код, которым он реализует задумку -- это разные вещи? Так же, как допустим, мысль у тебя в голове, и слова которыми ты мысль выражаешь -- это разные вещи. Когда ты читаешь код, ты видишь код, но чтобы с кодом осмысленно работать, нужно видеть за кодом задумку, которая его породила. Так же как, участвуя в разговоре, надо работать не со словами, а со смыслом, которые эти слова пытаются передать.
Но теперь прикинь, заглядываешь ты код и видишь:
switch(o->type) {
// и тут пара сотня case'ов
}
С точки зрения синтаксиса -- это просто switch, с точки зрения процессора -- это jmp-table. Но с точки зрения задумки, очевидно, что это наколенный ООП, с динамическим полиморфизмом организованным посредством enum'а и switch'а по нему. Тот же ООП можно было бы реализовать при помощи virtual метода в o. Ту же самую задумку, можно реализовать другим способом. И в то же время, используя тот же самый способ (switch) можно реализовать совершенно другую задумку, которая никакого отношения к ООП не имеет.
Вдумайся в это, есть пространство идей, есть множество всех возможных кусков кода. Твоя голова сопоставляет идеям куски кода, и кускам кода идеи, то есть реализует, говоря математическим языком, отображение одного в другое. Если тебе хочется не просто теоретически эту мысль уловить, а практически посмотреть, то я б рекомендовал покодить на ассемблере, и почитать код на ассемблере. Ты увидишь, как твоя голова, со временем, начнёт выдирать из списка инструкций некоторые, и такая "о, push ebp/mov ebp esp -- это создание стекового фрейма". Или mov [ebp+4], 5: это же в переменную на стеке кладётся 5. То есть, твоя голова начнёт сложным образом дешифровывать ассемблерный код, и видеть идеи за кодом. Со временем она начнёт видеть всё более и более сложные паттерны и опознавать их.
Но это иногда всё равно даётся крайне сложно. Зная это, опытные программисты пишут код так, чтобы из него легко можно было бы вывести идею, которая код породила. Когда им это не удаётся, они дополняют код комментариями. Но даже комментарии не всегда решают проблему -- они многословны, неформализованны, имеют тенденцию со временем расходится с кодом по сути, потому что компилятор их игнорирует, и вообще комменты -- это сакс, это костыль, подпирающий ущербность языка программирования.
В большинстве случаев же, опытным программистам удаётся писать понятный код. Как они этого достигают? А это сложная тема, которая, я подозреваю, граничит с психолингвистикой, с тем как человеческие мозги обрабатывают речь. Но как бы там ни было, напрашивается рождение идеи напихивания в язык много разных способов написать один и тот же код, с тем чтобы выбором способа можно было бы намекать на идею, породившую этот код. В этом направлении развития языков программирования сильно отличился Ларри Уолл, который запилил Perl. Что любопытно, Ларри ведь по образованию лингвист, и он получал образование в надежде найти язык без письменности и запилить к нему письменность. С этим не сложилось, поэтому он запилил Perl. Но я отвлёкся. Так вот, Ларри запиливал Perl с явно высказанной идеей о том, что в Perl'е всё что угодно может быть сделано несколькими способами. И слова о выразительности языка тоже звучали. Я не слышал правда, чтобы он говорил о той выразительности, к которой я выше подводил, но подозреваю, что речь именно о ней.
Так вот ruby можно рассматривать, как дальнейшие исследования в том же направлении, просто в другом синтаксисе, и разработчики, мне кажется, более конкретные идеи имеют в виду, когда дают специальные способы для их записи.
Насколько этот подход хорош или плох -- сложно сказать. Я не настолько знаю ruby, чтобы оценить работает ли это в нём, но в perl'е это не сработало так, потому что программисты на perl не думали о том, как они потом будут читать свой код, и лепили его первым пришедшим на ум способом, в результате чего, читаемость программ не повышалась, а снижалась.
