Эмпирические доказательства выбора парадигмы программирования для решения проблемы

В википедии C2 обсуждается « Эмпирические данные для объектно-ориентированного программирования», в которой, в основном, делается вывод, что нет ничего, кроме апелляции к авторитету. Последний раз эта редакция была отредактирована в 2008 году. Обсуждение, похоже, подтверждает это: вопросы о том, является ли ОО устаревшим , когда функциональное программирование является плохим выбором, а также о преимуществах и недостатках АОП , отвечаются мнением участников без опоры на доказательства.

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

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

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

Другими словами: некоторые люди говорят: «ОО дает лучшую гибкость» или «в функциональных программах меньше ошибок» - (часть) того, о чем я спрашиваю, является доказательством этого. Остальные просят предоставить доказательства против этого, или предположения, согласно которым эти заявления верны, или доказательства, показывающие, что эти соображения не важны. Существует множество мнений о том, почему одна парадигма лучше другой; есть ли что-нибудь объективное за этим?

Для предыдущего дубля см. Редакцию 1 этого ответа . Тем не менее, комментарии и правки к вопросу дополнительно разъясняют, что именно ищет вопрос, и позволяют мне быть более ясным.

Да, разработка программного обеспечения на основе фактических данных (EBSE) - это вещь. Похоже, что было предпринято несколько попыток в отношении баз данных EBSE, таких как эта в Университете Дарема и SEED, которая была начата профессором в Cal Poly . Все эти усилия, а также те, которые обсуждались в ряде статей, можно найти на сервере IEEE Xplore или в цифровой библиотеке ACM.(подписка или покупка требуется для многих работ в обеих), основаны на доказательной медицине. Они предоставляют обзоры литературы опубликованных эмпирических данных (наблюдения и эксперимента). Фактически, включение «обзора литературы» в строку поиска в любом поиске публикаций дает информацию по большинству тем - более 14000 обращений к ACM и более 1000 по базе данных IEEE (когда ограничено только компьютерными темами).

Глядя на общие типы тем, обсуждаемых в этих базах данных EBSE и обзорах литературы, я вижу общую нить - они, как правило, независимы от технологий. Основное внимание, по-видимому, уделяется процессу и методологии, а не конкретным инструментам, используемым для разработки программного обеспечения.

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

В частности, вопрос, касающийся применения методов EBSE к выбору парадигмы, кажется трудным из-за большого числа переменных, которые заставляют делать предположения, а также снижают возможность повторения эксперимента или наблюдения. Правильно в вопросе сказано: «какая парадигма является« правильным ответом », может зависеть от того, на какие метрики обращает внимание конкретное исследование, на какие условия оно остается постоянным или варьируется, и, несомненно, на другие факторы» . Хотя это не означает, что изучение того, какая парадигма «лучшая» в данной ситуации, делает любой обзор литературы этими документами невероятно трудным для заполнения и все же извлекает из них информацию.

Определенно нет решения «повернуть рукоятку» для выбора парадигмы.

Принимая во внимание парадигму программирования, вы можете найти исследования в различных академических и отраслевых базах данных о том, как эта парадигма влияет на различные аспекты разработки программного обеспечения - качество, дефекты, эффективность и т. Д. - в различных конкретных условиях, начиная от знаний и опыта Команда в проблемной области. Любая строгая статья должна четко определять условия, при которых были собраны данные, и допущения. Проблема становится попытка выделить факторы, которые делают его хорошим в каждом из этих условий.

Академически, есть некоторые утверждения, которые легко исследовать. Например, утверждение, что функциональная парадигма хорошо подходит для приложений, требующих параллелизма, вытекает из теоремы Черча-Россера . По этой причине вполне вероятно, что программная система, написанная на функциональном языке, будет иметь меньше дефектов, связанных с параллелизмом, чем та же система, написанная на процедурном или объектно-ориентированном языке.

Однако с практической точки зрения команда разработчиков программного обеспечения не всегда может использовать «лучший» инструмент или технику для работы только потому, что исследования показывают это. Хотя мы стремимся выпускать программные системы самого высокого качества, мы работаем в рамках ограничений. Часто я вижу, что эти ограничения минимизированы (или даже удалены из уравнения) при обсуждении эффективности любой методологии.

