Ответ на »сообщение 3132« (Сергей Перовский)
___________________________

Глядя на представителей инженерного слоя в современном программировании, не устаю удивляться тому, насколько абсолютизировано ООП. В строительстве основой основ является сопромат. А в программировании? UML и ООП – это здорово, просто замечательно, естетически выверено (почти как знаменитые черные-красные-белые квадраты Казимира Малевича). Но где же сопромат?

В Советском Союзе была блестящая школа, которая создавала этот сопромат, но теперь все позабыто-позаброшено. Какие там схемы коммутации, конечные автоматы, сети Петри? Что это там за операторные схемы Ляпунова-Янова, асинхронные модели Котова-Нариньяни, ситуационное программирование и суперкомпиляция Турчина, смешанные вычисления Ершова?..

У нас в почете классы-отряды-роды-виды Карла Линнея, философия зоологии Жана-Батиста Ламарка, клеточная теория Маттиаса Шлейдена и Теодора Шванна, теория эволюции Чарльза Дарвина, гибридизация и законы наследования Грегора Менделя, мутации и пангены Гуго де Фриза, наконец, концепция наследственности-изменчивости-видообразования Трофима Денисовича Лысенко.

В программировании XXI в. генетика сменила кибернетику. Ирония судьбы: одна гонимая наука погребла под собой другую...

Ответ на »сообщение 3130« (Сергей Перовский)
___________________________

Ответ на »сообщение 3128« (Руслан Богатырев)
Например, восторг от динамической замены модулей "без перезагрузки!", "без перекомпиляции!" абсолютно понятен для системных программистов, но совершенно не трогает программистов прикладных.

Стоит им поразрабатывать GUI в Блэкбоксе, как уже трогает, поверьте :-)
После этого необходимость при добавлении кнопки на форму пересобирать программу и заново ее запускать на тестирование в традиционных IDE воспринимается как анахронизм....

Ответ на »сообщение 3131« (Руслан Богатырев)
___________________________
Друг мой, Аркадий, не говори красиво(с)
>>>Монтирование ведется исключительно в терминах классов со всеми уже не раз обсуждавшимися проблемами.
Единственной реальной проблемой является низкий средний уровень аналитиков и архитекторов, точнее их практическое отсутствие в большинстве мейнстримовских проектов. Если мейнстрим перейдет на компонентное, функциональное или какое нибудь иррациональное программирование его качество принципиально не изменится и мы будем на примере множества нелепых решений показывать недостатки компонентного, функционального или иррационального программирования. 

>>>Так уж сложились тенденции мирового программирования последнего полутора десятка лет, что наибольшее внимание уделяется интерактивному пользовательскому интерфейсу
Давайте отделять мух от котлет. С одной стороны у этого процесса есть вполне объективные причины: актуальными стали задачи, решаемые во взаимодействии человека и компьютера. С другой стороны есть и стремление отличаться оригинальным интерфейсом у тех, кому нечего вложить в программу по сути.

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

>>>А они сплошь и рядом пали жертвой гегемонии ООП.
Хотелось бы понять, кого Вы считаете сварщиком от программирования и что с ним такое страшное случилось.

Ответ на »сообщение 3130« (Сергей Перовский)
___________________________

У меня все больше создается ощущение, что все идеи ОТ ориентированы на системное программирование.

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

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

КП и BlackBox (среди всех Оберонов) претендуют именно на эту нишу, равно как и ОТ. Непонимание их достоинств со стороны масс есть следствие упрощенческого взгляда на то, что КП только и занимается, что имитированием ООП, т.е. в понимании стороннего наблюдателя (чье мировоззрение сформировано в лучших традициях пропаганды Лени Рифеншталь), выступает в роли "примитивной подделки".

Так уж сложились тенденции мирового программирования последнего полутора десятка лет, что наибольшее внимание уделяется интерактивному пользовательскому интерфейсу -- UI (TUI, GUI и иже с ними). А здесь-то ООП наряду с модельным каркасом (как инструмент быстрого макетирования) предстает во всей своей красе. В строительстве есть такая специальность: облицовщик-плиточник. У меня сложилось впечатление, что мы живем в эпоху искусственно подогретого спроса именно на эту специальность в программировании.

