Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

Qraizer, а ты знаешь, что такое ООП?

Я достаточно далёк от ООП, но хотелось бы и какого-то такого:

А может даже:

Добавлено 19.05.19, 03:51
И ещё:

но хотелось бы и какого-то такого:

Я достаточно далёк от ООП, но хотелось бы и какого-то такого:

Никто не знает что такое ООП

Знаю, D_KEY.

В С++17 ввели std::optional ... Де жа вю! Из Раста скомуниздили штоле?

Для кого-то эрланг вполне себе ООП, а для кого-то и плюсы не ООП.

Все что вы описали есть в Ruby.

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

Что это такое, вполне себе чётко описано в определении

В каком?

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

К примеру, на C

Хочешь, чтобы я процитировал классиков?

In the article Is Software Engineering an Oxymoron?, Kay writes: "Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects." While this doesn't necessarily constrain the definition of OO in his mind, it is a key statement of philosophy. C++, of course, does early binding everywhere it can--up to the point of performing StaticDispatch as a default (you have to ask for DynamicDispatch with the "virtual" keyword when you want it. [and even that, as in many other languages like Java, is only single dynamic dispatch. If you want "late binding everywhere," you need a much more powerful dispatch system, e.g. CommonLispObjectSystem's generics]).

Из раста вообще пока никто ничего еще не комуниздил. Рано.

Хочешь, чтобы я процитировал классиков?

If you want "late binding everywhere," you need a much more powerful dispatch system, e.g. CommonLispObjectSystem's generics

Flex Ferrum, а ООП тут при чем?

а ты как определяешь ООП?

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

Добавлено 20.05.19, 10:39
Популярная сейчас микросервисная архитектура - это то же ООП, вид в профиль.

Задам хитрый вопрос - исходя из того, что ты сказал, что будет НЕ являться ООП?

Как подход к проектированию и декомпозиции программных систем.

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

Задам хитрый вопрос - исходя из того, что ты сказал, что будет НЕ являться ООП?

подход к проектированию и декомпозиции программных систем.

А акторы?

который заключается в ...
В чем?

Object-oriented software construction is the building of software systems as
structured collections of possibly partial abstract data type implementations.

То, что дизайнится без применения ОО-подхода. Очевидно же!

Смоллтоковская парадигма же. Общая шина, сообщения, которыми обмениваются объекты. Ну!

Это понятно. Но я б ответ без троллинга оценил

Object-oriented software construction is the building of software systems as
structured collections of possibly partial abstract data type implementations.

А можно пример не ОО-системы?

Ну, без если троллинга - то ООП не будет являться то, что не соответствует этому определению:

А я таких сходу не назову. Да и не с ходу тоже.

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

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

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

Так я и хочу услышать, что ему не соответствует - на практике.

А процедурная обычно вполне себе

Аналогично с чистой функциональщиной - ты дизайнишь "от фукнции" (желательно - кристально чистой ).

Лично для меня ООП начинается тогда, когда дизайн системы - это граф взаимодействия абстрактных объектов посредством интерфейсов

И чо делать?

Потому что ты идёшь от алгоритма (каким бы сложным он ни был). Начинаешь с main и спускаешься к деталям реализации конкретных процедур.

Но алгоритм-то работает с данными.

Не каждая работа с данными попадает под концепцию ОО-парадигмы.

Так какая попадает, а какая нет?

Это ОО код или процедурный?

Вроде бы речь шла о дизайне.

Что нужно для того, чтоб наш дизайн был ОО?

Абстракция для "настроек", абстракция для "клиентского ввода", абстракция для "хранилищ данных", абстракция для "персистентное хранилище". В процедурной декомпозиции будет иначе: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск".

Мне кажется, что код при этом будет практически одинаковый.

На практике, скажем, какая-нибудь система управления гидронасосом не будет ОО ни разу

Возможно. А возможно и нет.

А в ОО-системе не нужно будет делать это: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск"?

А что скажешь по поводу ядра Люникса?

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

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

На практике для разных аспектов системы я применяю разные подходы в плане дизайна. Как-то так.

