![[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
Фактор автобуса существует всегда.
Чем проще инструмент - тем надежнее.
Вам почему-то кажется что есть один правильный метод написания а все остальные неправильные и ущербные.
Да мне кажется ущербным использование практически мертвой технологии причем находящейся не в
opensource в 2013 году. И стоит его минимизировать.
Нет, юзается древнейшая D7. Перехода на более новую не планируется ибо пока нет причин. Будут причины - буду думать. Переходы с версии на версию проходят не гладко и без нужны нет смысла скакать по этим кочкам.
Знаете когда появятся причины будет поздно. Причины будут вида ой у нас больше эта версия под новой виндой не работает. А при попытках перехода выяснится что тех версий где это могло бы работать просто нигде нет.
Нет, потому что нет смысла. Для работы на линухе я отказался от некоторых заточек на сугубо виндовые реализации и программа прекрасно работает под вайном. Но это очень мало восстребовано.
Смысл как раз есть. В отличии от Delphi этот проект является opensource. И от воли компании закрыть среду не зависит.
Есть.
И то хлеб.
Хоть какая-то - есть, но документацией это назвать сложно.
Есть. но писалась много лет назад, возможно сейчас по той последовательности не все пройдет гладко.
Понятно.
Чем мне нравится Delphi - компиляция происходит крайне быстро, поэтому перекомпиляция проекта у меня происходит чаще чем даже сохранение. Бывает недописал команду, пошел вверх что-то посмотреть, а потом бывает проще запустить компиляцию и ткнуть в выданную ошибку и по ней перейти вместо того что бы идти на то место руками. Так что перекомпиляция применяется везде и всегда, тем более после переустановки.
Это не ответ. Значит считаем что нет.
По факту же мы имеем ПО которое после того как разработчик перестанет его поддерживать придется выкинуть как бы оно красиво не ложилось на бизнес-процессы.
no subject
>> opensource в 2013 году. И стоит его минимизировать.
Дрочка на opensource не нужна. Я не собираюсь разбираться с косяками того же лазаруса.
Delphi в текущем виде устраивает, на полочке лежит купленный диск с Delphi Express на который перейти не нашел повода, а интерфейс там заметно поменялся что и отпугнуло от немотивированного перехода.
Так же имеются в продаже Delphi XE3 включающий в себе кроме собственно XE3 так же и XE2, XE, 2010, 2009, 2007 и 7.
Слухи о гибели Delphi высосаны из пальца.
А вот перспективы лазаруса крайне туманны.
>> Это не ответ. Значит считаем что нет.
Есть, в любой момент без каких-либо препятствий.
>> По факту же мы имеем ПО которое после того как разработчик перестанет его поддерживать придется выкинуть
Не увидел каким образом это утверждение согласуется с реальностью.
no subject
Дрочка на opensource не нужна. Я не собираюсь разбираться с косяками того же лазаруса.
Ну-ну. Я так понимаю о рисках использования закрытого ПО в длительной перспективе вы ничего не знаете и не читали.
Слухи о гибели Delphi высосаны из пальца.
Панк не умер, он просто плохо пахнет (с)
Вы сейчас можете найти современную программу на Delphi? Я вот такой не припомню ни одной. Delphi давно не mainstream. Сейчас под windows все пишут на .NET.
Есть, в любой момент без каких-либо препятствий.
Возьмите windows 7 причем 64 битную и проверьте как это все там собирается.
Не увидел каким образом это утверждение согласуется с реальностью.
Мы имеем код написанного в среде разработки которой в этом году уже 11 лет. Этот код довольно велик, не документирован, не имеет четкой архитектуры. Разработчиков под него уже сейчас надо искать с факелами. Перенос на новую Delphi займет довольно много времени и сил. Использует РСУБД той же давности. И никаких действий по приведению ее к современному состоянию как-то не прикладывается.
no subject
>> Ну-ну. Я так понимаю о рисках использования закрытого ПО в длительной перспективе вы ничего не знаете и не читали.
С опенсорсем риски тоже есть, они другие но их не меньше.
Как показывает жизнь Борланд и Эмбаркадеро достаточно надежные компании что бы не бояться использовать их продукт.
>> Вы сейчас можете найти современную программу на Delphi? Я вот такой не припомню ни одной.
TheBat, SPlan. Куча корпоративного софта и софта государственных контор.
Более плотно вопрос не изучал.
>> Delphi давно не mainstream. Сейчас под windows все пишут на .NET.
Последние версии Delphi, если не ошибаюсь, тоже поддерживают .NET.
Дрочка на mainstream не нужна. Он слишком часто меняет свое направление.
Перепись программы на .NET только потому что "Сейчас под windows все пишут на .NET." - верх идиотизма.
>> Возьмите windows 7 причем 64 битную и проверьте как это все там собирается.
У меня ее нет. Если не будет собираться или работать - это не конец цвета. У нас бизнес а не шашечки. Если не пойдет под 64 - можно просто не использовать 64. Дрочка неа 64 не нужна. Но думаю что все будет работать без проблем.
Хотя вспомнил, ставили мы сервер и клиента на бук с семеркой 64. Работало.
Delphi - не ставил.
>> Мы имеем код написанного в среде разработки которой в этом году уже 11 лет.
>> Этот код довольно велик, не документирован, не имеет четкой архитектуры.
141 форма, общим размером DFM 1.3мб
146 юнитов общим размером паскалевского кода около 2мб
и некоторое количество своих и сторонник библиотек используемых не только в этом проекте.
Библиотеки без исходного кода принципиально не используются.
База:
- 64 таблицы
- 108 процедур
- 107 триггеров
- 85 генераторов
- 28 исключений
- 179 индексов
Скрипт создания базы - 368кб
Итого на 141 форму суммарно 2,5мб исходного кода.
На одну соответственно 17кб в среднем.
А сколько, в среднем у вас кода на одну форму? На экономном ОРМ?
>> Разработчиков под него уже сейчас надо искать с факелами.
80% тех кто работает с Firebird - пишут на Delphi.
Гнездо Firebird известно :)
Так что проблема поиска с факелами - в бОльшей степени надумана.
То что на Delphi мало пишет молодняк - это даже плюс, люди с опытом :)
>> Перенос на новую Delphi займет довольно много времени и сил.
Перенос на что бы то ни было займет много времени и сил. Но перенос ради переноса - не нужен.
>> Использует РСУБД той же давности.
Это вы выдумываете. Используется последний зарелизенный Firebird 2.5.1.
>> И никаких действий по приведению ее к современному состоянию как-то не прикладывается.
Если вы про переписывание на язык по писку последней моды - то да, не делается. А рефакторинг потихоньку происходит практически при залазе в исходники, с целью повышения стройности кода и архитектуры.
no subject
С опенсорсем риски тоже есть, они другие но их не меньше.
Есть, но риска "мы взяли и убили проект и давай до свидания" как-то нет.
Как показывает жизнь Борланд и Эмбаркадеро достаточно надежные компании что бы не бояться использовать их продукт.
Да ладно? Борланд продали не от хорошей жизни.
TheBat, SPlan. Куча корпоративного софта и софта государственных контор.
Более плотно вопрос не изучал.
Целых две программы, которые уже практически не покупают это да. А в гос. конторах своя атмосфера.
Остальные как-то Delphi не используют.
Последние версии Delphi, если не ошибаюсь, тоже поддерживают .NET.
От этого лучше не становится.
Дрочка на mainstream не нужна. Он слишком часто меняет свое направление.
Перепись программы на .NET только потому что "Сейчас под windows все пишут на .NET." - верх идиотизма.
Нужна не дрочка, а соответствие реалиям. Использовать Delphi 7 в 2013 год это верх идиотизма.
У меня ее нет. Если не будет собираться или работать - это не конец цвета. У нас бизнес а не шашечки.
Очень странные заявления у нас бизнес, а не шашечки. В бизнесе как-то важно чтобы ваша программа работала и без вас. А у вас увы фактор автобуса в чистом виде.
Если не пойдет под 64 - можно просто не использовать 64. Дрочка неа 64 не нужна. Но думаю что все будет работать без проблем.
Гениально. Давайте подстраивать платформу выполнения под программу.
141 форма, общим размером DFM 1.3мб
146 юнитов общим размером паскалевского кода около 2мб
и некоторое количество своих и сторонник библиотек используемых не только в этом проекте.
2 мегабайта кода? Реально у нас была программа аналогичного масштаба написанная на Delphi. Нам пришлось взять ее и выкинуть, потому что разобраться в ней было мало реально.
Библиотеки без исходного кода принципиально не используются.
Кривите душой. Используются компоненты Delphi. Я не припомню чтобы для VCL были исходники.База:
Итого на 141 форму суммарно 2,5мб исходного кода.
На одну соответственно 17кб в среднем.
А сколько, в среднем у вас кода на одну форму? На экономном ОРМ?
У меня код контроллера в среднем 10 килобайт. Размер формы на html в среднем 5 килобайт. Если уж сильно интересно.
Гнездо Firebird известно :)
Так что проблема поиска с факелами - в бОльшей степени надумана.
То что на Delphi мало пишет молодняк - это даже плюс, люди с опытом :)
Не надумана. А то что на этом не пишет молодняк как вы выражаетесь плохо. Так-как это как раз и приводит к искать с факелами.
Перенос на что бы то ни было займет много времени и сил. Но перенос ради переноса - не нужен.
А между тем мое приложение спокойно переехало с spring framework 3.0->3.1->3.2 и не кашляет. И да особого времени и сил это не затребовало.
Это вы выдумываете. Используется последний зарелизенный Firebird 2.5.1.
Это вот у вас единственный вменяемый компонент и используется у вас только в силу свой как раз таки opensource.
Если вы про переписывание на язык по писку последней моды - то да, не делается. А рефакторинг потихоньку происходит практически при залазе в исходники, с целью повышения стройности кода и архитектуры.
О какой стройности кода может идти речь если у вас в форме ад и израиль? Мягко говоря все образчики кода которые вы показывали ни у кого восторга не вызывает, скорее даже наоборот.
no subject
>> С опенсорсем риски тоже есть, они другие но их не меньше.
>>> Есть, но риска "мы взяли и убили проект и давай до свидания" как-то нет.
Да точно так же есть. Убили проект, самостоятельно вы его развивать не сможете а желающие разбежались. Все, приплыли.
Кстати, тот самый Firebird образовался когда Borland решил убить Interbase. В итоге есть бесплатный опенсорс Firebird и платный закрытый Interbase.
>> Да ладно? Борланд продали не от хорошей жизни.
У Борланда было херово с маркетингом.
Но то что Delphi был куплен другой компанией и продолжает развиваться - о чем-то говорит.
>> Нужна не дрочка, а соответствие реалиям. Использовать Delphi 7 в 2013 год это верх идиотизма.
Начинать длительный проект в 2013 году на Delphi7 - да, идиотизм. Хотя тоже могут быть ньюансы.
А вот переписывать код под каждый выходящий ежегодно Delphi - это что, не идиотизм?
>> А между тем мое приложение спокойно переехало с spring framework 3.0->3.1->3.2 и не кашляет.
>> И да особого времени и сил это не затребовало.
Ну, смена последней циферки может скрывать весьма небольшие изменения.
Моя программа мигрировала с Delphi (просто Delphi) на D2, D5, D7.
Каждая миграция была не просто так а вслед за полезными языковыми конструкиями которых не хватало в предыдущей. D1 вообще был 16-разрядным. Каждый переезд требует обновления всех используемых библиотек а они не все живут так долго. Обжогшись на этом перестал использовать либы без исходников т.к. с ними переход невозможен, приходится искать аналоги и переписывать. Так же стал стараться использовать стороннее по минимуму.
>> Гениально. Давайте подстраивать платформу выполнения под программу.
С вашей точки зрения программиста это выглядит дикостью, а с точки зрения бизнеса - это нормально.
Кроме того аналогичная ситуация вообще в компьютерном мире - вполне исправное и устраивающее железо может не заработать на новой платформе из-за отсутствия драйверов под эту платформу. Соответственно при смене ОС надо поменять еще и железо. Вопрос - нафига тогда менять ОС?
>> Это вы выдумываете. Используется последний зарелизенный Firebird 2.5.1.
>>> Это вот у вас единственный вменяемый компонент и используется у вас только в силу свой как раз таки opensource.
Миграция на новые версии Firebrird обусловлена тем что в нем вносится много полезных и нужных мне вещей.
Опенсорс тут особо не влияет. Он для меня все равно получается как бы платным, я являюсь членом Firebird Foundation и ежегодно плачу туда взносы. Они не велики но это мой вклад в развитие нужного мне продукта.
>> Мягко говоря все образчики кода которые вы показывали ни у кого восторга не вызывает, скорее даже наоборот.
Вызвать восторг - не является моей целью. Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
no subject
Да точно так же есть. Убили проект, самостоятельно вы его развивать не сможете а желающие разбежались. Все, приплыли.
Есть разница. В случае opensource вы имеете исходные коды и можете заниматься поддержкой сами. В случае закрытого продукта можете только рвать волосы на себе. Особенно весело если данные там лежат в своем закрытом формате.
Кстати, тот самый Firebird образовался когда Borland решил убить Interbase. В итоге есть бесплатный опенсорс Firebird и платный закрытый Interbase.
Как раз яркий пример почему использование не opensource плохо.
У Борланда было херово с маркетингом.
Но то что Delphi был куплен другой компанией и продолжает развиваться - о чем-то говорит.
Увы ни о чем это не говорит. Новых приложений на этой штуке я не видел ни одного. А вот на Qt видел.
Начинать длительный проект в 2013 году на Delphi7 - да, идиотизм. Хотя тоже могут быть ньюансы.
А вот переписывать код под каждый выходящий ежегодно Delphi - это что, не идиотизм?
Не переписывать, а портировать. И портировать надо если хочется чтобы программа не закончила свой жизненный цикл. На портирование с версии на версию как правило затрачивается меньше усилий. Но если этого не делать, а спохватится в 2013 году, то уже проще написать с нуля.
Ну, смена последней циферки может скрывать весьма небольшие изменения.
На момент старта разработки слава богу 2.5 уже можно было не использовать. Но и при его использовании я бы спокойно переехал на тройку.
Моя программа мигрировала с Delphi (просто Delphi) на D2, D5, D7.
Там какие-то значительные изменения были только с D2 на D5.
Каждая миграция была не просто так а вслед за полезными языковыми конструкиями которых не хватало в предыдущей. D1 вообще был 16-разрядным. Каждый переезд требует обновления всех используемых библиотек а они не все живут так долго. Обжогшись на этом перестал использовать либы без исходников т.к. с ними переход невозможен, приходится искать аналоги и переписывать. Так же стал стараться использовать стороннее по минимуму.
А потом дойдя до D7 стало незачем? Ну а библиотеки опять же яркий пример почему не стоит использовать закрытые решения. И да в Delphi с открытыми библиотеками и их качеством весьма грустная история. Это кстати еще одна из причин почему мы выкосили свое старое приложение на Delphi.
С вашей точки зрения программиста это выглядит дикостью, а с точки зрения бизнеса - это нормально.
С точки зрения бизнеса это тоже дикость. Так-как в один прекрасный момент все сложнее становится купить необходимую платформу. Это тоже самое что продолжать упорно использовать автомобиль прослуживший 10 лет, потому что у нас в кузов наш старый кран помещается.
Кроме того аналогичная ситуация вообще в компьютерном мире - вполне исправное и устраивающее железо может не заработать на новой платформе из-за отсутствия драйверов под эту платформу. Соответственно при смене ОС надо поменять еще и железо. Вопрос - нафига тогда менять ОС?
Компьютеры имеют такую особенность выходить из строя. И да сейчас уже все меньше компьютеров позволяет запускать Windows XP без бубна. А скоро этого сделать будет вообще нельзя.
Миграция на новые версии Firebrird обусловлена тем что в нем вносится много полезных и нужных мне вещей.
Опенсорс тут особо не влияет.
Влияет. Это дает возможность туда добавлять нужные вещи. В том числе и самому при должной квалификации.
Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
Увы сейчас ваш код таким не является. Он как минимум плохо структурирован.
no subject
no subject
no subject
з.ы. но был дико рад, когда наконец свалил от этого всего в java
(no subject)
(no subject)
(no subject)
no subject
Именно так. Все что нужно имеется. Тотальный юникод в строках не нужен. Будет нужен - подумаю над этим вопросом.
>> Влияет. Это дает возможность туда добавлять нужные вещи. В том числе и самому при должной квалификации.
Я не питаю иллюзий по поводу своей квалификации и способности разобраться в объемном и сложном чужом коде. Компиляторы и СУБД намного сложнее чем междумордия для бизнеса. Поэтому мне без разницы опенсорс это или нет - я не собираюсь в одиночку тащить чужие глобальные проекты. Я лучше куплю готовый инструмент и буду им пользоваться.
>> Код должен быть простым и легко понятным, с привлечением минимимума лишних абстракций.
>>> Увы сейчас ваш код таким не является. Он как минимум плохо структурирован.
Мое больное место - сложность в удержании в памяти слоев абстракций и каскадные ссылки и переходы. Соответственно я пишу так что бы этот дефект не сказывался. Пока-что получается. Но по этой причине код с водопадами классов я читать не могу и соответственно не применяю.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
>> Более плотно вопрос не изучал.
>>> Целых две программы, которые уже практически не покупают это да. А в гос. конторах своя атмосфера.
>>> Остальные как-то Delphi не используют.
Не надо передергивать. Я привел первое что пришло на ум.
Вот вам еще примеры:
- Skype
- Total Commander
- The KMPlayer
- Light Alloy
- QIP
- Download Master
- FastStone Image Viewer
- FastStone Capture
- Парус Бухгалтерия
>> Библиотеки без исходного кода принципиально не используются.
>>> Кривите душой. Используются компоненты Delphi. Я не припомню чтобы для VCL были исходники.
Вы писали на Delphi? :)
Как вы можете помнить того что не знали.
Исходники VCL идут в комплекте с дельфи, кроме самых дешевых и кастрированных комплектаций.
Лежат в
С:\Program Files\Borland\Delphi7\Source\Vcl
>> У меня код контроллера в среднем 10 килобайт. Размер формы на html в среднем 5 килобайт.
>> Если уж сильно интересно.
Порядок тот же самый. Где хваленая разница от применения ОРМ?
no subject
- Skype
Только под винду и теперь уже не надолго.
- Total Commander
- The KMPlayer
- Light Alloy
А это все еще живое?
- QIP
Уже нет. C# WPF
- Download Master
- FastStone Image Viewer
- FastStone Capture
- Парус Бухгалтерия
О да все это весьма известные программы.
Вы писали на Delphi? :)
Все студенты наших вузов в свое время писали на Delphi
Исходники VCL идут в комплекте с дельфи, кроме самых дешевых и кастрированных комплектаций.
Значит у нас была такая комплектация.
Порядок тот же самый. Где хваленая разница от применения ОРМ?
Хваленая разница в разделяемости слоев и в более быстрой разработке. У меня используется MVC в результате над кодом может работать большое количество народу и при этом они ничего не сломают. Один может исправить форму, другой логику. Третий внести правки в слой работы с СУБД и все это будет продолжать спокойно работать. При вашем подходе увы это сделать нельзя. Так-как вы уже смешали код контроллера с представлением.
no subject
И по качеству кода они на голову выше того адового говна которое я видел в дотнете.
Т.е. дотнет (более-менее высокоуровневые части - контролы, system.componentmodel) внутри - это вообще, индусятина уровня школы детей-дебилов, густо усыпанная паттернами.
no subject
no subject
Извините, что влезаю в ваш диалог, но судя по анимешному фейсу на вашей аватарке, вы относитесь к более молодому поколению. И у вас с оппонентов разный опыт разработки.
Когда пишешь на стороннего дядю - начинают вылазить странные требования, вроде .NET, кроссплатформенности, включающей FreeBSD, WinXP 64bit и проблемы наподобие "у нас бухгалтерия не может это провести, переделайте".
Когда работаешь со своим предприятием, то бухаглтерия делает то, что ей сказано, несовместимые компьютеры с неподдерживаемыми ОС просто не покупаются, и вообще - большая часть вопросов решается административно. И вообще, пространство для маневра намного шире.
no subject
Когда работаешь со своим предприятием
Когда работаешь со своим предприятием возникает "надо вчера". И использование фреймворков и орм дает больше времени для маневра. Тупо за счет меньшего внимания к рутинным операциям и тому а как бы сделать тут так чтоб у меня архитектуру не скрючило.
no subject
1) Не софтовая.
2) Ваша.
Очень сомнительно, чтобы у некой торговой компании возникла необходимость "ко вчера" что-то переделать.
no subject
no subject
Skype
no subject
no subject
Микрософт что бы не разводить зоопарк компиляторов переписывает (возможно) скайп на имеющийся инструмент.
no subject
no subject
Ну это только подтверждает применение монотехнологий :)
Это говорит скорее о победе здравого смысла и ухода от устаревших технологий. Монотехнологиями там не пахнет. У того же MS довольно обширный стек доступных языков.
no subject