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

Ясно, что у всех названных парадигм программирования есть свои плюсы и минусы.

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

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

В словаре Merriam-Webster для слова "парадигма", имеющего латинские корни (paradigma), предлагаются следующие интересующие нас трактовки:
1. Пример (example), шаблон (pattern); ясный или типичный пример
2. Философский или теоретический базис (framework) научной школы или дисциплины, внутри которого сформулированы поддерживающие его теории, законы, обобщения и экспериментальные данные. В более широком смысле: философский или теоретический базис любого вида.

Нередко в качестве заменителя слова "парадигма" используют такие понятия, как "подход", "направление", "стиль", "метод", "методология". Причем применительно к парадигме программирования мне часто попадалось в западных источниках именно соответствие слову style. Т.е. размытость термина близка к максимуму.

Здесь были затронуты 4 парадигмы:
1. Объектно-ориентированное программирование (ООП)
2. Функциональное программирование (ФП)
3. Модульное программирование (МП)
4. Компонентно-ориентиованное программирование (КОП)

Неплохо бы выбрать некие эталоны-книги ведущих специалистов этих направлений, где парадигмы представлены достаточно полно. Для ООП я бы предложил бы книгу Бертрана Мейера (Object-Oriented Software Construction), для МП -- Владислава Турского ("Computer Programming Methodology"), для КОП -- Клеменс Шиперски ("Component Software: Beyond Object-Oriented Programming"). Первые две есть в переводе на русский язык.

Для ФП -- вопрос к Джеку (желательно, одну-единственную).

Коротко суть этих парадигм характеризуется базисной сущностью: класс (ООП), функция (ФП), модуль (МП), компонент (КОП). Аксиоматика строится вокруг этого базиса.

Если мы взглянем на конкретные языки -- представители парадигм, то увидим, что вся эта четверка присутствует едва ли не в каждом. Даже компоненты, которые просто воспринимаются как бинарные/исполняемые блоки в контексте исполняющей системы или же ОС (те же EXE/DLL). Функция берет корни в математике, модуль и компонент -- в инженерном деле, класс -- в информационных моделях (не напрасно в Дании школа Дала-Нигаарда развивала направление datalogy).

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

Из оставшейся тройки сейчас очевидный перекос в сторону ООП. Тогда как ООП как раз является, пожалуй, наиболее агрессивной формой, внутри которой ФП и МП не могут самостоятельно существовать, а растворяются в универсальной отмычке под названием "класс". МП предлагает, пожалуй, наиболее нейтральную базисную сущность, а потому может рассматриваться как стартовая точка практически для любого проекта. Плюс служит гарантией минимизации проблем при работе в условиях неопределенности или крайне сжатых сроках разработки.

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

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

Ответ на »сообщение 3174« (Сергей Тарасов)
___________________________
По моему это чисто социальное явление и не имеет отношения к ООП или каким то другим изменениям в программировании.
В конце концов на VB можно и сегодня писать в самом кондовом процедурном стиле, не заморачиваясь никакими обьектами.

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

Такое чувство, что собрались побеседовать лебедь, рак и щука. :)
Точнее, сторонники модульного (Руслан Богатырев), объектно-ориентированного (Сергей Перовский) и функционального (Jack Of Shadows) программирования.
Ясно, что у всех названных парадигм программирования есть свои плюсы и минусы.
За Сергея Перовского я относительно спокоен: на его стороне структура любой устоявшейся предметной области.
Коллеги, а вам не кажется, например, что ООП фактически вытеснило из профессии женщин? :)
Шутки шутками, но взгляните на 15-20 лет назад.
Во времена Clipper и FoxPro программированием занималось большое количество представителей "слабого" пола. Хотя в том же клиппере никаких RAD-средств не было.

Собственно, я ориентируюсь на 2 ключевых высказывания, некогда услышанными мною в беседах от разных людей (с).
1. Пока обычная девчонка после ПТУ не сможет запрограммировать прикладную задачу, значит есть большая проблема
2. "Я понала, что такое классы, но не поняла, зачем они нужны"

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

