LINUX.ORG.RU

[philosophy] В чем заключается революционность перехода от функциональщины к ООП?


1

0

Так уж повелось, что первый язык, который я изучал, был делфи. Потом всякие сишарпики, С++, лисп, и т.п. В итоге, как мне кажется, у меня ООП головного мозга. Когда возникала задача писать на С, я начал реализовавывать обьектную модель в этом языке.

«Стоп», сказал я себе и подумал. Почему сейчас все кругом вопят про ООП и про его архиполезность и архиправильность? Далее, по ходу раздумий, пришел к мысли, что все, что пишется с использованием ООПшной парадигмы, может быть написано и без нее.

Почему появились языки, которые взяли ООП за главенствующую идею (java, c#, етц)?

Неужели те преимущества, которые предлагает ООП (полиморфизм, инкапсуляция, наследование), дают прирост в эффективности, скорости написания программ, понимания их работы и поддержке? Здесь было бы интересно сравнить одну и ту же программу, написанную на С и на С++, чтобы узреть принципиальные архитектурные различия (может такие уже есть?).

Сухой остаток. ООП представляет из себя еще один уровень абстракции, который позволяет оперировать про проектировании не функциями, а обьектами. А неужели это так меняет дело и делает разработку более удобной?

Было бы интересно без срачей услышать компетентное мнение.

★★

Ответ на: комментарий от linuxfan

Мосье ратует за декларативщину? А какие языки ее поощряют? На ум приходит только Prolog. SQL полноценным языком назвать сложно, а PL/SQL по степени декларативности вполне сравним хоть с C, хоть с асмом.

Уже тепло. Функциональный стиль действительно близок к декларативщине. :)

dave ★★★★★
()
Ответ на: комментарий от anonymous

>>наследование и виртуальные методы - основа создания гуёвых интерфейсов

Как бы я сам то согласен, но вот gtk'шники успешно извращаются.

Глупость сказал. Наследование и виртуальные методы там есть и реализованы на Си

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

>>>наследование и виртуальные методы - основа создания гуёвых интерфейсов

Как бы я сам то согласен, но вот gtk'шники успешно извращаются.


Глупость сказал. Наследование и виртуальные методы там есть и реализованы на Си


А где я сказал что их нет? Извращаются как раз потому что переизобретены на С. Так что не глупи и повнимательнее читай чужие комментарии.

anonymous
()
Ответ на: комментарий от anonymous

> Мы говорим про представление сущности объектами или про перечисление всех возможных объектов?

Меня интересуют ограничения объектной модели --- вполне естественное желание, по-моему. Пример с несчетным множеством можно продолжить, изучив вопрос о вычислимости функции «содержитЛи()».

Но это в каком-то смысле маргинальные задачи.

oami ★★
()
Ответ на: комментарий от jtootf

>>покажи мне наследование и виртуальные методы в Tcl/Tk, REBOL GUI, XPCE или QML

В QML это есть, только называется по-другому. По остальное ничего не могу сказать, на реболе видел только калькуляторы и таблички, наверно это всё что он может? Ещё раз - при создании GUI приложений без виртуальных методов не обойтись, ПОД ЧТО бы они не были завуалированы. В KDE/Qt это виртуальные методы, в QML это состояния. Просто так устроены окна, и так работает event propagation.

alex_custov ★★★★★
()
Ответ на: комментарий от Kuka

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

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

Quasar ★★★★★
()
Ответ на: комментарий от iZEN

iZEN> Современные микросхемы нигде не уступают лампочкам, а тем более транзисторам.

Уступают, и очень сильно. Подсказка: не музыкальная область, а вполне промышленная.

Quasar ★★★★★
()
Ответ на: комментарий от alex_custov

без виртуальных методов не обойтись, ПОД ЧТО бы они не были завуалированы

а вот это уже чистой воды демагогия

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

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

alex_custov ★★★★★
()
Ответ на: комментарий от Kuka