На практике для разных аспектов системы я применяю разные подходы в плане дизайна. Как-то так.

Ты когда абстракции придумываешь, об операциях, которые они будут осуществлять(или над ними будут), обдумываешь?

Да.

Но я размышляю над этим в терминах контрактов, активно применяя SOLID.

И что это меняет?

Точку и угол зрения. При таком взгляде на дизайн возникают интересные констрейнты типа "принцип минимальных привилегий", "один класс - одна задача", "ответственность класса" и т. п.

Эти же вещи возникают при любом другом дизайне.

И короче понял что всего надо в меру. Особенно эта проблема выражена у программистов C#/Java.

Пока звучит как словоблудие Или вера.

Пока звучит как словоблудие Или вера.

чтоб сделать идеальную ООП систему

Вообще то это целая уже научная отрасль.

У тебя пункт на "вере", обрати внимание.

Нда? Можешь показать, какое они будут иметь отражение при процедурном дизайне? А при функциональном?

Пока ты не показал разницу между ОО и процедурным

Потом когда SOLID начал более детально курить

Только это все не приблежает нас к пониманию термина ООП.

чтоб сделать идеальную ООП систему

Ты её не увидел (не захотел увидеть?).

Точку и угол зрения.

Тебя. *Fixed.

А как тут можно понять? Ты ничего конкретного не сказал:

Нужны соответствующие абстракции. Абстракция для "настроек", абстракция для "клиентского ввода", абстракция для "хранилищ данных", абстракция для "персистентное хранилище". В процедурной декомпозиции будет иначе: "Прочитали файл с настройками, получили клиентский ввод, проанализировали, определили тип создаваемой структуры, записали туда данные и выгрузили на диск". В функциональной... Похоже, без в функциональной монад не обойтись.

И сразу пошел в сторону SOLID.

Формален/не формален - это фигня.

Расскажи, как применяются принципы SOLID при процедурном подходе.

А какая разница между ОО и процедурным?

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

В процедурном стиле я сначала придумываю алгоритм, а потом подбираю нужные данные под него.

Где ты такое видел вообще?

В разбиении программы на подпрограммы в рамках императивного подхода.

Где ты такое видел вообще?

Вот. Алгоритмическая декомпозиция. Про которую я и говорю. Тогда в чём вопрос?

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

Именно это отсюда и следует.

Алгоритмическая декомпозиция против объектной. Вроде азы же!

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

Wound, речь про то, что такое ООП. Это все хорошо, что ты пишешь. Но не дает определение.

Определение можешь посмотреть на вики. Чем оно тебя не устраивает?

Сможешь посмотреть на систему и сказать, ОО она или нет? А другие "эксперты" согласятся с тобой?

Если она удовлетворяет основным принципам ООП

А другие "эксперты" согласятся с тобой?

Разные люди разные принципы выделяют. И все эти принципы расплывчаты. Кто-то скажет, что система им удовлетворяет, а кто-то скажет, что нет.

А что есть какой то другой способ определить ОО эта система или нет?

Приводи примеры.

Как?

Так я про это и говорю. Нет нормального способа.

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

Пример систем. Хм. Ну вот скажи, STL - это ООП или нет?

Ну вот скажи, STL - это ООП или нет?

Сможешь посмотреть на систему и сказать, ОО она или нет? А другие "эксперты" согласятся с тобой?

Flex, к тебе те же вопросы

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

У тебя, скажем, есть абстракция "конфигурация", у которой интерфейс иерархического хранилища.

Есть фабрика, которая создаёт экземпляр этой абстракции.

на выходе - интерфейс.

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

Скажи, ты опять не понял разницу между ОО- и процелурным подходом?

Это все одно и то же, просто сказано либо очень абстрактно либо конкретизировано.

Нет.

Мне ее еще надо придумать. Это происходит от того, что нужно сделать. В разных системах абстракции для "конфигурации" будут разными.
Исходя из чего придумывается интерфейсы абстракций?

Так это и есть алгоритм шаг за шагом.

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

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

Нет, это не одно и то же. И именно поэтому Алан Кей отказывал C++ в праве называться ОО-языком. Это его частное мнение. Определения-то четкого нет. Я уже не говорю формальное.

