Абстрактное о ЯП для СУБД

>темплейты-дженерики, замыкания-лямбды

50 лет

>ОО

30 лет

> Почему сами по себе ЯП замерзли и практически не меняются (в смысле введения новых языковых концепций)?

obvious fix

совместимость?

Ну до мейнстримских-то языков это довели в последние 10-15 лет. А языки СУБД замерзли (по ощущениям) не позже начала 80х.

> obvious fix
???

>Почему сам по себе SQL замерз и практически не меняется (в смысле введения новых языковых концепций)?

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

Думаю прежде всего по экономическим соображениям SQL рулит. Хотя могу и ошибатся, но такая версия.

Кто ж заставляет ломать работающее? Жабка сделала все исходники на фортране невалидными?

> Думаю прежде всего по экономическим соображениям SQL рулит
Думаю, это зависит от того, как именно считать деньги. С т.зр. эффективности разработки и поддержки я не думаю, что SQL это высший взлет разума.

> Или я что-то не знаю про современный PL/SQL и пр.?

Похоже, ты не всё знаешь о более ранних языках. А.В.Замулин "Языки программирования баз данных и знаний" - книга старая, но интересная.

> Почему встроенные ЯП программирования СУБД фактически замерли в развитии?

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

> Почему сам по себе SQL замерз и практически не меняется (в смысле введения новых языковых концепций)?

Сами базы данных не меняются, а для текущих SQL близок к идеалу, возможно.

> Похоже, ты не всё знаешь о более ранних языках.
А как это относится к моему вопросу? Я-то как раз спрашиваю о том, что происходит (не происходит!) с SQL за последние 20-30 лет.

За ссылку спасибо. Возможно, я даже эту книжку держал в руках...

> Конечно, со всех агитплакатов нам вещают о новейших технологиях
Дело не в плакатах. Победное шествие скриптовых языков. Внедрение ОО в массы, всякого рода динамика на уровне языка. Да, придумали их давно - но широко в продакшне эти вещи используют относительно недавно. И где это все в SQL?

> Сами базы данных не меняются, а для текущих SQL близок к идеалу, возможно.

У всякого языка две морды. Одна - в сторону компа, другая - в сторону программиста. Морда в сторону компа - да, не поменялась. Но программисты-то сегодня немножко другие?

ЗЫ Видимо, к программистам СУБД это не относится. Судя по всему, это очень консервативная почти-мафия, наслаждающаяся контролем за бизнес-критикал данными и готовая за это дело терпеть всякие неудобства;)

>я не думаю, что SQL это высший взлет разума.

Я тоже так думаю, даже более того, думаю, что хранение данных в виде объектов было бы куда логичнее учитывая современное развитие ЯП, чем в виде реляционных таблиц. И соответственно костылей вроде JDBC для работы с ними. Но приходится мириться - нас не спрашивают. :)

>> Похоже, ты не всё знаешь о более ранних языках.

> А как это относится к моему вопросу?

Вопрос должен звучать по-другому: "почему существовавшие _языки программирования_ БД тихо сошли со сцены, уступив место _языку запросов_".

Подозреваю, что ответ имеет мало отношения к техническим аспектам :)

> Вопрос должен звучать по-другому:
Нет, это просто другой вопрос. И ответ на Ваш вопрос, я думаю, мне известен. Но, однажды победив всех, SQL явно почил на лаврах. И вот это мне уже непонятно.

> думаю, что хранение данных в виде объектов было бы куда логичнее учитывая современное развитие ЯП

Было уже. Лет 15 назад было модно предрекать, что ООСУБД всех зохавают. Не случилось.

>> Вопрос должен звучать по-другому:

> Нет, это просто другой вопрос.

Естественно.

> И ответ на Ваш вопрос, я думаю, мне известен

И каков он?

> Но, однажды победив всех, SQL явно почил на лаврах. И вот это мне уже непонятно.

Тогда причем здесь языки _программирования_ БД? Скорее вопрос следует задавать о Третьем Манифесте.

> Победное шествие скриптовых языков.

Скриптовых? Это вы пистоныруби всякие имеете ввиду? Модное увлечение, со временем пройдет. Да уже и сейчас они не особенно нужны.

> Внедрение ОО в массы

О полезности которого еще стоит подумать.

> всякого рода динамика на уровне языка

Например?

> Но программисты-то сегодня немножко другие?

– Обедню небось уже не служите? – спросил он при следующей встрече.

– Где там служить! Прихожане по городам разбежались, сокровища ищут.

>Почему сам по себе SQL замерз и практически не меняется (в смысле введения новых языковых концепций)

а чего тебе в нём не хватает? реляционная алгебра она и есть реляционная алгебра

альтернативных вариантов тоже хватает - вон тебе Mnesia или BerkleyDB, например

> И каков он?
Универсальность + доминирование IBM.

> Тогда причем здесь языки _программирования_ БД?
PL/SQL это что?

