Обсуждение:Сравнение многопарадигмальных языков программирования

Текущее название этой страницы — «Мультипарадигмальные языки программирования».

В английском языке, по крайней мере в американском варианте английского языка, перенос слова после префикса «multi» не нужен, за исключением случаев, когда подлежащее слово начинается с буквы «i» или является именем собственным, начинающимся с заглавной буквы. (Я не грамматик и не преподаватель английского языка. Я работаю репортером в газете на неполный рабочий день.)

См. похожий случай: Мультиплатформенность в Мультиплатформенность .

Обсуждение этого вопроса было, возможно, здесь: Wikipedia talk:Manual_of_Style

Таким образом, представляется разумным изменить название страницы соответствующим образом на «Мультипарадигмальный язык программирования».

Является ли это правильным и лучшим местом для размещения подобных запросов или есть более подходящее место?

Спасибо.

Я не являюсь носителем английского языка, поэтому не могу помочь с этим. Я думаю, вы правы, лучшее место для установки политики по этому вопросу — Wikipedia :Manual of Style . Я не нашел никаких обсуждений по этому поводу. Также обратите внимание, что в настоящее время существует много страниц [префикс "Multi-"], поэтому это требует некоторой работы. С наилучшими пожеланиями. -- surueña 13:11, 6 октября 2005 (UTC) [ ответить ]

Почему Groovy отсутствует?

Либо вы его не добавили, либо Groovy не является языком программирования Multiparadigm. -- Krischik  T 07:14, 25 марта 2009 (UTC) [ ответить ]

Как работает ECMAScript?

Единственная квазифункциональная функция, которая приходит мне на ум, — это поддержка анонимных функций и функций более высокого порядка, но я не думаю, что это само по себе дает основания утверждать, что она заимствована из функциональной парадигмы. Tarcieri 01:09, 2 июля 2007 (UTC) [ ответить ]

Scala также поддерживает императивное программирование

Стоит ли нам перевести его на следующий уровень?

Как Ruby работает в режиме параллелизма?

Ruby добавляет параллелизм в небольшой степени с DRb. Хотя DRb связан с ядром Ruby, я бы не стал считать его частью языка. Сравните с Erlang, где параллелизм является неотъемлемой частью языка. DRb в Ruby можно было бы сравнить скорее с OTP Erlang (т.е. стандартной связанной библиотекой) Tarcieri 01:09, 2 июля 2007 (UTC) [ ответить ]

Корректность и полезность

Я немного обеспокоен как правильностью, так и полезностью сравнения языков в этой статье. В этом контексте нет определения «парадигмы» и нет полного списка парадигм, из которых можно выбирать. Вместо этого концепция парадигмы является ad hoc, иногда ошибочной (например, дженерики) и в основном вводящей в заблуждение. Следовательно, категоризация почти случайна. Например, OCaml в настоящее время указан как «две парадигмы», хотя он поддерживает функциональное, императивное, объектно-ориентированное, модульное и универсальное (что, кстати, не является шаблонным метапрограммированием). Является ли модульность парадигмой (она имеет совершенно другое значение в таких языках, как Lisp)? Являются ли энергичное и ленивое вычисление двумя отдельными парадигмами? Являются ли динамическая и статическая типизация парадигмами? Является ли параметрический полиморфизм парадигмой?

Категоризация — это шутка на самом деле. Я мог бы назвать несколько примеров, но я не хочу здесь навязывать какой-то один язык. Я бы счел гораздо более полезным просто объяснить происхождение слова, его использование и проиллюстрировать это некоторыми языковыми примерами и цитатами. Слово «мультипарадигма» слишком расплывчато, чтобы использовать его в качестве спецификации сортировки языка.

несколько предложений

Может быть, утверждение, что C++ реализует 4 парадигмы, заходит слишком далеко... если так, то C реализовал бы по крайней мере 3 (императивную, функциональную и шаблонную с макросами). Я думаю, что язык не является функциональным, если он не реализует по крайней мере несколько из этих функций: функции высшего порядка (допустимо в C и C++ через указатели функций), хвостовая рекурсия, каррирование, ленивые вычисления и, возможно, некоторые другие.

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

В этой статье отсутствует Erlang.

--85.59.39.220 14:51, 20 января 2006 (UTC) [ ответить ]

