OberonCore
https://forum.oberoncore.ru/

Парадигмы программирования...
https://forum.oberoncore.ru/viewtopic.php?f=27&t=1240
Страница 1 из 1

Автор:  kemiisto [ Среда, 05 Ноябрь, 2008 18:06 ]
Заголовок сообщения:  Парадигмы программирования...

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

Итак, есть такое красивое греческое слово: парадигма (παράδειγμα). Среди прочих у этого термина есть и такое значение:
Цитата:
Парадигма - совокупность ценностей, методов, технических навыков и средств, принятых в научном сообществе в рамках устоявшейся научной традиции в определенный период времени.


Парадигма одновременно как бы одновременно определяет и модель постановки проблемы, и методы её решения.

Естественно, что существуют парадигмы и в программировании. Парадигма программирования определяет то, как программист видит выполнение программы. Если я правильно понял существует 2 крупных парадигмы программирования: императивная и декларативная. Соответственно, существуют 2 крупных группы языков программирования: императивные и декларативные.

Программа на императивном языке определяет, как надо вычислить, а на декларативном - что надо вычислить. К императивному программированию относится процедурное, объектно-ориентированное. К декларативному - функциональное, логическое.

1) Вообще как, похоже на правду?

Теперь по поводу процедурное / структурное. Если я правильно понял, процедурное программирование основано на концепции вызова подпрограмм (процедур). И оно не есть структурное. Чтоб оно стало структурным, надо добавить пункты 1 и 3 из нижеследующих:
Цитата:
1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
* последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
* ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

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

3. Разработка программы ведётся пошагово, методом «сверху вниз».


2) Как соотносятся между собой структурное и процедурное программирование?

3) Как будет правильно: императивное программирование (помимо ООП) включает

* процедурное;
* структурное;
* и то и другое?

Чёрт меня дёрнул зайти в народную энциклопедию. В статье с говорящим названием "Парадигма программирования" написано следующее:
Цитата:
Основные модели программирования
* Императивное программирование
* Функциональное программирование
* Логическое программирование
* Объектно-ориентированное программирование
o Программирование, основанное на классах
o Программирование, основанное на прототипах


4) Т.е. ООП - НЕимперативное программирование? Странно, по сравнению с процедурным программированием поменялясь только модель организации данных, модель вычислений осталась прежней.

5) Но, что тогда входит в императивное программирование? Только процедурное и / или структурное?

P.S. Если я совсем далёк от истины и всё не так понял, просьба - сильно не пинать. :oops:

Автор:  Valery Solovey [ Среда, 05 Ноябрь, 2008 18:19 ]
Заголовок сообщения:  Re: Парадигмы программирования...

В точку Вы и вправду не попали. Самостоятельно Вы будете долго искать. Но сейчас придёт Илья и даст Вам свою любимую книгу : ), тогда уж станет всё намного проще.

