GUI. Программерская печаль.

[metaclass]

Автоматическая генерация GUI

Там приведены ссылки на существующие фреймворки. Из них вроде только XAML и XUL пригодны для изготовления интерфейса для обычных прог, а не веб-морд.

(Веб-программизм, кстати, ЗАДРАЛ, кого не спроси - все занимаются этим безумием. Кто будет линиями на ком-порту рулить, я вас спрашиваю? ActiveX, загружаемый со странички, которому надо полсистемы безопасности подкрутить, чтобы он заработал?)

И еще обратите внимание - речь идет о автоматической генерации, а все фреймворки просто заменяют код или ресурсы для форм внутри проги какими-то скриптами или xml-файлами, но ведь эти долбанные скрипты все равно надо или руками набрать или в говновизуальном дизайнере индусами нарисовать. Фиг ВАМ, а не автоматическая генерация. Покупайте индусов, белые господа, они все нарисуют.


Или ведь откройте любую книгу по обучению программированию - хотя бы в одной было написано, как писать программы правильно, то бишь максимально повторно используемо. ХРЕН ТАМ НА ЛЫСЫЙ ЧЕРЕП! "Положите на форму DataGrid, положите DataSet, положите соедиение, пропишите все в их свойствах, в том числе и строку коннекта к серверу и запросы и даже названия полей таблицы."
Нужна новая форма, отличающаяся одним полем в запросе? Не вопрос, создаем копию существующих файлов, правим, итд. И так 10000 раз, пока не получим "IFSSAPR/3OEBS1СГалактику". Ах, да, надо чтобы у клиентов формы менять не перекомпилируя. Не проблема - встраиваем птичий императивный язык, встраиваем птичий декларативный язык описания форм, собственный генератор отчетов, собственный обработчик OLAP-кубофф(переделываем из шахматной ведомости) , делаем говновизуальный редактор, нанимаем индусов выпускников ПТУ Программирования и те на "языке предметной области, понятном аналитикам" рисуют формы, опять 10000 штук во всех вариациях.
Ах, да, я забыл, у нас же клавиатурой и текстовым кодом пользоваться не модно. Выпускаем очередную версию, теперь можно рисовать алгоритмы мышкой в виде блок-схем. А еще можно прямо в программу встроить Rational Rose, в ней рисовать, потом генерить промежуточные файлы, впихивать это все прямо в базу оракла, а потом еще обработчики на PLSQL писать
В итоге получаем клиническое говно, в котором могут разобраться только высокооплачиваемые сектанты, прошедшие зомбирование на специальных курсах производителей и внедрение которого стоит дороже, чем написание заказной системы.

Comments

[vp.livejournal.com]

Ты все очень грустно, но крайне справедливо, сформулировал

[bagamut.livejournal.com]

не бывает так чтобы одновременно хорошо и универсально, обязательно вылезает лажа

[1ceheart.livejournal.com]

> Кто будет линиями на ком-порту рулить, я вас спрашиваю?

Линиями на ком-порту буду рулить я. Вы рисуйте, рисуйте :)))

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

Ну почему же. Бек, Макконнелл, Фоулер, как минимум :)

[colonel-sokker.livejournal.com]

Что-то и я стал ненавидеть ООП. Оно отучает программеров ДУМАТЬ, и ПОНИМАТЬ, как на самом деле всё это работает.

[metaclass.livejournal.com]

Так потому что цель - научить индусов формы рисовать, а не подготовить специалистов нормальных. Если начинать учить с ООП - это капец.

[eu3eu.livejournal.com]

Вот это слив! Зачот!
Мне становится всё страннее и страннее - производительность компов растет, а программы работают все медленнее и медленнее.
Все становится понятно, если представить себе парсер, скомпилированный в байткод, выполняемый интерпретатором. Он разгребает некий открытым текстом написанный скрипт, переводит его в куски байткода. Затем другой кусок байткода (опять же, под интерпретатором) исполнит по очереди куски байткода, сгенеренные парсером. А результатом станет какая-нибудь анимированная кнопка. И с каким невероятным скрипом это все работает!

[metaclass.livejournal.com]

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

[beskov.livejournal.com]

Я рассматривал автоматическую генерацию интерфейса как одно из преимуществ MDA-подхода - построение сквозного процесса - модель предметной области + модель бизнес-процессов + модель требований (1) -> модель архитектуры + модели компонентов системы (2) -> модели интерфейса + шаблоны / модель БД / модель БЛ (3) -> код приложения (4). Причём чтобы всё это максимально работало на стандартах UML, BPMN, XML, XSD, SQL и тех, которые приведены в конце исходного поста в ру_сисарх. Чтобы проектировщик мог основываясь на (1) и (2) спроектировать XML-документ, определить правила отображения и редактирования, и используя процессор сформирвоать приложение.

Причём тут визуальные редакторы и индусы я не понял - задача сделать более управляемым весь процесс разработки, так чтобы дешёвая рабсила не понадобилась.

Про повторное использование в книгах и проч. - всё верно, везде какая-то узость мышления - "решаем текущую задачу, а после нас хоть потоп".

[beskov.livejournal.com]

Кстати, одна из причин поиска подобных MDA-решений - в одном из проектов, например, московскими индусами от IBS было написано порядка 100 кастомных, но очень похожих ASP-форм. Теперь разгрести и найти концы практически не возможно. В БД из 400 таблиц 60 лежат вообще пустые, но удалить я их не могу без предварительного анализа ASP-кода, который бы показал, что да, действительно, эти таблицы не используются.

Так что надеюсь про индусов это сарказм.

[metaclass.livejournal.com]

Да, примерно это я и имел в виду.
Про индусов это да, сарказм :)

[metaclass.livejournal.com]

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

[inv2004.livejournal.com]

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

[alex-radko.livejournal.com]

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

[kong-en-ge.livejournal.com]

Ох, ребе, как Ви там у себя правы, однако. Прямо хоть ты напиши эссе ужозов: "Если бы ситиинфу писал ЕПАМ..." :-)))

Таки не все упомянуто...

[inhate.livejournal.com]

Из неупомняутого - GLADE + любой высокоуровневый язык понимающий eval() ;)