gudleifr писал(а):
Дыры-то затыкать, все равно, было надо.
Я на это и хочу обратить внимание. Дыры-то ведь тоже на самом деле объективны. Можно относиться к проблемам по-разному, в том числе и как к досадному препятствию с точки зрения предыдущего поколения методов программирования. Но если рассматривать вопрос более широко, то кажущийся чрезмерный перекос в "неправильную" сторону на деле может быть вызван другими причинами, лежащими за пределами восприятия отдельно взятого программиста.
gudleifr писал(а):
Такая возможность была, например, в Framework (1984) и даже MS Works (чуть позже?) - и даже с поддержкой сетевой работы (того времени). Framework даже умел не только вставлять документы, но и производить вычисления, используя их как источники данных/кода.
Я не изучал историю внедрения офисных пакетов Microsoft (тем более что интересно внедрение как раз не у нас, западный-то рынок существенно больше влияет на требования к софту). Однако думается, что возможность быстрого освоения офисного пакета офисным же работником весьма и весьма важна. А вот какие усилия придется приложить программисту, уже менее важно. Это вопрос затрат на программистов. И если одному программисту хочется, чтобы как можно больше кода проходило через его руки, то увы, его мнение вторично.
gudleifr писал(а):
Опять же, при чем тут "визуальное программирование"?
Использовать ActiveX и DirectX я могу и не "визуально", а честно дергая за API.
Я предлагал Вам сравнить не технический уровень железа, на котором запускали Lotus тогда и Excell сейчас, а их способность к эффективному решению типовых задач.
Напрямую ни при чем. Вопрос унификации требований к интерфейсам. Старые игры под DOS имели внушительный список поддерживаемых звуковых карт. Базовый адрес 220H, IRQ 5, DMA 1 - помните сочетание? А теперь можно представить проблему настройки, растиражированную на организацию с большим парком компьютеров. Визуальные средства здесь побочны, на уровне "положите вот этот компонент на форму, и у вас во всех программах будет одинаковое диалоговое окно настройки принтера". С точки зрения программиста, можно создать такое окно вызовами API. Заодно уменьшить размер кода и что-нибудь оптимизировать. С точки зрения системы выпуска ПО - лучше не надо, иначе на каждую программу придется дообучать IT-поддержку в компаниях-пользователях.
gudleifr писал(а):
А я о чем? Сначала внедряем ОС, требующую танцев с бубном, а потом - регулярно отстегиваем ассоциации шаманов, за новые бубны.
Но тогда бы Windows исчезла с рынка, нет? Не зря же сейчас Microsoft обращает внимание на такой параметр, как "стоимость владения". И не зря так много нареканий на бородато-свитератых линуксоидов, которые пытаются по-хозяйски расположиться в компаниях, понимая в их работе только то, что "там есть компьютеры, с которых надо срочно снести глюкавую винду". Да, я понимаю, что может быть привлекательным думать о таком мире, в котором к программистам будут приходить с поклоном и униженно просить помочь нажать на правильную кнопочку.
gudleifr писал(а):
Вы хотели сказать "отсутствия автоматизации"? "Визуальные обезьянники" ориентированы на ручной рутинный труд, только немного сократив его объемы за счет запрета программировать и автоматизировать.
Автоматизацию рутинных задач. Если есть компонент, то должны быть генераторы событий и их обработчики. Я не вижу здесь чего-то сакрального и подлежащего постоянному переосмыслению. Избыточный размер программы? Ну что ж, что получилось, то и получилось.
gudleifr писал(а):
Их нет - все силы уходят на ручное рисование.
Это недостаток подхода как такового. К визуальным конструкторам форм (Visual Studio, Borland/Embarcadero, Qt creator) могу добавить Labview. Те же претензии - упрощенное конструирование воспринимается не как элемент автоматизации рутинных действий и средство быстрого создания прототипа, а как полноценный инструмент, задающий (!) правила проектирования. Отсюда и подход "раз этого нет среди визуальных компонентов, это вообще нельзя сделать". Разумеется, и наличие этих претензий точно так же объективно, как и сам факт наличия Labview и его развития. Вопрос только в том, что из всего этого надо не недостатки собирать, а достоинства.