LINUX.ORG.RU

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


1

0

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

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

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

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

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

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

★★

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

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

ООП-языки и фреймворки поддерживаются кучей коммерческих организаций. Наверное, поэтому ООП так привычно куче народу.

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

>Вся хвалёная производительность труда частенько вылетает в трубу из-за пары опечаток, которые компилятор отловил бы моментально.
Пример?

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

В лиспе есть докстринги.

У, это называется «перекладывать на человека работу, которую может сделать компьютер». Это и про остальную документацию верно.

Да, а еще охрененно было бы если бы ошибок вообще бы не было.

Понимаешь, мне не светит стать королём Лондиниума и носить блестящую шляпу. Это не повод не хотеть на ужин пирожки.

Я все никак не пойму, почему адепты статической типизации путают динамическую типизацию с отсутствием типизации вообще?

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

Т.е. возражений нет?

Да и не будет, так как уже всем понятно, что не вытеснили и не вытеснят.

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

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

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

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

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

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

В любом случае, мысль понятна: чем больше ограничений, тем большую >надёжность можно обеспечить

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

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

А чем больше возможностей - тем меньше способов наложить ограничения.

Это не так

Это, увы, так. Мировой закон такой. Во всех областях человеческой деятельности проявляющийся.

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

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

> Вся хвалёная производительность труда частенько вылетает в трубу из-за пары опечаток, которые компилятор отловил бы моментально.

Экстремальный пример: http://www.linux.org.ru/forum/web-development/5039501

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

>> В лиспе есть докстринги.

У, это называется «перекладывать на человека работу, которую может сделать компьютер»

интересно, а как Вам тип функции поможет понять, что она делает?

Int -> Char -> [Float]

что эта функция делает? какой смысл имеют её аргументы, результат?

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

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

Ну почему обязательно идиотизм? И почему «ограничения инструмента»? Мысль как раз в том, чтобы ограничения накладывал программист, и такие, чтобы обеспечить надёжную работу своего кода. Идиотизм тут ни при чём, речь просто о разнице в восприятии проблемы.

Ok, запретим давать хирургам скальпель, знаете, чего натворить можно?

Замечательный пример. Как раз тот случай, когда баланс возможностей и ограничений подобран так, чтобы всем было удобно. Кому попало ходить с ножом - запрещено. Хирургу нож положен (да и не только нож, у них, небось, и электропила в руках бывает), но при этом до хирурга ещё надо дорасти, это такая «специальная клетка» для тех случаев, когда нож необходим по работе.

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

Ы? O_o

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

А в статике - пожалуйста, f :: a -> a.

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

что эта функция делает?

Ну, как минимум, она принимает целое и символ и возвращает массив вещественных чисел.

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

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

это ты CL с говнопхп сравниваешь?

Нет, конечно, откуда подобная идиотская мысль?

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

>Главная проблема динамики в том, что писать на ней нормально могут только люди с высокой квалификацией и самодисциплиной.

Ты можешь долго тешить своё ЧСВ, но реалии жизни таковы, что ошибаются все, кто что-ть делает. Рано или поздно все в динамике напарываются на ошибки, которые показал бы компилятор для статиков.

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

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

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

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

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

ООП-языки и фреймворки поддерживаются кучей коммерческих организаций. Наверное, поэтому ООП так привычно куче народу.

Не знаю что тут возникло первее. Но народу нравится ООП и коммерческим организациям нравится ООП. Народ быстро пишет код, а организации быстро получают прибыль. Ну а о тонкостях дела, и о том, что всё это работает и без ООП мало кто задумывается. Как то так?

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

Понятно, что нельзя доказать, что она всегда будет возвращать такое значение, но проверить - как нечего делать.

Ну, я и сказал. Вместо уверенного «да» - хилое «может быть». И то, сразу лезут всякие посторонние штуки, типа «а вдруг я случайно подставлял только аргументы таких типов, у которых есть некая общая черта, и она-то и является ключевой»? В статике сразу видно, a -> a у нас, или, скажем, Eq a => a -> a.

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

