Адский холивар

[metaclass]

На тему "зачем нужен reflection и метаданные, если все можно писать вручную в коде".
Это пиздец, граждане. Я подозревал, что есть люди абстрагированные от мира реальной разработки и его проблем, но не подозревал, что настолько.

ссылко 1
ссылко 2

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

Я тут сижу, думаю, как бы это вообще всю эту метаданную жопу вынести на уровень модели и генерить из нее код, затем мержить с написанной вручную нетривиальностью и таким образом избавится от 1000-кратного писания одного и того же кода "база данных->sqlreader->поле объекта->веб-сервис->поле объекта на клиенте->элемент гуя->поле объекта->веб-сервис->поле объекта->sqlparameter->база данных". Потому что у меня за пару дней может база на 3-5 таблиц увеличится, в каждой по 10-20 полей, и это все надо выставить юзеру на редактирование, да еще красиво, с подписями на трех разных языках и чтобы работать можно было и с мыши и с клавиатуры и чтобы не тормозило, и чтобы неправильных данных при всем желании запилить нельзя было.

А народу пофег, как я посмотрю. Нужно конфиг руками читать - читают. Понадобится изменения сделать - будут дописывать case в switch или там if/else и молиться, что остальные команды разработчиков код сохранения не поломают, и что имена будут одинаковые.

Видимо, я что-то в современной софторазработке и принятой в ней эффективности работы отдельных разработчиков не понимаю.

Comments

[zamotivator.livejournal.com]

ПИСАТЬ САМОМУ DSL???
bizon/yacc/parsec + llvm/.net/java + два дня = DSL

[metaclass.livejournal.com]

Я тебе точно скажу: за два дня ты напишешь только DSL, который работу упростит на ближайшую неделю, а усложнит тебе и тем, кто придет после тебя - на 10 лет вперед.

1) Адекватное проектирование даже простых вещей занимает от недели до месяца. А тут язык - вещь очевидно сложная
2) Реализация, отладка и иногда возврат и перепроектирование - еще неделю-две.
3) Интеграция этого с остальными процессами разработки. Вкрутить очередной тул в процесс билда и тестирования.
4) Документация

За два дня можно нахачить только поделку. А нормальная реализация займет столько времени, что проще будет на обычном языке все сделать, заодно, не будет проблем "где брать людей, которые смогут это понять".

[volodymir-k.livejournal.com]

Видите ли, мы с Вами в немного разных бизнесах работаем. У нас разные временнЫе рамки. Скажем, Вы можете себе позволить одной проблематикой, достаточно чёткой и понятной, заниматься и год, и два, и три. А вот если так:
- сегодня парсим текстовые файлы в оракл, средней сложности UI, 30 простых и 10 сложных бизнес-правил;
- через два месяца javascript/html/DOM, причём на уже существующих библиотеках сущетсввующее приложение, причём интеграция с САП;
- ещё через 3 месяца веб-сервисы и дот-нет клиент;
- ещё через полтора месяца другие вебсервисы.
Проекты начинаются не со спеки, прошу заметить, а со сбора требований. Юзер как правило говорит плохо, "а чего вы сами не понимаете." И кончаются изменения требований где-то за неделю до релиза, а иногда и месяц после него.

Если я на каждом проекте буду изобретать свой DSL (когда ещё нихрена не понятна постановка), отлаживать, переделывать... Это очень неэффективно. Часто копи-паста банально БЫСТРЕЕ "правильного дизайна".
В таких проектах и J2EE не особо хороша -- perl/ruby быстрее, адекватнее. Но у них и пиар хуже, и технически...

DSL хорош, когда
- задача чётко понятна (и меняется не сильно)
- времени на решение относительно дохрена (порядка месяца)
- коллеги сильны.

Да и правильно Метакласс говорит -- не дай Бог такое ядро себе к ноге привязать, не дадут отпуск ведь. ))

[dmzlj.livejournal.com]

DSL который генерирует просто код на высокоуровневом ЯП делается за день, в сложных случаях - за дни. При наличии инструментов, конечно.

Т.е. от одного до нескольких квантов планирования. Времени и сил иногда он может съэкономить очень много. Иррациональный страх DSL совершенно непонятен.

"Изобретение" и корректирование DSL - это может быть путь постановки и уточнения задачи, например. Если в проекте присутствуют большое число разнородных, но зависимыз сущностей, то использования DSL для консолидации информации для них и их построения - вполне хороший выход.

[metaclass.livejournal.com]

За день делается DSL, понятный только его автору.
Если к нему добавить инструментальные средства, обработку ошибок и прочая и прочая, то там получается как бы не полгода работы.

[dmzlj.livejournal.com]

Я вот ни разу не видел DSL со средствами отладки. А обработка ошибок - это обработка ошибок. Например, типизация + выброс и обработка исключений с выдачей сообщений.