> Модное увлечение, со временем пройдет. Да уже и сейчас они не особенно нужны.
На чем написан модный Lightroom - не знаете?

> Например?
Это я про типизацию.

Я ж вроде написал чего. Например, вот темлейтов бы туда, замыканий. Не в ANSI SQL, а во всякие PL/SQL и Transact SQL.

На мой вкус, Вы предаешь много внимания способу

> На мой вкус, Вы предаешь много внимания способу
Это объединяет меня с авторами Камасутры.

> На чем написан модный Lightroom - не знаете?

Нет. На чем и о чем это говорит? (о лайтруме я узнал только что от вас :))

> Это я про типизацию.

Это все оттого, что статическая типизация в новомодных жабах неудобна. Ни вывода типов, ничего. Средневековье какое-то.

>Почему сам по себе SQL замерз и практически не меняется

tsql микрософт и оракаль продвигают... sql справляется с возложенной на него задачей

>Например, вот темлейтов бы туда, замыканий

куда - туда? хоть один пример можно?

>Не в ANSI SQL, а во всякие PL/SQL и Transact SQL.

это как раз несущественно :)

>> Внедрение ОО в массы

>О полезности которого еще стоит подумать.

В смысле, а что вредного то в ООП? Не представляю хотя бы маленькое GUI-приложение без ООП, не говоря уже об каком-то бизнес-приложении, как объекты реального мира без ООП то описывать будешь? Это же реальный вынос мозгов будет. На процедурном чтоли - это наверно мой ночной кошмар. Нет против процедурных ничего абсолютно не имею, нужны и те и те, но где речь идет о программных аналогах объектов реального мира ООП просто незаменим. Даже не знаю как без него обходились раньше.

Хотя технология ООП не такая уж новая, язык Smalltalk уж давным давно появился, в 80-х, а то и раньше вроде.

Lua. Сейчас есть определенный тренд, написать ядро на чем-то "нативном", потом использовать скриптовость.

> статическая типизация в новомодных жабах неудобна
А в SQL-based languages это типа удобно обалдеть как;)

> tsql микрософт и оракаль продвигают...
Дык что там есть в смысле новых языковых фич?

> хоть один пример можно?

Ну вот передать в процедурку некий блок, который обрабатывает данные, на которые указывает курсор. Да, через execute immediate это можно - но это ж криво...

> это как раз несущественно :)
А я как раз про них, если кто не понял;)

>Дык что там есть в смысле новых языковых фич?

процедуры, функции, триггеры. то ли их нет в стандарте, то ли они в tsql оригинальные.

>Не представляю хотя бы маленькое GUI-приложение без ООП

#!/usr/bin/wish

wm geometry  . 200x200+0-0
wm resizable . 0 0
wm title     . {OOP Sucks}

set f [frame .f -relief flat -background BLACK]
place $f -in . -relx     0.0 -rely      0.0\
               -relwidth 1.0 -relheight 1.0

>как объекты реального мира без ООП то описывать будешь?

легко и непринуждённо

>ООП просто незаменим

4.2

> Lua. Сейчас есть определенный тренд, написать ядро на чем-то "нативном", потом использовать скриптовость.

Вы как-то перескакиваете с темы на тему. Встроить в программу какой-бы то ни было язык не проблема, хоть статически типизированный, хоть динамически. Вот xmonad "скриптуется" на хаскелле. И ничего, не жужжит. Это я к тому, что в данном случае язык удобен как для написания ядра, так и скриптов и конфигов. Ну да, при использовании ушибленных жаб приходиться встраивать что-нибудь "попроще", чтобы умом не тронуться. Тут достаточно сравнить усилия, необходимые для написания плагина-раширения к какому-нибудь эклипсу и имаксу.

>В смысле, а что вредного то в ООП?

hype. вреден в любой технологии, но именно ООП он губит на корню. и ты тому - живое подтверждение

> Ну вот передать в процедурку некий блок, который обрабатывает данные, на которые указывает курсор. Да, через execute immediate это можно - но это ж криво...

Не нужно тащить в базу логику приложения.

> А я как раз про них, если кто не понял;)

А они не нужны. Все эти процедурные расширения внутри баз - просто не нужны. Ну разве что изредка для каких-то совершенно экзотических случаев. Иначе траха с поддержкой не оберёшься. Вот придёт к вам клиент с жалобой на продукт: стал жрать CPU. Уже все 128 процессоров сожрал, например. Что вы будете делать с этой проблемой если у вас всё в базу позапихано - и данные, и их обработка и какие-то попутные задачи до кучи туда же засунуты для единообразия? Если вы можете ответить на этот вопрос - как вы будете искать и устранять проблему, то, конечно, пихайте всё в базу. Только мне почему-то кажется, что не можете :)

Дык это ж все было, сто лет назад в PL/SQL и tsql. Хочу чего посвежее. Нет, не надо их сравнивать с ANSI SQL - они действительнго сильно больше его. Но сами по себе они застыли.