C++ реализует 1 парадигму: императив. Он не реализует функционал. Объектная ориентация — это не парадигма, это способ группировки данных и функций, это не порядок выполнения операторов. Обобщения C++ на самом деле являются макро-видом шаблонов, и это текстовое преобразование. В Ada есть некоторые настоящие виды обобщений, но шаблоны C++ определены так плохо, что они могут/не могут быть реализованы с проверкой типов на фазе синтаксического анализа. C++ не является по-настоящему обобщенным. Сказал: Rursus ☺ ★ 09:34, 2 июня 2007 (UTC) [ ответить ]
(Кроме того: я ненавижу все языки программирования - это не вопрос конкретно по C++. Сказал: Rursus ☺ ★ 09:37, 2 июня 2007 (UTC))[ отвечать ]

C++ и функциональный

Я тоже об этом думал. Думаю, сторонники языка C++ зашли здесь слишком далеко. Но ведь они всегда сходят с ума по поводу своих шаблонов, которые являются их собственным языком.

-- Кришик  Т 14:14, 9 февраля 2006 (UTC) [ ответить ]

Обновление: главная страница C++ называет функционал как часть библиотеки boost. Boost даже не является частью стандартной библиотеки (ISO) для C++. Это не считается - я исправляю запись.
-- Кришик  Т 14:30, 9 февраля 2006 (UTC) [ ответить ]
Возможность функционального программирования заложена в C++. Хотя библиотека Boost предоставляет некоторые из общих инструментов, доступных в функциональном языке программирования, возможность функционального программирования заложена в C++. Фактически, и D, и C++ здесь сильно недооценены. Они оба имеют возможности для универсального многопарадигмального программирования, что означает, что в них можно использовать большинство парадигм. Они просто не входят в перечень парадигм. 13:07, 19 октября 2007 (UTC) — Предыдущий неподписанный комментарий добавлен Carewolf ( talk • contribs )

Параллельный и распределенный

Здесь вы не правы: Ada реализует параллельные и распределенные парадигмы как первоклассную языковую функцию, а не через библиотеку. Поэтому правильно иметь их на странице.

Вопрос:

  1. Все ли те, кто их перечисляет, действительно поддерживают их как языковую функцию или у них просто есть библиотека для поддержки?
  2. И должна ли (стандартная) библиотека для поддержки учитываться или нет? В первом случае я мог бы обновить Ada, включив программирование массивов ;-).

-- Кришик  Т 14:14, 9 февраля 2006 (UTC) [ ответить ]

::Включение стандартной библиотеки учитывается для встроенной поддержки, внешние библиотеки — нет. 188.57.101.218 (обсуждение) 19:54, 28 апреля 2013 (UTC) [ ответить ]

Общий Лисп

Действительно ли правильно говорить, что Common Lisp поддерживает только функциональную и объектно-ориентированную парадигмы? Common Lisp поддерживает императивное программирование так же хорошо, как и такие языки, как Python или Ruby. Я бы подумал, что его (по крайней мере) следует включить в список поддерживающих функциональные, императивные и объектно-ориентированные.

--66.115.232.200 22:04, 24 февраля 2006 (UTC) [ ответить ]

