nolocky,

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

nolockyНе соглашусь ни разу. DSL в обед сто лет, но в мире true-Enterprise, Java и C# его за декораторами, фасадами, синглтонами и адаптерами вообще ни разу не видно.
Да, DSL известны давно, и давно применяются. Например, очень часто варганят собственные dsl'и в виде xml. Но такой язык ограничен синтаксисом xml и это сложно признать правильным подходом. В том-то и дело, что мейнстримовые языки не поддерживают МП. А без МП полноценный dsl не сделать.
В языках с динамической типизацией зачастую можно реализовать довольно внятный dsl, но сама природа языка не позволяет сделать качественную проверку в компайл-тайме, так что эта идея идёт лесом.

nolockyМетапрограммирование - в каком ключе-то? Генерация модели данных в БД из классов, что там еще в ходу?
Распространённое (ошибочное) мнение, что МП применяется только для генерации одной модели из другой.
Например, в C# есть ключевые слова using и event. В языках, где таких нет, приходится писать приличный кусок кода (что становится паттерном). В языке Nemerle, где изначально таких ключевых слов нет, были написаны макросы, и они появились! То есть язык избавился от ставших ненужными паттернов.

Ещё пример: в C# постоянно приходится вручную писать реализацию интерфейса INotifyPropertyChanged. Сотни свойств - сотни реализаций! С ума сойти... Это настолько утомляющее действие, что существуют и code snippet'ы для INotifyPropertyChanged (но это лишь текстовая вставка), и реализации этого интерфейса в AOP-фреймворках, в частности, в PostSharp (но часто возникают проблемы с отладкой, с обфускацией и пр.)
Между тем, в Nemerle пишем макрос, после чего достаточно на класс навесить атрибут [ImplementsNotifyPropertyChanged], после чего все свойства автоматические реализуют этот интерфейс!

nolockyБолее того, любой DSL - это сразу антипаттерн и потому должен сгореть в аду (как самый близкий пример - SQL, должен быть замочен как минимум Hibernate, если не LINQ).
Ой-вэй! В том-то и дело, что SQL - неполноценный DSL. Неполноценный в том смысле, что он не встроен в основной язык программирования. А LINQ - встроен.
Но что делать, если в нашем языке linq'а нет? И нет метапрограммирования? Увы, остаётся лишь жрать кактус. Придётся по старинке писать sql в строковых литералах. В итоге ни подсветки синтаксиса, ни автоматического форматирования, ни проверки на этапе компиляции, ни подсказок от IDE...
А вот если в языке есть МП, то можно написать любой (теоретически) dsl. При этом будет и подсветка синтаксиса и все прочие плюшки. Чтобы не быть голословным, в языке Nemerle это реализуется.

Как я уже сказал, потребность в dsl очень высока. Например, регулярные выражения - это dsl разбора текста. Зачастую очень удобно. Но как записываются сами регулярки в коде программы? В виде текстовых литералов. Понять чужую регулярку очень сложно, потому что нет подсветки синтаксиса, нет форматирования, нет подсказок IDE... Разбор самих регэксов происходит в рантайме, так что об ошибке (банальной опечатке) узнаем лишь при падении программы. Напротив, при наличии МП можно сделать макрос, который будет парсить и подсвечивать регэкс сразу по мере набора в IDE.

Банальные строки форматирования - это тоже микро-DSL. Типа prinft("Name: %s", str). Опять же, они задаются в виде литералов и не проверяются на этапе компиляции в большинстве мэйнстримовых языков. Что делать? Жрать кактус!
Конечно, есть такие решения, как Решарпер: он, в частности, проверяет правильность строк формата. И это доказывает, что нормальные dsl востребованы.
А в том же Nemerle (да обратит Microsoft свой взгляд на него!) реализован макрос printf, в котором проверяется в компайл-тайме как строка формата, так и тип параметров.

sphinx_mvpetalvikПридётся по старинке писать sql в строковых литералах. В итоге ни подсветки синтаксиса, ни автоматического форматирования, ни проверки на этапе компиляции, ни подсказок от IDE...Вообще-то, это сильно зависит от IDE...
Согласен. Некоторые IDE имеют неслабый интеллект, или приобретают его от дополнений, наподобие Resharper'а.
Однако, меня всегда раздражало, что приходится использовать какие-то сторонние приблуды, в то время как могучий компилятор языка бездельничает. А ведь именно компилятор по определению абсолютно точно разбирает любые выражения языка. Увы, без МП мы не можем его задействовать.
И ещё дело в том, что если разработчики IDE или дополнения к ней не реализовали какую-то проверку, то мы не сможем сделать её сами. Конечно, иногда дополнение можно написать самому, но это почти МП, только присобаченное сбоку.
Греет душу вылупляющийся Roslyn в дотнете. Через несколько лет у нас наверняка будет полноценное метапрограммирование в мэйнстримовом языке (C#).

nolocky упаковывать .sql файлы в ресурсы (.res) как шаг компиляции и редактировать из прямо в Visual Studio/Eclipse/Netbeans/whatewer else

Это охренительная фича, если она реализована в IDE. А если нет? Без МП, всё - приплыли.
К тому же сам пишешь, что sql не комильфо.

nolockyПишется утилитка, которая берет на входе любой файл, .SQL, да хоть какой, и преобразовывает его в .csharp, .java, .cpp, во что угодно
Это и есть метапрограммирование.
Однако, согласись, что встроенная поддержка в язык гораздо удобнее, чем использование сторонних утилит, конфигов (указать build step) и прочего.

nolockyПросто это вы тут сирые и убогие начали тянуть жалобную песню про упаковку SQL в строки, а я же макнул вас в ваше невежество
Слышь, человече, я давал поводы для хамства?

nolockyпоказав, что SQL тексты можно хранить в отдельных .SQL файлах
Ну надо же, а мужики не знали!


Напомню мою основную мысль: метапрограммирование позволяет (почти) полностью избавиться от паттернов.