Товарищи бойцы!

Некоторое время назад я уже создавал тему с точно таким же названием. К сожалению, широкая общественность проигнорировала мои вопросы и тема выродилась в обсуждение ООБД как таковых, что к делу относилось весьма косвенно.

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


Итак, вопрос.

Где границы применимости той или иной парадигмы программирования? Например:
— для описания и реализации сложных задач управления лучше всего (кажется) подходит автоматное программирование (www.softcraft.ru).
— для работы со сложной (потенциально, изменяющейся) структурой данных лучше всего (кажется) подходят реляционные E-R диаграммы и РСУБД (для реализации)
— для описания сложных преобразований, например, цифровой обработки изображений, лучше всего (кажется) подходит функциональное программирование
— для реализации простых алгоритмов лучше всего (несомненно!) подходит старый добрый процедурный подход
— для реализации задач, характер эволюции которых заранее известен (например, расширяемые библиотеки, такие как оконные библиотеки, такие как, например VCL) лучше всего (кажется) подходит объектно-ориентированное программирование
— для реализации принятия решений на основании (неполной) информации о предметной области и ограничениях лучше всего (несомненно!) подходит программирование ограничениями (Prolog)


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

Особенный интерес представляют ссылки на проводившиеся НАУЧНЫЕ исследования в данной области, если таковые имели место. Также немалый интерес представляют КНИГИ по данному вопросу.

С уважением,
Борис.

Здравствуйте, Borisman2, Вы писали:

B>Итак, вопрос.

B>Где границы применимости той или иной парадигмы программирования? Например:
B> — для описания и реализации сложных задач управления лучше всего (кажется) подходит автоматное программирование (www.softcraft.ru).
Возможно. Но на всякий случай замечу, что автоматное программирование не противоречит оъектно-ориентированному (паттерн "Состояние").

B> — для работы со сложной (потенциально, изменяющейся) структурой данных лучше всего (кажется) подходят реляционные E-R диаграммы и РСУБД (для реализации)
На счет ЕР согласен, а вот на счет РСУБД нет.
http://www.citforum.ru/database/articles/art_24.shtml

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

Другим серьезным ограничением реляционных систем являются их относительно слабые возможности по части представления семантики приложения. Самое большее, что обеспечивают реляционные СУБД,- это возможность формулирования и поддержки ограничений целостности данных. Как мы отмечали в лекции 6, после проектирования реляционной базы данных многие знания проектировщика остаются зафиксированными в лучшем случае на бумаге по причине отсутствия в системе соответствующих выразительных средств.

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

B> — для описания сложных преобразований, например, цифровой обработки изображений, лучше всего (кажется) подходит функциональное программирование
согласен

B> — для реализации простых алгоритмов лучше всего (несомненно!) подходит старый добрый процедурный подход
тоже согласен

B> — для реализации задач, характер эволюции которых заранее известен (например, расширяемые библиотеки, такие как оконные библиотеки, такие как, например VCL) лучше всего (кажется) подходит объектно-ориентированное программирование
Да. И дело не только в неизвестном характере эводюции. ИМХО, ООП помогает справляться с "проклятием выбора". Это когда есть сложная задача, которую кажется, что можно решить огромным количеством способов, и изначально не понятно, какие из этих способов ошибочны. ООП с одной стороны предлагает метод естественной декомпозиции, а с другой помогает строить очень гибкий дизайн, благодаря которому не так страшно совершать ошибки. Вот.

Здравствуйте, prVovik, Вы писали:

V>Здравствуйте, Borisman2, Вы писали:

B>>Итак, вопрос.

B>>Где границы применимости той или иной парадигмы программирования? Например:
B>> — для описания и реализации сложных задач управления лучше всего (кажется) подходит автоматное программирование (www.softcraft.ru).
V>Возможно. Но на всякий случай замечу, что автоматное программирование не противоречит оъектно-ориентированному (паттерн "Состояние").
Мне кажется, автоматное программирование может быть реализовано при помощи ООП, так ? Конечно, не противоречит. Можно всегда обозвать автомат таким специальным объектом... Но тем не менее, это ОЧЕНЬ РАЗНЫЕ концепции.