А как насчет ГАПов и ГИПов (главных архитекторов проекта и главных инженеров проекта)? Как быть с рядовыми прорабами, арматурщиками, бетонщиками, слесарями, плотниками, монтажниками, сварщиками, электриками, с инженерами по организации работ и надзору за строительством и т.д. и т.п.? А они сплошь и рядом пали жертвой гегемонии ООП.

Что касается архитекторов, то как и в строительстве, они большей частью любят парить в небесах. Но если инженеры их там опускают на грешную землю (эфемерно-абстрактные фантазии вынуждены воплощать
в материально осязаемом), то в программировании союз архитекторов-плиточников сродни символу народного единения, смычки города и деревни, блестяще воплощенного в памятнике Веры Мухиной ("Рабочий и колхозница"). Куда уж тут грешным инженерам кластерно-модульного программирования, когда кругом кипят котлы таких гигантских всемирных коммунистических строек ООП?

Ответ на »сообщение 3128« (Руслан Богатырев)
___________________________
>>>Многие, наверно, давно осознали, что внутри классического Оберона как бы два языка -- алгоритмический язык (без использования SYSTEM) и язык системного программирования (с использованием SYSTEM и локализацией там "внеязыкового" уровня абстракций).
И это вызывает споры на ровном месте именно в силу разных требований к этим языкам.
Например, восторг от динамической замены модулей "без перезагрузки!", "без перекомпиляции!" абсолютно понятен для системных программистов, но совершенно не трогает программистов прикладных.
У меня все больше создается ощущение, что все идеи ОТ ориентированы на системное программирование.

Ответ на »сообщение 3124« (Илья Ермаков)
___________________________
>>>А по поводу исключения наследования реализации из языка - это слишком радикальная мера. Для базовых классов Frameworkов это наследование очень полезно.
С этого места, пожалуйста, поподробнее.
Где именно Вы видите границу между "очень полезно" и "очень опасно"?

Ответ на »сообщение 3122« (Антон Григорьев)
___________________________

Значит ли это, что теперь пора сделать следующий шаг и разработать новый язык - преемник Оберона, в котором будет запрещён небезопасный экспорт неабстрактных типов? Чтобы компилятор требовал сокрытия реализации внутри модуля?

Непростой вопрос. Если брать классический Оберон, то в нем есть определенные уязвимости-недочеты, которые имело бы смысл как-то подправить. Например, Вирт склонялся к тому, чтобы не было одновременно read-write и read-only экспорта. С его точки зрения, весь экспорт должен быть автоматически read-only. А если нужно править импортируемые переменные (для типов, констант и процедур понятие read-write экспорта смысла не имеет), то будьте любезны работать через посредников.

Уязвимость на границе модулей проявляется для тех же процедурных переменных и для наследования реализации. В первом случае возникает ситуация, когда модули играют роль подгружаемо-выгружаемых блоков памяти, по которым нет того контроля, что ведется автоматическим сборщиком мусора (закоммутировались на конкретную процудуру, а потом бац -- "вторая смена", модуль выгрузили). Значит, присваивания процедурным переменным должны быть жестко трассируемыми.

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

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

Многие, наверно, давно осознали, что внутри классического Оберона как бы два языка -- алгоритмический язык (без использования SYSTEM) и язык системного программирования (с использованием SYSTEM и локализацией там "внеязыкового" уровня абстракций). Для синтезирующего и конкретизирующего программирования (по Ершову) этого вполне достаточно. Да и сам Оберон-модуль -- хорошая капсула (уж лучше и нейтральнее класса) для помещения в нее инородных тел (в смысле языков других парадигм).

Для сборочного же программирования, на уровне кластеров (кустов модулей, каркасов) -- не хватат. Нужен язык сборок и модульной композиции, включая контроль инвариантов. Скорее всего, этот уровень должен быть асинхронно-декларативный, а не синхронно-императивный. Это видимо епархия языков декларативной природы и встраивать такой контроль в "ново-Оберон" смысла, пожалуй, нет.

Ответ на »сообщение 3126« (Илья Ермаков)
___________________________

Пока не покажешь наглядно, чтоб глаза на лоб полезли, так и будут спорить...

Ну вот так и надо - со скриншотами и популярными объяснениями... :о))

Вы тут расхваливали свою мультимедию - а где можно увидеть хотя бы несколько самых впечатляющих скриншотов её?