А что это?

И что? От этого там не будет "процедур"? И что мешало в процедурном подходе так же декомпозировать

Так а с чего ты взял, что до ООП люди все строили от алгоритмического представления?

D_KEY, если я (очередной раз) назову <stdio.h> имеющим объектную архитектуру, тебя это устроит?

И будешь прав.

Эм... Вроде такова история индустрии.

D_KEY, если я (очередной раз) назову <stdio.h> имеющим объектную архитектуру, тебя это устроит?

Так замечательно. Осталось сформулировать четкие критерии

Ну а причем тут его частное мнение к общепризнанному мнению?

Вот тут важный момент. Почему ты пишешь не "я тоже так считаю", а "будешь прав", как будто есть четкие критерии?

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

Что за общепризнанное мнение? Кто статистику подводил?

Так ты ее и привел, указав только одного ученого.

Потому что есть абстрактный тип данных (FILE) и набор операций с ним (интерфейс).

Считается, что это он придумал термин ООП.

Это все одно и то же, просто сказано либо очень абстрактно либо конкретизировано. В вики например описывают 4 основных принципа "абстрагирование, инкапсуляция, наследование, полиморфизм".
В более ранних интерпетациях выделяли три последних принципа. Это все логично, ибо все развивается, потом появились конкретные методики, которые еще больше конкретизируют эти принципы своими принципами(тот же SOLID), со временем возможно еще что то добавится. Так вот к чему это все, а к тому что технологии развиваются, и конкретизируются определения различных систем и парадигм. Что то конкретизируется, что то отсеивается и т.д. На сегодняшний день можешь измерять ООпшность системы путем применения этих 4 принципов. Раньше возможно хватало 3 принципов, а еще раньше возможно хватало принципа "все есть объекты, которые обмениваются между собой сообщениями".

Вон даже планет в солнечной системе стало меньше, за последние 10 лет, а ты тут про какую то расплывчатость формулировок.

Вообще да, если начать философствовать, то конечно ОО систему можно наковырять(разглядеть) и в сишной функции записи write(FILE*,...). Но какое это имеет отношение к реальным системам?

Я это к тому, что тот, кто этот самый <stdio.h> придумывал, вообще ничего не думал об ООП.

Ровно то же самое и с ООП. Вот тогда в бородатом 85ом или когда там, было одно определение, а сегодня оно уже немного модернизировалось и стало таким, как есть. Это диктуют современные реалии. Иначе система отомрет, ей нужно изменяться и подстраиваться. И со временем возможно она еще чем то пополнится, либо лишьнее уйдет. Этого уже будут требовать будущии реалии.

Так вот так люди мыслили при проектировании систем и до моды на ООП.

D_KEY, ты же отдаёшь себе отчёт, что споришь с представлением об ООП

Не все и не всегда.

ООП – это лишь набор спецификаций для проектирования систем.

Все что есть, это некий набор практик(довольно хороших)

Я не спорю с представлением об ООП.

А отсылать к Бочу или Мейеру - зачем?

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

И статьи очередного неосилятора на хабре.

В таком случае процедурного

функционального

аспектного

Разбиение программы на процедуры.

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

Представление процесса вычисления в виде вычисления функций в математическом смысле. Хорошо формализовано.

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

Ну так ООП - это про дизайн, а не про императивщину/функциональщину.

разделение проходит

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

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

А что такое вообще "математический смысл"? Дай определение, будь ласка

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

На самом деле, не ясно, чем тебе тогда да хотя бы Кеевское определение ООП не устраивает.

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

Поэтому и вопрос D_KEY'я (про кусок кода) немного, гм, странен.

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

Расскажи, как применяются принципы SOLID при процедурном подходе.

хоть квадратно-гнездово на CSS...

Слово "смысл" там встречается четырежды, и ни разы не в твоем новоявленном "математическом смысле". Так что же это такое?

Чего? Я тебе дал ссылку на определение функции в математике. Это и есть "функция в математическом смысле".

Чего? Я тебе дал ссылку на определение функции в математике. Это и есть "функция в математическом смысле".