Наверное, вы хотели сказать «от процедурщины к ООП»? Ничего страшного, тут такие ляпы делают на каждом шагу.

таки императивщины

wlan ★★
()
Ответ на: комментарий от oami

>Меня интересуют ограничения объектной модели --- вполне естественное желание, по-моему. Пример с несчетным множеством можно продолжить

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

anonymous
()
Ответ на: комментарий от anonymous

anonymous> Никакой инкапсуляции функциональщина не дает, потому и применять ее можно только в гибридных языках

Посмотри на Haskell. Чисто функциональный.

Quasar ★★★★★
()
Ответ на: комментарий от alex_custov

без идеи, аналогичной виртуальным методам, писать нормальный GUI будет весьма проблематично

и называется эта идея поздним связыванием, или run-time dispatching. непосредственного отношения ни в общем к ООП, ни конкретно к виртуальным методам не имеет

jtootf ★★★★★
()
Ответ на: комментарий от Manhunt

>Ты путаешь. Так пытаются объяснить концепции конечного автомата и машины тюринга. Без хотя бы смутного понимания которых быдлокодить не получится.

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

Waterlaz ★★★★★
()
Ответ на: комментарий от alex_custov

без идеи, аналогичной виртуальным методам, писать нормальный GUI будет весьма проблематично

и, кстати, ни разу не проблематично. посмотри всё же на Tcl/Tk - там нет ничего аналогичного вируальным методам; что-то подобное можно ввести с помощью того же Snit или XOTcl, но необходимости в подобном механизме - не наблюдается

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

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

Ну нифига себе естественных. Понимание ООП неимоверно трудно. Понимание императивной парадигмы на порядки проще. Понимание функционального программирования где-то между ООП и императивной парадигмами.

Quasar ★★★★★
()
Ответ на: комментарий от alex_custov

при создании GUI приложений без виртуальных методов не обойтись

MFC?

dave ★★★★★
()
Ответ на: комментарий от Manhunt

Я предложил это исходя из своей модели предметной области.

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

Ох, объекты - это не признак ОО подхода?

Во-1, не «ОО подхода», а ООП. Во-2, признак, но мы не об этом говорим.

Инкапсуляция - тоже не признак ОО подхода?

Не, не признак. Это именно что признак хорошей модульности.

Miguel ★★★★★
()
Ответ на: комментарий от wlan

>>Наверное, вы хотели сказать «от процедурщины к ООП»? Ничего страшного, тут такие ляпы делают на каждом шагу.

таки императивщины

____<

yoghurt ★★★★★
()

Эх раз, ещё раз

Сравнивать императивщину и ООП - это как сравнивать теплое с мягким.

yoghurt ★★★★★
()
Ответ на: комментарий от Quasar

>Понимание ООП неимоверно трудно.

Пациентов из школы-интерната для даунов мы уже обсудили выше.

anonymous
()
Ответ на: комментарий от iZEN

> Современные микросхемы нигде не уступают лампочкам, а тем более транзисторам.

Покажите мне киловаттный УНЧ/УВЧ/etc. на микросхемах.

(Отныне это тред «микросхемы vs. транзисторы vs. электровакуумные приборы».)

Kuka ★★
()
Ответ на: комментарий от Quasar

> Понимание функционального программирования где-то между ООП и императивной парадигмами.

Это возможно справедливо для незамутнённого разума. Но тем, кто учился программировать в рамках императивной парадигмы (а это подавляющее большинство программистов), функциональщина довольно трудно даётся. Потому как принципиально иной подход к вычислениям (подстановочная модель). В то время как ООП - это просто развитие привычной императивной модели с состоянием. Потому обучить худо-бедно ОО-языку и паттернам можно даже птушника. Конечно шедевров OO-дизайна от него ждать не стоит, но как чернорабочий для индустрии сгодится. А вот с функциональщиной совсем иная ситуация. Тут даже хелловорлд потребует суровой ломки привычек и рефлексов. А уж чем дальше в дебри, тем суровее. Пытаясь обойти естественные ограничения подстановочной модели функциональщики приходят либо к компромиссным вариантам (как ООП в окамле), либо к таким извращениям (хаскельные монады), после которых уже ни у кого язык не повернётся назвать ФП простым для понимания. В конце концов народ голосует ногами, выбирая ОО-языки, которые _проще_ и оттого популярнее.