Может быть. Но определение функций на C не делает C функциональным PL, поскольку он не может хорошо выполнять оптимизации sibcall (и это недостаток дизайна). Зависит не от того, допускает ли Common Lisp императивный код, а от того, является ли полностью императивная программа, написанная на Common Lisp, стабильной. Полностью функциональная программа на C вскоре приведет к переполнению стека и зависанию. Сказал: Rursus ☺ ★ 09:24, 2 июня 2007 (UTC) [ ответить ]
Нет ничего, что указывало бы на то, что императивный Common Lisp менее стабилен, чем C. Многие примеры больших (не объектно-ориентированных) фрагментов кода, которые полагаются на обновление постоянных переменных, доступны в сети. В частности, я цитирую P. Norvig `Paradigms of Artificial Intelligence' в качестве примеров.
Common Lisp поддерживает императивное программирование изначально, естественным и простым способом. В Common Lisp есть примитивы для группировки команд (списков) и их выполнения от первой до последней (prog1, progn и т. д.); в Common Lisp есть setf для установки значений переменных; "loop", "do", "dotimes" и т. д. для итерации. Также есть if и case, а также более общий if, называемый "cond". Как он может не поддерживать императивное программирование? Теперь, Scheme действительно отличается, поскольку (насколько мне известно) не поддерживает итеративные конструкции, что побуждает вас использовать рекурсию. Но Common Lisp *поддерживает* императивное программирование. Или что такого необходимого для императивного программирования, чего вы не найдете в Common Lisp? -- wg, 28 сентября 2007 г.

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

Три языка LISP (Scheme, Dylan и CL) также заслуживают того, чтобы быть классифицированы как поддерживающие символьные вычисления, см. книгу Турецкого: http://www.cs.cmu.edu/~dst/LispBook/index.html или как разрабатывать программы: http://www.htdp.org/2003-09-26/Book/curriculum-ZH-1.html Их также следует классифицировать как поддерживающие метапрограммирование, т.е. написание кода, который пишет код, см. `On Lisp' Грэма или просто погуглите название языка + макросы.Jekyll 18:53, 23 июня 2007 (UTC) [ ответить ]

Это действительно важно, так как это одна из особенностей, которая делает Lisp'ы такими разными. Метапрограммирование в Common Lisp и Scheme гораздо более естественно, чем, например, в C++. Это действительно должно быть включено как одна из парадигм (полностью поддерживаемая Lisp и Scheme, и я не уверен насчет других языков -- определенно не C++, где слишком сложно быть "естественным") -- wg, 28 сентября 2007 г.

Кроме того, макросы Lisp проще в использовании и мощнее шаблонов C++, поэтому здесь должно быть различие. C++ следует указать как поддерживающий «параметрический полиморфизм», потому что это единственное простое, что можно сделать с его шаблонами. Тяжелое метапрограммирование в C++, которое так нравится людям, не является естественным или простым; это как-то странно. Прочтите исходный код любой библиотеки boost, если вы мне не верите. Сравните с любым макросом Lisp. -- wg, 28 сентября 2007 г.

PHP

Объектно-ориентированный? Забавно, учитывая не только то, что www.php.net не определяет php таким образом, но и то, что там также специально указано, что PHP не является ... conio.h • talk 11:24, 8 августа 2006 (UTC) [ ответить ]

Я считаю, что www.php.net прав, а Wikipedia ошибается в этом вопросе. Сказал: Rursus ☺ ★ 14:54, 2 июня 2007 (UTC) [ ответить ]

Java как многопарадигмальный язык

Если concurrent — это парадигма, то Java был одним из первых современных языков со встроенной синтаксической поддержкой concurrency. Таким образом, Java будет объектно-ориентированным и concurrent.

Вы дважды неправы: в Ada параллелизм был первоклассным языковым средством с 1983 года, задолго до того, как была задумана Java. Также потоки Java реализованы как библиотечная функция, а не языковая функция. Посмотрите здесь Wikibooks:Ada_Programming/Tasking, чтобы увидеть разницу. В Ada есть ключевые слова для определения всей важной работы, связанной с потоками, Java использует коллекцию библиотечных классов. Java - язык - довольно примитивен. Вся сила Java в библиотеке и виртуальной машине. -- Krischik  T 14:32, 1 мая 2007 (UTC) [ ответить ]
Java поддерживает параллелизм как часть языка и хорошо документирована в спецификации языка Java [1]. Пакет java.lang является частью языка и поддерживается снизу вверх с требованием к jvm поддерживать параллелизм. Наличие ключевых слов не является требованием для функции/дизайна языка. Ваше утверждение, что это не часть языка, так же нелепо, как утверждение, что класс Object не является частью Java (он также находится в java.lang, как и другие фундаментальные части Java). 128.200.69.122 02:23, 6 июля 2007 (UTC) [ ответить ]
Хорошо, тогда Ada можно обновить до 6 парадигм. У Ada есть стандартная библиотека для программирования массивов. Или векторного и матричного программирования — есть стандартная библиотека и для этого. Обратите внимание, к чему это приведет? Скоро все языки будут 8+ парадигмами из-за какой-то полустандартной библиотеки где-то. —Предыдущий неподписанный комментарий добавлен 194.41.152.158 ( обсуждение ) 08:03, 10 декабря 2008 (UTC) [ ответить ]
Даже если вы настаиваете на ключевом слове для доказательства, как насчет модификатора блока/метода Java «synchronized»? «synchronized» не имеет смысла в однопоточном мире. 109.239.78.197 (обсуждение) 20:42, 12 сентября 2012 (UTC) [ ответить ]