Когда тебе дают определение на ООП в программировании, тебя это не устраивает почему то

Ты говорил про програмирование "в математическом смысле"

хоть квадратно-гнездово на CSS...

Молчи! *** Даже не вздумай повторять!

Озвучивал. Здесь: ООП - в топку! (сообщение #3799452)

Прекрасное определение.

Object-oriented software construction is the building of software systems as
structured collections of possibly partial abstract data type implementations.

Нет, я говорил про функции в математическом смысле. Возможно, коряво выразился.

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

Цитата
функционального

Представление процесса вычисления в виде вычисления функций в математическом смысле. Хорошо формализовано.

А вот после этого восклицания мне даже интересно стало, о чём речь идёт

Я тебе напомню, что именно ты говорил:
...

Т.е. "в математическом смысле" относится к функциям.

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

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

Т.е. если в системе, возможно есть (а возможно и нет?) АТД — это ООП?

И почему, вдруг, структурированная коллекция. В сферическом ООП каждый объект живёт своей жизнью, какая тут структурированность? Или тут имеется в виду инкапсуляция (мол объекты взаимодействуют друг с другом только через интерфейсы)? Чем это тогда отличается от модульности?

Смотри, какая наркомания https://habr.com/ru/post/267701/

Я не понимаю тебя.

Какие-то новые странные вопросы

рожаешь в связи с ним некий "математический смысл"

И я объяснил почему

Кроме того, вон у Флекса другое определение

Я просто пояснил, что термин "функция" берется из математики. Все.

Я просто пояснил, что термин "функция" берется из математики. Все.

Скажи, а если я напишу в коде:

- это будет функциональным программированием?

А если ты еще навесишь листенер на вызов функции, то вообще оно станет событийным

Правда? А ещё вот так вот можно:

Ай-ай-ай, как не чисто! Что ж ты, гад, побочный эффект подсовываешь?

Определение нужно для того, чтобы описать границы термина. В данном случае ООП

Уверен, тот, кто тебя спрашивал, что такое функция, остался твоим ответом доволен.

это будет функциональным программированием?

Это это, как её... Ну... Это, слово страшное... Манд... Монд... Во! Монада!

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

если бы спрашивал об этом.

Может хоть ты объяснишь что это такое?

Так о чем же ты спрашивал тогда?

Вообще забавно наблюдать, как в подобных спорах говорят о проектировании систем, а потом приводят строчку кода, и начинают рассуждать ООП это, или функциональщина При этом если-таки посмотреть на более-менее большую систему, то можно заметить, что в коде на java, в котором никуда не сбежать ни от классов, ни от интерфейсов, ни от наследования с полиморфизмом, тут и там встречается вполне себе функциональщина, типа стримов с лямбдами, или монад из vavr'а, а чуть в стороне, благодаря Spring, тут и там раскиданы bean post processor'ы, которые вполне себе аспекты, а то и вообще AspectJ найти можно. А если по соседству болтается что-нибудь типа кролика, а в коде висит листенер на очередь, то можно начинать рассматривать происходящее, как событийно ориентированную систему. И все это - один и тот же код

Обсуждали уже. Можно вот тут посмотреть.

Что такое "в математическом смысле" относительно функционального подхода. Дай, пожалуйста, четкое определение.

Кстати, а что такое "do-нотация"?

Согласен. Надо же.

Еще раз. "В математическом смысле" относилось к "функциям". Т.е. эта часть фразы означает лишь то, что под "функцией" понимается то же, что в математике.

Это синтаксический сахар для цепочки.

Тогда с чем ты споришь?

в том моем говнокоде на плюсах

Нет.

Структурированный - это, очевидно, имеющий некую внутренню структуру, взаимосвязи.

С наличием четкого и вменяемого определения ООП.

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

С наличием четкого и вменяемого определения ООП.

Но это же и означает, что четкого определения нет.

Набор практик.

Но некоторые вот считают, что знают истину.

Но C++ ничего подобного не позволяет сделать, насколько я понимаю.

Не понял...

Не понял...

Нужно перегрузить оператор ';'(если бы он был).

По-твоему что, есть разница между Плюсовым a=b и Паскальным a:=b, что ли?

D_KEY, зачем это всё?

Что не так?

Объясни Астарот-у, почему это важно.

По-твоему что, есть разница между Плюсовым a=b и Паскальным a:=b, что ли?

И насколько точно, на твой взгляд, эти границы определяет то определение, что ты привел?

Добавлено 21.05.19, 13:00

Пока это просто определение функции.

то как (по твоему мнению) две приведённые тобою строчки кода могут относиться к ООП?

Так в той же цитате написано, что да.


Как это всё относится к ООП? Если программа не в ООП-стиле, то она априори не сруктурирована?

Данное определение даёт понять, с чем именно и как оперирует ОО- парадигма.

Я и не утверждал, что они относятся.

А дает ли оно понять, является ли некая система ОО?

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

Если нет, то в чём был смысл вопроса?

Да.

Но может лучше тратить время более конструктивно?

А чё сразу я?!

Нет. Тут суть в том, что ты уходишь от разрушающего присваивания и передаешь значение по цепочке следующей функции.

Для монад. Сходи по ссылке, если время есть. Я там для иллюстрации накидал реализацию монад на крестах.

А его там и не было.

D_KEY, если ты действительно хочешь объяснить кому-либо что-либо, делай это правильно, и не намёками.

Объяснять разницу между монадами и лямбдами на примерах

Я еще тогда прочитал, но что такое монада - так и не понял Кстати, а что такое "do-нотация"? А то который раз слышу, но определения не знаю

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

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

любые попытки притащить монады в императивные языки.

Дело в том, что в "настоящих" функциональных языках вроде х-я нет встроенной возможности вызывать функции последовательно друг за другом. Так как тотально отсутствуют языковые конструкции вроде циклов, блоков и т.п. А в реальной жизни время имеет очень важную роль, а последовательность операций следующих друг за другом во времени, мягко говоря, обычнейшее дело. В х-е же есть только вызовы функций которые могут вызывать другие функции, полиморфизм, паттерн-матчинг и прочие list comprehensions. Это еще усугублено тотальной ленивостью: пока результат не нужен функция выполняться не будет. Тогда ФП-фаги придумали костыль (они это считают наоборот величайшим благом) - do-нотацию, которая представляет из себя языковую конструкцию оборачивающую все говно в монаду и позволяющую таки просто тупо написать список операций и они, о бозе!, будут выполнены в том порядке в котором написаны в исходном коде.
Механизм примитивен: функция, результат которой является аргументом другой функции физически должна быть вычислена раньше, чем эта самая другая функция. Вот do-нотация и превращает список операций в кучу функций, результаты которых являются аргументами других функций, результаты которых являются аргументами других функций... Все это является одним из видов монад.

Любой нормальный язык дает возможность все это сделать без специальных do-нотаций. В сиобразных языках достаточно поставить точку с запятой, вот тебе и последовательность операций. Так сказать, неявная do-нотация.
В этом плане erlang представляет из себя некий компромисс: это иммутабельный ФЯ с возможностью писать грязные функции и написанные друг за другом вызовы функций будут вызваны именно в том порядке в котором они написаны, такая же неявная do-нотация.

Именно поэтому меня веселят любые попытки притащить монады в императивные языки.

А разве есть такие попытки?

Доходчиво!

Монады Try и Either в ту же жабу вполне себе притащили, и ничего, удобненько.

Скорее притащили типы.

Они там вроде и без того были

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

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

Именно поэтому меня веселят любые попытки притащить монады в императивные языки.

Я так и не понял, на кой хрен кому-либо может пригодиться в Плюсовом коде переделать Плюсовый синтаксис в Хаскельный.

Именно поэтому меня веселят любые попытки притащить монады в императивные языки.

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

Эрланг (а для меня лично эликсир)

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

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

Если речь идет, к примеру, о программировании какой-либо логической матрицы с 256 выходами и 1024 состояниями

Выглядит, как те же яйца, просто в профиль.

А киллер-фича какая-нибудь есть?

Хаскель это просто и понятно, говорили они

А что тут сложного? =)

