Здравствуйте, Ikemefula, Вы писали:
V>>Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.
I>Так у вас что, живые ссылки на эти пустые списки ?
Конечно, живые. Пока живо сообщение, жив список его полей, даже если он пуст. Сообщение-то будет обработано именно после того, как извлекут из списка. Это очередь задержки на выравнивание джиттинга UDP-пакетов.
I>Похоже вы придумали проблему что бы элегантно решить по месту возникновения Дешевле хранить нуль и создавать пустой список.
Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...
V>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит. I>Ты привел конкретные цифры только с третьей попытки.
С первой, после того, как ты попросил конкретные цифры. Со второй я привел сценарий.
Здравствуйте, Ikemefula, Вы писали:
V>>Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.
I>Для GC это мизер Издержки на очереди много больше издержек на выделение памяти. Я накидал тест, как ты говоришь, и в ём инстанцирований в 8 раз меньше, нежели без очередей,
Всё с вами ясно... Умудриться написать очередь, которая в 8 раз тяжелее GC — это весчь... )))
У нас она намного легче, чем GC. Не пробовал такую штуку, как "интрузивный список"?
I>А то что вы храните ссылки на пустые списки — это ваша проблема.
Этот пустой список в моем варианте — один на всех.
I>Как экономию памяти это можно принять, правда не ясно, зачем вообще хранить ссылку на пустой список
Рядом ответил на этот же вопрос от тебя же.
V>>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика. I>Так тест будет а то опять окажется что у тебя условие снова изменилось ?
Дык, ты не привел своих данных. Сколько сообщений в секунду ты выжал на выхолощенном примере?
А мне сюда исходники ложить, чтобы ты их тестировал или как?
V>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит. I>Проблемы оттого что вы хранили ссылки на пустые коллекции.
Не только. Проблемы от того, что мы храним сами сообщения. Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.
В общем, лечение было многостадийное. Объекты внутри "выпрямлялись". Те объекты по сценарию, которые переживают 0-е поколение — переиспользовались. Разумеется, рано или поздно объекты из пула они вообще уходят во 2-е поколение и GC их "не видит", поэтому такое большое кол-во объектов его перестает напрягать. Главное в этих объектах — ссылки не дергать. Поэтому, сообщения без дополнительных полей берутся из одного пула, а с полями — из другого. То бишь фактически такое присвоение пустого списка вообще идет однократное в момент создания объекта и затем при переиспользовании из пула никаких лишних телодвижений. В "разогретой" системе фактически никаких new. Операции с сокетами были переписаны на интеропе на свой интерфейс, бо родной дотнетный корявый и тормозной.
. Не заметить то, что речь в нем идет вовсе не о теоретике, довольно сложно, не находишь?
ВВ> До этого вроде бы как о парадигмах говорили.
И что? Парадигмы на практике не нужны?
ВВ>В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает.
Всемирный заговор разработчиков языков?
ВВ> ФП нормальное можно построить либо вообще без системы типов
Значит в жопу такое нормальное ФП, делов то.
AVK>>Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями. ВВ>Смотря, где. В Скале, по-моему, уже скоро тройное будет
А Скала на промышленный язык и не тянет. Хаскель, вид сбоку.
ВВ>>>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*. AVK>>Для чего важно?
ВВ>Для того, чтобы наконец понять — утверждение, что ФП является более самодостаточной парадигмой, чем ООП — не голословно
Т.е. с целью победить в споре. ЧТД.
ВВ>>>С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница. AVK>>Какая разница в практическом плане?
ВВ>У ФП есть будущее и почва для развития. У ООП — нет.
Главное — верить.
ВВ>Кстати, у меня почему-то возникает упорное чувство, что ты резко переключил дискуссию в какое-то совершенно другое русло.
Видимо, потому что ты, как обычно, понял не то что я хотел сказать, а что то свое.
ВВ>Ну ты вот любишь Синклера по этому поводу цитировать
Ога. Главное, в тему фраза.
ВВ> И что-то все идет к тому, что вот это самое "ООП — это про поведение" настолько это самое ООП сужает, что оно вообще в какую-то экзотическую концепцию превращается.
Есть еще один вариант — ты просто его не понял.
ВВ>Вообще с "чистым ООП" должно быть все достаточно просто. Мы ведь можем определить, что такое ООП, я полагаю?
Не уверен, если речь об абсолютно формальном определении.
ВВ>Вот только реальные языки обычно не такие.
Верно. Поэтому в жопу концепцию чистого ООП.
ВВ>А какая тебе тема интересна?
Гы. Могу крупными буквами, если ты за несколько топиков еще не понял. УДОБСТВО РЕШЕНИЯ ЗАДАЧ.
ВВ> Вроде как второй день говорим про ФП и ООП — теперь оказывается, что неинтересно
Этот прием называется подтасовка. Я нигде не говорил, что мне неинтересны ФП и ООП, я прямо сказал, что мне не интересна идеологическая чистота концепций. Неужели без подобных приемчиков никак?
ВВ>Все, что ты тут перечислил, есть и в том же ФП.
Скажем так — там это можно съэмулировать. Хуже того, структурного программирования это тоже касается. Ужась, правда?
ВВ> Но ФП от этого ООП не становится.
Конечно нет.
ВВ> У ООП есть еще одна такая маленькая деталь, которую вы постоянно упоминаете — поведение.
И что не так с поведением сервисов?
AVK>>Не ты ли недавно доказывал, что наследование контрактов не нужно? ВВ>Я не доказывал, я спрашивал.
Очень смешно.
ВВ> Кстати, вопрос был не про ООП.
Интерфейсы с наследованием без ООП? Еще смешнее. Пиши еще.
ВВ>Ага, знаю. Это трюк из области — формулируем задачу в терминах ООП
Подожди, подожди. Ты только что доказывал, что SOA это не ООП. А теперь уже задача в терминах ООП. Как интересно.
ВВ>, потом просим один-в-один перевести это в ФП
Я тебя не просил перевести что то там в ООП. Следи за руками — в SOA контракт это фундаментальное понятие, центральная точка всей архитектуры. Контракт сервиса состоит из набора контрактов операций. Каждый контракт операции описан параметрами, возвращаемым значением и возможными ошибками. Типы параметров и возвращаемое значение описываются отдельным контрактом-схемой. Типы ошибок так же описываются своим контрактом. Это все из определения SOA, никаких внешних ООП терминов. Покажи, как описание контракта сервиса будет выглядеть на ФП языке. Вроде нормальная задача, и вопрос без подковырок — я сам не очень представляю себе оптимальное решение.
AVK>>Круто. А еще есть четкая граница между персистентными данными в БД и неперсистентными в памяти. Тоже будем новую парадигму придумывать?
ВВ>Зачем?
Наверное затем же, зачем новая парадигма понадобилась RPC.
ВВ> Она уже выдумана. Анемичная модель называется. И не ООП, и не... В общем неведома зверушка.
Ну да, тебя послушать так ООП вообще нет. Жопа есть, а слова нету.
ВВ>Кстати, хороший пример. Я сам хотел его привести. Тоже тот случай, когда ООП-ная косвенность как бы не сильно популярностью пользуется, и Фаулера с его репозитариями народ что-то не шибко не любит в общей-то массе своей.
И чего? Кто то спорит тут с этим? Или в ФП ситуация чем то лучше? Чего там в Хаскеле — ХаскеллДБ, который просто отказался от преобразования реляционной модели к чему бы то ни было, как, впрочем, и нормальные реализации LINQ2DB?
AVK>>Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.
ВВ>Примерчик чего?
Правильного функционального подхода к гую.
ВВ>Я вижу, что, скажем, за последние 10 лет в ФП неплохо прогрессирует. Так что 30 лет ждать, может, и не придется.
Главное — верить.
AVK>>Сколько? И ФП и гуевым фреймворкам уже много десятков лет, не новые, мягко говоря, вещи? Что танцору мешает? ВВ>ФП настоящему не так много лет как тебе кажется.
Ах да, как же я мог не знать. Главное, в следующий раз, когда кто то тут будет рассказывать про то что ФП стар, суперстар, цитатку твою ввернуть.
ВВ>А что не так с компонентностью?
Она утонула Нет ее. Ну кроме тех Ф-языков, в которых есть поддержка ООП.
ВВ>Мне казалось, что с целью разобраться в том, что же такое *в действительности* ФП
Спасибо, не надо. Я уж как нибудь сам.
ВВ>. Если такой цели нет
А ты что, всерьез считаешь, что моей целью было узнать из твоих постов, что такое ФП? Ну вот честно, ответь.
ВВ>Вот только симула фактически заложила весь фундамент современного ООП
Ты ее видел, Симулу ту? Идеи похожи, цель совсем не та, так что и развитие совсем не в ту сторону. Ранний ООП это смолток. 1972, примерно когда ML народился. Кея не зря папкой ООП кличут, а вовсе не Нюгорда с Далем.
Это как с колесным пароходом — колеса похожи на телегу, но телега вовсе не предок.
ВВ>, которое не шибко-то и поменялось с тех пор. А Лиспе от ФП — две чайных ложки и вообще это язык не функциональный. ВВ>Что-то более или менее похожее — это уже скорее Хоуп. И в большей степени Миранда.
А педивикия нагло врет про IPL как первый действительно Ф-язык. 1954 год.
AVK>>Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом?
ВВ>Написал бы пару АлгТД
Учитывая, что кое кто тут утверждал, что кортежи и АлгТД это одно и тоже, ты сделал мне смешно.
ВВ>Могу лишь повторить — ФП более самодостаточная концепция.
По барабану.
ВВ> Но тебе, похоже, это уже неинтересно.
Мне это с самого начала было не очень интересно в контексте данного топика.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>>>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. AVK>>Нет, не начинает. V>Начинает для заведомо рекурсивных и бесконечных программ, будучи исполненными в энергичной манере.
Мысль не понял.
V>>> Некие выражения вычисляются заведомо РАНЬШЕ других AVK>>Ну и что? Это не приводит к ни к каким сайд-эффектам. V>Приводит к тому, что заведомо неудачные ветки не вычисляются. Вроде бы и не сайд-эффект
Не вроде бы, а точно не сайд эффект.
V>, если представить вычислитель с бесконечным быстродейтсвием и бесконечной памятью... А в конечных характеристиках этот момент — разминка для воображения.
Трансляция ФП в реальную императивную машину — тема для совершенно отдельного разговора. Тут важно, что чистоту ФП функция if не нарушает, и все практические следствия из этого, типа возможности мемоизации или гарантии thread safety остаются полностью справедливыми.
Мемоизация кстати, еще один тебе аргумент в твою мегатеорию, которая есть чуть менее чем во всех Ф-языках, мутабельна до самой глубины своей грязной души.
AVK>>Есть. Предикаты как раз ветвление для тел правил и задают.
V>Ну дык, это в процессе работы вычислителя происходит ветвление.
Это и на логическом уровне так, что в Л-языках, что в data-машинах. Непрерывного потока исполнения нет, да, но если настаивать на принципиальности этого, тогда и ФП побоку, там тоже этого нет.
V> Просто в ФП-языке можно глазами пробежаться по коду и сэмулировать поток исполнения
Садись, двойка. Нет, нельзя. Реальные компиляторы Ф-языков делают кучу всяких переписываний — замена хвостовой рекурсии на цикл, мемоизация, схлопывание кучи вложенных функций и т.д. Чистый код позволяет очень много над собой измываться без боязни сломать семантику.
V> А в Прологе так не пробежишься, бо правила могут быть объявлены в произвольном порядке, затрудняющем восстановить ход работы (поток исполнения) вычислителя.
Ага, я у гадал. Вот ты и попался — и п.2 из твоего определения за бортом. Итого — 3 из 3 базовых концепций СП в ФП отсутствуют.
AVK>>Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию. V>Дык, если брать OCaml
Да можешь взять что угодно. Вот только доставание отступлений от чистого ФП из реальных языков в качестве доказательства происхождения концепции ФП от СП — чистейшей воды мухлеж.
V>>>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл. AVK>>Нет, не дает. Кури определение чистоты. V>Дык, уже год как бросил...
Очень смешно.
V>Сайд-эффект маскируется созданием нового значения из старого и ростом стека.
Он не маскируется, он отсутствует.
V>Именно на этом важном принципе работает раскрутка рекурсии в цикл, даже если на каждом шаге изменяется более одной переменной-параметров ф-ии.
Спасибо КО, я в курсе про связь рекурсии и цикла. Только это не отменяет того простого факта, что рекурсия может быть чистой, а цикл нет. И пофигу как оно там в процессоре раскручивается, на уровне семантики программы все предельно чисто. Это важно для той математики, прежде всего, которая за ФП стоит.
V>Всего-то требовалось немного воображения относительно аргументов оппонентов и хотя бы на минуту перестать считать окружающих дураками.
Я лично тебя дураком не считаю, я всего лишь удивляюсь удивительным пробелам в знаниях, которые ты демонстрируешь.
AVK>>Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?
V>Фортран, ес-но.
Это все?
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, samius, Вы писали:
V>>Значит, так выясняли. Поведение ес-но есть. И уже раз 100 говорили, что дело в подробностях задачи, которые надо зафиксировать в ТЗ. S>Нет никакого поведения у двери кроме как подчиняться законам природы.
Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться. То бишь, послать сообщение "откройся внутрь" объекту-двери и само открытие двери — это разные события.
S>А то что ты совокупность действующих на дверь сил заменяешь методом Откройся() — так это не двери забота. Это особенности твоей модели, а не двери вовсе.
Я ничем не заменяю, я не могу добиться внятного ТЗ на эту дверь. Ес-но, ТЗ можно сформулировать так, чтобы всю дверь можно было заменить булевской переменной, над которой что ООП, что ФП будут оверкиллом.
S>>>И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь. V>>Где ты эту траву берешь? S>У Кэя взял.
Такой у него точно не было ))
V>>Ох... Было сказано "функциональный объект". V>>А почему так? — из-за природы ФВП, т.к. они прямо по определению хранят в замкнутом контексте некоторые данные. S>хранят, но с ООП-шностью этих данных в чистом языке напряг. Так что в топике об ООП лучше не называть эти данные объектом.
Позволь мне разобраться самостоятельно, что как называть. "функциональный объект" — это известный устоявшийся термин. Это именно то, как выглядит ФВП с точки зрения ООП, то бишь его внутренняя конструкция. И да, замыкания могут быть мутабельными... Хотя бы в Лиспе.
V>>Ну да, вас 3-5. Как и во все времена. Просто самые плодовитые. Один из этой "группы" какой-то неактивный в последнее время, дык, смотрю, замена подоспела... )) S>Самый плодовитый тут однозначно ты.
Это временно ... Приходится гонять тесты на виртуалках, а оно "само и долго"... )))
V>>Дык, а про что конкретно он так писал? Есть брать атомы в смысле атомов из Лиспа, то их можно натянуть разве что на объектную identity. S>да, об identity items речь была. S>>>На самом деле от Лисп-атома до кортежа функций не так далеко. V>>Бесконечно далеко. S>ну-ну
По-я-сни.
S>>>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.
V>>А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле? S>Конечно. Примерно как между статикой и динамикой.
Дык, если наследования нету, то компилятор С++ вообще виртуальные вызовы на обычные заменяет аж бегом. В обход vtable. В этом плане у кого больше статики?
V>>Начинает для заведомо рекурсивных и бесконечных программ, будучи исполненными в энергичной манере. AVK>Мысль не понял.
Мысль в том, что если исполнять реальные программы на Хаскеле в энергичной манере, то для большинства программ получим мгновенное бесконечное зацикливание на рекурсиях.
V>>Приводит к тому, что заведомо неудачные ветки не вычисляются. Вроде бы и не сайд-эффект AVK>Не вроде бы, а точно не сайд эффект.
Таки основная мысль была о выпрямлении порядка вычислений, которые больше присущи императиву.
V>>, если представить вычислитель с бесконечным быстродейтсвием и бесконечной памятью... А в конечных характеристиках этот момент — разминка для воображения. AVK>Трансляция ФП в реальную императивную машину — тема для совершенно отдельного разговора. Тут важно, что чистоту ФП функция if не нарушает, и все практические следствия из этого, типа возможности мемоизации или гарантии thread safety остаются полностью справедливыми. AVK>Мемоизация кстати, еще один тебе аргумент в твою мегатеорию, которая есть чуть менее чем во всех Ф-языках, мутабельна до самой глубины своей грязной души.
Дык, именно в этом соль. Ленивое выполнения + мемоизация — это унутре изменяемое состояние вычислителя. Здесь любопытен такой момент, что ленивое исполнение само по себе начинает давать некие гарантии коду. То бишь внутренний побочный эффект механики вычислителя начинает давать какие-то гарантии исходному чистому ФП-коду. Как тебе такое положение вещей?
AVK>Это и на логическом уровне так, что в Л-языках, что в data-машинах. Непрерывного потока исполнения нет, да, но если настаивать на принципиальности этого, тогда и ФП побоку, там тоже этого нет.
V>> Просто в ФП-языке можно глазами пробежаться по коду и сэмулировать поток исполнения
AVK>Садись, двойка. Нет, нельзя. Реальные компиляторы Ф-языков делают кучу всяких переписываний — замена хвостовой рекурсии на цикл, мемоизация, схлопывание кучи вложенных функций и т.д. Чистый код позволяет очень много над собой измываться без боязни сломать семантику.
Мало ли, что компилятор в процессе оптимизации переписывает? Компилятор С++ может переписать вызов ф-ии на инлайн и вместо оперирования исходной копией значения посчитать, что конкретно в этом месте можно оперировать без копий. Дык, пусть он там что угодно делает, лишь бы сохранялась семантика, указанная мной, программистом, в исходнике. Точно так же и компилятор ФП, он может переписать много, но семантика результата должна быть точно такая же, как я получаю, пробегаясь по коду глазами... Иначе, как программировать-то?
V>> А в Прологе так не пробежишься, бо правила могут быть объявлены в произвольном порядке, затрудняющем восстановить ход работы (поток исполнения) вычислителя. AVK>Ага, я у гадал. Вот ты и попался — и п.2 из твоего определения за бортом. Итого — 3 из 3 базовых концепций СП в ФП отсутствуют.
Пролог не ФП ни разу.
AVK>>>Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию. V>>Дык, если брать OCaml AVK>Да можешь взять что угодно. Вот только доставание отступлений от чистого ФП из реальных языков в качестве доказательства происхождения концепции ФП от СП — чистейшей воды мухлеж.
Не собираешься ли ты обсуждать такое ФП, которого в природе не существует?
V>>>>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл. AVK>>>Нет, не дает. Кури определение чистоты. V>>Дык, уже год как бросил... AVK>Очень смешно.
Мне от предложений "курить" давно не смешно.
V>>Сайд-эффект маскируется созданием нового значения из старого и ростом стека. AVK>Он не маскируется, он отсутствует.
А, ну да.
V>>Именно на этом важном принципе работает раскрутка рекурсии в цикл, даже если на каждом шаге изменяется более одной переменной-параметров ф-ии.
AVK>Спасибо КО, я в курсе про связь рекурсии и цикла. Только это не отменяет того простого факта, что рекурсия может быть чистой, а цикл нет.
Так был в курсе, просто "баба Яга против?" ))
Это я уже второй пост молчу, что в обсуждаемом смысле оно не принципиально. Ср-ва организации "повторения одних и тех же участков кода" в ФП есть или нет? Мне нужен прямой ответ на прямой вопрос.
AVK>И пофигу как оно там в процессоре раскручивается, на уровне семантики программы все предельно чисто. Это важно для той математики, прежде всего, которая за ФП стоит.
Дык, математика как раз использует рекурсии для повторения. См. лямбда-исчисление Черча. Вызов из лямбды самой себя невозможен (это же очевидно!).
Получив лямбда-терм, представляющий тело рекурсивной функции или цикл, передав себя в качестве первого аргумента, комбинатор неподвижной точки возвратит необходимую рекурсивную функцию или цикл.
См. Y-комбинатор, для чего он вообще нужен.
V>>Всего-то требовалось немного воображения относительно аргументов оппонентов и хотя бы на минуту перестать считать окружающих дураками. AVK>Я лично тебя дураком не считаю, я всего лишь удивляюсь удивительным пробелам в знаниях, которые ты демонстрируешь.
Пробелы могут в постах, дабы не повторяться. Да и свой подход я давно обрисовал: сначала даю вход и выход. Если путь из первого во второе неочевиден — будут и подробности и закрытие пробелов.
Ну и в самой "философии" таки хочется смотреть на привычные вещи под разными углами зрения. Иначе нафига такой раздел форума вообще? Банальности мы можем почитать и в Вики.
AVK>>>Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?
V>>Фортран, ес-но. AVK>Это все?
Здравствуйте, Ikemefula, Вы писали:
I>Массы и линейных размеров нет, зато поведение и свойства есть. Эта математическая абстракция есть заимствование из физического мира, представь, передача информанции на уровне сообщений, каналов и даже пакетов появилась еще в те времена, когда пароход феодосия еще шлюпкой был.
Брр. Давайте не будем углубляться в дебри. Математика и физика разделились относительно недавно; тем не менее, под термином "физический объект" подразумевают не просто "что-то со свойствами", а что-то с определёнными свойствами.
I>Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает.
В том-то и дело, что учебники вводят иллюзию, что надо копировать объекты Реального Мира. Лужа и Камень являются очевидными вариантами.
I>Физический объект имеется ввиду заимствование из реального мира, а не корова с выменем, рогами и хвостом.
Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, SV., Вы писали:
SV.>А хранение и вычисление где будут реализованы?
В операциях, заданных над этим ADT. Для этого нет необходимости в ООП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, SV., Вы писали:
SV.>>>И, кстати, откуда у вас статичность взялась? S>>Как откуда? В приведённом коде метода нет никаких обращений к нестатическим мемберам. Так нахрена ему быть экземплярным? SV.>А идентификатор счета где?
А он неявно присутствует в определении allTransfers. Достаточно иметь ещё один статический метод
public static IQueryable<Transaction> GetAllAccountTransactions(string accId, IQueryable<Transaction> allTransactions)
{
return from t in allTransactions where t.TargetAccount == accId select t;
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>>>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования) S>>А моя основная мысль, что счёт не ведёт себя как объект в ООП. Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".
DG>Как минимум стоит тогда вернуться к основам. DG>Я утверждаю, что объект — это ментальная модель служающая для удобства описания происходящего, обладающая рядом характеристик (а дальше по любому классическому учебнику ООП).
Вы путаете две вещи. Начинаете вы с философского понятия "объект", который всего лишь противопоставляется субьекту. Такой объект вполне может быть нечётким, и недоопределённым, и т.п.
С этим никто не спорит. DG>Если ты с этим не согласен, тогда приведи слова кого-нибудь из классиков, где утверждается, что объект должен реально сущестовать как объект, или у кого хотя бы говориться, что такое реальное существование объекта.
DG>Соответственно, по этому определению, например, и linux-овый file и winapi-шный файл — являются объектами. И тред на форуме rsdn.ru тоже является объектом.
А потом вы внезапно перепрыгиваете в ООП-шное определение объекта, которое значительно более строгое. Но при этом почему-то пользуетесь двумя разными определениями взаимозаменяемо.
Файл в винде и линуксе как раз похож на ООП-шный объект, и ОО-дизайн в WinAPI торчит довольно сильно.
Но ООП требует от объекта некоторых минимальных вещей, в частности — идентичности. Философский объект "верёвка" запросто может состоять из двуз философских объектов "конец верёвки" и одного "середина верёвки". ООП-шный объект так построить не удастся — потому, что нет возможности провести чёткую границу между "серединой" и "несерединой". См. "где начало того конца, которым заканчивается начало".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
AVK>>>Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.
ВВ>>Примерчик чего?
AVK>Правильного функционального подхода к гую.
Подумалось мне что-то... А ведь классическое «висит окно, принимает события» — это классический Erlang Насколько это ФП — это уже ХЗ
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Соглашусь, посетитель был бы кстати. Но ничто не мешает прикрутить внешнюю диспетчеризацию
AVK>Только это уже куча писанины, и, в отличие от внутреннего визитора, обработка всех вариантов компилятором не гарантируется.
Если бы визитора генерил компилятор ФП, то он мог бы давать какие-то гарантии. Но в рукописном внутреннем визиторе тоже нет гарантий обработки всех вариантов.
S>>или dynamic-ах.
AVK>Ты это серьезно?
почему бы и нет, для случаев где за тактами бегать не надо
. Не заметить то, что речь в нем идет вовсе не о теоретике, довольно сложно, не находишь?
Ну да, для того, чтобы рассуждать о парадигмах, разбираться в них совершенно необязательно. А зачем? Главно же удобство.
Просто забавно, было наблюдать, как ты весьма охотно со мной спорил о чистоте концепций, а потом резко так слился в сторону практики.
Вообще уровень дискуссии очень характерно развивается — посчитай, сколько раз в твоем сообщении слово "жопа" встречается.
ВВ>>В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает. AVK>Всемирный заговор разработчиков языков? ВВ>> ФП нормальное можно построить либо вообще без системы типов AVK>Значит в жопу такое нормальное ФП, делов то.
А может лучше такую систему типов отправить по этому назначению? Зачем новый дом на старом фундаменте строить. Есть и другие системы типов, причем давно.
AVK>>>Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями. ВВ>>Смотря, где. В Скале, по-моему, уже скоро тройное будет AVK>А Скала на промышленный язык и не тянет. Хаскель, вид сбоку.
Недавно ты утверждал, что будущее за такими языками как Скала. Теперь что, Скала уже экзот?
ВВ>>>>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*. AVK>>>Для чего важно? ВВ>>Для того, чтобы наконец понять — утверждение, что ФП является более самодостаточной парадигмой, чем ООП — не голословно AVK>Т.е. с целью победить в споре. ЧТД.
Мне казалось, что идет обсуждение, в котором выдвигаются некие тезисы. Целью является эти тезисы доказать или опровергнуть. У же тебя, видимо, какой-о другой взгляд на происходящее.
В споре я уже и так победил. А твои контр-аргументы превратились в "жопу" и "НУ И ЧТО". Другой вопрос, что заметят это один или два человека. Так что пользы от этого мало.
ВВ>>>>С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница. AVK>>>Какая разница в практическом плане? ВВ>>У ФП есть будущее и почва для развития. У ООП — нет. AVK>Главное — верить.
Верят обычно во что-то бездоказательное. Так что в данном случае верить совершенно не обязательно. Другой вопрос, что любой потенциал может быть загублен безразличием и тупостью — это уже действительно другой вопрос, и его уже мне обсуждать не хочется.
ВВ>> И что-то все идет к тому, что вот это самое "ООП — это про поведение" настолько это самое ООП сужает, что оно вообще в какую-то экзотическую концепцию превращается. AVK>Есть еще один вариант — ты просто его не понял.
Конечно, возможно. Хороший способ это показать — дать свое понимание.
AVK>Этот прием называется подтасовка. Я нигде не говорил, что мне неинтересны ФП и ООП, я прямо сказал, что мне не интересна идеологическая чистота концепций. Неужели без подобных приемчиков никак?
Я не понимаю, наверное, прежде чем рассуждать о каких-то парадигмах, надо очертить, какие-то границы у этих парадигм, понять, что в них входит, а что — нет. А "практический аспект" никуда не уйдет.
ВВ>>Все, что ты тут перечислил, есть и в том же ФП. AVK>Скажем так — там это можно съэмулировать. Хуже того, структурного программирования это тоже касается. Ужась, правда?
Идентичность, инкапсуляция — все это именно что есть, а не эмулируется.
ВВ>> У ООП есть еще одна такая маленькая деталь, которую вы постоянно упоминаете — поведение. AVK>И что не так с поведением сервисов?
А никакого поведения у сервисов попросту нет. Сервис с поведением — это даже звучит смешно. Ты на ходу выдумываешь?
AVK>>>Не ты ли недавно доказывал, что наследование контрактов не нужно? ВВ>>Я не доказывал, я спрашивал. AVK>Очень смешно. ВВ>> Кстати, вопрос был не про ООП. AVK>Интерфейсы с наследованием без ООП? Еще смешнее. Пиши еще.
Интерфейсы и из наследование вообще-то ортогональны ООП. Ты считаешь, что ООП автоматически вместе с интерфейсами появляется? Слушай, а может, это ты неправильно понимаешь, что такое ООП?
ВВ>>Ага, знаю. Это трюк из области — формулируем задачу в терминах ООП AVK>Подожди, подожди. Ты только что доказывал, что SOA это не ООП. А теперь уже задача в терминах ООП. Как интересно.
SOA это конечно не ООП, однако появилось в ООЯ, и интегрируется в них действительно неплохо. Переносить as is в ФП что-то такое, что выросло на дрожжах ООЯ не совсем корректно.
ВВ>>, потом просим один-в-один перевести это в ФП AVK>Я тебя не просил перевести что то там в ООП. Следи за руками — в SOA контракт это фундаментальное понятие, центральная точка всей архитектуры. Контракт сервиса состоит из набора контрактов операций. Каждый контракт операции описан параметрами, возвращаемым значением и возможными ошибками. Типы параметров и возвращаемое значение описываются отдельным контрактом-схемой. Типы ошибок так же описываются своим контрактом. Это все из определения SOA, никаких внешних ООП терминов. Покажи, как описание контракта сервиса будет выглядеть на ФП языке. Вроде нормальная задача, и вопрос без подковырок — я сам не очень представляю себе оптимальное решение.
Это вопрос отдельный и заслуживает, наверное, отдельного обсуждения. Но задачу все-таки надо формулировать не в терминах СОА, ибо СОА — это уже решение. Как толькоты начинаешь думать в стиле СОА, ты уже сужаешь спектр возможных решений.
Если эта тема тебе действительно интересна, рекомендую создать отдельный топик. В рамках этих "священных войн" мне данную тему обсуждать не хочется.
К тому же я вроде как сразу сказал, что ФП возможно тут не очень подходит. Если бы я утверждал обратнОе, то твои нападки, наверное, имели бы смысл.
ВВ>> Она уже выдумана. Анемичная модель называется. И не ООП, и не... В общем неведома зверушка. AVK>Ну да, тебя послушать так ООП вообще нет. Жопа есть, а слова нету.
А можно вернуть культурного и умного собеседника, который был раньше? С ним было интереснее.
ООП конечно используется достаточно широко, но вот в ряде областей он оказывается неудобен — причем в очень даже мейнстрим областях. Можно подумать, почему это так — и есть ли там место ФП. Можно рассуждать о жопах.
ВВ>>Кстати, хороший пример. Я сам хотел его привести. Тоже тот случай, когда ООП-ная косвенность как бы не сильно популярностью пользуется, и Фаулера с его репозитариями народ что-то не шибко не любит в общей-то массе своей. AVK>И чего? Кто то спорит тут с этим? Или в ФП ситуация чем то лучше? Чего там в Хаскеле — ХаскеллДБ, который просто отказался от преобразования реляционной модели к чему бы то ни было, как, впрочем, и нормальные реализации LINQ2DB?
Ты вроде как сам начал про распределенку и БД. Я тут ничего не утверждал.
AVK>>>Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно. ВВ>>Примерчик чего? AVK>Правильного функционального подхода к гую.
Я вообще в гуе не разбираюсь. Ни в функциональном, ни в каком. Подход такой, возможно, имеется, я о нем не в курсе. Про гуй тебе придется говорить с кем-то другим.
ВВ>>А что не так с компонентностью? AVK>Она утонула Нет ее. Ну кроме тех Ф-языков, в которых есть поддержка ООП.
С чего вдруг компонентности нет?
ВВ>>Мне казалось, что с целью разобраться в том, что же такое *в действительности* ФП AVK>Спасибо, не надо. Я уж как нибудь сам. ВВ>>. Если такой цели нет AVK>А ты что, всерьез считаешь, что моей целью было узнать из твоих постов, что такое ФП? Ну вот честно, ответь.
Не знаю. В той или степени — возможно, да. Спор — это же тоже форма разобраться в предмете. Но, возможно, и нет. Тебе, наверное, виднее.
Вооюще потенциал знаний в любой области практически бесконечный. Как бы ты хорошо ни разюирался в чем-либо, всгегда можно свои знания еще увеличить.
AVK>>>Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом? ВВ>>Написал бы пару АлгТД AVK>Учитывая, что кое кто тут утверждал, что кортежи и АлгТД это одно и тоже, ты сделал мне смешно.
Смешно это про список с maybe типов. Остальные варианты ты, конечно, поскипал.
ВВ>>Могу лишь повторить — ФП более самодостаточная концепция. AVK>По барабану.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Нет никакого поведения у двери кроме как подчиняться законам природы.
V>Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться.
Это не дверь отказывается, а ты делаешь что-то не так. V>То бишь, послать сообщение "откройся внутрь" объекту-двери и само открытие двери — это разные события.
В реальной жизни я с дверьми не разговариваю. Я их открываю без посылок сообщений.
То что дверь становится открытой или продолжает оставаться закрытой — это безусловно мессадж. Но не от двери конечно же. Это мессадж от меня самого, что если буду заходить в закрытую дверь — расшибу лоб. В моей реальной жизни все именно так. Но когда я делаю ООП модель с методом у двери, все мои представления о реальной жизни сливаются в унитаз и появляется грубая шизофреническая пародия, где дверь отвечает, открыта ли она.
S>>А то что ты совокупность действующих на дверь сил заменяешь методом Откройся() — так это не двери забота. Это особенности твоей модели, а не двери вовсе.
V>Я ничем не заменяю, я не могу добиться внятного ТЗ на эту дверь. Ес-но, ТЗ можно сформулировать так, чтобы всю дверь можно было заменить булевской переменной, над которой что ООП, что ФП будут оверкиллом.
То как будет сформулировано ТЗ не повлияет на возможность реальной двери рассылать сообщения. Это свидетельствует в пользу того что ООП-изация двери далека от рж.
V>>>Где ты эту траву берешь? S>>У Кэя взял.
V>Такой у него точно не было ))
Значит ты его точно не читал
S>>хранят, но с ООП-шностью этих данных в чистом языке напряг. Так что в топике об ООП лучше не называть эти данные объектом.
V>Позволь мне разобраться самостоятельно, что как называть. "функциональный объект" — это известный устоявшийся термин. Это именно то, как выглядит ФВП с точки зрения ООП, то бишь его внутренняя конструкция. И да, замыкания могут быть мутабельными... Хотя бы в Лиспе.
Я написал о чистом языке. Мутабельные замыкания в чистом языке — это определенно прорыв.
S>>Самый плодовитый тут однозначно ты.
V>Это временно ... Приходится гонять тесты на виртуалках, а оно "само и долго"... )))
что только не сделаешь, что бы пофлудить
S>>>>На самом деле от Лисп-атома до кортежа функций не так далеко. V>>>Бесконечно далеко. S>>ну-ну
V>По-я-сни.
Я на самом деле не в теме, но речь явно не о бесконечности.
S>>>>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.
V>>>А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле? S>>Конечно. Примерно как между статикой и динамикой.
V>Дык, если наследования нету, то компилятор С++ вообще виртуальные вызовы на обычные заменяет аж бегом. В обход vtable. В этом плане у кого больше статики?
А если наследование есть, то не заменяет.
Здравствуйте, Wolverrum, Вы писали: W>И чо? W>Индусы код не поймут?
Да. W>Система работать не будет? W>Цена поддержки многократно вырастет?
Да. W>Чувству прекрасного будет нанесен невосполнимый урон?
Да.
Вы поймите, ООП решает вполне конкретные задачи. Это же инженерная дисциплина.
И всякие полезные принципы, типа SRP, они для того, чтобы помочь людям добиться от ООП той пользы, которая в нём потенциально есть.
Понимаете? С точки зрения функциональных требований все парадигмы совершенно одинаковы — см. тезис Чёрча. То есть в принципе нет такой программы, которую можно было бы написать на ФП, но нельзя на ООП — как и наоборот.
Отличия — только в нефункциональных требованиях. Например, в том, сколько стоит отладка (т.е. доказательство корректности, хотя бы и нестрогое) и внесение изменений. Или в том, насколько эффективный код получается в результате.
Ну так вот понятность кода напрямую влияет на стоимость его поддержки.
Возможность изолировать эффекты локальных изменений — тоже.
Именно ради неё Кей вводил эти "чёрные ящики", а не потому, что они как-то особенно подходят к устройству мозга.
Как только мы отказываемся от преимуществ этой изоляции, ООП превращается в культ карго — написание кода ради самого кода.
Часто именно такая ерунда получается в т.н. рич-модели — это где элементы предметной области искусственно наделяются поведением. Получаем лишний код, который нужно писать, и нужно исполнять.
С точки зрения классического, незамутнённого ООП, вызов метода transaction.getAmount() — это обращение к чёрному ящику. Мы не имеем права интересоваться, как устроен этот код. У нас нет другого способа узнать, на какой счёт переводятся деньги, не вызвав метод transaction.getAccId().
Так что если у нас есть список транзакций, мы обязаны честно полностью его проходить и выполнять все обращения:
foreach(var t in allTransactions)
if (t.getAccId() == accId)
sum += t.getAmount();
Только отказ от "чёрной ящиковости" позволяет нам делать хитрые преобразования — например, строить индексы в СУБД.
S>>То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры. W>Выделенное плохо?
Выделенное очень хорошо. W>Подчеркнутое обязательно?
Крайне желательно. >>anemic model: >>"Logic cannot be implemented in a truly object-oriented way"
Здесь truly имеет саркастический оттенок. Да, с точки зрения ООПГМ-нутых анемик — это плохо, потому что в нём бухгалтерские счета внезапно перестают быть объектами, а в ущербной ментальной модели ООПГМ-нутого все сущности предметной области обязаны быть объектами. Именно это пишут в говноучебниках.
А с точки зрения профессионала анемик ничуть не ограничивает применение ООП — просто в нём объектами становятся элементы решения, а не задачи.
Вместо того, чтобы вводить объекты для чисел и уравнений, мы вводим объект EquationSolver.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Если ты настаиваешь, я тебе продемонстрирую, где ты подменил мое высказывание. Сперва смотрим (1) — речь зашла о языках бизнес-правил, которые не создают новые абстракции. В (2) мое утверждение, раскрываю с учетом (1): "Написатели бизнес-правил на спецязыке без создания абстракций — не программисты в привычном понимании". А в (3) ты переиначиваешь мое высказывание, легким движением руки заменяя "языки бизнес-правил без абстракций" на языки высокого уровня. Это, батенька, называется подтасовка.
Я их не заменяю на языки высокого уровня. Я их считаю языками наиболее высокого уровня из возможных, так как меряю уровень по числу конструкций языка, требуемых для выражения понятийного аппарата предметной области. Чем этих конструкций меньше (и соответственно, меньше деталей реализации), тем уровень выше. Вне рамок предметной области оценка высоты уровня языка не имеет смысла. У вас тут тоже спор идет по большей части о применимости т.н. языков общего применения к конкретным, пусть и более широким, предметным областям, а не "вообще, в целом".
Если есть возможность рисовать абстракции более высокого уровня, то в зависимости от предметной области, это может быть интересно. Хотя в том же форексе почти все абстракции-классы по факту, сколько помню, ложились на понятия предметной области один к одному. Более высоких не требовалось.
K>>Я понимаю, очень приятно смотреть на такие языки
AVK>Какие такие? Давай конкретные примеры в студию. Вот в нашей платформе (Парус Торнадо) есть несколько языков, имеющих отношение к бизнес-правилам. Например, язык метаданных платформы, описывающий прикладные сущности (текстовый декларативный язык + гуевый дизайнер). Но, вот что характерно, этот язык напрямую предназначен для создания новых абстракций.
Примеры полезных абстракций, пожалуйста.
AVK>А вот есть еще язык (в какой то мере, это не текстовый язык) задания правил обработок (проводок) документов. В нем таки нет никаких средств создания новых абстракций, только использование существующих. И таки те, кто этим пользуется, нифига не программисты, а всякие внедренцы и админы.
Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь. Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.
Здравствуйте, Sinclair, Вы писали:
I>>Массы и линейных размеров нет, зато поведение и свойства есть. Эта математическая абстракция есть заимствование из физического мира, представь, передача информанции на уровне сообщений, каналов и даже пакетов появилась еще в те времена, когда пароход феодосия еще шлюпкой был. S>Брр. Давайте не будем углубляться в дебри. Математика и физика разделились относительно недавно; тем не менее, под термином "физический объект" подразумевают не просто "что-то со свойствами", а что-то с определёнными свойствами.
Это совершенно неважно, потому что нас интересует заимствование из реального мира. Обмен информацией на уровне сообщений, каналов и пакетов был в этом мире давным давно. Эту концепцию и воплотили в сокетах, разве что название сокет совсем неудачное.
I>>Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает. S>В том-то и дело, что учебники вводят иллюзию, что надо копировать объекты Реального Мира. Лужа и Камень являются очевидными вариантами.
Учебники не заставляют тебя вводить эти классы. Парадигма не говорит ни какая должна быть модель, ни правильная ли она. Парадигма говорит как модель перевести в код, всё ! Моделируешь ты сам точно так же как это делали до изобретения программирования.
I>>Физический объект имеется ввиду заимствование из реального мира, а не корова с выменем, рогами и хвостом. S>Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.
19й век
В двадцатом уже были универсальные вычислители. А про логарифмическую линейку, счеты ты тоже забыл ?
Соответсвено идея вычислителя, как некоего устройства, есть заимствование из реального мира. Вычислитель — объект со свойствами, поведением и тд. Дёргаешь его и получаешь результат. Это и есть ООП. Удобно или нет, к ООП это не относится. Не удобно — не используй.
Дешевле хранить нуль и создавать пустой список.
