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. Если я совсем далёк от истины и всё не так понял, просьба - сильно не пинать. |
Автор: | 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. Неплохо будет прочесть хотя бы по диагонали. Попробую, но судя по началу, такая подача материала мне врядли подходит. Не мой уровень... Неужели всё так сложно? Игорь Лоскутов писал(а): Извините за такие академические подробности , надеюсь они будут интересны kemiisto, автору темы. Интересно, интересно... Я вроде даже что-то понял... |
Автор: | Valery Solovey [ Вторник, 11 Ноябрь, 2008 14:57 ] |
Заголовок сообщения: | Re: Парадигмы программирования... |
Так я же и говорю: по диагонали. Начинайте сразу с 5-й главы : ). Если пожелаете что-то уточнить по ходу, то вернётесь к пропущенному (скажем, к определению прагматики). |
Автор: | kemiisto [ Четверг, 08 Январь, 2009 22:47 ] |
Заголовок сообщения: | Re: Парадигмы программирования... |
Немного полистал труд Одинцова и Ваш, Илья. Складывается такая картинка... Небольшое замечание - в этом сообщении обращения на Вы - обращения к Илье Ермакову. Жизненный цикл ПО (из Одинцова, в скобках - из Вашей статьи):
Далее, у Одинцова появляется термин методология - совокупность методов, применяемых в жизненном цикле и объединённых общим философским подходом. Это определение сродни Вашему, Илья, парадигма проектирования. Также встречается в книге Одинцова и понятие парадигма программирования: Цитата: Когда методология применяется во время стадии программирования (реализации) очень часто её называют парадигмой программирования - способом мышления и программирования, не связанным с конкретным языком. ... У Вас, похожий по содержанию термин - парадигмы языков программирования. Вот именно они то меня и интересуют... У Одинцова 5 ядер методологий и, соответственно, (это моё предположение) должно быть и 5 ядер парадигм:
Соотнести с Вашими методологиями несколько сложно по причине того, что у Вас стадия программирования разделена на программирование "в среднем" и программирование "в малом". Единственное, есть мысль что Декларативная (у Вас) = Логическая (у Одинцова). Холодно? Горячо? |
Автор: | Geniepro [ Пятница, 09 Январь, 2009 07:47 ] |
Заголовок сообщения: | Re: Парадигмы программирования... |
kemiisto писал(а): * Методология (парадигма) программирования в ограничениях. (вот что это за "птица" я так и не понял...) Имеется в виду разновидность декларативного программирования -- Constraint programming |
Автор: | Илья Ермаков [ Пятница, 09 Январь, 2009 13:20 ] |
Заголовок сообщения: | Re: Парадигмы программирования... |
Гм, польщён сопоставлением моей скромной заметки с солидной книгой-обзором Одинцова. Этого делать, наверное, не стоит - я записывал конкретные идеи по интересующим лично меня моментам, не более. А именно: пытался наметить "карту" для анализа средств и механизмов какого-нибудь языка применительно к какой-нибудь сфере задач. Я извиняюсь за большой поток мыслей ниже, просто затронуло. Воспринимайте как мысли вслух. Слова "методология", "парадигма" - всё это очень условно.... В ИТ царит большой бардак, и люди, которые хоть как-то пытаются это упорядочить, разумеется, будут делать это по-разному - разными словами и т.п. По поводу жизненного цикла ПО - там всё с этими этапами ясно: это конкретные этапы, использующиеся в конторах-конвейерах, типа крупных аутсорсеров и т.п. Я это вообще не брал во внимание, во-первых, потому, что собственного опыта "конвейера" не имею, во-вторых, потому, что мне это малоинтересно. Собственно, в случае сложных задач и сильной небольшой команды все эти этапы интегрированы очень плотно и выполняются постоянно. Выскажу своё имхо: в случае массовой разработки ПО самым слабым этапом оказывается именно программирование (по сто раз обсуждённым причинам низкой подготовки масс). Эта низкая подготовка сочетается ещё и с трудной управляемостью. Если о первом как-то стыдливо молчат, то о втором написано немало, в стиле "как же пасти этих котов". Что делать бедным манагерам? Изолировать программёров в конкретном звене процесса. На входе сажаются аналитики-прикладники. На выходе - тестеры. Тогда манагер может по-прежнему не вмешиваться в звено программирования ("пусть эта банда работает, как хочет..."), но программёры оказываются зажатыми жёсткими документированными КПП на входе и выходе. Что, конечно, не позволяет получить высококачественный результат, но съедобный продукт + управляемый процесс для массовых задач - вполне. На самом же деле, возьмём то же тестирование. Классическая дисциплина разработки предполагает тестирование не чёрного, а белого ящика (т.е. с известным внутренним устройством), притом теми же людьми, которые его разрабатывают (которые от и до понимают, какие именно критические точки и граничные случаи следует проверять). Правильность гарантируется не тестами, а обоснованным построением программы + defensive-style реализацией. Тесты разрабатываются во многом ещё ДО написания программы - и в первую очередь помогают понять саму спецификацию задачи, выловить подводные камни для проектирования (те самые критические точки и граничные случаи), проверить правильность используемой модели. А уже в конце они срезают небольшое количество случайных ляпов на уровне "опечаток" в коде. Испытания же "чёрного ящика" (т.е. отделённое от разработчиков и без учёта внутреннего устройства системы) вообще в инженерии выполняется обычно на стороне заказчика, при приёмке. И служит не выявлению ошибок, а в первую очередь демонстрационным целям и "для галочки". Просто в области софтвера даже собственная компания часто вынуждена ставить себя в положение внешнего заказчика по отношению к программёрам, "запертым в изолированной палате". Касательно списка парадигм - ещё раз говорю: всё это очень условно. Не воспринимайте это как классификацию, а просто как перечисления того, что есть и что знает конкретный автор... Вот есть ООП, + кроме mainstream есть оно в чисто рафинированном виде, как отдельное интересное направление (языки типа Smalltalk) - и пишет Одинцов пунктик "ООП". И воспринимать этот пунктик надо не как некую фундаментальную категорию, а просто как переданную вам "зарубку" о том, что есть вот такая вот отдельная штука... А вообще говоря, и "чистое ООП" тоже предполагает явное описание последовательности событий - а значит, вроде бы, императивно. А с другой стороны, "нечистое ООП", как именно концепция и возможности - это возможность расширения системы без её переписывания (поддержка принципа "рыба-селёдка" и возможности в систему, работающую с "рыбами", вводить разных "селёдок" без изменения уже существующей части) - и поэтому вообще можно говорить об наличии или отсутствии ОО при абсолютно любой парадигме, хоть императивной, хоть неимперативной. А если Вам хочется именно строгой и аккуратной классификации.... То с этим трудно. В конечном счёте, классификация - это обычно точка зрения на проблему. Построенная с конкретными целями. Правда, точки зрения тоже бывают более или менее объективными. Можно точно сказать, что хорошая классификация никогда не будет включать в себя длинные списки а) б) в) г).... (это просто перечисление, см. выше - и хороший автор всегда это явно укажет, а не будет имитировать наукообразие словом "классификация"). Наиболее чётко делить вообще, наверное, можно дихотомически, надвое - тогда можно подбирать некий индикатор, признак - "горит-не горит, есть-нету". Поэтому деление на императив-декларатив, видимо, неплохое деление. Чёткий признак есть (задаётся преимущественно последовательность событий либо задаются преимущественно информационнные соотношения). А попытки дотыкивать кучу пунктов, как то - отдельно ФП, отдельно ООП и т.п. - видимо, не слишком полезная затея. (Это вот как в ветке о двух умотипах: Info21 ввёл некое чётко наблюдаемое и полезное деление, с ясным индикатором; а многим хочется сразу наплодить уровней 1-2-3-4-5...). (Позволю себе ещё абзац "лирики": у харьковско-белгородской школы теории систем (проф. С.И. Маторин и коллеги его) есть гипотеза о том, как получать естественную классификацию: если для некоей "вилки" в этой классификации А есть такая же (изоморфная, мат. языком) "вилка" в классификации В свойств, присущих объектам из классификации А. Интересная мысль, и конкретные результаты у них есть - в частности, альтернативу УДК они делали и некоторые классификации для госструктур типа МЧС). Ещё раз пардон за многословие. |
Автор: | Клоп Говорун [ Суббота, 24 Январь, 2009 19:11 ] |
Заголовок сообщения: | Re: Парадигмы программирования... |
"Непейвода"-веселая книга особенно в последней ее части,я получил большое удовольствие.Полезная книга... |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |