Адский холивар
На тему "зачем нужен reflection и метаданные, если все можно писать вручную в коде".
Это пиздец, граждане. Я подозревал, что есть люди абстрагированные от мира реальной разработки и его проблем, но не подозревал, что настолько.
ссылко 1
ссылко 2
zabivator и второй персонаж оттуда усиленно убеждают, что ничего этого не нужно, а потом комментом ниже предлагают решения, которые являются ничем иным, как закатом солнца реализацией рефлекшена и метаданных вручную.
Я тут сижу, думаю, как бы это вообще всю эту метаданную жопу вынести на уровень модели и генерить из нее код, затем мержить с написанной вручную нетривиальностью и таким образом избавится от 1000-кратного писания одного и того же кода "база данных->sqlreader->поле объекта->веб-сервис->поле объекта на клиенте->элемент гуя->поле объекта->веб-сервис->поле объекта->sqlparameter->база данных". Потому что у меня за пару дней может база на 3-5 таблиц увеличится, в каждой по 10-20 полей, и это все надо выставить юзеру на редактирование, да еще красиво, с подписями на трех разных языках и чтобы работать можно было и с мыши и с клавиатуры и чтобы не тормозило, и чтобы неправильных данных при всем желании запилить нельзя было.
А народу пофег, как я посмотрю. Нужно конфиг руками читать - читают. Понадобится изменения сделать - будут дописывать case в switch или там if/else и молиться, что остальные команды разработчиков код сохранения не поломают, и что имена будут одинаковые.
Видимо, я что-то в современной софторазработке и принятой в ней эффективности работы отдельных разработчиков не понимаю.
Это пиздец, граждане. Я подозревал, что есть люди абстрагированные от мира реальной разработки и его проблем, но не подозревал, что настолько.
ссылко 1
ссылко 2
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Я тут сижу, думаю, как бы это вообще всю эту метаданную жопу вынести на уровень модели и генерить из нее код, затем мержить с написанной вручную нетривиальностью и таким образом избавится от 1000-кратного писания одного и того же кода "база данных->sqlreader->поле объекта->веб-сервис->поле объекта на клиенте->элемент гуя->поле объекта->веб-сервис->поле объекта->sqlparameter->база данных". Потому что у меня за пару дней может база на 3-5 таблиц увеличится, в каждой по 10-20 полей, и это все надо выставить юзеру на редактирование, да еще красиво, с подписями на трех разных языках и чтобы работать можно было и с мыши и с клавиатуры и чтобы не тормозило, и чтобы неправильных данных при всем желании запилить нельзя было.
А народу пофег, как я посмотрю. Нужно конфиг руками читать - читают. Понадобится изменения сделать - будут дописывать case в switch или там if/else и молиться, что остальные команды разработчиков код сохранения не поломают, и что имена будут одинаковые.
Видимо, я что-то в современной софторазработке и принятой в ней эффективности работы отдельных разработчиков не понимаю.
no subject
САМОМУ??? В 2009 ГОДУ???
no subject
no subject
Для, скажем, скриптинга или сериализации, или вообще "конфигуратора" всё наоборот: сначала пишут код, а потом думают, как прикрутить фичи.
no subject
no subject
О! Найден Адепт Единственно Работающей Методологии!
Быстрее пишите книгу, все остальные 100500 ошибались!
> А уж по модели сделать метаинформацию, кодогенерацию, и автоматическое создание дескриптора веб-сервиса — это уже не задействующие мозг трансформации.
Но их надо писать, не так ли?
Если проделать в мозгу упражнение, поняв, что рефлекшен это как раз и есть кодогенерация на рантайме, причём уже сделанная -- в чём останется возражение?
Давайте теперь отвлечёмся от абстракций, и расскажите мне, как в уже работающую программу на Си мне добавить сервер мониторинга, удалённых вызовов и скриптинг. Желательно строк в 100-200.
no subject
Быстрее пишите книгу, все остальные 100500 ошибались!
Ты вот ёрничаешь, а книга будет к вечеру готова (в моём журнале).
Если проделать в мозгу упражнение, поняв, что рефлекшен это как раз и есть кодогенерация на рантайме, причём уже сделанная -- в чём останется возражение?
Where do I begin? Прочитаешь в книге.
Давайте теперь отвлечёмся от абстракций, и расскажите мне, как в уже работающую программу на Си мне добавить сервер мониторинга, удалённых вызовов и скриптинг. Желательно строк в 100-200.
Откуда Си взялся? Я вообще-то пропагандирую высокоуровневые решения, а не ассемблер переносимый.
no subject
Я даже предскажу её будущее с 95% вероятностью. Её прочтёт человек 20 программеров с лишним временем, который они забивают всяким окамлом-хаскелом без всякой практики, они скажут: о круто!, почерпнут пару идей уровня МИТ-2000, и будут дальше заниматься полунаучной туфтой.
> Откуда Си взялся? Я вообще-то пропагандирую высокоуровневые решения
Я вообще-то ценю собеседника, который может ответить на вопрос, невзирая на мелочи. Хорошо, пусть на паскакале-эйфеле-эрланге или чём там адепты с Серебряной Пулей пишут. Как мне добавить. В работающую. В смысле готовую, отлаженную, можно даже в не запущенную.
no subject
Нострадамус хренов.
Как мне добавить. В работающую.
На эрланге добавить RPC можно даже в работающую программу. Штатными средствами. За 20-30 строк, а не за 100-200.
Каким именно образом можно добавить, говорить не буду, потому что не ценю собеседника, который не ценит моё время.
(no subject)
(no subject)
no subject
no subject
Насколько понимаю, спокойная реакция на 40-летней давности идею "сначала давайте подумаем" -- зевок и плевок.
Заранее думать каждый дурак сможет. А ты попробуй 5 фич в день для бизнеса выдай. И чтобы всё работало.
(no subject)
(no subject)
no subject
Но все это имеет смысл обсуждать применительно к какой-то конкретной задаче.
no subject
ПИСАТЬ САМОМУ DSL???
Нет, ну вы кадры, ей-Богу.
> писанины выйдет сильно меньше, чем при наличии этого самого "рефлекшена", который
...который Вы не умеете готовить.
Ваше заявление весьма пионерское: "во всех случаях я лучший." Даже детсад какой-то.
Видите ли, люди применяют и то, и то (hibernate/jaxb/jsp). Очевидно, что представление в виде исходного кода частей, которые человек не увидит -- в общем случае лишнее и неэффективное. И более того, программировать данный этап сборки руками -- зло. Можете в голове заменить рефлекшен написанием кода самой виртуальной машиной -- что изменится?
no subject
С чего вы взяли - это раз? У нас сейчас серверное ПО на эрланге, который один весь сплошной рефлекшн.
И вы уверены, что вы вообще со мной спорите? Это два. Я не имею ничего против рефлекшена, ващета. И если поднятся выше по треду, это видно. Может, как-то умерить градус дискуссии?
И три - какие проблемы писать руками DSL? Это делается очень быстро и просто. Это три.
И четыре - покажите, пожалуйста, где я пишу "во всех случаях я лучший." ?
no subject
НАсколько понимаю, это утверждение, неявно претендующее на универсальность. Что всегда кодогенерация короче. Что Вы так умеете делать. Что люди ошибаются, и делают неэффективные подходы с использованием рефлекшена.
В общем случае надо мерять и прикидывать. У кодогенерации есть много подводных камней.
> какие проблемы писать руками DSL? Это делается очень быстро и просто
Хотелось бы вообще не писать.
Что-то мне подсказывает, что с времён yacc написание языков -- непростое предприятие: не дай Бог где-нибудь вкрадётся ошибка. (Хотя, конечно, у Настоящих Адептов ошибок не бывает. По определению.)
no subject
с одной стороны, я пропустил слово "возможно", отвлекшись. С другой стороны, даже если есть код, использующий рефлекшн, его можно как-нибудь сократить, используя кодогенерацию, так что утверждение не совсем неверно. Ну и по опыту из маленькой модели можно нагенерить кучу кода, типа мэппинга атрибутов на колонки базы или базового CRUD. Если не ошибаюсь, рефлекшн тут не совсем помощник, и это частенько решается инструментированием байткода, что как бы кодогенерация и есть.
Ну ошибка как вкрадется, так и исправится, в чем проблема? Можно подумать рефлекшн каким-то образом исключает ошибки.
no subject
Сравнительно с генерацией исходного кода и его компиляцией -- да, устранение промежуточного звена уменьгшает возможность ошибок.
> с одной стороны, я пропустил слово "возможно", отвлекшись
Принято. Часто с рефлекшеном бывает и довольно корявый код.
> инструментированием байткода, что как бы кодогенерация и есть.
Ну так рефлекшен в Яве как раз кодогенерацией и реализован. Во ирония судьбы.
(no subject)
(no subject)
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)