anonymous
()
Ответ на: комментарий от Manhunt

>Если учесть, что количество даже конечных множеств кардинально больше, чем 2^объем_всех_существующих_цифровых_накопителей_выраженный_в_битах, то становится ясно, что возможности обработки множеств на компьютере весьма ограничы. Только не совсем понятно, причем тут объекты.

:3 Колчество целых чиел тоже, но тем не менее, ты с ними успешно работаешь

Waterlaz ★★★★★
()
Ответ на: комментарий от anonymous

> Пытаясь обойти естественные ограничения подстановочной модели функциональщики приходят либо к компромиссным вариантам (как ООП в окамле), либо к таким извращениям (хаскельные монады), после которых уже ни у кого язык не повернётся назвать ФП простым для понимания.

Поэтому будущее за гибридными языками - ФП+ООП :)

tailgunner ★★★★★
()
Ответ на: комментарий от jtootf

> ты таки что-то имеешь против монад?

Наверное то, что их трудно, при всём желании, отнести к чему-либо естественному.

archimag ★★★
()
Ответ на: комментарий от jtootf

> посмотри всё же на Tcl/Tk - там нет ничего аналогичного вируальным методам; что-то подобное можно ввести с помощью того же Snit или XOTcl, но необходимости в подобном механизме - не наблюдается

Ну привет, как это не наблюдается? А мегавиджеты тебе не нужны совсем? Почему собственно появился Snit. Потому что не было стандартных механизмов расширения. Вот тебе базовый набор виджетов-команд и всё, делай что хошь. И люди городили несовместимый лес, пользуясь разными (часто самописными) объектными обёртками. Snit именно потому не используют наследование, что была цель - склеить эту разнородную хероту. Но в основе то всё равно OO-полиморфизм, пусть и без наследования. Одна из главных бед тикля на мой взгляд как раз в том, что вовремя не сделали стандартную OO-подсистему. Делать гуи без ООП очень хреновая идея. Вон гткшникам пришлось прикручивать ООП к сям. А уж в тикле после реализации неймспейсов это было как два пальца... Но созрели только к 8.6, когда Tcl/Tk уже пора в музей.

anonymous
()
Ответ на: комментарий от archimag

Наверное то, что их трудно, при всём желании, отнести к чему-либо естественному.

Ну уж не более нестественная штука, чем, скажем IAbstractDatabaseContainerFactory.

Miguel ★★★★★
()
Ответ на: комментарий от archimag

>> Поэтому будущее за гибридными языками - ФП+ООП :)

Ну т.е. за Common Lisp?

Нет, конечно. CL всей свое жизнью доказал свое лузерство^W^W, что он никогда не станет мэйнстримом (мы же о мэйнстриме говорим, или я что-то не так понял?).

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

А мегавиджеты тебе не нужны совсем?

я написал до чёрта GUI на Tk, но создавать мегавиджеты не приходилось ни разу. так, чтобы поиграться и попробовать разные маханизмы - это да, а вот на практике - нет

Ну привет, как это не наблюдается?

ну и где там позднее связывание? в делегации событий к агрегируемым виджетам что ли?

jtootf ★★★★★
()
Ответ на: комментарий от Miguel

>> Ну т.е. за Common Lisp?

Я что-то пропустил? Лисп неожиданно стал функциональным языком?

Очевидно он осознал разницу между «функциональный» и «чисто функциональный».

SV0L0CH
()
Ответ на: комментарий от archimag

Наверное то, что их трудно, при всём желании, отнести к чему-либо естественному.

вообще-то в монаде по определению целых два естественных преобразования ;)

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> ты таки что-то имеешь против монад?

