Ответ на »сообщение 3203« (Руслан Богатырев)
___________________________

Интересно, а есть ли среди известных языков якобы декларативного плана такие, где нет ни миллиграмма императивности?

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

Такие языки. как Брейнфак, J, K - не в счёт, хотя на такой эзотерике, как K , написана вроде как самая быстрая реляционная база данных kdb ...

Ответ на »сообщение 3202« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3200« (Руслан Богатырев)
___________________________
С модулями или без - в императивном языке задача будет решаться одним и тем же образом, компоновка будет другая.
С модулями или без в функциональном языке задача будет решаться одним и тем же образом, компоновка будет другая.
...Более того не влияют вообще как вы подходите к решению задачи.

Джек, а это что понимать под "к решению задачи"...
Решение задачи программиста в общем случае - это успешное обеспечение жизненного цикла целевой программной системы. Можно прекрасно составить всю алгоритмическую часть... Но архитектуры нет - нет и жизненного цикла, система через полгода ушла на помойку. Задача не решена.

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

И модуль в Хаскеле и модуль в Обероне - это "две большие разницы". Потому что архитектурная нагрузка у них разная. Модуль же - это не просто единица упаковки функций и типов...
Мейнстримовское ООП вообще модульной парадигмы не признает, ибо у них "великие и могучие классы". Это же совершенно разные принципы к декомпозиции и связям в системе, а вы тут говорите, что "Модульность и компонентность УЖЕ победили"

Ответ на »сообщение 3203« (Руслан Богатырев)
___________________________
Входят. Модули -- это погранзастава, а не проходной двор. Сущности модульного программирования привыкли жить при диктаторском режиме, железный занавес их не напрягает.

Не буду говорить за ООП, но вот в функциональном программировании с его чистыми функциями, границы функций - это уже жесткая погранзастава. И потому модульность является естественным дополнением к ФП.

Ответ на »сообщение 3201« (Jack Of Shadows)
___________________________

Складывайте оружие и выходите из леса. :))

Ни за что. :) Партизанить интереснее. Скоро подойдут регулярные части и тогда...

Далее ни модульность ни компонентность не входят в противоречие с ООП или с ФП.

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

Я как раз таки про что что они настолько важны что без них никакой современный язык будь то ООП язык или ФЯ не обходятся.

Обходятся, модулей нет в C++, нет в Эйфеле, да и в других, где царствует namespaces, это не модули. А так, одно название. Что-то вроде клаксона: погудел и поехал с ветерком дальше.

Вы конечно можете гордо выставить флаг модульного там или компонентного программирования и пытаться "отделиться",

Да я бы давно выставил, вот только рейхстага подходящего не найду. Надо же на что-то гордо водрузить. Не лезть же в Гималаи, на Эверест.

В конце концов именно это и диктует как мыслит программист решая задачу.

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

Ответ на »сообщение 3200« (Руслан Богатырев)
___________________________
Ах да, у нас есть беспроигрышный вариант: списать в императив и точка.
А разве нет ? Никакая модульность не поможет прикрыть вам этот факт.
В конце концов именно это и диктует как мыслит программист решая задачу. Все остальное (включая и модули) уже крутится вокруг принятого решения.
С модулями или без - в императивном языке задача будет решаться одним и тем же образом, компоновка будет другая.
С модулями или без в функциональном языке задача будет решаться одним и тем же образом, компоновка будет другая.

Ответ на »сообщение 3200« (Руслан Богатырев)
___________________________
Руслан, я не про то что модульность или компонентность не важны :))
Я как раз таки про что что они настолько важны что без них никакой современный язык будь то ООП язык или ФЯ не обходятся.
То есть предмета спора нет. Есть общее направление в котором мы все (и императивщики и функциональщики) согласны двигаться.
Далее ни модульность ни компонентность не входят в противоречие с ООП или с ФП. Более того не влияют вообще как вы подходите к решению задачи. Это совершенно другой уровень. Уровень компоновки если хотите, но не уровень алгоритма.
Вы конечно можете гордо выставить флаг модульного там или компонентного программирования и пытаться "отделиться", но народ просто пожмет плечами и пройдет мимо...пройдет с теми самыми модулями и компонентами у себя в кармане.
Модульность и компонентность УЖЕ победили. Складывайте оружие и выходите из леса. :))