Т.е. можно считать, что эндофунктор — это такой контейнерный тип, у которого есть операция map, применяющаяся к содержимому контейнера некоторую операцию, но сохраняющая сам контейнер.

Какая киллер-фича у интерфейса Collection? Или у интерфейса Iterable?

Я спрашивал про киллер-фичу Эликсира против Эрланга.

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

Моноид — это тройка:
– множество
– бинарная ассоциативная операция над элементами этого множества и возвращающая в качестве результата элемент этого же множества
– нейтральный элемент по отношению к это операции

Но ещё более непонятно, каким боком к ним ООП.

JoeUser, а ты как определяешь ООП?

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

Некое недалекое подобие шитого кода.

Тогда возникает другой вопрос: где здесь "логические матрицы"?

Но использовать адреса переходов (ШК) в хранимых вне программы данных непрактично - такие адреса при любом изменении программы становятся неактуальными

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

Я командировке

Ну тогда жду (ждем).

Так а че, погуглить не?

Если я не ошибаюсь, это подход Форта?

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

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

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

и даже в сторону Майерса камни кидаешь

Дай пожалуйста пруф!!!

Философское отступление. Несколько лет назад у меня спала "пелена из глаз". До этого, в течении многого времени, я считал себя заядлым агностиком. Многие вааще не понимали о чем речь. Но пришло осознание - я не агностик или атеист, я - неверующий. Даже религия тут не при чем! Я не верю ваще, ни во что. Полностью. Я пытаюсь воспроизвести и оценить. Гадил я с Пизанской башни на аксиомы "аксакалов". Но ... приду и проверю

