![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
Как работает мой велосипедик я знаю, и он по минимуму завязан на что-то стороннее.
А вот бывает пытаешься заюзать новую версию чего-то, оно требует поменять версии еще кучи всего, вся эта куча в неопределенных местах может поменять поведение и в итоге программа перестает нормально работать. Чем больше разнообразных библиотек и инструментов - тем хуже ситуация.
no subject
Как работает мой велосипедик я знаю, и он по минимуму завязан на что-то стороннее.
А вот бывает пытаешься заюзать новую версию чего-то, оно требует поменять версии еще кучи всего, вся эта куча в неопределенных местах может поменять поведение и в итоге программа перестает нормально работать. Чем больше разнообразных библиотек и инструментов - тем хуже ситуация.
Знаете это больше похоже на боязнь нового. Я понимаю что далеко не все могут адекватно оценить последствия применения той или иной технологии. Но использование готовых сторонних инструментов позволяет экономить кучу времени. Единственное но надо правильно оценить инструмент. Все же группа адекватных разработчиков которые делают фреймворк лучше сделают его чем я в одну харю. Потому что я банально охвачу меньше аспектов чем они.
no subject
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.
Группа разработчиков делают инструменты исходя не из ваших задач а своих. Если они совпали - хорошо. Но могут и не совпасть, и более того, со временем разойтись в разные стороны.
no subject
Да, это боязнь нового.
Адекватно оценить не то что не все а вообще мало кто может.
Использование готовых сторонних инструментов может сэкономить а может и поглотить кучу времени. Как повезет. Использование обкатанных методов - известные временные затраты, и это совершенно не критичное время, в моем случае.
Вы надеюсь понимаете, что в итоге пополните ряды разработчиков на COBOL?
Группа разработчиков делают инструменты исходя не из ваших задач а своих. Если они совпали - хорошо. Но могут и не совпасть, и более того, со временем разойтись в разные стороны.
Вы не поверите, но есть фреймворки общего назначения.
no subject
Они до сих пор восcтребованы, как ни странно :)
>> Вы не поверите, но есть фреймворки общего назначения.
Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.
no subject
Они до сих пор восcтребованы, как ни странно :)
Их количество существенно сократилось.
Либо они умерли и не развиваются и след. версий от них не жди либо они развиваются не в ту сторону куда вам надо. Есть счастливые исключения.
Конечно конечно. К примеру Delphi
no subject
Большинство разработчиков сторонних фреймворков неадекватны, как и любые программисты. Это не значит, что их продуктами нельзя пользоваться, но надо понимать, что там могут быть такие же залежи легаси кода и неадекватных архитектурных решений, как и в любом проекте.
no subject
Я лучше код пишу чем все остальные!
Надо понимать, что если я в одну харю такое решение буду делать, то убью существенно больше времени и результат будет хуже. Тупо за счет того что те люди занимаются этим больше времени чем я.
Ну а то что там могут быть черви и пауки, так это везде есть. И на стадии оценки стоит ли использовать и требуется оценить их количество.
no subject
Можно написать некое приближение, но радости это не добавит.
В C# сделали чуть лучше, с синтаксическими расширениями, но в итоге там сделали несколько несовместимых вариантов.
no subject
А как же Hibernate?
no subject
В нормальных условиях такой проект вообще возникнуть не должен был.
no subject
Дай мне код метакласса - хрен я в нем разберусь.
То же самое со сторонними фреймворками - упоротые разработчики наваяют красивостей в сто слоев абстракций вместо того что бы тупо написать линейный код делающий ровно то же самое, но блять оно ведь не по феншую будет... А доку написать по всем их поделиям и слоям абстракций - кишка тонка.
no subject
Я пишу код таким что бы я же с ним мог и разобраться.
Я уже обращал внимание, на то что это ваш код и если не дай бог случится фактор автобуса, тот кто будет за вами его разбирать будет вникать дольше. Опять же сколько у вас человек код пишет? Один два?
То же самое со сторонними фреймворками - упоротые разработчики наваяют красивостей в сто слоев абстракций вместо того что бы тупо написать линейный код делающий ровно то же самое, но блять оно ведь не по феншую будет... А доку написать по всем их поделиям и слоям абстракций - кишка тонка.
Это вот из разряда не читал, но осуждаю. Для начала давайте вы посмотрите две документации
http://www.yiiframework.com/doc/guide/
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/
И расскажете что тут не так по вашему и чего же так остро не хватает и тому и тому.
no subject
Пишет один - я, плюс брал еще одного товарисча по удаленке, москвича. Он пишет неплохо но сложно - как вам и нравится, обвешать все классами и объектами так что физ.смысл что это все делает заипешься отслеживать. Мне в памяти ячеек не хватает все это одновременно удерживать :) Поэтому давал ему такие вещи которые в случае возникновения косяков на критичные вещи в программе не повлияют.
По поводу чтения документации - у меня совершенно нет желания копаться в документации к продукту с которым я не работаю. Без этого никаких выводов по доке сделать нельзя. Дока может выглядеть красиво и информативно, но как начнешь продукт реально использовать - всегда натыкаешься на то что в доке даны элементарные вещи и если повезет - основы и принципы. А тонкости - дай бог что бы хотя бы упомянуты были, а уж что бы были разжеваны с примерами - так и вообще чудо.
Могу дать пример такого продукта. VirtualTreeView. Хорошая дока, и компонент. Но страдает тем же. И я не уверен что есть хоть что-то что было бы описано полностью. Хотя нет, вспомнил - документация на ОС РАФОС, он же RT11. Если ты там чего-то не нашел это означало только одно - плохо искал. Все что надо я там в конце-концов находил. "Но сейчас так уже не делают".
no subject
У меня тупо кода мало - в нем и разбираться проще.
Пишет один - я
Ну этим можно и закончить. Для того чтобы начать ценить такие вещи как ORM фреймворки и прочее надо поработать там где код пишет не один человек.
По поводу чтения документации - у меня совершенно нет желания копаться в документации к продукту с которым я не работаю. Без этого никаких выводов по доке сделать нельзя. Дока может выглядеть красиво и информативно, но как начнешь продукт реально использовать - всегда натыкаешься на то что в доке даны элементарные вещи и если повезет - основы и принципы. А тонкости - дай бог что бы хотя бы упомянуты были, а уж что бы были разжеваны с примерами - так и вообще чудо.
Как я и говорил. К тому времени когда надо будет копаться уже будет поздно.
no subject
И не претендую на звание сильно продвинутого программиста.
Поддерживая культуру монотехнологии, или неувеличения их количества в проекте я упрощаю его поддержку. Для проекта это плюс. И этого достаточно.
no subject
Поддерживая культуру монотехнологии, или неувеличения их количества в проекте я упрощаю его поддержку. Для проекта это плюс. И этого достаточно.
Увы нет. Упрощение происходит тогда когда используется известный и документированный инструментарий, а так же общеизвестные практики. У вас этого всего нет. И у вас есть фактор автобуса. Проще говоря если вас завтра собьет автобус будет проще выкинуть весь ваш код и написать с нуля. У меня был проект по описанной вами "монотехнологии" как раз на дельфи. В результате вместо разбирательств с накопленным линейным и монокультурным кодом было принято решение выкинуть его к хренам и переделать все на базе spring framework. И кода внезапно стало меньше и в нем проще стало искать что нужно. Потому что банально следовали общепринятым практикам.