Начиная с Java 1.5, разве Java не будет языком 4 парадигмы? См. Generics_in_Java . —Предыдущий неподписанный комментарий добавлен 206.47.254.12 (обсуждение) 20:43, 5 марта 2008 (UTC) [ ответить ]

Согласно определению универсального программирования , Java может быть языком 4 парадигм, в противном случае информация на странице универсального программирования должна быть изменена.

Википедия:Статьи для удаления/Aurora (язык программирования)

Было бы полезно, если бы в этом обсуждении приняло участие больше пользователей. Dpbsmith (обсуждение) 03:27, 17 декабря 2006 (UTC) [ ответить ]

Путаница в терминах

Статья, похоже, путает термин и маркетоидизированную интерпретацию термина. Разрешает ли PHP логическое и функциональное программирование? Имеет ли Java гарантированную оптимизацию sibcall для избежания переполнения стека при использовании двух взаимно вызывающих функций итеративно? Что такое «мультипарадигма» определяется тем, легко ли ЯП допускает более одного программирования, например, функциональное (полностью, а не фиктивное), итеративное (полностью, а не фиктивное), логическое программирование (полностью, а не фиктивное) и параллельное программирование. Скоро я составлю список упомянутых ЯП, которые не являются мультипарадигмальными. Сказал: Rursus ☺ ★ 08:07, 2 июня 2007 (UTC) [ ответить ]

Более:

По словам Бьярна Страуструпа, это позволяет «программе использовать более одного стиля программирования».

Теперь, Страуструп не тот "авторитет", на которого можно ссылаться в компьютерных науках. Лучше профессор или что-то в этом роде! Страуструп сделал непрактичное "улучшение" C с серьезными недостатками дизайна, которые бесят людей, чтобы создавать Java, Csharp и D. Немультипарадигмальные PL:s, в статье:

  • APL - исключительно императивный
  • PHP - исключительно императивный/ОО
  • Simula - исключительно императивный/ОО, возможно также псевдоконкурентный с сопроцессами,
  • Perl - исключительно императивный/ОО
  • Python — исключительно императивный/ОО
  • ECMAscript - исключительно императивный/ОО
  • C++ - исключительно императивный/ОО
  • D - исключительно императивный/OO
  • (Ада - отозвано мной, язык с двумя парадигмами - если двух достаточно для "мульти-" ...)

Утверждения статьи совершенно нелепы! Добавьте еще к списку ложных утверждений сами! Сказал: Rursus ☺ ★ 08:23, 2 июня 2007 (UTC) [ ответить ]

Еще: нет смысла считать некоторые парадигмы дважды, например, dataflow/concurrent и императивный/объектно-ориентированный. Dataflow — это потоки данных в параллельном языке программирования, а object-oriented — это данные, которые обычно используются в императивных PL. «Парадигмы» — это многообразия взглядов на то, что считать данными, а что программами, например, concurrent парадигма, рассматривающая процессы (запущенные программы) как сущности (данные). Многопарадигмальный PL реализует такие многообразия без видимых явных проектных решений, чтобы полностью позволить программисту строго придерживаться той или иной парадигмы. Например, возможность определять функции в C не делает C функциональным языком программирования, поскольку функциональное программирование заключается в создании бесконечных циклов (не переполнений стека) с помощью вызова самой себя функцией. Сказал: Rursus ☺ ★ 08:53, 2 июня 2007 (UTC) [ ответить ]

