LINUX.ORG.RU

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


1

0

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

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

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

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

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

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

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

> Ты топик не читал, просто увидел знакомый ник и решил при&%аться. Что ж, как при&%ался, так и отъ&%ёшся.

Ты как обычно слил. Понятно, крыть то нечем тот факт, что хаскелль только для ночного задротства и годится. А утром на работу, а там опять унылый C++. Наверно нехилый дискомфорт доставляет такая раздвоенность сознания. Душа гения стремится к прекрасному, но разбивается о суровую действительность. Ну хоть на лоре отдохнешь, задротыч.

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

Это нормальная практика, тут нечему удивляться. Если такая экзотика и находит применение в коммерческих проектах, кто, это как, правило благодаря сочетанию нешарящего менеджера + разработчик-сектант.

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

Ты как обычно слил.

Гм. Какое из своих утверждений в этом топике я «слил»? Ткни пальцем, иначе будем считать, что ты тупо спиздел.

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

Ты не там ищешь плюшки ООП. Они - в ad-hoc полиморфизме.

Дядь, вот ты талдычишь весь топик, что ООП — это по сути один лишь ad-hoc полиморфизм. А можешь указать, что почитать, чтобы это стало очевидно?

Но только так, чтобы не пришлось несколько лет изучать 200 различных точек зрения на ООП, а потом самому сделать вывод, что единственное, что их объединяет — это ad-hoc полиморфизм.

P.S. Желательно, чтобы это была ссылка на статью кого-нибудь из крутых дядек, где все коротко раскладывается по полочкам. А то как ни открою какую-нибудь википедию, там плюсовый маразм в каждом предложении.

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

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

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

> Ты как обычно слил. Понятно, крыть то нечем тот факт, что хаскелль только для ночного задротства и годится. А утром на работу, а там опять унылый C++. Наверно нехилый дискомфорт доставляет такая раздвоенность сознания. Душа гения стремится к прекрасному, но разбивается о суровую действительность. Ну хоть на лоре отдохнешь, задротыч.

Ты так толст, что тебе пора уже регистрироваться

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

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

Чего никогда не понимал, так это формализованных «шаблонов проектирования». Шаблоны и приемы существуют всегда. Их нужно умело комбинировать как строительные кирпичики. Но когда начинают это дело формализовывать, отливать в бетоне, то у меня возникает какое-то чувство неправильности происходящего :)

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

Почему? Формализация и конкретизация паттернов - очень даже хорошее дело. Потому что их потом можно записать макросами(в стандартной библиотеке того же CL куча таких паттернов - WITH-OPEN-FILE, например, очень хороший и полезный паттерн).

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

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

> Дядь, вот ты талдычишь весь топик, что ООП — это по сути один лишь ad-hoc полиморфизм.

Он талдычит не это, он талдычит, что ООП не нужен, если есть нормальный ad-hoc полиморфизм в ЯП. Что тоже весьма спорно, конечно.

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

Потому что их потом можно записать макросами

А можно - записать обычным исполняемым кодом, а не макрокостылями.

Тот же with-open-file, скажем, становится обычной фукнцией.

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

Он талдычит не это

Да, в общем, и это тоже.

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

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

Более чем спорно.
ООП это состояние + взаимодействие.

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

> А можно - записать обычным исполняемым кодом, а не макрокостылями.

нихера не шаришь же

Тот же with-open-file, скажем, становится обычной фукнцией.

чем-чем? о_О

LOL

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

Ага, и засрать производительность(а также место, на thunk'и и прочее говно) и интерфейс.
Кроме того, существует куча паттернов, которые так вот просто в функции высшего порядка не разложишь. Да, по факту, разложить таким образом можно только самые примитивные, шаблонные, паттерны.

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

Тогда я теряюсь в догадках, что же такое «шаблон проектирования». Я имел ввиду что-то типа Command или Visitor. Впрочем, в этой теме несилен. Главное - это хорошая постановка задачи с сопутствующим анализом, то есть моделированием, обыгрыванием, проектных решений. Тогда шаблоны как-то сами собой вырисовываются. Зачем их отдельно изучать? Тем более, человеку с мат. образованием :)

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

>А можно - записать обычным исполняемым кодом, а не макрокостылями.

Именно. Макросы - зло. Это ещё отец всея быстрого ООП Страуструб проповедовал.

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

>Я имел ввиду что-то типа Command или Visitor.
Это слишком узкая, даже дебильная, трактовка.

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

> узкая, даже дебильная, трактовка.

очередной наплыв дебилов...

Таке впечатление, что ты в комнате с зеркальными стенами.

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

ООП - это одна техническая подробность (ad-hoc полиморфизм) плюс специфический стиль программирования.