Автор:  Valery Solovey [ Среда, 05 Ноябрь, 2008 18:23 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Впрочем, он уже выложил её в соответствующей теме. Автор - Непейвода.

Автор:  Илья Ермаков [ Среда, 05 Ноябрь, 2008 21:43 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Да, стоит почитать книги по вышеприведённой ссылке.
А терминология весьма размыта - как обычно...

kemiisto писал(а):
Соответственно, существуют 2 крупных группы языков программирования: императивные и декларативные.
Программа на императивном языке определяет, как надо вычислить, а на декларативном - что надо вычислить.

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

Автор:  igor [ Четверг, 06 Ноябрь, 2008 10:25 ]
Заголовок сообщения:  Re: Парадигмы программирования...

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

Автор:  Илья Ермаков [ Четверг, 06 Ноябрь, 2008 13:23 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Я некогда экспериментировал с анализом подходов в программировании. Может быть, какое-нибудь зерно там и есть:
viewtopic.php?f=26&t=592

Автор:  kemiisto [ Воскресенье, 09 Ноябрь, 2008 17:15 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Valery Solovey писал(а):
В точку Вы и вправду не попали. Самостоятельно Вы будете долго искать. Но сейчас придёт Илья и даст Вам свою любимую книгу : ), тогда уж станет всё намного проще.

Да уж, в точку я точно не попал. :)

Valery Solovey писал(а):
Впрочем, он уже выложил её в соответствующей теме. Автор - Непейвода.

900 страниц!? Я в шоке! Если честно, даже открывать не хочу... :(

Илья Ермаков писал(а):
Я некогда экспериментировал с анализом подходов в программировании. Может быть, какое-нибудь зерно там и есть:
viewtopic.php?f=26&t=592

А вот это почитаю... Если после прочтения будут вопросы - задам в этой теме.

Автор:  Valery Solovey [ Понедельник, 10 Ноябрь, 2008 11:40 ]
Заголовок сообщения:  Re: Парадигмы программирования...

kemiisto писал(а):
900 страниц!? Я в шоке! Если честно, даже открывать не хочу... :(
Есть укороченный вариант на http://www.intuit.ru. Неплохо будет прочесть хотя бы по диагонали.

Автор:  TAU [ Понедельник, 10 Ноябрь, 2008 16:49 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Игорь Лоскутов писал(а):
Если сравнивать императивную и декларативную парадигмы, то основное отличие на мой взгляд состоит в том, в императивном программировании модель вычислителя находится в том или ином состоянии, а в декларативном программировании состояний нет

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

Автор:  igor [ Понедельник, 10 Ноябрь, 2008 17:48 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Ещё добавлю. В случае императива, модель вычислителя представляет собой микропрограммный автомат (МПА) с естественной адресацией (как правило, хотя в принципе может быть и с принудительной). Реально этот МПА может быть виртуальным (не "в железе"), как в случае с программами на ЯВУ. Очень полезно представлять себе эту машину. Оператор рассматривается как атомарное действие (микрооперация). Выполнение оператора -- переход МПА из одного состояния в другое. Текущее состояние МПА -- это значения всех переменных плюс текущий адрес в программе (точка на структурной схеме алгоритма). Это, конечно, несколько упрощено и слишком прямолинейно, но зато позволяет уловить суть.
Извините за такие академические подробности :) , надеюсь они будут интересны kemiisto, автору темы.

PS: Все эти выкладки не применимы к декларативному программированию

Автор:  Geniepro [ Вторник, 11 Ноябрь, 2008 07:34 ]
Заголовок сообщения:  Re: Парадигмы программирования...

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

Функциональное программирование давно уже слишком сильно переплелось с декларативным, так что отделять ФП от ДП не стоит, наверное. В конце концов, ФП -- это не только Лисп, но и Хаскелл, ML-семейство, Erlang, даже Рефал, и в них есть ярковыраженная декларативная составляющая -- pattern matching...

И кстати, это ваше определение очень хорошо описывает эти ФЯ -- именно что функция представляет собой описание результата при тех или иных параметрах функции...

Автор:  Alexey_Donskoy [ Вторник, 11 Ноябрь, 2008 13:50 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Ну, раз пошла такая пьянка, вставлю и свои пять копеек... нет, лучше рублей ;)

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

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

Причём, что характерно, в рамках объектно-ориентированной модели ;) (разумеется, не той модели, которая в С++).

Достаточно внимательно рассмотреть тривиальный пример "c=a+b", чтобы заметить, что этот оператор сам по себе не содержит никакого алгоритма. Единственно важным, что мы можем увидеть из этой записи, это наличие объектов (a,b,c) и взаимоотношений между ними. Рассматривая эту метаинформацию в "императивном" контексте (чему способствует запись "c:=a+b" ;) ), мы можем добавить дополнительньное утверждение: "хочу, чтобы результат сложения объектов а и b был помещён в объект с".

Тем не менее, реализация даже такого "тривиального" примера может быть очень и очень не простой. И не очевидной.

Но в очень большом количестве случаев нам, желающим получить результат, достаточно приведённой выше метаинформации. В качестве постановки задачи. А в какой парадигме иполнитель решит эту задачу, нам не так уж и важно!

Автор:  kemiisto [ Вторник, 11 Ноябрь, 2008 13:52 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Valery Solovey писал(а):
Есть укороченный вариант на http://www.intuit.ru. Неплохо будет прочесть хотя бы по диагонали.

Попробую, но судя по началу, такая подача материала мне врядли подходит. Не мой уровень... :oops: Неужели всё так сложно? :(

Игорь Лоскутов писал(а):
Извините за такие академические подробности :) , надеюсь они будут интересны kemiisto, автору темы.

Интересно, интересно... Я вроде даже что-то понял...

Автор:  Valery Solovey [ Вторник, 11 Ноябрь, 2008 14:57 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Так я же и говорю: по диагонали. Начинайте сразу с 5-й главы : ). Если пожелаете что-то уточнить по ходу, то вернётесь к пропущенному (скажем, к определению прагматики).

Автор:  kemiisto [ Четверг, 08 Январь, 2009 22:47 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Немного полистал труд Одинцова и Ваш, Илья. Складывается такая картинка... Небольшое замечание - в этом сообщении обращения на Вы - обращения к Илье Ермакову.
Жизненный цикл ПО (из Одинцова, в скобках - из Вашей статьи):
  • анализ (анализ проблемной области);
  • проектирование (программирование «в большом» - ­проектирование,  архитектура программной системы);
  • программирование (программирование «в среднем» - система типизации, организация вычислительного процесса и т.п. + программирование «в малом» (алгоритмизация));
  • тестирование и отладка;
  • соповождение и эксплуатация.
Последние два этапа в Вашей статье не фигурируют, "как не связанные с непосредственно программированием." Надеюсь более-менее правильно соотнёс...

Далее, у Одинцова появляется термин методология - совокупность методов, применяемых в жизненном цикле и объединённых общим философским подходом. Это определение сродни Вашему, Илья, парадигма проектирования. Также встречается в книге Одинцова и понятие парадигма программирования:
Цитата:
Когда методология применяется во время стадии программирования (реализации) очень часто её называют парадигмой программирования - способом мышления и программирования, не связанным с конкретным языком. ...

У Вас, похожий по содержанию термин - парадигмы языков программирования. Вот именно они то меня и интересуют...

У Одинцова 5 ядер методологий и, соответственно, (это моё предположение) должно быть и 5 ядер парадигм:
  • Методология (парадигма) императивного программирования.
  • Методология (парадигма) оьъектно-ориентированного программирования.
  • Методология (парадигма) функционального программирования.
  • Методология (парадигма) логического программирования.
  • Методология (парадигма) программирования в ограничениях. :shock: (вот что это за "птица" я так и не понял...)

Соотнести с Вашими методологиями несколько сложно по причине того, что у Вас стадия программирования разделена на программирование "в среднем" и программирование "в малом". Единственное, есть мысль что Декларативная (у Вас) = Логическая (у Одинцова).

Холодно? Горячо?

Автор:  Geniepro [ Пятница, 09 Январь, 2009 07:47 ]
Заголовок сообщения:  Re: Парадигмы программирования...

kemiisto писал(а):
* Методология (парадигма) программирования в ограничениях. :shock: (вот что это за "птица" я так и не понял...)

Имеется в виду разновидность декларативного программирования -- Constraint programming

Автор:  Илья Ермаков [ Пятница, 09 Январь, 2009 13:20 ]
Заголовок сообщения:  Re: Парадигмы программирования...

Гм, польщён сопоставлением моей скромной заметки с солидной книгой-обзором Одинцова. Этого делать, наверное, не стоит - я записывал конкретные идеи по интересующим лично меня моментам, не более. А именно: пытался наметить "карту" для анализа средств и механизмов какого-нибудь языка применительно к какой-нибудь сфере задач.

Я извиняюсь за большой поток мыслей ниже, просто затронуло. Воспринимайте как мысли вслух.

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

По поводу жизненного цикла ПО - там всё с этими этапами ясно: это конкретные этапы, использующиеся в конторах-конвейерах, типа крупных аутсорсеров и т.п. Я это вообще не брал во внимание, во-первых, потому, что собственного опыта "конвейера" не имею, во-вторых, потому, что мне это малоинтересно. Собственно, в случае сложных задач и сильной небольшой команды все эти этапы интегрированы очень плотно и выполняются постоянно.
Выскажу своё имхо: в случае массовой разработки ПО самым слабым этапом оказывается именно программирование (по сто раз обсуждённым причинам низкой подготовки масс). Эта низкая подготовка сочетается ещё и с трудной управляемостью. Если о первом как-то стыдливо молчат, то о втором написано немало, в стиле "как же пасти этих котов". Что делать бедным манагерам? Изолировать программёров в конкретном звене процесса. На входе сажаются аналитики-прикладники. На выходе - тестеры. Тогда манагер может по-прежнему не вмешиваться в звено программирования ("пусть эта банда работает, как хочет..."), но программёры оказываются зажатыми жёсткими документированными КПП на входе и выходе. Что, конечно, не позволяет получить высококачественный результат, но съедобный продукт + управляемый процесс для массовых задач - вполне.

На самом же деле, возьмём то же тестирование. Классическая дисциплина разработки предполагает тестирование не чёрного, а белого ящика (т.е. с известным внутренним устройством), притом теми же людьми, которые его разрабатывают (которые от и до понимают, какие именно критические точки и граничные случаи следует проверять). Правильность гарантируется не тестами, а обоснованным построением программы + defensive-style реализацией. Тесты разрабатываются во многом ещё ДО написания программы - и в первую очередь помогают понять саму спецификацию задачи, выловить подводные камни для проектирования (те самые критические точки и граничные случаи), проверить правильность используемой модели. А уже в конце они срезают небольшое количество случайных ляпов на уровне "опечаток" в коде.
Испытания же "чёрного ящика" (т.е. отделённое от разработчиков и без учёта внутреннего устройства системы) вообще в инженерии выполняется обычно на стороне заказчика, при приёмке. И служит не выявлению ошибок, а в первую очередь демонстрационным целям и "для галочки". Просто в области софтвера даже собственная компания часто вынуждена ставить себя в положение внешнего заказчика по отношению к программёрам, "запертым в изолированной палате".

Касательно списка парадигм - ещё раз говорю: всё это очень условно. Не воспринимайте это как классификацию, а просто как перечисления того, что есть и что знает конкретный автор...

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

А если Вам хочется именно строгой и аккуратной классификации.... То с этим трудно. В конечном счёте, классификация - это обычно точка зрения на проблему. Построенная с конкретными целями. Правда, точки зрения тоже бывают более или менее объективными.
Можно точно сказать, что хорошая классификация никогда не будет включать в себя длинные списки а) б) в) г).... (это просто перечисление, см. выше - и хороший автор всегда это явно укажет, а не будет имитировать наукообразие словом "классификация").
Наиболее чётко делить вообще, наверное, можно дихотомически, надвое - тогда можно подбирать некий индикатор, признак - "горит-не горит, есть-нету". Поэтому деление на императив-декларатив, видимо, неплохое деление. Чёткий признак есть (задаётся преимущественно последовательность событий либо задаются преимущественно информационнные соотношения). А попытки дотыкивать кучу пунктов, как то - отдельно ФП, отдельно ООП и т.п. - видимо, не слишком полезная затея. (Это вот как в ветке о двух умотипах: Info21 ввёл некое чётко наблюдаемое и полезное деление, с ясным индикатором; а многим хочется сразу наплодить уровней 1-2-3-4-5...).

(Позволю себе ещё абзац "лирики": у харьковско-белгородской школы теории систем (проф. С.И. Маторин и коллеги его) есть гипотеза о том, как получать естественную классификацию: если для некоей "вилки" в этой классификации А есть такая же (изоморфная, мат. языком) "вилка" в классификации В свойств, присущих объектам из классификации А. Интересная мысль, и конкретные результаты у них есть - в частности, альтернативу УДК они делали и некоторые классификации для госструктур типа МЧС).

Ещё раз пардон за многословие. :)

Автор:  Клоп Говорун [ Суббота, 24 Январь, 2009 19:11 ]
Заголовок сообщения:  Re: Парадигмы программирования...

"Непейвода"-веселая книга :D особенно в последней ее части,я получил большое удовольствие.Полезная книга...

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/