нет конечно

и как может быть ФП против ООП

это вообще ортогональные вещи

Задачи решают функции, а не объекты

OOP was good back in the days, and it still has its uses today, but now everyone is realising modifying states is equivalent to kicking babies, so now everyone is moving to immutable objects and functional programming

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

тому що всё фп оно о какой-нибудь композиции функций, трансдьюсеров, монад, функторов и т.д.

альтернатива для ФП это императивное программирование

их можно сравнивать

ООП это о представлении данных и связанных с ними функциях

тогда уж правильнее будет декларативное vs императивное, не?

ООП сочетается как с ФП, так и с иммутабельностью

альтернатива для ФП это императивное программирование

так одного в другое уже намешали

@KolesnichenkoDS согласен

См. скала?))0)

ООП это о представлении данных и связанных с ними функциях

вот а можно об этом поподробнее? а то я уже столько разных определений ООП встречал, совершенно разных интересно ещё одно мнение выслушать

вы же знаете про featherweight java?

эта милота у Пирса в книжке есть

начинается с лямбда-инсчисления

вот а можно об этом поподробнее? а то я уже столько разных определений ООП встречал, совершенно разных интересно ещё одно мнение выслушать

потому что если инкапсуляция, наследование, полиморфизм, то если допустить что под наследованием можно понимать наследование поведения, а не реализации, то Haskell очень даже ОО-язык

классическое mainstream определение это про то, что система работы с данными где данные образуют иерархию со свойствами инкампуляция, наследование, subtype полиморфизм 😏

и на каком-то моменте реализуется маленькая джава

впрочем последние 2 можно объединить в 1 =)

вот а можно об этом поподробнее? а то я уже столько разных определений ООП встречал, совершенно разных интересно ещё одно мнение выслушать

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

это про Алана Кея, альтернативный вариант

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

это определение ещё из 60х =)

ООП сочетается как с ФП, так и с иммутабельностью

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

ООП по Клею это про pi

ООП в меинстриме ничего про calculus нижележащий не говорит

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

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

"А расскажите своими словами, что такое полиморфизм" - "Я конечно могу рассказать, но честно говоря за те пять лет, что я работаю программистом, я еще ни разу не сталкивался с необходимостью пользоваться полиморфизмом." - ".... наверно на этом нам стоит прекратить собеседование. До свидания."

хотя сейчас, еще через 6 лет, я могу сказать, что таки да, кое-где мне полиморфизм тогда все-таки попадался, просто я его не узнал

полиморфизм это когда один метод может работать с данными разного типа

т.е. написал один раз и потом применяешь к разному не меняя код

хм.. не совсем точно, но ладно

Точнее, когда разные данные подходят для одного метода

и его полиморфизма много видов

Если просто с разными типами работает метод, то это перегрузка

параметрический - когда в одну функцию можно пихать разные данные

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

subtype - когда метод может работать со вмести подтипами (наследниками) данного типа

dynamic - то что в динамических языках, и там несколько подклассов

можно открыть книжку пирса и посмотреть, там доступно

parametric это то что в меинстриме называют Generic

Вон в смолтолке нет перегрузки по типам. Просто те объекты, которые принимают некое сообщение - "утки"

это вообще ортогональные вещи

а скала как то объединила в себе все это) (но скорее всего это уже обсудили)

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

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

Где тут полиморфизм?

что не важно, что за драйвер, у него есть open, read, write, close и ioctl

Полиморфизм, это возможность взять некий признак (поведение), присущий разным объектам и сгруппировать эти разные объекты по данному принзаку: "плавают и лодки и рыбы - плавание полиморфно"

а скала как то объединила в себе все это) (но скорее всего это уже обсудили)

если я правильно понял, ортогонально в том плане, что не противоречат друг другу и нет причин не использовать ооп в фп

что не важно, что за драйвер, у него есть open, read, write, close и ioctl

вот это уже похоже

если я правильно понял, ортогонально в том плане, что не противоречат друг другу и нет причин не использовать ооп в фп

именно. Объекты можно поиметь и в ФП

Но как подход, а не конкретику типа "состояние+поведение и классы в придачу"

соответственно все character device drivers с точки зрения операционки выглядят одинаково

вопросик если койонеда дает бесплатный функтор, то что делает йонеда?

соответственно все character device drivers с точки зрения операционки выглядят одинаково

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

чморить объектно-ориентированных

Звучит как заднеприводных

Не, "заднеприводных", это не в этот чятик, это к Платову

Объекты - это замыкания для бедных. Поэтому ООП есть и в Схеме и даже у меня в языке.

А искаропки они в Скале и Фшарпе из-за платформ реализации и интеропом с жвм и нетом

а скала как то объединила в себе все это) (но скорее всего это уже обсудили)

как-то = весьма криво?

Скала согласно одерскому- ООП язык

"С элементами"

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

А можно ли назвать тип допустим data Person = Person String Person "Lisa Hacker" , объектом типа Person?

иммутабельный дто ака структура

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

мож я чего не понимаю, но в скала-мире дофига объектов с конструктором, состоянием и методами

Что в общем-то слабо напоминает чистую функциональщину с функциями, которые группируются в модули

мож я чего не понимаю, но в скала-мире дофига объектов с конструктором, состоянием и методами

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

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

Ну я скорее к тому, что аналогия с указателями не совсем корректная

аналогия не про указатели, а про вынужденную поддержку платформы - что нет в фшарпе, что жвм в скале, что сишные примитивы в плюсах

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

аналогия не про указатели, а про вынужденную поддержку платформы - что нет в фшарпе, что жвм в скале, что сишные примитивы в плюсах

подцепить готовую инфраструктуру - это практическая целесообразность, чтобы язык не пропал в тоннах других языков

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

кстати, именно поэтому я в свое время начав с Фшарпа все равно смотрел на сабж - потому что он в этом смысле горд и не идет на подобные компромиссы )))