>вреден в любой технологии, но именно ООП он губит на корню. и ты тому - живое подтверждение

Ну ладно ладно пусть буду "живым подтверждением" :), но пример GUI ты весьма интересный и любопытный привел, даже не думал, что так может быть. Просто когда говорят обычно про GUI без ООП у меня сразу ассоциации с MFC - ну тут я думаю комментарии дальше излишни дальше.

> А они не нужны.
Охх, Вы наступаете на мою больную мозоль. Я как жабщик тоже так считаю. Но есть реальный мир. В нем есть всякое. И есть менеджеры и проекты, которые требуют делать ЭТО внутри БД.

>но пример GUI ты весьма интересный и любопытный привел, даже не думал, что так может быть

могу ещё на XPCE написать. на предикатах. или на REBOL/GUI. или на Phooey, например. веришь - все без ООП

>GUI без ООП у меня сразу ассоциации с MFC

ЕМНИП там как раз ООП. уродливое, но ООП

>Дык это ж все было, сто лет назад в PL/SQL и tsql. Хочу чего посвежее. Нет, не надо их сравнивать с ANSI SQL - они действительнго сильно больше его. Но сами по себе они застыли.

после моего последнего общения с tsql у меня складывается мнение, что там _всё_ нужно переделать. ибо напоминает php.

однако, это скорее всего наломает дров и переход будет медленным.

>могу ещё на XPCE написать. на предикатах. или на REBOL/GUI. или на Phooey, например. веришь - все без ООП

интересно, нужно таки хаскелл выучить...

>ЕМНИП там как раз ООП. уродливое, но ООП

...потому что все виденные мною гую написаны в ООП стиле. на сях, плюсах, асме, питоне, жабе.

> Охх, Вы наступаете на мою больную мозоль. Я как жабщик тоже так считаю. Но есть реальный мир. В нем есть всякое. И есть менеджеры и проекты, которые требуют делать ЭТО внутри БД.

Ну спросите их - как они будут разруливать проблемы в этом конгломерате. Oracle и без того достаточно сложная штука, но когда речь заходит о работе базы - тут идут и пинают DBA и он диагностирует чо там не так и по загрузке CPU он бы в принципе даже и сказал бы сразу что там примерно не так, если бы там не крутилась ещё и логика приложения. А вот когда оракловые процессы начнут затыкаться ещё и на куче PL/SQL-кода, DBA просто разведёт руками и уйдёт работать в другую компанию. А начальство его компании будет звонить вам, разработчегу, выдёргивать среди ночи с критическими тикетами и опять же встанет вопрос что с этим делать, как диагностировать, как отлаживать, как хотя бы уменьшить вред что бы дать работать прочей бизнес-логике клиента на том же сервере. Ну не знаю, может я утрирую и сам не встречался с такими приложениями, но мне кажется, что будет мрачновато.

>могу ещё на XPCE написать. на предикатах. или на REBOL/GUI. или на Phooey, например. веришь - все без ООП

jtootf, слушай стыдно конечно спрашивать, а что это за технология/язык была ну тот пример твой? Так ради интереса и общего развития.

>ЕМНИП там как раз ООП. уродливое, но ООП

Да какое там ООП одно название от ООП, одни структура на структуре и структурой погоняет макрос на макросе и макросом погоняет в основном. Есть конечно классы, но так как все это выполнено и обработка сообщений и все - без слов.

Кстати, ну вам как жавщику ещё должно быть небезынтересно узнать, что Oracle кроме pl/sql ещё и джаву поддерживает. Но всё равно - неправильно это..

>интересно, нужно таки хаскелл выучить...

неочевидный вывод. XPCE - это Prolog. REBOL/GUI - это, внезапно, REBOL. почему именно Haskell?

>...потому что все виденные мною гую написаны в ООП стиле. на сях, плюсах, асме, питоне, жабе

ну это всё от неправильного подхода к обучению :)

мне вот недавно доложили, что даже M$ осилили часть идей Tcl/Tk - в последних релизах своего WPF (XAML, routed events). интересно, кто первый полноценно применит Reactive в GUI?..

> что это за технология/язык была ну тот пример твой?

Язык tcl. Новейшая технология Тк, позволяющая вам работать на 40.92% эффективней!

>стыдно конечно спрашивать

спрашивать не должно быть стыдно. учиться - полезно!

>что это за технология/язык была ну тот пример твой?

http://www.tcl.tk/

у gaa поинтересуйся, что оно и к чему :)

>Есть конечно классы, но так как все это выполнено и обработка сообщений и все - без слов

а GUI на ООП намного лучше и не сделаешь, ИМХО. всё равно уродливо будет

>Язык tcl. Новейшая технология Тк, позволяющая вам работать на 40.92% эффективней!

это в среднем. в пике - на 245.13%

Благодарю.

А я встречался много раз. Как-то справляются. И походу платят охрененное бабло Ораклу за поддержку.

Я видел ту жабку. Смотрится как-то дико и неродно.