[ООП] Почему ООП - это плохо?

enochka1145

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

tolval58

Время от времени здесь на форуме проскакивает мысль, что мол "ООП - это плохо"

Ссылки?

Marinavo_0507

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

traffik

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

Не связано с ООП. Объектность - разделение концептов на элементы и их внешние рецепторы, если можно так выразиться. Не разделение кода на блоки.
___________________________________
>>Wir machen nicht auf<<, riefen sie, >>du bist unsere Mutter nicht, die hat eine feine und liebliche Stimme, aber deine Stimme ist rauh; du bist der Wolf.<<

Ivan8209

Потому что:
1. Программы пишутся для того, чтобы их читал человек.
2. Человек мыслит больше в глаголах, причём --- не вовзратных.
3. Объекты АТД --- тоже объекты, а ООП вводит какие-то свои,
не очень-то понятные новобъекты.
4. Искусственно вводится бесполезное понятние наследования,
к которому пытаются всё прикрутить, из-за чего возникает куча
трудностей, связанных с областями видимости и т. п.
Альтернативы: функциональное программирование.
Последнее легко использует совершенно ортогональные ему
модульное программирование и АТД.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

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

enochka1145

> плохо, когда используется без веских причин там, где есть лучшие варианты
Я так понимаю, это не только к ООП относится.
> функциональное, логическое, агентно-ориентированное
И это решает все проблемы, которые возникают в ИТ (или хотя бы 50%)?
Кстати, агенты при агентно-ориентированном подходе случайно не объектами представляют?

traffik

КОНТРЕ: Четкой разницы между глаголом и существительным нет.
ДжУниту: Неважно, как представлять. В конечном счете все представимо линейным программированием в двоичном машинном коде. В еще более конечном - в виде аналоговых схем.

sergey_m

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

Ivan8209

Этих некоторых слишком мало.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

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

enochka1145

А разве объекты мира - не элементы с внутренностями и внешними рецепторами? По крайней мере, так удобнее думать.
И потом, чем ООП не разделение кода на блоки (по сути)?

Marinavo_0507

> По крайней мере, так удобнее думать.
Тебе удобнее считать, что в мире есть "недоношенные водители" (или как там этих тварей из соседнего треда зовут?)

Ivan8209

Далеко не все программисты занимаются на досуге языкознанием.
Обычно программирование заключается в описании того, что надо
сделать машины. Причём производится это описанием того, что бы
делал человек на её на месте.
В частности, часто пытается пропихнуть что-то подобное.
При этом человек наименее склонен рассуждать в вовзратных глаголах.
"Измени себя так, чтобы оно получилось," --- не проходит:
слишком сложно как для понимания, так и для восприятия.
---
...Я работаю антинаучным аферистом...

traffik

А разве объекты мира - не элементы с внутренностями и внешними рецепторами? По крайней мере, так удобнее думать.

Не совсем. Но мне так, действительно, удобнее думать. Люблю ООП. Главное не переусердствовать. "Дабы вы не развратились и не сделали себе изваяний".

И потом, чем ООП не разделение кода на блоки (по сути)?

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

bleyman

Я читал книжки про ООП, например Буча. В его терминологии объекты обмениваются сообщениями. В реальности объекты как правило всё-таки вызывают функции (даже если на низком уровне это реализовано через мессаги). В результате получаются разные смешные вещи, типа reentrancy, которая в случае ООП гораздо круче может всё убить чем в случае обычного функционального программирования. Это загадочно.

traffik

Может быть, я не права? Мне казалось, что сообщением в модели ООП называется вызов метода - по определению. Термин введен для того, чтобы не возникало ассоциаций с функцией. Потому что функция потенциально может получать инфу и о вызываемой, и о вызывающей сущностях. Более того, как раз функция - это и есть сущность. Можно сказать, что в функциональном программинге все делится на данные и функции, реализующие действия. А в ООП методы ничего не знают и не должны знать о вызывателе. Все делится на объекты, реализующие действия, и вызовы - "сообщения".
__________________________________
Now pray I to hem all that herken this litel tretise or rede, that if there be anything in it that liketh hem, that thereof they thanken our Lord Jesu Christ, of whom proceedeth all wit and all goodness. And if there be anything that displese hem, I pray hem also that they arrette it to the defaut of mine unkonning, and not to my will, that wolde full fain have said better if I had the konning.

nattana

ты наизусть цитируешь?
риспект, если чо

stm7884696

пока еще не сталкивался ни с одним проектом, в котором ООП реально бы давало фору функциональному программированию...
Хотя фанатиков, которые прогали в 2-3 раза больший код на ООП, решая ту же задачу, что и я повидал многих...
Давайте все таки конкретно и по примерам:
Вот задача.
Вот решение в функциональном виде.
Вот более ПРОСТОЕ и ВЫГОДНОЕ решение на ООП.
А вот - обоснование такого подхода.

Ivan8209

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

psm-home

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

функциональное программирование

? Фигасе.

dedwowan

Попробуй написать систему документооборота с помощью функционального подхода )

stm7884696

промышленный проект?
А что это?
Я же просил по полочкам:
Вот задача, вот варианты решения, вот ООП зарулил..
А кидаться фразами типа промышленный проект - это туфта...
Давай описалово и аргументацию.

Marinavo_0507

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

enochka1145

> Хотя фанатиков, которые прогали в 2-3 раза больший код на ООП, решая ту же задачу, что и я повидал многих...
Где ты их берёшь? Я-то думал, весь смысл ООП сводится к тому, чтобы так переформулировать задачу и её решение, чтобы писать надо было поменьше и попонятнее.

psm-home

Я не кидался фразами. Что ты понимаешь под "функциональным программированием"? По твоим постам в форуме видно что ты web developer. Ты говорил о том, что не встречал проекта, где ОО программирование зарулило бы функциональное. Мне стало интересно, что за проекты, о которых ты говоришь. Всё.

psm-home

Маза, кое-кто нефкурсе про смысл термина функциональное программирование. web page

Ivan8209

Может и сводится.
Да только плохо получается.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

Модернизированные лопаты уже завезли (delegates в .net будут и проекты, когда поколение сержантов сменится.

stm7884696

а мне стало интересно, какой смысл несет фраза "промышленные проект"?
Интерисоваться проектами, в которых ООП не зарулило функчиональное программирование (на функциях) не стоит...
Судя по твоим словам можно предположить, что таких проектов ты не знаешь...
А если ты их не знаешь, то возможны два варианта:
1) Ты вообще не знаешь о чем говоришь;
2)Ты знаешь о чем говоришь, но до сих пор сталкивался только с проектами, которые рулят на ООП...
Вот как раз об этой рульности твоих проектов на ООП я и спрашивал...
А так же о том, почему нельз было использовать функциональный подход...
ЗЫ Ну как, осилишь ответ?

enochka1145

> Тебе удобнее считать, что в мире есть "недоношенные водители" (или как там этих тварей из соседнего треда зовут?)

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

bleyman

Повторяю: я читал Буча. Объектно-Ориентированное Проектирование, второе издание. Это типа классика. У него объекты обмениваются сообщениями. Точка.
Начал я его читать именно потому что тоже очень удивился, когда Контра мне вдруг сказал, что в ООП вот так всё на самом деле. Почитал - и вправду.
Но дело в том, что парадигма сообщений неэффективна. Потому что сценарий именно вызова функции (типа GetItem(int index) например) крайне распространён, естественен для человека и всё такое, и при этом через сообщения в явном виде его заебешься организовывать. Поэтому в 99.9% ООП программеров считают что объекты вызывают друг у друга функции и методы (в терминологии Вирта - процедуры, то есть что-то, что не имеет возвращаемого значения).
С другой стороны, ООП обеспечивает предсказуемость поведения _исключительно_ в том случае, если всё построено на явных сообщениях, а иначе - реентранси и пиздец.
Вот это меня очень удивляет.

psm-home

Отлично. Я только за. Чем разнообразнее жизнь, тем интереснее. Моя позиция в этом деле простая. Если Родина прикажет вдруг забить на Java и пересесть на SML, то я это сделаю. И не буду кричать что "OOP рулит, а функциональщина говно".

Marinavo_0507

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

Ivan8209

Определения нет.
"Хотя Lisp всё ещё используется (как, например, и FORTRAN он
уже не удовлетворяет некоторым современным запросам..."
После таких заявления должны следовать слова: "например," "как
то" и т. п. Однако их не наблюдается.
"Появляется множество типизированных функциональных языков:
ML, Scheme, Hope, Miranda, Clean и многие другие."
Это вообще порадовало.
Вывод: фтопку.
---
...Я работаю антинаучным аферистом...

enochka1145

> Я устану ещё быстрее, если буду в дополнение к этим тысячам изобретать ещё столько же лишних.
Так не надо дополнять. Просто замени.
> Как тебе уже сказали, модульное программирование и абстракция данных ортогональны ООП.
Дожили...
Откроем какой-нибудь букварь ООП и прочтём: "ООП - это, вкратце, абстракция данных (инкапсуляция полиморфизм и наследование."
По поводу модульного программирования. Я не очень понимаю, что конкретно это означает, но например в Java строго: 1 класс (public) - 1 файл.

Marinavo_0507

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

psm-home

По пунктам, хуле.

а мне стало интересно, какой смысл несет фраза "промышленные проект"?

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

Интерисоваться проектами, в которых ООП не зарулило функчиональное программирование (на функциях) не стоит...

Это ещё почему? Я вот поинтересовался. Кто там говорил "пока еще не сталкивался ни с одним проектом, в котором ООП реально бы давало фору функциональному программированию...". Вот мне и интересно стало, что за проектыы такие.

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

В десятку. Я не знаю таких. Это не значит что их нет. Поэтому я спросил. Тебя.

если ты их не знаешь, то возможны два варианта:
1) Ты вообще не знаешь о чем говоришь;
2)Ты знаешь о чем говоришь, но до сих пор сталкивался только с проектами, которые рулят на ООП...

1). Не канает. Я немного щупал SML и OCaml. Одно время рядом со мной люде лепили нечто на SMLе.
Та что "вообще не знаешь" это не ко мне.
2). Я видел проекты, где применялось либо структорное, либо ОО-программирование. Они не то что бы откровенно рулили. Но они были. Понимаешь?

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

Забавно. Такая инверсия. Это мне было интересно тебя спросить. Грамотно стрелы перевёл. Ещё раз тебя процитировать, что ли.

Ivan8209

> Я не очень понимаю, что конкретно это означает,
> но например в Java строго: 1 класс (public) - 1 файл.
То есть модульности нет.
Потому что она достигается неязыковыми средствами (файлы).
---
"Я знаю правду! Все прежние правды --- прочь!"

psm-home

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

Ivan8209

> Я видел проекты, где применялось либо структорное,
> либо ОО-программирование.
> Они не то что бы откровенно рулили. Но они были. Понимаешь?
Первое включает функциональное.
---
"Я знаю правду! Все прежние правды --- прочь!"

Ivan8209

Но является им.
---
"Я знаю правду! Все прежние правды --- прочь!"

enochka1145

> Я не очень понимаю, что конкретно это означает,
> но например в Java строго: 1 класс (public) - 1 файл.
То есть модульности нет.

Ну возьми C# или C++ - там есть namespace-ы.

Потому что она достигается неязыковыми средствами (файлы).

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

Ivan8209

Да, чтобы модульность достигалась языковыми средствами,
а не средствами внешней операционной системы.
В твоих сях не ни "with", ни "use."
Так что управление областями видимости --- никакое.
---
"Я знаю правду! Все прежние правды --- прочь!"

evgen5555

>В твоих сях не ни "with", ни "use."
Неправда. В C# такое есть.

Ivan8209

Оба?
Вложенные модули?
Несколько модулей в файле?
---
...Я работаю антинаучным аферистом...

evgen5555

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfusingdirective.asp
"with" там -- не нужен.

enochka1145

> В твоих сях не ни "with", ни "use."
Паскалевское with, что ли? И как оно изменяет область видимости?

psm-home

А можно увидеть твоё определение модуля/модульности? Чтоб лучше понимать, о чём ты. Тока не посылай меня учить Ada, это слишком долго. Можешь просто ссылку дать.

Ivan8209

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

Marinavo_0507

> Ну возьми C# или C++ - там есть namespace-ы.
Неплохие штуки, но к ОО - никаким боком.

enochka1145

Это не к ОО, это к модульности, чёрт бы её побрал.

Marinavo_0507

Таким образом, что относится к ОО?
1) некий специальный вид абстракции данных, как сказал Контра, мешающий другим, но не пояснил, как;
2) некий частный случай полиморфизма (вызов фунции в зависимости от типа первого аргумента ---
multiple dispatch в распространённых ОО-языках нет); при этом вроде бы не мешает некоторым другим типам полиморфизма:
в C++ шаблоны вполне ортогональны ОО.
3) наследование, как частный случай отношения is-a, считать которое настолько универсальным во многих случаях вредно.

enochka1145

Кстати,
> А вот наследование - это искусственная операция, и часто излишне усложняет модель.
А кто просит наследовать? Можно ведь сделать один объект частью другого.

Marinavo_0507

> А кто просит наследовать?
Без этого бывает ОО?
> Можно ведь сделать один объект частью другого.
Да уж видели, какие выродки при этом иногда получаются

enochka1145

Серьёзно. Экель в своей "Thinking in Java" акцентирует внимание на то, что программисты в первую очередь думают: "Как бы отнаследовать?", тогда как чаще всего нужно сначала подумать: "Нельзя ли объединить в новый объект?".
Короче, если кто-то злоупотребляет наследованием, причём тут ООП?

Ivan8209

У тебя это описывается в п. "2": нельзя хорошо определить действия,
существенно вовлекающие более одного объекта, приходится вводить
сущности, выпадающие из ОО парадигмы.
Со всеми вытекающими.
---
...Я работаю антинаучным аферистом...

Dasar

Напомню:
что ООП - это когда есть объекты и они обмениваются сообщениями.
Объект - это ящик, у которого есть состояние,
также этот ящик может обрабатывать внешние сообщения.
Все. (большая жирная точка)
Полиморфизм
Инкапсуляция
Наследования
Модульность
Области видимости
Шаблоны
Типизация
Это все ортогональные понятия по отношению к ООП.
C++/Java/C# - не являются чистыми ООП-реализациями.
C++/Java/C# - это языки практического применения, и одна из основных целей этих языков - сделать так, чтобы компилятор генерировал максимально эффективный код, может быть даже в ущерб удобству.
Соответственно тот же ООП в рамках данных языков реализован только в той степени, в какой это позволил компилятор.

Marinavo_0507

> Напомню:
Откуда это?
И что там сказано про сообщения? В частности, чем посылка сообщения отличается от вызова метода?

Julie16

Ничем. Просто другое название одной и той же сущности?

Marinavo_0507

Если ничем, то приведено определение абстракции данных, и сказано, что ООП - это когда она есть.

Julie16

Ага. Все верно.

Dasar

> Откуда это?
(C) Мое.
Каждый из пунктов могу подтвердить примерами.
> И что там сказано про сообщения? В частности, чем посылка сообщения отличается от вызова метода?
Вызов метода - это упрощенная посылка сообщения.
Или другими словами посылка сообщения - это вызов метода, который превратили в отдельную сущность/объект.
т.е. вызов метода - это что-то нематериальное, и соответственно - неуправляемое.
то посылка сообщение - это тоже самое, но уже материализованное, и соответственно уже поддающееся управлению

Ivan8209

Тем, что первая более точно описывает ОО подход.
---
...Я работаю антинаучным аферистом...

Julie16

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

Ivan8209

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

Dasar

> Если ничем, то приведено определение абстракции данных, и сказано, что ООП - это когда она есть.
Абстракция данных - это скорее тип, чем объект.
Объект - это что-то с состоянием.

Dasar

Что такое жонглирование?

Julie16

Может быть я тебя не понимаю, но чем плохо do_things_with_objects( object1, object2 ) ?

Ivan8209

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

Ivan8209

Чей метод вызывается в этом случае?
Ты подменил ОО подход процедурным.
Или функциональным.
---
...Я работаю антинаучным аферистом...

Dasar

> Почему она не считается объектом, а вводится дополнительно подход, называемый "ОО"?
Почему ты считаешь, что она не считается объектом?

Ivan8209

Работа с равноправными объектами.
---
...Я работаю антинаучным аферистом...

Julie16

Ну тогда object1->method( object2, ..., objectn )

Ivan8209

Хорошо.
Тогда объясни, почему, к примеру, SML менее ОО язык, чем С++/С#?
В первом есть мощная система АТД, а в остальных --- огрызки.
---
...Я работаю антинаучным аферистом...

Dasar

> Работа с равноправными объектами.
Приведи конкретный пример из жизни, который надо положить на ООП.
чтобы мы не блуждали в облаках.

Marinavo_0507

В чистом ОО не должно быть функций, не привязанных ни к одному объекту.
А, например, сложение двух чисел (или других математических объектов) - это не то, что должно делать одно из них.
Где ты видел, чтобы число складывало себя с другим?
Да откуда оно вообще узнает, как это делать?

Ivan8209

То есть, ты отсылаешь объекту 1 сообщение, содержащие объекты 2--n.
На чём основывается выделение первого объекта?
Они ж все равноправны!
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Приведи конкретный пример из жизни, который надо положить на ООП.
Разные числа: целые разной разрядности, действительные с разной точностью, длинные.
Над ними выполняются арифметические действия.

Julie16

1) А кто сказал что эта функция не привязана ни к одному объекту? Она привязана скажем к объекту по умолчанию. Или глобальному объекту
2)

Где ты видел, чтобы число складывало себя с другим?

Ну например в С++. Там даже есть такой B::operator+ ( const A& a ) Если оно знает тип второго слагаемого, то оно знает и как это сделать.

Dasar

> Тогда объясни, почему, к примеру, SML менее ОО язык, чем С++/С#?
Потому, что понятие объект в SML-е искусственное, и не поддерживаемое самим языком.

Julie16

И что? Я так хочу. Объясни поподробнее, я тебя не понимаю

Ivan8209

Пример.
Тензор конвективного потока импульса получается произведением вектора скорости на ковектор количества движения.
Типы всех трёх объектов различны.
Чисто пример из моей жизни.
Считай, экспертная система.
---
...Я работаю антинаучным аферистом...

enochka1145

А, например, сложение двух чисел (или других математических объектов) - это не то, что должно делать одно из них.
Где ты видел, чтобы число складывало себя с другим?
Да откуда оно вообще узнает, как это делать?

Издеваешься?

Dasar

> А, например, сложение двух чисел (или других математических объектов) - это не то, что должно делать одно из них.
В чистом ООП - это будет скорее всего так:

processor.Add(число1, число2);

И уже processor на основе своего состояния, на основе, например, своих представлений о допустимой разрядности, сложит эти числа.

Marinavo_0507

> Она привязана скажем к объекту по умолчанию. Или глобальному объекту
В предметной области такой привязки нет. Лишняя сущность, усложняющая модель.
> Если оно знает тип второго слагаемого, то оно знает и как это сделать.
А как оно узнает, если мы этот тип только что придумали?

Julie16

Для таких вещей есть double dispatch.

Ivan8209

Кто тебе об этом сказал?
Только что выяснили, что сущность произвольного АТД --- объект.
Система АТД в ML-языках самая мощная из всех существующих сегодня.
Всяким сям и явам с ней никак не потягаться.
АТД --- это то, что лежит в основе всех ML-языков,
а ты заявляешь, что это искусственно?
---
...Я работаю антинаучным аферистом...

Marinavo_0507

processor - лишняя сущность, введённая, чтобы замаскировать отсутствие объекта с состоянием

Julie16

Ты утверждаешь что процессор это не объект? Или что у него нет состояния? Лол.

Ivan8209

Погоди!
Причём здесь процессор?
Он кто, вообще, такой?
Вводишь дополнительные сущности?
---
...Я работаю антинаучным аферистом...

Dasar

> Тензор конвективного потока импульса получается произведением вектора скорости на ковектор количества движения.
> Типы всех трёх объектов различны.
Записать это удобнее всего так:

a = speed * covector;

в ООП - это соответственно будет проинтерпретировано следующим образом:

a = MathSystem.Multiply(speed, covector);

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

Marinavo_0507

Это объект, но ненужный.
Какое у него будет состояние, и зачем?

Dasar

> Вводишь дополнительные сущности?
Да, ввожу.
Вы же только что сами правильно сказали, что числа сами складываться не умеют.

Ivan8209

А кто такой "MathSystem"?
У меня ЭС по гидродинамике!
Будь добр не выбиваться из предметной области ЭС.
---
...Я работаю антинаучным аферистом...

Julie16

Состояние - набор регистров + состояние памяти + etc... В общем любая совокупность железа - это объект с некоторым состоянием. Где состояний может быть ну очень много.

Ivan8209

Так это получается, что твой хвалёный подход дал сбой.
Не подходит он для работы одновременно с двумя равноправными объектами.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

У нас уже есть настоящий процессор с регистрами и т.д.
Зачем ещё один?

Dasar

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

Julie16

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

Dasar

> Зачем ещё один?
Чтобы точнее записать, что мы имеем ввиду.
Числа могут складывать и два процессора, и человек, их может, вообще складывать вселенский разум.

Dasar

> Не подходит он для работы одновременно с двумя равноправными объектами.
даже если так, ну и что?
ты до сих пор веришь в серебрянную пулю? которая подходит на все случаи жизни?

Marinavo_0507

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

Ivan8209

Отлично!
Ещё лучше.
Доказывай, что твой хвалёный приплюснутый и зарешёченный более ОО, чем Лисп.
Большинство объектов принадлежит к типу "ячейка списка."
Можно считать, что не принадлежит ни к какому.
Каждая сущность --- вполне себе объект.
---
...Я работаю антинаучным аферистом...

Julie16