Ответ на »сообщение 3198« (Jack Of Shadows)
___________________________

Имеет смысл говорить о парадигмах только в том случае если они не уживаются.

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

А компонентная система вообще к чистому программированию не имеет отношения.

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

Мы тут про две парадигмы толкуем: про ООП и ФП? А как же классический Оберон, давший жизнь всему нашему "базару"? Он ведь ООП не признает, строится на модулях, ФП там и не пахнет. Ах да, у нас есть беспроигрышный вариант: списать в императив и точка.

Ответ на »сообщение 3195« (Geniepro)
___________________________

По-моему, модульное программирование также следует вынести на внеязыковый уровень.

Нет, не надо. И эволюция языков модульного программирования наглядно показала, что сама идея модуля как центральной концепции в языке, как минимум, имеет право на жизнь.

В модульном программировании основу составляют модули. Модуль -- это базовая сущность. Вокруг нее все и строится. Причем в языке, что очень важно. А то, что модули используются в языках, причисляемых к другим парадигмам, так чего тут удивляться? Я уже говорил, что чистых-то раз-два и обчелся. В ООП разве что Smalltalk, где все есть класс. А другие -- гибрид на гибриде и гибридом погоняет. Известны и модульный Smalltalk, и модульный Пролог, и модульный Лисп, и модульный Forth, и модульный Кобол, и модульный С++ ...

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

По сути остаются две парадигмы: ООП (включающее в себя императивное программирование) и ФП.

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

Насчет того, что ООП включает в себя императивное программирование, не могу согласиться. Ибо не считаю императивное программирование парадигмой в том смысле, как понимается это слово (ранее его значение подробно разъяснял).

Очень рекомендую почитать работы Алана Кея и его интервью. Там Вы найдете крайнее раздражение по поводу того, до какой ручки нынешние ОО-реформаторы довели его идеи. Если уж брать классику, то неплохо бы в ООП делать различие между ветвями Simula- и Smalltalk-. Несмотря на кажущееся сходство, у них разная философия. Smalltalk -- это язык message-ориентированный, где каждый класс мыслится как самостоятельный маленький компьютер. В этом и была изюминка идеи Кея. Ну а если в основе языка лежит поток сообщений и реакция на них (коммутация на уровне сообщений, а не вызовы методов -- очень большая разница), то почему Вы вдруг решили, что это императивное программирование? Потому что так сказал аксакал Страуструп? Кстати, Обероны в этом отношении куда ближе к идеям Smalltalk, чем многие супер-пупер-ОО-языки.

Я думаю плодить сущности (парадигмы) нет никакой нужды.
Имеет смысл говорить о парадигмах только в том случае если они не уживаются.
В этом плане существуют только 2 парадигмы - императивная, с победившей ипостасью в лице ООП, и функциональная.
Что касается модульного и компонентного подхода то они не противоречат ни ООП ни ФП, и потому присутствуют практически во всех языках (в той или иной степени)
Geniepro уже приводил примеры очень развитой модульной системы в хаскеле и окамле.
А компонентная система вообще к чистому программированию не имеет отношения.
Это схема сборки, схема компоновки, причем изначально специалисты имели в виду компоновку при помощи внешних инстрмуентов (сред).
То есть речь идет о создании инфраструктуры для поддержки "черных ящиков" которые можно легко и удобно стыковать друг с другом, но НЕ ПРИ ПОМОЩИ языка, а с помошью каких то внешних инструментов.
Естественно такая техника может быть "посажена" на любую достаточно мощную платформу. Дельфи, java, dotnet все это примеры коммерческих сред с встроенными компонентыми механизмами.
Даже старый ActiveX - тоже компонентная модель, пусть и не такая развитая.

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

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

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