V>Ну дык, надо больше интересоваться как оно всё устроено и работает и меньше поддаваться догмам. Тогда бы ты понимал, скажем, чуть быстрее. А то мне приходится объяснять тебе простейшие вещи в десятках постов, в попытке преодолеть косность мышления.
V>То, что я высказываю точку зрения, не совпадающую со многими коллегами на этом сайте — я для этого сюда и пишу, собственно. Бо вторить банальностям как попугай — банально неинтересно, я их наизусть уже 20 лет знаю. Просто надо уметь смотреть на любой технический момент под разными углами, а не только с "единственно правильного".
Воинствующий Шериданизм на марше. Причем, текст почти один-в-один такой же
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Не понял. А кто нам запрещает сообщения отсылать в инфиксной форме?
Инфиксность формы неважна. ВВ>В Смолтоке, кстати, инфиксные сообщения были. А это, если не считать Симулы, самая заря ООП.
В Смолтоке сообщения отправлялись совершенно конкретному объекту. То, что в нём выглядело как инфиксная форма — всего лишь синтаксис.
А я говорю о семантике — когда я пишу 2 / (a + b) * c, я не ожидаю от читателя мысли "А, тут двойке отправляется сообщение 'поделись'".
Читателю понятно, что кто-то должен сложить а и б, поделить два на результат, и умножить всё на ц.
ВВ>Ну да, а если еще глубже копнуть, то окажется, что там сплошной ассемблер.
Совершенно верно. То есть мы имеем обычную арифметику, реализованную поверх ООП-шных объектов.
Можно реализовать её поверх чего угодно — например, поверх чистых функций. У ДеСмета было выполнено это упражнение.
S>>2. Я вовсе не уверен в том, что операция __add__ реализована "объектным" образом, а не является всего лишь частью описания ADT.
ВВ>Я не улавливаю разницы между "реализована объектным образом" и "является всего лишь частью описания ADT". Можно пояснить?
Объекты в ООП имеют внятную семантику, в частности — идентичность и поведение. Если нет идентичности, нет поведения, нет инкапсуляции состояния, то это не ООП, а фикция. Почитайте про http://en.wikipedia.org/wiki/Abstract_data_type.
ВВ>А в Джава примитивы вообще ни в каком смысле объектами не являются, а боксинг делается ручками завертыванием int во вполне себе "объектный" Integer. Но о чем это говорит?
О том, что арифметика в Java не пользуется ООП. ВВ>Примитивы нельзя представить как объекты? Ну, конечно же, можно, и другие языки это прекрасно показывают. Просто такое представление является неэффективным. Как, впрочем, и рантайм диспатч арифметических функций, вместо статического диспатча. Но эффективность — это отдельный вопрос.
Ага. Это неэффективно с точки зрения и программиста и процессора.
ВВ>Я этому товарищу отдельно отвечу, когда время будет. ВВ>По поводу математических операций могу прежде всего заметить, что необходимость неявных приведений, из-за которых как раз и начинаются все описанные проблемы, мне не кажется столь уж несомненной.
Проблема — не в необходимости неявных применений. А в том, что операция "сложить инт и флоат" не является "свойством" или "умением", присущим инту или флоату. Это я, я умею их складывать. Инт и флоат — не "чёрные ящики", я прекрасно знаю, как они устроены. Поэтому я могу определить операцию сложения как метод построения нового флоата по заданным флоатам. Почитайте рассуждения Степанова, из которых получился STL. Он очень внятно объясняет, что операция сортировки не является собственностью коллекции, а существует совершенно независимо от неё. Поэтому концеация "давайте отправим объекту "массив" сообщение "отсортируйся"" — абсолютно противоестественна.
ВВ>По поводу конкатенации ленивых списков я вообще не понял проблему. Если ленивые списки превратить в IEnumerable, то в рамках того же C# контактенация двух бесконечных последовательностей описывается без всяких проблем во вполне объектном ключе.
Проблема — в несимметричности симметричной операции. Вам обязательно нужен первый аргумент там, где он вовсе не нужен.
Хрен с ней, с ленивостью. Вот у меня операция (a + b). Я хочу иметь правило "adding null yields null", которое типично для большинства nullable логик. Реализовать это для правого аргумента мне нетрудно — метод сложения a.__add__(b) будет проверять b на null и возвращать null.
А для левого аргумента сделать так не получится — у меня будет NullReferenceException при попытке выполнить VMT lookup.
Принудительная невиртуальность для метода __add__ — это уже отход от ООП и чудовищное неравноправие различных операций.
Вывод: диспетчеризация бинарных операций, в том числе отношений, плохо ложится на ООП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
V>>Дык, в том-то и дело, что нет в природе никакого "нечистого ООП". Есть просто некие вычисления и есть сохранение результатов вычислений в полях объектов или передача их как сообщений другим объектам. Способ вычислений в ООП никогда не ограничивался, в отличие от чистого ФП, где полно ограничений. S>Твои представления об ООП наивны.
Это твои представления об ФП догматичны. А мои об ООП ровно такие, каково состояние дел в ООП прямо на сегодня у лидеров рынка.
V>>А "нечистое ФП" — это процедурный подход + функциональный тип. )) S>нечистое ФП вполне может быть испачкано ООП-ой
Увы, тогда это будет уже скорее ООП. Оно итак испачкано ФП-ой чуть ли не изначально.
V>>Ключевое в связи ООП с мышлением я вижу именно в способности мышления человека моделировать окружающий мир. S>Ничего что до ООП человек тоже мог моделировать окружающий мир? Или возможность моделирования открыл Др. Кэй?
Гы, ничего, что сейчас ты показал умение переворачивать всё с ног на голову почище моего?
Жаль что под перевернутым на этот раз пусто, т.к. именно способность человека моделировать окружающий мир лежит в идее ООП. Никак не наоборот, ес-но. Ведь это человек назначает объектам роли, то бишь это не происходит "само по себе".
V>>Из-за поведения. В чистом ФП нет поведения, бо поведение — это побочный эффект, эта реакция, которая зависит от всей истории предыдущих воздействий. В ФП же "реакции" функций безусловные, зависят только от текущего воздействия. S>С реакцией от истории в ФП все впорядке. Да и вся история как на ладони заодно.
Увы, если брать отдельно взятый функциональный объект — то не в порядке. В порядке там только при наличии состояния. А в чем оно заключается в "чистом ФП" (которое даже без монад) — я тебе уже писал... про стек вычислений и положение указателя команд в потоке исполнения.
V>>С отношениями в ФП тоже большие проблемы из-за наличия лишь одного вида декомпозиции — функционального. S>что не так с отношениями?
Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this.
Здравствуйте, Mamut, Вы писали:
M>Воинствующий Шериданизм на марше. Причем, текст почти один-в-один такой же
Я ХЗ что ты имел ввиду, я этого товарища не читаю. Но лично для меня догматичность является синонимом ограниченности, даже местами откровенной глупости. Потому что по работе постоянно приходится лечить результаты этих догм... что характерно, практически всегда видно, что причины самых серьезных ошибок кроются в неглубоком понимании происходящего. Я бы сказал, в преднамеренном дистанциировании от подробностей происходящего.
Так что да, над таким принудительным дистанциированием я всегда потруниваю на этом сайте. Бо есть за что. ))
Здравствуйте, Ikemefula, Вы писали:
V>>Но не достаточно сильно. ))
V>>
V>>...
V>> return list ?? Static<ArrayList<T>>.Instance;
V>>...
V>>
I>Скажи пожалуйста а какой профит даёт эта конструкция и в каких условиях получается монетизировать этот профит ?
Монетизировать этот подход получается, показывая обработку заметно большего числа сообщений в сек, чем конкуренты.
========
Ээээ... скажи, вот этот вопрос относительно показанного изменения — это принципиальная твоя позиция, или просто хотелось услышать лично моё мнение? Ну чтобы я был на будущее в курсе?
Здравствуйте, SV., Вы писали:
SV.>До- и переписывайте как угодно, но форматирование строк, хранение в бинарном формате IEEE-666 и заданную точность оставьте, это условия задачи, которые к ООП отношения не имеют.
var aT = ConvertLongToHighPrecisionNumber(a);
var bT = ConvertStringToHighPrecisionNumber(b);
var cT = ConvertIeee666ToHighPrecisionNumber(c);
Идея понятна?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mamut, Вы писали:
M>>Воинствующий Шериданизм на марше. Причем, текст почти один-в-один такой же
V>Я ХЗ что ты имел ввиду, я этого товарища не читаю. Но лично для меня догматичность является синонимом ограниченности, даже местами откровенной глупости. Потому что по работе постоянно приходится лечить результаты этих догм... что характерно, практически всегда видно, что причины самых серьезных ошибок кроются в неглубоком понимании происходящего. Я бы сказал, в преднамеренном дистанциировании от подробностей происходящего.
А как охарктеризовать вот такое: "Утверждать что фп растет из структурного подкрепляя это википедией, не упомянуа ни машину Тьюринга ни лямбда-счисление Черча" ?
Здравствуйте, Ikemefula, Вы писали:
V>>Мутность в том, что ты не помнишь каждый кустик, встречаемый тебе по дороге. I>То есть, мутный у тебя стало синонимом абстрактный ? Вообще говоря мутный это нечто, мешающее построить абстракцию.
Гы, абстракция — это упрощение.
Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не?
I>>>Покажи на примере, как функциональная композиация несильно отличается от процедурной. V>>Легко. Для примера, любое замыкание — это пара: { ф-ия, замкнутый_контекст }. ФП-языки представляют эту пару в виде неделимого объекта. Заметь, исходно декомпозиция может идти по двум координатам, то бишь как по ф-ии, так и по замкнутому контексту, но реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии).
I>Вот функциональная декомпозиция I>Order(x => x.ABC)
I>А вот процедурная
I>OrderByHellKnowsWhat
I>Надо ли объяснять разницу ?
Ес-но надо.
Для начала приведи эквивалентный по функциональности код и там и там.
Если с наскока не получится — см. мою подсказку насчет того, что есть замыкание.
Здравствуйте, vdimas, Вы писали:
V>>>Но не достаточно сильно. ))
V>>>
V>>>...
V>>> return list ?? Static<ArrayList<T>>.Instance;
V>>>...
V>>>
I>>Скажи пожалуйста а какой профит даёт эта конструкция и в каких условиях получается монетизировать этот профит ?
V>Монетизировать этот подход получается, показывая обработку заметно большего числа сообщений в сек, чем конкуренты.
Какой профит, в каких условиях, точнее пожалуйста, в количественных показателях, ты ведь инженер ? На мой взгляд (подсмотрел в профайлере) ты экономишь около нуля(но справа) ресурсов и для этого создал целую инфраструктуру.
V>======== V>Ээээ... скажи, вот этот вопрос относительно показанного изменения — это принципиальная твоя позиция, или просто хотелось услышать лично моё мнение? Ну чтобы я был на будущее в курсе?
Вопрос это с целью 1 прояснения непосредственно того что вопрошалось 2 проверки можешь ли ты выдать жосткие проверяемые данные или отделаешься общими словами.
Итого, п.1 — прояснить не удалось п.2 жостких данных не было, были общие слова
Здравствуйте, Ikemefula, Вы писали:
I>А как охарктеризовать вот такое: "Утверждать что фп растет из структурного подкрепляя это википедией, не упомянуа ни машину Тьюринга ни лямбда-счисление Черча" ?
Дык, прочти еще раз что я писал в пред посте и перед ним по этой же ветке — там все ответы.
=========
Ответы:
1 — потому что ты скатился в сплошную теорию, хотя структурное программирование, это ес-но никакая не теория, это парадигма, то бишь набор практик. Итого, уход от обсужденией аналогичных практик в догмы.
2 — упомянутое тобой мы обсуждали здесь раз сто, если не больше, и я тоже дохрена места на экране исписал по этому поводу. Мне показались любопытными еще кое-какие совпадения, которые не так, чтобы на поверхности.
Здравствуйте, samius, Вы писали:
V>>В исходнике, что ле? С ума сошел? Я могу рассуждать только о работе программы в рантайм. И я тебе уже всё показал. S>Так порассуждай и о Логическом программировании в таком же ключе. Получишь что и Логическое выросло из структурного.
Дык, а я и рассуждаю обязательно. Язык — это ведь инструмент, им надо уметь пользоваться. Поэтому факты и правила в Пролог надо понимать в каком порядке подавать, чтобы не получить проседание быстродействия на порядок на ровном месте из-за непонимания работы вычислителя Пролога.
Но ветвления в языке (относящимся к языку, а не расширениям) таки нет.
Здравствуйте, Sinclair, Вы писали:
SV.>>С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках. S>Не соответствует.
Это счет-то не соответствует результату операций по проводкам?
SV.>>С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы. SV.>>Вся эта штука называется объектная модель. S>Вся эта штука называется "ошибка архитектуры". S>У неё нет никаких преимуществ. То есть совсем никаких.
У нее есть одно большое преимущество — она интуитивно-понятна. Поэтому так строят реальные системы типа ShP OM. А других преимуществ — да, нет.
Есть и недостаток — ОМ чувствительна к дизайну. Кривые руки ее погубят. Поэтому, ШП ОМ — редкая гадость (когда я последний раз смотрел на их CAML, плакал горючими слезами — пакетные запросы адекватно представлены не были, пришлось плюнуть и переписать все на SQL).
S>Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него: S>
S>BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();
S>
Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден. Искать вы будете по внешним атрибутам счета, может быть, даже, в соответствии с правами доступа. Создаваться экземпляр будет фабрикой, внешний вид которой зависит от архитектуры. Разумеется, этот поисковый объект не будет исключительно фабрикой, и я никогда не соглашусь, что это нарушение SRP.
S>А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()).
Да, хотел дописать почти теми же словами, но решил, что и так понятно. Это некий шорткат, который можно реализовать по-разному (хоть бы и дефолтным значением параметра).
>Этот инвариант верен для всех счетов; то есть, с точки зрения правильного дизайна надо его выносить наружу. Ок, CalcCurrentBalance мы отобрали.
Зрение бывает у дизайнера, а не у дизайна. Как и точка, откуда дизайнер зрит. Это так, к слову.
С какой точки зрите вы, я не знаю. Мой поинт в том, чтобы сложность разложить по полочкам. Поставьте себя на место гуёвого программиста, которому дела нет до идентификаторов и базы. Зато у него на входе есть счет, который сводит дебит с кредитом по запросу. И полученный таким образом результат можно запихать в форму и отдать операционисту.
S>Откуда он будет брать эти проводки? Из базы? Ну, тогда надо научить его общаться с базой, а это — прямое нарушение SRP. Придётся отпилить от него какую-то функциональность — либо по расчёту баланса, либо по работе с базой.
Это зависит от точки зрения дизайнера на responsibility. Если у вас есть дополнительные требования к работе с БД (допустим, поддержка в качестве БД чего угодно, в том числе NoSQL) — ну, введем посредника, который будет делать выборки и другие реляционные операции по чему ему скажут (а Account ему скажет — по проводкам). Если нет — ради бога, прячьте сиквел в реализацию, получите быстрособранную систему, которая жестко завяжется на структуру таблиц. И то, и другое будет понятной объектной моделью, но с разными достоинствами и недостатками в других областях.
S>Если оставить в нём работу с базой, тогда непонятно, почему в нём — почему нам не иметь класс DbManager с методами GetTransfers(Predicate where), кроме которого, в общем-то, ничего и не нужно? S>Если оставить в нём работу с расчётом баланса, а проводки отдавать снаружи, то получается, что мы завели целый отдельный класс для примитивов типа S>
S>Decimal static CalcBalanceForDate(Date date, allTransfers)
S> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>
S>Зачем всё это делать, совершенно непонятно.
Как же это непонятно? Допустим, мы завязались на структуру таблиц. Тогда, во-первых, а где это хранить? В каком месте? "Там, где архитектурно правильно" — это общие слова. Где конкретно? Помните про гуёвого программиста, которому нужно состояние счета, атрибуты, балансы и больше ничего? Его вы озаботите знанием этого запроса, в том или ином виде?
S>Всё, что нужно, прекрасно получается безо всяких объектов Account.
Заглавное сообщение прочитайте еще раз. Всё, что нужно, прекрасно получается безо всяких объектов. Хоть на ассемблере. А вот если подумать о людях, которым с этим кодом работать...
Здравствуйте, Sinclair, Вы писали:
SV.>>До- и переписывайте как угодно, но форматирование строк, хранение в бинарном формате IEEE-666 и заданную точность оставьте, это условия задачи, которые к ООП отношения не имеют. S>
Здравствуйте, vdimas, Вы писали:
I>>А как охарктеризовать вот такое: "Утверждать что фп растет из структурного подкрепляя это википедией, не упомянуа ни машину Тьюринга ни лямбда-счисление Черча" ?
V>Дык, прочти еще раз что я писал в пред посте и перед ним по этой же ветке — там все ответы.
V>========= V>Ответы: V>1 — потому что ты скатился в сплошную теорию, хотя структурное программирование, это ес-но никакая не теория, это парадигма, то бишь набор практик. Итого, уход от обсужденией аналогичных практик в догмы.
Общего между структурным и функциональным это "и там и там надо писать код", если ты хотел это сказать, то я полностью с тобой согласен.
А если про математический базис, то есть правомочность применения практик, то надо рассматривать машину Тьюринга и лямбда-счисления Черча.
Здравствуйте, vdimas, Вы писали:
V>Гы, абстракция — это упрощение. V>Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не?
Нет. Представь себе, что часть дороги накрыл туман. Если тумана нет, дорогая представляется тремя отрезками. А если туман есть, то ...
I>>Вот функциональная декомпозиция I>>Order(x => x.ABC)
I>>А вот процедурная
I>>OrderByHellKnowsWhat
I>>Надо ли объяснять разницу ?
V>Ес-но надо. V>Для начала приведи эквивалентный по функциональности код и там и там.
Ну, имя неудачное, так будет яснее OrderByAbc
V>Если с наскока не получится — см. мою подсказку насчет того, что есть замыкание.
Это не важно, что есть замыкание. Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает.
Здравствуйте, Sinclair, Вы писали:
ВВ>>Не понял. А кто нам запрещает сообщения отсылать в инфиксной форме? S>Инфиксность формы неважна. ВВ>>В Смолтоке, кстати, инфиксные сообщения были. А это, если не считать Симулы, самая заря ООП. S>В Смолтоке сообщения отправлялись совершенно конкретному объекту. То, что в нём выглядело как инфиксная форма — всего лишь синтаксис. S>А я говорю о семантике — когда я пишу 2 / (a + b) * c, я не ожидаю от читателя мысли "А, тут двойке отправляется сообщение 'поделись'". S>Читателю понятно, что кто-то должен сложить а и б, поделить два на результат, и умножить всё на ц.
Соответственно, вопрос уже переносится из ниши "можно ли нормально представить математику в ООП" в нишу "насколько удачным может быть такое представление". Мне кажется, это уже несколько другой вопрос. Мне неочевидно, что отправление двойке сообщения "поделись" является, хотя бы потому что есть перед глазами реализации подобного, да еще и в количестве больше одной, где все это прекрасно работает. Кстати, для того же Питона до фига математических библиотек — значит, видимо, это кому-то нужно, и ООП-ность математики им не мешает.
Нет, мы, конечно, можем прийти к выводу, что ООП представление для математики менее удобное и гибкое (ну т.е. это так и есть, конечно), чем какое-либо другое представление — но это ведь не тот вывод, который был изначально заявлен.
Я еще раз повторю свою мысль — есть языки, в которых это сделано именно вполне ООП-но, причем совсем не экзотические языки. И они как бы работают
ВВ>>Я не улавливаю разницы между "реализована объектным образом" и "является всего лишь частью описания ADT". Можно пояснить? S>Объекты в ООП имеют внятную семантику, в частности — идентичность и поведение. Если нет идентичности, нет поведения, нет инкапсуляции состояния, то это не ООП, а фикция. Почитайте про http://en.wikipedia.org/wiki/Abstract_data_type.
С утра мне казалось, что я вообще-то понимаю, что такое ADT. А еще мне казалось, что противопоставлять ООП-шные объекты ADT как-то не совсем корректно. В лучшем случае ADT можно рассматривать как некое надмножество. И вот тут ты уже начинаешь вводить какие-то различия — "идентичность и поведение". Осталось только объяснить, что такое а) идентичность, б) поведение. Ведь если это такие простые и очевидные вещи, то и объяснить их можно очень просто, без всяких там ссылок куда бы то ни было. Или не получится?
ВВ>>По поводу конкатенации ленивых списков я вообще не понял проблему. Если ленивые списки превратить в IEnumerable, то в рамках того же C# контактенация двух бесконечных последовательностей описывается без всяких проблем во вполне объектном ключе. S>Проблема — в несимметричности симметричной операции. Вам обязательно нужен первый аргумент там, где он вовсе не нужен. S>Хрен с ней, с ленивостью. Вот у меня операция (a + b). Я хочу иметь правило "adding null yields null", которое типично для большинства nullable логик. Реализовать это для правого аргумента мне нетрудно — метод сложения a.__add__(b) будет проверять b на null и возвращать null. S>А для левого аргумента сделать так не получится — у меня будет NullReferenceException при попытке выполнить VMT lookup.
Это уже больше вопрос реализации, наверное. И того, что null в целом не самая хорошая вещь на свете. А так — вполне такое разруливается, как в том же Питоне, через пару методов __add__/__radd__.
Вообще это вопрос больше о том, кто тащит с собой таблицу методов — она приклеена к значению или же передается отдельно.
Первая стратегия позволяет нам иметь две разные таблицы методов в контексте одной операции. Вторая означает, что таблица методов одна. Это может быть серьезным преимуществом, а может, и не быть. В тех случаях, когда нам нужна одна таблица, достаточно ввести ограничение на то, чтобы таблицы методов для двух операндов всегда совпадали.
S>Принудительная невиртуальность для метода __add__ — это уже отход от ООП и чудовищное неравноправие различных операций. S>Вывод: диспетчеризация бинарных операций, в том числе отношений, плохо ложится на ООП.
Только в том случае, если a и b этих операций могут иметь разный "тип" — сиречь две разные таблицы методов, и непонятно, какую из них вызвать. Запрет этого для ряда операций (это как раз к вопросу о возможности складывать целые и флоаты) в рамках математики эту проблему вполне решает. Избавление от null — которого в динамике все равно в привычном смысле нет — решает ее практически полностью. Остается вопрос оправданности (разумности) такого дизайна, т.е. представления математики в ООП ключе. Но не вопрос принципиальной возможности.
Ikemefula,
LCR>>Короче, реализация бинарных соотношений и операций как методов — это ужасно граблеобразно и неестественно. Это как минимум некрасиво. А решение-то на поверхности: отказаться от клеящего объекта, ввести сообщения приходящие из ниоткуда — свободные функции и ввести ограничения для аргументов функций в виде классов типов или обобщённых интерфейсов.
I>20 лет назад адепты ООП уже проходили это — http://lib.rus.ec/b/163426/read
Только кроме функций как таковых желательно ещё иметь хорошую возможность для абстрагирования, иначе такой подход становится слишком трудоёмким (классы типа Utils как раз являются имитацией).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Так порассуждай и о Логическом программировании в таком же ключе. Получишь что и Логическое выросло из структурного.
V>Дык, а я и рассуждаю обязательно. Язык — это ведь инструмент, им надо уметь пользоваться. Поэтому факты и правила в Пролог надо понимать в каком порядке подавать, чтобы не получить проседание быстродействия на порядок на ровном месте из-за непонимания работы вычислителя Пролога.
V>Но ветвления в языке (относящимся к языку, а не расширениям) таки нет.
В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Это значит, что у ФП больше ограничений и границы проявляются очень четко. S>>Так обозначь их
I>Легко, фп — вычислительные задачи "унутре" метода которые, кроме того, не требуют изменяемого состояния и всяких числодробилок.
Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.
I>Использование ФП на уровене АПИ пока что возможно только в закрытой нише, вроде Эрланга.
В закрытой от ООП языков что ли?
Ikemefula,
LCR>>Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.
I>А с каких пор ООП это именно создавать классы Лужа и Камень ?
Вот я и говорю, что сначала нужно придумать (кстати, мышление гораздо свободнее ООП, и поэтому у нас хорошие шансы на успех) адекватную модель, затем понять как в терминах этой модели будет выглядеть решение. И я утверждаю, что обычные ООП-шные способы моделирования (выделить базовые сущности, определить взаимодействия) в данном случае не работают. Работают другие техники абстрагирования, такие как векторное поле, дифференциал. И абстракции из вычметодов — сеточная функция, норма, невязка. Ты видел объект "невязка"?
LCR>>Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл: I>А с вычметодами разве не так же ? ну, по моему, вычметоды могут моделировать тоьлко ту действительность, которая, внезапно!, подходит к тому что бы быть промоделированой через вычметоды.
Да, согласен, вычметоды тоже имеют ограничения и хороши на своём месте. QR-разложение нет смысла применять для того, чтобы дёргать разные покерные АПИ; было бы странно применять метод Гаусса к решению задач скажем комбинаторики. (хотя... кто его знает )
Вообще говоря мутный это нечто, мешающее построить абстракцию.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
