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

11

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

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

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

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

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

Сообщество
источник
1
веб-поиск научно обоснованной разработки программного обеспечения показывает множество ссылок
gnat
@gnat EBSE - это систематическое обобщение литературы и общие выводы о том, как мы могли бы улучшить практику. Мой вопрос заключается в том, существует ли эта литература; достаточно ли систематических обзоров или метаанализов, чтобы быть продуктивными.

Ответы:

12

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

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

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

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

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

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

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

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

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

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

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

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

Томас Оуэнс
источник
Раздел о полноте по Тьюрингу игнорирует компромиссы, которые я хочу увидеть в открытом виде и сравнить. Позвольте мне привести конкретный пример. Многие люди говорят мне, что функциональное программирование отлично подходит для избежания ошибок параллелизма. Теперь мы находим, что Схема, как и Паскаль, полна по Тьюрингу. Таким образом, должна быть возможность писать код, безопасный для параллелизма, процедурно. Согласовано. Но разве это здорово ? Есть ли преимущества выбора одного метода? Можно ли измерить такие преимущества?
1
@GrahamLee Подтверждение или отклонение вашей гипотезы требует объективных доказательств, которых не существует. Существуют субъективные причины для создания новой парадигмы и новой модели представления точно таких же вычислительных возможностей - и это касается не только языков программирования, но и базового математического представления этих языков . Эти объективные причины включают нацеливание на конкретную демографию (вычислительный математик против бизнес-аналитика - их мышление отличается, требует другой парадигмы).
Томас Оуэнс
2
@Thomas: ваш вывод о том, что практика программирования уникальна для науки, является своеобразным. Там много исследований продолжается. Часто цитируемый пример - исследовательская группа Лутца Пречелта . Я не знаю области достаточно хорошо, чтобы знать, решал ли кто-нибудь конкретные вопросы Грэма, но нет никаких оснований полагать, что они не поддаются методам, используемым Пречелтом и другими.
Cris
1
@ Крис Я не верю, что они непрозрачны для науки. Тем не менее, я считаю, что есть некоторые вещи, которые к тому времени, как вы, как говорит Грэм в вопросе, добавляют «много предостережений и предположений» к исследованию, больше не нужны для практиков. На этом этапе, с практической точки зрения, просто более эффективно основывать свои решения на истории и опыте. Наличие хороших, надежных и достоверных данных - очень хорошая вещь. Но наступает момент, когда его слишком сложно достать или он действителен только в очень специфической ситуации, когда он бесполезен для промышленности.
Томас Оуэнс
1
@ Томас, я сомневаюсь в этом. Общая медицинская практика, по крайней мере, настолько же ситуативна и контекстно-зависима, как и разработка программного обеспечения, и, кроме того, появляется все больше свидетельств того, что основанный на фактических данных врач производит заметные улучшения. Это во многом зависит от количества и качества исследований.
Cris
7

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

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

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

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

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

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

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

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

Карл Билефельдт
источник
«Качество кода - это очень субъективная вещь», согласился - вы должны быть осторожны с тем, что измеряете, а восприятие является важным фактором. Но восприятие, как и многие другие вещи, тоже податливо: посмотрите на взлеты и падения и подъемы функционального программирования, чтобы увидеть, что то, что люди думают о том, как они работают, не имеет прямого отношения к тому, как они работают. Я также недавно перечитывал TAOUP. Часть моей мотивации для этого вопроса - видеть в ранней литературе решения проблем, которые актуальны в разработке программного обеспечения.
+1: «Вторая проблема в том, что 50% разработчиков имеют талант ниже среднего». Это предложение мне облегчает. Это лучше, чем многие таблетки, которые я попробовал :)
NoChance
3

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

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

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

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

GlenPeterson
источник
2

Я изучаю различные способы разработки программного обеспечения более 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, и я надеюсь, что это поможет ...

Ричард Джон Боттинг
источник
1

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

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

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

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


