metaclass | В Советской Белоруссии SQL разжигает айседа

В Советской Белоруссии SQL разжигает айседа

http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.

Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).

Flat | Top-Level Comments Only

Это вы к чему? Основная цель программиста в любом случае написать ПО которое автоматизирует тот или иной аспект.

Автоматизирует аспект задачи или автоматизирует процесс написания автоматизации?
ОРМ - это больше походит на второе.

ORM это как раз второе. Часто бывает ситуация нужно вчера. И ORM позволяет это делать быстро и часто сводится к добавить поле в Entity ORM

Мой опыт с автоматизаторами автоматизации говорит о том что разборки с тем что же оно там наавтоматизировало и как побороть вот такое его поведение что бы сделать так как я хочу занимает гораздо больше времени чем тупо набить все руками. Это примерно то же самое как в спешке ехать пытаясь сократить дорогу - всегда выходит дольше чем ехать как обычно :)

Мой опыт с автоматизаторами автоматизации говорит о том что разборки с тем что же оно там наавтоматизировало и как побороть вот такое его поведение что бы сделать так как я хочу занимает гораздо больше времени чем тупо набить все руками.

Документацию читать не пробовали? Вы или работали с каким-то очень кривым ORM или не читали документацию. Если бы я лабал то количество кода которое я банально генерирую по РСУБД, то я бы конкретно утомился.

Реалии таковы что документация либо отсутствует либо там описаны элементарные вещи а все остальное - копай на примерах и на собственных шишках + лазай по чужому коду и смотри что они там понаписали. Нафиг такое щастье. Самому бывает быстрее написать чем в чужом разобраться.

на делфи там нихуя нет а кроме делфи эта амёба нихуя не знает

у делфи во время ее популярности была ровно та же проблема что у php это пропаганда говнокода. Тяп-ляп готово. А что надо еще о архитектуре думать вспоминали когда такого говна было дохуя.

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

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

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

Знаете это больше похоже на боязнь нового. Я понимаю что далеко не все могут адекватно оценить последствия применения той или иной технологии. Но использование готовых сторонних инструментов позволяет экономить кучу времени. Единственное но надо правильно оценить инструмент. Все же группа адекватных разработчиков которые делают фреймворк лучше сделают его чем я в одну харю. Потому что я банально охвачу меньше аспектов чем они.

Да, это боязнь нового.
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.

Группа разработчиков делают инструменты исходя не из ваших задач а своих. Если они совпали - хорошо. Но могут и не совпасть, и более того, со временем разойтись в разные стороны.

Edited 2013-04-03 06:42 (UTC)

Да, это боязнь нового.
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.

Вы надеюсь понимаете, что в итоге пополните ряды разработчиков на COBOL?

Группа разработчиков делают инструменты исходя не из ваших задач а своих. Если они совпали - хорошо. Но могут и не совпасть, и более того, со временем разойтись в разные стороны.

Вы не поверите, но есть фреймворки общего назначения.

>> Вы надеюсь понимаете, что в итоге пополните ряды разработчиков на COBOL?

Они до сих пор восcтребованы, как ни странно :)

>> Вы не поверите, но есть фреймворки общего назначения.

Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.

Они до сих пор восcтребованы, как ни странно :)

Их количество существенно сократилось.

Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.

Конечно конечно. К примеру Delphi

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

Прям

Я лучше код пишу чем все остальные!

Надо понимать, что если я в одну харю такое решение буду делать, то убью существенно больше времени и результат будет хуже. Тупо за счет того что те люди занимаются этим больше времени чем я.

Ну а то что там могут быть черви и пауки, так это везде есть. И на стадии оценки стоит ли использовать и требуется оценить их количество.

Ну для начала, писать ORM на жабе или дельфях - это невменяемое занятие, язык для этого непригоден.
Можно написать некое приближение, но радости это не добавит.

В C# сделали чуть лучше, с синтаксическими расширениями, но в итоге там сделали несколько несовместимых вариантов.

>>"Ну для начала, писать ORM на жабе или дельфях - это невменяемое занятие, язык для этого непригоден."

А как же Hibernate?

Попытка обойти несуразности языка и баз данных. Условно успешная.
В нормальных условиях такой проект вообще возникнуть не должен был.

Я пишу код таким что бы я же с ним мог и разобраться.
Дай мне код метакласса - хрен я в нем разберусь.
То же самое со сторонними фреймворками - упоротые разработчики наваяют красивостей в сто слоев абстракций вместо того что бы тупо написать линейный код делающий ровно то же самое, но блять оно ведь не по феншую будет... А доку написать по всем их поделиям и слоям абстракций - кишка тонка.

Я пишу код таким что бы я же с ним мог и разобраться.

Я уже обращал внимание, на то что это ваш код и если не дай бог случится фактор автобуса, тот кто будет за вами его разбирать будет вникать дольше. Опять же сколько у вас человек код пишет? Один два?

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

Это вот из разряда не читал, но осуждаю. Для начала давайте вы посмотрите две документации
http://www.yiiframework.com/doc/guide/
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/
И расскажете что тут не так по вашему и чего же так остро не хватает и тому и тому.

У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я, плюс брал еще одного товарисча по удаленке, москвича. Он пишет неплохо но сложно - как вам и нравится, обвешать все классами и объектами так что физ.смысл что это все делает заипешься отслеживать. Мне в памяти ячеек не хватает все это одновременно удерживать :) Поэтому давал ему такие вещи которые в случае возникновения косяков на критичные вещи в программе не повлияют.

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

Могу дать пример такого продукта. VirtualTreeView. Хорошая дока, и компонент. Но страдает тем же. И я не уверен что есть хоть что-то что было бы описано полностью. Хотя нет, вспомнил - документация на ОС РАФОС, он же RT11. Если ты там чего-то не нашел это означало только одно - плохо искал. Все что надо я там в конце-концов находил. "Но сейчас так уже не делают".

У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я

Ну этим можно и закончить. Для того чтобы начать ценить такие вещи как ORM фреймворки и прочее надо поработать там где код пишет не один человек.

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

Как я и говорил. К тому времени когда надо будет копаться уже будет поздно.

(no subject)

fraks-nsk.livejournal.com - 2013-04-03 16:09 (UTC) - Expand

(no subject)

norguhtar.livejournal.com - 2013-04-03 16:14 (UTC) - Expand

Flat | Top-Level Comments Only