B>> — для работы со сложной (потенциально, изменяющейся) структурой данных лучше всего (кажется) подходят реляционные E-R диаграммы и РСУБД (для реализации)
V>На счет ЕР согласен, а вот на счет РСУБД нет.
V>http://www.citforum.ru/database/articles/art_24.shtml
Вот! Уже лучше. Значит сфера применения реляционной теории уже гораздо уже.

Здравствуйте, prVovik, Вы писали:

V>Другим серьезным ограничением реляционных систем являются их относительно слабые возможности по части представления семантики приложения. Самое большее, что обеспечивают реляционные СУБД,- это возможность формулирования и поддержки ограничений целостности данных. Как мы отмечали в лекции 6, после проектирования реляционной базы данных многие знания проектировщика остаются зафиксированными в лучшем случае на бумаге по причине отсутствия в системе соответствующих выразительных средств.
Таким образом, РСУБД должны использоваться для хранения ДАННЫХ, причем толком создать ограничения может и не получиться вовсе. Запомним.

Добрый день!

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

Нет?

Здравствуйте, Borisman2, Вы писали:

B> — для описания и реализации сложных задач управления лучше всего (кажется) подходит автоматное программирование (www.softcraft.ru).

ООП и автоматы совершенно ортогональны и нисколько друг другу не мешают

B> — для работы со сложной (потенциально, изменяющейся) структурой данных лучше всего (кажется) подходят реляционные E-R диаграммы и РСУБД (для реализации)

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

B> — для описания сложных преобразований, например, цифровой обработки изображений, лучше всего (кажется) подходит функциональное программирование

вполне вероятно. Да и для алгоритмов на графах тоже, я думаю.

B> — для реализации простых алгоритмов лучше всего (несомненно!) подходит старый добрый процедурный подход

... который так же несомненно является подмножеством ООП

B> — для реализации принятия решений на основании (неполной) информации о предметной области и ограничениях лучше всего (несомненно!) подходит программирование ограничениями (Prolog)

Согласен.

Здравствуйте, Borisman2, Вы писали:

B>Товарищи бойцы!

Более или менее полный список существующих парадигм программирования есть в данной книжке. "Основы программирования" Непейвода.
http://ulm.udsu.ru/~nnn/index.html
P.S. Автор, кажется, забыл АОП. Почему кажется ? Давно читал, а смотреть лень

BiТ пишет:

> B>Товарищи бойцы!
> Более или менее полный список существующих парадигм программирования
> есть в данной книжке. "Основы программирования" Непейвода.
> http://ulm.udsu.ru/~nnn/index.html <http://ulm.udsu.ru/%7Ennn/index.html&gt;
> P.S. Автор, кажется, забыл АОП. Почему кажется ? Давно читал, а
> смотреть лень

Список парадигм в этой книге далеко не полный, но основные действительно
рассмотрены. Вообще, хорошая книга в качестве "энциклопедии
программирования".

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, BiТ, Вы писали:

BiТ>Более или менее полный список существующих парадигм программирования есть в данной книжке. "Основы программирования" Непейвода.
BiТ>http://ulm.udsu.ru/~nnn/index.html
Пасибо, покачал и почитаю .
BiТ>P.S. Автор, кажется, забыл АОП. Почему кажется ? Давно читал, а смотреть лень
Ну, не велика потеря. АОП ИМХО вообще лишь прибамбас для исправления траблов с ООП %))
Ну или более точно, проблемы того, что существет много способов декомпозиции предметной области.
ПОка что на парадигму не тянет

Здравствуйте, Borisman2, Вы писали:

B>Ну, не велика потеря. АОП ИМХО вообще лишь прибамбас для исправления траблов с ООП %))

скажем точнее — для исправления проблем декомпозиции в любой парадигме. К примеру, для ФП тоже существует АОП.