Является ли парадигма объектно-ориентированного программирования устаревшей, поскольку она антимодульная и антипараллельная? [закрыто]

23

Я прочитал противоречивую статью « Обучение ФП первокурсникам», которую написал Роберт Харпер, профессор КМУ. Он утверждал, что CMU больше не будет обучать объектно-ориентированному программированию во вводном курсе, поскольку он «не подходит для современной программы CS».

И он утверждал, что:

Объектно-ориентированное программирование полностью исключено из вводной учебной программы, потому что оно антимодульное и антипараллельное по самой своей природе.

Почему ООП считается антимодульным и антипараллельным?

сяо
источник
14
Buhwaaaah ?! ОО делает модульность и параллелизм проще, чем в процедурном, и не является взаимоисключающим для ФП. Цвет меня смутил.
Мэтт Эллен
4
Они переработали свой учебный план, поэтому он должен продать новую программу и делает смелые заявления, подкрепленные абсолютно без данных. Нет никаких доказательств того, что сложные функциональные программы являются более параллельными или модульными, чем их ООП-аналоги.
davidk01
4
@Matt Ellen: ООП определенно взаимоисключающий с FP. FP основывается на нескольких ключевых понятиях, одним из которых является отсутствие изменяемого состояния. ООП основывается на существовании изменчивого состояния, доступ к которому контролируется путем его оборачивания в «объекты». Изменчивое состояние и неизменное состояние являются взаимоисключающими в значительной степени по определению. Да, это правда, что вы можете программировать в функциональном стиле на многих языках ООП, но это не то же самое, что использование языка FP. И да, это правда, что не все языки FP являются чистыми. Это не значит, что FP совместима с ООП, однако.
ТОЛЬКО МОЕ правильное мнение
2
@ Просто: у меня другое представление о взаимной исключительности для вас. Я вижу чистый и нечистый FP как подмножества FP, и поэтому ООП не является взаимоисключающим от FP, если вы предполагаете, что изменчивость необходима для ООП. Также я не согласен, что изменчивость важна для ООП. Вы можете добиться и полностью OO системы, используя передачу сообщений, и никогда ничего не мутировать.
Мэтт Эллен

Ответы:

30

Пожалуйста , обратите внимание, что потребности Харпера для обучения в вводном учебном плане CS класса сильно отличаются от потребностей реального проекта жизни . Его работа состоит в том, чтобы преподавать фундаментальные понятия (например, модульность, параллелизм, индукция) новичкам. Таким образом, очень важно, чтобы выбранный язык (и парадигма) мог выражать эти понятия с как можно меньшей церемонией (синтаксической и концептуальной), насколько это возможно. Знакомство, поддержка инструментов, доступные библиотеки, производительность выполнения и т. Д. Совершенно не имеют значения в этом контексте. Поэтому, пожалуйста, имейте это в виду, учитывая следующее ...

Мнение , что OO является анти-модульные результаты большого числа зависимостей с другими классами даже объекты хорошо разработанные классы , как правило, в конечном итоге. То, что это проблема - даже в глазах сторонников ОО - становится ясным, если взглянуть на распространение платформ Dependency Injection , статей, книг и постов в блогах за последние годы (также интересно появление насмешек и заглушек).

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

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

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

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

Александр Баттисти
источник
10
Требования параллелизма из функционального лагеря часто преувеличиваются. Компиляторы для функциональных языков работают с более чистой фундаментальной теорией, поэтому у разработчиков есть больше способов реорганизовать код до его превращения в машинный код, но это не значит, что если вы предоставите ОО-программистам правильные абстракции для параллелизма, они не смогут написать чистый параллельный код. До сих пор процедурные программисты получили только блокировки и потоки, и я думаю, что с этими инструментами они справились довольно хорошо.
davidk01
2
Хотя я в целом согласен со всем, что вы здесь говорите, я хотел бы отметить, что шаблоны проектирования присутствуют во всех парадигмах программирования. Для функционального программирования я бы выделил такие вещи, как монады и карты / сокращения.
Anm
@ davidk01 Возьми Go, например. Он поддерживает объектно-ориентированное программирование и имеет большие примитивы параллелизма. Что еще более важно, это действительно взлетает для параллельного программирования, не будучи чисто функциональным.
weberc2
19

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

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

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

  2. Утверждение, что ООП является антипараллельным, просто демонстрирует отсутствие понимания. ООП не фиксирует никаких решений относительно параллелизма. ООП диктует только их скрыть: при правильной сборке вы не можете сказать, является ли реализация объекта параллельной или нет.
    Таким образом, в конечном итоге ООП и параллельное программирование являются ортогональными. Модель актера - это элегантная модель параллелизма, которая может быть непосредственно отражена в объектной системе (но не обязательно), создавая потрясающую комбинацию обоих.