Тебе не надо про это думать так как есть processor.blablabla. А если этого нет(так или иначе то тебе придется об этом задуматься.

Marinavo_0507

> Чтобы точнее записать, что мы имеем ввиду.
Куда уж точнее? Есть два числа, и нужен результат.
Пофиг, кто складывает.
> Числа могут складывать и два процессора, и человек, их может, вообще складывать вселенский разум.
Тогда почему ты ввёл именно процессор, и только один?

Dasar

> Так же, если надо сложить числа, мне незачем думать про какую-то штуку с регистрами.
Так если не надо, то ты и не думай.
Просто напиши:

a = b +c *d;

а потом сделай:

ТвойЛюбимыйЯзык.Вычислить("a = b + c * d");

Ivan8209

Как факт, он накладывает куда больше ограничений,
чем другой, не менее распространённый и, кстати,
куда более эффективный подход.
---
...Я работаю антинаучным аферистом...

Dasar

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

Julie16

Этот "факт" тебе нужно доказать. Иначе это пустая болтовня.

Marinavo_0507

МойЛюбимыйЯзык.Вычислить(длинная-длинная-программа)

Оказывается, ОО - это очень просто.

Dasar

> Оказывается, ОО - это очень просто.
да, никто и не говорил обратного.
ООП - это просто отражение реального мира.
В реальном мире всегда есть исполнитель действия (явный или неявный само по себе ничего не бывает.
Именно этот исполнитель и стоит обычно слева от точки.

Ivan8209

val x = [1, 2, 3];
x --- объект.
---
...Я работаю антинаучным аферистом...

Ivan8209

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

Julie16

Сформулируем иначе: ты не справляешься с простейшим примером в рамке ОО модели. Делаем вывод что ты не рюхаешь ОО.

Marinavo_0507

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

Dasar

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

Ivan8209

То есть, процедурный подход --- это такой ОО подход,
когда исполнитель просто не пишется?
Фтопку такой подход!
Я не хочу всё время работать за компилятор.
---
...Я работаю антинаучным аферистом...

Ivan8209

Приведи свой пример.
не справился.
---
...Я работаю антинаучным аферистом...

Julie16

200$. 40% заранее. Стандартная такса

Ivan8209

> ООП - позволяет более просто (более естественно) записать действия,
Ложно.
С задачей ты не справился.
---
"Истина грядёт --- её ничто не остановит!"

Ivan8209

Значит, твой довод отметаем за недоказанностью.
---
"Истина грядёт --- её ничто не остановит!"

Julie16

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

Ivan8209

Забыл добавить это: "Ты не справляешься с простейшим примером
в рамке ОО модели. Делаем вывод, что ты не рюхаешь ОО."
---
"Истина грядёт --- её ничто не остановит!"

Julie16

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

Ivan8209

Утверждения о несуществовании не следует доказывать.
Они истинны по определению.
---
...Тут приехал бульдозер товарища Оккамы...

Ivan8209

Потому что мне доказывать это не надо.
Пока не доказано обратное, я прав.
---
...Тут приехал бульдозер товарища Оккамы...

Dasar

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

ЛюбимыйЯзык.FindItem(collection, ">2");

или что тоже самое:

FindItem(collection, ">2");

или так:?

collection.Find(">2");

Julie16

Утверждение: КОНТРЫ не существует. Доказано КОНТРОЙ.

Dasar

> val x = [1, 2, 3];
> x --- объект.
Я могу послать этому объекту сообщение?
например, так:
x.FindAll(">2");
?

Ivan8209

Учи логику.
---
"...Физик должен, хотя бы в какой-то мере, быть в здравом рассудке."

Ivan8209

Например, так: filter (fn x => x>2) x.
То же самое, только в другой нотации.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

x : x in collection and x > 2

И уж точно a+b понятнее, чем UniversalMind.Add(a, b)

Julie16

Ну как сказать... Еще не ясно во что развернется +. Во втором же случае все кристально ясно.

Marinavo_0507

> Во втором же случае все кристально ясно.
Ничего не ясно.
Устройство Мирового Разума скрыто за его интерфейсом.

Julie16

Зато я буду знать что именно Мировой Разум будет делать сложение. В первом случае мне это не ясно.

Marinavo_0507

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

Dasar

> То же самое, только в другой нотации.
есть одно - "но", в данной записи не видно, кем и какой именно filter будет исполняться.

Marinavo_0507

> Зато я буду знать что именно Мировой Разум будет делать сложение.
Лично мне от этого, как правило, ничуть не легче.
См. выше про возможность разного мышления.

Dasar

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

Function func = НайтиНаиболееПодходящуюФункциюДляДанныхАргументов;

func.Выполнить(параметры);

Julie16

Я с этим и не спорю. Просто мне легче.

Marinavo_0507

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

Dasar

> И вот потому как всё равно компилятор преобразует, я хочу писать как удобно, а не как диктует парадигма.
Как минимум нужна возможность преобразования фя в ооп.
Чтобы в наглядном виде увидеть, что именно будет вызываться.

Marinavo_0507

> Чтобы в наглядном виде увидеть, что именно будет вызываться.
Ссылка на Мировой Разум - это наглядно?
Кстати, есть ещё абстракция кода - тоже полезный приём, так вот он как раз против такой "наглядности".

Dasar

> Ссылка на Мировой Разум - это наглядно?
Если именно он проводит вычисления, то да.
> Кстати, есть ещё абстракция кода - тоже полезный приём, так вот он как раз против такой "наглядности".
Так абстракция и конкретизация позволяют увидеть разные аспекты программа.
Если абстракция - позволяет наглядно увидеть общую идею,
то конкретизация - позволяет увидеть, что именно будет сделано в данном конкретном случае.

Marinavo_0507

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

bastii

Напомню:
что ООП - это когда есть объекты и они обмениваются сообщениями.
Объект - это ящик, у которого есть состояние,
также этот ящик может обрабатывать внешние сообщения.
Все. (большая жирная точка)
Полиморфизм
Инкапсуляция
Наследования
Модульность
Области видимости
Шаблоны
Типизация
Это все ортогональные понятия по отношению к ООП.

Странно, если ты можешь посылать одно и тоже сообщение разным объектам, то это и есть полиморфизм. Так что точку не там поставил. В остальном похоже на правду. Другие названые вещи это уже атрибуты ОО языка. Понятно, что на практике одного чистого ООП в языке мало.
Так инкапсуляция помогает упросить дело с пространством идентификаторов на одном уровне, а логическая модульность на другом. Типизация позволяет более упорядоченно работать с объектами, упорядочивает полиморфизм. Статическая типизация позволяет следить за этим порядком во время компиляции. Еще сегодня статическая типизация позволяет IDE лучше помогать при наборе кода (как убедились многие джависты, дело очень полезное; это основная причина, почему в VB.NET опция strict стала по умолчанию). Наследование – это довольно удобный способ упорядоченного повторного использования кода. Во многих современных ООЯП наследование еще хорошо увязывается с полиморфизмом, так что реализация "посылки сообщения" объекту получается очень эффективной. Еще можно вводить родовые элементы ЯП, как способ повторного использования кода, ортогональный наследованию. Причем тут возможны вариации в способе введения родовитости: от чисто синтаксического подхода (как темплейты в С++ до подхода, когда это дело лучше увязывается с полимофизмом и его реализацией (как генерики в С# или Eiffel). Кстати о наследовании, понятно, что его можно вводить по-разному. Так множественное наследование реализаций - это очень сложный механизм повторного использование кода. Если его вводить, то в достаточно развитой форме, как в Eiffel.
Главное, чтобы в языке все эти вещи хорошо сочетались между собой. Еще перед языком должны ставиться очень четкие цели. Требования, заданные в порядке убыванию по приоритету. Список сценариев, которые язык должен хорошо обслуживать. Исходя из этого уже должны приниматься решения относительно выбора деталей реализации. Остальное можно считать делом техники и квалификации создающих язык.
Аналогично можно оценивать язык. Нужно смотреть насколько удовлетворяет определенный язык тем требованиям, что вы хотите в первую очередь. Так, например, я не уверен, что согласен ставить требование "максимальная простота языка" на первое место (это я про Java). IMHO только так можно серьезно рассматривать языки. Иначе пустое дело.
И опять, ФП к ООП ни какого прямого отношения не имеет. Сам считаю, что ООП крайне полезная штука в языке, более того не вижу, как без этого обходится, достойной замены тоже. Хотя конечно не везде он возможно и нужно. Но если уже вводит какие-то элементы ООП в язык, то делать это нужно основательно, см. выше. Короче хотите ФЯ, ок, почему не ЯП=ФП+ООП. Есть еще такая экзотика, как логические ЯП. Есть такие, где ЛП+ООП. Нет проблем. Но для масс ничего лучше, чем императивные языки не придумали. Вон как рулит Basic. Сделали VB.NET как VB+OOП, так у большиства сразу возникли проблемы с пониманием основных концепций ООП. Говорят, что VB прогеры жалуются, что теперь им приходится явно иметь дело с наследованием.
Ну что, я не прав? Или давайте заканчивать этот флуд.

Dasar

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

Marinavo_0507

> Я только говорил, что исполнитель всегда существует - хотим мы этого или нет.
Все существующие объекты нужно упомянуть в программе?
Или может только те, которые важны для её понимания?

bastii

Когда человек говорит, что ООП говно, то скорее всего он не умеет им пользоваться. Жалко тех, кто пишет на ЯП без ООП, пользуюсь элементами ООП (это про вас любители С; если у вас часто всплывают указатели на функции, то пора задуматься).

Dasar

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

Marinavo_0507

> если у вас часто всплывают указатели на функции, то пора задуматься
правильно, пора задуматься об ФП
вот я задумывался, когда ещё не знал, что такое бывает (про ООП знал, но не помогало)
когда узнал - сильно обрадовался

Dasar

> Странно, если ты можешь посылать одно и тоже сообщение разным объектам, то это и есть полиморфизм.
Ты понимаешь, что означает термин "ортогональны"?
ps
С остальной частью сообщения - согласен.

Marinavo_0507

> Короче хотите ФЯ, ок, почему не ЯП=ФП+ООП.
Есть такие языки. Только тем, кто умеет ФП, почему-то не хочется ООП.
Ну кроме как для расширения чужого кода, уже спроектированного в соотв. стиле.

Marinavo_0507

> еще раз напомню, что понимание нужно разное: важно понимать
поэтому предлагаю выбирать стиль по ситуации, смотря что важнее

bastii

Может, тогда назовешь популярный ФЯ без элементов ООП? И заодно ФЯ, который советуешь посмотреть.

Dasar

> правильно, пора задуматься об ФП
Проблема в том, что на данный момент нет промышленных (удобных на практике) ФЯ.
Но есть много чистых(теоретических) реализаций ФЯ.
В рамках ФЯ, например, очень редко реализуются все следующие концепции:

Полиморфизм
Инкапсуляция
Наследования
Модульность
Области видимости
Шаблоны
Типизация
Императивный/декларативный
ООП

Marinavo_0507

> Может, тогда назовешь популярный ФЯ без элементов ООП?
Согласно данному выше определению, такого быть не может.

bastii

Ок, про "ортогональность" я понял.

Marinavo_0507

> В рамках ФЯ, например, очень редко реализуются все следующие концепции.
Тебя обманули, скорее всего рамку не там нарисовали.

Dasar

> поэтому предлагаю выбирать стиль по ситуации, смотря что важнее
Я бы предпочел, чтобы компилятор/IDE позволил бы мне записать и просмотреть один и тот же код, как в виде ФЯ, так и в виде ООП.

Dasar

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

Marinavo_0507

> Я бы предпочел, чтобы компилятор/IDE позволил бы мне записать и просмотреть один и тот же код, как в виде ФЯ, так и в виде ООП.
А я бы на твоём месте сначала озаботился бы отращиванием органов для восприятия этого.

Marinavo_0507

Ocaml, Common Lisp

Dasar

И где там: инкапсуляция, наследование, области видимости, модульность?

Marinavo_0507

RTFM?

Dasar

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

Marinavo_0507

Правда вопрос больше похож на:
"А где у этого микроскопа набалдашник, чтоб забивать гвозди, как я это делаю любимым молотком"?

Marinavo_0507

> Тебе сложно привести пример из трех строчек, которое это показывает?
Сложно, так как я не использую это на практике, и весь TFM позабыл.

Dasar

> Правда вопрос больше похож на:
> "А где у этого микроскопа набалдашник, чтоб забивать гвозди, как я это делаю любимым молотком"?
Я правильно понял, что ты считаешь - эти концепции не нужными?

Marinavo_0507

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

Marinavo_0507

Лучше посоветую, как смотреть, чтоб увидеть что-то новое.
Главное - это научиться по-другому мыслить.
И для этого лучше всего не использовать привычный стиль.
В случае OCaml:
* не использовать ОО-систему, можно про неё не читать вообще
* стараться не использовать императивных фичей: вместо циклов использовать всегда
рекурсию, даже если получается длинней и непонятней
* стараться создавать чистые функции, где это возможно (можно прочитать книжку Purely Functional Data Structures,
ftp://tentacle.local/pub/tmp/okasaki.pdf )
* придумывать применения тем фичам, для которых это применение не очевидно (ну вот я однажды
реализовал нечто похожее на наследование абстрактных типов через функторы, на игрушечном примере)
Можно, когда скажем делаешь что-то на работе, представлять, как бы это написать
в функциональном стиле.
И только когда начнёт получаться, изучить ОО-систему и начать использовать императивные фичи.
Иначе получится, что "Real Programmer can write FORTRAN in any language".

bastii

ок, спасибо, так и сделаю

bleyman

По поводу "Жонглирования Объектами"

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

Я бы написал так:
ConvectiveFlowTensor = new ConvectiveFlowTensor(speed, momentConvector);
Если вышеприведённая запись оказалась бы для меня слишком длинна (то есть часто используема я бы определил у скорости оператор умножения на конвектор количества движения.
Если учесть, что в данном конкретном случае все эти величины описываются матрицей даблов общего вида, то знать детали их внутреннего устройства вообще не нужно. Более того, на самом деле не нужно знать что это матрица именно даблов. В таком виде никакого ООП виолейшена не возникает ни за что.
А люди, которые пытались в данном случае ввести разные процессоры объектов етс. - просто хуёвые ООП дезигнеры.
Хотя иногда, конечно, бывают нужны "объекты без состояний", которые описывают операции. А что такого в том, чтобы операция была объектом? Единственная сложность - в том, насколько сильно операндам придётся открывать для операции свою внутреннюю структуру. В вышеприведённом случае - не пришлось.

Ivan8209

А какая разница, кем именно он будет исполняться?
Будет исполняться именно подходящий filter.
---
...Я работаю антинаучным аферистом...

Ivan8209

Ложно в отношении всего, за исключением наследования,
которое неизвестно, нужно ли вообще.
Ну, и "ООП" надо вычеркнуть.
---
...Я работаю антинаучным аферистом...

Ivan8209

Чем это отличается от функционального
"val ConvectiveFlowTensor = speed * momentConvector;"?
---
...Я работаю антинаучным аферистом...

Dasar

> А какая разница, кем именно он будет исполняться?
В ряде случаев очень важно, например, важно при разработке движков, когда я могу хотеть ограничить какие-либо вызовы.
> Будет исполняться именно подходящий filter.
Подходящий на мой взгляд?
или подходящий на взгляд компилятора?
как эту разницу увидеть?

Dasar

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

Dasar

> "val ConvectiveFlowTensor = speed * momentConvector;"?
Допустим ничем.
Как на ФЯ выглядит постоянная синхронизация двух внешних сущностей - например, состояния двух каталогов или состояния двух баз?

Marinavo_0507

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

Ivan8209

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

Dasar

Как на ФЯ записывается отношение общее-частное?
Например, что круг - это частный случай эллипса? И соответственно большая часть операций (заисключением выродившихся) справедливых для эллипса справедлива и для круга.
Как записываются отношения, например, между следующими понятиями:
фигура,
точка,
линия,
круг,
эллипс,
прямоугольник,
отрезок,
ромб,
треугольник,
многоугольник,
прямоугольник со скругленными краями,
ломаная,
сплайн,
составная фигура.
И соответственно, как записываются такие полиморфные операции, как:
нарисовать,
передвинуть,
повернуть,
отзеркалить,
получить оси симметрии?

Dasar

> Захочешь ограничить --- ограничишь.
> И это опять не зависит от того, кем именно выполняется вызов.
Средствами языка - я могу это сделать?
или мне придется - этот механизм реализовывать?

Dasar

> Ничего подобного.
Ты часть внешнего мира?
У тебя состояние есть? Или твое состояние полностью контролируется из вне?

bastii

Ну блин, чего спорить. Уже выяснили, что и в OCaml, и в ML (да и много где наверно) есть полноценная поддержка ООП, аналогичная тому, что есть в Java и в C#. Так чего ты хочешь доказать? Что есть полезные вещи кроме ООП -- никто не спорит. Что ООП бесполезная штука -- так это не правда. Что без ООП в ФЯ можно обойтись -- похоже, что создатели многих ФЯ языков так не считают.

Dasar

> Это не наследование, а выделение общего у двух действий и оформление его
в виде функции высшего порядка.
И почему это называется не наследование?

RTYuPZ78

где хоть одно слово об АОП, господа-студенты?

Ivan8209

Малая модульность --- куда более мощный механизм повторного использования.
Запрещая существование функций без привязки к "классам", ты
вводишь куда больше ограничений на повторное использование.
Тебе приходится вводить лишние сущности, чтобы привязать к
чему-то даже простые синонимы сложных действий.
> Внешний мир - это всегда ящик с состоянием.
Внешний мир --- это никогда не ящик с состоянием.
Внятного примера работы с физическими величинами в твоей
парадигме от тебя не дождались.
Увидели лишь фортраноподобный код в стиле древних времён.
---
...Я работаю антинаучным аферистом...

bastii

Дай с ООП разобраться. ООП уже давно. И вроде все кроме КОНТРЫ согласны, что штука полезная. Про АОП такого пока сегодня сказать нельзя.

voronetskaya

1. название треда прочитай
2. тут студент-то хоть один вообще участвует в обсуждении?

Ivan8209

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

Ivan8209

Отношение иначе называется "предикат".
---
...Я работаю антинаучным аферистом...

Dasar

> Запрещая существование функций без привязки к "классам", ты
> вводишь куда больше ограничений на повторное использование.
Моя точка зрения такая:
во время записи действий - функция может быть не привязана, во многих случаях, это удобно.
во время выполнения - функция должна быть привязана.
программист должен иметь возможность записывать и так, и так - а также иметь возможность просмотреть, как компилятор привязал функции.
также должно быть ограничение привязки - т.е. иногда хочется, чтобы к сущности чужие функции не привязывались.
> Внятного примера работы с физическими величинами в твоей
парадигме от тебя не дождались.
Я согласен с тем, что для записи мат. выражениий - лучше(по крайней мере - естественнее) всего подходит мат. запись.

bastii

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

В этом все фишка. Наследование -- это упорядоченное повторное использование кода. Можно ведь обходится только Copy/Paste, макросами и инклюдами. А главное никто не мешает кроме наследования всем этим пользоваться или чем ты там предлагаешь пользоваться. Ведь наследование это удобно, взял кнопочку перегрузил метод, который фон перерисовывает, получил кнопочку с картинкой. Взял MFC, перегрузил пару методов, получил готовое приложение

Dasar

> Если так, то это внешние представления одного и того же,
> а потому доступ производится через одно и то же имя.
Даже если это внешние сущности - "программу (схему работы)", которых ты менять не можешь?
Как ты собираешься объяснять, например, двум ftp-серверам - что они теперь имеют одно имя?

Dasar

> Отношение иначе называется "предикат".
Ты пальцем покажи.

Marinavo_0507

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

Ivan8209

Потому что это не наследоватние, а абстракция.
Малая модульность!
---
...Я работаю антинаучным аферистом...

Dasar

> Отношение иначе называется "предикат".
Т.е. получается, что ФЯ - низкоуровневый.
т.е. ФЯ не вводит такие более высокоуровневые понятия - как отношение наследования, отношения родитель<->ребенок, отношение использования, отношение частное<->общее и т.д.
Я правильно понял?

Dasar

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

Dasar

> Потому что это не наследоватние, а абстракция.
Имхо, это одно и тоже.
Абстракцией называется "поднятие" знаний(кода) вверх, а наследование - это "спуск" последствий "поднятых" знаний.
> Малая модульность!
Читабельность и скорость падает.
не зря же, например, любого бэкуса-Наура дополняют толпой конкретных примеров.

Marinavo_0507

> Чем этот язык будет отличаться от другого языка - который тоже работает со сложной иерархией сущностей, но с другими названиями?
Возможно тем, что отношения в этой иерархии будут по-другому устроены.
Например, эллипс.
Вроде бы эллипсу присуще наличие двух полуосей.
Применяем ООП - заводим класс "эллипс", и соответствующие члены, определяющие ориентацию, и величины полуосей.
Вроде бы круг - частный случай эллипса.
Применяем ООП - наследуем класс "круг" от класса "эллипс".
Получили, что кругу тоже присуще наличие двух полуосей.
Лажа вышла, не получилось использовать встроенные средства ОО-языка для представления нужных отношений.
Но в то же время круг можно рассматривать, как эллипс. Причём разными способами.
И хотелось бы, чтоб язык это позволял.
Эти отношения вообще интересно устроены.
Например, в результате афинного преобразования любого эллипса может получиться круг.
Хочется, чтобы это как-то записывалось на используемом языке.
Например, чтобы компилятор замечал, если мы пытаемся рассматривать результат преобразования
как прямоугольник, что такого не может быть.
А если - только как круг, то чтобы замечал, что это не единственный случай, и может быть ещё эллипс.
Вот и получается, что нужен специальный язык для моделирования фигур.

Dasar

Что измениться, если вместо слов круг/эллипс и т.д. будут, например, теги html-я?
или какая-то другая область тоже со сложными взаимосвязями?
> Лажа вышла, не получилось использовать встроенные средства ОО-языка для представления нужных отношений.
Где лажа? И почему не получилось?
Замечу, что у тебя в рассуждениях есть ошибка,
когда ты постулируешь, что эллипс - имеет две оси, ты подразумеваешь, что полуоси эллипса не равны, далее ты это свойство переносишь на круг - у которого эти оси равны, и удивляешься, почему ничего не работает.
Во-первых, если рассматривать круг и эллипс - то там как минимум три понятия, а не два:
1. круг
2. чистый эллипс (полуоси не равны)
3. Обобщенный эллипс - это и круг и эллипс (полуоси могут иметь равные значения).
а также такие извраты - как когда полуоси или равны нули, или равны бесконечности.
Соответственно эти три понятия связаны следующими отношениями:
круг и чистый эллипс - это частный случай обобщенного эллипса,
соответственно для круга и эллипса справедливо все то, что справедливо для обобщенного эллипса.
круг - это вырожденный случай чистого эллипса, соответственно для круга справедливы операции чистого-эллипса с учетом вырождения: например, у круга тоже есть две полуоси, но таких пар бесконечное число.

Marinavo_0507

> Соответственно эти три понятия связаны следующими отношениями:
> круг и чистый эллипс - это частный случай обобщенного эллипса,
> соответственно для круга и эллипса справедливо все то, что справедливо для обобщенного эллипса.
> круг - это вырожденный случай чистого эллипса, соответственно для круга справедливы операции чистого-эллипса с учетом вырождения:
> например, у круга тоже есть две полуоси, но таких пар бесконечное число.
Отлично, как ты выразишь это на ООЯ? В частности, как наследование поможет подставить круг вместо эллипса?
Подозреваю, что почти так же, как я на ФЯ. Неадекватно то есть.
В частности, компилятор не будет знать, что круг при преобразовании эллипса может получиться, а прямоугольник - нет.
А потом захочется, чтобы пользователь мог вводить классы фигур и определять отношения между ними "на лету".
Без специального языка не обойтись, вопрос лишь в том, насколько сложным окажется его трансляция,
сколько будет ручной работы, насколько она будет интеллектуальная.

bleyman

>Чем это отличается от функционального
>"val ConvectiveFlowTensor = speed * momentConvector;"?
В том и сила ООП, что на вид - ничем.

bleyman

> Отлично, как ты выразишь это на ООЯ? В частности, как наследование
> поможет подставить круг вместо эллипса?
class Circle
{
public static implicit operator Ellipsis(Circle circle);
}
и наоборот.

Marinavo_0507

> public static implicit operator Ellipsis(Circle circle);
не получится implicit, нужно указать, какую из бесконечного числа ориентаций использовать

bastii

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

Dasar

> Отлично, как ты выразишь это на ООЯ? В частности, как наследование поможет подставить круг вместо эллипса?
Например, для унарных операций через объявление и реализацию интерфейса.
Но согласен: у существующих реализаций ООП (особенно промышленных) языковые средства бедноваты.
Так, например, существующие языки очень тяжело переносят операции, которые выводят тип из кольца.
Но при чем здесь, вообще, ООП?
> В частности, компилятор не будет знать, что круг при преобразовании эллипса может получиться, а
> прямоугольник - нет.
Если пользователь расширяет на лету - то возможно, что и круг в прямоугольник превращается.
> Без специального языка не обойтись,
еще раз спрошу - чем эти специальные языки отличаются друг от друга?
Пока я вижу, что язык должен оперировать следующими понятиями:
тип, операция, отношение общее<->частное, состояние, операции, образующие кольцо, операции, выводящие из кольца, следствие (отношение: причина<->следствие вырожденный случай.

bastii

Пока я вижу, что язык должен оперировать следующими понятиями:
тип, операция, отношение общее<->частное, состояние, операции, образующие кольцо, операции, выводящие из кольца, следствие (отношение: причина<->следствие вырожденный случай.

Ну загнул Это что, принятая терминология?
Можно подробнее про

бразующие кольцо, операции, выводящие из кольца, следствие (отношение: причина<->следствие вырожденный случай

Dasar

> Ну загнул Это что, принятая терминология?
Что именно для тебя ново?
> операции, образующие кольцо
Результат таких операций имеет тот же тип, что и операнд(операнды).
например, для фигур - это операции поворота и перемещения.
> операции, выводящие из кольца
результат операции имеет другой тип, чем операнд (операнды).
например, для фигур в общем случае - это операция растяжения.
> следствие (отношение: причина<->следствие
истинность последующих утверждений зависит от истинности предыдущих.
например, истинность - эллипс имеет только две оси симметрии является следствием того, что полуоси не равны.
соответственно при добавлении новых утверждений, отношений, зависимостей, вырождении необходимо проверять на непротиворечивость и истинность всех остальных утверждений.
> вырожденный случай
также называется, как граничный случай, предельный случай.
Возникает при устремлении каких-либо параметров к границе их существования/истинности.
круг - вырожденный случай чистого эллипса при устремлении длин полуосей к равенству.
отрезок - вырожденный случай чистого эллипса при устремлении одной из полуосей к нулю.
полоса - вырожденный случай чистого эллипса при устремлении одной из полуосей к бесконечности.

Marinavo_0507

> Круг это подтип эллипса, он оуочняет эллипс условием, что оси равны.
То есть, ты предлагаешь в реализации круга оставлять две оси? И добавлять ещё радиус?
Несмотря на то, что у круга нет полуосей?
Хреновый дизайн.
> И вообще если у тебя будет какой-нибудь редактор
А если не редактор?
> Будет тип Фигура с методами Нарисовать, Активизировать и т.д.
Для этого не нужно наследование, всего лишь абстрактный тип данных, и его реализации.

Dasar

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

Marinavo_0507

> Например, для унарных операций через объявление и реализацию интерфейса.
Ещё раз.
У эллипса есть ориентация, соответственно должны быть функции:
получить вектор большой полуоси, малой полуоси.
У круга как такового ориентации нет, но можно придать произвольную ориентацию,
и потом рассматривать как эллипс.
Эллипс или круг можно подвергать афинному преобразованию, в результате получится эллипс или круг.
А прямоугольник получиться не может.
Как это записать? Нельзя на промышленном языке - давай на непромышленном.
> Но при чем здесь, вообще, ООП?
При том, что ОО-мышление в этой задачи не помогает, а многих наталкивает на плохой дизайн.
> еще раз спрошу - чем эти специальные языки отличаются друг от друга?
Вполне возможно, что язык, разработанный для фигур, окажется пригодным для чего-то ещё,
это будет дополнительный плюс.

Julie16

Ellipse* Ellipse::affineTransform( Transform* t ) const;

Marinavo_0507

> Объясни мне, как может быть абстракция без наследования?
Ну вот интерфейсы в java такие.

Marinavo_0507

> Ellipse* Ellipse::affineTransform( Transform* t ) const;
Ещё у нас есть многоугольники.
На них действуют такие же преобразования.
Из многоугольника получается многоугольник, а эллипс никогда не получится.
Также преобразование бывает для произвольной фигуры, неизвестного заранее вида.
Там может получиться что угодно.
Нужно, что если преобразуется фигура типа "эллипс", то чтобы компилятор знал,
что в результате может быть круг, но не может быть многоугольник.
Если мы пытаемся рассмотреть результат как многоугольник, то должны получить warning, что такого не бывает.
И чтобы если мы хотим рассматривать результат, как круг, то чтобы был error,
что рассмотрены не все случаи, так как может получиться произвольный эллипс.

Julie16

Да ты чо? Могу привести два способа решения этой задачи. Рантайм и во время компиляции. Тебе какой?

Marinavo_0507

Давай во время компиляции.

bastii

Хреновый дизайн

Почему?
Чем плох такой пример? В C# можно даже такой фокус сотворить.

  

interface IEllipse

{

  double AxeX { get; }

  double AxeY { get; }

}



class Ellipse : IEllipse

{

  private double axeX;

  private double axeY;



  public double AxeX { get { return axeX; }}

  public double AxeY { get { return axeY; }}

}



class Circle : IEllipse

{

  private double radius;



  double IEllipse.AxeX { get { return radius; } }

  double IEllipse.AxeY { get { return radius; } }



  public double Radius { get { return radius; } }

}

Надеюсь я правильно написал

Dasar

> Ну вот интерфейсы в java такие.
не вся правда.
Наследование даже в интерфейсах есть.
Если интерфейс A является абстракцией интерфейса B, то для B справедливы те же операции, что и для А.
Если интерфейс A является абстракцией объекта С, то C наследует возможность реализации всех этих операций.

bastii

> Объясни мне, как может быть абстракция без наследования?
Ну вот интерфейсы в java такие.

Пример неудачный, в Java полиморфизм завязан на наследование. В интерфейсах тоже.

Marinavo_0507

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

bastii

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

Marinavo_0507

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

bastii

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

Marinavo_0507

> нужно копать в сторону языков с динамической типизацией
точно, например lisp

bastii

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

Не инерция ОО-мышления, а издержки реализации в Java и ее родственниках.

bastii

Ты определись, что тебе не нравиться: ООП в целом или определенные ее реализации?

Julie16

#include <set>

#include <algorithm>

#include <stdio.h>



class Exception

{

};



class Convertible

{

        public:

                virtual int getClass const throw  = 0;

};



class Ellipse: public Convertible

{

        public:

                Ellipse

                {

                }



                virtual int getClass const throw 

                {

                        return 0;

                }

};



class Circle: public Ellipse

{

        public:

                Circle

                {

                }



                virtual int getClass const throw 

                {

                        return 1;

                }

};



class Converter

{

        private:

                Converter

                {

                }



        public:

                void addPair( int a, int b ) throw ( std::exception )

                {

                        d_possible.insert( std::pair< int, int >( a, b ) );

                }



                static Converter* getConverter

                {

                        static Converter c;



                        return &c;

                }



                template< class A, class B >

                void convert( A*& a, B* b )

                {

                        if ( d_possible.find( std::pair< int, int >( a->getClass b->getClass ) )

                                != d_possible.end )

                        {

                                a = (A*)b;//здесь конечно должна быть настоящее преобразование :)

                        }

                        else

                        {

                                throw Exception;

                        }

                }



        private:

                std::set< std::pair< int, int > > d_possible;

};



int main

{

        Converter::getConverter->addPair( 0, 1 );



        try

        {

                Ellipse* e = new Ellipse;

                Circle* c = new Circle;

                Converter::getConverter->convert( e, c );

        }

        catch ( const Exception& e )

        {

                printf( "exception 1\n" );

        }



        try

        {

                Ellipse* e = new Ellipse;

                Circle* c = new Circle;

                Converter::getConverter->convert( c, e );

        }

        catch ( const Exception& e )

        {

                printf( "exception 2\n" );

        }

}

PS: это во время выполнения. Можно сделать то же самое во время компиляции, определив template convert и специализировать его только для случаев возможной конвертации.
PPS: можно вместе с каждой парой регистрировать функцию преобразования.
PPPS: можно даже применить поиск в графе и находить путь преобразования, чтобы можно было делать A -> C, если заданы A -> B, B -> C.

Marinavo_0507

> PS: это во время выполнения. Можно сделать то же самое во время компиляции, определив template convert и специализировать его только для случаев
> возможной конвертации.
> PPS: можно вместе с каждой парой регистрировать функцию преобразования.
> PPPS: можно даже применить поиск в графе и находить путь преобразования, чтобы можно было делать A -> C, если заданы A -> B, B -> C.
Всё правильно, но только ООП будет не при делах.
Примерно так же это запишется на любом достаточно выразительном языке.
А на специальном - гораздо понятнее.

Marinavo_0507

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

Julie16

Круг один и тот же, а свойства его зависят от субъекта.

Для этого можно использовать грани.

Marinavo_0507

> Для этого можно использовать грани.
Это что?

Dasar

> что только объекты есть в реальном мире, а например чистых функционалов - нет.
проблема в том, что чистые функционалы - это абстракция.
взять те же фигуры - пока мы их рассматриваем оторванно от "реальной жизни" - то все хорошо.
Но допустим мы рассматриваем те же фигуры в рамках редактора.
Сразу появляется понятие экземпляр, ссылка на экземпляр, текущее состояние экземпляра, изменение экземпляра и т.д.
Я, например, согласен с тем, что ФЯ является одним из мощных инструментов для описания преобразований.
Но вот остальные задачи - ФЯ делает очень и очень плохо.

Julie16

Джефф Элджер. С++ for real programmers.
Грань - это интерфейсный указатель, который предоставляет некий интерфейс к объекту.

Marinavo_0507

> проблема в том, что чистые функционалы - это абстракция
как и объекты, обладающие определённым набором свойств, причём только одним
как и отношение is-a
говорить, что какие-то из этих абстракций якобы есть объективная реальность - это упрощение,
которое иногда оказывается слишком грубым
> текущее состояние экземпляра, изменение экземпляра
нет такого
не меняются фигуры в граф. редакторе - создаются новые, но и старые сохраняются
доказательство: наличие кнопки undo

Marinavo_0507

> Грань - это интерфейсный указатель, который предоставляет некий интерфейс к объекту.
Похоже на что-то чисто функциональное

Julie16

Очень может быть. Тем не менее это объект

Marinavo_0507

Идеи мудрецов постепенно доходят и до "прапорщиков", командующих "солдатами с сапёрными лопатками".

Dasar

> не меняются фигуры в граф. редакторе - создаются новые, но и старые сохраняются
Что происходит с ссылками?
например, если фигура была подсоединена к другим фигурам?
Фигура была выбрана в UI?
Фигура являлась внешним объектом (например, Ole-документом)?
ps
undo - ничего не значит
я знаю, как минимум три варианта реализации undo, которые сильно друг от друга отличаются.

Marinavo_0507

Безнадёжно

Dasar

Так как все-таки оформляются ссылки?

bleyman

Это. Сила ооп в том, что даже операцию можно рассматривать как объект. Весьма специфический, но вообще нормальный такой объект. Тяжело в компайл-тайм проконтролировать типизацию, конечно, но что-то у меня подозрение есть одно, относительно проверок времени компиляции в ФЯ...
Да, а вот зато воспринять объект как операцию невозможно.

Marinavo_0507

> Сила ооп в том, что даже операцию можно рассматривать как объект.
Чем такой объект лучше, чем просто значение?

bleyman

чо?

Marinavo_0507

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

bleyman

Это типа как в С, да?

Marinavo_0507

Нет, не как в С. Изучи какой-нибудь язык (рекомендую ocaml).

bleyman

[Запомни Фж, смайлики надо ставить когда шутишь в софтваре... Да и вообще...]
>> Сила ооп в том, что даже операцию можно рассматривать как объект.
>Чем такой объект лучше, чем просто значение?
Он объект. Объект является объектом ООП парадигмы (объектом).
А вот интерпретировать объект как функцию у тебя всё равно не получится ;Р

Marinavo_0507

Получится. Только это тоже не нужно.

lera98

Ох и нихренась, сколько воды развели по теме!
Забейте вы на все эти формулировки. Спорите, втираете что-то друг другу. Это выглядит как "каламбур" - игра слов, понятий. Нужно стараться говорить не на терминологическом языке, а на обычном, не требующем каких-либо дополнительных пояснений и растолковываний.
___________________________________________________________________________
Во многих сообщениях отражается основная мысль-ответ на эту тему. Сформулирую её так: "Хошь в консоли Hello,World напечатать, - забей на ООП".
Более чётко так:
"Есть разные методы программирования. Возьмём ООП и ФП (Функциональное Программирование). Поставлена конкретная задача. Для её решения выбираем метод, позволяющий добиться _понятного_ результата при _наименьших_ затратах.
Под понятным результатом понимается такой код, разобраться в котором может другой (сторонний, или ты сам через пару лет) программист. Затраты учитываются, например, такие: время разработки кода, скорость выполнения на проце, потребление ресурсов машины, и т.п."
Так что на вопрос "Почему ООП - это плохо?" ответ простой: "Удобно? Есть смысл? - Пользуй. Не удобно? - пользуй другое."
Отрицательное отношение к ООП может сложиться у приверженцев не-ООП-методов при виде неоптимально решённой задачи. Такие "неоптимальные" решения возникают из-за того, что любители ООП, натренировавшись в этом методе, применяют его _почти везде_. Из-за большого опыта ООП-программирования их трудозатраты (время разработки кода) при использовании этого метода минимальны, и они выбирают такое решение задачи.
______________________________________________________________________________
Вобщем, надо разумно выбирать метод решения задачи.

lera98

Насчёт того, как _я_ понимаю ООП, по порядку:
Использовать ООП - это писать код объектов и код работы с ними.
/* Причём первое, как правило, делать не надо, поскольку это уже было _ранее выполнено_. Примерно то же можно сказать и о _готовых_ функциях в функциональном подходе. */
Объект - "ящик" с входами и выходами. Из входа нельзя получить инфу, на выход её нельзя подать. Объект либо состоит из нескольких других объектов, либо является примитивным.
/* Пример примитивного объекта - операция сложения. Ящик. Два входа слагаемых и один выход суммы. */
Работа с объектами - соединение их входов и выходов.
/* Как частный случай, в результате работы с объектами можно получить новый, более сложный объект. Также можно считать любую программу объектом, но, как правило, такие объекты имеют слишком узкую область применения и не подходят для использования в конструировании новых (более сложных) объектов. */
________________________________________________________________________
Функциональное программирование тоже можно рассматривать с позиций ООП. В ФП группы функций для работы с одной и той же совокупностью данных не объединены в единый объект. Отсюда (с этих самых позиций) видны (возможно, только некоторые) плюсы и минусы ФП.
(+) меньше кода (имеется ввиду не посимвольно, а по действиям)
(-) сложнее понимание
Более подробно:
Допустим, имеется N групп функций по N (то же число взято для удобства оценивания сложности, чтоб степени применять можно было) функций в группе.
ФП: реализуем по отдельности функции. Всего N*N = N^2 объектов (т.е. функций) первого (верхнего) уровня.
ООП: реализуем N объектов первого уровня (для каждой группы функций). В каждом реализуем по N объектов второго уровня ("объекты-функции"). Итог: N объектов первого уровня, N*N второго, всего N*N + N объектов.
Таким образом, используя ООП, конструировать объектов (ака писать кода) нужно больше. Для понимания же в случае ФП перед взором предстаёт N^2 объектов; в случае ООП - N объектов.

bleyman

Работа с объектами - соединение их входов и выходов.

Отлично! Возвращаясь к единственному возражению против ООП не в стиле "а нах надо?" (моему) (на которое все забили почему-то): А как ты гарантируешь отсутствие цикла в своём графе соединений (то есть реентранси)?
Поясню проблему примером: Есть компутерная игрушка. Есть стрела, которая умеет летать, тыкаться в объекты, и наносить им дамаг. После попадания стрела исчезает.
Как эту задачу будет писать ООП программер:

public class Arrow : INextFrame, IDamageDealer, IDamageReceiver

{

    /// <summary>

    /// Called by ObjectManager

    /// </summary>

    public void NextFrame

    {

        object targ;

        if (null != targ = Radar.HitTest(this

        {

            IDamageReceiver targ;

            if (null != targ as IDamageReceiver)

            {

                targ.Hit(this as IDamageDealer);

            }

            ObjectManager.Remove(this);

        }

    }

    

    int IDamageDealer.Damage

    {

        get { return 10; }

    }



    void IDamageReceiver.ReceiveDamage(int dmg)

    {

        if ( dmg > 2 ) 

        {

            ObjectManager.Remove(this);

        }

    }

}

Отличный код для стрелы, не правда ли? Пока стрела тыкается в кроликов, всё работает превосходно. А какой-нибудь Fire Shield исправно сшибает низколетящие стрелы.
ок, едем дальше. Через полгода программеру надо добавить новый объект (4711ый по счёту): Бочку. Бочка может взорваться, если получит единомоментно достаточно дамажа. Взрывом бочка делает дамаж всему вокруг.

public class Barrel : IDamageDealer, IDamageReceiver

{

    int IDamageDealer.Damage

    {

        get { return 20; }

    }



    void IDamageReceiver.ReceiveDamage(int dmg)

    {

        if ( dmg > 8 ) 

        {

            object[] nearby = Radar.GetNearby(this)

            foreach (object targ in nearby)

            {

                IDamageReceiver targ;

                if (null != targ as IDamageReceiver)

                {

                    targ.Hit(this as IDamageDealer);

                }

            }

            ObjectManager.Remove(this);

        }

    }

}

Угадайте с трех раз, что произойдёт, если стрела тыкнется в бочку? В процессе угадывания считайте потраченное время и приложенные интеллектуальные усилия - чтобы осознать, что обнаружение проблемы вовсе не тривиально.
Если не удаётся понять глазами, а компилить влом, могу объяснить - в процессе вызова стрелой targ.Hit(this as IDamageDealer); вызывается её же интерфейсная функция ReceiveDamage, которая её уничтожает (вызывая ObjectManager.Remove(this. Но стрела об этом как бы не знает, поэтому сама ещё раз удаляет себя после этого.
Так вот, в оригинальной концепции ООП бочка и стрела обмениваются мессагами. При этом приняв мессагу объект заново осознаёт текущее состояние себя и мира, и такой проблемы не возникает (так я понимаю Оригинальную Концепцию ООП).
Мне могут сказать: хуйовый дизайн у чувака. Ну да, хуйовый. Если писать ООП не на мессагах, а на вызовах методов, то через некоторое обязательно время возникает вот такая херня (и это ещё хорошо если она возникнет достаточно рано). Херня, кстати, состоит конкретно вот в чём: отдавая execution flow наружу метода, можно получить его произвольное количество раз обратно в тот же объект. В процедурном программировании это называлось Reentrancy, и именно поэтому локальные переменные функций клались на стек, а не резервировались раз и на всегда (как правило). А тут как бы поля объекта в стек не засунешь.
Ну вот, в результате у чувака есть несколько выходов (сколько заметил, столько заметил):
1) расставить кучи проверок вокруг всех вызовов.
2) пытаться переделать дизайн ручками (в данном случае можно сделать класс Damage, который будет существовать отдельно от стрелы или бочки, создаваться ими, и быть неуничтожимым).
3) пытаться добавить элементы ООП-на-мессагах (немножко мессаг в ObjectManager).
4) перейти целиком на ООП-на-мессагах.
Во-первых, по поводу (4): а вы пробовали? Я пробовал, это пиздец. Мб где-то ещё сохранился код (если можно его так называть). Фишка в том, что послать мессагу каждый дурак может. А вот реализация запроса "А сколько у тебя хитов осталось" (с проверкой поддержки соответствующей мессаги, естественно) - это уже жёппа.
Во-вторых, по поводу (1): а я не пробовал и не собираюсь. Потому что никто и никогда мне не гарантирует (и даже не намекнёт что я расставил все нужные проверки.
Правильным вариантом, по видимому, должен быть (2). Если нужно - добавить (3) по вкусу. Насколько я понимаю, в оригинальной концепции ООП тоже скорее всего дизайн следовало бы сделать таким как в (2 но отступление от этого не привело бы к таким забавным результатам (как мне кажется). Однако я не уверен, что (2) всегда реализуемо. Более того, чтобы реализовать (2) нужно вначале догадаться/заметить что глюк вообще есть. А ещё, когда вдруг обнаруживаешь что-нить такое, очень хочется удавиться. Ну типа по личному опыту говорю - в голову попадает мысль "бля бля дизайн нужно переделать бля скорее всего целиком бля бля", которая очень мешает думать.
Ну так вот, ИМХО основная проблема ООП - это реентранси, которую можно устранять либо внимательно изучая Call Graph, либо имея этот Call Graph в голове постоянно, либо изначально заморачиваться на эту тему, получая кучу лишего (и как правило нечитаемого кода).
Полноценных программных решений я что-то ещё не видел, поэтому одно пишу сам =).

enochka1145

Слушай, ! Ты конечно клёвый чел, хорошую статьи порой выдаёшь, типа той про Бойцовский Клуб, Кастанеду и транспоттинг (или как там его).
Но про игры тебе вроде ясно сказали: законы игрового мира пишут сценаристы (даже не программисты) на специальном скриптовом языке.
Ты сам-то, что, всерёз считаешь, что такие детальные правила игры, какие ты привёл, кодируют жёстко, в коде программы?
Просьба думать. Я сам не всегда этим занимаюсь, но всё-таки. Кроме того, неуместный мат и дурацкие слова напрягают.

bleyman

>законы игрового мира пишут сценаристы (даже не программисты) на специальном скриптовом языке
1)Я пример привёл. В тех терминах, которые очевидны и всем понятны. Вот так сразу придумать более общепрограммерский пример я не могу. Если хочешь, могу придумать попозже.
2) А специальный скриптовый язык не ООП? Гы гы гы. Вот уж что прямо таки обязательно описывать на ООП - так это взаимодействие объектов игрового мира.
3) А один из лучших скриптовых языков - С#, кстати =) Ему динамической типизации немножко не хватает, но вообще она делается через рефлекшен достаточно просто.
> неуместный мат и дурацкие слова напрягают
Извини, я так думаю. Можешь не читать.

voronetskaya

глупый вопрос - зачем поражаемому объекту сцылка на то что его поразило?

bleyman

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

Marinavo_0507

А если с каждым объектов связать поток выполнения (co-routine и разрешить менять состояние только этому потоку?
А состояние других менять только асинхронными сообщениями. Можно синхронно делать запросы, не меняющие состояние,
например, узнать число хитов.
Не решится ли проблема тогда?

bleyman

Дык, я себе уже решение придумал (типа того что ты сказал, только проще и оно мне нравится.
Типа есть три атрибута, которые ставятся перед методами:
QueryPermission - состояние не меняет.
ChangePermission - меняет состояние только данного объекта.
OrderPermission - может менять состояние и данного и других объектов, но вызывать её может только ObjectManager, то есть это как бы точка входа.
Типа мы уже почти дописали чекалку (забив на проверку QueryPermission - const в шарпе не очень просто реализовать скоро будем тестить как под это прогать.

Dasar

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

Ivan8209

TEA-P
---
...Я работаю антинаучным аферистом...

Ivan8209

Он ещё не вводит понятий UnicersalMind и MathSystem.
---
...Я работаю антинаучным аферистом...

Ivan8209

Конкретизация делается без извращений с наследованием птицы от мухи и человека.
---
...Я работаю антинаучным аферистом...

Dasar

покажи
Ps
наследование птицы от мухи и человека - это ошибка дизайна

Marinavo_0507

В этом треде пока ещё не родился пример, в котором наследование не было бы ошибкой дизайна.

Dasar

ты так и не ответил: спуск последствий делается в ручную или автоматом

Marinavo_0507

N/A

Ivan8209

MathSystem, которую ты вводил,--- тоже абстракция.
> Но допустим мы рассматриваем те же фигуры в рамках редактора.
> Сразу появляется понятие экземпляр, ссылка на экземпляр,
> текущее состояние экземпляра, изменение экземпляра и т.д.
То есть, вместо "классов" со всякими "наследованиями",
появляются объекты некоторого АТД.
И ООП идёт лесом.
> Но вот остальные задачи - ФЯ делает очень и очень плохо.
Ложно.
Напоминаю, что примера работы с физическими величинами от ООП не дождались.
---
...Я работаю антинаучным аферистом...

Ivan8209

fun ff x y = f a b c x y;
---
...Я работаю антинаучным аферистом...

Ivan8209

> Работа с объектами - соединение их входов и выходов.
Так что насчёт жонглирования двумя объектами?
Чей вход-выход будем подсоединять первым?
> (-) сложнее понимание
Скорее, наоборот.
Математику начинают учить раньше ООП.
---
...Я работаю антинаучным аферистом...

Ivan8209

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

Ivan8209

"Я возражаю <...> против точки зрения, что только объекты есть в реальном мире,
а например чистых функционалов - нет."
"Добро пожаловать в реальный мир!"
Там нет ни тех, ни других.
---
...Я работаю дзен-бульдозеристом...

bastii

Единственная проблема ООП, это то, что при разработке естественно получается подход, когда идут сверху вниз. Сначала создаются основные абстракции (интерфейсы, базовые классы, схема их взаимодействия все остальное в проге очень от них зависит. А проблема, что хорошо это сделать очень сложно. Вот и получается, что очень долго и старательно проектировали, а когда начали кодировать, обнаружили, что что-то не учили. Возможно поэтому и стали популярны всякие ХР программировании.
Но все равно, ведь ничего не придумали хорошего пока, что могло заменить ООП.

Marinavo_0507

> Там нет ни тех, ни других.
Откуда ты это знаешь?

Ivan8209

Прикинь, при ФП тоже естественно идти сверзу вниз.
Правда, ничто не мешает в любое время пройти снизу вверх.
> Но все равно, ведь ничего не придумали хорошего пока, что могло заменить ООП.
Мы уже установили, что это гнусная ложь. Не устал ещё?
Это ещё более усугубляется только что установленной невозможностью средствами ООП наращивать сложность проблемно-ориентированного языка.
То есть, надо начинать наследование от чего-то богоподобного, а "ex nihilo nihil."
---
...Я работаю антинаучным аферистом...

Ivan8209

А я знаю правду.
---
"...Да святится имя Мое, да приидет Царствие Мое,
да будет воля Моя и на земле, как на небе."

bastii

Мы уже установили, что это гнусная ложь. Не устал ещё?

Ну напомни, пожалуйста, что вы там нашли в замену ООП, а то этот спор идет уже не один день.

Marinavo_0507

"Папа, где море?"

Ivan8209

ФП убивает всё ООП к чёрту и даёт довесок, потому что ООП менее универсально.
---
...Я работаю антинаучным аферистом...

Julie16

Нда? Что такое ФП? Даже не так: объясни парадигму ФП.

Dasar

> MathSystem, которую ты вводил,--- тоже абстракция.
Она не абстракция - это реальный контекст в рамках которого исполняется твой код (твоя запись).
> появляются объекты некоторого АТД.
> И ООП идёт лесом.
Чем объект из АТД отличается от объекта из ООП?
> Напоминаю, что примера работы с физическими величинами от ООП не дождались.
Могу еще раз повторить.
Запись будет такая:

a = b + c * d;

исполнение будет такое:

a = b.Add(c.Mul(d;

ps
напомню, что Immutable объекты тоже бывают.
immutable объект - это все-таки не функция.

Marinavo_0507

с.Mul(d)
если с - число, то откуда оно знает, как умножать многочлены?
d - случайно оказалось многочленом

bastii

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

Dasar

> То есть, переводя на более понятный, наследование
> является выражением конкретизации,
> а следовательно, усложнять _ничего_не_может_.
доказать можешь?
напомню, что вся математика - это конкретизация аксиомы, что 1+1 = 2
> То есть, вот откуда растёт бедность мышления боевиков ООП.
Путаешь причину и следствие.

Dasar

> если с - число, то откуда оно знает, как умножать многочлены?
зачем ему быть числом?
с - это число-объект.

bastii

В ООП числа тоже объекты, какого-нибудь АТД Number с методами +, -, / , и т.д.

Marinavo_0507

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

Dasar

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

Ivan8209

>> MathSystem, которую ты вводил,--- тоже абстракция.
> Она не абстракция - это реальный контекст в рамках
> которого исполняется твой код (твоя запись).
То есть, мне для полного счастья надо ещё и знать ту "неабстракцию,"
где это будет обсчитываться?
Нафиг тогда ООП? Пиши на маш. коде!
>> появляются объекты некоторого АТД.
>> И ООП идёт лесом.
> Чем объект из АТД отличается от объекта из ООП?
Я задавал тебе этот вопрос выше.
Ты не дал внятного ответа.
Объект АТД вообще лежит вне парадигмы ООП,
поскольку последняя не знает, что такое абстракция
и чем последняя может быть полезна.
> Могу еще раз повторить.
> a = b.Add(c.Mul(d;
Напомню, что ты не ответил на несколько вопросов.
В частности, связанных с выбором "главного объекта."
Где ответы?
И мы не увидим внятного ответа, потому что ООП _не_способно_
работать с несколькими равнозначными объектами.
> напомню, что Immutable объекты тоже бывают.
И что?
> immutable объект - это все-таки не функция.
А наоборот?
---
...Я работаю антинаучным аферистом...

Ivan8209

Да для инвалидов можно и не такое сделать.
Кстати, примеров обратного не видно,
что только подтверждает ограниченность ООП.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

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

Marinavo_0507

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

Ivan8209

>> То есть, переводя на более понятный, наследование
>> является выражением конкретизации,
>> а следовательно, усложнять _ничего_не_может_.
> доказать можешь?
Отмотка обсуждений --- по обычной таксе:
DG> Абстракцией называется "поднятие" знаний(кода) вверх,
DG> а наследование - это "спуск" последствий "поднятых" знаний.
>> То есть, вот откуда растёт бедность мышления боевиков ООП.
> Путаешь причину и следствие.
Понял.
Был неправ.
Исправляю.
Из бедности мышления боевиков ООП растёт ограниченность средств ООП.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Marinavo_0507

> Из бедности мышления боевиков ООП растёт ограниченность средств ООП.
Это больше похоже на правду: в современные вроде-бы-ОО-языки всё больше проникают ФП-средства,
и средства метапрограммирования.

Julie16

Ну всегда можно сделать operator+ ( const A& a, const B& b ). Во всяком случае в С++. И как это противоречит ОО? Блин, хватит противопоставлять ООП и ФП. Эти две концепции очень хорошо дополняют друг друга. Или вы хотите сказать что те сущности, которыми управляет ФЯ, не являются объектами?

Julie16

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

Ivan8209

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

Ivan8209

CL --- современный язык.
Записали.
---
...Я работаю антинаучным аферистом...

Julie16

Ну хорошо что ты признаешь что объектами(хоть в каком-то понимании) они являются.

Dasar

> То есть, мне для полного счастья надо ещё и знать ту "неабстракцию,"
> где это будет обсчитываться?
Если ты абстрактный теоретик, то да - знать не надо.
Если ты практик, то знать надо.
> Объект АТД вообще лежит вне парадигмы ООП,
> поскольку последняя не знает, что такое абстракция
> и чем последняя может быть полезна.
Ок, давай разделим понятие объект на два понятия:
1. Объект-ящик: объект-ящик - это что-то, что имеет состояние и умеет обрабатывать сообщения.
2. Объект-сущность: логическая абстракция. Имеет разные связи с другими объектами-сущностями (например, такие связи, как общее-частное, родитель<->ребенок, ресурс<->потребитель и т.д.)
Объект-ящик - используется при выполнении
Объект-сущность - используется при описании задачи.
> И мы не увидим внятного ответа, потому что ООП _не_способно_
> работать с несколькими равнозначными объектами.
Человек - это объект? Люди - это равнозначные объекты?
люди решают свои проблемы?
> > immutable объект - это все-таки не функция.
> А наоборот?
да, функция - это объект. immutable или нет - зависит от контекста.

Marinavo_0507

> И как это противоречит ОО?
Никак в общем-то.
Просто прелести ООП не используются.
И в этом треде пока не появилось примера, где бы на основе этих прелестей получался бы хороший дизайн.
Под прелестями я понимаю:
1) представления о том, что бывают объекты, к которым гвоздями прибиты свойства, определяющие их поведение;
2) наследование (к которому я не отношу реализацию абстрактного интерфейса).

Julie16

CL - примерно 1980 год
С++ - 1979 год. Вполне современные языки.

Julie16

Например string. У него есть очень удобные свойства - find, length.

Dasar

> тогда на каком основании знание способов умножения мы приписываем именно объекту c ?
приписываем или нет - это не важно, хотя приписывание позволяет ускорить выполнение (уменьшить время на обработку).
мы его только как крайнего просим выполнить операцию.
> в предметной области числа не умеют умножать себя на многочлены, это ОО-программист
> приписывает им такое умение, так как не может себе представить "просто умножение"
да, компилятор (не программист) может добавить такую операцию к числу - потому что такое добавление позволит уменьшить время обработки выражения.
Ps
особенно скорость обработки возрастает, если выражение появляется на этапе выполнения, а не на этапе компиляции.

Ivan8209

K> То есть, мне для полного счастья надо ещё и знать ту "неабстракцию,"
K> где это будет обсчитываться?
DG> Если ты практик, то знать надо.
За меня это сделает компилятор и сделает, к тому же, лучше.
Чисто практическое рассмотрение.
> Объект-ящик - используется при выполнении
> Объект-сущность - используется при описании задачи.
Опять искусственное разделение?
Зачем мне два разных объекта, когда можно обойтись одним
и с куда большим успехом?
>> И мы не увидим внятного ответа, потому что ООП _не_способно_
>> работать с несколькими равнозначными объектами.
> Человек - это объект?
Задача была описана выше --- подменяешь.
> да, функция - это объект. immutable или нет - зависит от контекста.
Увидим примитивы создания и изменения функций от ООП?
---
...Я работаю антинаучным аферистом...

Ivan8209

MacLisp (или откуда оно пошло думается мне, будет постарше.
---
...Я работаю антинаучным аферистом...

Julie16

В нем есть объекты? Не вижу никаких противоречий с моим утверждением.

Marinavo_0507

> У него есть очень удобные свойства - find, lenngs.
Нет, не у него есть. А их можно наблюдать.
Сколько бы методов ты бы ни определил, всегда можно добавить новые.
А почему? Потому что они не принадлежат строке, а возникают, когда программист о них подумает.
То есть, например, есть у нас стандартная библиотека, и в ней класс string,
а в нём метод find_substring, который находит вхождение подстроки.
Нормально, да?
А вот нам нужно искать не подстроку, а регулярное выражение.
Нужен метод find_re.
find_substring ничем не лучше, чем find_re, но его почему-то прибили гвоздями к string.
Нет никаких оснований полагать, что find_substring "принадлежит" строке, а find_re - не "принадлежит".
ФП предлагает взгляд, свободный от таких ложных отношений:
есть строки, и есть операции (над ними, или не только).

Ivan8209

g> в предметной области числа не умеют умножать себя на многочлены,
g> это ОО-программист приписывает им такое умение,
g> так как не может себе представить "просто умножение"
DG> да, компилятор (не программист) может добавить такую операцию к числу
Предметная область не находится в ведении компилятора.
---
...Я работаю антинаучным аферистом...

Julie16

А кто тебе мешает отнаследоваться и добавить такой метод? Для ФЯ твое утверждение переформулируется так: "Почему создатели библиотеки добавили функцию find_substring, но не добавили функцию find_re? Чем find_re хуже чем find_substring?" В общем это не аргумент.

Ivan8209

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

Julie16

Чего? Ты сам-то понял что сказал?

Marinavo_0507

> А кто тебе мешает отнаследоваться и добавить такой метод?
Объясняю.
Тогда у нас получатся "старые" строки, без нужного метода.
И "новые", с таковым.
И будет казаться, что это разные строки - у них ведь разные свойства.
А они одинаковые!

Julie16

Тогда заведи функцию, которая делает то что нужно. Это никак не противоречит ООП.

Dasar

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

Анализ
(от греч. análysis - разложение, расчленение процедура мысленного, а часто также и реального расчленения предмета (явления, процесса свойства предмета (предметов) или отношения между предметами на части (признаки, свойства, отношения);

> Задача была описана выше --- подменяешь.
Ты привел сильное утверждение - я тебе привел контрпример.
не было бы сильного высказывания - не было бы и этого контрпримера.
>> да, функция - это объект. immutable или нет - зависит от контекста
> Увидим примитивы создания и изменения функций от ООП?
зачем такое надо делать?
Функция - это частный случай операции.
Операции можно записывать/выполнять и другими способами.

Ivan8209

Прекрасно понял.
Для строк ("string") добавить сопоставление с рег. выражением добавить нельзя,
потому что оно не предусмотрено в определении объекта, надо наследоваться.
Последнее производится с образованием нового класса "новстрока,"
с которым уже можно творить, что нужно.
Теперь понятно, почему type inference ставит ООП в ступор.
---
...Я работаю антинаучным аферистом...

Julie16

Почему нельзя? Можно. Только не как метод.

Ivan8209

>> Зачем мне два разных объекта, когда можно обойтись одним
>> и с куда большим успехом
> Потому что такое разделение позволяет четче формулировать высказывания.
Каким образом?
>> Задача была описана выше --- подменяешь.
> Ты привел сильное утверждение - я тебе привел контрпример.
Ты подменил задачу из жизни каким-то построением,
не имеющим или имеющим мало отношения к действительности.
Повторяю: условия задачи изложены, решения от ООП не видно.
>>> да, функция - это объект. immutable или нет - зависит от контекста
>> Увидим примитивы создания и изменения функций от ООП?
> зачем такое надо делать?
То есть, это невозможно.
Q.E.D.
> Операции можно записывать/выполнять и другими способами.
Например, написать интерпретатор.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Ivan8209

Выход за пределы ООП.
Значит, последнее справиться с задачей не способно.
Q.E.D.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Dasar

> find_substring ничем не лучше, чем find_re, но его почему-то прибили гвоздями к string.
Откуда ты, вообще, взял, что в ООП что-то куда-то прибивается гвоздями?
ps
Ты не думаешь, что вот это высказывание в том числе и про тебя:

Из бедности мышления боевиков ООП растёт ограниченность средств ООП.

Julie16

Кто сказал что это выход за пределы ООП? Кто сказал что действия над объектами совершают только методы?

Ivan8209

А он не является фанат(ик)ом ООП.
А как существование функций, не являющихся методами,
соотносится с основной идеей ООП?
Вопрос про сложение чисел и умножение векторов-ковекторов остался без ответа.
Это так, напоминаю про UniversalMind.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Ivan8209

Тогда ты знаешь ответ на только что поставленный вопрос.
---
...Я работаю антинаучным аферистом...

Julie16

А как существование функций, не являющихся методами,
соотносится с основной идеей ООП?

Ты дурак или просто прикидываешься? Достало уже твое передергивание. Объект = инкапсулированные данные + функции обработки этих данных. Никто не говорит что эти функции должны быть инкапсулированы в объект. Хотя они могут.

Ivan8209

Тогда чем отличается "инкапсуляция" данных от обычного
сокрытия внутреннего строения в ходе абстрагирования?
---
...Я работаю антинаучным аферистом...

Julie16

Ничем. У тебя другое мнение? Какое?

bastii

Вот объясните мне, такому новичку в ФП, как я буду реализовывать полиморфизм на ФЯ в таком примере.
Есть http сервер, он там всякие запросы ловит и все такое. Пусть для примера, этот сервер взаимодействует с объектами, которые представляют собой страницы сайта. Сервер по определенной url знает какую выбрать страницу для формирования ответа. Считаем, что есть 3 типа объектов, Запрос, Ответ, Страница. У Страницы есть метод Ответить (в терминах Darkgray -- может принимать сообщения вида Ответить). На С# все это дело выглядит так:

public interface IRequest

{

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

// в этом примере не пользуемся

}



public interface IResponse

{

// ну тут тоже по идее до хрена чего нужно, но для примера только

  void WriteToBody(string text);

}



public interface IPage

{

  void FormResponse(IRequest request, IResponse response);

}

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

public class Page1 : IPage

{

  void IPage.FormResponse(IRequest request, IResponse response)

  {

    response.WriteToBody("This is Page1");

  }

}



public class Page2 : IPage

{

  void IPage.FormResponse(IRequest request, IResponse response)

  {

    response.WriteToBody("This is Page2");

  }

}

Как что-то похожее сделать в ФЯ без ООП?

Julie16

Я так понимаю что в ФЯ нет полиморфизма. Так как нет объектов.

Dasar

> Каким образом?
На этапе компиляции - оперирование происходит в виде объектов-сущностей.
например, так:

class Number;



class Polynom;



[Symmetry]

operation Polynom *(Number, Polynom);

Соответственно - это даст такие объекты-ящики:

class Number

{

   Polynom Mul(Polynom);

}

class Polynom

{

   Polynom Mul(Number);

}

class Mul

{

   Polynom Mul (Polynom, Number);

   Polynom Mul (Number, Polynom);

}

bastii

Я так понимаю что в ФЯ нет полиморфизма. Так как нет объектов.

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

Julie16

PS:

-- У нас такого вопроса уже нет, - сказал Паламидов.
-- Как же может не быть еврейского вопроса? - удивился
Хирам.
-- Нету, Не существует.
Мистер Бурман взволновался. Всю жизнь он писал в своей
газете статьи по еврейскому вопросу, и расстаться с этим
вопросом ему было бы больно.
-- Но ведь в России есть евреи? - сказал он осторожно.
-- Есть, -- ответил Паламидов.
-- Значит, есть и вопрос?
-- Нет. Евреи есть, а вопроса нету.

Dasar

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

Ivan8209

Опиши задачу на русском языке.
В том виде, как она описана, решается она так:

val al = [(url1, page1 (url2, page2)];

fun select al url = rassoc al url;

fun http socket = write socket  (select al extract_url(read socket;

Программисту остаётся только впихать свои страницы в ассоциативный список al.
Предоставить доступ к последнему --- не вопрос.
---
...Я работаю антинаучным аферистом...

Ivan8209

Это опять на псевдокоде?
---
...Я работаю антинаучным аферистом...

bastii

а что такое page1? функция?

Ivan8209

> функция - это что-то атомарное
Кто тебе такое сказал?
> зачем менять атомарные вещи?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Ivan8209

Объект АТД.
Можно сделать и функцией.
---
...Я работаю антинаучным аферистом...

bastii

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

Dasar

Если нет объектов и есть динамический полиморфизм, то какой код при этом генерит ФЯ?

Dasar

> Это опять на псевдокоде?
Зачем псевдокод? это M#

Ivan8209

Во write.
Там уже написано с двумя страницами.

val page1="This is page ";

val page2="This is page ";

Если страницы являются простыми строковыми данными.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Откуда ты, вообще, взял, что в ООП что-то куда-то прибивается гвоздями?
Потому что при описании класса (вариант: при создании объекта) указываются некоторые свойства.
И считаются, что они у объекта "есть".
А остальных, необъявленных, считается, что "нет".

Julie16

Кем считается? Не говори за всех

Ivan8209

Что оно будет делать, если умножение некоммутативно?
---
...Я работаю антинаучным аферистом...

Marinavo_0507

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

Marinavo_0507

> Кем считается?
Языком.
string->find_substring он понимает
а string->find_re не понимает
И программистом, если он мыслит так же.

bastii

Предположу, что в ФЯ ф-я тоже значение, и есть ф-я eval, что можно eval(func, params только в ФЯ для этого есть синтаксис симпатичный. Это будет соответствовать params->func в ООП.

Julie16

Бред. Я еще раз повторяю: функции по обработке данных не обязаны быть инкапсулированы в эти данные. Для вызова разных функций есть разный сиснтаксис. Что в этом такого?

Marinavo_0507

> Что в этом такого?
Для похожих функций почему-то вводится разный синтаксис.
Надо писать s->find_substring(s1 но find_re(s, s1).
Можно не инкапсулировать эти функции. Тогда получится ФП.

Ivan8209

Предположение далеко от истины.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Julie16

А в FP нельзя инкапсулировать функции в данные? Например засунуть функцию в список?

Ivan8209

Можно.
Это и есть упоминавшееся ОО для инвалидов, не понимающих ФП.
---
...Я работаю антинаучным аферистом...

Dasar

> И считаются, что они у объекта "есть".
> А остальных, необъявленных, считается, что "нет".
Кем считается? Кто считает?

Из бедности мышления боевиков ООП растёт ограниченность средств ООП.

Marinavo_0507

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

Dasar

> Что оно будет делать, если умножение некоммутативно?
ничего делать не будет.
выдаст ошибку.

Julie16

Да я в общем так и думал. Тогда для меня ООП = ФП. С разными уклонами.

Ivan8209

От вас, кстати, не дождались объяснения, что нового и полезного
несёт ОО по сравнению с АТД.
---
...Я работаю антинаучным аферистом...

Julie16

Что характерно, в другую структуру можно засунуть эту же строку, но с другой функцией.
И синтаксис вызова не поменяется при этом.

Это не отличие ФП от ООП. Это отличие динамической системы типов от статической. Не интересует.

bastii

Ага, тогда мне интересно, как будет выглядеть page3, которая печатает целые числа в цикле от 1 до 10?

Ivan8209

Тогда показывай, как будешь обходить.
Напоминаю: произведение на векторах-ковекторах некоммутативно.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

Тогда почему ты решил, что какие-то функции должны быть привязаны к любой строке?
Это проявление ОО-мышления: "у нас есть гвозди, давайте ими что-нибудь прибьём".

Ivan8209

val page3 = string (iota 10);
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Это не отличие ФП от ООП. Это отличие динамической системы типов от статической.
Враньё. От системы типов не зависит.

lera98

В ответ на сообщение

Отлично! Возвращаясь к единственному возражению против ООП не в стиле "а нах надо?" (моему) (на которое все забили почему-то): А как ты гарантируешь отсутствие цикла в своём графе соединений (то есть реентранси)?

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

bastii

Нет, ничего не понимаю, что ты пишешь, иду ботать ФП.

Ivan8209

Перевожу на русский.
Из-за ОО-мышления возникает трудная задача,
которая в ином случае никогда не возникла бы.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Julie16

Лично мне нравится запись ->. Больше нет никаких причин. И для реализации полиморфизма необходима инкапсуляция методов.

Julie16

Ышо как зависит. Какой тип у элемента списка в твоем случае?

lera98

> Из-за ОО-мышления возникает трудная задача,
> которая в ином случае никогда не возникла бы.
Эта задача возникает не из-за "ОО-мышления". Такая же задача возникает и в ФП в случае callback-функций.
ЗЫ: ты уж дай определение этого термина - "ОО-мышление". Я мыслю "по-человечески | по русски | по сишному".

Ivan8209

Не слышал, чтобы "call-back" были так приняты в ФП.
---
...Я работаю антинаучным аферистом...

lera98

> Нет, ничего не понимаю, что ты пишешь, иду ботать ФП.
, на всякий повторюсь: под объектом я понимаю гораздо более широкую сущность. К примеру, инструкция асма INC EAX тоже является объектом. Теперь более понятно?

Marinavo_0507

> Лично мне нравится запись ->.
Однако писать s->find_re(s1) нельзя.
> И для реализации полиморфизма необходима инкапсуляция методов.
Есть другие способы. Можно например, инкапсулировать объект в операцию.
Пока в этом треде не было приведено примеров, когда полезен именно такой полиморфизм.
Не то что бы таких примеров нет. Просто их гораздо меньше, чем привык считать всё-есть-объектный программист.

Marinavo_0507

> Какой тип у элемента списка в твоем случае?
Это зависит от системы типов языка.

lera98

> Не слышал, чтобы "call-back" были так приняты в ФП.
Всяко бывает... Например
f1 calls f2
f2 calls f3
f3 calls f2
f2 calls f3
f3 calls f1
...
Прикинь, какая цикловая "ересь" может получаться при соответствующей реализации функций? Особенно за ними не углядишь, когда их - тысячи...

Julie16

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

Ivan8209

Взаимная рекурсия разрешается обычным образом.
Если функции нечистые, то мне об этом, думаю, сообщат.
---
...Я работаю антинаучным аферистом...

Julie16

1) Нельзя. А мне и не нужно. Просто если так можно писать - почему нет? Это красиво, в конце-концов
2) Есть и другие способы. Я не спорю. Но почему нельзя как я предложил?

lera98

> Взаимная рекурсия разрешается обычным образом.
"...отсутствие цикла в своём графе соединений (то есть реентранси)..." тоже решается известными способами, не надо из этого слона делать.
> Если функции нечистые, то мне об этом, думаю, сообщат.
Нормальному ФЯ должно быть абсолютно всё равно, по какому адресу ты передаёшь управление и не поломал ли ты при этом стэк.

lera98

Кстати, вот жестокий пример по поводу взаимной рекурсии:
Имеются библиотека Б.
В ней находится множество функций.
Часть функций может вызывать функции из Б. (в т.ч. саму себя)
Изначально неизвестно, кто кого будет вызывать, потому как адреса переходов определяются и динамически изменяются в рунтайме.
Тут бедняга компилер (но только не Сишный) либо скажет "я тупой и так не умею" или пискнет "боюсь!" и ничего вразумительного не посоветует.

Ivan8209

Да, но тебе это приходится делать руками,
тогда как за меня это сделает компилятор.
А хороший ФЯ стек не поломает.
---
...Я работаю антинаучным аферистом...

Ivan8209

Функции, в подавляющем большинстве случаев, повторно входимы.
---
...Я работаю антинаучным аферистом...

lera98

> Да, но тебе это приходится делать руками, тогда как за меня это сделает компилятор.
Что ты имеешь ввиду по "делать руками"? Я имею ввиду чистый сишный код без асма. И в асм всё за меня соберёт компилятор. Сложно понять, что ты хотел сказать.
А запостил я этот пример, чтоб показать тебе, что проблема циклов может существовать и в ООП, и в ФП.

Ivan8209

Под "делать руками" я подразумеваю "делать руками."
И ничего больше.
Почти всё, связанное с повторной входимостью, за меня сделает компилятор.
Там, где возникнут трудности, мне подскажут, что они возникли.
Сишный компилятор с последним не справится.
Это к тому, что в ФП проблемы циклов --- не существует.
---
...Я работаю антинаучным аферистом...

enochka1145

Что, ФП-компиляторы сами делают циклы из рекурсий? Или оставляют всё в виде рекурсий?

Ivan8209

Делают.
Прикинь, да?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

lera98

> Почти всё, связанное с повторной входимостью, за меня сделает компилятор.
Какой компилятор? Что он умеет?
> Там, где возникнут трудности, мне подскажут, что они возникли.
При грамотном подходе сторонние подсказки не требуются.
> Сишный компилятор с последним не справится.
ИМХО ты только слышал о Си, но не оценивал его возможности.
> Это к тому, что в ФП проблемы циклов --- не существует.
Я пример привёл с проблемой циклических вызовов? Разве не на ФП? Тогда это твоё утверждение ложно, и не понятно, зачем его было высказывать.

lera98

> Что, ФП-компиляторы сами делают циклы из рекурсий? Или оставляют всё в виде рекурсий?
Это не компилеры, они не сами и не виноваты. Это программеры

enochka1145

А откуда ты знаешь, что делают?
Ссылка есть?

Ivan8209

>> Почти всё, связанное с повторной входимостью, за меня сделает компилятор.
> Какой компилятор? Что он умеет?
Любой ФЯ.
Преобразовывать рекурсию в циклы не научились только совсем ленивые.
Все ML умеют ещё type inference и много чего.
MLton умеет ещё оптимизировать всю программу целиком.
>> Там, где возникнут трудности, мне подскажут, что они возникли.
> При грамотном подходе сторонние подсказки не требуются.
"При грамотном подходе" означает ручную работу писателя?
>> Сишный компилятор с последним не справится.
> ИМХО ты только слышал о Си, но не оценивал его возможности.
Сишный компилятор почти ни с чем не справляется.
>> Это к тому, что в ФП проблемы циклов --- не существует.
> Я пример привёл с проблемой циклических вызовов?
Нет.
Проблемы нет.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Ivan8209

1. RnRS
2. CLtL
3. caml.inria.fr
4. mlton.org
Ещё?
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

lera98

Не понял, как это не привёл? А "жестокий пример по поводу взаимной рекурсии"?
> Преобразовывать рекурсию в циклы не научились только совсем ленивые.
Обычную - да.
Невозможно и бессмысленно преобразовывать список действий в цикл, если действия не повторяются. Тем более, если следующее действие сложным образом зависит от предыдущих.
Ещё раз спрошу: мой пример - это пример ФП? Нет? - аргументируй. Да - та самая проблема _существует_.
___________________________________________________
> Сишный компилятор почти ни с чем не справляется.
Ты действительно не умеешь писать на сях.

Ivan8209

Проблема-то где?
Да там хоть что пусть будет, даже если это Лисп --- переварится.
А если это что-то типизированное, то большая часть ошибок,
если это ошибки, отловится при компиляции.
Там, где это не может быть циклом, оно и не будет.
Но и рекурсия вполне развернётся насколько такое возможно.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

lera98

список действий в цикл ... - я имел ввиду цикл в обычном понимании этого термина. Типа
1 Инит
2 Тело
3 Условие? переход на 2
4 Конец
В поднятой проблеме понимание смысл этого слова другой - передача управления коду, который перед этим уже выполнялся.

Ivan8209

Никаких трудностей нет.
---
"Расширь своё сознание!"

Marinavo_0507

> Нельзя. А мне и не нужно. Просто если так можно писать - почему нет?
Так вот оказывается, что в общем случае нельзя.
> Есть и другие способы. Я не спорю. Но почему нельзя как я предложил?
Потому что это ведёт к появлению в дизайне программы лишнего отношения принадлежности.
Что есть неоправданное усложнение дизайна.
В правильном дизайне не будет лишних отношений и сущностей.
> Если я могу одновременно в список запихнуть и функцию и не функцию, это уже не статическая типизация.
Правильно. В языке со статической типизацией придётся делать по-другому, например
* использовать не списки, а скажем структуры
* запихивать в список не прямо объекты, а оборачивать их вариантным типом.

lera98

Тогда на том и остановимся - никаких трудностей с циклами и "циклами" ни в ФП, ни в ООП нет.

Ivan8209

В ООП --- есть, см. сообщение .
А вот в ФП --- нет.
Ты не показал, где проблема.
---
"Я знаю правду! Все прежние правды --- прочь!"

lera98

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

Ivan8209

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

Marinavo_0507

> CL - примерно 1980 год
> С++ - 1979 год. Вполне современные языки.
У того С++ не было шаблонов (средств метапрограммирования не было исключений, не помню ещё чего.
О средствах для функционального программирования (типа делегатов, введённых Microsoft в MC++) вообще никто
не помышлял.
У CL уже было всё и многое другое.
Все "новые" навороты "современных" языков реализуются в CL на макросах, без изменения ядра языка,
в виде простой библиотеки, в том числе и ОО-надстройка.

lera98

"наполовину" - это точно, т.к. типы функций могут быть идентичны.
У ООП нет проблем с "двойными уничтожениями" (или с реентранс это проблема реализации задачи у . Конкретно - функции ObjectManager.Remove .
"Реентранс" - такая же неотъемлемая часть ООП, как и обычная взаиморекурсия в ФП. Это - _НЕ_ _проблема_, а мощный _инструмент_ ОО программирования, который нужно использовать в исключительных случаях при необходимости.

lera98

> Все "новые" навороты "современных" языков реализуются в CL на макросах, без изменения
> ядра языка, в виде простой библиотеки, в том числе и ОО-надстройка.
Надеюсь, использование макросов не приводит к удвоеннному по размеру exe и удвоенной тормознутости, по сравнению с аналогичным по функциональности Си- или Асм-кодом.

Marinavo_0507

А причём тут Cи и прочие ассемблеры? Я сравниваю с современными "навороченными" языками: C#, Java, MC++.

Ivan8209

ООП эту задачу вообще не решает, судя по "(disk+text).format" и т. п. от .
Показывай, в чём ошибка Fj.
Почему решение задачи приводит к появлению лишних сущностей,
наподобие "damage"?
---
...Я работаю антинаучным аферистом...

lera98

Надо писать её (ф-ю ObjectManager.Remove так, чтоб безглючно работала следующая конструкция:

        object targ;

        if (null != targ = Radar.HitTest(this

        {

            IDamageReceiver targ;

            if (null != targ as IDamageReceiver)

            {

                targ.Hit(this as IDamageDealer);

            }

            ObjectManager.Remove(this);

            ObjectManager.Remove(this);

            ObjectManager.Remove(this);

            ObjectManager.Remove(123456);

            ObjectManager.Remove(NULL);

        }

 

lera98

Это - проблемы класса ObjectManager и/или его предков.

lera98

И вообще лучше мутить объекты с полем "Статус", а лучше^2 - с очередями сообщений (от других объектов).

Dasar

> О средствах для функционального программирования (типа делегатов, введённых Microsoft в MC++) вообще никто не помышлял.
mem_fun-ы, bind-ы и т.д. в С++, вроде, давно появились.

Ivan8209

А кто это?
"UniversalMind"?
---
...Я работаю антинаучным аферистом...

Ivan8209

> а лучше^2 - с очередями сообщений (от других объектов).
То есть, надо руками выполнять работу компилятора?
---
...Я работаю антинаучным аферистом...

Marinavo_0507

Без lexical scoping и без автоматического управления памятью?

lera98

> То есть, надо руками выполнять работу компилятора?
> Без lexical scoping и без автоматического управления памятью?
Scoping в Сях достаточный, памятью управлять - пару функций надо.
Чем "умнее" компилятор, тем он менее универсальный (тем он тупее).
Настоящая программа начинается с гордого main (WinMain, "Lin"Main и т.п) !

Marinavo_0507

*plonk*

lera98

>> а лучше^2 - с очередями сообщений (от других объектов).
>То есть, надо руками выполнять работу компилятора?
Я уже успешно делал подобное - реализацию собственной очереди сообщений с конкретной, сквозной проверочной, up-broadcast и down-broadcast доставкой сообщений. Кода всего около пары сотен строк с красивыми комментариями. Нечего таких проблем пугаться. Наоборот рулез, когда всё своё.

lera98

*ля, лингву влом ставить чтоб посмотреть, что значит "plonk".

kamputer

>*ля, лингву влом ставить чтоб посмотреть, что значит "plonk".

сущ.
дешевое вино, вино плохого качества

lera98

Ясно. Ну не мой это стиль - валить заботы на язык и компилер. Я сам.
(ЗЫ: если меня хотели обидеть - мне пох.)

Ivan8209

Я понимаю, что есть такое развлечение --- писать постоянно
управление памятью, односвязные списки и т. п.
Пиши.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

lera98

> Я понимаю, что есть такое развлечение --- писать постоянно
> управление памятью, односвязные списки и т. п.
> Пиши.
Мне не в тягость две строчки написать: "дай память", "освободи память" - ты об этом?
Если мне что надо часто, я ввиде отдельного модуля cpp оформляю код или компилю ввиде dll. Постоянно одно и то же я не пишу.

Ivan8209

100 раз по две строчки --- это получается 200 строк.
Ты не работал, очевидно, с теми задачами, когда
следить за временем, когда можно сказать "освободи память".
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

lera98

Чуть более по-русски напиши?...

Marinavo_0507

Грубо говоря, так:

let page1 _ = "This is page 1"



let page2 params =

  let n = CGI.get_param_int params "N" in

  let nums = upto 1 n in

  let strings = map int_to_string nums in

  let result = concat " " strings in

    ("This is page 2: " ^ result)



let pages = 

  Server.make (* переведём список в эффективное представление: дерево или хеш-таблицу *)

    [("page1", page1); ("page2", page2); ]



let process_request pages client uri =

  let page_name = CGI.get_base_name uri 

  and params = CGI.decode_params uri 

  in

  let page = Server.get_page pages page_name in

  let result = page params in

    Server.put_result client result



Server.mainloop (process_request pages)

lera98

это на каком жаргоне русского?
ЗЫ: я не пример просил привести. Особенно на языке программирования.

Ivan8209

В ходе правок утеряно слово "надо."
Когда решение занимает одну строку, явное выписывание
"дай память, освободи память" увеличивает код втрое-впятеро.
Если не больше.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike

Dasar

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

Ivan8209

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

bleyman

У ООП нет проблем с "двойными уничтожениями" (или с реентранс)

Reentrancy != двойное уничтожение. Двойное уничтожение - одно из следствий реентранси. Проблема реентранси - это когда

if (this.flag)

{

   someObject.SomeMethod;

   Console.WriteLine(this.flag);

}

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

"Реентранс" - такая же неотъемлемая часть ООП

Ты неправильно понял что такое Reentrancy, видимо. Потому что я ещё ни разу не видел случая Reentrancy в ООП, от которого меня не начало бы плющить.
По поводу очередей сообщений - покажи, пожалуйста, как ты на мессагах сделаешь вызов функции с возвращаемым значением (+определишь, поддерживается ли она вообще (+ таки проверишь, что ничего страшного в процессе вызова не произошло. Я делал, возможно я плохо делал, возможно можно сделать более понятно, но то, что у меня получилось, было полным говном. На основе чего я заключил, что эта система не применима в реальной жизни, по крайней мере в чистом виде. Хотя винда вот работает как-то...
Да, это очень прикольно бывает написать своё выделение памяти. Чувствуешь себя неебаццо хацкером. По мере накопления опыта внезапно обнаруживается, что все эти самописные операторы new оказались абсолютно бесполезными в смысле применимости. Хотя бесценный опыт, и всё такое, это да.
2Контра - на самом деле введение дополнительной сущности Damage в моём примере было более чем оправдано, а проблема состоит в том, что _необходимость_ введения этой сущности ловко маскируется.

Julie16

все эти самописные операторы new оказались абсолютно бесполезными в смысле применимости.

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

Marinavo_0507

> Да, это очень прикольно бывает написать своё выделение памяти. Чувствуешь себя неебаццо хацкером. По мере накопления опыта внезапно обнаруживается,
> что все эти самописные операторы new оказались абсолютно бесполезными в смысле применимости. Хотя бесценный опыт, и всё такое, это да.
В ядре ОС без различных специальных аллокаторов - никак.
Но только вот переопределением operator new не обойтись: всё сложнее.

Marinavo_0507

> Мне в свое время пришлось написать аллокатор для маленьких объектов. Работал он в разы быстрее чем стандартный.
Я как-то замерил производительность glibc'шного malloc для маленьких объектов.
Получилась какая-то неебически большая величина.
Оверхед незаметен на фоне любых реальных действий с этими объектами.

Julie16

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

lera98

> Когда решение занимает одну строку, явное выписывание
> "дай память, освободи память" увеличивает код втрое-впятеро.
> Если не больше.
( Решение в одну строку - вырожденное решение, почти инкапсуляция. Это не есть хорошо.)
Как это ты так посчитал - "3-5, если не больше"? Странно...
Вот кое какие проценты кол-ва строк кода (Си) по типам:
- в одной из dll, обеспечивающей работу с многолиственными деревьями (без учёта хэдера):
33% - комментарии, пустые и безоператорные строки (типа "{" )
03% - директивы препроцессора
03% - объявления без инициализации (функций, переменных, структов, классов)
10% - работа с динамической памятью
50% - другие рабочие строки *
- класс cControl, cpp и h ( в т.ч там реализация очереди сообщений ):
29% - комментарии, пустые и безоператорные строки (типа "{" )
06% - директивы препроцессора
19% - объявления без инициализации (функций, переменных, структов, классов)
14% - работа с динамической с памятью
32% - другие рабочие строки *
* - код, смысл которого только работа с памятью (выделение, освобождение, "втыкание" элемента в массив и т.п.)

Ivan8209

"Решение в одну строку <...> Это не есть хорошо."
Кто тебе такое сказал?
Наоборот: решение в одну строку --- лучшее решение, которое
можно придумать.
> Как это ты так посчитал - "3-5, если не больше"? Странно...
Видимо, потому что я пишу не на Си:

(define (shorten step) (map (fn (x) (/ x 10 step

Объяснишь, зачем мне нужен здесь комментарий?
А выделение памяти под итог?
У меня определений длиннее 5 строк нет.
Это насчёт читаемости.
---
"Расширь своё сознание!"

lera98

я знаю, что такое reentrancy. И утверждаю: "Реентранс" - такая же неотъемлемая часть ООП. Нужно _чётко_ представлять себе граф связей (внешних и внутриобъектных). Тогда глюков не будет.
> ... как ты на мессагах сделаешь вызов функции с возвращаемым значением?..
Объект А фызывает ф-ю объекта Б:
- А посылает Б мессагу "что вызвать, параметры"
- если А нужен ответ прям щас, то А ждёт
- Б принимает, думает.
- Б посылает ответ А (варианты: "такое не знаю, не умею", "параметр Х стрёмный", "результ")
- А счастлив ;

Papazyan

Некоторые тут сомневаются в способности компиляторов ФЯ преобразовать рекурсию в циклы. Я на днях написал на OCaml обход дерева в Contunuation Passing стиле и случайно забыл удалить запомненное продолжение из списка. Программа ясен пень зациклилась, но OCaml не упал. Значит он рюхнул, что реально CPS функции значения не возвращают.

lera98

> решение в одну строку --- лучшее решение, которое можно придумать.
Я об этом:

int f1(int x){

   return x*1+1+0-1;// code...

}



int f2(int x){

   return f1(x);

}



int f3(int x){

   return f2(x);

}

Это - не есть хорошо, или кто-то не согласен?

Ivan8209

Да, это не есть хорошо.
Потому что то же самое, но записанное в три строки вместо
одиннадцати, проще читается, что влечёт лёгкое обнаружение двух
лишних сущностей и сокращение объёма кода в одиннадцать(!) раз.
---
"Курс истинно физической химии"
Ломоносов

lera98

Стопудово )

lera98

Мож пора итоги подводить по теме "почему ООП - плохо"?
Вроде вопросы по проблемам ООП кончились.
Кстати, если кто до сих пор считает, что ООП не есть рулез - открывать крышку системника, смотреть на девайсы и втыкать! Особенно ОО видно на маме.

Ivan8209

Боюсь тебя огорчить, но электроника имеет
куда меньше отношения к ООП.
---
...Я работаю антинаучным аферистом...

lera98

Контра, заквоть плз классическое определение ООП.
ЗЫ:
Раскрывай термин ООП как Объектно-Ориентированный Подход.
ОО Программирование - частный случай ООП.
И ещё в частном случае, повторюсь, INC EAX - тоже можно рассматривать как Объект.
Можно отдельно: Объект (команда) INC и Объект (регистр) EAX.
Используя такую трактовку, любой Ф код можно представить как ОО код. Причём, вероятнее всего, некрасивый ОО код.

Ivan8209

> Причём, вероятнее всего, некрасивый ОО код.
А другого не бывает.
---
...Я работаю антинаучным аферистом...

lera98

>> Причём, вероятнее всего, некрасивый ОО код.
> А другого не бывает.
В серьёзном разговоре несмешная шутка.

Ivan8209

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

Dasar

Критерии красивого кода в студию

Ivan8209

Хотя бы --- решать простейшие задачи в одну строку.
---
...Я работаю антинаучным аферистом...

Dasar

> Хотя бы --- решать простейшие задачи в одну строку.
Я правильно понимаю, что ты считаешь, что regexp-ы - это самый красивый код?
а также читабельный, и уменьшающий потенциальные ошибки?

lera98

Гы ) боевики.. Ты там воевать чтоль собрался?
--------
>Критерии красивого кода в студию?
Красивый ≈ такой, чтоб другому программисту всё стало понятно за малый промежуток времени. Что, зачем, почему так, и т.п.

Ivan8209

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

lera98

А что нам скажет боец ?

enochka1145

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

lera98

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

enochka1145

Вроде же видно - [re:КОНТРА]

Ivan8209

Если бы ООП действительно работало, то решение известной задачи
с двумя физическими величинами давно было бы известно.
Однако, этого не случилось.
Этой задаче уже не один год, и даже не пять лет.
И до сих пор никто не привёл решения.
---
...Я работаю антинаучным аферистом...

lera98

мож не стоит так грубо к Контре? Жаль его конечно.
Контра, красивого кода от тебя я тоже не видел.

lera98

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

Ivan8209

Условие полностью изложено выше.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek

Dasar

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

listBox.DataSource = root.Entities.Select(_.By("Name", "Child".Apply(_.Get("Target/Id";

enochka1145

Разберём сообщение типичного манипулятора сознанием - потенциального политика.
> Если бы ООП действительно работало...
Хорошее начало.
> ...то решение известной задачи с двумя физическими величинами...
Известной кому? Тут, похоже, полагается склониться перед авторитетом этого научного светила.
> ...давно было бы известно.
О как! ООП, видать, не для прояснения архитектуры, реализации и поддержки. ООП для решения задач.
> Однако, этого не случилось.
А-а, ну всё ясно. ООП действительно [нигде] не работает, как же это я сразу не сообразил...

Ivan8209

listBox.DataSource = root.Entities.Select(_.By("Name","Child".

Как видим, в одну строку оно не поместилось.
---
...Я работаю антинаучным аферистом...

enochka1145

Что поделать, не люблю тупое высокомерие фанатиков от науки.
Про два объекта ему уже давно растолковали:

matrix_n_m = new matrix(matrix_n_k, matrix_k_m);

lera98

Контра! Будь человеком!
( Хуль ты ерунду пишешь, правильный пример привёл )

Ivan8209

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

Ivan8209

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

enochka1145

> Про архитектуру, реализацию и поддержку.
> А на кой ляд они нужны?
М-да...
Этому, наверно, только жизнь может научить.

Ivan8209

Открой любую книгу и посчитай число знаков в строке.
---
"Расширь своё сознание!"

lera98

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

Marinavo_0507

Listbox.from_dataSource  (let e = root.entities in let s = select (by "Name" "Child") e in get_something "Target/ID" s)

Правда, такие длинные строки трудно читать.

enochka1145

Dear ,
ООП не может ничего решить, просто потому, что это не Решатель. Это подход, который позволяет элегантно спроектировать, запрограммировать, а затем долгое время улучшать реализацию решения данной задачи. Точнее, достаточно широкого класса задач. Только и всего.

Ivan8209

Ну-ну.
Учись поддерживать свою ОО архитектуру.
При таких объёмах кода, неудивительно, что придаётся
большое значение поддержке архитектуры.
Когда увидишь такие нагромождения, только диву даёшься.
Я тут общался с перловщиком, который постоянно пытался
написать что-то невообразимое для решения какой-нибудь
простейшей задачи, прозрачно решающейся за один проход
трёхступенчатым конвейером.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek

Ivan8209

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

enochka1145

Пора переименовать тред в "[Сказка про белого бычка] Почему ООП - это плохо?"

lera98

> Dear ,
Не будете ли вы столь любезны в дальнейшем не употреблять подобных по изысканности обращений к моей персоне?
( Какой нах dear? )
> ООП не может ничего решить, просто потому, что это не Решатель.
> Это подход, который позволяет элегантно спроектировать,
> запрограммировать, а затем долгое время улучшать реализацию
> решения данной задачи. Точнее, достаточно широкого класса задач.
> Только и всего.
Спроектировать объекты, запрограммировать объекты - это этапы ООП решения.

lera98

Не заморачиваясь на защиту от хренового использования объектов..
И не заморачиваясь на лучшесть решения..
Получаем что-то типа этого:
(могут быть ошибки)

class TypesArray{

public:

   struct{

      int Type; // ИД типа

      int Exp;  // степень

   } *Array;

   int Count;

   TypesArray;

   TypesArray(int SingleType);

};



class TypesDefiningArray{

public:

   struct{

      int Type; // этот тип =

      TypesArray Types;// комбинация этих типов

   } *Array;

   int Count;

   TypesDefiningArray;

};



class PhysObj{

public:

   double Value;

   TypesArray Types;

   PhysObj(double value, TypesArray type);

};



class Phys{

private:

   IntArray KnownTypes;

   IntArray BasicTypes;

   TypesDefiningArray TypesDefinings;

protected:

   bool MakeTypesEasier(TypesArray Types);

   bool ConvertToDefaultTypes(TypesArray Types);

public:

   Phys;

   TypesArray * SummarizeTypes(TypesArray *a, TypesArray *b);

   PhysObj * Multiply (PhysObj *a, PhysObj *b);

};



//--------------------implement

Phys *ph=new Phys;

PhysObj *a, *b, *c;



Init{

   a=new PhysObj(1.5, TI_MASS);

   b=new PhysObj(9.8, TI_ACCEL);

   c=ph->Multiply(a,b);

}



PhysObj * Phys::Multiply (PhysObj *a, PhysObj *b){

   PhysObj *ret=new PhysObj;

   ret->Value = a->Value * b->Value;

   ret->Types = SummarizeTypes(a, b);

   return ret;

}

Ivan8209

Много понаписал, но дошёл только до "MakeTypesEasier."

   a=new PhysObj(1.5, TI_MASS);

   b=new PhysObj(9.8, TI_ACCEL);

   c=ph->Multiply(a,b);

Почему это три строки, а не одна?
Можно добиться записи наподобие такой: "(1.5*kg)*g".
И что это за сущность такая "ph"?
Так сегодня называется "UniversalMind"?
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Можно добиться записи наподобие такой: "(1.5*kg)*g".
Как раз такого легко добиться на C++
Без ООП.

Ivan8209

Я знаю.
Но последнее запрещено условием задачи.
---
...Я работаю антинаучным аферистом...

lera98

> Почему это три строки, а не одна?
Можно и одной (объекты коряво написаны, работать будет херово)
c=ph->Multiply(PhysObj(1.5, TI_MASS PhysObj(9.8, TI_ACCEL;
> Можно добиться записи наподобие такой: "(1.5*kg)*g".
Надо сделать объекты, основанные на работе со строками.
> И что это за сущность такая "ph"?
"ph" - экземпляр физики. : ) Прикольно? (Класс физики очень обкацаный, вощем альфа-версия.) Физик может быть много, у каждой свои законы, свои размерности величин и др. В большинстве случаев хватит одного экземпляра этого класса.

enochka1145

А чем плохо

c = Tensors.Multiply(a,b);

где Tensors - класс-тензормен, или

c = Tensor.Multiply(a,b);

где Multiply - статический метод класса Tensor для создания нового тензора из двух имеющихся?

Marinavo_0507

Это, в общем, довольно не плохо.
В частности, потому что не ООП.
(Если меня часто спрашивать одно и то же, мне быстро надоедает повторять)

Ivan8209

> c=ph->Multiply(PhysObj(1.5, TI_MASS PhysObj(9.8, TI_ACCEL;
Отлично, ещё чуть-чуть до ФП осталось.
> Надо сделать объекты, основанные на работе со строками?
Зачем?
Нельзя доопределить умножение, чтобы оно понимало
"real * mass -> mass"?
> "ph" - экземпляр физики.
Накой чёрт мне ещё одна физика?
Физика одна на всех и другой нет.
А самое главное, что её нет в предметной области.
В общем, ты тоже завёл лишнюю сущность.
Спрашивается, зачем?
---
...Я работаю антинаучным аферистом...

lera98

Классическое определение ООП в студию.

Ivan8209

"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
---
...Я работаю антинаучным аферистом...

enochka1145

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

Да уж, источники "ОБС News" и "ОБС Consulting" - самое то для серьёзного учёного.

Ivan8209

Я знаю ещё пару перловщиков, и у всех такие же устремления.
Судя по тому, что лежит в Большой Помойке,
другие от них не особо-то отличаются.
---
"Всё наше знание происходит из опыта."
Франсуа Ларошфуко

lera98

> Физика одна на всех и другой нет.
Щас, "нет"! Есть. Разные модели физики описываются разными объектами - экземплярами. Кроме того, я могу выдумать несуществующую физику, никоим боком не связанную с реальной. Класс физики и экземпляр его - не лишнее.
> Нельзя доопределить умножение, чтобы оно понимало
> "real * mass -> mass".
Про "operator *" забудь. А операция умножения физ.величины на ф.в. мной не ДОопределяется, а определяется.

enochka1145

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

Ivan8209

Иди, подучи методологию науки.
В любом случае, необходимости ph из условия задачи не следует,
так что ты:
а) выполнил лишнюю работу, введя лишнюю сущность;
б) загромоздил запись своими "ph->", ухудшив читаемость.
Задачу от -а ты будешь решать эмулируя процессор?
Да без разницы, "доопределяется" или "определяется".
Почему ты её не определил?
ООП помешало?
---
"Про эмуляторы и прочие садо-мазо атрибуты мы помним."

Ivan8209

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

lera98

> Иди, подучи методологию науки.
Возможно, твоё мышление закостенело, раз ты не можешь представить себе несколько физ.моделей или несколько разных физик. Не останавливайся в развитии по любому направлению и не ставь рамки. Всё бывает, и всё возможно.
> ...необходимости ph из условия задачи не следует...
Это моё решение. Оно несовершенно, я знаю. Можно сделать лучше. Но я решил на ООП эту задачу.
> Да без разницы, "доопределяется" или "определяется".
Разница есть существенная. Приставка "до" отнюдь не бессмысленна.
> Почему ты её не определил?
Определил в классе физики.
> ООП помешало?
Порядком надоевшая реплика.

Ivan8209

Ещё раз, физическая модель и физика --- это две очень и очень
большие разницы. В данном случае, есть только одна модель.
Ты её взял и не только обозвал, но ещё и ввёл как отдельную
сущность.
Этим ты нарушил общенаучный принцип экономии мышления.
Это, во-первых.
Во-вторых, ты этими излишними сущностями загромоздил модель,
увеличив её и усложнив её использование.
Писать всё время "ph->" --- для этого люди компиляторы
придумывают, препроцессоры. Чтобы _не_писать_ то, что не нужно,
что не является необходимым написать.
В-третьих, задачи ты так и не решил:
введение необоснованной сущности.
---
...Я работаю антинаучным аферистом...

lera98

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

enochka1145

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

lera98

Во-первых, возможны задачи с возникновением команд типа
ph1->....;
ph2->....;
Во-вторых, введение ph обосновано. Поскольку нам требуется умножать физ.величины, то требуется объект, производящий умножение объектов-ф.вел. Для этого умножения нужно уметь складывать и упрощать размерности. Для упрощения размерностей нужно знать соотношения размерностей в данной (т.е. в нашем случае в реальной) физике. Для перечисления основных (базовых) размерностей служит массив BasicTypes. Для перечисления всех известных (в этой физике) размерностей (метры, килограммы, дюймы, сажени, паскали, мм.рт.ст, и др.) используется массив KnownTypes.
Чтож тут необоснованного?
> Ещё раз, физическая модель и физика ---
> это две очень и очень большие разницы.
Во-первых не "ещё раз". Во-вторых, предложение корявое с точки зрения великого и могучего. И в-третьих, твоё утверждение по смыслу верно, но не является контраргументом в данном споре.
Поясняю: в классе "физики" я полагаю хранить размерности ф.в. и законы (формулы связывающие ф.в. Поэтому как для разных физик, так и для разных физ.моделей мне потребуются разные экземпляры физик.
Вот пример: в физике есть раздел "Механика". Неспроста существует термины "Механика Ньютона", "Квантовая механика", "Релятивистская механика". Они описываются разными законами.
Для, например, нахождения разниц суммы скоростей, посчитанных с помощью Ньютоновой и релятивистской механик нужны будут два экземпляра физики.

Marinavo_0507

Некоторые выводы по обсуждению.
ООП было придумано в качестве подхода к решению узкого класса задач.
Первый ООЯ, Симула, был предназначен для создания определённого класса имитационных моделей.
Фигня началась, когда ввели ООП-средства в С, что дало толчок развитию
всего семейства современных "промышленных" языков, и соответствующего подхода к проектированию.
Почему фигня?
Потому что, кроме поддержки объектов, эти языки остались всё тем же Алголом.
То есть, объекты приходится использовать и для замены абстрактных типов данных,
и как средство модульности, и для реализации простейших алгебраических типов данных,
и для борьбы с отсутствием функций высших порядков и closures.
Функции - до сих пор низший класс в этих языках.
Например, у объекта есть поля и методы.
Значение поля можно изменить присваиванием, а новый метод объекту не приделать -
при компиляции он прибивается гвоздями.
Полноценных lexical closures в этих языках нет.
Поэтому, при проектировании ОО-программист вынужден обходиться данным
ему набором абстракций, не используя всё остальное.
Некоторые из них даже утверждают, что объекты якобы существуют в реальном мире,
в отличие от, например, функций.
Особенно поразительная вещь - наследование.
В этом треде никто так и не привёл примера, когда оно нужно.
(Кроме реализации АТД, что даже Java отличает от настоящего наследования:
implements вместо extends).
Но его поддержка в языках есть, а намного более полезных lexical closures - нет.
Вторая особенность ООП, уменьшающая универсальность этого подхода -
привязка свойств к объектам, независимо от субъектов.
Это несмотря на то, что в темноте все кошки чёрные, масса тела зависит от системы отчёта,
а у квантово-механической системы состояние вообще невозможно определить.
"Боевики" игнорируют научные данные, и упорно утверждают, что в реальном мире объекты такие же, как в ООП.
Но даже и для работы с такими "гвоздями приколоченными" свойствами у "промышленных"
языков не хватает инструментов: нельзя например, добавить новый тип поведения уже созданному объекту.
Если человек не рождён водителем, ему в "промышленном ООП" уже никогда не суждено этому научиться.
Этих недостатков лишены некоторые из современных функциональных языков.
Соответственно, функциональные программисты свободны использовать абстракции,
наиболее подходящие под задачу.
Например, объектная система Ocaml - одна из лучших.
Но главное - это то, что использовать её не обязательно.
Ведь для отделения интерфейса от реализации есть модули,
полиморфизм поддерживается полиморфной системой типов и функциями высшего порядка,
кроме того, удобные средства работы с алгебраическими типами данных и pattern matching
тоже не требуют использования объектов.
Место объектной системы Ocaml - для того узкого круга задач, где объекты таки полезны.
CLOS - одна из мощнейших объектных систем.
Реализована на чистом Common Lisp, используя его превосходные средства
создания проблемно-ориентированных расширений языка.
А уж простейшую динамическую объектную систему типа SmallTalk без труда можно реализовать на ФЯ.
Приятный синтаксис можно добавить встроенными средствами метапрограммирования,
без использования внешних препроцессоров и генераторов.
Когда такие средства дойдут до "промышленных" языков и до сознания "промышленных" разработчиков,
можно будет говорить, что ООП - это не плохо, а всему своё место.

Dasar

Имхо, выяснение, что лучше с ООП или без ООП - это возня в песочнице.
на мой взгляд есть более серьезные проблемы:
1. Как представить информацию в легко расширяемом виде?
2. идентификация термов, как понять, что подразумевается в данный момент под данным термом?
3. Как работать в условиях противоречивых правил?
4. Как быть, если нет полной модели правил?

Marinavo_0507

(3 (4) - может помочь недетерминизм: попробовать несколько вариантов, потом сравнить
а вообще-то довольно глупо браться за сложные проблемы, не умея решать простые

lera98

> ООП было придумано в качестве подхода к решению узкого класса задач.
Я за то, чтоб сделать ООП универсальным.
> ...новый метод объекту не приделать - при компиляции он прибивается гвоздями...
> ...нельзя например, добавить новый тип поведения уже созданному объекту...
> ...Вторая особенность ООП, уменьшающая универсальность этого подхода -
> привязка свойств к объектам, независимо от субъектов...
Ничто не мешает на чистом Си с помощью структов соорудить другое ОО расширение языка, в котором будет нормальная поддержка новых методов, добавляемых объекту динамически. (И удаление имеющихся)
> Особенно поразительная вещь - наследование.
> В этом треде никто так и не привёл примера, когда оно нужно.
Оно нужно для создания дочерних классов, имеющих частичную информацию о классе-родителе, расширяющих родительский или заполняющих пустоты в случае абстрактного родительского класса.
> Полноценных lexical closures в этих языках нет.
Не знаю такого определения. : ( Что это и зачем?
> Это несмотря на то, что в темноте все кошки чёрные, масса тела зависит от системы отчёта,
> а у квантово-механической системы состояние вообще невозможно определить.
Имхо, бессмысленные аргументы впользу неуниверсальности ООП. Пояснения будут? На псевдокоде хотя бы.
Насчёт современности языка: определение "современный", например, не применимо к Асму. Он всегда будет актуальным. Перспектив "загибания" у Асма не было и нет.

enochka1145

Спасибо, что зарезюмировал. Дай-ка и я поделюсь своими (около- ?) философскими мыслями.
> ООП было придумано в качестве подхода к решению узкого класса задач.
Вроде как ООП было придумано, когда один Соколиный Глаз заметил, что данные порой неплохо бы рассматривать вместе с методами их обработки.
> Потому что, кроме поддержки объектов, эти языки остались всё тем же Алголом.
Напоминает довод, что Java, мол, не развивается, а развитие библиотек не в счёт. А если у языка цель - оставаться простым и удобным?
Потому что когда язык становится сложнее проблемы, которая на нём обсуждается, такой язык загибается. Примеров, думаю, можно нарыть и из математики, например, из алгебры.
> ...для борьбы с отсутствием функций высших порядков.
А разве бывают функции высших порядков? Так или иначе, они к чему-то относятся. И если функция относится к высшему порядку в твоем математической системе, это ещё не значит, что она будет оставаться такой, когда ты надумаешь соединить свою математическую систему, скажем, с пользовательским интерфейсом. Disclaimer: на абсолютную истину я не претендую.
> Некоторые из них даже утверждают, что объекты якобы существуют в реальном мире, в отличие от, например, функций.
Наверно, они утверждают, что объекты ОТРАЖАЮТ объекты реального мира, которые, кстати, в свою очередь, тоже являются человеческими абстракциями.
> Особенно поразительная вещь - наследование. В этом треде никто так и не привёл примера, когда оно нужно.
> Значение поля можно изменить присваиванием, а новый метод объекту не приделать -
при компиляции он прибивается гвоздями.
Так вроде наследование и имеет дело с расширением. Или я что-то пропустил?
> Вторая особенность ООП, уменьшающая универсальность этого подхода -
привязка свойств к объектам, независимо от субъектов. Это несмотря на то, что в темноте все кошки чёрные, масса тела зависит от системы отчёта, а у квантово-механической системы состояние вообще невозможно определить. "Боевики" игнорируют научные данные, и упорно утверждают, что в реальном мире объекты такие же, как в ООП. Но даже и для работы с такими "гвоздями приколоченными" свойствами у "промышленных" языков не хватает инструментов: нельзя например, добавить новый тип поведения уже созданному объекту. Если человек не рождён водителем, ему в "промышленном ООП" уже никогда не суждено этому научиться.
Я не сомневаюсь, что здесь есть какая-то идея, но только я не смог её уловить. Вроде как наследование решает проблемы расширения.

Marinavo_0507

> Вроде как ООП было придумано, когда один Соколиный Глаз заметил, что данные порой неплохо бы рассматривать вместе с методами их обработки.
Это "всего лишь" модульность.
> Потому что когда язык становится сложнее проблемы, которая на нём обсуждается, такой язык загибается.
Ocaml проще C++ и микрософтовских "промышленных" языков.
Проще Схемы вообще трудно что-то придумать.
Вводить объекты в С - это примерно как, не используя инструментов, работать с ящиками инструментов.
Вместо простого молотка использовать ящик, в котором лежит молоток, и забивать гвозди молотком вместе с ящиком.
Терминология для тех, кто не в ладах с гуглом.
Функции высших порядков: http://c2.com/cgi/wiki?HigherOrderFunction
Lexical Closures: http://c2.com/cgi/wiki?LexicalClosure
> Наверно, они утверждают, что объекты ...
Гадать не надо, говорит прямо.
Рекомендую перечитать тред. Этот, и в архиве есть несколько подобных.
> Так вроде наследование и имеет дело с расширением. Или я что-то пропустил?
Ты пропустил, что присваивание позволяет изменить значение поля объекта.
Уже созданного объекта. Во время выполнения программы.
В то время как наследование может поменять поведение только новых объектов.
В "промышленных" языках и для этого требуется перекомпиляция.
> Я не сомневаюсь, что здесь есть какая-то идея, но только я не смог её уловить.
Идея в том, что цвет не принадлежит кошке.
Он формируется кошкой, источником света и наблюдателем.
Убери одного - и цвета не станет.
О нём можно говорить как о функции трёх параметров.
Масса, скорость и размеры физического тела - зависят от системы отсчёта.
Состояние в квантовой механике возникает в момент наблюдения, и не существует в отсутствие наблюдателя.
И только образ мышления "боевиков" похоже, привязан к ним навсегда, как свойства к объектам в их программах.

bastii

Во многом согласен. Особенно с замечанием, что как языки ФЯ гораздо более развитые.

Например, объектная система Ocaml - одна из лучших.
Но главное - это то, что использовать её не обязательно.
Ведь для отделения интерфейса от реализации есть модули,
полиморфизм поддерживается полиморфной системой типов и функциями высшего порядка,
кроме того, удобные средства работы с алгебраическими типами данных и pattern matching
тоже не требуют использования объектов.
Место объектной системы Ocaml - для того узкого круга задач, где объекты таки полезны.

С другой стороны, видимо, развитость -- это и есть основная причина того ФЯ не относятся к мейнстрим ЯП.
Правда, чтобы не сложилось впечатление, что ООП – говно, а ФП хорошая замена ООП, напишу развернутый ответ в пользу ООП.
Необходимо отметить, что полиморфизм очень важная составляются, которая позволяет абстрагироваться от данных, и работать на таком уровне абстракции, который отражает точку зрения определенного алгоритма. Практически все развитые языки позволяют это делать. ФЯ позволяют это делать так, как сказал godfather. Плюс все остальное делает ФЯ очень мощными, наверно, даже без тех расширений, как поддержа ООП и императивного пр-я.
Теперь, если посмотреть на ООП, то фактически это попытка объединия следующих дисциплин в программировании:
1) Полиморфизм -- абстрагирование от данных до удобного уровня при программировании алгоритмов.
2) Инкапсуляция -- связывание операций и данных, что добавляет дополнительный способ абстрагирования над данными посредством восприятия данных через операции, которые можно выполнять над этими данными. Унифицируются данные и алгоритмы. Механизмы повторного использования кода для данных и алгоритмов одни. Такие инкапсулированные сущности более самостоятельные и независимые. Зависимость между алгоритмами и данными слабее. Все это упрощает усовершенствование отдельных элементов программы, которое не затрагивает остальные части программы. Удобно разбивать на части код решения задачи и ее реализацию. Последнее привело к развитию концепции компонентов. Программисту проще сосредотачивать свое внимание локализовано. ООП хорошо масштабируется на большие проекты. Это объясняет популярность ООП в промышленном программировании. Позволяет делать "доступные" API к сложным фреймфоркам. Когда для решения простых и типичных задач, API предоставляют простой взгляд на фреймворк и позволяют не вдаваться в подробности архитектуры и реализации, но вместе с тем делают удобным "глубокий" доступ к фреймфорку при более сложных задачах.
3) Наследование – это очень ограниченный способ повторного использования кода. И это очень важно. Вместе с 1) и 2) позволяет строить сложнейшие, но очень гибкие фреймворки. Когда можно не только заменить любой кусок фреймворка на свой, но при этом максимально использовать ту функциональность, что уже содержит этот фреймворк. Что важно отметить, что именно ограниченность механизма наследования, позволяет при всей гибкости и проницаемости фреймфорка оставить достаточный запас для дальнейшего развития и совершенствования, которые не приведут к breaking change с точки зрения клиентского кода.
Все эти 3 парадигмы очень хорошо сочетаются и дополняют друг друга. Нужно так же заметить, что сегодня ООП – это хорошо изученный вопрос. Хорошо изучены и способы реализации ООП. ООП хорошо сочетается со статической типизацией. Даже такой убогий язык (как Java) с ООП становится мощным инструментом. ООП библиотеки очень доступны для использования начинающими программистами, и на определенном уровне даже не требует понимания ООП (пример VB). И вообще на сегодня имеется очень богатый опыт встраивания ООП в языки, в том числе и в ФЯ.
В виду выше сказанного слова godfather, занижающие ценность ООП кажутся отражением узконаправленного взгляда на ООП.
Не смотря на то, что не могу похвастаться хорошим знанием ФП и примеров ФЯ, верю, что ФП не может служить полноценной заменой ООП.

lera98

> Терминология для тех, кто не в ладах с гуглом.
Жмусь на инет, у меня его щас мало : (
Почитал немного. И что там такого можно, что нельзя на Си?
> Вводить объекты в С - это примерно как, не используя инструментов,
> работать с ящиками инструментов.
> Вместо простого молотка использовать ящик, в котором лежит
> молоток, и забивать гвозди молотком вместе с ящиком.
Объекты в Си уже вводили - получился Си++. Я предлагаю ввести их по другому, более универсально. А то, чем будем гвозди забивать, зависит от прямости рук разработчиков нового объекного расширения Си.
> ...цвет не принадлежит кошке. Он формируется кошкой, источником света и наблюдателем...
Ты прав. Кошке принадлежат отражательные и поглощательные свойства шкуры. Источнику принадлежат свойства спектра, интенсивности и направленности света. Наблюдателю принадлежат рецепторы со свойствами поглощения света, определяющими сигнал на их выходах, который является воспринимаемым ЦВЕТным изображением. Таким образом цвет - внутренняя информация наблюдателя, а не всех трёх объектов сразу.
> Убери одного - и цвета не станет.
Без наблюдателя нет смысла говорить о цвете. Без источника цвет есть (т.к. есть рецепторы но равномерно чёрный. Без объекта наблюдения цвет есть, но везде чёрный, кроме области отображения источника.
> Масса, скорость и размеры физического тела - зависят от системы отсчёта.
> Состояние в квантовой механике возникает в момент наблюдения,
> и не существует в отсутствие наблюдателя.
Что мешает создать такую объектную систему, где это будет учитываться?
> И только образ мышления "боевиков" похоже, привязан к ним навсегда,
> как свойства к объектам в их программах.
Не труби в фанфары, боевик. Я отбил твои аргументы ; )
____
ЗЫ: я более дружу с Яндексом.

lera98

Народ! У нас рульная дискуссия Только она затянулась...
Мне так и не привели задачи, которая бы не решалась на ООП в том виде, в котором оно есть сейчас. : )
Я не с ВМК, а сам по себе, поэтому бОльшая часть терминологии мне неизвестна. Тем не менее прогать начал с бейсика 7 лет назад, а сейчас ярый сторонник Асма и Си. Отношусь к каждому имхо с уважением.
_______
ЗЫ: Ненавижу толстые учебники. Люблю толстые справочники.

shlyumper

>> Терминология для тех, кто не в ладах с гуглом.
>Жмусь на инет, у меня его щас мало : (
>Почитал немного. И что там такого можно, что нельзя на Си?
В дополнение к функциям высшего порядка:
http://en.wikipedia.org/wiki/Lambda_calculus
>> ...цвет не принадлежит кошке. Он формируется кошкой, источником света и >наблюдателем...
>Ты прав. Кошке принадлежат отражательные и поглощательные свойства шкуры.
>Источнику принадлежат свойства спектра, интенсивности и направленности света.
>Наблюдателю принадлежат рецепторы со свойствами поглощения света, определяющими
>сигнал на их выходах, который является воспринимаемым ЦВЕТным изображением.
>Таким образом цвет - внутренняя информация наблюдателя, а не всех трёх объектов
>сразу.
Нет. Ты вводишь лишнее ограничение, в силу привязки к объекту-наблюдателю. Изначально цвет существует только при наличии трех сущностей. Тебе для ООП реализации необходимо, чтобы цвет принадлежал конкретно одной сущности, от имени которой ты смог бы его "получать", вот ты его и присваиваешь наблюдателю, что вкорне нарушает модель задачи.
Дальше ты сталкиваешься со следующей проблемой: отсутствие цвета при нехватке одной из необходимых сущностей, и для борьбы с этой проблемой вводишь специальный цвет типа null, что опять же является рождением новой ненужной сущности, не имеющей физического воплощения:
> Без наблюдателя нет смысла говорить о цвете. Без источника цвет есть (т.к.
> есть рецепторы но равномерно чёрный. Без объекта наблюдения цвет есть, но
> везде чёрный, кроме области отображения источника.

lera98

Всё, о чем я говорю, могу изложить более подробно и понятно, если есть какие-либо тёмные для понимания пятна в моих постах.
> Нет. Ты вводишь лишнее ограничение, в силу привязки к объекту-
> наблюдателю. Изначально цвет существует только при наличии трех
> сущностей. Тебе для ООП реализации необходимо, чтобы цвет
> принадлежал конкретно одной сущности, от имени которой ты смог бы его
> "получать", вот ты его и присваиваешь наблюдателю, что вкорне нарушает
> модель задачи.
Во-первых, определение цвета (из физики) в студию. Иначе спор беспочвенен.
> ...вводишь специальный цвет типа null...
Нет, не ввожу. Чёрный цвет такой же по правам цвет, как белый или красный. Почему это ты его null'ом обозвал?
------
Тебе не кажется, что я изложил истину?
Тогда чётко и ясно, пожалуйста: моя ошибочная фраза - это ...

Marinavo_0507

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

let choose filter_func unlabel_func cats =

  let filtered = filter filter_func cats in

  let unlabeled = map unlabel_func filtered in

    unlabeled

И всё это со строгой статической типизацией!
Легко видеть, что это композиция стандартных функций map и filter,
таким образом пригодно далеко не только для кошек:

let compose f g = fun x -> f (g x)



let choose f m = compose (map m) (filter f)

Пример использования:

(* Рассмотрим кошек при нормальном освещении и повесим каждой бирку *)

let labeled_cats = map (fun cat -> (get_color light cat, cat cats



(* Теперь пусть доступа к освещению нет, но бирки сохранились.

Выберем всех белых кошек *)

let white_cats = choose (fun (color, _) -> (color = white snd labeled_cats

(* snd - стандартная функция (a, b) -> b *)

lera98

! определение цвета !
_________________
Твои примеры основаны на косвенных способах измерения оптических свойств шкурок кошек.
А выбрать кошек с заданными свойствами можно и на ООП тоже.

Dasar

> 3) Наследование – это очень ограниченный способ повторного использования кода.
имхо, наоборот.
Наследование - очень мощный механизм.
Особенно если язык позволяет реализовать наследование над объектами АТД, последовательностями выполнения и т.д.

lera98

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

enochka1145

Д-во. Очевидно.

class A { void f { сделать_всю_работу; } }

lera98

)
Один умный препод мне сказал, что решение такое, над которым хочется смеяться, - правильное с > 99% вероятностью. Возможно, это была шутка.

lera98

Нда....... : )
Может ты и доказал... Но какой же жопно-безобразный у тебя объект получился! Это ж надо! И каой же он бесполезный! Подходит только для решения единственной задачи. Для другой - мочало - начинай сначала.
...хм....

bastii

Я имел в виду, что если сравнивать наследование с таким способом: сделал Copy, сделал Paste, подправил для своих нужно. (Так наверно любят работать пхпшники )
Ок, тогда так:
Наследование это определенный, довольно мощный способ повторного использования кода. И, что важно, позволяет автору исходного кода защитить себя от непредусмотренного повторного использования, тем самым давая себе возможность внесения изменений в свой код, зная что это не повредит тем, кто уже им повторно пользуется.
На практике -- это очень важный момент. И, как мне кажется, ФП эту ситуацию плохо обслуживает.

Marinavo_0507

> И, как мне кажется, ФП эту ситуацию плохо обслуживает.
См. выше две реализации функции choose.

Dasar

> Идея в том, что цвет не принадлежит кошке.
Все правильно. Но это правильность нужна только, если расписывать полную картину мира.
но полная картина мира очень редко нужна.
> Он формируется кошкой, источником света и наблюдателем.
> Убери одного - и цвета не станет.
> О нём можно говорить как о функции трёх параметров.
С теоретической точки зрения все именно так и обстоит.
Но на практике все зависит от задачи.
Если это задача - каталог цветных мелков, то проще приписать цвет мелку.
Если расматривается задача формирования изображения цветными прожекторами - то цвет проще приписать прожектору.
Если рассматривается задача - формирование изображения цветными прожекторами на цветном экране - то цвет проще приписать точке, освещенной прожектором.
И хороший язык - это тот, который позволяет легко перейти от одного представления к другому.
to GF:
тебя почему-то очень бесит ООП-ешная точка...
но точка всего лишь обозначает связь между двумя сущностями.
каким образом эта связь обеспечивается - это уже дело языка/системы.
Вернемся к задачке про цвет:
Brain.Point.Color = Receptor.Process(Wall.Point.Color);
Здесь просто задекларировано, что есть понятия Brain/Point/Color/Receptor/Process/Wall,
что между понятиями Brain, Point и Color - есть связь, что между Receptor-ом и глаголом Process - есть связь, что между Wall, Point-ом и Color-ом тоже есть связь.
Также задекларировано, что имея Wall мы можем получить Point, имея Point мы можем получить Color и т.д.
Причем это лишь представление, ни больше, и не меньше - т.е. сейчас мне удобнее думать, что все обстоит именно так, если завтра мне удобнее будет думать по другому - я изменю это представление, или добавлю еще одно.
ps
Промышленные языки - это "база".
Сначала такой базой был - ассемблер, затем C, C++, сейчас Java и C#/.Net.
Имея код записанный на "базе" - мы можем его исполнить, причем эффективно, т.е. можно считать, что если код записан на "базе", то его ручное переписывание на более низкоуровневом языке реальной выгоды почти не принесет. Т.е. компиляторы с "базы" очень и очень эффективны.
Текущие реализации ФЯ - такой базой не являются, т.е. на практике они требуют для эффективного исполнения перетрансляции кода в ассемблер, C/C++, Java-у или C#/.Net.
Соответственно чем "база" высокоуровневее, тем удобнее, т.к. именно на "базе" разрабатывается и выполняется большая часть API, библиотек, примеров и т.д.
Также если мы пишем, напрямую на языке-"базы" - то мы избегаем проблемы двойной конвертации: Api/библотекти - в доп. язык, а затем обратно.
Причем, как на уровне выполнения, так и на уровне размышлений.

Dasar

> См. выше две реализации функции choose.
Мне тут сказали, что ФЯ pattern matching не поддерживает вызов функций.
Соответственно на сложных примерах тебе это все равно не поможет.

Marinavo_0507

> Все правильно. Но это правильность нужна только, если расписывать полную картину мира.
> но полная картина мира очень редко нужна.
Мой пример с кошками работает независимо от того, насколько полная картина мира в программе.
Так как использует только те свойства, что нужны для выбора, независимо от того, как они получены.
Кроме того, если вместо кошек там их id из базы данных, всё равно код работает без изменений.
Вот это --- полиморфизм.
Про "базу" - фигня полная.
Что Оcaml транслирует в маш. код, что Java, что .Net.
Ну в разное время, в зависимости от реализации.
Эффективность - это ещё надо смотреть, на каких задачах что быстрее.

lera98

>> Он (цвет) формируется кошкой, источником света и наблюдателем.
>> О нём можно говорить как о функции трёх параметров.
> С теоретической точки зрения все именно так и обстоит.
, , в этом согласен.
> Убери одного - и цвета не станет.
А вот в этом нет. Функция цвета f(x,y,z) определена при z==0 и равна f(x,y,0).
> Brain.Point.Color = Receptor.Process(Wall.Point.Color);
Неплохое частное определение цвета. Оно, правда, подразумевает то, что мы имеем уже вычисленное значение Wall.Point.Color, зависящее от опт. свойств стены и источников.

Dasar

> Мой пример с кошками работает независимо от того, насколько полная картина мира в программе.
Объясни, плиз, какой новый и полезный функционал делает введенная тобой high-функция choose?
Почему ее нельзя было ввести прямо по месту?
Чем этот choose отличается от других choose-ов? Другими буквами?

Marinavo_0507

Не только choose, весь пример работает независимо от того, кто и как определяет цвет,
и что подставляется под видом кошек.

lera98

>> Все правильно. Но это правильность нужна только, если расписывать полную картину мира.
>> но полная картина мира очень редко нужна.
>Мой пример с кошками работает независимо от того, насколько полная картина мира в программе.
>Так как использует только те свойства, что нужны для выбора, независимо от того, как они получены.
Работать только с нужными свойствами и забивать на возможные остальные и на то, как именно получаются значения этих свойств - такое делается и на ООП. Именно, с помощью наследования (добавление новых свойств и методов) и замены виртуальной функции (метода получения свойства).
> Про "базу" - фигня полная
Я противоположного мнения. верно пишет.

Dasar

> весь пример работает независимо от того, кто и как определяет цвет, и что подставляется под видом кошек
Это настолько важно? Ты же сам вручную заложил такую возможность расширения - такое любой язык умеет.
важнее обычно другое:
мы записали факт:
Brain.Point.Color = Receptor.Process(Wall.Point.Color);
Посидели подумали записали еще один факт:
Wall.Point.ReflectColor = Combine(Wall.Point.MaterialColor, Light.Color);
каким образом можно не переписывая первый факт - сказать всем, что в первом факте мы имели ввиду
под Wall.Point.Color на самом деле Wall.Point.ReflectColor.

bastii

> И, как мне кажется, ФП эту ситуацию плохо обслуживает.
См. выше две реализации функции choose.

Ну так это понятно, что аналогом предоставления в классе виртуальных методов для перегрузки в ФП будет функция, с у которой будет несколько функциональных параметров. Причем в примере по сложнее функциям-параметрам нужно будет передавать данные, с которыми работает функция (аналог того, что в ООП перегруженный метод имеет доступ к pretected методам и полям). Короче придется городить ручками то, то предоставляет язык с поддержкой ООП. Такое и в С можно сделать.

shlyumper

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

Ну что ты привязался к слову цвет-то?
Хочешь физическую, действительно существующую сущность такого рода? Пожалуйста:
Пусть это будет правило Фейнмана для какой-либо вершины. Сущность существующая только для комбинации из трех одновременно взаимодействующих частиц. Или для четырех. Или для пяти. И т.д. Не свойственная какой-либо из этих частиц в отдельности. Определяющаяся только комбинацией из этих частиц и ничем более.
За подробностями - в любую книжку по квантам/теории поля.
Твое ошибочное утверждение: "цвет - внутренняя информация наблюдателя, а не всех трёх объектов сразу". Для правила Фейнмана нет такого выделенного "наблюдателя". Доволен? Решай в рамках ООП.

lera98

> Ну что ты привязался к слову цвет-то?
Цвет - частность. Если у каждого своё определение сущности, то спорить о ней нет смысла.
Под цветом я понимаю именно информацию (для глаза/для видеокамеры - тройку величин электрических импульсов) от элементарного участка поверхности рецептора (сетчатки/диода).
Рассматривать цвет без наблюдателя попытаться можно. Например, введя определение цвета как спектр отражённого от тела света. Типа в простом случае
<цвет'> = <спектр_источника> * <спектральная_хар-ка_отражения_объекта>.
В этом случае умножаем <цвет'> на <спектральная_ хар-ка_поглощения_наблюдателя> == 1 и получаем
<цвет> = 1 * <цвет'>.
Назову такого наблюдателя идеальным. Это очень мощный перец получается, - от каждой элементарной точки он получает не одно число (ч/б изобр.) и не три (обыч. цветное а множество континуума действительных чисел, что даёт ему несравнимо большую зрительную информацию.
> ...правило Фейнмана для какой-либо вершины...
Во, пасиба. Хорошее и понятное определение. Щас попробую его представить в объекном виде.

- объект вершина

- объект фейнман ( а как ж ещё назвать :  )  )

- объект опер ( обеспечивает взаимодействие, движение, рождение и смерть частиц и проч. )

- опер при выполнении определённых условиях порождает и уничтожает фейнманы.

> Твое ошибочное утверждение: "цвет - внутренняя информация
> наблюдателя, а не всех трёх объектов сразу".
Это предложение-следствие. Если оно ошибочно, то должна быть ошибка в предыдущих предложениях-причинах. Не вижу. Я описывал как есть.

Ivan8209

Определение "современный" очень хорошо применимо к ассемблеру.
Современные ассемблеры очень даже хорошо отличаются от
несовременных. Чтобы убедиться в этом не надо особенных трудов,
достаточно сравнить набор инструкций ИБМ-360/370 и чего-нибудь
более нового. Например, АРМ.
"Оно нужно для создания дочерних классов" --- это не пример.
Примером оно станет, когда получит выражение в качестве решения
жизненной задачи и когда убедительно покажут, что задача не
может быть решена без наследования.
К тому же, это сказано на языке ООП, что уже говорит о подгоне
решения к парадигме ООП.
---
...Я работаю антинаучным аферистом...

Ivan8209

1. Например, списком.
2. По контексту.
---
"Расширь своё сознание!"

Dasar

> 2. По контексту.
Что такое конктекст?
Как правило привязывается к контексту?
Как происходит уточнение контекста?
Как для необходимого конктекста вводится новое правило?

Ivan8209

Возможны две задачи или нет --- безразлично.
Обсуждается одна, вполне определённая задача.
Умножать физические величины должна, вроде как, программа,
а не встроенный в неё под названием "ph" интерпретатор.
Зачем перечислять размерности списком, если для решения задачи
достаточно завести три типа: массу, ускорение и силу?
В общем, пока введение дополнительных сущностей не обосновано.
---
...Я работаю антинаучным аферистом...

Ivan8209

У меня короче:

(do-it-all)

---
...Я работаю антинаучным аферистом...

Ivan8209

Область видимости имён.
Определением.
Указанием квалификации, если это требуется.
Определением.
---
...Я работаю антинаучным аферистом...

Dasar

> Область видимости имён.
> Определением.
> Указанием квалификации, если это требуется.
> Определением.
Детский сад какой-то...

Marinavo_0507

> Ты же сам вручную заложил такую возможность расширения - такое любой язык умеет.
Где? Покажи пальцем в коде.
Я всего-лишь не стал ограничивать общность.
Менее общий код был бы длиннее.
> важнее обычно другое:
> мы записали факт:
> Brain.Point.Color = Receptor.Process(Wall.Point.Color);
> Посидели подумали записали еще один факт:
> Wall.Point.ReflectColor = Combine(Wall.Point.MaterialColor, Light.Color);
> каким образом можно не переписывая первый факт - сказать всем, что в первом факте мы имели ввиду
> под Wall.Point.Color на самом деле Wall.Point.ReflectColor.
Искусственная проблема, привнесённая в задачу ОО-мышлением.

Dasar

> Где? Покажи пальцем в коде.
вот здесь, ты заложился на то, что у тебя есть два доп. расширения: filter и развешивание ярлыков.
также ты заложился на то, что сначала у тебя присваиваются метки, а только потом идет фильтрация.

let choose filter_func unlabel_func cats =

  let filtered = filter filter_func cats in

  let unlabeled = map unlabel_func filtered in

    unlabeled

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

Dasar

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

Ivan8209

Скажи, почему пишешь не на ассемблере?
---
...Я работаю антинаучным аферистом...

lera98

> Обсуждается одна, вполне определённая задача.
> Умножать физические величины должна, вроде как, программа,
> а не встроенный в неё под названием "ph" интерпретатор.
Затем:

> Зачем перечислять размерности списком, если для решения задачи
> достаточно завести три типа: массу, ускорение и силу?
Для решения этой задачи с возможностью лёгкого расширения решения для более широкого класса задач я ввёл списочную систему перечисления. Надо о будущем думать. Решение, подходящее для единственной задачи, полезно для тренировки в решении задач, но не для серьёзной практики.

Dasar

> Скажи, почему пишешь не на ассемблере?
Потому что в нем сложнее записывать факты, и писать большие программы.

shlyumper

- объект вершина
- объект фейнман ( а как ж ещё назвать : ) )
- объект опер ( обеспечивает взаимодействие, движение, рождение и смерть частиц и проч. )
- опер при выполнении определённых условиях порождает и уничтожает фейнманы.

Прежде чем говорить "незачет", хочу чтобы ты расписал все это дело на каком-нибудь ОО языке без использования ФП.
Для сравнения:

val factor1 = feynman_rule (particle1 particle2 particle3) ;;

val factor2 = feynman_rule (particle1 particle2 particle3 particle4) ;;

Никаких лишних сущностей. Частица - имеет физическое воплощение. Правило Фейнмана - имеет физическое воплощение. Бывает как для трех частиц, так и для четырех, и для пяти, и для тысячи. Не бывает для одной или двух. Не является "собственностью" какой-то конкретной частицы. Является совокупным свойством набора из N взаимодействующих частиц. Не является свойством какого-либо UniversalMind по имени Фейнман.

enochka1145

Ну замечательно.

psi = 3particles.waveFunction(p1, p2, p3);

Dasar

> Искусственная проблема, привнесённая в задачу ОО-мышлением.
Ты суть проблемы понял?
Суть проблемы в том, что допустим мы где-то сделали замыкание (т.е. написали вызов уже конкретной функции).
например, такое:
return choose(IsColor(white Set(Random;
то можно ли не меняя код, а также как можно меньше меняя исполнение других участков кода
расширить эту конструкцию.
например, превратить в такую:
return choose(IsColor(white or black Set(Random;

Можно ли такое сделать только для определенного контекста?

Marinavo_0507

> Также ты заложился на то, что у тебя функция unlabel и filter на вход берет только один экземпляр кошки.
Прямое следствие из постановки задачи.
> также ты заложился на то, что сначала у тебя присваиваются метки, а только потом идет фильтрация.
Также из постановки задачи: сначала есть свет и наблюдатель, а потом они ушли, и надо выбрать кошек по результату.
> Покажи, что этой проблемы нет при других мышлениях.

- Вы мне не верите? Но я действительно только что оттуда.- Скайл протянул нам герметически закрытую стеклянную баночку.- Вот, взгляните: я наполнил ее космической пустотой.
Мы взглянули и ахнули: в баночке действительно было пусто.

(c) Ф.Кривин

shlyumper

кто такое "3particles"? UniversalMind, который умеет манипулировать тремя чатицами? откуда он взялся?

enochka1145

Из набора функций для трёх частиц.

shlyumper

Из набора функций для трёх частиц.

Незачет. Надуманная сущность, в физике не существующая. Издержки неудачного ОО дизайна, не более того.

Ivan8209

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

Marinavo_0507

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

Dasar

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

enochka1145

Это был просто пример навскидку.
И непонятно, почему такие отвращение к UniversalMind. При желании, его можно заменить на ещё более universal без вреда для остального кода.

Dasar

> Тогда почему ты постоянно выписываешь явное указание контекста,
ткни мне пальцем, где я выписал явное указание

Ivan8209

"Умножитель" --- это твоя программа, зачем вводится
дополнительная рефлексия? Каким образом она здесь востребована?
Из условий задачи.
Из постановки задачи не следует необходимость возможности её
обобщения. Она возникла сиюминутно и в будущем может больше
никогда и не решаться. А ты выполнил лишнюю работу.
Тот же вопрос: почему ты стал решать эту задачу на плюсах,
а не на ассемблере? Программировать на ассемблере куда более
полезно для тренировки в решении задач. Даже Кнут советует.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Что именовать их надо сразу по трое?
Хочешь сказать, что нужно заводить класс "3 кошки", унаследованный от одной?

shlyumper

И непонятно, почему такие отвращение к UniversalMind. При желании, его можно заменить на ещё более universal без вреда для остального кода.

Конечно можно. Получим любой не-ОО язык. В нем абсолютно все функции являются методами объекта UniversalMind.
UniversalMind - это способ свести ОО модель к не-ОО модели. В той ОО концепции, которую исповедуют C++/java/C#/... вызов метода должен пренадлежать какому-то объекту, с этого весь спор-то начался. А UniversalMind это такой костыль, специальная доска, к которой можно прибить те методы, которые не могут принадлежать объекту, в силу того, что принадлежат совокупности равноправных объектов. Это не стыкуется с правильным ОО-дизайном.

lera98

> Прежде чем говорить "незачет"...
Семь раз подумай, один раз скажи. Видимо, ты не въехал в мой пример.
> val factor1 = feynman_rule (particle1 particle2 particle3) ;;
> val factor2 = feynman_rule (particle1 particle2 particle3 particle4) ;;
Частные задачи решать не надо, поскольку в случае известности решения общей задачи решение частной очевидно.
Система частиц - динамическая. Мы не знаем, сколько частиц будет через дельта-тэ, но знаем текущее состояние системы. Поэтому записи типа "factor2=..." неуместны.
> Частица - имеет физическое воплощение.
> Правило Фейнмана - имеет физическое воплощение.
Вот я и записал: объекты "частица" и "фейнман".
> ... Не является "собственностью" какой-то конкретной частицы.
Верно, у меня фейнман не принадлежит никакой частице.
> ...Является совокупным свойством набора из N взаимодействующих частиц.
Является. Опер создаст нужное количество фейнманов и запишет в них, каким совокупностям частиц они принадлежат.

Dasar

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

enochka1145

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

shlyumper

>> Прежде чем говорить "незачет"...
> Семь раз подумай, один раз скажи. Видимо, ты не въехал в мой пример.
Еще раз повторю: запиши свой пример на каком-либо ОО языке, без использования элеменотов ФП. Тогда, возможно, он будет понятнее.
> Система частиц - динамическая. Мы не знаем, сколько частиц будет через
> дельта-тэ, но знаем текущее состояние системы. Поэтому записи типа "factor2=..."
> неуместны.
Нет. Нет никакой динамической системы чатиц. Правило Фейнмана - это совершенно статичная вещь. Определяется только комбинацией частиц, и ни чем более. Никакой динамики.
Запиши свою модель в виде кода. Возможно, я тебя действительно совершенно не понимаю, т.к. ты недостаточно подробно описал свою идею.

shlyumper

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

Какого рода объект должен быть такой совокупностью? Приведи пример. Лучше, записанный в виде кода.

Dasar

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

enochka1145

Например, в Java для работы с массивами есть класс Arrays - там двоичный поиск в массиве, его сортировка, в общем, все дела.

shlyumper

Еще раз, учимся читать.
Приведи пример объекта, реализующего совокупность из трех частиц, в виде кода. Хоть на java, хоть на Oberon.

Marinavo_0507

> Мы как фильтровали, так и фильтруем.
Код фильтрации не изменится.
А вот условие нужно новое, не то, которое прописано в коде.
> Рефакторинг во многих случаях затруднен, особенно для большой программы.
Если нужно обобщить дальше, чем изначально спроектировано, придётся что-то менять.
Функции из 1 строчки менять легче, чем из 5-10.
Независимые функции менять легче, чем зависимые.
> где здесь польза от малой модульности?
Переписывать придётся только небольшое число функций.
> где здесь польза от открытого задания правил?
Видно, в каких местах надо менять. Забудешь - компилятор напомнит, так как интерфейс поменялся.

Marinavo_0507

> придется просто реализовать интерфейс, который требует тот же choose
вот именно, просто реализовать интерфейс
ООП опять отдыхает

sergey_m

У меня короче:

(do-it-all)

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

shlyumper

Ты не прав. Пример был вполне адекватным примеру .

Ivan8209

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

enochka1145

Это была шутка, адекватная

Ivan8209

Там, где ты написал "MathSystem".
---
...Я работаю антинаучным аферистом...

sergey_m

> Ты не прав. Пример был вполне адекватным примеру универсального ОО дизайна.
Мда. По-моему мне пора заигнорить этот тред.

Dasar

> Если нужно обобщить дальше, чем изначально спроектировано, придётся что-то менять.
да, менять надо.
но не обязательно менять для этого всю программу, и это доп. изменение не обязательно должно присутствовать у каждого из пользователя.
Удобно, когда можно отнаследоваться от уже рабочей копии программы, и сказать, что да, для данного пользователя мы вводим такое расширение.
все остальные пользователи работают с основной копией.
плюсы:
1. остальные не видят той сложности, и тех проблем - которые есть у нового участника
2. при изменении основной копии (исправлении, например, ошибки) - меняются и все унаследованные копии.
3. В унаследованной копии можно попытаться воспользоваться теми следствиями, которые были в основной копии.
Пример:
возьмем геометрию
есть основная копия - евклидова геометрия, в ней есть свои постулаты, свои следствия, свои зависимости.
есть унаследованная копия - геометрия лобачевского, в которой изменен по сравнению с евклидовой - один постулат.
Можно поступить тупо и разрабатывать геометрию лобачевского с нуля.
Можно поступить более грамотно, унаследовать все следствия из евклидовой геометрии и проверить их исходя из новых постулатов.
В результате проверки может выявиться следующее: следствие до сих пор работает, следствие больше не работает, следствие работать, но чуть-чуть не так.
Соответственно, имея такое наследование - мы в геометрии Лобачевского - не имея еще ни одного своего правила, уже имеем кучу унаследованных следствий и теорем.

lera98

Код влом писать. Так пойдёт?

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

enochka1145

Не пойму, чего ты от меня хочешь. Это устроит?

class _3particles {

  _3particles(Particle p1, Particle p2, Particle p3) { ... }

  type waveFunction { ... }

  ...

}

где type - тип, в котором ты хочешь получить результат, например, String.

Marinavo_0507

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

Dasar

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

enochka1145

> Мда. По-моему мне пора заигнорить этот тред.
"Wisely done, Mr. Freeman."
Повторять по-разному, что ООП - это всего лишь парадигма (не универсальная! удобная для многих реальных задач - реально достало. Всегда найдётся кто-то, кто скажет "У меня с 3 кошками коряво получается => ООП - отстой."

Marinavo_0507

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

Marinavo_0507

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

enochka1145

> Ни одного примера не было приведено.
Да ладно ля-ля. Про документооборот никто не спрашивал? Водил-мутантов не обсуждали?
Подсовываете чисто математические примеры, причём не думая о конкретной реализации в виде конечного продукта.

lera98

О том что им для форума ломает создавать нормальную объектную концепцию. По крайней мере, это меня касается. ; )

sergey_m

> Ни одного примера не было приведено.
По-моему игровые миры отличный пример.

lera98

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

Marinavo_0507

> Про документооборот никто не спрашивал?
А что документооборот?
Почему ты считаешь, что существующие реализации удачные?
Я вот например вижу вокруг полно организаций, не использующих
системы документооборота, несмотря на наличие компов на рабочих местах.
Вывод: существующие системы пригодны для ограниченного набора случаев.
Насколько удобно хотя бы оформление документов задним числом,
с граничным условием невлияния на данные, которые уже у контролирующих органов?
> Водил-мутантов не обсуждали?
Это пример хорошего дизайна?
> Подсовываете чисто математические примеры,
> причём не думая о конкретной реализации в виде конечного продукта
Математические примеры "подсовывают" ООП-щики почему-то.
Рекомендую ещё раз перечитать тред.
Мой пример с кошками не математический, и я подумал о реализации,
даже про базу данных сказал.
:
> По-моему игровые миры отличный пример.
Именно для таких примеров был создан язык Симула.
То есть, единственный классический пример.
"Промышленные" языки тут довольно плохо подходят, к тому же,
ввиду отсутствия средств борьбы с проблемой, которую указал Fj.
Это подтверждает мою идею о том, что место ООП - в частных проблемно-ориентированных языках.

enochka1145

Вот тебе непотопляемый пример - САПР.
> Я вот например вижу вокруг полно организаций, не использующих системы документооборота, несмотря на наличие компов на рабочих местах.
И как это влияет на реализацию этих самых систем? Не хочешь ДО-, возьми ERP-системы.

lera98

> Я вот например вижу вокруг полно организаций, не использующих
> системы документооборота, несмотря на наличие компов на рабочих местах.
Совкововзрощенных несовременных организаций ты хотел сказать?
> существующие системы пригодны для ограниченного набора случаев.
Я ж говорю: нужны прямые руки, которых в мире ограниченное малое количество.
> Насколько удобно хотя бы оформление документов задним числом,
> с граничным условием невлияния на данные, которые уже у контролирующих органов?
Функциональность от кодеров зависит.
Место ООП - решение любых достаточно сложных задач.

sergey_m

> Место ООП - решение любых достаточно сложных задач.
Начни с переписывания сетевого стека какой-нибудь ОС на ООЯП.

Ivan8209

Особенно --- AutoCAD.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Вот тебе непотопляемый пример - САПР.
AutoCAD использует Лисп в качестве встроенного языка.
> И как это влияет на реализацию этих самых систем?
Походу, никак: эта область оккупирована "боевиками", которые скорее лбом стенку прошибут,
чем научатся чему-то.

enochka1145

Это ты насчёт LISP, что ли?
Так я про реализацию самой САПР, а не о программировании на ней.

enochka1145

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

Ivan8209

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

Ivan8209

Трезвомыслящие прагматики, вроде Чарльза Мура,
вообще клали на ООП и пишут на Форте.
В том числе и САПР.
---
...Я работаю антинаучным аферистом...

enochka1145

// Не воспринимайте слишком серьёзно. Если надо, считайте, что здесь стоит нужный вам смайлик.
Бывают и другие САПР:

Marinavo_0507

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

Это только эмоции.
А на практике видим - задача пользователей не решена.

enochka1145

я про реализацию самой САПР, а не о программировании на ней.

Сам он может быть написан хоть на плюсах --- это никого особо
не волнует. А вот проектирование, оно же программирование,---
на Лиспе. Никого не волнует, как оно устроено там внутри,
пока оно предоставляет простой и понятный интерфейс.

Можешь больше не трудиться мне отвечать.

Ivan8209

Меня это уже давно не столь сильно напрягает.
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."

lera98

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

sergey_m

> А на практике видим - задача пользователей не решена.
Если бы задача пользователей была решена, то сколько разработчиков систем документооборота осталось бы без работы?
Как известно, язык C++ был изобретен для того, что бы конктракты были более долгосрочными.

sergey_m

> сетевой стэк тоже можно сделать, надо только знать, что от него требуется
Сделай. Для начала будем считать, что от него требуется то, что делает стек 4.4BSD.

enochka1145

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

Ivan8209

Ты мою-то ещё не решил, куда тебе больше?
---
...Я работаю антинаучным аферистом...

lera98

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

Ivan8209

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

lera98

Если ты про умножение двух физ.величин - я её решил.

Dasar

>> Вот тебе непотопляемый пример - САПР.
> AutoCAD использует Лисп в качестве встроенного языка.
.Net - они тоже сейчас используют в качестве внутреннего языка.

Ivan8209

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

Ivan8209

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

lera98

Это не решение?

Marinavo_0507

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

Ivan8209

Нет.
Выше уже написано, почему именно.
---
...Я работаю антинаучным аферистом...

lera98

Вы отстанете со своими "боевиками", а? Сами боевики те ещё!

enochka1145

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

lera98

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

sergey_m

> ООП успешнее?
А с этим кстати никто не спорит.

Marinavo_0507

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

Ivan8209

Если бы ООП было успешнее, то AutoCAD был бы написан на Симуле.
Или на чём-то другом не менее исламистском.
---
...Я работаю антинаучным аферистом...

Ivan8209

Это никак не может быть решением, потому что не выполнены
условия задачи.
Решение ad hoc за решение не принимается.
Задача имеет явно методический характер, а приводя решение
"к случаю", ты можешь под полой протаскивать не только ФП,
но и ещё что-нибудь, мало имеющее отношения к ООП как таковому.
Все функционалисты уже не один раз требовали подобное,
но боевикам, складывается такое впечатление, это не удаётся
не только осилить, но даже понять, зачем это надо.
---
...Я работаю антинаучным аферистом...

lera98

Условие:
> Выбираешь любые две физические величины и пытаешься
> умножением получить из них третью.
> Потом объясняешь, чётко и внятно, опираясь на понятия предметной
> области, что, как и почему ты делал.
- Ввожу объектные классы для использующихся в условии понятий - классы: "ф.в." и "умножитель".
(Класс физики я вводил для общности. Ну да не нравится тебе его
присутствие в решении этой задачи - давай выкинем и оставим голый,
но умный "умножитель".)
- Создаю два объекта класса "ф.в." - А и Б - и один класса "умножитель" - У.
- Действую: В=У->(А, Б); , где В - новый объект класса "ф.в.", содержание которого - ответ к задаче.
Теперь объяснил?

Ivan8209

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

Julie16

Только в функциональном подходе этот умножитель скорее всего будет HOF + использование lexical closure. А по сути это ничем не отличается от объекта-умножителя. не надо передергивать факты. Если ты не называешь эту штуку сущностью, а называешь просто функцией, дело твое. Но не надо вешать лапшу на уши.
PS: я придумал ответ который заткнет тебя навечно: при функциональном подходе есть не только умножение. Еще есть функция, которая выполняет это умножение. Зачем эта лишняя сущность? Достаточно же только умножения?

Dasar

> При функциональном подходе есть только умножение, которого достаточно
достаточно для чего?
Мне больше нравится следующее описание (как более мощное):
1. глагол(операция) может быть представлена в виде существительного
2. умножение является операцией.

Ivan8209

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

lera98

> У тебя есть и "умножитель", и собственно умножение.
"Умножитель" содержит в себе не только метод выполнения умножения, но и интерфейс обучения умножителя, собственно, умножать. Ведь для умножения необходимо знать некий набор размерностей ф.в. и как они соотносятся.
> При функциональном подходе есть только умножение,
> которого достаточно.
Кстати говоря, если ты имеешь ввиду ФП выражение В=У(А,Б); , то я могу рассматривать саму функцию У как объект и таким образом оставаться в рамках ООП.
Если же такое недопустимо "рассматривать саму функцию У как объект и таким образом оставаться в рамках ООП", то я - не ООП-программист. Назовусь тогда ООП*-программист. Мож лучше название найду.

Julie16

Чего ты тут наплел?

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

Это и есть умножитель. Или функция в твоем подходе. Функция - тоже сущность.

Ivan8209

Для решения задачи.
Твоё описание неэкономно.
Описание должно быть таким: "Умножение --- это _вот_что_."
Точка.
Без долгих рассусоливаний про глаголы и существительные.
---
...Я работаю дзен-бульдозеристом...

Julie16

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

dedwowan

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

lera98

Да, обосновывать надо всё. И даже то, что умножение - это именно функция, а не объект.
_____________
Всё-таки не могу удержаться от комментария: Господин ПэЖэ, ну и морда у тебя в аватаре

lera98

> ООП не используют для физ. вычеслений
Пока что не используют. И то не факт.

Ivan8209

То есть, кроме собственно умножения там ещё что-то есть.
Тем хуже для ООП.
Если У --- объект, то какой метод у него вызывается?
И что в нём заинкапсулировано?
Кстати, тебе не кажется, что этим ты протаскиваешь ФП?
Равнозначность функций и прочих данных ---
не слышал такого про ООП.
> Назовусь тогда ООП*-программист.
Это как?
Звезданутый ООП-программист?
Хотя, учитывая это:
> Если же такое недопустимо "рассматривать саму У как объект и
> таким образом оставаться в рамках ООП"
не самый худший выбор.
---
...Я работаю антинаучным аферистом...

Ivan8209

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

Dasar

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

enochka1145

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

Ivan8209

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

lera98

> То есть, кроме собственно умножения там ещё что-то есть.
> Тем хуже для ООП.
Аналогичный аргумент:
То есть, в стиле ФП будут глобальные структуры, описывающие соотношения размерностей.
Тем хуже для ФП.
Имхо ни в первом, ни во втором случае ничего плохого нет.
> Если У --- объект, то какой метод у него вызывается?
> И что в нём заинкапсулировано?
Например, метод В=Умножение->Произвести(А, Б);
Я написал выше, что в нём инкапсулировано как минимум.
> Равнозначность функций и прочих данных ---
> не слышал такого про ООП.
>> Назовусь тогда ООП*-программист.
>Это как? Звезданутый ООП-программист?
> Хотя, учитывая это:
>> Если же такое недопустимо "рассматривать саму У как объект и
>> таким образом оставаться в рамках ООП"
> не самый худший выбор.
Ценю юмор.

Ivan8209

Покажешь, как метод одного класса передаётся по значению методу
другого класса? А также создаётся и уничтожается.
И всё это --- во время исполнения.
Кстати, твоё определение ООП на бочку.
---
"Даёшь крылья!"

Dasar

> Кстати, твоё определение ООП на бочку.
Я их уже как минимум два разных давал (второе более уточненное по отношению к первому).

Marinavo_0507

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

enochka1145

Ты действительно считаешь это сколько-нибудь стоящим возражением?

lera98

Резюминг:
Итак, Объектно-Ориентированный подход заключается в фразе:
"Всё является объектом."

Ivan8209

> в стиле ФП будут
Нет, не будут.
Вот засада, да?
> Например, метод В=Умножение->Произвести(А, Б);
А зачем тогда два имени для одного и того же?
---
...Я работаю антинаучным аферистом...

enochka1145

Ну да. У Б. Эккеля в "Thinking in Java" и "Thinkng in C#" чёрным по белому написано: "Everything is an object". Некоторые, правда, забывают, что это всего лишь парадигма, удобная в определённых случаях.

Ivan8209

Ладно, сейчас разыщу.
Ты пока придумывай отмазку, почему делается различие между
объектами и их методами, в т. ч. конструкторами.
---
...Я работаю антинаучным аферистом...

Ivan8209

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

Marinavo_0507

Это возражение против доминирующего "промышленного" подхода.
Например, в Tk более правильный ООП, частично лишённый такого недостатка.

enochka1145

А что тебе мешает реализовать нужный именно тебе МегаСписок?

dedwowan

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

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

ОО подход не потому не нужен, что всё известно заранее,--- не
всё известно заранее, а потому не нужен, что вводит лишние
сущности. А последнее в физике не принято уже полтыщи лет как.

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

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

Ты их много спроектировал? Или хотя бы видел как их проектируют? Ну или хотя бы как они создаются? Я вот первым не занимался, но второго и третьего мне хватило, чтобы понять - без ООП было бы гораздо сложнее.
Вообще твоя последняя фраза выдает этакого идеалиста. Лучше вообще понять, что надо и написать все на ассемблере. Или даже на машином коде.

Marinavo_0507

> А что тебе мешает реализовать нужный именно тебе МегаСписок?
То, что установленные у меня продукты создают именно такие списки, какие создают.

sergey_m

> То, что установленные у меня продукты создают именно такие списки, какие создают.
Но при чём здесь ООП? Старайся придерживаться топика.

enochka1145

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

Marinavo_0507

> Но при чём здесь ООП?
Все свойства такого объекта находятся внутри него.
Не дали ему свойста фильтрации списка - нет такой функциональности у окна.

Dasar

>Покажешь, как метод одного класса передаётся по значению методу
>другого класса? А также создаётся и уничтожается.
>И всё это --- во время исполнения.

var a = new Object;

a.b = Xx;



function Xx

{

  return "zz";

}



WScript.Echo(a.b;



var c = new Object;

c.b = a.b;



WScript.Echo(c.b;



c.b = eval("f; function f{return 1;}");

WScript.Echo(c.b;

sergey_m

> Не дали ему свойста фильтрации списка - нет такой функциональности у окна.
Ну не дали. А каким боком тут ООП? Или в не-ООП такая функциональность появляется автоматически?

Marinavo_0507

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

Ivan8209

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

Marinavo_0507

> Или в не-ООП такая функциональность появляется автоматически?
ls $dir/ | grep $pattern
Чисто функциональный подход.
Для GUI я не слышал про реализации.

enochka1145

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

Dasar

> Ты пока придумывай отмазку, почему делается различие между объектами и их методами, в т. ч. конструкторами
Потому что это удобно.
Потому что у методов и конструкторов разное предназначение.
ps
суп удобно есть ложкой, колбасу резать ножом, макароны вилкой,
СуперМегаУниверсальнойОбобщеннойФункцией - это тоже можно делать, но это будет менее удобно.

enochka1145

> в "промышленном" подходе этого не сделать без перекомпиляции
И часто возникает необходимость добавлять/удалять такие функциональности к спискам в реальной программе? По-моему, случай экзотический. Можешь привести пример? Только не забудь - речь о GUI.

Marinavo_0507

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

lera98

> Ты пока придумывай отмазку, почему делается различие между
> объектами и их методами, в т. ч. конструкторами.
Я не делаю различий между объектом, методом и конструктором, - всё объекты. Поясняю:

class Obj{

private:

   int priv;

protected:

   int prot;

public:

   int publ;

   int func;

   Obj;

};

Выглядит это так:

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

enochka1145

Расширь тип "окно".
---
Стоп! Я гоню. См. сл. пост.

Marinavo_0507

> И часто возникает необходимость добавлять/удалять такие функциональности к спискам в реальной программе?
Сразу во всех реальных программах.
Как это происходит при определении функции.
Про GUI есть несколько обсуждений в архиве, рекомендую ознакомиться.

Ivan8209

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

enochka1145

> А как ты заставишь окно, создающее старый список, получить указатель на новый?
Возьму и исправлю старое определение списка. Что ещё окну останется делать, кроме как создать список нового типа?
Это ООП. Изменения в одних классах не портят другие.

sergey_m

ls $dir/ | grep $pattern

Охуенна! Если бы у тебя в системе не было grep, то функциональный подход был бы виноват? Ты винишь ООП, в том что разработчики GUI не знают кто такое regexp, вот что ты делаешь.

Ivan8209

Погоди, только что ты говорил, что и методы, и конструкторы,
всё --- объекты. Как понимать?
---
...Я работаю антинаучным аферистом...

Marinavo_0507

> Ты винишь ООП, в том что разработчики GUI не знают кто такое regexp, вот что ты делаешь.
Разработчик ls не обязан был знать, что такое regexp. grep работал бы в любом случае.
P.S. вот с функциями высших порядков слабовато в юниксе, поэтому только самые простые примеры
вроде этого можно показать.

lera98

См определение ООП.
А что, по рисунку не ясно, как я их считаю объектами?
Если ты в тупике от этого - вспомни, что я писал про INC и про EAX.
Мой объект Obj состоит из пяти объектов, имеющих выходы на разных слоях Obj. Всего шесть объектов на рисунке.

Marinavo_0507

> Возьму и исправлю старое определение списка.
Потом перекомпилировать все программы?
Ну я понимаю, что сейчас может и не все, типа .Net.
Но факт в том, что эта проблема была создана искусственно.
Создаём проблемы, долго придумываем им решения, по ходу дела сменяя
несколько "промышленных" технологий.
Вот способ удержания лидерства.

Ivan8209

Говорят, есть scsh.
А ещё можно сделать такое: chsh -s `which your-FPL` `whoami`
---
...Я работаю антинаучным аферистом...

sergey_m

> Разработчик ls не обязан был знать, что такое regexp. grep работал бы в любом случае.
По-твоему нельзя сделать так же если ls и grep обмениваются не потоком, а объектом?

Marinavo_0507

> По-твоему нельзя сделать так же если ls и grep обмениваются не потоком, а объектом?
В типичном GUI так и происходит.
Не вынесли в интерфейс объекта-списка сообщение типа "отфильтровать" - пользователь объекта сосёт лапу.

Dasar

> Погоди, только что ты говорил, что и методы, и конструкторы,
> всё --- объекты. Как понимать?
Для тебя нов тот факт, что одно и тоже можно объяснить с разных позиций?
Что одно и тоже может быть представлено по разному?

Ivan8209

Чьё?
Да ты вообще особый, звезданутый боевик.
Прочитай что-нибудь про Тезис Чёрча.
---
...Я работаю антинаучным аферистом...

Ivan8209

Расписывай сообщения.
---
...Я работаю антинаучным аферистом...

enochka1145

> Но факт в том, что эта проблема была создана искусственно.
Ну не создавай искусственных проблем. По крайней мере, я так и не увидел проблему. Тем более, новые .dll-, .so- и .class-файлы могут помочь.
> Создаём проблемы, долго придумываем им решения, по ходу дела сменяя несколько "промышленных" технологий. Вот способ удержания лидерства.
Интересный взгяд. А что предложишь ты? Изучить все
ash, bsh, csh, ..., zsh, awk, gawk, sed, grep, tcl, tk, lisp, ocaml, perl, python..., а потом говорить: "М-м, у этой проблемы есть элегантное ФЯ-решение на языке X"

sergey_m

Не вынесли в интерфейс объекта-списка сообщение типа "отфильтровать" - пользователь объекта сосёт лапу.

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

Dasar

> Не вынесли в интерфейс объекта-списка сообщение типа "отфильтровать" - пользователь объекта сосёт лапу.
еще раз повторю: это проблема замыканий вообще, а не проблема ООП-подхода.
Ты до сих пор не показал, как можно исправить на ФЯ последствия поспешных замыканий
Если у тебя в ФЯ-шной программе будет жестко зашит вызов ls-а, то ты тоже уже ничего не сделаешь.

Marinavo_0507

"Отобразитель" - и есть тот объект, который принимает сообщения от пользователя.
Именно про него разговор. Он называется ListBox или как-то ещё.

enochka1145

Отнаследуй от окна, которое создаёт этот ListBox и заставь его создавать твои MegaListBox-ы.
Иначе может оказаться, что и во всех остальных программах, которые пользуются стандартными диалоговыми окнами, изменится поведение. А если это и есть то, что тебе надо - ну измени определения стандартного диалогового окна (напр., File Open). ОС и IDE - они же не телепаты, не знают, чего кому хочется.

lera98

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

Ivan8209

Если есть доступ к промежуточному представлению,
то навешивается преобразователь. Тот же grep.
Не очень часто встречал неявные замыкания у функционалистов.
А вот в ООП, судя по всему,--- обычное дело.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

Функциональный код: чем меньше напишешь, тем более общий интерфейс.
Не будешь вставлять "ls" - получишь возможность работы с произвольной функцией.
Наиболее естественно получается именно generic-код.
ООП-код: нужно заранее включать в интерфейс все свойства объекта.
Если что забыл, оно будет недоступно для пользователей.
Наиболее общими оказываются классы со сложным, развесистым интерфейсом.
Учиться писать generic-код нужно в любом случае, но в ФП он к тому же получается короче,
что уменьшает число ошибок, которые нужно будет исправлять, и оставляет на это исправление больше времени,
так как простые интерфейсы проектируются быстрее сложных и развесистых.

Ivan8209

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

Marinavo_0507

> Отнаследуй от окна, которое создаёт этот ListBox и заставь его создавать твои MegaListBox-ы.
Там в методе создания окна ещё 20 элементов создаются.
Предлагаешь копировать этот код?
> ну измени определения стандартного диалогового окна (напр., File Open)
А если стандартный только список, а окно нестандартное?

lera98

> ООП-код: нужно заранее включать в интерфейс все свойства объекта.
> Если что забыл, оно будет недоступно для пользователей.
> Наиболее общими оказываются классы со сложным, развесистым интерфейсом.
Неверно, ты забыл об абстракции и наследовании. Базовые классы, на основе которых создаются другие базовые классы, на которых ....., на которых создаётся твой класс, имеют как правило, примитивную структуру.

lera98

Устал от твоего чёрного юмора.

Dasar

> Не очень часто встречал неявные замыкания у функционалистов.
даже в примере у GF-а были замыкания, пусть неявные - но все же.
> Если есть доступ к промежуточному представлению,
> Не очень часто встречал неявные замыкания у функционалистов.
ты много видел больших программ написанных на ФЯ?
причем таких, которые активно взаимодействуют с окружающим миром, с пользователем, а не являются вещью в себе. Которые поддерживают настройку под конкретного пользователя и т.д.
> Если есть доступ к промежуточному представлению,
в ООП все тоже самое, если есть доступ к промежуточному представлению, то можно или расширить объект (в динамическом ООП либо заменить создание объекта на необходимый (в статическом ООП).

Dasar

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

Marinavo_0507

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

Dasar

> Там в методе создания окна ещё 20 элементов создаются.
> Предлагаешь копировать этот код?
1. можно скопировать
2. если есть малая модульность, то собрать новый объект из этих малых модулей.
3. написать объект-адаптер, которые перенаправляет все старые вызовы на внутренную копию старого объекта.
ps
если у тебя по каким-то причинам ls-не поддерживает работу с китайскими символами,
ты что будешь делать?
будешь копировать код всего ls-а?

Dasar

> Проблема, когда это находится в стандартной или не очень библиотеке, исправить которую не так просто.
Если библитека будет ФЯ-шная и замкнутая, что-то изменится?

Ivan8209

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

Dasar

ad hoc изменения насколько легко делаются?
например, изменить во всем emacs-е вывод справа налево (включая меню, вывод текста, ввод команд и т.д.)

добавить вывод векторной и 3d-графики?

Marinavo_0507

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

Dasar

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

Marinavo_0507

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

Dasar

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

Ivan8209

Несложно.
Примеры есть.
---
...Я работаю антинаучным аферистом...

Marinavo_0507

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

lera98

Насчет UniversalMind - зацени строчки из конфига UnrealTournament (99):

Render=Render.Render
GameEngine=Engine.GameEngine
EditorEngine=Editor.EditorEngine
...
Input=Engine.Input
Canvas=Engine.Canvas

Вроде ничем не хуже моих "физик" ; )
PS: даже круче: тута у рендера свойство рендер! Преклоняюсь перед непомерной хитрожопостью Рекурсию намутили бы Render.Render.Render.Render.Render.Render.Render.Render.Render.....

Ivan8209

Доводы рода "миллионы мух не могут ошибаться" не рассматриваются.
---
...Я работаю антинаучным аферистом...

lera98

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