Различия и общие черты между парадигмами программирования [дубликат]
3 ответа
Безусловно, лучшие объяснения парадигм программирования можно найти в работах Питера ван Роя. Особенно в книге Питера Ван Роя и Сейфа Хариди Концепции, методы и модели компьютерного программирования . ( Вот сопутствующая вики. ) CTM использует мультипарадигмальный язык программирования Distributed Oz , чтобы представить все основные парадигмы программирования.
Питер ван Рой также сделал этот удивительный плакат, на котором показаны 34 основные парадигмы, их отношения и позиции на различных осях . Плакат - это, по сути, невероятно сжатая версия CTM.Более подробное объяснение этого плаката содержится в статье Парадигмы программирования для чайников: что должен знать каждый программист , которая появилась в качестве главы в книге Новые вычислительные парадигмы для компьютерной музыки , отредактированной Дж. Ассаяг и А. Герцо.
Другая замечательная книга, демонстрирующая несколько основных парадигм программирования, - это Структура и интерпретация компьютерных программ Гарольда Абельсона и Джеральда Джея Сассмана . Эта книга была основой CS101 Массачусетского технологического института в течение нескольких десятилетий. Курс, преподаваемый самими Абельсоном и Сассманом, был записан на корпоративном тренинге для Hewlett-Packard в 1986 году .
Основное различие между CTM и SICP состоит в том, что CTM демонстрирует большинство основных парадигм, используя язык, который их поддерживает (в основном Distributed Oz, но также и некоторые другие). SICP OTOH демонстрирует их, реализуя их на языке, который не поддерживает их изначально (подмножество Scheme). Видеть, как объектная ориентация реализована в десятке или около того строк кода, чертовски круто.
Вы можете найти видеозаписей и материалы курса весны 2005 года на веб-сайте OpenCourseWare Массачусетского технологического института . Еще одна запись курса из недолговечного проекта Университета АрсДигита Массачусетского технологического института . SICP также преподавался в других университетах, фактически он преподается в Беркли прямо сейчас .
От себя лично, мой собственный опыт показал, что на самом деле понимание парадигмы программирования возможно только
- по одной парадигме за раз и
- в языках, которые заставляют вы в парадигму
В идеале вы должны использовать язык, который доводит парадигму до крайности. В языках с несколькими парадигмами слишком легко «обмануть» и вернуться к парадигме, которая вам более удобна. А использование парадигмы в качестве библиотеки реально возможно только в таких языках, как Scheme, которые специально разработаны для такого типа программирования. Например, изучение ленивого функционального программирования на Java - не лучшая идея, хотя для этого есть библиотеки.
Вот некоторые из моих любимых:
- объектная ориентация в целом : Self
- функциональное программирование : Haskell
- чистое функциональное программирование : Haskell
- ленивое чистое функциональное программирование : Haskell
- статическое функциональное программирование : Haskell
- динамическое функциональное программирование : Clojure
- чистое функциональное программирование : Haskell
- императивное программирование : Lua
- параллельное программирование : Clojure { {1}}
- параллельное программирование с передачей сообщений : Erlang
- метапрограммирование : Схема
- языково-ориентированное программирование : Инструментальные средства Intentional Domain
Вот мой вариант:
- Функциональный программирование означает написание функций, которые принимают данные и работают с ними. Вы создаете большие приложения, собирая функции.
- Объектно-ориентированное программирование объединяет данные и их операторы в единый компонент, который хорошо отображается на ментальных моделях. Вы создаете большие приложения из взаимодействующих объектов.
- Декларативное программирование (например, SQL) отделяет то, что делается, от того, как это делается. Вы сообщаете реляционной базе данных, что вы хотите, и оставляете управление обработчиком запросов.
Ну эта ссылка пытается объяснить кое-что, что я использовал в течение последних двух десятилетий. Я упоминаю это, потому что это доказательно полезно, и я думаю, что это считается парадигмой, потому что для ее использования вам нужно думать определенным образом.
Другой способ мышления заключается в том, что при анализе проблемы, вместо того чтобы спрашивать, какие объекты существуют и какие действия происходят, вы начинаете с общих требований и спрашиваете What Needs to be Said?
Исходя из этого, вы выбираете или разрабатываете язык, специфичный для конкретной области (DSL), и излагаете свою проблему на этом языке.
По этой ссылке объясняется конкретный язык для описания динамически изменяющихся диалоговых пользовательских интерфейсов. Его реализация зависит от конкретной структуры управления, Differential Execution. Это позволяет на порядок сократить объем исходного кода, уменьшая вероятность ошибок при кодировании. Сэкономленные средства можно направить на создание более сложного пользовательского интерфейса.
Для других типов проблем подходят другие структуры управления, но концепция работы через хорошо подобранный DSL, делающий исходный код намного меньше, легче изменяемый и менее подверженный ошибкам, является общим подходом.
Я думаю, что парадигмы функционального программирования и ООП лучше всего оценивать, определяя типы проблем, для которых они являются наилучшим выражением. Зачастую эти парадигмы просто превращаются в бандвагон, и их рекламируют как панацею от всех бед, вместо того, чтобы классифицировать их по проблемным областям, которые они решают.