Проблема с ООП состоит в том, что мало кто на самом деле понимает это в том смысле, в каком его определил Алан Кей .

  1. ООП это подход. В некоторых языках это реализовано с использованием шаблонов, в других вы можете напрямую использовать встроенные языковые идиомы (например, Ruby, Objective-C, Smalltalk, Io ).
  2. Вопреки распространенному мнению, ООП не о классах. Речь идет об объектах, а объекты - о передаче сообщений или о одинаково неплотном способе инкапсуляции и абстракции.

Вот почему Java для ООП является тем, что заостренные палки для морского боя. Это также верно для многих других так называемых «ООП-языков», но в Java есть то, что в университетах существует общее мнение, что Java следует использовать для обучения ООП.

Я согласен со всеми, кто считает, что введение в ООП с Java должно быть исключено из учебных программ по CS. Я также думаю, что люди, которым явно не хватает фундаментального понимания ООП, не должны этому учить. Так что, вероятно, было бы лучше, если бы Боб придерживался ML для своих курсов и просто учил тому, что у него есть твердое понимание.
Прямо сейчас ООП - это больше модный этикет, который людям нравится придерживаться. Это вредит ООП и сказал людям. ООП не устарел. Золотой век ООП является еще впереди, когда люди , наконец , понять , что это такое , что это не о том (например , решая все возможные проблемы с помощью ключевого слова class500 раз).

back2dos
источник
1
+1 для передачи сообщений и +1 для «с Java». К сожалению, если бы они удалили Java, они бы просто заменили его на C # и продолжили его наследие.
gbjbaanb
@ back2dos +1 для критиков, -1 для Java. Конечно, Smalltalk "намного больше ОО", чем Java, но кто его использует? Objective-C труден для начинающих, как и C.
Maaartinus
@maaartinus: Вы найдете, что Squeak широко используется в образовательной и академической сфере, если это отвечает на ваш вопрос. Также как и для Java: вам может понравиться, а может и нет. Во многом как кофе, это вопрос личных предпочтений, и нет смысла обсуждать это. Однако Java, не подходящая для введения в ООП, является ИМХО бесспорным следствием природы Java и концепции ООП, и это именно то, что я сказал. Популярность Java не уйдет. Что касается C, я предлагаю вам прочитать joelonsoftware.com/articles/ThePerilsofJavaSchools.html .
back2dos
@ back2dos Скрип может использоваться в этих областях, но в университете я изучил ML. Оба одинаково непригодны для использования в отрасли, и оба заслуживают изучения из-за своих концепций. Указанная статья - худшая статья Джоэля, которую я когда-либо читал, она слишком длинная, и на первый взгляд кажется, что важно разобраться с ошибками сегмента. : D Я бы действительно предложил Java для обучения ООП.
Maaartinus
@maaartinus: То, что вы узнали в университете, мало что значит в вопросе, чему следует учить . Вы по-прежнему не указали причин, по которым следует использовать Java для обучения ООП, в то время как я привел то, что считаю вполне обоснованным, почему бы не сделать это. Также вы, очевидно, не смогли понять суть статьи: люди, которые не могут справиться с проблемами так же сложно, как C, не должны изучать CS в первую очередь. Я думаю, что CS не следует удивляться тому, что может понять каждый ребенок, который любит компьютеры. Если мы не можем согласиться с этим, дальнейшее обсуждение - пустая трата моего и моего времени.
back2dos
12

Вы получаете фанатиков каждой полосы.

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

Без сомнения, через двадцать лет у нас будет еще одна отрицательная реакция на функциональное программирование.

Фрэнк Шиарар
источник
1
Там уже есть!
Quant_dev
1
++ «Ты получаешь фанатиков всех мастей». Я был академиком, и мой опыт был таким . Академики любят высказывать провокационные мнения, впечатляя, может быть, своих учеников.
Майк Данлавей
5

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

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

Распараллеливание : Что касается параллельного программирования, большинство фреймворков поддерживают прерывания, затем многопоточность и теперь правильное распараллеливание, такое как то, что мы видим в .Net framework 4.0 и языки ООП, которые на него навязывают.

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

CarneyCode
источник
4

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

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

Лично я думаю, что это излишне, но ученые любят пробовать новые и экстремальные вещи. В качестве противовеса MIT использовал (и мог бы по-прежнему) преподавать все основные парадигмы программирования в одном классе новичка.

Как ни странно, обе школы подготовили несколько действительно хороших программистов. Пойди разберись.

Стивен А. Лоу
источник