Как практикующий специалист, когда я участвую в выборе технологий для использования, я стараюсь определить наилучшие возможные инструменты. Но затем я ограничиваю себя тем, что знает и понимает команда, которая у меня есть. Возвращаясь к моему предыдущему примеру, если у меня есть команда, хорошо разбирающаяся в создании параллельных приложений на C ++ и не имеющая опыта работы с Haskell, нет смысла предлагать создание системы на Haskell, поскольку я, скорее всего, не смогу это сделать. график и бюджетные ограничения, и мое качество, скорее всего, пострадает из-за недостатка опыта в наборе инструментов.

Напомним, что разработка программного обеспечения на основе фактических данных - это, как правило, хорошая вещь, и обзоры литературы существуют и доступны. Однако существуют аспекты разработки программного обеспечения, в которых применение основанных на фактических данных подходов мало что дает. Выбор парадигмы программирования для крупномасштабных усилий по разработке является одним из них.

Если вы хотите узнать о том, как объектная ориентация направлена ​​на повторное использование или дефекты в функциональном программировании, вы легко найдете публикации по этим вопросам. Тем не менее, я не нашел (и при этом не доверял бы) публикацию, которая могла бы эффективно решать выбор парадигм в широком спектре реальных проектов разработки программного обеспечения.

Я читал «Искусство программирования Unix » Эрика С. Рэймонда. У этого есть некоторые очень интересные исторические идеи о вещах, которые мы теперь принимаем как должное. Он приводит несколько хороших исследований программного обеспечения IEEE , в которых используются эмпирические данные, такие как плотность дефектов. Это может быть хорошим источником, если вы ищете учебу в академическом стиле.

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

Деннис Ритчи поддержал модульность, сказав всем и каждому, что вызовы функций в Си действительно, очень дешевы. Все начали писать небольшие функции и модульность. Спустя годы мы обнаружили, что вызовы функций все еще дороги в PDP-11, и код VAX часто тратит 50% своего времени на инструкцию CALLS. Деннис солгал нам! Но было слишком поздно; мы все зацепили ...

- Стив Джонсон

Однако на самом деле есть две проблемы с тем, чтобы стать слишком эмпирическими. Во-первых, качество кода очень субъективно. Код может быть ужасным и все же быть правильным. Люди воспринимают парадигму программирования - очень верная метрика, потому что код написан так, чтобы люди читали столько же, сколько и для компьютеров, если не больше.

Вторая проблема заключается в том, что 50% разработчиков имеют талант ниже среднего. Не имеет значения, будет ли ваш ведущий разработчик более продуктивным, используя функциональное программирование, если «сброд» изо всех сил пытается написать работающее программное обеспечение, используя его, не говоря уже о красивом, хорошо спроектированном программном обеспечении. Точно так же с языками программирования TMTOWTDI ваш ведущий разработчик по-прежнему собирается писать чистый модульный код, но менее талантливые кодеры пишут помехи в строках из-за отсутствия навязанной структуры.

Вот почему я думаю, что ООП поднялся на вершину популярности, несмотря на свои недостатки. Это не настолько ограничительно, что это мешает наиболее талантливым, но его структура обеспечивает краткий способ общения и навязывает хорошие принципы дизайна наименее талантливым.

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

Есть конкурсы по программированию, которые используют компьютерную систему оценок и позволяют писать на разных языках и публиковать всевозможные результаты и тому подобное. Могу поспорить, у них есть хорошие данные для вас. Вот список из 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

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

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

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

Я изучаю различные способы разработки программного обеспечения более 30 лет. Существует нехватка хороших опубликованных данных о выборе парадигмы.

Я собрал большую библиографию с поиском ASCII. Это включает в себя много статей и статей IEEE и ACM. Я отмечаю предметы типом предоставленных доказательств. Вот самые распространенные теги:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Теперь найдите PARADIGM и посчитайте теги

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Если вы хотите копать глубже, http://cse.csusb.edu/dick/lab.html, и я надеюсь, что это поможет ...

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

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

