LINUX.ORG.RU

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


1

0

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

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

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

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

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

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

★★

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

ну и, назвали иммутабильную структуру, список, ввод-вывод и т.д массивом.

Ты обкурился? Кто назвал список массивом? Кто назвал ввод-вывод массивом?

Мутабельные массивы есть искаропки в GHC, причём давно. В Hugs - не помню, может, тоже есть.

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

Вот и публикуй свое альтернативно-ассемблерное понимание интерфейсов и контрактов от своего имени.

У меня нет ассемблерного понимания интерфейсов, с чего ты взял.

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

> Кто наш сферический в вакууме разработчик? Обезьяна с гранатой? Ok, запретим давать хирургам скальпель, знаете, чего натворить можно? Ограничений ведь никаких по-сути!

Согласен. Юзер должен иметь возможность сделать что угодно, это еще Столлман сказал. Ограничения со стороны других бибилтеок, программ - это всегда плохо. Максимум, ограничения должен делать для себя сам пользователя библиотеки, но никак не ее автор.

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

> чтобы обрезать те возможности, которые мало кому нужны

Вот как раз такое делать не нужно. М[asdjh]софт пошел по такому пути, и что в результате? Библиотека должна предоставлять все возможные и доступные ей ресурсы с точки зрения предоставляемой ею абстракции.

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

Юзер должен иметь возможность сделать что угодно, это еще Столлман сказал.

А, этот, который мозолями питается?

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

Библиотека должна предоставлять все возможные и доступные ей ресурсы с точки зрения предоставляемой ею абстракции.

Угу. А то, что в эту абстракцию не вписывается - не предоставлять. Ограничивать.

Ты, собственно, сказал то же, что и я.

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

мигель растолстел. мне не нравится в пыхпыхе его автообъявление переменных. про такую эе ошибку Маконнеелл писал в своем «совершенном коде», только там был visual basic. php, как видно, недалеко ушел.

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

А зачем, собственно, библиотека, если не делать еще один уровень абстракции? Ограничивать то, что туда не входит? Это звучит, как «висит штора. Но в нее же можно сморкаться! Значит надо ее поднять над полом на 2 метра, тогда не смогут.» (навеяно из какой-то песенки)

Вывод: то, что ты сказал, звучит просто глупо.

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

>вообще-то, я тебе сейчас пишу с компьютера iMac в связке с Mac OS X, и, должен тебе сказать, хороша в этом именно связка - ни iMac с виндолинуксами, ни хакинтош такого качества не дают.

клавиши под виндой и линуксом не так жмутся что ли?

ну уберём мы классическое ООП из этой связки, ну, останется неклассическое. Толку-то.

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

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

А там вообще о связывании ничего нет. Посмотри в главе polymorphism.

ну там фигурирует термин virtual methods, который намекает на то, что виртуальность не есть имманентное свойство метода

ЕМНИП, в Ada95 foo(obj, a) может иметь ту же семантику, что и obj->foo(a) в Си++.

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

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

> ну там фигурирует термин virtual methods

Ааа... так ты к терминам решил придраться? Так и сказал бы... я бы тебе напомнил историю термина «virtual».

без виртуальности метод - это всего лишь специфический вид записи функции

Форма записи вообще не имеет значения и к ООП отношения не имеет. Зачем вообще ее упоминать было?

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

«висит штора. Но в нее же можно сморкаться! Значит надо ее поднять над полом на 2 метра, тогда не смогут.»

Вот. А если сделать такую штору, чтобы недорого, глазу приятно, от яркого солнца защищает, но сморкаться не даёт - вот это хорошие, кошерные ограничения. За которые и ратуем.

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

>> Как это? Вы вообще чем занимаетесь?

Видеоигру фигачим.

Вот скажи честно, используете там где-то хаскель, или таки всё на С++?

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

клавиши под виндой и линуксом не так жмутся что ли?

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

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

И что? Ты какой тезис пытаешься доказывать?

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

Ааа... так ты к терминам решил придраться?

вообще-то, нет. если метод в твоём понимании сугубо виртуальный, замени его в моём исходном предложении на переменную-член

Форма записи вообще не имеет значения и к ООП отношения не имеет. Зачем вообще ее упоминать было?

затем, что без виртуальности и, собственно, позднего связывания, переменная-член - это всего лишь форма записи. не более

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

корпоративные традиции основной компании стоящей за хаскеллем.

А в америке негров линчуют.

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

вон, там даже препроцессор советуют для костылей эмуляции состояния.

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

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

там даже препроцессор советуют для костылей эмуляции состояния.

Ни фига, эмуляция состояния - совершенно не в тему.

Кстати, забавно, первый раз в жизни слышу об этом препроцессоре.

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

Вот скажи честно, используете там где-то хаскель, или таки всё на С++?

Э... я, конечно, скажу, но ты сначала скажи, как это относится к той ветке обсуждения, в которую ты влез?

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

>вообще-то для синтаксического подслащивания.

десяток видов массивов - тут и вагон сахара не поможет.

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

десяток видов массивов - тут и вагон сахара не поможет.

Да и не нужен. Этот препроцессор - странный какой-то, я не знаю, кому в голову пришло его изобрести.

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

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

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

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

> как это относится к той ветке обсуждения, в которую ты влез

