![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Адский холивар
На тему "зачем нужен reflection и метаданные, если все можно писать вручную в коде".
Это пиздец, граждане. Я подозревал, что есть люди абстрагированные от мира реальной разработки и его проблем, но не подозревал, что настолько.
ссылко 1
ссылко 2
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
zabivator и второй персонаж оттуда усиленно убеждают, что ничего этого не нужно, а потом комментом ниже предлагают решения, которые являются ничем иным, как закатом солнца реализацией рефлекшена и метаданных вручную.
Я тут сижу, думаю, как бы это вообще всю эту метаданную жопу вынести на уровень модели и генерить из нее код, затем мержить с написанной вручную нетривиальностью и таким образом избавится от 1000-кратного писания одного и того же кода "база данных->sqlreader->поле объекта->веб-сервис->поле объекта на клиенте->элемент гуя->поле объекта->веб-сервис->поле объекта->sqlparameter->база данных". Потому что у меня за пару дней может база на 3-5 таблиц увеличится, в каждой по 10-20 полей, и это все надо выставить юзеру на редактирование, да еще красиво, с подписями на трех разных языках и чтобы работать можно было и с мыши и с клавиатуры и чтобы не тормозило, и чтобы неправильных данных при всем желании запилить нельзя было.
А народу пофег, как я посмотрю. Нужно конфиг руками читать - читают. Понадобится изменения сделать - будут дописывать case в switch или там if/else и молиться, что остальные команды разработчиков код сохранения не поломают, и что имена будут одинаковые.
Видимо, я что-то в современной софторазработке и принятой в ней эффективности работы отдельных разработчиков не понимаю.
Это пиздец, граждане. Я подозревал, что есть люди абстрагированные от мира реальной разработки и его проблем, но не подозревал, что настолько.
ссылко 1
ссылко 2
zabivator и второй персонаж оттуда усиленно убеждают, что ничего этого не нужно, а потом комментом ниже предлагают решения, которые являются ничем иным, как Я тут сижу, думаю, как бы это вообще всю эту метаданную жопу вынести на уровень модели и генерить из нее код, затем мержить с написанной вручную нетривиальностью и таким образом избавится от 1000-кратного писания одного и того же кода "база данных->sqlreader->поле объекта->веб-сервис->поле объекта на клиенте->элемент гуя->поле объекта->веб-сервис->поле объекта->sqlparameter->база данных". Потому что у меня за пару дней может база на 3-5 таблиц увеличится, в каждой по 10-20 полей, и это все надо выставить юзеру на редактирование, да еще красиво, с подписями на трех разных языках и чтобы работать можно было и с мыши и с клавиатуры и чтобы не тормозило, и чтобы неправильных данных при всем желании запилить нельзя было.
А народу пофег, как я посмотрю. Нужно конфиг руками читать - читают. Понадобится изменения сделать - будут дописывать case в switch или там if/else и молиться, что остальные команды разработчиков код сохранения не поломают, и что имена будут одинаковые.
Видимо, я что-то в современной софторазработке и принятой в ней эффективности работы отдельных разработчиков не понимаю.
no subject
Но все это имеет смысл обсуждать применительно к какой-то конкретной задаче.
no subject
ПИСАТЬ САМОМУ DSL???
Нет, ну вы кадры, ей-Богу.
> писанины выйдет сильно меньше, чем при наличии этого самого "рефлекшена", который
...который Вы не умеете готовить.
Ваше заявление весьма пионерское: "во всех случаях я лучший." Даже детсад какой-то.
Видите ли, люди применяют и то, и то (hibernate/jaxb/jsp). Очевидно, что представление в виде исходного кода частей, которые человек не увидит -- в общем случае лишнее и неэффективное. И более того, программировать данный этап сборки руками -- зло. Можете в голове заменить рефлекшен написанием кода самой виртуальной машиной -- что изменится?
no subject
С чего вы взяли - это раз? У нас сейчас серверное ПО на эрланге, который один весь сплошной рефлекшн.
И вы уверены, что вы вообще со мной спорите? Это два. Я не имею ничего против рефлекшена, ващета. И если поднятся выше по треду, это видно. Может, как-то умерить градус дискуссии?
И три - какие проблемы писать руками DSL? Это делается очень быстро и просто. Это три.
И четыре - покажите, пожалуйста, где я пишу "во всех случаях я лучший." ?
no subject
НАсколько понимаю, это утверждение, неявно претендующее на универсальность. Что всегда кодогенерация короче. Что Вы так умеете делать. Что люди ошибаются, и делают неэффективные подходы с использованием рефлекшена.
В общем случае надо мерять и прикидывать. У кодогенерации есть много подводных камней.
> какие проблемы писать руками DSL? Это делается очень быстро и просто
Хотелось бы вообще не писать.
Что-то мне подсказывает, что с времён yacc написание языков -- непростое предприятие: не дай Бог где-нибудь вкрадётся ошибка. (Хотя, конечно, у Настоящих Адептов ошибок не бывает. По определению.)
no subject
с одной стороны, я пропустил слово "возможно", отвлекшись. С другой стороны, даже если есть код, использующий рефлекшн, его можно как-нибудь сократить, используя кодогенерацию, так что утверждение не совсем неверно. Ну и по опыту из маленькой модели можно нагенерить кучу кода, типа мэппинга атрибутов на колонки базы или базового CRUD. Если не ошибаюсь, рефлекшн тут не совсем помощник, и это частенько решается инструментированием байткода, что как бы кодогенерация и есть.
Ну ошибка как вкрадется, так и исправится, в чем проблема? Можно подумать рефлекшн каким-то образом исключает ошибки.
no subject
Сравнительно с генерацией исходного кода и его компиляцией -- да, устранение промежуточного звена уменьгшает возможность ошибок.
> с одной стороны, я пропустил слово "возможно", отвлекшись
Принято. Часто с рефлекшеном бывает и довольно корявый код.
> инструментированием байткода, что как бы кодогенерация и есть.
Ну так рефлекшен в Яве как раз кодогенерацией и реализован. Во ирония судьбы.
no subject
По иронии судьбы, в Алкателе огромный пласт кода на Яве генерируется из DSL'ей.
И там этому подходу лет уже под десяток будет.
Reflection подразумевает обработку структур языка средствами языка.
Т.е. reflection - eDSL.
Плюсовые шаблоны - тоже eDSL
Кодогенерация - это DSL. Это означает, что на входные данные и реализацию генератора не накладывается ограничений, что есть в reflection. Накладываются другие - меппинг семантики и типов не даётся бесплатно, его приходится продумывать. Но с другой стороны, на него можно положить болт, и оставить верификацию сгенерированного кода на совесть компилятора и/или интерпретатора целевого языка.
no subject
И это очень хорошо. Нет "импеданс мисматч".
> Это означает, что на входные данные и реализацию генератора не накладывается ограничений, что есть в reflection.
А вот это мрак и ужас. Когда программа на одном языке начинает обрабатываться другим... Вспоминается, как запускали написанную под ДОС MS-фортран-программу через компиляцию в Си на солярисе. Конечно не завелась, и пришлось vi делать тупые переделки пару часов.
В конце концов баги будут в кодогенераторах, и вот тут-то я злорадно посмеюсь над попытками найти и исправить баги. То ли в оригинальной программе бага, то ли в генераторе, то ли в целевом компиляторе. Шайтан!!!
no subject
no subject
no subject
no subject
no subject
bizon/yacc/parsec + llvm/.net/java + два дня = DSL
no subject
1) Адекватное проектирование даже простых вещей занимает от недели до месяца. А тут язык - вещь очевидно сложная
2) Реализация, отладка и иногда возврат и перепроектирование - еще неделю-две.
3) Интеграция этого с остальными процессами разработки. Вкрутить очередной тул в процесс билда и тестирования.
4) Документация
За два дня можно нахачить только поделку. А нормальная реализация займет столько времени, что проще будет на обычном языке все сделать, заодно, не будет проблем "где брать людей, которые смогут это понять".
no subject
- сегодня парсим текстовые файлы в оракл, средней сложности UI, 30 простых и 10 сложных бизнес-правил;
- через два месяца javascript/html/DOM, причём на уже существующих библиотеках сущетсввующее приложение, причём интеграция с САП;
- ещё через 3 месяца веб-сервисы и дот-нет клиент;
- ещё через полтора месяца другие вебсервисы.
Проекты начинаются не со спеки, прошу заметить, а со сбора требований. Юзер как правило говорит плохо, "а чего вы сами не понимаете." И кончаются изменения требований где-то за неделю до релиза, а иногда и месяц после него.
Если я на каждом проекте буду изобретать свой DSL (когда ещё нихрена не понятна постановка), отлаживать, переделывать... Это очень неэффективно. Часто копи-паста банально БЫСТРЕЕ "правильного дизайна".
В таких проектах и J2EE не особо хороша -- perl/ruby быстрее, адекватнее. Но у них и пиар хуже, и технически...
DSL хорош, когда
- задача чётко понятна (и меняется не сильно)
- времени на решение относительно дохрена (порядка месяца)
- коллеги сильны.
Да и правильно Метакласс говорит -- не дай Бог такое ядро себе к ноге привязать, не дадут отпуск ведь. ))
no subject
Т.е. от одного до нескольких квантов планирования. Времени и сил иногда он может съэкономить очень много. Иррациональный страх DSL совершенно непонятен.
"Изобретение" и корректирование DSL - это может быть путь постановки и уточнения задачи, например. Если в проекте присутствуют большое число разнородных, но зависимыз сущностей, то использования DSL для консолидации информации для них и их построения - вполне хороший выход.
no subject
Если к нему добавить инструментальные средства, обработку ошибок и прочая и прочая, то там получается как бы не полгода работы.
no subject