Но как только мы хотим получить объекты со своим локальным состоянием, то мы вынуждены ввести присваивание, отказаться от принципа "прозрачности по ссылкам" и ввести модель "вычислений с окружением" вместо простой "подстановочной модели".
Что просто, на первый взгляд, перечеркивает все принципы ФП и вытекающие из них перспективы.
По видимому, ФП пытается решить эту проблему путем разделения функциональных и императивных конструкций в Хаскеле с помощью монад (немного сходно с тем, как в Обероне, решается вопрос с loopholes -- требуется использование специальной конструкции, псевдомодуля SYSTEM). Но, IMHO, остается фактом, что нельзя получить объекты в рамках чистого функционального программирования.

Jack Of Shadows уже как-то предлагал (тут или не тут, не помню) обратить внимание на статьи Криса Окасаки.

Chris Okasaki, "Functional Data Structures"
"Purely Functional Data Structures"
"Purely Functional Random-Access Lists"
"Simple and Efficient Purely Functional Queues and Deques"
ну и в том же духе...

Чистое функциональное программирование предполагает работу с чистыми же функциональными структурами данных.

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

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

Это ощущение прямо и огромно противоречит тому факту, что info21, угробивший больше здоровья, чем кто-либо, на продвижение ОТ -- quintessentially прикладной программист.

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

Или они не видят в функциональном подходе никаких недостатков (эффективность сейчас не в счет)?


Недостатки ФП навскидку (эффективность и требования к рессурсам не рассматриваем, правильно ?)

1. Невозможность чистого ФП, приходится "опускаться" до императива.
2. Сравнительная (с ИЯ) сложность обучения.
3. Все недостатки императивного подхода (поскольку к нему ПРИХОДИТСЯ прибегать) ТАМ где к нему приходится прибегать.
4. Исторически сложившаяся бедность (по сравнению с mainstream языками) библиотеками и тулзами (средами)
5. Невозможность обеспечить индустрию достаточным количеством специалистов. При чем я не знаю вызвано ли это повышенной сложностью работы с ФП или же отсутствием необходимой инфраструктуры (повальное обучение, коммерческие среды и библиотеки) То есть лечится это со временем или нет.

Такое чувство, что собрались побеседовать лебедь, рак и щука. :)
Точнее, сторонники модульного (Руслан Богатырев), объектно-ориентированного (Сергей Перовский) и функционального (Jack Of Shadows) программирования.
Ясно, что у всех названных парадигм программирования есть свои плюсы и минусы.
За Сергея Перовского я относительно спокоен: на его стороне структура любой устоявшейся предметной области.
А вот что касается модульного и функционального подхода, то для каждого из них следует определить область применения.
Утверждается, модульный подход (особенно в его обероновском варианте) связан с архитектурой развивающихся больших программных комплексов, особенно -- операционных систем и компонентных платформ. Короче, "программирование в большом", требующее дополнительной (по сравнению с "прикладным" ООП) гибкости.
Область применения функционального подхода очерчена (пока) менее ясно. Здесь надежды на автоматическое распараллеливание программ для многоядерных процессоров и на перспективы верификации программ. Короче, подход, который должен проявить себя во всем блеске в (ближайшем?) будущем. :)

Но вот что особо привлекает мое внимание к соревнованию этих двух подходов.
При чтении классиков (Абельсон и Сассман, SICP, 3.1.2.Преимущества присваивания) невольно создается впечатление, что эти подходы противоречат друг другу.
Т.е. до определенного момента у ФП с модульностью все хорошо: отсутствие побочных эффектов, локальные (вложенные) объявления функций и переменных.
Но как только мы хотим получить объекты со своим локальным состоянием, то мы вынуждены ввести присваивание, отказаться от принципа "прозрачности по ссылкам" и ввести модель "вычислений с окружением" вместо простой "подстановочной модели".
Что просто, на первый взгляд, перечеркивает все принципы ФП и вытекающие из них перспективы.
По видимому, ФП пытается решить эту проблему путем разделения функциональных и императивных конструкций в Хаскеле с помощью монад (немного сходно с тем, как в Обероне, решается вопрос с loopholes -- требуется использование специальной конструкции, псевдомодуля SYSTEM). Но, IMHO, остается фактом, что нельзя получить объекты в рамках чистого функционального программирования.
Вполне возможно, это не является такой уж проблемой для функциональщиков. Мне это неизвестно. Я только опираюсь на мнение Абельсона и Сассмана, что собственно ФП в их учебнике к третьей главе уже заканчивается.

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

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