Элементарно. Ты как обычно поругиваешь ООП, пару раз больно пнул С++, а хаскель, тебя послушать, так просто убер-язык, silver bullet нашего времени. Вот и интересно, применяешь ли ты его на практике и если да, то для каких задач. Или всё же старые добрые уродские плюсы с убогой системой типов и вездесущей ООП-ней, это твой основной инструмент?

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

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

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

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

Ты как обычно поругиваешь ООП

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

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

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

> «висит штора. Но в нее же можно сморкаться! Значит надо ее поднять над полом на 2 метра, тогда не смогут.»

Вот. А если сделать такую штору, чтобы недорого, глазу приятно, от яркого солнца защищает, но сморкаться не даёт - вот это хорошие, кошерные ограничения. За которые и ратуем.

Вот как раз ВОТ ТАКОЕ НИКОМУ НАХЕР НЕ ПРИЕЛОСЬ. Зачем вводить лишние ограничения? Или идеи анально прозондированных рабов мелкософта заполонили лучшие умы ЛОРа?

Сделаем общий вывод. Лишние ограничения - это глупо и просто НЕ НУЖНО.

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

>вон, там даже препроцессор советуют для костылей эмуляции состояния.

Там препроцессор не для того советуют.

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

> «висит штора. Но в нее же можно сморкаться! Значит надо ее поднять над полом на 2 метра, тогда не смогут.»

Вот. А если сделать такую штору, чтобы недорого, глазу приятно, от яркого солнца защищает, но сморкаться не даёт - вот это хорошие, кошерные ограничения. За которые и ратуем.

Вот как раз ВОТ ТАКОЕ НИКОМУ НАХЕР НЕ ПРИЕЛОСЬ. Зачем вводить лишние ограничения? Или идеи анально прозондированных рабов мелкософта заполонили лучшие умы ЛОРа?

Сделаем общий вывод. Лишние ограничения - это глупо и просто НЕ НУЖНО.

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

Вот как раз ВОТ ТАКОЕ НИКОМУ НАХЕР НЕ ПРИЕЛОСЬ. Зачем вводить лишние ограничения?

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

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

И вот он уходит, ты с облегчением плюхаешься в кресло, устремляешь затуманенный взор в окно - А ПРЯМО ПЕРЕД НИМ ВИСИТ БОЛЬШАЯ ЗЕЛЁНАЯ СОПЛЯ!

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

> А если сделать такую штору, чтобы недорого, глазу приятно, от яркого солнца защищает, но сморкаться не даёт - вот это хорошие, кошерные ограничения

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

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

> кушать тоже хочется, жена и два дитёнка, тыры-пыр

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

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

> А ПРЯМО ПЕРЕД НИМ ВИСИТ БОЛЬШАЯ ЗЕЛЁНАЯ СОПЛЯ

Нет, ну правда ведь монада головного мозга у некоторых...

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

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

Наивный ты. Ограничивают по той же причине, почему перила на лестницах стоят и предохранители на ружьях есть.

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

> Или идеи анально прозондированных рабов мелкософта заполонили лучшие умы ЛОРа

Не, мелкософт тут не причём. Mac же у товарища. А это в сочетании с жутко типобезопасным хаскелем - гремучая смесь!

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

Слушай, а может проще не страдать паранойей и не считать клиентов библиотеки идиотами?

А никто и не считает. Просто не нужно им доверять. И себе тоже. Особенно, когда условия, которые нужно соблюсти, становятся более-менее нетривиальны.

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

Ты пробовал, например, реализовать с нуля, ну, хотя бы, AVL-деревья?

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

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

Так что даже от самого себя, причём нынешнего, настоящего, имеет смысл закрыться в некоторых местах.

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

по шутливой просьбе хозяина не пришлось еще эту штору спускать для него с высоты двух метров

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

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

> Ограничивают по той же причине, почему перила на лестницах стоят и предохранители на ружьях есть.

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

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

Через перила ведь наивный юзер и сигануть может.

Не, наивный - не сиганёт.

А какой-нибудь джемсбонд - может и сигануть, если оно ему надо.

В Хаскеле - точно то же самое. В принципе, сигание через перила не одобряется. Но если очень надо - unsafePerformIO тебе в руки, и сигай. Только если убьёшься ап стену, учти, страховкой это не покрывается.

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

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

Ну... обойти можно любую защиту всегда и везде. В частности в память залезть и все поломать. Но определенные гарантии это все же дает.

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

> Но если очень надо - unsafePerformIO тебе в руки, и сигай. Только если убьёшься ап стену, учти, страховкой это не покрывается.

И как это к ООП относится?

Вы со своими аналогиями куда-то совсем далеку ушли.

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

Никак не относится. Тут от темы уже порядочно отошли.

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

Нет, это не дельный срачь. Аналогии - не технарские аргументы.

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

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

Разумный довод, но я не думаю, что ты каждый день занимаешься реализацией AVL-деревьев с нуля. Хотя... фиг тебя знает. Поинт в том, что далеко не все задачи требуют суровой типобезапосности. Даже несуровая статическая типизация порой - overkill, только замедляющий разработку.

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

Поинт в том, что далеко не все задачи требуют суровой типобезапосности

я бы сказал так, что есть два подхода к языку программирования (в совокупности с его рантаймом) - собственно программирование, и использование; первое предполагает создание чего-то персистентного, второе - непосредственное применение программы для решения насущных задач. так вот для первого лично я предпочитаю развитую строгую статическую типизацию (Haskell, параноидальный C++), для второго - как можно более гибкую и слабую динамическую (Tcl). в рамках моего опыта такой подход себя вполне оправдывает

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