Человеческие языки (насколько я это всё понимаю) бывают более или менее контекстно-зависимые. Например, русское слово «смеркается», вырванное из контекста скорее всего будет значить тоже самое, что и в самом контексте. Это удобно тем, что всегда можно его однозначно перевести просто по таблице перевода, а человеку надо меньше напрягать мозг, что бы понять что оно значит. Зато это слово писателю сложнее подогнать под свои нужды и выразить с его помощью что-то новое. Английское слово “do” наоборот: само по себе мало чего значит, зато его можно использовать в окружении других слов в разнообразнейших случаях. Минус понятен: что бы понять, что оно тут значит, надо держать кучу слов в памяти, что создает сильное когнитивное сопротивление.

Если перевести всё сказанное на программирование, то получается что:

• менее контекстно-зависимые языки хуже расширяются новыми инструкциями, но проще для понимания и поиска по документации;
• более контекстно-зависимые языки лучше расширяются, но тяжелее для понимания.

Язык конфигурации postfix-а — первый вариант. Assembler — это чуть ли не предел контекстной зависимости. Хорошо бы держать всю память приложения в голове, когда на нем пишешь. Однако вполне понятно, что написать почтовый сервер на ассемблере безумно сложно, но теоретически возможно, а вот на языке конфигурации postfix-а — увы, никак.

Впрочем, столь же очевидно, что настраивать почтовый сервер лучше на нормальном языке, а не на ассемблере, или его адском порождении M4 (RIP sendmail). Связно это, как я считаю, с двумя факторами:

• меньшая контекстная зависимость языка предметной области (DSL);
• маленький размер этого DSL.

Руби предоставляет очень удобные возможности по созданию DSL-ей, например роуты в рельсах или миграции:

class CreateClubs < ActiveRecord::Migration
  def self.up
    create_table :clubs do |t|
      t.belongs_to :creator
      t.belongs_to :avatar
      
      t.string   :name
      t.text     :description

      t.timestamps
    end 
  end

  def self.down
    drop_table :clubs
  end
end

Практически ничего лишнего, не относящегося к делу. Метод string в контексте смены структуры БД делает вполне конкретную вещь, а belongs_to здесь — совершенно другое, нежели belongs_to в модели.

Чем именно руби лучше, чем использование спец-языка со спец-парсером? Тем, что всегда можно прям в миграции выполнить ещё код, который написан не на спец-языке, не на DSL. Будет огромной ошибкой думать, что «вот, этот ваш руби — лучший способ выстрелить себе в ногу». Проблема расползания кода по разным уровням логики существует давно и пока не решена. MVC — один из древних примеров решения этой проблемы: как разделять логику обработки действий пользователя (контроллер) и бизнес-логику.

У меня родилась такая мысль:

• весь код приложения пилится на какие-то декларируемые слои (представление, контроллер, сетевое взаимодействие, бизнес-логика, структура БД, мониторинг и т.п.);
• все пользовательские методы и классы маркируются, как относящиеся к какому-то из слоев;
• вызвать чужой метод можно, но это должно сопровождаться предупреждениями. Например, find_by_sql в контроллере или в шаблоне должен быть легко отслеживаемым. Таким образом на каждом стыке разных слоев возникает набор ручек, которые слой, как черный ящик, выставляет наружу, но если очень-очень нужно, то другой слой может влезть в кишки соседа. Просто это должно быть легко отслеживаемо;
• следствием этого будет то, что код становится гораздо читаемее из-за снижения размера контекста, требуемого для осмысления каждой строчки кода.

В каком году все эти мысли уже получили гораздо более четкое оформление на бумаге?