Источник для переписывания: ЗДЕСЬ!! Сказал: Rursus ☺ ★ 09:57, 2 июня 2007 (UTC) [ ответить ]
Хотя я согласен, что Страуструп не является окончательным авторитетом в этом вопросе, я не думаю, что его несовершенные усилия имеют здесь значение. (В том же ключе можно было бы упомянуть, что его язык оказался чрезвычайно успешным, но я сомневаюсь, что его определение поддержки нескольких парадигм имело к этому какое-либо отношение.)
Я не согласен, что язык должен поддерживать более двух парадигм, чтобы называться многопарадигмальным. Я думаю, что "двух достаточно" — единственный полезный подход для такого списка, если только почти каждый язык программирования не поддерживал две парадигмы. Очевидно, если список слишком длинный, мы могли бы отфильтровать его по значимости.
Вы немного ревностно относитесь к своему стремлению объединить императивное и объектно-ориентированное программирование. Хотя в императивном программировании можно просто использовать объекты в качестве структуры данных, это отличается от пуристического стиля, поддерживаемого Java и C# (и, менее пуристически, C++). В этих языках изменение состояния программы (с помощью глобальных переменных) затруднено или нежелательно, в то время как изменение состояния объекта легко и предпочтительно.
Ваш аргумент будет работать лучше для языка, такого как PHP, где императивное программирование является нормой, а объекты используются в основном как структуры данных. Тем не менее, PHP, возможно, поддерживает OO-программирование, хотя большинство людей не используют эту поддержку должным образом. («Возможно», потому что API тоже.)
Я недостаточно разбираюсь в языках параллельного программирования/программирования потоков данных, чтобы что-либо о них комментировать.
Вы абсолютно правы, однако, что C не является функциональным. Он поддерживает передачу указателей на функции, но анонимные функции невозможны, а оптимизация хвостовой рекурсии не является обязательной.
— Лейф Арне Сторсет 12:03, 6 июня 2007 (UTC) [ ответить ]
Perl полностью поддерживает функциональную парадигму. Ищите книгу под названием "High Order Perl" и, например, реализацию монад в Perl. —213.148.171.34 17:48, 29 июня 2007 (UTC) [ ответить ]
ООП и императивное программирование — ЭТО НЕ ОДНО И ТО ЖЕ. Похоже, вы пытаетесь продвинуть какую-то странную точку зрения языка. НЕ РЕДАКТИРУЙТЕ с утверждениями, что ООП и императивное программирование попадают в одну и ту же парадигму без надежных источников. Четыре основные парадигмы — это функциональная, императивная, ОО и логическая [2]. 128.200.69.122 02:32, 6 июля 2007 (UTC) [ ответить ]

Начать с нуля

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

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

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

Ах да, ★ не могли бы вы прочитать wikibooks:Ada_Programming/Tasking и сказать мне, чего именно не хватает в типе задачи, чтобы он подпадал под определение процессов (запускаемых программ) как сущностей (данных) . (Конечно, я также сторонник языка, но, по крайней мере, я добавляю ссылки на свои утверждения) -- Krischik  T 07:40, 25 марта 2009 (UTC) [ ответить ]

Можем ли мы уменьшить беспорядок?

Я думаю, что предупреждения в конце статьи достаточно: тот, кто добавил все эти дурацкие теги «Требуется цитирование», действительно испортил статью.

да и нет. Когда я их добавлял, я надеялся, что защитники языка добавят доказательства того, что их язык так крут, как они утверждают. Я ошибался - за очень редкими исключениями защитники языка оставляют его бездоказательными утверждениями... -- Krischik  T 18:34, 17 июля 2007 (UTC) [ ответить ]

Windos PowerShell не является языком программирования

Предлагаю удалить его, так как это CLI. -- QuicksilverPhoenix ( обсуждение ) 19:45, 24 января 2008 (UTC) [ ответить ]

Неправильно. Windows PowerShell — это одновременно и оболочка командной строки , и язык программирования .
«Цель Monad [Windows PowerShell] — предоставить среду оболочки, похожую на Korn, Bourne или другие оболочки в UNIX и Linux, а также богатый язык программирования, такой как Perl или Ruby, в сочетании с функциональностью Microsoft .NET Framework». [3]
Ghettoblaster ( обсуждение ) 19:18, 28 октября 2008 (UTC) [ ответ ]

Где находится Пролог

Я думаю, что Prolog — это тоже язык программирования. Я не прав? --Controll (обсуждение) 15:54, 15 февраля 2008 (UTC) [ ответить ]

но является ли он языком программирования Multiparadigm? -- Krischik  T 07:12, 25 марта 2009 (UTC) [ ответить ]

Излишняя классификация?