всё это работает и без ООП

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

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

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

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

Вот нормальный компилятор динамического языка их и поймает. Но даже со статической типизацией ни один не отловит вызов f(a,b), вместо f(b,a), если типы a и b совпадают.

P.S. Известно, что традиционное статически типизированное ООП бесполезно, поскольку ничего формально не гарантирует. Статическая типизация была придумана исключительно из-за соображений скорости.

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

> Известно, что традиционное статически типизированное ООП бесполезно, поскольку ничего формально не гарантирует

Бгг.

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

Вот нормальный компилятор динамического языка их и поймает.

Это - возможно (и то, максимум ворнингом). Я же говорю - пример совершенно экстремальный.

Но даже со статической типизацией ни один не отловит вызов f(a,b), вместо f(b,a), если типы a и b совпадают.

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

Другое дело, что у них, ИМХО, баланс возможности/ограничения тоже здорово перекошен, на сей раз в сторону ограничений.

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

Блин, второй раз уже нажимаю «поместить», недописав.

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

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

C++ - да, ни фига не гарантирует, но это вообще язык-уродец.

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

> И что же гарантируют сами наследование, инкапсуляция и полиморфизм?

Ы?

III> Известно, что традиционное статически типизированное ООП бесполезно, поскольку ничего формально не гарантирует

Так вот, «традиционное статически типизированное ООП» гарантирует, что у объектов есть методы, которые ты пытаешься вызвать, причем гарантирует это на этапе компиляции. А вот «традиционное динамически типизированное ООП» и правда ничего такого не гарантирует до этапа исполнения. // К.О.

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

>Так вот, «традиционное статически типизированное ООП» гарантирует, что у объектов есть методы

ну, обычные поля у структур. ООП тут не видно.

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

ну, обычные поля у структур. ООП тут не видно.

Вполне видно.

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

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

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

Оба ООП. В одном есть гарантии, в другом нет. Вывод: ты сам себе противоречишь.

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

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

не очень понял, но x.f будет всегда работать, когда в x есть f. на мой взгляд этим множество всех подходящих исчерпано.

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

>> «традиционное статически типизированное ООП» гарантирует, что у объектов есть методы

ну, обычные поля у структур. ООП тут не видно.

Ну, если ты в методах не видишь ООП, то кто ж тебе доктор...

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

Ну, если ты в методах не видишь ООП, то кто ж тебе доктор...

в методах и я ООП не вижу - до тех пор, пока они не виртуальные. или obj.method(arg) чем-то существенным отличаеся от method(obj, arg)?

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

Оба ООП. В одном есть гарантии, в другом нет. Вывод: ты сам себе противоречишь

Нисколько. Просто в джаве статическая типизация на порядок сильнее. Мы же не про ООП вообще, а про статически типизированное ООП?

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

>> Ну, если ты в методах не видишь ООП, то кто ж тебе доктор...

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

А методы бывают невиртуальные? %)

obj.method(arg) чем-то существенным отличаеся от method(obj, arg)?

На каком языке? %)

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

x.f будет всегда работать, когда в x есть f. на мой взгляд этим множество всех подходящих исчерпано.

Да речь не только и не столько об x.f. Речь, скорее, об f(X x) (когда у X имеются наследники). Потому как тогда и f(Y y).

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

>Нисколько.

именно противоречишь.

Просто в джаве статическая типизация на порядок сильнее.

И ООП тоже на порядок сильнее? Если нет - значит и связи с ООП тоже нет.

Мы же не про ООП вообще, а про статически типизированное ООП

вот в каком-нибудь хаскелле очень сильная статическая типизация (что даже нет основных структур данных), а традиционное статически типизированное ООП там есть?

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

А методы бывают невиртуальные? %)

http://en.wikipedia.org/wiki/Method_(computer_science)

тут о вируальности ни слова, например

http://en.wikipedia.org/wiki/Object-oriented_programming#Method

тут тоже

На каком языке? %)