... это я кидаю камень в сторону Меерса

Есть "логика", есть высказывания Меерса, есть куча методик шкальных оценок достоверности. Ну и есть чуйка))) Поверил во "фьючерсы" - это не смертельно! Возьми вычлени репрезентативную выборку результатов синтетических тестов на своих данных - и ты поймешь. Нужно ли слепо идти за Мейерсом, или эффективнее просто прислушиваться, приглядоваться, записывать ходы... E2-E4?

Wound, давай договоримся - не будем обсуждать САМОГО МЕНЯ

То ты гадишь на аксиомы "аксакалов", то доверяешь им

А всегда тебя щетал полезным - а оно вот как!!!

Никогда такого не делал !!!

Ну тогда жду (ждем).

И твой авторитет для него абсолютен, не смотря на все то, что он говорил в своей мировоззренческой теме

Сейчас вот перечитал в спокойной обстановке и всё равно не понял, в чём вопрос.

Что ты собственно, хотел узнать-то? Бо ничего не понятно...

А вот с Сями не факт

А виртуальное наследование по логике понятно, а по реализации - туман.

Ржал бы в голос, если б не спящие человеки рядом.

Всю статью процитировать?

ООП-код является недетерминированным. В отличие от функционального программирования, нет гарантий в получении одинакового вывода при одинаковых входных данных. Это делает анализ программы очень сложным. В качестве упрощённого примера: вывод 2 + 2 или calculator.Add(2, 2) в основном равен четырём, но иногда он может становиться равным трём, пяти и даже 1004. Зависимости объекта Calculator могут изменить результат вычисления трудно уловимым, но основательным способом.

Или их уже можно считать неосиляторами и сбитыми летчиками?

Как минимум тут уже обсуждали неосиляторство Линуса в плюсах

И как, посрамили этого недоучку?

"Посрамили" в моём понимании подразумевает участие того, кого срамят, так что нет

Или их уже можно считать неосиляторами и сбитыми летчиками?

Как минимум тут уже обсуждали неосиляторство Линуса в плюсах

Статья бредовая, практически полностью. Но прямо вот ржать..

Не думаю, что Линус неосилятор. Что в этих плюсах такого, чтобы их неосилить? Скорее он нежелает их осиливать, вероятно религия не позволяет, ибо Линус, как ни крути, слегонца упорот. А может и не слегонца.

Что в этих плюсах такого, чтобы их неосилить?

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

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

"Не осилил" во всех смыслах означает, что пытался осилить, но не шмогла.