Эта статья, похоже, является упражнением в чрезмерной классификации того, что во многих отношениях является нечеткими концепциями. Поскольку никто не согласен на 100%, что можно квалифицировать как язык ООП, как классифицировать язык, который является ООП лишь частично (по какому-то конкретному определению)? Считается ли это поддержкой 2,5 парадигм? Конечно, вопрос о том, поддерживает ли данный язык данную парадигму (что бы это ни значило), является вопросом степени? Это не вопрос «да/нет». Поэтому подсчет поддерживаемых парадигм и классификация языков в соответствии с количеством парадигм кажутся усугублением греха. У Ричарда Докинза есть термин для того, что эта статья, похоже, пытается сделать — он называет это «Тирания прерывистого разума» (т. е. поиск жестких и быстрых границ там, где их на самом деле не существует в реальности).

Все вышесказанное, разве Аспектно-ориентированное программирование не считается парадигмой? А как насчет Метапрограммирования ?

Хотелось бы, чтобы вы подписали этот пост, но вы правы — эта статья сильно усложняет все своей классификацией «парадигм». Особенно это касается списка языков программирования по количеству парадигм. Я не знаю достаточно языков программирования в этом списке, чтобы переписать его, и я ожидаю, что почти все находятся в том же положении (сколько людей знают каждый язык в этом списке достаточно хорошо, чтобы редактировать его?). Я думаю, было бы хорошей идеей стереть весь список языков по парадигме и написать лид так, чтобы статья объясняла, что такое многопарадигмальный подход и почему так много современных языков его используют (с несколькими примерами из популярных языков). -- CalPaterson ( обсуждение ) 16:00, 27 мая 2008 (UTC) [ ответить ]
Я частично согласен. Вместо того, чтобы "стирать весь список языков по парадигме", убедитесь, что вы добавили этот материал в Сравнение языков программирования . Ghettoblaster ( обсуждение ) 16:12, 27 мая 2008 (UTC) [ ответить ]

Небольшое предложение: Haskell. Менее незначительное предложение: добавьте таблицу с языками в строках и парадигмами в столбцах, чтобы было легче понять «различия» между любыми двумя. — Предыдущий неподписанный комментарий добавлен 99.162.208.204 ( обсуждение ) 14:38, 29 июня 2008 (UTC) [ ответить ]

Я считаю полезным число поддерживаемых "числа парадигм", я сортирую по нему. Я предлагаю "Абстрактные типы данных (ADT)" как способ зафиксировать различие "не полностью ОО". Страница о CLU (язык программирования) фиксирует это различие. Кроме того, многие столбцы в сравнительной таблице должны быть сгенерированы из информационного поля для каждого языка. Информационное поле должно перечислять парадигмы, поддерживаемые языком. Таким образом, будет меньше "оригинальных исследований" или неподтвержденных заявлений. rhyre ( talk ) 11:02, 1 ноября 2014 (UTC) [ ответить ]

Объединить сПарадигма программирования?

Я не уверен, как "официально" предложить слияние, но я думаю, что эта тема должна быть перенаправлена ​​в Programming paradigm . Поскольку практически каждый язык общего назначения может быть классифицирован как "мультипарадигмальный", большая часть этой статьи сводится к мелочам. Список языков можно полностью удалить или, возможно, скопировать в Comparison of programming languages , как предлагалось выше. Поскольку список в основном не имеет источников, неполон и даже спорен, я бы согласился на удаление. Кто-нибудь согласен? Не согласен? Maghnus ( обсуждение ) 03:15, 6 июля 2008 (UTC) [ ответ ]

