Парадигма программирования: Что такое парадигма программирования
Парадигма программирования — Национальная библиотека им. Н. Э. Баумана
Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:42, 11 января 2019.
Парадигма программирования – это совокупность принципов, методов и понятий, определяющих способ конструирования программ.
Парадигма (философия науки) – устоявшаяся система научных взглядов, в рамках которой ведутся исследования (Т. Кун).
Парадигма определяется:
- вычислительной моделью
- базовой программной единицей(-ами)
- методами разделения абстракций [Источник 1]
Язык программирования не обязательно использует только одну парадигму. Языки, поддерживающие несколько парадигм, называются мультипарадигменными. Создатели таких языков придерживаются точки зрения, гласящей, что ни одна парадигма не может быть одинаково эффективной для всех задач, и следует позволять программисту выбирать лучший стиль программирования для решения каждой отдельной задачи.
История
Своим современным значением в научно-технической области термин «парадигма» обязан, по-видимому, Томасу Куну и его книге «Структура научных революций». Кун называл парадигмами устоявшиеся системы научных взглядов, в рамках которых ведутся исследования. Согласно Куну, в процессе развития научной дисциплины может произойти замена одной парадигмы на другую, при этом старая парадигма ещё продолжает некоторое время существовать и даже развиваться благодаря тому, что многие её сторонники оказываются по тем или иным причинам неспособны перестроиться для работы в другой парадигме.
Термин «парадигма программирования» впервые применил в 1978 году Роберт Флойд в своей лекции лауреата премии Тьюринга. Флойд отмечает, что в программировании можно наблюдать явление, подобное парадигмам Куна, но, в отличие от них, парадигмы программирования не являются взаимоисключающими: если прогресс искусства программирования в целом требует постоянного изобретения и усовершенствования парадигм, то совершенствование искусства отдельного программиста требует, чтобы он расширял свой репертуар парадигм.
Таким образом, по мнению Роберта Флойда, в отличие от парадигм в научном мире, описанных Куном, парадигмы программирования могут сочетаться, обогащая инструментарий программиста.
Важно отметить, что парадигма программирования не определяется однозначно языком программирования; практически все современные языки программирования в той или иной мере допускают использование различных парадигм. Так на языке Си, который не является объектно-ориентированным, можно работать в соответствии с принципами объектно-ориентированного программирования, хотя это и сопряжено с определёнными сложностями; функциональное программирование можно применять при работе на любом императивном языке, в котором имеются функции (для этого достаточно не применять присваивание). [Источник 2]
Разновидности парадигмы
Парадигма программирования не определяется однозначно языком программирования; практически все современные языки программирования в той или иной мере допускают использование различных парадигм.
Так на языке Си, который не является объектно-ориентированным, можно работать в соответствии с принципами объектно-ориентированного программирования, хотя это и сопряжено с определёнными сложностями; функциональное программирование можно применять при работе на любом императивном языке, в котором имеются функции (для этого достаточно не применять присваивание), и т.д.
Императивное программирование
Императивные парадигмы программирования представляют программу как последовательность действий (операторов), которые преобразуют состояние программы. Допустимые виды операторов, а также типы обрабатываемых данных определяются конкретным языком программирования. К императивным парадигмам относится процедурная парадигма программирования., в которой отдельные группы часто повторяемых операторов выделяются в процедуры (называемые также подпрограммами), описывающие действия по переводу одних данных в другие. В число операторов таких языков входит оператор обращения к процедуре.
Вычислительная модель — машина Тьюринга.
Основные механизмы управления/абстракции:
- Последовательное исполнение команд
- Ветвление
- Безусловный переход
- Вызов подпрограммы (иногда)
Элементарные единицы модульности — отсутствуют. [Источник 3]
Структурное программирование
Структурные парадигмы программирования нацелены на сокращение времени разработки и упрощение поддержки программ за счёт использования блочных операторов и подпрограмм. Отличительной чертой структурных программ является отказ от оператора перехода (goto).
Вычислительная модель — машина Тьюринга.
Основные механизмы управления/абстракции:
- Последовательное исполнение команд
- Ветвление
- Цикл
- Вызов подпрограммы
- Лексический контекст
Элементарные единицы модульности:
- Подпрограмма с изолированным лексическим
контекстом
Объектно-ориентированное программирование
В данной парадигме программирования программа разбивается на объекты – структуры данных, состоящие из полей, описывающих состояние, и методов – подпрограмм, применяемых к объектам для изменения или запроса их состояния. В большей части объектно ориентированных парадигмах для описания объектов используются классы, объекты более высокого порядка, описывающие структуру и операции, связанные с объектами. В качестве более частной парадигмы по отношению к объектно ориентированной выделяют прототипно ориентированную парадигму. В отличие от основанных на классах объектно ориентированных систем, в прототипно ориентированных системах понятие классов не используется, а новые переменные объекты создаются путём копирования существующих прототипов. К языкам, поддерживающим объектно ориентированную парадигму программирования , относятся си++, Common Lisp (также содержит элементы функциональной парадигмы), джава, джава-скрипт (прототипно ориентированная модель).
Вычислительная модель — машина Тьюринга
Основные механизмы управления/абстракции:
- Объект
- Класс
- Иерархии классов/объектов
- Полиморфизм
Элементарные единицы модульности — класс
Функциональное программирование
Представление программы в форме набора чистых функций, порождающих результаты на основе входных данных.
Вычислительная модель — λ-исчисление
Основные механизмы управления/абстракции:
- Чистая функция, как объект первого класса
- Вызов функции (в т.ч. рекурсивный)
- Лексический контекст, замыкание
Элементарные единицы модульности:
- Функция (в т.ч. высшего порядка, обобщенная и т.д.)
Основные концепции:
Неподвижное состояние объектов
При инициализации идентификатора (переменной) ему сопоставляется некоторое значение (объект), которое не может быть изменено. При этом идентификатор с тем же самым именем может быть определен в другом лексическом контексте с другим значением.
Чистая функция (pure function) – функция не имеющая побочных эффектов, т.е. единственным эффектом ее применение является порождение результата, зависящего только от аргументов.
[Источник 3]
Логическое программирование
Методология логического программирования — подход, согласно которому программа содержит описание проблемы в терминах фактов и логических формул, а решение проблемы система выполняет с помощью механизмов логического вывода.
Логическое программирование начинает свой отсчет времени с конца 60-х годов XX века, когда Корделл Грин предложил использовать резолюцию как основу логического программирования. Алан Колмеро создал язык логического программирования Prolog в 1971 году. Логическое программирование пережило пик популярности в середине 80-х годов XX века, когда оно было положено в основу проекта разработки программного и аппаратного обеспечения вычислительных систем пятого поколения.
Важным преимуществом такого подхода является достаточно высокий уровень машинной независимости, а также возможность откатов – возвращения к предыдущей подцели при отрицательном результате анализа одного из вариантов в процессе поиска решения.
Одним из недостатков логического подхода в концептуальном плане является специфичность класса решаемых задач.
Другой недостаток практического характера состоит в сложности эффективной реализации для принятия решений в реальном времени, скажем, для систем жизнеобеспечения.
Нелинейность структуры программы является особенностью декларативного подхода и, строго говоря, представляет собой оригинальную особенность, а не объективный недостаток. [Источник 4]
Подходы и приёмы
Далее будут представлены более подробно подходы и приемы парадигмы программирования:
- Структурное программирование
- Процедурное программирование
- Обобщённое программирование
- Доказательное программирование
- Порождающее программирование
- Аспектно-ориентированное программирование
- Рекурсия
- Автоматное программирование
- Событийно-ориентированное программирование
- Компонентно-ориентированное программирование
- Грамотное программирование
Структурное программирование
Cтруктурное программирование воплощает принципы системного подхода в процессе создания и эксплуатации программного обеспечения ЭВМ. В основу структурного программирования положены следующие достаточно простые положения:
- алгоритм и программа должны составляться поэтапно (по шагам).
- сложная задача должна разбиваться на достаточно простые части, каждая из которых имеет один вход и один выход.
- логика алгоритма и программы должна опираться на минимальное число достаточно простых базовых управляющих структур.
Фундаментом структурного программирования является теорема о структурировании. Эта теорема устанавливает, что, как бы сложна ни была задача, схема соответствующей программы всегда может быть представлена с использованием ограниченного числа элементарных управляющих структур. Базовыми элементарными структурами являются структуры: следование, ветвление и повторение (цикл), любой алгоритм может быть реализован в виде композиции этих трех конструкций. [Источник 5]
Обобщённое программирование
В основе обобщенного программирования лежит использование так называемых шаблонов функций и шаблонов классов. Применение таких шаблонов связано с тем обстоятельством, что алгоритмы обработки данных часто слабо зависят от типа данных, которые они обрабатывают. Информацию о типе данных, которые следует обрабатывать, в этом случае удобно передавать через параметры, которые носят название обобщенных типов. Приведем пример шаблона функции, предназначенного для обмена значений двух переменных. . [Источник 6]
Процедурное (алгоритмическое) программирование
Процедурное программирование — есть отражение фон Неймановской архитектуры компьютера. Программа, написанная на процедурном языке, представляет собой последовательность команд, определяющих алгоритм решения задачи. Основная идея процедурного программирования — использование памяти для хранения данных. Основная команда- присвоение, с помощью которой определяется и меняется память компьютера. Программа производит преобразование содержимого памяти, изменяя его от исходного состояния к результирующему.
Преимущества и недостатки процедурного программирования:
Среди недостатков ПП можно назвать следующие:
- Риск возникновения множества ошибок при работе над большим проектом. Приходится писать много процедур, и это не может не сказаться на чистоте и работоспособности кода.
- Все данные процедуры доступны только внутри нее. Их нельзя вызвать из другого места программы и при необходимости придется писать аналогичный код. А это уже противоречит одному из основополагающих принципов программирования, который звучит как Don’t Repeat Yourself (Не повторяйся).
- Сложность изучения для начинающих. Этот недостаток может кому-то показаться притянутым за уши, но простая статистика свидетельствует, что процедурное программирование для большинства новичков дается сложнее, чем объектно-ориентированное. Преимущества:
- Любая процедура (функция) может быть вызвана неограниченное количество раз.
- Возможность оперативно решить задачу, в которой отсутствует сложная иерархия. [Источник 7]
Доказательное программирование
Доказательное программирование — это составление программ с доказательством их правильности. Сложность составления и доказательства правильности алгоритмов и программ состоит в следующем.
Для заключений о наличии ошибок в алгоритме или в программе достаточно указать тест, при котором произойдет сбой, отказ или будут получены неправильные результаты.
Поиск и исправление ошибок в программах обычно проводятся на ЭВМ.
Для утверждений о правильности программ необходимо показать, что правильные результаты будут получаться для всех допустимых данных. Такие утверждения могут быть доказаны только путем исчерпывающего анализа результатов выполнения программ при любых допустимых данных.
Существуют два подхода к проверке программ — прагматический и доказательный. При прагматическом подходе проверка программ выполняется на ЭВМ путем тестирования.
Тестирование — это проверка программ на ЭВМ с помощью некоторого набора тестов. Ясно, что тестирование не дает гарантий правильности выполнения программ на всех допустимых данных. Следовательно, тестирование в общем случае не может дать и не дает полных гарантий отсутствия ошибок в программах.
Напомним, что отладка программ — это процесс поиска и исправления ошибок в программах на ЭВМ. Однако поскольку поиск ошибок при отладке программ проводится с помощью тестов, то полных гарантий нахождения и исправления всех ошибок в программах отладка не дает и в принципе дать не может.
По этой же причине неясно, когда процесс отладки программ — процесс поиска и исправления ошибок на ЭВМ — может считаться завершенным. А выявлены или нет все ошибки в программе при ее отладке не может сказать никто.
Таким образом, прагматический подход чреват созданием программ, содержащих ошибки даже после «завершения» отладки, что и наблюдается практически во всех больших программах для ЭВМ. [Источник 8]
Порождающее программирование
Порождающее программирование (generative programming) – парадигма технологии разработки программного обеспечения, основанная на моделировании семейства программных систем, используя которые можно по конкретным техническим требованиям автоматически получить специализированный и оптимизированный промежуточный или конечный программный продукт из элементарных, многократно используемых компонентов реализации с помощью базы знаний о конфигурациях.
Порождающее программирование фокусирует внимание не на уникальных продуктах (объектах), а на семействах программных систем (классах объектов). Таким образом, порождающее программирование имеет огромное сходство с теорией универсальных и интегративных моделей, применяемых для синтеза объектов, и являющихся моделями не отдельно взятого объекта, а моделями всех объектов, принадлежащих рассматриваемому классу (моделью семейства объектов или систем). [Источник 9]
Аспектно-ориентированное программирование
Аспектно-ориентированное программирование(АОП) — это парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули.
Аспектно-ориентированное программирование выросло из осознания того, что в типовых программах на объектно-ориентированных языках часто представлена функциональность, которая не вмещается естественно в один или даже в несколько тесно связанных программных модулей. Такую функциональность называют «сквозной» (англ. scattered, разбросанная или tangled, переплетённая), её реализация рассыпана по различным модулям программы. Сфера действия АОП охватывает пространство проблем, непосильных для объектно-ориентированных и процедурных языков. Оно предлагает элегантные пути для реализации задач, решение которых сдерживалось из-за фундаментальных ограничений программирования.
АОП дополняет объектно-ориентированное программирование, обогащая его другим типом модульности, который позволяет локализовать код реализации «сквозной» логики в одном модуле. Такие модули обозначаются термином аспекты. За счет отделения аспектно-ориентированного кода работа со «сквозными» отношениями упрощается. Аспекты в системе могут изменяться, вставляться, удаляться на этапе компиляции и, более того, повторно использоваться. [Источник 10]
Рекурсия
В программировании рекурсия тесно связана с функциями, точнее именно благодаря функциям в программировании существует такое понятие как рекурсия или рекурсивная функция. Простыми словами, рекурсия – определение части функции (метода) через саму себя, то есть это функция, которая вызывает саму себя, непосредственно (в своём теле) или косвенно (через другую функцию).
У рекурсии должно быть условие остановки — Базовый случай (иначе также как и цикл рекурсия будет работать вечно — infinite). Это условие и является тем случаем к которому рекурсия идет (шаг рекурсии). При каждом шаге вызывается рекурсивная функция до тех пор пока при следующем вызове не сработает базовое условие и произойдет остановка рекурсии(а точнее возврат к последнему вызову функции). Всё решение сводится к решению базового случая. В случае, когда рекурсивная функция вызывается для решения сложной задачи (не базового случая) выполняется некоторое количество рекурсивных вызовов или шагов, с целью сведения задачи к более простой. И так до тех пор пока не получим базовое решение. [Источник 11]
Автоматное программирование
Автоматное программирование поддерживает такие этапы создания программного обеспечения как проектирование, реализация, отладка и документирование.
Особенность рассматриваемого подхода состоит в том, что при его использовании автоматы задаются графами переходов, для различения вершин в которых вводится понятие «кодирование состояний». При выборе «многозначного кодирования» с помощью одной переменной можно различить состояния, число которых совпадает со значностью выбранной переменной. Это позволило ввести в программирование такое понятие, как «наблюдаемость программ».
В рамках предлагаемого подхода программирование выполняется «через состояния», а не «через переменные» (флаги), что позволяет лучше понять и специфицировать задачу и ее составные части.
При этом необходимо отметить, что в автоматном программировании отладка проводится путем протоколирования в терминах автоматов. [Источник 12]
Событийно-ориентированное программирование
Идеология здесь основана на событиях (нажал клавишу, меню щелк). В ответ в windows генерируется подходящее сообщение, которое отсылается окну соответствующей программы.
Структура программы в событийном программировании следующая: главная часть программы представляет собой один бесконечный цикл, который опрашивает windows, следя за тем, не появилось ли новое сообщение. При его обнаружении вызывается программа, отвечающая за обработку соответственного сообщения. Цикл опроса будет продолжаться, пока не будут получены сообщения завершения работы.
События могут быть пользовательскими, системными и программными, которые генерируются самой программой. [Источник 13]
Компонентно-ориентированное программирование
Компонентно-ориентированное программирование (англ. component-oriented programming, COP) — парадигма программирования, существенным образом опирающаяся на понятие компонента — независимого модуля исходного кода программы, предназначенного для повторного использования и развёртывания и реализующегося в виде множества языковых конструкций (например, «классов» в объектно-ориентированных языках программирования), объединённых по общему признаку и организованных в соответствии с определёнными правилами и ограничениями. [Источник 14]
Грамотное программирование
Грамотное, или литературное, программирование – это экстремальная технология самодокументируемого кода, предложенная знаменитым специалистом в вычислительной технике Дональдом Кнутом. Он написал книгу под этим названием, в которой и описал эту технологию (Knuth 92). Это радикальная альтернатива традиционной модели программирования, хотя некоторые считают, что период грамотного программирования был крупной неудачей в карьере Д. Кнута.
Лежащая в основе идея проста: нужно писать не программу, а документ. Язык документации тесно привязан к языку программирования. Ваш документ в основном описывает то, что программируется, но при этом допускает компиляцию в нужную программу. Таким образом, исходный код – это документация, и наоборот. [Источник 15]
Источники
Сказка о парадигмах программирования / Хабр
Привет, друг. Удачно заглянул на огонёк ты, ибо сказку собираюсь сказать я. Об эпохах нынешней и минувшей, о пределах могущества кодерского, и о том, как в силе себе отказывая, силы достичь можно. А коли не интересна тебе тема парадигм, дальше листай и вид сделай, что не слышал о сказке моей. Зайдёшь же коли на огонёк, так знай, что словца красного ради не всегда сказитель хронологию соблюдал и на совести его перегибы все и недомолвки.
В начале было слово машинное и только дух носился над вычислителем.
Во времена далёкие те, компьютеры были велики размерами своими, программисты — возвышены и сильны, а программы их — коротки и прямы как стрела. Не существовало ничего кроме самого кода и было это хорошо.
По мере того, как программисты становились всё изощрённее, а программы множились и усложнялись, стало понятно, что могущественны программисты слишком, и что переизбыток могущества не к эпохе изобилия и процветания ведёт, но к раздору и трагедии. Творя по измышлению своему, черпали программисты силы в водах Хаоса первозданной вседозволенности, что против воли создателей, а иногда и по оной, просверливался из каждого байта машинной инструкции. Кто во что горазд творили в далёкое время то и не было видения общего и понимания.
Увидели программисты, что могущественны они слишком и от того сложно им код писать и масштабировать. И поняли они, что нужны им правила, чтобы удерживать могущество своё в рамках заданных и результаты предсказуемые получать, а не выхремунду какую. Собрались они тогда и создали парадигмы, дабы силу свою запечатать на веки вечные.
И создали они кольца, дабы могущество своё обуздать. Первым кольцом магическим стало программирование процедурное, ибо повсеместной была необходимость делать над данными раз за разом одни и те же действия. Чтобы не прописывать действия такие сто и пятьсот раз, решили выделить кусок небольшой кода, который бы выполнял очерченную работу и делал бы это хорошо. И к нему обращаться регулярно решили программисты, аки к волхву и мудрецу великому. Создали программисты процедуры, взглянули на них и поняли, что это хорошо. И пользоваться ими с тех пор стали.
Повсеместное распространение процедур и функций привело к тому, что программы довольно сильно унифицировались. Вместо раздольного хаоса первородного и всемогущества над регистрами, программисты умерили возможности свои и в код свой привнесли стиль подпрограмм и аргументов. Хотя кодеры всё еще могли вытворять с процессором всё, что производитель разрешил, они решили что преимущества процедурного стиля важнее гордости их. Ибо соблазнились они возможностью не повторять однажды написанное, возможностью ограничивать область необходимого одномоментного интеллектуального охвата, и возможностью кристально чисто вылизывать код не весь и разом, но позадачно. И отказались они от части силы своей, ибо больше не писали они иначе, нежели как парадигма им велеть стала. И эра процедурная настала.
Тем временем в мир приходили новые кодеры и не так возвышены были и сильны они как предшественники, и сложно им было в словах машинных разбираться. И тогда сообща создали себе они инструменты для того, чтобы немощь свою побороть и появились так сначала Assembler, а позже Fortran и Algol. Не модно стало кодом машинным повелевать и над процессором напрямую властвовать. Пусть компилятор трудится, говорили программисты и еще толику могущества своего поутратили и хаос поослабили. Заодно и процедурную парадигму окончательно в ранг закона возвели.
Но не унимались программисты и интеррактивности возжелали и repl технологию изобрели, чтобы делишки свои не отходя от кассы выдумывать и в жизнь претворять, и прототипы первых интерпретаторов появились во время то. И вскоре из repl-а вышли скрипты и стал мир разделён между программами машинными и скриптами интерпретируемыми и было в то время счастье, ибо всегда ясно было, где программа, а где скрипт, а не как сейчас, когда интерпретируемое компилируют, а компилируемое интерпретируют. Еще дальше программисты от железа стали и уж не знали они уже как АЛУ работает, ибо ОС появились и необязательно матчасть знать стало, о чем, впрочем, никто не горевал, покуда махали все, улыбались и радовались.
Долгим был мир в ту эпоху, но не стоял прогресс на месте. Захотели программисты не только код писать, но и читать его периодически, дабы поддерживать и масштабировать. И поняли они, что сложно им, ибо даже силы процедурного кольца недостаточно было, дабы порядок в коде навести. И пришёл тогда техношаман один, которого Дейкстра звали, и Вирт ему помогал.
Вознёс Дейкстра глас свой и впоследствии теоремой Бёма — Якопини вооружившись, надругался он над оператором goto, утвердив, что колдовство оператора сего порочно и слов магических while, for и if достаточно быть должно для хакера любого. И сказав так, изгнал goto лишив сообщество еще одного могущественного инструмента, и создали прогеры тогда кольцо структурной парадигмы, дабы подвиг шамана на веки вечные восславить. Опечалился goto, но не сдался произволу героическому, и даже сейчас нет-нет да и проскакивает он в коде иного ностальгирующего по былому величию кодера и смущает его. Стыдливо оглядывается программист, не видит ли кто, метку создаёт, goto пишет и процедуру свою в дальний файл прячет, дабы не видел никто, и слёзы тогда на глаза статического анализатора наворачиваются, когда видит он код такой, ибо не умеют статические анализаторы работать, когда парадигма не соблюдается.
Красивым стал код, табуляцией и скобочками размеченный, циклами и блоками обрамлённый. Благодарны кодеры техношаману были и теореме его и командное взаимодействие между программистами, хакерами, и кодерами налаживаться начало, ибо возможно стало не только код писать, но и читать его и даже понимать периодически.
Во время то шаманы тему искусственного интеллекта полюбили и думали думу, как мозг машинный создать, чтобы гомункулуса породить, чтоб чёрную работу делать его заставить. И создали они тогда Prolog, экспертные системы и теорию автоматического доказательства, да и под шумок парадигму еще одну изобрели и логической её назвали. Мало кто понял, что за парадигма это такая и в чем соль её и суть, но для порядку в книжечку внесли и номер присвоили. Да и забыли про неё, потому что не тянула она на парадигму, ибо узка была слишком и самобытна.
А тем временем, благодаря структурной парадигме стали команды кодеров продукты создавать и код свой множить и кодом своим делится и поняли они, что опять предел возник перед ними, ибо разваливался под собственной тяжестью код программ их, размеров определённых достигнув. Но были инженеры, глазами вооружённые и увидели они проблему задолго до того как в полный рост она стала, и созданы руками их были тогда Simula и Smalltalk, и Алан Кей речь свою произнёс. Но умна слишком речь была и смутила она программистов, детей их, и детей детей их, и увы, детей детей детей их и много еще поколений смутит и смущать будет, ибо вместо луны над водой смотрели кодеры на палец, а вместо декомпозиции и иерархии видели инкапсуляцию, полиморфизм, наследование, да описание объектов реального мира, а абстракцией во время просмотра закусывали, что конечно никакого отношения к истинной сути ООП не имело, но только внешнюю форму немного затрагивало. Опечалился тогда Алан Кей и сказал, что C++ — это не true ООП, но поздно было уже, ибо гвалт поднялся такой, что ни в сказке сказать ни пером описать.
Однако, нет-нет, но стронулось дело и не мытьём так катанием научились кодеры объектному мышлению, данные с кодом увязывали, из объектов объекты складывали и тем самым код декомпозировали и иерархически выстраивали. И интерфейсами пользоваться научились, и окончательно хорошо стало, ибо программы теперь не только на процедуры разбиты были, но и на объекты и методы их, что связность программ понизило, а простоту чтения кода повысило. А что до обмена сообщениями, о котором Алан Кей говорил, позабыли о нем, ибо решили, что негоже кодерам праведным письма писать, когда напрямую в гости ходить можно, лишь бы только интерфейс соблюдался. И на тему туже спустя время долгое эпичная срач между святым воителем Торвальдсом и мудрецом почитаемым Таненбаумом вышел, но другая история это, казалось бы не о том она вообще и к чему тут упомянута непонятно, да и дело ли нам кодерам простым в дела святых воителей и мудрецов почитаемых лезть.
С тех пор и поныне настала эпоха парадигмы объектной, и немыслимо программирование уже без объектов, но и тут недовольные оказались и говорили они слова верные, что ООП софт замедляет и избыточность его повышает и качество программ из-за того падает, ибо жёстки слишком интерфейсы и действий лишних много делать приходится, но не слушали их программисты остальные и иерархии объектов в продакшн выкатывали, и Java создали, и DotNet. А под шумок всё памятью и богомипсом закидали, дабы быстродействие повысить, и окончательно недовольным глотки заткнуть. Не модно стало бесклассовый код писать, хотя нет классов никаких в словах машинных и не было никогда, а потому всё дальше отдалялись кодеры от изначальной природы своей и не могли больше процессором на мощность полную повелевать и машиной фон Неймана от сердца к генератору тактового импульса править.
Тем временем, мужи учёные всё не унимались и споры свои вели о том, как код писать правильно, чтобы ошибок не допускать, чтоб выполнялся предсказуемо и творцов не удивлял поведением своим и норовом. И решили они, что чистота и иммутабельность есть благо, а глобальные переменные и сайдэффекты есть зло. И хорошо было это, но сказали они также, что вывод информации на экран должен оформляться как возврат из функции модифицированного объекта вселенной, что всё есть монада, что теория категорий над типами повелевает, а также, что reduce, map, select и прочие слова страшные. А под конец еще Haskell изобрели, чтобы окончательно всех запутать. Почесали затылки программисты, не поняли, что функциональное программирование это про объекты, только иммутабельные и без глобальщины, а решили, что сложно это и непонятно, а кто разобрался с ФП, тот монада какая-то заумная. Однако, концепция чистых функций неплохо зашла и научились прогеры тогда юниттесты писать, а в последствии continuos integration изобрели зачем-то.
Заметить стоит, что хотя умы ученые код математический завсегда писали, но к типам базовым термин иммутабельности неприменим особо, а потому функциональная парадигма никак не раньше объектной возникла, ибо про объекты она, а не про математику, кто бы там что не думал и не утверждал, и если программист объектно не пишет, то функционально он точно писать не сможет. Но если отказывается от изменения состояния объектов своих, то строгую логическую цепочку вывода получает, а заодно возможность кеширования и мемоизации. А всё что про монады и композиции функций, так это метод, а не результат, и палец то, а не луна. Так, вновь от части силы своей отказываясь, новые свойства коду своему кодеры придавать научились и ограничиваясь в одном, в другом сильнее становились, а хорошо это или плохо, не мне судить.
Покуда скрипты и интерпретаторы развивались, нашлись кодеры немытые, которые решили, что не хотят они процессору объяснять, как дом строить, но хотят просто говорить, каким быть тот должен и как выглядеть снаружи и интерьеру какому быть изнутри желательно. И создали они языки разметки, и xaml, и yaml, и css и много других интересных штук, и заодно web по ходу дела породили и на том декларативное программирование постулировали. А для тех неучей, кто не хотел желания свои мимолётные описывать, но как раньше хотели кирпичи складывать, презрительно всё недекларативное императивным обозвали и тем самым дихотомию императивной и декларативной парадигм породили. Посмотрели на это кодеры мытые да чистые, плечами пожали и сказали «Ну, оке… Вроде тоже хорошо».
И вот мир стал таким, каким мы его знаем и выдохнуть бы нам бы надо бы, но еще одна важная парадигма прошла мимо нас незамеченной. Не возможно было хакерам да кодерам расписать императивненько ряд задач связанных с обработкой данных, приходящих потоком непрерывным или в непредсказуемые времени моменты, ибо нельзя императивно обработать то, что непонятно когда и в каком количестве в систему падает. И создали тогда кодеры да хакеры виджеты для гуи, сервисы для вэба и конвейеры для обработки данных, и увязали react, qt, да simulink с labview в event-driven парадигму или реактивную парадигму, что одно и то же по сути своей, ибо вывернуть код пришлось им и на колбеках да конвейерах строить его. На этапе инициализации структуры обработки данных выстраивали они единожды, и после только информацию гнали через них и считали они, что хорошо это и воистину было так, ибо как по другому делать никто не знал никогда, и впредь не знает, и вряд ли когда знать будет.
Много других колец выплавили кодеры, и книжки умные писали и конференции проводили. Тут вам и аспектно-ориентированное, и компонентно-ориентированнное, и реактивно-функциональное, и прототипное, которое тоже ООП, но по-другому. Однако всегда и везде суть парадигмы в том состоит, чтоб ограничить так могущество твоё и инструменты твои, О Кодер, чтобы результат работы твоей, силу имел привнесённую, потому что свойства кода программы твоей зависят от того, какие средства ты используешь и как. Воистину сказал мудрец древний во времена до мира сотворения: Получить что-то можно только что-то отдав.
А если горестно в душе твоей стало после сказа моего о потере могущества великого, то так скажу тебе. Не злословь на предков своих, ибо дела их делались во благо и помыслы их были чисты и возвышенны. И так же как думаешь о них ты, так о тебе будут думать все внуки твои и правнуки. Если же чувствуешь силушку в себе, чтоб кольцо очередное создать и парадигму новую изобрести, дважды подумай, ибо никогда наперёд знать не можешь, какое детище твоё в веках останется.
Таков завет мой и мораль. Сказочке меж тем конец… А кто слушал — молодец.
При сложении сказки ни одна парадигма не пострадала. Пока, друг.
Парадигма программирования — Википедия. Что такое Парадигма программирования
Паради́гма программи́рования — это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером[1].
Важно отметить, что парадигма программирования не определяется однозначно языком программирования; практически все современные языки программирования в той или иной мере допускают использование различных парадигм (мультипарадигмальное программирование). Так, на языке Си, который не является объектно-ориентированным, можно работать в соответствии с принципами объектно-ориентированного программирования, хотя это и сопряжено с определёнными сложностями; функциональное программирование можно применять при работе на любом императивном языке, в котором имеются функции, и т. д.
Также важно отметить, что существующие парадигмы зачастую пересекаются друг с другом в деталях (например, модульное и объектно-ориентированное программирование), поэтому можно встретить ситуации, когда разные авторы употребляют названия из разных парадигм, говоря при этом, по сути, об одном и том же явлении.
История термина
Своим современным значением в научно-технической области термин «парадигма» обязан, по-видимому, Томасу Куну и его книге «Структура научных революций» (см. парадигма). Кун называл парадигмами устоявшиеся системы научных взглядов, в рамках которых ведутся исследования. Согласно Куну, в процессе развития научной дисциплины может произойти замена одной парадигмы на другую (как, например, геоцентрическая небесная механика Птолемея сменилась гелиоцентрической системой Коперника), при этом старая парадигма ещё продолжает некоторое время существовать и даже развиваться благодаря тому, что многие её сторонники оказываются по тем или иным причинам неспособны перестроиться для работы в другой парадигме.
Термин «парадигма программирования» впервые применил в 1978 году Роберт Флойд в своей лекции[2] лауреата премии Тьюринга.
Флойд отмечает, что в программировании можно наблюдать явление, подобное парадигмам Куна, но, в отличие от них, парадигмы программирования не являются взаимоисключающими:
Если прогресс искусства программирования в целом требует постоянного изобретения и
усовершенствования парадигм, то совершенствование искусства отдельного программиста требует, чтобы он расширял свой репертуар парадигм.
Таким образом, по мнению Роберта Флойда, в отличие от парадигм в научном мире, описанных Куном, парадигмы программирования могут сочетаться, обогащая инструментарий программиста.
Различные определения
Далеко не все авторы, использующие термин «парадигма программирования», решаются дать интенсиональное определение данному термину. Однако и те определения, которые удаётся найти, серьёзно отличаются друг от друга.
Диомидис Спинеллис даёт следующее определение[3]:
Слово «парадигма» используется в программировании для определения семейства обозначений (нотаций), разделяющих общий способ (методику) реализаций программ.
Оригинальный текст (англ.)
The word paradigm is used in computer science to talk about a family of notations that share a common way for describing program implementations
Для сравнения тот же автор приводит определения из других работ. В статье Дэниела Боброва[4] парадигма определяется как «стиль программирования как описания намерений программиста». Брюс Шрайвер (Bruce Shriver) определяет парадигму программирования как «модель или подход к решению проблемы»[5], Линда Фридман (Linda Friedman) — как «подход к решению проблем программирования».[6]
Памела Зейв (Pamela Zave) даёт определение парадигмы как «способа размышления о компьютерных системах» (в оригинале «way of thinking about computer systems»).[7]
Питер Вегнер (Peter Wegner) предлагает другой подход к определению термина парадигмы программирования. В его работе «Concepts and paradigms of object-oriented programming»[8] парадигмы определяются как «правила классификации языков программирования в соответствии с некоторыми условиями, которые могут быть проверены».
Тимоти Бадд предлагает понимать термин «парадигма» как «способ концептуализации того, что значит „производить вычисления“, и как задачи, подлежащие решению на компьютере, должны быть структурированы и организованы».[9]
Парадигма программирования как исходная концептуальная схема постановки проблем и их решения является инструментом грамматического описания фактов, событий, явлений и процессов, возможно, не существующих одновременно, но интуитивно объединяемых в общее понятие.
Основные модели программирования
Подходы и приёмы
См. также
Примечания
- ↑ Роганов, 2001, подраздел «Парадигмы программирования».
- ↑ R. W. Floyd. The Paradigms of Programming Communications of the ACM, 22(8):455—460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966—1985), М.: МИР, 1993.
- ↑ D. D. Spinellis. Programming paradigms as object classes: a structuring mechanism for multiparadigm programming. PhD thesis, University of London, London SW7 2BZ, United Kingdom, February 1994.
- ↑ D. G. Bobrow. If Prolog is the answer, what is the question. // Fifth Generation of Computer Systems, pages 138—145, Tokyo, Japan, November 1984. Institute for New Generation Computer Technology (ICOT), North-Holland.
- ↑ B. D. Shriver. Software paradigms. IEEE Software, 3(1):2, January 1986.
- ↑ L. W. Friedman. Comparative programming languages: generalizing the programming function. Prentice Hall, 1991, page 188.
- ↑ P. Zave. A compositional approach to multiparadigm programming. IEEE Software, 6(5): 15—25, September 1989.
- ↑ P. Wegner. Concepts and paradigms of object-oriented programming. {OOPS} messenger}, 1(1): 7—87, August 1990.
- ↑ T. A. Budd. Multy-Paradigm Programming in LEDA. Addison-Wesley, Reading, Massachusets, 1995.
Литература
Ссылки
Парадигмы программирования
☰
Что такое парадигма вообще? Можно сказать, что это определенный взгляд на явления окружающего мира и представление о возможных действиях с ними. В программировании под парадигмой принято понимать обобщение о том, как должна быть организована работа программы.
Среди прочего выделяют такие парадигмы программирования как директивное (структурное), объектно-ориентированное и декларативное (функционально-логическое). Многие языки поддерживают несколько парадигм программирования. С другой стороны, есть языки ориентированные исключительно на реализацию одной парадигмы.
Структурное программирование
Некоторые представители: Fortran, Pascal, C.
Директивная программа предписывает, как достичь результата, пошагово описывая действия. Поэтому такое программирование является достаточно легким для понимания.
В структурном программировании от входных данных полностью зависит последовательность выполнения команд.
В директивном программировании в свое время возникла концепция локализации части кода в так называемые подпрограммы (функции, методы), с последующим их вызовом из разных мест основной программы. При вызове в подпрограмму могут передаваться какие-либо данные в виде аргументов; а подпрограмма, в свою очередь, может возвращать в главную программу результат (т.е. полученные в ходе ее выполнения данные).
Функциональное и логическое программирование
Представители функциональных языков: List, Haskell.
Представитель логических языков: Prolog.
Декларативная программа заявляет (декларирует), что должно быть достигнуто в качестве цели. Важным является точная формулировка задачи. Программист не задает алгоритм для ее решения.
Функциональное программирование основано на математическом понятии функции, которая не изменяет свое окружение; это отличие функционального программирования от функций в структурных языках. Функциональная программа состоит из совокупности определений функций, которые в свою очередь представляют собой вызовы других функций и предложений, управляющих последовательностью вызовов. Каждая функция возвращает некоторое значение в вызвавшую его функцию, вычисление которой после этого продолжается; этот процесс повторяется до тех пор, пока не будет достигнут результат.
В логическом программировании программы выражены в виде формул математической логики, и решение задачи достигается путем вывода логических следствий из них.
Объектно-ориентированное программирование
Представители объектно-ориентированных языков: С++, Java, Python.
Особое внимание уделяется данным, которые представляются в программе в виде объектов. Объекты взаимодействуют между собой с помощью механизма передачи сообщений. Задача программиста — реализовать такие объекты, при взаимодействии которых можно будет получать желаемый результат.
ООП призвано решать более сложные и объемные задачи по сравнению с директивным программированием.
В основе ООП лежат такие понятия как наследование, полиморфизм и инкапсуляция.
Инкапсуляция предполагает, что малозначащие детали объекта скрыты. Объект, получая какую-либо команду, сам «знает» как ее обработать исходя из того, к какому классу он принадлежит.
Все объекты являются экземплярами классов, которые по отношению друг к другу могут выступать в роли родитель-потомок. Дочерние классы наследуют свойства родительского. В случае, когда 100% наследование не требуется, выручает так называемый полиморфизм, который предполагает переопределение методов родительского класса в дочерних классах.
Шаблон: Просмотр • [1]. Важно отметить, что парадигма программирования не определяется однозначно языком программирования; практически все современные языки программирования в той или иной мере допускают использование различных парадигм (мультипарадигмальное программирование). Так на языке Си, который не является объектно-ориентированным, можно работать в соответствии с принципами объектно-ориентированного программирования, хотя это и сопряжено с определёнными сложностями; функциональное программирование можно применять при работе на любом императивном языке, в котором имеются функции (для этого достаточно не применять присваивание)[источник не указан 132 дня], и т. д. Приверженность определённого человека какой-то одной парадигме иногда носит настолько сильный характер, что споры о преимуществах и недостатках различных парадигм относятся в околокомпьютерных кругах к разряду так называемых «религиозных» войн — холиваров.
История терминаСвоим современным значением в научно-технической области термин «парадигма» обязан, по-видимому, Томасу Куну и его книге «Структура научных революций» (см. парадигма). Кун называл парадигмами устоявшиеся системы научных взглядов, в рамках которых ведутся исследования. Согласно Куну, в процессе развития научной дисциплины может произойти замена одной парадигмы на другую (как, например, геоцентрическая небесная механика Птолемея сменилась гелиоцентрической системой Коперника), при этом старая парадигма ещё продолжает некоторое время существовать и даже развиваться благодаря тому, что многие её сторонники оказываются по тем или иным причинам неспособны перестроиться для работы в другой парадигме. Термин «парадигма программирования» впервые применил Роберт Флойд в своей лекции[2] лауреата премии Тьюринга. Флойд отмечает, что в программировании можно наблюдать явление, подобное парадигмам Куна, но, в отличие от них, парадигмы программирования не являются взаимоисключающими:
Таким образом, по мнению Роберта Флойда, в отличие от парадигм в научном мире, описанных Куном, парадигмы программирования могут сочетаться, обогащая инструментарий программиста. Различные определенияДалеко не все авторы, использующие термин «парадигма программирования», решаются дать интенсиональное определение данному термину. Однако и те определения, которые удаётся найти, серьёзно отличаются друг от друга. Диомидис Спинеллис даёт следующее определение[3]:
Для сравнения тот же автор приводит определения из других работ. В статье Дэниела Боброва[4] парадигма определяется как «стиль программирования как описания намерений программиста». Брюс Шрайвер (Bruce Shriver) определяет парадигму программирования как «модель или подход к решению проблемы»[5], Линда Фридман (Linda Friedman) — как «подход к решению проблем программирования».[6] Памела Зейв (Pamela Zave) даёт определение парадигмы как «способа размышления о компьютерных системах» (в оригинале «way of thinking about computer systems»).[7] Питер Вегнер (Peter Wegner) предлагает другой подход к определению термина парадигмы программирования. В его работе «Concepts and paradigms of object-oriented programming»[8] парадигмы определяются как «правила классификации языков программирования в соответствии с некоторыми условиями, которые могут быть проверены». Тимоти Бадд предлагает понимать термин «парадигма» как «способ концептуализации того, что значит „производить вычисления“, и как задачи, подлежащие решению на компьютере, должны быть структурированы и организованы».[9] Парадигма программирования как исходная концептуальная схема постановки проблем и их решения является инструментом грамматического описания фактов, событий, явлений и процессов, возможно, не существующих одновременно, но интуитивно объединяемых в общее понятие. Основные модели программированияПодходы и приёмыСм. такжеПримечания
ЛитератураКатегория:
Wikimedia Foundation.
Смотреть что такое «Парадигма программирования» в других словарях:
Книги
Другие книги по запросу «Парадигма программирования» >> |
Парадигма (программирование) — это… Что такое Парадигма (программирование)?
Паради́гма программи́рования — это совокупность идей и понятий, определяющая стиль написания программ. Парадигма, в первую очередь, определяется базовой программной единицей и самим принципом достижения модульности программы. В качестве этой единицы выступают определение (декларативное, функциональное программирование), действие (императивное программирование), правило (продукционное программирование), диаграмма переходов (автоматное программирование) и др. сущности. В современной индустрии программирования очень часто парадигма программирования определяется набором инструментов программиста, а именно, языком программирования и используемыми библиотеками.
Парадигма программирования определяет то, в каких терминах программист описывает логику программы. Например, в императивном программировании программа описывается как последовательность действий, а функциональном программировании представляется в виде выражения и множества определений функций (слово определение (англ. definition) следует понимать в математическом смысле). В популярном объектно-ориентированном программировании программу принято рассматривать как набор взаимодействующих объектов. ООП есть по сути императивное программирование, дополненное принципом инкапсуляции данных и методов в объект (принцип модульности) и наследованием (принципом повторного использования разработанного функционала).
Важно отметить, что парадигма программирования не определяется однозначно языком программирования — многие современные языки программирования являются мультипарадигменными, то есть допускают использование различных парадигм. Так на языке Си, который не является объектно-ориентированным, можно писать объектно-ориентированным образом, а на
Приверженность определённого человека какой-то одной парадигме иногда носит настолько сильный характер, что споры о преимуществах и недостатках различных парадигм относятся в околокомпьютерных кругах к разряду так называемых «религиозных» войн.
История термина
Своим современным значением в научно-технической области термин «парадигма» обязан, по-видимому, Томасу Куну и его книге «Структура научных революций» (см. парадигма). Кун называл парадигмами устоявшиеся системы научных взглядов, в рамках которых ведутся исследования. Согласно Куну, в процессе развития научной дисциплины может произойти замена одной парадигмы на другую (как, например, геоцентрическая небесная механика Птолемея сменилась гелиоцентрической системой Коперника), при этом старая парадигма ещё продолжает некоторое время существовать и даже развиваться благодаря тому, что многие её сторонники оказываются по тем или иным причинам неспособны перестроиться для работы в другой парадигме.
Термин «парадигма программирования» впервые применил Роберт Флойд в своей лекции[1] лауреата премии Тьюринга.
Флойд отмечает, что в программировании можно наблюдать явление, подобное парадигмам Куна, но, в отличие от них, парадигмы программирования не являются взаимоисключающими:
Если прогресс искусства программирования в целом требует постоянного изобретения и усовершенствования парадигм, то совершенствование искусства отдельного программиста требует, чтобы он расширял свой репертуар парадигм.
Таким образом, по мнению Роберта Флойда, в отличие от парадигм в научном мире, описанных Куном, парадигмы программирования могут сочетаться, обогащая инструментарий программиста.
Различные определения
Далеко не все авторы, использующие термин «парадигма программирования», решаются дать интенсиональное определение данному термину. Однако и те определения, которые удаётся найти, серьезно отличаются друг от друга.
Диомидис Спинеллис даёт следующее определение[2]:
Слово «парадигма» используется в программировании для определения семейства обозначений (нотаций), разделяющих общий способ (методику) реализаций программ. (В оригинале: The word paradigm is used in computer science to talk about a family of notations that share a common way for describing program implementations)
Для сравнения тот же автор приводит определения из других работ. В статье Дэниела Боброва[3] парадигма определяется как «стиль программирования как описания намерений программиста». Брюс Шрайвер (Bruce Shriver) определяет парадигму программирования как «модель или подход к решению проблемы»[4], Линда Фридман (Linda Friedman) — как «подход к решению проблем программирования».[5]
Памела Зейв (Pamela Zave) даёт определение парадигмы как «способа размышления о компьютерных системах» (в оригинале «way of thinking about computer systems»).[6]
Питер Вегнер (Peter Wegner) предлагает другой подход к определению термина парадигмы программирования. В его работе «Concepts and paradigms of object-oriented programming»[7]парадигмы определяются как «правила классификации языков программирования в соответствии с некоторыми условиями, которые могут быть проверены».
Тимоти Бадд предлагает понимать термин «парадигма» как «способ концептуализации того, что значит „производить вычисления“, и как задачи, подлежащие решению на компьютере, должны быть структурированы и организованы».[8]
Основные модели программирования
Подходы и приёмы
См. также
Примечания
- ↑ R. W. Floyd. The Paradigms of Programming Communications of the ACM, 22(8):455—460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966—1985), М.: МИР, 1993.
- ↑ D. D. Spinellis. Programming paradigms as object classes: a structuring mechanism for multiparadigm programming. PhD thesis, University of London, London SW7 2BZ, United Kingdom, February 1994.
- ↑ D. G. Bobrow. If Prolog is the answer, what is the question. // Fifth Generation of Computer Systems, pages 138—145, Tokyo, Japan, November 1984. Institute for New Generation Computer Technology (ICOT), North-Holland.
- ↑ B. D. Shriver. Software paradigms. IEEE Software, 3(1):2, January 1986.
- ↑ L. W. Friedman. Comparative programming languages: generalizing the programming function. Prentice Hall, 1991, page 188.
- ↑ P. Zave. A compositional approach to multiparadigm programming. IEEE Software, 6(5): 15—25, September 1989.
- ↑ P. Wegner. Concepts and paradigms of object-oriented programming. {OOPS} messenger}, 1(1): 7—87, August 1990.
- ↑ T. A. Budd. Multy-Paradigm Programming in LEDA. Addison-Wesley, Reading, Massachusets, 1995.
Wikimedia Foundation.
2010.
Парадигма программирования — Programming paradigm
Эта статья посвящена классификации языков программирования. Для определения термина «модель программирования» см. Модель программирования .
Парадигмы программирования — это способ классификации языков программирования на основе их характеристик. Языки можно разделить на несколько парадигм.
Некоторые парадигмы в основном связаны с последствиями для модели выполнения языка, такими как разрешение побочных эффектов или определение того, определяется ли последовательность операций моделью выполнения. Другие парадигмы связаны в основном со способом организации кода, например, с группировкой кода в блоки вместе с состоянием, которое изменяется кодом. Третьи в основном связаны со стилем синтаксиса и грамматики.
Общие парадигмы программирования включают:
- императив, в котором программист инструктирует машину, как изменить ее состояние,
- декларативный, в котором программист просто объявляет свойства желаемого результата, но не то, как его вычислить
- функционал, в котором желаемый результат декларируется как значение ряда функциональных приложений,
- логика, в которой желаемый результат декларируется как ответ на вопрос о системе фактов и правил,
- математический, в котором желаемый результат объявлен как решение задачи оптимизации
Символические методы, такие как отражение , которые позволяют программе ссылаться на себя, также могут рассматриваться как парадигма программирования. Однако это совместимо с основными парадигмами и, таким образом, само по себе не является настоящей парадигмой.
Например, языки, попадающие в императивную парадигму, имеют две основные особенности: они устанавливают порядок, в котором происходят операции, с конструкциями, которые явно контролируют этот порядок, и они допускают побочные эффекты, в которых состояние может быть изменено в один момент времени, в пределах одной единицы кода, а затем позже считываются в другой момент времени внутри другой единицы кода. Связь между модулями кода не является явной. Между тем, в объектно-ориентированном программировании код организован в объекты, которые содержат состояние, которое изменяется только кодом, который является частью объекта. Большинство объектно-ориентированных языков также являются императивными языками. Напротив, языки, соответствующие декларативной парадигме , не определяют порядок выполнения операций. Вместо этого они предоставляют ряд операций, доступных в системе, а также условия, при которых каждая из них может выполняться. Реализация языковой модели выполнения отслеживает, какие операции можно выполнять, и самостоятельно выбирает порядок. Подробнее см. Сравнение языков программирования с несколькими парадигмами .
Обзор
Обзор различных парадигм программирования от Питера Ван Роя
Подобно тому, как программная инженерия (как процесс) определяется различными методологиями , так и языки программирования (как модели вычислений) определяются разными парадигмами . Некоторые языки предназначены для поддержки одной парадигмы ( Smalltalk поддерживает объектно-ориентированное программирование, Haskell поддерживает функциональное программирование), в то время как другие языки программирования поддерживают несколько парадигм (например, Object Pascal , C ++ , Java , JavaScript , C # , Scala , Visual Basic , Common Lisp , Scheme , Perl , PHP , Python , Ruby , Wolfram Language , Oz и F # ). Например, программы, написанные на C ++, Object Pascal или PHP, могут быть чисто процедурными , чисто объектно-ориентированными или могут содержать элементы обеих или других парадигм. Разработчики программного обеспечения и программисты решают, как использовать эти элементы парадигмы.
В объектно-ориентированном программировании программы рассматриваются как набор взаимодействующих объектов. В функциональном программировании программы рассматриваются как последовательность вычислений функций без сохранения состояния. При программировании компьютеров или систем с большим количеством процессоров в процессно-ориентированном программировании программы рассматриваются как наборы параллельных процессов, которые действуют на логические общие структуры данных .
Многие парадигмы программирования известны как запрещенными методами, так и методами, которые они позволяют . Например, чистое функциональное программирование запрещает использование побочных эффектов , а структурное программирование запрещает использование оператора goto . Отчасти по этой причине новые парадигмы часто рассматриваются как доктринерские или чрезмерно жесткие теми, кто привык к прежним стилям. Тем не менее, отказ от определенных методов может облегчить понимание поведения программы и доказательство теорем о корректности программы.
Парадигмы программирования также можно сравнить с моделями программирования, которые позволяют вызывать модель выполнения , используя только API. Модели программирования также можно разделить на парадигмы в зависимости от особенностей модели выполнения.
Для параллельных вычислений часто используется модель программирования вместо языка. Причина в том, что детали параллельного оборудования просачиваются в абстракции, используемые для программирования оборудования. Это заставляет программиста отображать шаблоны в алгоритме на шаблоны в модели выполнения (которые были вставлены из-за утечки оборудования в абстракцию). Как следствие, ни один язык параллельного программирования не подходит для всех вычислительных задач. Таким образом, более удобно использовать базовый последовательный язык и вставлять вызовы API в модели параллельного выполнения через модель программирования. Такие модели параллельного программирования можно классифицировать в соответствии с абстракциями, которые отражают аппаратное обеспечение, например разделяемую память , распределенную память с передачей сообщений , понятия места, видимого в коде, и так далее. Их можно рассматривать как разновидности парадигмы программирования, применимые только к параллельным языкам и моделям программирования.
Критика
Некоторые исследователи языков программирования критикуют понятие парадигм как классификации языков программирования, например, Харпер и Кришнамурти. Они утверждают, что многие языки программирования не могут быть строго отнесены к одной парадигме, а скорее включают функции из нескольких парадигм. См. Сравнение языков программирования с несколькими парадигмами .
История
С течением времени развивались различные подходы к программированию, которые были идентифицированы как таковые либо в то время, либо ретроспективно. Ранний подход, сознательно идентифицированный как таковой, — это структурное программирование , пропагандируемое с середины 1960-х годов. Концепция «парадигмы программирования» как таковая восходит, по крайней мере, к 1978 году в лекции Роберта У. Флойда , посвященной премии Тьюринга , под названием «Парадигмы программирования» , в которой цитируется понятие парадигмы, использованное Томасом Куном в его «Структуре научного знания». Революции (1962).
Машинный код
В низшем уровне парадигм программирования машинный код , который непосредственно представляет инструкции (содержимое памяти программ) как последовательность чисел, и язык ассемблера , где машинные инструкции представлены мнемоники и адреса памяти могут быть даны символические метки. Иногда их называют языками первого и второго поколения .
В 1960-х годах были разработаны языки ассемблера для поддержки копирования библиотеки и довольно сложных условных возможностей создания макросов и предварительной обработки, CALL для ( подпрограмм ), внешних переменных и общих разделов (глобальных объектов), что позволило повторно использовать код и изолировать его от аппаратных особенностей посредством использования логических операторов, таких как READ / WRITE / GET / PUT. Сборка использовалась и до сих пор используется для критичных по времени систем и часто во встроенных системах, поскольку она дает наиболее прямой контроль над тем, что делает машина.
Процедурные языки
Следующим шагом вперед стала разработка процедурных языков . Эти языки третьего поколения (первые описываются как языки высокого уровня ) используют словарный запас, связанный с решаемой проблемой. Например,
- COmmon Business Oriented Language ( COBOL ) — использует такие термины, как файл , перемещение и копирование .
- FORmula TRANslation ( FORTRAN ) — используя терминологию математического языка, он был разработан в основном для научных и инженерных задач.
- Алгоритмический язык ( АЛГОЛ ) — ориентирован на то, чтобы быть подходящим языком для определения алгоритмов , используя терминологию математического языка для решения научных и инженерных задач, как и FORTRAN.
- Programming Language One ( PL / I ) — гибридный коммерчески-научный язык общего назначения, поддерживающий указатели .
- Универсальный код символьных инструкций для начинающих ( BASIC ) — он был разработан, чтобы дать возможность большему количеству людей писать программы.
- C — язык программирования общего назначения, первоначально разработанный Деннисом Ричи в период с 1969 по 1973 год в AT&T Bell Labs .
Все эти языки следуют процедурной парадигме. То есть они шаг за шагом описывают именно ту процедуру, которой, по крайней мере, по мнению конкретного программиста, следует следовать для решения конкретной проблемы. Следовательно, эффективность и действенность любого такого решения полностью субъективны и сильно зависят от опыта, изобретательности и способностей этого программиста.
Объектно-ориентированного программирования
Вслед за широким использованием процедурных языков были созданы языки объектно-ориентированного программирования (ООП), такие как Simula , Smalltalk , C ++ , C # , Eiffel , PHP и Java . В этих языках данные и методы для управления ими хранятся как одна единица, называемая объектом . Благодаря идеальной инкапсуляции , одной из отличительных черт ООП, единственный способ, которым другой объект или пользователь может получить доступ к данным, — это методы объекта . Таким образом, внутренняя работа объекта может быть изменена без воздействия на какой-либо код, который использует объект. Существует еще некоторые споры , поднятые Александр Степанов , Ричард Столлман и другими программистами, касающейся эффективности парадигмы ООП в сравнении с процедурной парадигмой. Необходимость для каждого объекта иметь ассоциативные методы заставляет некоторых скептиков связывать ООП с раздутием программного обеспечения ; попытка разрешить эту дилемму пришла через полиморфизм .
Поскольку объектно-ориентированное программирование считается парадигмой, а не языком, можно создать даже объектно-ориентированный язык ассемблера. Сборка высокого уровня (HLA) является примером этого, который полностью поддерживает расширенные типы данных и объектно-ориентированное программирование на языке ассемблера, несмотря на его раннее происхождение. Таким образом, различные парадигмы программирования можно рассматривать скорее как мотивационные мемы их сторонников, а не обязательно как отражение прогресса от одного уровня к другому. Точное сравнение эффективности конкурирующих парадигм часто затрудняется из-за новой и отличающейся терминологии, применяемой к аналогичным объектам и процессам, а также из-за многочисленных различий в реализации на разных языках.
Дальнейшие парадигмы
Грамотное программирование , как форма императивного программирования , структурирует программы как ориентированную на человека сеть, как в гипертекстовом эссе: документация является неотъемлемой частью программы, и программа структурирована в соответствии с логикой изложения, а не удобством компилятора.
Независимо от императивной ветви были разработаны парадигмы декларативного программирования . На этих языках компьютеру сообщается, в чем проблема, а не как ее решить — программа структурирована как набор свойств, которые необходимо найти в ожидаемом результате, а не как процедура, которой нужно следовать. Учитывая базу данных или набор правил, компьютер пытается найти решение, соответствующее всем желаемым свойствам. Архетипом декларативного языка является язык SQL четвертого поколения и семейство функциональных языков и логического программирования.
Функциональное программирование — это подмножество декларативного программирования. Программы, написанные с использованием этой парадигмы, используют функции , блоки кода, предназначенные для работы как математические функции . Функциональные языки не рекомендуют изменять значение переменных посредством присваивания , вместо этого широко применяя рекурсию .
Логика программирования парадигма рассматривает вычисление в автоматизированном рассуждения над телом знаний. Факты о предметной области выражаются в виде логических формул, а программы выполняются путем применения к ним правил вывода до тех пор, пока не будет найден ответ на проблему или пока набор формул не окажется несогласованным.
Символическое программирование — это парадигма, которая описывает программы, способные манипулировать формулами и программными компонентами как данными. Таким образом, программы могут эффективно модифицировать себя и «учиться», делая их пригодными для таких приложений, как искусственный интеллект , экспертные системы , обработка естественного языка и компьютерные игры. Языки, поддерживающие эту парадигму, включают Лисп и Пролог .
Дифференцируемое программирование структурирует программы таким образом, чтобы их можно было различать повсюду, обычно посредством автоматического различения .
Поддержка нескольких парадигм
Большинство языков программирования поддерживают несколько парадигм программирования, чтобы позволить программистам использовать наиболее подходящий стиль программирования и связанные языковые конструкции для данной работы.
Смотрите также
Ссылки
внешние ссылки
Парадигма программирования — Простая английская Википедия, бесплатная энциклопедия
Парадигмы программирования — это способ группировки языков программирования по тому, что они делают. Языки могут относиться к нескольким парадигмам.
Некоторые парадигмы рассматривают способ выполнения кода, например, разрешение побочных эффектов или необходимость выполнять действия в определенном порядке. Другие парадигмы смотрят на способ группировки кода, например, разделение кода на одну или две части (или вместо этого на множество маленьких частей). Некоторые другие парадигмы рассматривают порядок и части, которые делают программу такой, какая она есть.
Есть две основные группы парадигм: императив и декларативный . Язык может быть и тем, и другим одновременно. [1] [2]
Императивное программирование [изменить | изменить источник]
В императивных программах программисты дают компьютеру набор упорядоченных шагов , которые необходимо выполнить, чтобы что-то сделать. Если кто-то хочет, чтобы компьютер нарисовал морду кошки, он может дать указания вроде «Нарисуйте круг здесь, нарисуйте два круга поменьше, нарисуйте два треугольника сверху» и так далее.Императивные программы иногда имеют много побочных эффектов.
Есть две основные императивные парадигмы, и в большинстве случаев язык будет иметь обе:
Декларативное программирование [изменить | изменить источник]
В декларативной парадигме программист сообщает компьютеру , что делать , вместо , как это делать . Если они хотят, чтобы компьютер рисовал морду кошки, они могут дать указания вроде «Нарисуйте морду, нарисуйте два глаза, два уха и рот».
Наиболее известные декларативные парадигмы: [3]
- Функциональные — Большая часть работы выполняется функциями без побочных эффектов.
- Логика — Излагается набор фактов, а затем задается один или несколько «вопросов».
- Управляемый событиями — фрагменты кода запускаются при определенных событиях (например, при включении компьютера).
Другие парадигмы [изменить | изменить источник]
Некоторые парадигмы можно найти как в императивных языках , так и в декларативных языках . Эти парадигмы обычно встречаются с одной из вышеперечисленных парадигм, а не сами по себе.
- Параллельно: одновременно выполняется несколько фрагментов кода.
- Мета: Особые элементы языка позволяют программисту изменять способ работы самого языка.
Обзор различных парадигм программирования в соответствии с Питером Ван Роем [4] : 5 [5]
Языки программирования сгруппированы по парадигмам так же, как машины могут быть сгруппированы по тому, для чего они используются.
Несколько языков вписываются в одну основную парадигму, например:
Однако большинство языков принадлежат более чем одной парадигме.Вот некоторые из них, которые отличаются наличием более одного:
- Scala (объектно-ориентированный, функциональный, параллельный)
- Visual Basic (событийно-ориентированный, объектно-ориентированный)
- Common Lisp (процедурный, функциональный, объектно-ориентированный, мета)
- Схема (функциональная, процедурная, мета)
- Perl (функциональный, процедурный, мета, объектно-ориентированный, управляемый событиями)
- Python (функциональный, объектно-ориентированный, процедурный)
- Ruby (функциональный, объектно-ориентированный, процедурный)
- Язык Wolfram Language (функциональный, процедурный, в целом декларативный)
- унций (логическая, функциональная, императивная, объектно-ориентированная)
- F # (функциональный, императивный, объектно-ориентированный, мета)
Наличие большего количества парадигм не всегда хорошо.Один раз, когда меньше парадигм может быть хорошо, это когда есть язык, который является только функциональным. Функция на одном из этих языков иногда выполняет меньше работы (например, перебирает только те части группы вещей, которые ей действительно необходимы), чем это могло бы быть, если бы язык также был процедурным. [6]
Многие парадигмы программирования так же хорошо известны тем, что они не позволяют делать людям, позволяют людям делать то, что они делают. Один раз, когда это правда, — функциональные языки.Когда функциональный язык только или в основном функциональный, он обычно не допускает побочных эффектов. [6] Другой случай, когда это верно, — это структурированное программирование: оно отличается от обычных императивных языков, потому что не позволяет программистам использовать «операторы перехода» (операторы, указывающие программе перейти к более раннему шагу). По этой и другим причинам люди иногда думают, что новые парадигмы не позволяют делать достаточно вещей. [7] Иногда это нормально, если компьютер не позволяет людям что-то делать: это может помочь людям избежать проблем с кодом и позволить компьютеру догадываться, что он может выполнять код быстрее, или даже проверять код на проблемы до запуска кода!
Некоторым людям, изучающим языки программирования, не нравится, что парадигмы используются для группировки языков программирования, таких как Harper [8] и Krishnamurthi. [9] Эти люди говорят, что многие языки программирования нельзя просто сгруппировать в парадигмы, потому что языки заимствуют вещи и идеи из множества парадигм.
Новые парадигмы создавались с течением времени, и люди указывали на них либо тогда, либо оглядываясь назад. Одной из первых парадигм, которая была признана новым способом программирования, было структурное программирование 1960-х годов. Идея «парадигмы программирования» возникла в 1978 году, если не раньше, когда Роберт У.Флойд использовал его во время обучения. Слово «парадигма» в том смысле, в каком его имел в виду Роберт, впервые было использовано Томасом Куном в его книге « Структура научных революций » (1962). [10]
Машинный код [изменить | изменить источник]
Самый низкий уровень (наиболее близкий к тому, как компьютер любит понимать вещи) и самая старая парадигма программирования — это машинный код, [11] императивная парадигма. Направления в машинном коде — это просто набор чисел в определенном порядке.Язык ассемблера немного менее низкоуровневый (и немного менее старый). На ассемблере указаниям для компьютера даются мнемонические символы (имена, которые легче запомнить), а адресам памяти (указания для поиска части информации в компьютере) можно давать имена. Иногда их называют языками первого и второго поколения.
В 1960-х годах языки ассемблера были улучшены за счет добавления новых вещей, таких как COPY библиотеки, макросов (биты «специального» кода, которые были преобразованы в обычный код перед запуском программы), [12] выполняемых процедур (наборы направлениям присвоено имя и сохранено на будущее), а также переменные (элементы, получившие имена и сохраненные на будущее) извне программы.Это позволяет людям использовать некоторый код в более чем одном проекте и не беспокоиться о проблемах, связанных с оборудованием (проблемы, которые возникают только на одном компьютере) благодаря командам (названиям направлений), таким как READ / WRITE / GET / PUT .
Сборка использовалась, а иногда и до сих пор используется в системах, где важно, чтобы код был быстрым, а также часто используется во встроенных системах, поскольку позволяет пользователю точно контролировать то, что делает машина.
Процедурные языки [изменить | изменить источник]
В самом конце 1960-х годов люди начали изобретать процедурные языки.В этих языках третьего поколения (первых нескольких из того, что мы сейчас называем языками высокого уровня) были слова, связанные с тем, что они пытались решить. Например,
- COmmon Business Oriented Language (COBOL) — использует такие слова, как файл, перемещение и копирование. [13]
- FORmula TRANslation (FORTRAN) — использует математические слова и символы (формы, используемые при письме и наборе текста). Он был разработан в основном для науки и техники.
- ALGOrithmic Language (ALGOL) — предназначен для написания алгоритмов (набор шагов, говорящих компьютеру, что делать).Он использует математические слова и символы, как и ФОРТРАН.
- Programming Language One (PL / I) — должен был быть полезен всем.
- Универсальный код символьных инструкций для начинающих (BASIC) — создан, чтобы помочь начинающим программам.
- C — язык программирования, предназначенный для многих вещей. Деннис Ричи работал над ним с 1969 по 1973 год в AT&T Bell Labs.
Объектно-ориентированное программирование [изменить | изменить источник]
После того, как многие люди начали использовать процедурные языки, они изобрели объектно-ориентированные языки программирования.В этих языках данные и их «методы» (способы манипулирования данными) помещаются в один «объект». Некоторые программисты, такие как Ричард Столлман, [14] , не согласны с тем, что объектно-ориентированные языки лучше подходят для объяснения идей компьютеру, чем процедурные языки.
Поскольку объектно-ориентированное программирование — это парадигма, а не язык, люди создали объектно-ориентированные языки ассемблера, такие как HLA (сборка высокого уровня).
Декларативные парадигмы [изменить | изменить источник]
В то же время некоторые люди создавали декларативные языки программирования.Язык, который известен своей декларативностью, — это SQL (язык для добавления и удаления элементов из таблиц).
- ↑ Майкл А. Ковингтон (23.08.2010). «CSCI / ARTI 4540/6540: Первая лекция по символическому программированию и LISP» (PDF). Университет Джорджии. Архивировано из оригинального (PDF) 07 марта 2012 года. Проверено 20 ноября 2013.
- ↑ Нёрмарк, Курт. Обзор четырех основных парадигм программирования . Университет Ольборга, 9 мая 2011 г. Проверено 22 сентября 2012 г.
- ↑ Франс Коенен (1999-10-11). «Характеристики декларативных языков программирования». cgi.csc.liv.ac.uk . Проверено 20 февраля 2014.
- ↑ Питер Ван Рой (12 мая 2009 г.). «Парадигмы программирования для чайников: что должен знать каждый программист» (PDF). info.ucl.ac.be. Проверено 27 января 2014.
- ↑ Питер Ван-Рой; Сейф Хариди (2004). Концепции, методы и модели компьютерного программирования . MIT Press. ISBN 978-0-262-22069-9 .
- ↑ 6,0 6,1 Худак, Пол (сентябрь 1989 г.). «Концепция, развитие и применение языков функционального программирования». Цифровая библиотека ACM .
- ↑ Франк Рубин (март 1987 г.). «Признано вредным для себя» Считается вредным »(PDF). Связь с ACM . 30 (3): 195–196. DOI: 10,1145 / 214748,315722. Архивировано из оригинального (PDF) 20 марта 2009 года.
- ↑ Харпер, Роберт (1 мая 2017 г.).«Что такое парадигма программирования?». Пятнадцать Восемьдесят Четыре . Издательство Кембриджского университета.
- ↑ Кришнамурти, Шрирам (ноябрь 2008 г.). «Обучение языкам программирования в постлиннейскую эпоху». СИГПЛАН . ACM. С. 81–83. Не. 43, 11. .
- ↑ Флойд Р. У. (1979). «Парадигмы программирования». Связь с ACM . 22 (8): 455. DOI: 10.1145 / 359138.359140.
- ↑ «Информатика — языки программирования». Британская энциклопедия . Проверено 29 декабря 2018.
- ↑ Маурер, Уорд (14 мая 1969 г.). «Скомпилированный макроассемблер» (PDF). Весенняя совместная вычислительная конференция AFIPS .
- ↑ Маккинсон, Томас Н. (1961-08-01). «КОБОЛ: пример проблемы». Связь с ACM . 4 (8): 340–346. DOI: 10.1145 / 366678.366687. ISSN 0001-0782.
- ↑ «Наследование режимов, клонирование, перехватчики и ООП (обсуждение в группах Google)».
.
Что такое парадигма программирования? (с иллюстрациями)
Компьютерные программисты превратились из первых дней языков первого поколения с битовой обработкой в сложных логических проектировщиков сложных программных приложений. Парадигма программирования — это логический подход, используемый в разработке программного обеспечения, который описывает, как реализован язык программирования. Парадигмы программирования уникальны для каждого языка в области компьютерного программирования, и многие языки программирования используют несколько парадигм.Термин «парадигма» лучше всего описать как «образец или модель». Следовательно, парадигма программирования может быть определена как шаблон или модель, используемая в языке программирования для создания программных приложений.
Каждый язык программирования имеет свои собственные парадигмы программирования.
Языки программирования чрезвычайно логичны и следуют стандартным правилам математики. У каждого языка есть уникальный метод применения этих правил, особенно в отношении функций, переменных, методов и объектов. Есть много парадигм программирования; примеры включают объектно-ориентированное, процедурное и структурированное программирование. Каждая парадигма предъявляет уникальные требования к использованию и абстракции процессов в языке программирования.
C ++ — широко используемый язык компьютерного программирования, поддерживающий несколько парадигм.
Полезно понять историю языка программирования и программного обеспечения в целом, чтобы лучше понять концепцию парадигмы программирования. На заре разработки программного обеспечения инженерия программного обеспечения завершалась созданием двоичного или машинного кода, представленного единицами и нулями. Эти бинарные манипуляции заставляли программы реагировать определенным образом.Это раннее компьютерное программирование обычно называют парадигмой программирования «низкого уровня».
Это был утомительный и подверженный ошибкам метод создания программ. Языки программирования быстро превратились в «процедурную» парадигму или языки третьего поколения, включая COBOL, Fortran и BASIC.Эти процедурные языки программирования определяют программы поэтапно.
Следующим этапом эволюции языков программирования стало создание более логичного подхода к разработке программного обеспечения, парадигмы «объектно-ориентированного» программирования. Этот подход используется в языках программирования Java ™, Smalltalk и Eiffel.Эта парадигма пытается абстрагировать модули программы в объекты многократного использования.
Помимо этих парадигм программирования, существуют также «декларативная» парадигма и «функциональная» парадигма. В то время как некоторые языки программирования строго предписывают использование одной парадигмы, многие поддерживают несколько парадигм.Некоторые примеры этих типов включают C ++, C # и Visual Basic®.
Предоставляя разработчикам гибкость в использовании языков программирования, можно использовать парадигму программирования, которая наилучшим образом отвечает бизнес-задачам, которые необходимо решить. По мере развития искусства компьютерного программирования развивалась и парадигма программирования.Создавая структуру шаблона или модели для разработки системы, программисты могут создавать компьютерные программы, которые будут наиболее эффективными в рамках выбранной парадигмы.
.
Понимание парадигм программирования Python | Opensource.com
В начале каждого года TIOBE объявляет язык программирования года. Когда вышел его последний ежегодный отчет об индексе TIOBE, я совсем не удивился, увидев, что Python снова выиграл титул, основанный на получении наибольшего количества очков рейтинга в поисковых системах (особенно в Google, Bing, Yahoo, Wikipedia, Amazon, YouTube, и Baidu) в 2018 г.
В дополнение к выводам TIOBE, ранее в этом году почти 90 000 разработчиков приняли участие в ежегодном опросе разработчиков Stack Overflow, который является крупнейшим и наиболее полным опросом людей, которые программируют по всему миру.Главный вывод из результатов этого года:
«Python, самый быстрорастущий из основных языков программирования, в очередной раз поднялся в рейтингах языков программирования, опередив Java в этом году и став вторым по популярности языком (после Rust)».
С тех пор, как я начал программировать и изучать разные языки, я видел, как восхищение Python растет. С 2003 года он неизменно входит в десятку самых популярных языков программирования.Как говорится в отчете TIOBE:
«В настоящее время это наиболее часто преподаваемый первый язык в университетах, он номер один в области статистики, номер один в программировании искусственного интеллекта, номер один в написании сценариев и номер один в написании системных тестов. Помимо этого, Python также является лидером в области Интернета. программирование и научные вычисления (просто чтобы назвать некоторые другие области). Таким образом, Python повсюду ».
Существует несколько причин быстрого роста, расцвета и доминирования Python во многих областях, включая веб-разработку, научные вычисления, тестирование, науку о данных, машинное обучение и многое другое.Причины включают его читаемый и поддерживаемый код; обширная поддержка сторонних интеграций и библиотек; модульная, динамическая и переносная конструкция; гибкое программирование; легкость обучения и поддержка; удобные структуры данных; производительность и скорость; и, самое главное, поддержка сообщества. Разнообразное применение Python является результатом его комбинированных функций, которые дают ему преимущество перед другими языками.
Но, на мой взгляд, сравнительная простота синтаксиса и поразительная гибкость, которые он предоставляет разработчикам, работающим на многих других языках, выигрывают.Очень немногие языки могут соответствовать способности Python соответствовать стилю программирования разработчика, а не заставлять его или ее кодировать определенным образом. Python позволяет более продвинутым разработчикам использовать стиль, который, по их мнению, лучше всего подходит для решения конкретной проблемы.
Работая с Python, вы словно заклинатель змей. Это позволяет вам воспользоваться обещанием Python предложить разработчикам несовместимую среду для кодирования в стиле, наиболее подходящем для конкретной ситуации, и сделать код более читаемым, тестируемым и связным.
Парадигмы программирования Python
Python поддерживает четыре основных парадигмы программирования: императивную, функциональную, процедурную и объектно-ориентированную. Согласны ли вы, что они действительны или даже полезны, Python стремится сделать все четыре доступными и работающими. Прежде чем мы углубимся в поиски того, какая парадигма программирования наиболее подходит для конкретных случаев использования, самое время сделать их быстрый обзор.
Императивная парадигма программирования
Парадигма императивного программирования использует императивное настроение естественного языка для выражения указаний.Он выполняет команды пошагово, как ряд словесных команд. Следуя принципу «как решить», он вносит прямые изменения в состояние программы; поэтому ее также называют моделью программирования с отслеживанием состояния. Используя парадигму императивного программирования, вы можете быстро написать очень простой, но элегантный код, и это очень удобно для задач, связанных с манипулированием данными. Из-за своей сравнительно более медленной и последовательной стратегии выполнения он не может использоваться для сложных или параллельных вычислений.
Рассмотрим этот пример задачи, цель которой состоит в том, чтобы взять список символов и объединить его в строку. Способ сделать это в императивном стиле программирования будет примерно так:
>>> sample_characters = ['p', 'y', 't', 'h', 'o', 'n']
>>> sample_string = ''
>>> sample_string
''
> >> sample_string = sample_string + sample_characters [0]
>>> sample_string
'p'
>>> sample_string = sample_string + sample_characters [1]
>>> sample_string
'py'
>>> sample_string = sample_string + sample_characters [ 2]
>>> sample_string
'pyt'
>>> sample_string = sample_string + sample_characters [3]
>>> sample_string
'pyth'
>>> sample_string = sample_string + sample_characters [4]
>>> sample_string
'pytho'
>>> sample_string = sample_string + sample_characters [5]
>>> sample_string
'python'
>>>
Здесь переменная sample_string также похожа на состояние программы, которое изменяется после выполнения серии команд, и ее можно легко извлечь для отслеживания хода выполнения программы.То же самое можно сделать, используя цикл для (также считающийся императивным программированием) в более короткой версии приведенного выше кода:
>>> sample_characters = ['p', 'y', 't', 'h', 'o', 'n']
>>> sample_string = ''
>>> sample_string
>>> для c в sample_characters:
... sample_string = sample_string + c
... print (sample_string)
...
p
py
pyt
pyth
pytho
python
>>>
Парадигма функционального программирования
Парадигма функционального программирования рассматривает программные вычисления как оценку математических функций на основе лямбда-исчисления.Лямбда-исчисление — это формальная система математической логики для выражения вычислений на основе абстракции функции и приложения с использованием привязки и подстановки переменных. Он следует подходу «что решать», то есть выражает логику без описания потока управления, поэтому его также классифицируют как модель декларативного программирования.
Парадигма функционального программирования продвигает функции без сохранения состояния, но важно отметить, что реализация функционального программирования в Python отличается от стандартной реализации.Говорят, что Python является нечистым функциональным языком , потому что можно поддерживать состояние и создавать побочные эффекты, если вы не будете осторожны. При этом функциональное программирование удобно для параллельной обработки и очень эффективно для задач, требующих рекурсии и одновременного выполнения.
>>> sample_characters = ['p', 'y', 't', 'h', 'o', 'n']
>>> import functools
>>> sample_string = functools.reduce (lambda s , c: s + c, sample_characters)
>>> sample_string
'python'
>>>
Используя тот же пример, функциональный способ объединения списка символов для формирования строки будет таким же, как указано выше.Поскольку вычисление происходит в одной строке, нет явного способа получить состояние программы с помощью sample_string и отслеживать ход выполнения. Реализация функционального программирования этого примера увлекательна, поскольку она сокращает количество строк кода и просто выполняет свою работу в одной строке, за исключением использования модуля functools и метода reduce . Три ключевых слова — functools , reduce и lambda — определяются следующим образом:
- functools — это модуль для функций высшего порядка, который обеспечивает функции, которые действуют на другие функции или возвращают их.Он поощряет написание кода многократного использования, поскольку легче воспроизвести существующие функции с некоторыми уже переданными аргументами и создать новую версию функции хорошо документированным способом.
- уменьшить — это метод, который применяет функцию двух аргументов кумулятивно к элементам в последовательности слева направо, чтобы уменьшить последовательность до одного значения. Например:
>>> sample_list = [1,2,3,4,5]
>>> import functools
>>> sum = functools.уменьшить (лямбда x, y: x + y, список_выборок)
>>> сумма
15
>>> ((((1 + 2) +3) +4) +5)
15
>>> - лямбда-функции — это небольшие анонимные (т. Е. Безымянные) функции, которые могут принимать любое количество аргументов, но выдавать только одно значение. Они полезны, когда используются в качестве аргумента для другой функции или находятся внутри другой функции; следовательно, они предназначены для использования только для одного экземпляра за раз.
Парадигма процедурного программирования
Парадигма процедурного программирования — это подтип императивного программирования, в котором операторы структурированы в процедуры (также известные как подпрограммы или функции).Состав программы — это скорее вызов процедуры, когда программы могут находиться где-то во вселенной, а выполнение является последовательным, что становится узким местом для использования ресурсов. Подобно парадигме императивного программирования, процедурное программирование следует модели с отслеживанием состояния. Парадигма процедурного программирования облегчает практику хорошего проектирования программ и позволяет повторно использовать модули в виде библиотек кода.
Эта модульная форма разработки — очень старый стиль разработки.Различные модули в программе не могут быть связаны друг с другом и могут располагаться в разных местах, но наличие множества модулей создает трудности для многих разработчиков, так как это приводит не только к дублированию логики, но и к большим накладным расходам в терминах. поиска и совершения правильных звонков. Обратите внимание, что в следующей реализации метод stringify может быть определен в любом месте юниверса и для выполнения своего трюка требуется только правильный вызов с желаемыми аргументами.
>>> def stringify (символы):
... string = ''
... для c в символах:
... string = string + c
... return stringify
...
>> > sample_characters = ['p', 'y', 't', 'h', 'o', 'n']
>>> stringify (sample_characters)
'python'
>>>
Парадигма объектно-ориентированного программирования
Парадигма объектно-ориентированного программирования рассматривает базовые сущности как объекты, экземпляр которых может содержать как данные, так и соответствующие методы для изменения этих данных.Различные принципы объектно-ориентированного проектирования помогают повторно использовать код, скрывать данные и т. Д., Но это сложный зверь, и написать ту же логику в объектно-ориентированном методе сложно. Например:
>>> класс StringOps:
... def __init __ (self, символы):
... self.characters = characters
... def stringify (self):
... self.string = ''. join (self.characters)
...
>>> sample_characters = ['p', 'y', 't', 'h', 'o', 'n']
>>> sample_string = StringOps (sample_characters )
>>> sample_string.stringify ()
>>> sample_string.string
'python'
>>>
Какую парадигму программирования мне выбрать?
Важно отметить, что нет никакого сравнения между различными типами парадигм программирования. Поскольку программное обеспечение — это не что иное, как представление знаний, ответ на вопрос: «Как лучше всего представить мою проблему?» выбирает конкретную парадигму программирования.
С точки зрения непрофессионала, если ваша проблема включает серию простых последовательных манипуляций, следование старой парадигме императивного программирования будет наименее затратным с точки зрения времени и усилий и даст вам наилучшие результаты.В случае проблем, требующих математических преобразований значений, фильтрации информации, отображения и редукции, может пригодиться функциональное программирование с вычислением программ в качестве математических функций. Если проблема структурирована как набор взаимосвязанных объектов с определенными атрибутами, которые могут изменяться с течением времени, в зависимости от определенных условий, объектно-ориентированное программирование будет очень полезным. Конечно, подход, основанный на правилах, здесь не будет работать, поскольку выбор парадигмы программирования также сильно зависит от типа обрабатываемых данных, динамических потребностей системы и различных других вещей, таких как масштабируемость.
Последние тенденции
Анализ последних технических модных словечек может помочь определить, почему одни парадигмы программирования работают лучше, чем другие.
- Машинное обучение использует здоровое сочетание императивного программирования и функционального программирования с некоторой долей неизменности. Извлечение признаков и предварительная обработка лучше всего подходят функционально, поскольку они требуют математической обработки данных, потому что сопоставления, сокращения и фильтрации могут в значительной степени выполняться параллельно, без особой зависимости от точек данных друг друга.К обучению моделей машинного обучения лучше всего подходить через императивное программирование старой школы, поскольку значение оптимизирующих функций (также известное как состояние программы) необходимо обновлять на каждой итерации и, следовательно, требует последовательного выполнения во многих точках алгоритма. В этом случае это быстрее, чем функциональное программирование. Это также позволяет избежать создания копий всего после каждого шага; вместо этого он просто обновляет заполнители предыдущего значения.
- Глубокое обучение может хорошо выполняться функционально, так как модели глубокого обучения являются композиционными.Весь процесс оптимизирует набор составных функций, веса неизменяемы и не имеют состояния, а обновления могут применяться в любом порядке, если вычисляются соответствующие входные данные. Использование функционального программирования обеспечивает параллелизм и параллелизм бесплатно, а также упрощает работу с большими распределенными моделями. Существуют также определенные индивидуальные парадигмы, в которых функциональное программирование переплетается с теорией информации, чтобы избежать переобучения статистических моделей.
- К манипуляции данными можно подходить с помощью функционального или объектно-ориентированного программирования.В способе функционального программирования все неизменяемо, алгоритмы выражены лаконично, есть собственное сопоставление с образцом, но формулировка команды, подобной математическому выражению, — это искусство. Подход к нему с помощью объектно-ориентированного программирования предусматривает рекурсивные и итерационные циклы и структуру на основе классов, которая упрощает масштабирование для больших данных и новых функций. Обратной стороной является то, что алгоритмы и логика кода не выражаются в удобочитаемой форме. Хотя обе парадигмы имеют тенденцию иметь автоматическую систему сбора мусора и могут беспрепятственно обращаться к базам данных и управлять ими, выбор какой из них в значительной степени зависит от знаний программиста.
Еда на вынос
Существует высокая вероятность того, что любые два разработчика не согласятся на лучший стиль кодирования для любой ситуации и будут иметь веские аргументы в поддержку своего мнения. В Python замечательно то, что он позволяет вам выбрать парадигму программирования, которая лучше всего подходит для вас в данной ситуации.
Как показывают приведенные выше примеры, задачу всегда можно разбить на подзадачи, где каждая меньшая часть закодирована в совершенно другой парадигме.Стиль смешивания и сопоставления работает отлично, пока используемые пакеты минимальны, входы и выходы четко определены, а сложность умерена. Нет правил, запрещающих комбинировать стили по мере необходимости. Python не останавливается на середине интерпретации вашего приложения и отображает ошибку стиля, когда вы смешиваете стили.
Поскольку не существует идеального руководства по выбору правильного стиля кодирования для данного варианта использования, лучше всего попробовать несколько парадигм, взвешивая их за и против, пока не найдете ту, которая приведет к простому, но эффективному решению.В ходе этого эксперимента будут моменты, когда вы увидите, что вместо использования единого стиля повсюду комбинация парадигм программирования лучше работает для разных частей решения. Во время этого процесса также настоятельно рекомендуется задокументировать требования и испытания различных стилей, чтобы поделиться ими с сообществом и получить отзывы. Комментарии и предложения помогут в разработке, а также вашим товарищам по команде и любым будущим разработчикам, которые добавятся в команду.
Джигьяса Гровер представил стили приручения программирования на Python на All Things Open 13-15 октября в Роли, штат Нью-Йорк.С.
.