Лично у меня скепсис к применению ФЯ в системной сфере (а прикладной я не занимаюсь)

В книге "История Хаскелла: будучи ленивым и с классами" (Paul Hudak сотоварищи, "A History of Haskell: being lazy with class") упоминается, как ещё тридцать лет назад на чистом ленивом ФЯ SASL (один из предков Хаскелла) в фирме Burroughs создали операционную систему - первый пример чистого ленивого функционального программирования "в большом".
К сожалению, я не нашёл подробностей об этом проекте...

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

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

Ежели из него это делает Microsoft, то мы-то при чем? :) На самом деле выпячивание любого подхода, который своей жирной массой затмевает все остальное разумное, мягко говоря, не хорошо. У любого подхода есть недостатки, изъяны применительно к решаемым задачам и условиям использования.

Про ООП уже говорил. Давайте затроним и компонентное программирование (component-oriented programming). В принципе для обсуждения необязательно даже фиксировать взгляд Шиперского.

Компоненты -- это самостоятельные единицы исполняемого кода (вне зависимости от того, в каком виде представлены -- исходном, бинарном), к которым предъявляются определенные требования (например, по Шиперски: information hiding, polymorphism, late binding, safety). Компоненты обычно подразумевают отчуждаемость от  разработчика (т.е. их могут использовать сторонние лица, не знающие деталей проектирования и реализации). Отчуждаемость диктует повышенные требования к безопасности. Компоненты предназначены для композиционного включения в разъемы среды исполнения. Для этой цели они предлагают интерфейсы или даже контракты (более жесткая по требованиям форма интерфейсов).

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

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

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

Т.е. сварганить компонент для наружного употребления несложно, а добиться его reusability в среде сторонних разработчиков уже непросто. Пока компоненты условно/частично отчуждаемы (например, однородны с точки зрения операционного каркаса, к которому их привинчивают) и относительно прозрачны в формировании внешних разъемов (понятны посторонним), то у них есть надежда на reusability. К компонентам можно относиться как к черным ящикам (black-box; есть только интерфейс, что внутри -- неизвестно). Можно считать, что black-box компоненты имеют бинарную форму. Другая крайность -- white-box компоненты, т.е. когда доступны и все исходники. Есть и компромиссные "полупрозрачные" варианты (напр., grey-box в трактовке Вольфганга Века).

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

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

Недостатки? Их не так мало. Отчуждаемость, полупрозрачность, композиционность, безопасность (инварианты) -- вот лишь некоторые аспекты, критичные для применения компонентного подхода. На мой взгляд, ряд проблем можно снивелировать при наложении ограничений на компонентный подход (напр., в определенной мере зафиксировав язык(и) реализации и/или операционный каркас (более узкое понятие, чем среда/платформа исполнения).

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

Ответ на »сообщение 3165« (Илья Ермаков)
___________________________
Лично у меня скепсис к применению ФЯ в системной сфере (а прикладной я не занимаюсь) по другой причине - слишком много от "чистой" математики.
А какие задачи конкретно ?
Если написание языков, то вроде народ наоборот хвалит хаскель как наиболее подходящий для этого.
Например prel 6 "Pugs" пишется на хаскеле.

Базы данных ? Для хаскеля пример привести не могу, но на эрланге есть Mnesia, которая используется в очень больших системах.
Операционные системы ? Опять же erlang

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

Однако ни в коем случае не считайте что я вас к чему то там призываю. Вы как раз делаете совершенно правильно, останавливаетесь на том что для вас работает, с чем вы чувствуете себя удобно, комфортно.
И то что эти же задачи можно решать как то еще, к вопросу конечно никакого отношения не имеет.
Главное найти свой инструмент. И у вас по моему с этим проблем нет.