Я добавил предложение о слиянии от вашего имени. Я согласен, что эта статья, сама по себе, имеет мало смысла с ее текущим содержанием. Diego ( talk ) 07:49, 7 июля 2008 (UTC) [ ответить ]
Я поддерживаю идею объединить это с Programming paradigm . Только на основе информации, указанной в Programming paradigm, вы можете ясно понять, что такое multi-paradigm, и даже перечислены несколько примеров. Если есть реальная необходимость в полном описательном списке парадигм, то мы можем создать новую wiki под названием "Список парадигм программирования". --Ричард ( обс .) 05:24, 13 августа 2008 (UTC) [ ответить ]
Я поддерживаю это предложение и считаю, что обе статьи нуждаются в переписывании, парадигма программирования содержит больше обоснованного содержания, хотя она также несколько запутана и находится на шаткой почве. Это может быть, конечно, потому что возведение некоторых сомнительных «стилей» программирования в статус парадигмы может быть преждевременным!! - «Догмы программирования» могли бы быть еще одной подходящей статьей с разделами о полиморфных догмах, инкапсулированных догмах и т. д. — Предшествующий неподписанный комментарий добавлен Kdakin ( talk • contribs ) 05:56, 31 марта 2009 (UTC)[ отвечать ]
Да, эта страница — полный бардак. Я единственный, кто добавил теги <ref>, а все остальное — это необоснованная гонка за то, кто получил больше парадигм для своего любимого языка -- Krischik  T 07:15, 31 марта 2009 (UTC) [ ответить ]
Я не понимаю, почему для этого вообще была отдельная статья, объедините ее. -- Digipatd 02:52, 1 июня 2009 (UTC) [ ответить ]
Объедините концепцию , но сохраните это как отдельный список , как я сделал со списком объектно-ориентированных языков программирования . Pcap ping 06:39, 27 августа 2009 (UTC) [ ответить ]
Я вижу, что наверху есть консенсус, поэтому я собираюсь это сделать. Pcap ping 06:41, 27 августа 2009 (UTC) [ ответить ]

Действительно ли Java поддерживает функциональное программирование?

Извините, если вопрос глупый, но действительно ли Java поддерживает ФП?

Если так, кто-нибудь должен добавить это на страницу Java_(programming_language) , так как там говорится, что это только OO, структурированный и императивный язык.-- 189.29.141.31 (обсуждение) 07:49, 2 сентября 2008 (UTC) [ ответить ]

ну попробуй:
int f (int x) { return 1 + f(x); }
если он падает с переполнением стека, то ответ НЕТ. Следует применить рекурсию Tail функционального языка, и функция должна выдать ошибку переполнения целочисленного диапазона. Или работать вечно, если переполнения целочисленного диапазона не поддерживаются. -- Krischik  T 15:11, 31 марта 2009 (UTC) [ ответить ]
Поддержка оптимизации хвостовой рекурсии вряд ли является критерием того, поддерживает ли язык FP или нет. GCC поддерживает оптимизацию хвостовой рекурсии для C, и вы же не утверждаете, что C поддерживает FP, не так ли? -- DevSolar ( обсуждение ) 07:18, 11 июля 2011 (UTC) [ ответить ]

Повторный взгляд на Windows PowerShell

Конвейер? Серьёзно? Парадигма? Признаюсь, я не знаю PowerShell, но мне трудно поверить, что соединение вывода одной программы с вводом другой программы можно назвать «парадигмой». Я могу связать исполняемый файл C и скрипт Perl вместе. Делает ли это эти два языка «поддерживающими парадигму конвейера»? Есть ли что-то ещё в этой «конвейеризации» PowerShell, что отличает её от этого? Или это попытка увеличить «количество парадигм» PowerShell? -- DevSolar ( обсуждение ) 08:00, 7 июля 2011 (UTC) [ ответить ]

Процедурный: как парадигма?, только Python?

Programming newb здесь. Процедурное программирование обсуждается в этих статьях, ссылки на которые приведены здесь, как парадигма программирования , но здесь оно не указано. Если оно в основном отсутствует здесь, потому что (что сбивает с толку) в этой статье оно рассматривается как тип языка, а не парадигма, то его следует удалить из Python (и переместить Python в 3-парадигму?). Или, если это парадигма, Python не может быть единственным языком, который подходит. Спасибо, "alyosha" (обсуждение) 19:29, 25 августа 2012 (UTC) [ ответить ]

Перл

Согласно Higher-Order Perl , Perl также поддерживает декларативное программирование и другие вещи, так почему же он отмечен как "Нет"? Это также был бы хороший источник для цитат, так как это бесплатная (доступная онлайн) книга. --Athaba ( обсуждение ) 09:42, 30 января 2013 (UTC) [ ответить ]

Я не совсем понимаю, в какой степени язык должен поддерживать рефлексию, чтобы получить «Да» в этой колонке. Perl поддерживает рефлексию для объектов, но не для скаляров, массивов или хэшей. Это считается? -- 12.146.21.163 (обсуждение) 18:53, 5 февраля 2014 (UTC) [ ответить ]

