Успешный непрограммист, 5GL, визуальный, 0 исходных кодов или подобные инструменты?

Может любой давать мне пример успешного непрограммиста, 5GL (не, что я уверен, каковы они!), визуальный, 0 исходных кодов или подобные инструменты, которые бизнес-пользователи или аналитики могут использовать для создавания приложений?
Я не полагаю, что существует, и я хотел бы быть доказанным неправым.

В компании, в которой я работаю, мы разработали внутренний MVC, который мы используем для разработки веб-приложений. Это - в основном уменьшенный конечный автомат, записанный в XML (а-ля Spring WebFlow) для контроллера и простого основанного на шаблоне механизма для презентации. Некоторые преимущества:

• динамический характер: никакая потребность перекомпилировать для наблюдения изменений
• уменьшенная “семантическая загрузка”: в основном действия в контроллере знают только “Если”. Поэтому легко обучить кого-то разрабатывать приложения.

Современная тенденция в компании (или по крайней мере на уровне управления) состоит в том, чтобы попытаться произвести инструменты для платформы, которые требуют 0 исходных кодов, визуальны и т.д. Это имеет хороший эффект на клиенты (или по крайней мере на уровне управления) с тех пор:

• они могут быть убеждены, что этот способ, которым они не будут нуждаться ни в каких программистах или по крайней мере смогут нанять end-of-the-lather программистов, которые стоят намного меньше, чем типичные программисты.
• Кажется, что существует сниженный включенный риск, так как инструмент ограничивает реализатора, или пользователь (просто не используют программиста слова!) в том, что он может сделать, таким образом, существует менее случайное, что он может представить ошибку
• Это, кажется, упрощает целую проблему, так как, кажется, нет никакого программирования, включенного (известно сложный). Так как приложения загружаются динамично, существует меньше сложности, затем обычно связанной с жизненным циклом J2EE: компиляция, пакет, развертывается и т.д.

Я - лично скептик, что что-то вроде этого может быть достигнуто. Решение, которое мы имеем сегодня, имеет много проблем:

• Реализаторы пишут, код JavaScript для обогащения страниц (мог быть решен путем разработки виджетов). Хотя клиентский, все еще код, который может стать очень сложным и привести к некоторым трудным ошибкам.
• Уже существует визуальный инструмент, но реализаторы предпочитают редактировать XML, так как это более быстро и легче. Для сравнения я предполагаю не, многие используют плагин Eclipse Spring WebFlow для редактирования потока XML.
• Существует очень плохое повторное использование в решении (на основе вставки копии XML). Это препятствует производительности и некоторым другим аспектам, как содействие знаниям о бизнесе.
• Была многочисленная производительность и другие проблемы на основе неправильного использования инструментов. Неважно, насколько уменьшенный playfield, всегда существует пространство для ошибки.
• В то время как платформа, вероятно, более продуктивна, чем Struts, я сомневаюсь, что это более продуктивно, чем сегодняшние веб-платформы RAD как RoR или Grails.
• Многословие

Исторически, в этом направлении были многочисленные отказы. Идея программ, записанных непрограммистами, стара, но AFAIK, никогда не успешный. На определенном уровне что-либо кроме питания исходного кода становится незаменимым. Сегодня, существует большой разговор о DSLs, но не как что-то, что непрограммисты должны записать, больше как что-то, что они могли считать.

Мне кажется, что компания направления берет, в этом отношении тупик. Что Вы думаете?

Править: Это стоит отметить (и это - то, куда некоторые insipiration прибывают из), что многие крупные игроки экспериментируют в том направлении. Посмотрите Microsoft Popfly, Google Sites, iRise, много решений для Мэшапа и т.д.