Чем же тогда является состояние ( = объекты + время) ?

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

> Залогинился, наконец, да?

Не разлогинился еще.

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

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

Да не получается так, тогда придется clojure считать тоже объектно-ориентированной.

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

>Зачем их отдельно изучать? Тем более, человеку с мат. образованием :)

А на собеседованиях спрашивают. При решении более-менее нетривиальных задач «мышление шаблонами» IMHO только повредит

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

А то я их никак не могу понять, они представляют собой

http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

за редким исключением они представляют собой костыли, подпирающие тот или иной недостаток подлежащего ОО-языка

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

>> читай по буквам Ф-У-Н-К-Ц-И-Е-Й.

(Н-Е-У-Г-А-Д-А-Л)

ты просто говно.

Вот, нагло стырено из интернета. Функция, как функция:

withOpenFile:: FileName -> FileMode -> (Handle -> IO a) -> IO a

withOpenFile name mode = bracket (openFile name mode) hClose

Waterlaz ★★★★★
()

Никому не надоело о сферических конях в вакууме спорить? Обсуждали бы на примере реальных программ что-ли. А то как не откроешь какой-нибудь код от Google, так там Java/С++ и много-много ООП. Или все спецы на ЛОРе прячутся, а в Google только «шаблонно мыслящих ламеров-индусов» берут?

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

> Тот же with-open-file, скажем, становится обычной фукнцией.

чем-чем? о_О

Обычной функцией. Учи матчасть. Таковая есть в поставке GHC, называется withFile.

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

Ага, и засрать производительность(а также место, на thunk'и и прочее говно) и интерфейс.

??? Это с чего вдруг?

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

Ну так скажи, какие?

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

Чем же тогда является состояние

Признаком императивности.

Или ты хочешь сказать, что в C-шных программах состояния нет?

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

Да не получается так, тогда придется clojure считать тоже объектно-ориентированной.

А в clojure принят ООП-шный стиль программирования? Он как-то поддерживается языком?

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

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

Ну вот, для нормального языка:

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

Что-то не так?

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

> А в clojure принят ООП-шный стиль программирования? Он как-то поддерживается языком?

Вопрос не в том принят или нет, а в том, возможно ли на нем принципиально писать сразу в ООП-стиле. By design в нем нет технических возможностей для этого, а не моего желания. Посему ООП - это не просто ad-hoc полиморфизм.

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

возможно ли на нем принципиально писать сразу в ООП-стиле.

Ха, так в этом стиле можно писать хоть на том же C.

Вопрос в том, является ли такой стиль естественным.

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

withOpenFile

Обсуждалось уже, ленивость не покрывает возможностей макросов:

http://www.newartisans.com/2009/03/hello-haskell-goodbye-lisp.html

Макрос это выразительное средство над самим кодом (мета-средство, короче), ленивость же - просто стратегия вычисления кода. Это очень разные вещи. Если бы ленивость покрывала возможности макросов, то вещей вроде TH, Liskell просто не возникало бы.

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

>> http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5044184

да ты просто фразу из контекста вырвал. первоначально Лове5фан заикнулся на счет паттерна в cl:with-open-file. Мигель назвал его функцией, так как не в теме.

Нет, Мигель сказал, что такие вещи можно делать функциями высших порядков, а не макросами. Кстати, с возможностью этого и Love5an не спорит. А ты начал пороть какую-то хрень, так как не в теме.

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

> Тот же with-open-file, скажем, становится обычной фукнцией.

хаскелляторы такие хаскелляторы. тьфу на вас.

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

> Нет, Мигель сказал, что такие вещи можно делать функциями высших порядков, а не макросами. Кстати, с возможностью этого и Love5an не спорит. А ты начал пороть какую-то хрень, так как не в теме.

и на тебя тьфу.

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

тьфу на вас.

Плеваться можешь сколько угодно, но нигде я лисповый макрос with-open-file не называл функцией.

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

Чем же тогда является состояние

Признаком императивности.
Или ты хочешь сказать, что в C-шных программах состояния нет?

Ок, императивность. А ООП это просто ad-hoc полиморфизм и определённый стиль поверх неё. Я вообще-то хотел спросить, как мне написать что-то вроде state machine с состоянием в рамках чистого ФП:


class Stack
  stack :: list

method put object (stack :: Stack)
  stack <- (cons object stack)

// и теперь

with-stack my-stack ()
  put 1 my-stack
  put 2 my-stack
  put 3 my-stack
  // будем иметь (1 2 3)

оч. интересно)

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

> Ха, так в этом стиле можно писать хоть на том же C.

Сразу - нельзя, ООП хоть как-то, но нужно реализовать средствами языка, glib тому пример.

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