Разделить GUI между программистами и дизайнерами

Когда-то давно vitus_wagner устраивал у себя обсуждение на тему того, что GUI в юниксовом мире нарушает традиции этих самых юниксов в том смысле, что консольные проги можно интегрировать в сложные комплексы только за счет использования стандартного текстового ввода-вывода и башевских скриптов, а GUI слабо поддается подобным действиям.
Т.е. "есть окно и в него можно только долбится мышью, а автоматизировать - исключительно или консольными прогами, работающими с той же сущностью, или через адские жопные API".
Ну, с юниксовыми GUI тут понятно - они вместо того, чтобы подумать и сделать правильно, начали отвечать на критику из макоебско-виндовского графического мира методом "усремся, наиндусячим, но наделаем в лоб графических интерфейсов, чтобы было красиво как у них".
В виндах микрософт что-то пытался делать на эту тему (DDE, OLE всякие) но нихера хорошего с этого не вышло - получились монстрообразные С++ API с tight coupling, в которые в здравом уме никто не полезет.

Кроме того, недавно zelanton пропагандировал разделение труда между программистами и дизайнерами интерфейса, но практика показывает, что все сводится к "дизайнер нарисовал гламурную хрень, а теперь вы это запрограммируйте, как хотите, потому как я макоеб творческая личность, в вашем программировании не разбираюсь".

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

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

Я пару раз пытался такое сделать, оно частично даже работало, но в итоге всегда оказывалось, что "вот именно тут нужно отказаться от фреймворка и сделать все руками в дизайнере, так будет быстрее". Т.е. протекающая абстракция. Ну и для работы со строго типизированным API использованные языки малость печальны - на дельфи не было нормального RTTI, рефлекшен в .NET вроде нормально, но все быстро сводилось к тому, что на одну проперть объекта вешалось 100 атрибутов для расширения типа, а ФП и теорию типизации я тогда толком не знал.

Ну и вообще интерпретация типов в рунтайме для генерации GUI охрененно неудобна, сделать то же самое в виде кодогенерации было бы намного лучше в плане результата, но теоретически тянет за собой тоже всякое вуду.
Вообще еще проблема в том, что в моих data-centric приложения типы полей постоянно зависят от данных вводимых в рунтайме. К примеру - поле какой-нибудь платежки, хранящее ссылку на предприятие-клиента, можно сделать типом объекта "предприятие", но тогда сериализация объекта и тому подобные действия превращаются в идиотизм, а можно сделать точно так же как в базе данных - численный тип с ограничением "могут быть только значения присутствующие в поле первичного ключа таблицы предприятий", и это приходится проверять повсюду в коде.

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

На тему убитых котов

Когда же они, взломав ветхую дверь, проникли внутрь, то увидели только два дочиста объеденных скелета да ползающих в темных углах тараканов.

Зависимые типы

Решительно непонятно, как можно программировать на языке без dependent types.
Хм, как это я до сих пор во френды sorhed не добавил.
А без зависимых типов мы так и будем топтаться между ООП, ORM и закатом солнца рисованием гуя вручную, но я теорию даже обычных типов с трудом осознаю, а до зависимых вообще еще не добрался.

Безумие

Читаю туториал по агде, на третей же странице перепутаны or и and. Т.е написано or, а определение дано от and.

N900

vitus_wagner купил себе N900. У него сейчас срач на эту тему.

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