источник
2
из реферата цитируемой статьи выделено мое: «Фактор квалификации означает, что эксперименты по разработке программного обеспечения уязвимы для предвзятости субъекта и экспериментатора . Фактор жизненного цикла означает, что трудно определить, как будут вести себя технологии после развертывания . Выводы: разработка программного обеспечения выиграет от принятие всевозможного подхода к доказательствам при условии, что он имеет дело с конкретными проблемами, возникающими из природы разработки программного обеспечения ». К чему я бы добавил: удачи в этом! ;)
Стивен А. Лоу
Стивен: часть мотивации, стоящей за EBSE, состоит в том, чтобы перейти от «я могу догадаться о следующих проблемах, поэтому я буду отвергать любые шансы на то, что ваше решение сработает», к анализу результатов по своему усмотрению. Есть гораздо больше, чем бумага, чем ее реферат.
2
Я ценю ваш энтузиазм. Медицинская наука и разработка программного обеспечения - радикально разные дисциплины. Хотя аналогия интересна, она вряд ли является новаторской. Полный текст статьи доступен здесь: labada.inf.utfsm.cl/~gvaldes/ESE/docs/… Раздел 5 отражает несоответствие импеданса, упомянутое в аннотации. Более прямым отображением медицинских методов будет отладка существующих систем, а не создание новых. ;) Если вы хотите создавать лучшие продукты, создавайте лучшие команды. Люди гораздо важнее, чем инструменты (см. Peopleware)
Стивен А. Лоу
1
Приложение: на сайте EBSE есть некоторая полезная информация, dur.ac.uk/ebse/evidence.php будет особенно полезна для новичков в области SE - но примите участие в опросах с соленой солью, потому что (1) имеющиеся доказательства является скудным и (2) средние результаты могут не иметь отношения к работе вашей команды конкретных людей с высокоспециализированными навыками и способностями.
Стивен А. Лоу
0

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

ОБНОВИТЬ

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

Woot4Moo
источник
Как мне выбрать, нанять ли команду Java-программистов или команду C-программистов? Должен ли я переучить их в Clojure? После того, как я выбрал свой алгоритм, какая архитектура является «лучшим» способом для его инкапсуляции в программном решении для заданных значений «лучший»?
@GrahamLee посмотри мое обновление
Woot4Moo
Я чувствую, что мы обсуждаем одну и ту же проблему, но на разных уровнях абстракции. «Использовать сильные стороны команды, которую вы имеете» означало бы никогда не создавать компьютер, потому что в Bletchley Park не было никого , кто мог бы создавать компьютеры. Иногда вы должны сказать «мы могли бы создать лучшее решение, если бы использовали эту вещь»; то, что я ищу, это информация об этих случаях.
0

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

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

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

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

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

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

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

Стивен А. Лоу
источник
1
Так не входит ли в компетенцию архитектор искать предшествующую работу, на которой строится его мнение? Вероятно, нет - отсюда и вопрос, можно ли и где найти такие результаты.
2
Если бы было определенное исследование с разумным экспериментальным методом, результаты исследования могли бы быть интересными; в таком виде, как представляется, в этих ответах говорится, что любое исследование бесполезно, независимо от метода, который мне слишком ненаучен
jk.
3
@Steven: слово «не доверять результатам действительно определенного исследования» - «суеверие». Возможно, то, что вы действительно имеете в виду, это то, что вы не верите, что когда-либо могут быть какие-то окончательные исследования в SE (это утверждение само по себе, очевидно, потребует большого количества подтвержденных доказательств).
Cris
1
Качество программного метода заключается в том, насколько хорошо он соответствует потребностям местного населения. В общем, это не ограничено законами физики (Скотти). Пройдет еще много времени, прежде чем «программному обеспечению» (дисциплине) удастся выработать свои неизменные фундаментальные законы. Например, см. «Метрики качества программного обеспечения: три вредных метрики и две полезные метрики» в ppi-int.com/newsletter/SyEN-046.php#feature и ppi-int.com/newsletter/SyEN-047.php#feature
Philip Окли
1
@Cris: для справки, нет, я не верю, что когда-либо может быть действительно окончательное исследование в этой области; см. приложение. Идея о том, что для принятия критического архитектурного решения вместо «экспертного суждения» может быть использовано «окончательное» исследование, - это «обращение к авторитету», что является формой логической ошибки :) По моему опыту - и я не делаю ничего общего обвинения, просто наблюдение - стремление к таким вещам чаще всего либо попытка избежать ответственности за решение, либо попытка поддержать решение, которое уже было принято.
Стивен А. Лоу