Как насчет "научился но не захотел использовать"?

Это обсуждали уже - тогда бы на вопрос "почему не плюсы" был бы дан совершенно другой ответ.

Если А и Б в целом +- эквивалентны (git vs mercurial, vs code vs vim, блондинки vs брюнетки), то да. Если же вопрос звучит "Почему не Б, как более подходящей для задачи", да ещё если объективно Б покрывает абсолютно все возможности А и добавляет 100500 удобных плюшек, нужных в любом проекте сложнее helloworld-а, то вопрос более чем логичен.

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

Ты должен помнить, что, выступая против сентенций Линуса, я вменил ему совсем не это. Он привёл аргументы против Плюсов, которые ровно так же применимы и к Сям. Об чём предпочёл умолчать. Из чего можно сделать два вывода: либо он просто не понял, о чём высказывается (почему бы и не "не осилил" в конце концов), ибо лично я не могу себе представить, что бы профессиональному разработчику, успешно решающему подобные проблемы в C, могло б помешать использовать те же подходы в C++, либо он лукавит, имея в виду совсем не то, что сказал, умолчав об истинных причинах.

Но прямо вот ржать... думаю Qraizer несколько преувеличивает свою реакцию.

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

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

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

Erlang — это ООП в чистом виде. В отличие от других популярных языков, он сосредоточен на основной идее ООП — обмен сообщениями. В Erlang объекты взаимодействуют, передавая между собой неизменяемые сообщения

Что делает кодовую базу сложной? Есть много вещей, на которые следует обратить внимание. На мой взгляд, главными причинами являются: общее изменяемое состояние, ошибочные абстракции и низкое отношение сигнал/шум (бойлерплейт). Все они распространены в ООП.

Внезапно ООП именно так и выглядит везде.

Поэтому правильный ответ на вопрос "почему не плюсы?", как я уже сказал, должен звучать примерно, как "идите в жопу".

Где в java обмен сообщениями?

Если б он так сказал, я б только кивнул в ответ.

Вызовы методов.

Если честно, то лично мне сугубо фиолетово на чем разрабатывает Линус.

и они, разумеется, заслуживают более развёрнутого ответа, чем посылание в задницу.

К тому же ты подменяешь вопросы

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

Вызовы методов.

Как я уже сказал, я не уверен, что более развернутый ответ в принципе возможен

Почему?

В голом С++ нормальной реализации этой идиомы нету.
Именно поэтому для реализации "сигнал-слот" Qt запилило свой moc.

что такое обмен сообщениями в ОП

Что "почему"? Почему разработчикам линукса не фиолетово, на чём линукс разрабатывается?

Именно это и реализуют экземпляры классов посредством вызова методов в ООП.

Вызовы методов.

Мне кажется, вы не понимаете, что такое обмен сообщениями в ОП. В ОП вообще ничего нет, кроме объектов, которые взаимодействуют посредством обмена сообщениями. Именно это и реализуют экземпляры классов посредством вызова методов в ООП.
А то, что вы, ну вот сейчас конкретно ты, JoeUser, считаешь за обмен сообщениями, это не те сообщения, и не те обмены между объектами. Широковещательный, групповой итп обмены – это уже не принцип, а паттерн

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

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

то какая принципиальная разницf между отправкой сообщения и вызовом функции?

Вообще-то '!' это оператор

Expr1 отправлено процессу Expr2. Что там находится в Expr1 совершенно не важно. Что с этим сделает Expr2 тоже совершенно не важно. Нет даже гарантий, что Expr2 существует. А если существует, то нет гарантий, что Expr1 будет когда-то прочитано. А если быдет прочитан, то нет гарантий, что не будет отброшен. А если будет обработан, то нет гарантий, что это выльется в вызов каких-то функций. И процесс, который отправил сообщение ничего не ждет, как при вызове метода, ничего не пишет на стек, живет себе дальше. Вообще если приземленно, то аналогия будет примерно такой: вызов метода - это письмо, в котором Петя говорит Васе, что нужно сделать. А посылка сообщения тогда - это почта, которая это письмо доставляет от Пете к Васе в запечатанном конверте, и чья ответственность ограничивается только доставкой, при этом находится вне сферы влияния и Пети, и Васи.