Ракетка добавлена

https://en.wikipedia.org/wiki/Racket_%28programming_language%29 Мультипарадигма: функциональная, процедурная (императивная), модульная, объектно-ориентированная, логическая, рефлексивная, метапрограммирование — Предыдущий неподписанный комментарий добавлен BearnHeart ( обсуждение • вклад ) 19:25, 31 марта 2015 (UTC) [ ответить ]

Язык Д

D поддерживает метапрограммирование

D поддерживает метапрограммирование через шаблонное метапрограммирование и строковые миксины. Можем ли мы сделать адекватные изменения, чтобы отразить это.

Я написал следующий черновик на своей странице пользователя здесь

См. http://dlang.org/template.html и http://dlang.org/mixin.html

Добавлены эти изменения 16 ноября 2015 г. Machinistprogrammer ( обсуждение ) 02:02, 16 ноября 2015 г. (UTC) [ ответить ]

Является ли «Проектирование через интроспекцию» парадигмой программирования?

Уже упомянутый в викиучебнике «Проектирование через интроспекцию» описывает его так:

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

Эту идею впервые описал здесь (стр. 44) Андрей Александреску.

Мысли?

GoLang

Как насчет добавления Go_(programming_language) — Предыдущий неподписанный комментарий, добавленный Long.mindworker ( обсуждение • вклад ) 16:37, 8 декабря 2015 (UTC) [ ответить ]

Machinistprogrammer ( обсуждение ) 06:21, 13 ноября 2015 (UTC) [ ответить ]

Не знаю. Go императивен, рефлексивен и параллелен, но эта страница не описывает многопарадигменность. Для пущего эффекта библиотеки и расширения языка, похоже, подходят, но так много парадигм могут быть эмулированы друг другом с помощью соответствующих шаблонов проектирования. Мистер Мормон ( обсуждение ) 22:57, 4 февраля 2016 (UTC) [ ответить ]

Разве некоторые из языков не относятся к категории «конвейерных»?

На ум приходят F# и Elixir. Достаточно ли идиоматических |> или составных .? — Предыдущий неподписанный комментарий добавлен Mister Mormon ( talk • contribs ) 04:18, 20 февраля 2016 (UTC) [ ответить ]

количество парадигм

Что считается парадигмой? Только один раз в таблице? Или мы должны также учитывать "другие парадигмы", которые не указаны/не связаны? Аноним~dewiki ( обсуждение ) 21:25, 25 октября 2016 (UTC) [ ответ ]

Здравствуйте, уважаемые википедисты!

Я только что изменил одну внешнюю ссылку на Comparison of multi-paradigm programming languages . Пожалуйста, уделите немного времени, чтобы просмотреть мои правки. Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой раздел FaQ для получения дополнительной информации. Я внес следующие изменения:

  • Добавлен архив https://web.archive.org/web/20130119045517/http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html в http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html

Закончив просмотр моих изменений, вы можете следовать инструкциям в шаблоне ниже, чтобы исправить любые проблемы с URL-адресами.

Это сообщение было опубликовано до февраля 2018 года . После февраля 2018 года разделы страниц обсуждения "Внешние ссылки изменены" больше не генерируются и не отслеживаются InternetArchiveBot . Никаких специальных действий в отношении этих уведомлений на страницах обсуждения не требуется, кроме регулярной проверки с использованием инструкций инструмента архивации ниже. Редакторы имеют право удалять эти разделы страниц обсуждения "Внешние ссылки изменены", если они хотят очистить страницы обсуждения от загромождения, но перед выполнением массовых систематических удалений ознакомьтесь с RfC . Это сообщение динамически обновляется через шаблон (последнее обновление: 5 июня 2024 г.) .{{source check}}

  • Если вы обнаружили URL-адреса, которые бот ошибочно посчитал неработающими, вы можете сообщить о них с помощью этого инструмента.
  • Если вы обнаружили ошибку в архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента.

Привет.— InternetArchiveBot ( Сообщить об ошибке ) 17:19, 11 августа 2017 (UTC) [ ответить ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_multi-paradigm_programming_languages&oldid=1206764712"