web_foxКоллеги, я думаю вы через чур сильно накинулись на Nitro_Junkie, и всё чаще приводите ошибочные доводы. Идея Nitro_Junkie понятна и намерения только приветствуются. Лично я считаю, что текущие языки а-ля СИ слишком просто позволяют программисту делать ошибки, а как известно лучшая ИС та, что не позволяет пользователю ошибаться. Одна только слабая типизация сводит все преимущества, например, PHP, при написании приложений корпоративного уровня в хлам (да, звучит дико, но многие пишут корпоративные приложения на этом языке), получается типичный го.но-код. И выражения типа "кривые руки" здесь не канает.

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

Спасибо за понимание, а то начинает казаться что я что-то совсем не то говорю.

Ситуация в том, что проект длится около 2-х лет и только сейчас мы вышли на законченный вариант этой свойство-ориентированной платформы в базовой постановке (бета-версию можно сказать). Честно говоря не ожидал что получится настолько цельная парадигма разработки, но результат превзошел даже мои ожидания. Соответственно с месяц назад мы приступили к описанию парадигмы и сейчас оно готово процентов на 40. В него также войдут презентация, видео с процессом разработки и несколько примеров систем (от самого простого, до достаточно "навернутого")... По плану завершить это все через месяц полтора, на практике думаю все затянется до 2-3 месяцев. После этого начнем продвижение в том числе в нете с целью поиска партнеров, инвесторов, клиентов и т.п. На этот форум ессно ссылку тоже закину :)

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

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

Gluk (Kazan)Nitro_Junkie
P.S.: Следуя вашей логике, нет никакой разницы между SQL, C++ и Prolog...

Есть разница :) Первый не Тьюринг-полный

Вы начало темы читали? SQL-1999 как раз Тьюринг-полный...

_модNitro_JunkieЯ же вам привел уже пример - частично-рекурсивные функции. Это чистая объектная алгебра.
Как с помощью функций получить объект неописанного класса ?

Забыли про классы. Мы говорим про объектную алгебру.
В данной логике класс это производное понятие. Поясню на примере. То есть если у нас есть функция Объем_двигателя(объект1). То Объем_двигателя(Роза1) = undef. Соответственно Объем_двигателя(митсубиси4332) = объем4 . Класс Авто всего лишь обозначают что для всех объектов не этого класса, функция Объем_двигателя всегда будет давать undef (что впрочем не значит что для Авто она не будет undef). То есть объектную логику можно рассматривать в отрыве от классов, а последние рассматривать как просто характеристику функций.

ЗЫ: Если кому-нибудь не _моду, понятен принцип что я написал здесь и выше, напишите, реально интересно... а то мне это очевидно, но такое ощущение что мне одному :)

_модNitro_JunkieМы говорим про объектную алгебру.
Да нет никакой объектной алгебры. То что описали - обычный язык без контроля типов, тот же питон

Да нет никакой реляционной алгебры. То что описали - обычный язык запросов, тот же SQL.

PS: кстати в питоне есть оператор минимизации аргумента? И то что я описал это декларативный язык, а питон - императивный (по моему определению во всяком случае)...

Gluk (Kazan)А вот это еще стоит доказать
кстати, вику и надписи на заборах я тоже не читаю

На раз два доказывается :

функция выбора и следование - обычные выражения
оператор подстановки - операция Join
оператор примитивной рекурсии - рекурсивные CTE
оператор минимизации рекурсии- GROUP BY с аггрегирующей функцией MAX

Значит эквивалентно частично-рекурсивным функциям, значит SQL - тьюринг-полный.

_модNitro_JunkieЧем мощнее?
Параметризованные типы. Т.е. конструктор - это функция с параметрами. А ООП-наследование - простое копирование

_мод, не поймите меня неправильно, но у меня от ваших постов мозги клинит. Вы как будто хотите не объяснить, а еще больше запутать.

То есть в вашем примере x это не обозначение ребра наследования, а типа generic'а в Java? Но толку наследоваться от generic'а если интерфейсов вы все равно не знаете.

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

_модNitro_JunkieP.S.: Следуя вашей логике, нет никакой разницы между SQL, C++ и Prolog...
Между тьюринг-полными нет. Семантику любого ЯП можно описать на лиспе. Если описания совпадут то языки эквивалентны

Железно. Можно и на асемблере, а еще круче на машине Тьюринга, назад к земле так сказать.

web_fox,

Вот это все будет, когда будут примеры с описанием... Но в общем да, что-то я многовато потратил на эти абстрактные споры, пора завязывать :) Так что думаю через какое-то время продолжим начатый разговор, но уже в другой теме...

Gluk (Kazan),

Вы передергиваете, я говорил про ВСЕ бизнес-решения (или информационные системы в общем случае). Про написание драйверов, игрушек и т.п. на SQL речи не шло. Впрочем речь шла не о чистом SQL (который во многом ущербен), а о его расширении.

Gluk (Kazan)Декларативное программирование это очень хорошо (теоретически), но на практике приживается с трудом. Сие означает, что простым смертным пользоваться им неудобно . А пользователь всегда прав

Скажем так, простым пользователям (не программистам) пользоваться любой декларативной парадигмой проще чем связкой Java\C# + SQL. Во всяком случае ни одного такого пользователя не встречал, а в нашем проекте все приложение создают бизнес-аналитики (люди для которых программирование закончилось одним уроком информатики в 8 классе)