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

L>В основе проблем лежат:
L>1) Преувеличение мыслительных способностей программистов, а и людей вообще. В реальности они довольно ограничены.

Так почему вообще кто-то должен рассчитывать на ограниченных? Только то, что ограниченные обезьянки стоят дёшево ещё не делает категорическим императивом требование угождать обезьянкам. Есть (и прекрасно себя зарекомендовали) бизнес-модели, построенные на привлечении самых лучших и самых дорогостоящих кадров. Да, в программировании это пока что редкость, но в других отраслях (например, у банкиров) это норма. Так почему, с какой такой радости IT-индустрия перед обезьянками обязана "ку" делать?!?

L>2) Преувеличение роли логического, рационального мышления. Человек мысли иррационально, эмоционально (увы и ах).

И метапрограммирование этому способу мышления очень даже способствует, между прочим.

L>3) Ошибочная посылка: язык программирования служит общения к компьютером. При современном развитии вычислительных сред, язык программирования служит прежде всего для накопления знаний и общения между разработчиками.

Верно. И тут как раз и нужен язык с неограниченным сверху уровнем абстракций. Язык, который можно было бы сделать близким к естественному человеческому языку в каждой из предметных областей.

L>Подробно о проблемах:
L> Ответ: да, выучат, если захотят учить язык с "предательским" (эмоциональная реакция!) синтаксисом, но удовольствия не получат (опять эмоции, но на них держится мир).

Тогда и синтаксис C# после Жабки — "предательство".

L>2) Программистам не хватает не "мощности", которую вполне можно упаковать в библиотеки и API,

НЕЛЬЗЯ. Невозможно СЕМАНТИЧЕСКУЮ сложность засунуть в API. Принципиально!!!


L> Простота и лаконичность — вот чего ждут разработчики.

И как её без метапрограммирования добиться?


L>3) Метапрограммирование очень существенно усложняет понимание кода человеком, в виду ограниченности мыслительных возможностей последнего (причем подвижек с этим в обозримом будущем не ожидается).

Чушь. Метапрограммирование, употреблённое к месту, позволяет очень легко разделить степени минимально допустимого понимания. Прикладник будет читать и понимать терминологию и семантику своей предметной области, и плевать ему на то, как оно внутри сделано. Разработчик DSL-ей будет читать код макросов и понимать всякие там оптимизации, не зная ни шиша о предметной области (ни его это дело). Программист системного уровня будет думать про файлики с сокетами, и плевать ему на DSL-ы и на предметную область и тем более на всякие там GUI.

L> И это очень серьезная причина ограничивать использование средств метапрограммирования, не смотря на их потенциальную силу, не зря в современных успешных языках (C++, C# 2.0) оно сведено к минимуму (generic-и), а то и вовсе отсутствует (Java).

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

L> А ведь мир видал препроцессоры куда круче Nemerle-вского, в PL/I язык препроцессора по мощи не многим уступал самому целевому языку. Похоже, использование generic-ов (причем без typedef!) и Reflection вполне достаточная доза метапрограммирования в современных языках.

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

L>4) Язык реализующий несколько парадигм (процедурная, функциональная, декларативная) видимо предполагает их интенсивное совместное использование, что опять таки является непосильной (увы) нагрузкой для программиста.

Не программиста, а обезьянку. Обезьянок надо уволить и никогда больше на них не рассчитывать. Пусть улицы подметают. Бизнес-модель "шапками нах закидаем!" пора отправить на помойку истории.