Зачем нужно ООП

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

Ссылку можно?

что на чистом ФП можно проектировать схемы

Цитату, пожалуйста.

открой хоть 3-ю главу SICP и посмотри как это делается с полусумматором

Ну так вот тебе и модель твоей релешки, на вход единица или ноль, на выход - кортеж.

По-другому ты ее не смоделируешь, не имея данных об импедансах.

http://btdigg.org/search?info_hash=&q=цепи и сигналы

Можно.

Зачем нужно ООП

Бог создал людей, а кольт дал им равные права.
ООП примерно для того же.

Цитату, пожалуйста.

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

По-другому ты ее не смоделируешь

Так что ж ты тогда весь тред голову людям морочишь, что ее можно спроектировать в ФП?

Поверь мне, юзернейм, графический фреймворк без oop не хочешь ты. А у меня есть их.

AssignValue(circle);
    SetColor(Color.CornFlowerBlue);

...

AddGridDisplay(
    name => 'asdf',
    foo  => bar,
    ...
);
AppendExecProcedure(ProcedureName);
    AppendParameterName(SomeParam1);
    AppendParameterName(SomeParam2);

Блеванул? И так каждый день 5 дней в неделю.

Я уже понял, что чукча не читатель, либо никогда не проектировалцепи.

Так что ж ты тогда весь тред голову людям морочишь, что ее можно спроектировать в ФП?

Спроектировать что-либо нельзя в языке.

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

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

https://ru.wikipedia.org/wiki/Язык_описания_аппаратуры

Всегда узнаешь что-то новое, да?))

И чем тебе моя модель релешки не понравилась, я так и не понял.

Ты и что такое модель не знаешь, да?

короче, я понял, ты нулевой. знал бы сразу, не ввязался бы.

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

строить системы такие, какие ты видишь IRL.

на виденье_восприятие влияет предистория смотрящего ,

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

субъект не только и не столько субъективен(не без этого)

но есть https://ru.wikipedia.org/wiki/Субъект читай актор.

в отличии от объекта который покоится и воспринимает совершаемое над ним.

агрегирование.

был такой CLU не ооп но оп так.

это вредители стали абстрагировать вызов в сообщение.

по чистому

сообщение это набор бит приходящий актору. актор диспатчит сообщение , меняет(возможно) своё состояние и также делает 0 и более сообщений.

не соглашусь, ибо культурное шаблонство даёт обобщённое программирование, на макросах это всёж ещё страшнее.

можно просто вот 98 страниц

Дал У.И. Симула 67.Универсальный язык программирования 1969

познавательно как это стало с++

Была ли жООПа до страусиного трупа?

на виденье_восприятие влияет предистория смотрящего ,

Если видишь функции, то наверное ФП для тебя будет привычнее. Но к доктору всё же обратись :3

жООПщикам надо к дохтуру обращаться.

И всяким идиотам, которые исповедуют С♯, жабку, пхытон и прочую порнуху.

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

мысль о хипе и змеином масле

и натягивании на глобус ставшего популярным термина

в процессе натягивания семантика изменилась на прямо противоположное .

На самом деле, оба термина, в принципе подходят. Тут нет противоречия. Любой объект есть так же и субъект, все зависит от того, как мы на него смотрим. Тот же актор, это либо объект — получатель сообщения — тут мы смотррим на него как на пассивный элемент, так и субъект — активный элемент, который отправляет сообщения. Я же говорю, все зависит от точки зрения. Акторы, в этом смысле, ничем не отличаются от объектов в ООП. Собственно, толчком для возникновения теории акторов стало ООП.

наоборот

теория акторов появилась раньше чем поднялся хип с ООП

Кстати, SystemVerilog вполне настоящий ООП язык.

теория акторов появилась раньше чем поднялся хип с ООП

Карл Хьюитт, Питер Бишоп, Ричард Штайгер: Универсальный модульный формализм акторов для искусственного интеллекта. IJCAI, 1973 (англ.)

Первая реализация смолтока, емнип, 71, симула — где-то 67, примерно.

ооп ставшее тем чем оно известно(две колесницы большая и малая) это

ObjectiveC vs C++

первое семейство это С внизу и Smalltalk80 наверку

второе семейство это С внизу и Simula-67 наверху.

(в огрублении конечно)

в чистом виде ооп позже акторов, генезис взаимозависимый.

изолированность, компонентность и повторное использование кода...эти три вещи ООП по идее должно было дать. К сожалению, не дало.

программирование как вид деятельности не масштабируется

А как написаны на С++ с использованием ООП такие сложные проекты как KDE? И разве ООП не основа для всяких там Windows 7 и прочих магапроектов галактического масштаба? Что-то твои утверждения расходятся с реальностью.