на сферическом в вакууме, поддерживающем структуры с функциями-членами, но не поддерживающем ad-hoc полиморфизм

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

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

щито?

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

И ООП тоже на порядок сильнее? Если нет - значит и связи с ООП тоже нет.

Гм. Не понял. Мы про ООП вообще - или про статически типизированное ООП?

Имеем C++. ООП более-менее (хотя то, что не все методы виртуальные - это жопа, а то, что деструкторы по умолчанию не виртуальные - это жопа в кубе), статическая типизация хреновая. Общий результат - статически типизированное ООП хреноватое.

Имеем жабу. ООП получше, статическая типизация вполне себе ничего. Общий результат - статически типизированное ООП неплохое.

Корреляция, по-моему, явная.

вот в каком-нибудь хаскелле очень сильная статическая типизация (что даже нет основных структур данных), а традиционное статически типизированное ООП там есть?

Ну, Олег сделал в Хаскеле статически типизированное ООП в стиле ОКамла, а традиционное - это его подмножество. Правда, никто не пользуется.

Но речь даже не об этом. Твой тезис был «статически типизированное ООП ничего не гарантирует». При чём тут то, что гарантии можно завести другим способом?

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

что даже нет основных структур данных

щито?

Мнда. Этот кусок фразы у меня вообще в бредофильтре остался, до мозга не дошёл.

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

>Речь, скорее, об f(X x) (когда у X имеются наследники). Потому как тогда и f(Y y).

Зачем наследники и ООП - без них лучше. Достаточно одного интерфейса у объекта (например, все объекты с f типа t), который используется внутри функции. Если что-то измениться в каком-то объекте, то компилятор при статической типизации тоже выдаст ошибку. Это пример, где классическое ООП сливает структурному программированию.

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

>щито?

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

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

>> А методы бывают невиртуальные? %)

http://en.wikipedia.org/wiki/Method_(computer_science)

тут о вируальности ни слова, например

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

In object-oriented programming, a method is a subroutine that is exclusively associated either with a class (in which case it is called a class method or a static method) or with an object (in which case it is an instance method)

на сферическом в вакууме, поддерживающем структуры с функциями-членами, но не поддерживающем ad-hoc полиморфизм

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

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

Достаточно одного интерфейса у объекта (например, все объекты с f типа t), который используется внутри функции.

Да, согласен. Лучше обойтись без наследования, реализацией интерфейсов.

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

Это пример, где классическое ООП сливает структурному программированию.

Нет, извини. Классическое структурное программирование таких конструкций как f<X extends I>(X x) не знает, это в мейнстрим вошло относительно недавно, причём извращённым образом, причём в связке с ООП.

И потом - не уводи разговор в сторону. Ты заявил, что «классическое статически типизированное ООП ничего не гарантирует». Теперь выясняется, что таки гарантирует, хотя те же, или большие, гарантии можно получить иначе. То есть, ты сказал фигню.

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

> возьми тот же ассемблер, типа как манхунт предлагал

Не приписывай мне свои бредовые идеи, пожалуйста.

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

>f<X extends I>(X x)

речь вообще не об этом.

выясняется, что таки гарантирует

пока нет. никаких особых гарантий от наследования, инкапсуляции и полиморфизма не продемонстрировано, которых бы не было без них.

То есть, ты сказал фигню.

не уводи разговор в сторону.

причём в связке с ООП.

вот в магазине компьютер в связке с виндой.

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

>То, что даже в Haskell98 есть массивы - видимо, для тебя сюрприз.

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

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

> Я ж не виноват, что ты сам не понял, что сказал.

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

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

никаких особых гарантий от наследования, инкапсуляции и полиморфизма не продемонстрировано, которых бы не было без них.

Так. Ещё раз. Гарантии от наследования, инкапсуляции и полиморфизма - это гарантии от ООП просто. Нас интересуют гарантии от статически типизированного ООП.

не уводи разговор в сторону.

Я, как раз, пытаюсь его вернуть на рельсы.

вот в магазине компьютер в связке с виндой.

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

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

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