Нет. Я лишь считаю, что концепция монад сложна для понимания. И вообще хаскель весьма сложный язык по сравнению с лидерами OO-мейнстрима жабкой и шарпом. Есть что возразить?

anonymous
()
Ответ на: комментарий от Miguel

> Которая никому нафиг не нужна. Несколько возможных решений были приведены; ты придумал модель, которая им противоречит. Уймись.

прекрати бредить — твоя модель ничем принципиально не лучше модели Manhunt-а;

более того, твоя модель хуже тем, что она подогнана под ограничения конкретных языков, а не под реальность из предметной области;

при проектировании так можно делать (подгонять модель под возможности языка), но это рискованно — можно получить профит, а можно и обломаться потом, особенно в скорости выполнения и потребляемой памяти

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>а не под реальность из предметной области;

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

anonymous
()
Ответ на: комментарий от jtootf

> нет. но монады хорошие

+1

монады — это не только ценный мех...

но вот кодирование императивной последовательности монадами на имеративном железе — это, вероятно, извращение; было бы функционально-ленивое железо — тогда еще можно было бы как-то это терпеть

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от jtootf

> ну и где там позднее связывание? в делегации событий к агрегируемым виджетам что ли?

Делегация событий - это всего лишь деталь реализации Snit. Само использование снитовских (и любых других) объектов в динамическом языке предполагает позднее связывание. Благодаря чему возможен тот самый ad-hoc полиморфизм.

я написал до чёрта GUI на Tk, но создавать мегавиджеты не приходилось ни разу

Ну счастливый, что там говорить. Всё видать писал сам (for fun?), с legacy дела не имел. А люди кроме своих велосипедов наворотили ещё всяких Iwidgets, видимо нечем заняться было.

anonymous
()
Ответ на: комментарий от anonymous

> Стоит заметить, что предметную область так никто и не обозначил

да

что все их потуги исходно смешны и бессмысленны.

нет

archimag придумал пример, который я немного разовью: допустим, мы пишем autocad, но аксиоматика пространства, в котором он будет работать, пока не известна — то ли оно будет евклидово, где к каждой прямой имеется ровно одна параллельная, то ли неевклидово (и там м.б. параллельных много либо ни одной в зависимости от кривзны)

так что хорошие языки должны позволять работать (в т.ч. чекать констрайнты) и в таких условиях

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

Само использование снитовских (и любых других) объектов в динамическом языке предполагает позднее связывание

не понял. поясни. лучше, если на примере тех же IWidgets - где у меня при их использовании появится позднее связывание?

Всё видать писал сам (for fun?)

сам. и for fun, и по работе

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> и называется эта идея поздним связыванием, или run-time dispatching. непосредственного отношения ни в общем к ООП, ни конкретно к виртуальным методам не имеет

виртуальные методы — это реализация run-time dispatching

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

допустим, мы пишем autocad, но аксиоматика пространства, в котором он будет работать, пока не известна

что мы тогда пишем?

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

виртуальные методы — это реализация run-time dispatching

спасибо, кэп

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> было бы функционально-ленивое железо — тогда еще можно было бы как-то это терпеть

Функционально-ленивое железо никто терпеть не стал бы. А вот ФЛЯ (:)) на обычном железе - наверное, оправданы.

tailgunner ★★★★★
()
Ответ на: комментарий от Miguel

> C++-style ООП отвечает: в рантайме. Оптимизатор, в принципе, может и выбрать вариант при компиляции, но делать это не обязан и, в общем случае, не может. Хаскельные классы производят такой выбор на стадии компиляции.

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

аксиоматика пространства, в котором он будет работать, пока не известна

интересная, кстати, тема. как ты предлагаешь проверять соответствие аксиоматике?

взять что-нибудь проще пространства - полугруппу, скажем,- как ты предлагаешь доказывать замкнутость и ассоциативность для типа, заявленного инстансом полугруппы?

jtootf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.