в его реальности это все «не нужно» и не является примерами.

Это удобнее в параллельной разработке. И в расширении функциональности, если все грамотно спроектировано.

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

ООП - зло и не нужно, конкретно инкапсуляция и наследование - страшное зло

Варьируемое поведение (write файла, специального файла и сокета) не нужно, защита данных (private members) не нужна, reuse кода с уже отлаженным поведением (сортировки, поиск) не нужен, абстрации не нужны, нужна лапша и велосипеды - больше лапши и велосипедов!!! Я правильно тебя понял?

Варьируемое поведение (write файла, специального файла и сокета) не нужно

ad-hoc полиморфизм

защита данных (private members) не нужна

А зачем она нужна? И почему такая узкая форма, а не инкапсуляция?

reuse кода с уже отлаженным поведением (сортировки, поиск) не нужен

сортировки, поиск

ООП? Да ты упоролся!

абстрации не нужны

Действительно, абстракций без ООП не бывает.

Вот что действительно не нужно — защищать ООП совершенно ничего в нем не смысля.

И разве ООП не основа для всяких там Windows 7 и прочих магапроектов галактического масштаба?

Сейчас тебя начнут убеждать, что вот ядро линукса написано без ООП :-)

ЕМНИП, ведро линукса таки с ООП.

В рамках ФП можно (и нужно) смоделировать любой подход, главное что бы top-level это была функция с ссылочной прозрачностью. А внутри заводи что угодно, хоть в монаде императивщину моделируй, хотя реактивщину. Реактивщина, кстати, одна из самых популярных моделируемых штук в ФП.

При таком подходе, о котором ты говоришь, от «функционального» подхода, там остается только название.

сортировки, поиск

ООП? Да ты упоролся!

Да ну? Ты сдаешь в сортировку контейнер, ты отдаешь в сортировку компаратор. И если второе может быть функцией, то первое - объект, со свойствами (размером) и методами/операциями - типа «обменять i'й и j'й элемент местами», «взять подмножество» и т.п. Аналогично с тем же поиском - на входе контейнер/итератор и компаратор (возможно и контейнер-приемник), на выходе - объект или множество объектов.

защита данных (private members) не нужна

А зачем она нужна?

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

ЕМНИП, ведро линукса таки с ООП.

Это все понимают, кроме истеричныхх ООП-хейтеров, ведь для последних единственный признак ООП это наличие слова «class».

Сейчас тебя начнут убеждать, что вот ядро линукса написано без ООП :-)

Да и там тоже ООП, насколько это возможно на Си конечно.

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

Но при этом все основные реализации ООП позволяют эту инкапсуляцию нарушить. В C++ прямой доступ к памяти (или приведение типа), в Java — через интроспекцию, про питон и js вообще молчу. К чему бы это? Или они не ООП? (инкапсуляции ведь нет...)

Но при этом все основные реализации ООП позволяют эту инкапсуляцию нарушить.

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

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

И как и в аналогии, обычно оно впоследствии приводит к «чернобылю» в проекте, поскольку изначально private как раз и играл роль тех самых предохранителей и защиты (как и строгая типизация). На чем угодно можно написать

class ClassA {
    void do(ClassA b) {}
}
class ClassB {
    void do(ClassA ) {  a.do( (ClassA) ((Object)this) ); }
}

защита данных (private members) не нужна

const

reuse кода с уже отлаженным поведением (сортировки, поиск) не нужен

напиши функцию - будет reuse кода с уже отлаженным поведением

Варьируемое поведение (write файла, специального файла и сокета)

это как связано с ооп?

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

«сообщение» — это просто вызов метода объекта.

И неправильно понял. Так только в популярных ООП ЯП.

Но при этом все основные реализации ООП позволяют эту инкапсуляцию нарушить.

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

const

const не защищает данные, он делает их просто неизменяемыми. Что здесь общего?

Смысл инкапсуляции (и ооп) в том, чтобы гарантировать зависимость корректности крупной системы от корректности маленького интерфейса. Вместо того, чтобы проверять всю систему - проверяем реализацию интерфейса, и если интерфейс корректен, то вся система становится корректной _автоматически_, просто потому что написать некорректную систему при помощи заданного интерфейса тупо нельзя.

Далёк я буду от правды если скажу

Очень далек.

draw(circle) и draw(rectange) в одной программе

Если это разные функции, то это будет уже ООП. Суть которого не в синтаксисе.

Если это одна функция, то тебе придётся внутри неё совать анализ типа аргумента, что и не позволит просто расширять её, и производительность снизит. Считай, что ООП — просто синтаксический сахар для такого подхода, позволяющий оптимизировать разработку и исполнение.

Так ты же и нарушаешь. Инструмент всего лишь это. Не нянька.