• Во-первых, если вы не являетесь членом ACM, вы, вероятно, вообще не сможете прочитать ссылку выше, которая охватывает первую проблему: не все существующие исследования фактически доступны для практиков.
• большая часть практики разработки программного обеспечения держится в секрете как часть коммерчески конфиденциальных процессов, поэтому нет никакого представления о том, что сработало или не сработало для этих людей.
• Разработка программного обеспечения - это квалифицированная практика, поэтому трудно (не невозможно, просто сложно) организовать подходящее слепое исследование.
• Различные части жизненного цикла программного обеспечения влияют на результаты друг друга до такой степени, что трудно контролировать в любом эксперименте.
• как показали дискуссии, многие практики не считают «литературу» (или академическую сторону разработки программного обеспечения в целом) актуальной для своей работы.

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

Я не верю, что этот тип обучения существует. Можно было бы полагать, что не парадигма программирования имеет значение так же, как фактический алгоритм, который используется. Например, если взять любую нетривиальную системную систему, которая опирается на алгоритмы малого пространства, то стих, который опирается на алгоритмы малого времени, будет генерировать разные метрики. Тот, который имеет лучшее время, скорее всего, будет считаться более правильным, если только пространство не является проблемой, тогда обратное верно. Я нахожу это похожим на мощение дороги. Хотя алгоритм или рецепт изготовления материалов постоянен во всех процессах, возможно, одна компания считает, что прокладка двух полос одновременно (по одной на каждой стороне дороги) лучше, чем одновременная укладка двух полос движения на одной и той же стороне дороги. , В конце концов, это не имеет значения, поскольку процесс создания черного верха остается прежним, Единственная разница заключается в подходе. Возвращаясь к программированию, если у вас есть команда разработчиков C, напишите код процедурным образом, если у вас есть команда разработчиков Java, напишите его в ОО. Не зацикливайтесь на парадигме так сильно, как на реализации алгоритма. Потому что в конце концов вы можете написать Java как C и попытаться написать C как Java.

ОБНОВИТЬ

Чтобы ответить на комментарий Грэм оставил меня:
Я предполагаю, что под архитектурой вы подразумеваете парадигму программирования. Если вы собираетесь использовать Clojure, возможно, вам следует нанять команду программистов Clojure. Однако, основываясь на быстром поиске, Clojure - это язык, основанный на Java, он просто так функционирует. Учитывая эту информацию, я бы взял программистов на Java (поскольку технически они могут просто написать Java, и это даст вам те же результаты), или искать функциональных программистов, таких как разработчики на Haskell. Теперь с точки зрения выбора лучшего это полностью зависит от вашей команды. У меня никогда не было бы команды экспертов по реляционным базам данных, которая бы организовывала для меня облачное решение, и у меня не было бы команды функциональных программистов, которая бы создавала для меня объектно-ориентированное решение. Вы должны использовать сильные стороны команды, которой вы не обладаете прославленным видением, которое у вас есть в голове, для того, что команда «должна»

Различные парадигмы приводят к разным решениям. Какая подгонка является «лучшей», во многом зависит от:

• решение
• команда разработчиков
• операционная среда

Я не знаю ни одного такого окончательного исследования, и даже если бы оно было, я бы не стал ему доверять.

Это работа архитектора.

Замена мудрости архитектора на возможно не относящиеся к делу выводы исследования - путь к катастрофе.

Примечание: в комментарии упоминается выбор «алгоритма», а затем выбор языка. Алгоритмы являются центральным структурным механизмом для процедурных языков. Объектно-ориентированные языки ориентированы на классы и модели сотрудничества / общения. Если вы убеждены (как архитектор), что решение, ориентированное на алгоритмы, «лучше», тогда придерживайтесь процедурных или функциональных языков.

Приложение: не доверять учебе - это не «суеверие», это здравый смысл. Научные эксперименты должны быть объективными и повторяемыми. Программные проекты очень субъективны, но еще хуже - это неповторимые эксперименты . Вы просто не можете реализовать проект X с командой Y, измерить результаты, а затем откатить время, стереть воспоминания и повторить тот же проект с той же командой. Информация, обнаруженная или подразумеваемая исследованиями, может быть полезна для архитектора, но она никогда не может быть окончательной.