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

[metaclass]

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

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

Comments

[sbj-ss.livejournal.com]

Кобол я мельком видел и вздохнул. "IF THISINPUT IS EQUAL TO 001 ADD 1 TO COUNT001". SQL в меньшей мере потащил то же самое — попытки описать на естественном языке вещи, которым в конструкциях естественного языка просто нет аналогов.
Впрочем, беда "академиков" с SQL не в попытках "придумать язык для менеджеров", а в отсутствии смелости сказать "Б" после того, как сказано "А". Если бы хотя бы были предложены фрагменты синтаксиса, покрывающие всё множество решаемых задач, а не его небольшое подмножество, не было бы сейчас ругани на несовместимость. Там же, где есть потребность, но нет стандарта, каждый пойдёт придумывать, что горазд, (при активной поддержке менеджеров, срочно требующих новые фишки), а опоздавшие стандарты только усугубляют ситуацию. В результате в 2013 году многие кроваво-энтерпрайзные РСУБД тупо не поддерживают полностью SQL'92.
Паскакаль - отдельный разговор. Оторванность логических типов от физических неоднократно крепко напакостила, дав борландовцам возможность ломать совместимость. Достаточно вспомнить невозможность записи в нулевой байт строки в Дельфи (полбеды) и переезд поздних версий RAD Studio на UTF-16 по умолчанию (беда). Второе всем привыкшим, что Byte === Char с точностью до контекста использования, переломало существующий код. И если уж предусматривалось, что возможны изменения, нехрен было делать в языке преобразование Byte <=> Char. C/C++ так не испортишь.
Что до языков, придуманных программистами для программистов, здесь тоже не всё гладко. Простой пример - Perl с его write-only программами и необходимостью запоминать назначение $₪ и $℧. Сам же нагнетатель срача theiced, по рассказам очевидцев, использует его, как Shell Script :) Perl компактен и эффективен, не спорю. Но читать на нём чужой код - избави Ктулху.

[theiced.livejournal.com]

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

[voidex.livejournal.com]

А если бы перл был вином, ты бы сказал, что это программист для программистов, да.

[theiced.livejournal.com]

там в оригинальном псто снизу я уже объяснял почему вот это утверждение некорректно ;]

[voidex.livejournal.com]

Не нашёл. Если там, где про JavaScript Python и PHP, то там другое утверждение. Там утверждение о достаточности, а я о том, что если найдётся вин, который таки сделал сантехник для программистов, то всегда можно сказать, что этот сантехник самый что ни на есть программист.