Nitro_Junkie_мод,

То что альтернатив SQL в плане декларативных языков нет мы в курсе... И у него кстати масса недостатков, одного факта того, что он не с объектами и свойствами работает а таблицами и строками уже достаточно, что его нельзя самого по себе использовать в разработке бизнес-приложений...

Хм, а я таблицы рассматриваю как раз как массивы объектов, а поля как свойства. Именно поэтому не позволяю программистам именовать таблицы во множественном числе, потому что плохо читается SELECT Apples.colour FROM. Да, у таких объектов нет методов. Но, в Оракле, например, можно создавать таблицы объектов с методами (хотя работать с этим всем практически невозможно, т.к. сейчас у них слишком много ограничений), а в Постгрессе схемы можно расматривать как объекты с методами (а в следующей версии у этих "объектов" даже появятся свойства). Кстати, очевидно ваше сравнение объекты-свойства и таблицы-строки не коректно.

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

Nitro_Junkieтиповые настройки делают бизнес-аналитики... без программистов... то есть вообще без программистов... Конечно если возникнет вопрос с подключением симплекс-методов и иже с ними там надо будет использовать точки входа и подключать программистов, но например в управлении торговлей, расчетами, CRM и т.п. таких вопросов не возникает... А в конечном итоге, предполагается что формы будут создавать сами пользователи, а особо продвинутые пользователи и бизнес-логику
Интересную задачу вы берёте. В принципе, это как упростить в компании пирамиду, убрать, так сказать, лишние слои абстракции и подчинить всех рабочих сразу генеральному директору. Хотя, мнение, что отношение Java\C# + SQL далекто от оптимального у меня сомнений не вызывает, улучшать есть что, и даже в революционном смысле.

авторIt will be like changing from assembler and native code bits to high-level programming languages—even better, because, as Doug says, every person (business user) will be, in a certain way, a programmer, because business-expert users will be creating applications
Если честно, - пустые слова, чистый маркетинг. Совершенно очевидно, что бизнес-пользователь, даже на просто SQL ничего серьёзного не напишет, - придётся стать программистом. Куда усложнять то? Да чего уж там душой кривить, даже бизнес-процес в IDEF0 будет сидеть и долго разглядывать... Возможным подходом может стать визард, но уж очень продвинутый, страшно представить насколько :) Потому что у пользователей не так хорошо получается придумывать решения, но сравнительно хорошо получается описывать проблемы - между этими двумя шагами великая работа.