Чи застаріла парадигма орієнтованого на об'єктивне програмування, оскільки вона є антимодульною та антипаралельною? [зачинено]

Я прочитав суперечливу статтю Навчання ФП для першокурсників, опубліковану Робертом Харпером, професором КМУ. Він заявив, що КМУ більше не буде викладати об'єктно-орієнтоване програмування у вступному курсі, оскільки це "непридатно для сучасної навчальної програми CS".

І він стверджував, що:

Об'єктно-орієнтоване програмування повністю виключається із вступного навчального плану, оскільки воно є як антимодульним, так і антипаралельним за своєю суттю.

Чому вважати ООП антимодульним та антипаралельним?

Зверніть увагу, що потреби Гарпера у викладанні вступного класу навчальних програм CS дуже сильно відрізняються від потреб проекту реального життя . Його завдання - навчити першокурсників фундаментальних понять (наприклад, модульність, паралелізм, індукція). Як таке, дуже важливо, щоб обрана мова (і парадигма) могла виражати ці поняття якомога менше обрядовості (синтаксичної та концептуальної). Ознайомлення, підтримка інструментів, наявні бібліотеки, продуктивність виконання тощо в цьому контексті абсолютно не мають значення. Тому, майте на увазі, враховуючи наступне ...

Думка про те, що ОО є антимодульним результатом через велику кількість залежностей від інших класів, з якими стикаються навіть об'єкти добре розроблених класів. Це проблема - навіть в очах прихильників ОО - стає зрозуміло, коли ви дивитесь на поширення рамок , статей, книг та публікацій в блогах за останні роки ( залежно від зростання макетів та заглушок).

Ще один натяк на важливість шаблонів дизайну та складність їх застосування - порівняно з деякими іншими парадигмами програмування - наприклад, Фабрики, Будівельник, Адаптер, Міст, Декоратор, Фасад, Команда, Ітератор, Посередник, Спостерігач, Стратегія та Метод шаблонів і, можливо, Композиція певним чином пов'язана з поліпшенням модульності коду OO.

Спадкування також є проблематичним (наприклад, крихка проблема базового класу ) та (підтип) поліморфізм спокушає одного до розширення реалізації алгоритму між декількома класами, де зміни можуть переплестися по всьому ланцюгу спадкування (вгору і вниз!).

Обвинувачення в тому, що воно є паралельним , пов'язане з акцентом на стані порівняно з обчисленнями (т.к. мінливість проти незмінність). Перший робить його більш задіяним для вираження залежностей від підрахунків (це Харпер приймає на паралелізм!), Оскільки зазвичай не можна зробити висновок з місця, яким керує стан (ака. Файл, де оголошена змінна екземпляра), який знаходиться поза суб'єктами змінить його в якийсь момент часу.

Наголос на незмінюваності та обчисленнях значно полегшує вираження залежностей від підрахунків, оскільки не існує управління державою, а лише функції / обчислення, які поєднуються там, де ви хочете висловити залежності підрахунків.

Це, мабуть, сміливе твердження, але я якось підозрюю, що цей Роберт Харпер ніколи не писав реального програмного забезпечення у своєму житті. Він, здається, турбує себе - це ML та системи статичного типу. Наскільки це може бути великий внесок, я не бачу, як його претензії щодо ООП мають релевантність.

Ця стаття не є суперечливою. Суперечка передбачає експертизу, аргументацію та дискусію. У вас тут є якийсь неосвічений академік, який висуває два досить фундаментальні звинувачення лише в одній заяві, не намагаючись наводити жодних аргументів.

1. Твердження про те, що OOP є антимодульним, є просто нонсенсом. Я навіть не знаю, як на це відреагувати, не тільки аргументи не наводились, але і OOP задумом - це підхід до встановлення модульності з дуже низькою зв’язкою між окремими модулями за допомогою інкапсуляції та абстракції.

2. Претензія на ООП є антипаралельною, просто демонструє нерозуміння. OOP не блокує жодних рішень щодо одночасності. OOP диктує лише їх приховування: Якщо правильно побудовано, ви не можете сказати, паралельна чи ні реалізація об'єкта.
   Таким чином, OOP і паралельне програмування є ортогональними. Модель актора - це елегантна модель для одночасності, яка може бути безпосередньо відображена в об'єктній системі (але цього не повинно бути), даючи грандіозне поєднання обох.

Проблема з ООП полягає в тому, що мало хто насправді розуміє це в тому сенсі, як це визначив Алан Кей .

1. OOP - це підхід. У деяких мовах вона реалізується за допомогою шаблонів, в інших можна безпосередньо використовувати вбудовані мовні ідіоми (наприклад, Ruby, Objective-C, Smalltalk, Io ).
2. Всупереч поширеній думці, ООП не стосується занять. Йдеться про об'єкти та об'єкти - про передачу повідомлень або настільки ж непрохідний спосіб інкапсуляції та абстрагування.

Ось чому Java - OOP, якими загостреними палицями є морський бій. Це справедливо і для багатьох інших так званих "мов OOP", але справа в Java полягає в тому, що в університетах, як видається, існує загальна думка, що Java повинна використовуватися для викладання OOP.

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

Ви отримуєте завзяток кожної смуги.

Об'єктно-орієнтоване програмування - це не срібна куля. Це ніколи не було. Що це таке, - жертва ажіотажу. Неминуче люди хворіють на ажіотаж, і люфт починає розвиватися (незалежно від фактичної корисності парадигми).

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

Я не можу відповісти на це питання повністю, бо можна лише вдруге здогадатися про розпливчасті думки його автора. Я сильно підозрюю, що ця стаття ось-ось викличе збентеження її автора. Немає нічого про OOP, що б підказувало, що воно не є ні модульним, ні паралельним:

Модульність : Основна грань OOP полягає в тому, що вона дійсно є модульною (але модульність означає різні речі в різних контекстах). Отже, незалежно від того, говорить автор про узагальнення чи статичне програмування, він є невірним.

Паралелізація : Що стосується паралельного програмування, більшість фреймворків підтримують перехрестя, а потім нарізування ниток і тепер правильну паралелізацію, наприклад, те, що ми бачимо в.

Я підозрюю, що автор став жертвою моди в тому, що існує помилкова думка, що функціональне програмування та OOP взаємно виключають у використанні. Існують функціональні стилі в мовах ООП, які добре задокументовані, наприклад, Олівер Штурм опублікував у цій галузі.

Автор стверджує, що OOP занадто складно зрозуміти програмістам-першокурсникам, що може бути правдою - хоча я сумніваюся в цьому, враховуючи вимоги до вступу до КМУ! Антимодульні та антипаралельні твердження можуть бути правдивими у вузькому контексті порівняно з суто функціональними мовами, але навряд чи є осудом цілої парадигми (яка, здається, спрацює нормально для тих, хто вміє її використовувати).

Пропонована навчальна програма навчає функціонального програмування в одному класі, імперативного (процедурного) програмування в іншому класі та структури даних в іншому класі. Після того, як першокурсник оволодів цими трьома речами, він / вона має бути готовим навчитися OOP.

Особисто я думаю, що це надмірно, але науковці люблять пробувати нові та екстремальні речі. Як противагу, MIT використовував (і може все-таки) викладати всі основні парадигми програмування в одному класі першокурсника.

Як не дивно, обидві школи підготували справді хороших програмістів. Піди розберися.