@Kaaboeld как я уже написал - понимание языка происходит не от того, что тебе показали пару фич, а от того, что ты самостоятельно решаешь разные задачи, размышляешь, какой бы инструмент больше подошёл в каждом случае и сравниваешь свои размышления с _уже_накопленными_ знаниями и опытом работы с конкретным языком или языками. А так автор просто_слышал о руби и пришёл сюда поговорить Ну вот и поговорил.
@Kaaboeld сам язык (я именно про язык, не про экосистему, не про библиотеки, не про рынок труда) очень гибок, позволяет вводить собственные уровни абстракций для собственных задач. Это то, что называется eDSL. Достигается это за счёт нескольких языковых особенностей, например, за счёт блоков. Блок - это кусок кода, который можно передать как аргумент куда-либо и выполнить в том контексте, где он был определён(!). Благодаря блокам можно делать такие штуки:
database.transaction do
// some queries
end
Ещё одна особенность - любой код всегда возвращает значение. Сколько раз вы хотели сделать так a = if (...) {...} else {...}
или
a, b = switch(...)
case 1: ... break;
case 2: ... break;
case N: ... break;
default: ...
endswitch;
это простая и естественная форма записи вместо набившего всем оскомину присваивания значения в каждом case. То есть, в руби можно работать намного ближе к декларативному стилю даже не используя возможности метапрограммирования. Ещё раз подчеркну, эти черты не связаны с экосистемой или рынком труда, а характеризуют руби как самостоятельный инструмент.
динамическое создание классов и eval в том числе оправданы лишь в одном случае - когда а) количество классов заранее неизвестно и б) все они подобны. ни таблицы базы данных, ни ваши заказчики не удовлетворяют этим условиям. хардкод будет намного удобнее как в плане отслеживания изменений, так и в плане дебага.
@IkaR49 то есть ты хочешь ввести некую промежуточную абстракцию для каждого url в виде класса Page, и наследовать от неё классы по типу задач? например site.com/images/all создаёт класс Images, инстанс от него и затем вызывает метод all, который дёргает таблицу images в базе?
@IkaR49 метапрограммирование - палка о двух концах. с одной стороны оно делает код более гибким, с другой - менее читабельным. когда долго поддерживаешь проект все эти финты ушами надоедают, хочется простоты и понятности. лишний раз написать класс руками - не проблема. ну и плюс евал - всегда оверхед по производительности.