Ну это на самом низком уровне. Голый процесс вряд-ли можно назвать объектом. А вот gen_server уже вполне

а там для отправки уже нужно делать call или cast

call так вообще очень сильно похож на обычный вызов метода объекта.

Это все детали реализации.

Говорят в Smalltalk то что внешне выглядит как отправка сообщений внутри сделано обычными вызовами.

Походу эта дискуссия скоро перейдет в плоскость философии.

Это все детали реализации. Говорят в Smalltalk то что внешне выглядит как отправка сообщений внутри сделано обычными вызовами.

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

Отсылка в статье конкретно к Эрлангу не имеет отношения к общему принципу взаимодействия объектов.

Если "создатель" термина ООП

Первым языком программирования, в котором были предложены основные понятия, впоследствии сложившиеся в парадигму, была Симула, но термин «объектная ориентированность» не использовался в контексте использования этого языка. В момент его появления в 1967 году в нём были предложены революционные идеи: объекты, классы, виртуальные методы и др.

На самом деле это спорный вопрос. C++ вдохновлялся языком simula

Мы говорим о идиоме, отвязанной от реализации.
Просто когда возникла такая идея.

Если "создатель" термина ООП критикует некоторые из его "инкарнаций" идеологии (его идеологии!!!) ООП, то он имеет на это полное право. Не нравится - форкай! Только не называй это уже ООП, называй, к примеру, ООПQ. Никто и лишнего слова не скажет!

то какая принципиальная разница между отправкой сообщения и вызовом функции?

Говорят в Smalltalk то что внешне выглядит как отправка сообщений внутри сделано обычными вызовами.

Вот тут чуть подробней про разницу сообщений и методов. По сути это разница между динамической и статической типизацией.

В D тоже есть возможность создать объект для которого можно вызвать любой метод. Правда все разруливается в compile-time.

Но можно взять Ruby, Там тоже можно любой метод для объекта вызвать и объект может сам решать, что ему делать с этим методом. И это уже в run-time. ЕМНИП даже похапе и жабаскрипт так умеют. Тоже мне киллер-фича.
Так что неубедительно.

Каким образом это может разруливаться в compile-time, если сообщение можно сформировать в runtime?

Это и есть отправка сообщения, а не вызов метода.

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

Что ты имеешь в виду?

Что именно тебе не понятно в этом предложении?

Просто это или неверно, или ты не раскрыл мысль.

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

Аналогично, мы можем в том же D создать аналогичный алгебраический тип и передавать объекту сообщения этого типа (вся диспечеризация в рантайме)

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

Не понял, к чему тут твой пример? Где разные объекты и где разная реакция на разные сообщения, в том числе и неизвестные?

Я рассуждаю в более узком смысле. Имеются в виду типы встроенные в язык. Допустим любая переменная в erlang имеет алгебраический тип состоящий из следующих типов: атом, функция, список, целое и так далее.

Объект foo, которому мы посылаем разные сообщения (в функции main) и он по разному реагирует на эти сообщения.

Мне кажется, тебя просто сбивает с толку pattern matching. Но фиг с ним.

А где имена сообщений-то? Мы же про ООП говорим? Диспетчеризация не по имени разве должна быть?

Причем тут pattern matching? Я о нем вообше не думал, замени erlang на JavaScript или PHP смысл не поменяется.

Ну добавь в сообщение строку с именем, будет тебе имя сообщения. Это не принципиально вообще.

Даже в определении ООП Алана Кея, ЕМНИП, нет ничего об именах сообщений.

Тогда я совсем не понимаю, при чем тут алгебраические типы данных

Так деспетчеризация же по имени идти должна, как не принципиально? Дальше идет поиск метода(сам объект/класс и далее по предкам). Нет?

Так а что идентифицирует сообщение?

Так деспетчеризация же по имени идти должна, как не принципиально? Дальше идет поиск метода(сам объект/класс и далее по предкам). Нет?

В TurboVision у сообщений не было адресатов.