Re[24]: хихи - Философия программирования

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

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

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

S>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно,
Вот еще один пример. Вашу мысль о том что мозг мыслит объектно вы уже декларировали. Но ни одного подтверждающего обстоятельства не привели. Т.е. то что мозг мыслит объектно, выдвигается вами за постулат. Причем, выглядит это так, что утверждение абсолютно. Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

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

S>ФП удобно для реализации алгоритмов определённого толка. К чему предлагать проводить экперименты, если они уже проделаны самой цивилизацией? ООП методология не вчера появилась. Ей уже много лет и она доказала все те посылы о которых я пишу.
Так приведите уже эти доказательства. Если ваши доказательства основаны на численном сопоставлении количеств разработок в разных парадигм, то я могу таким же образом доказать что лучший автопроизводитель автоваз а самая продвинутая страна — Китай.

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

Да я вам про функции даже разу не сказал.
Мозг склонен использовать проверенные решения и строить новые на основе проверенных. Соответственно, если вы не видили букварь по ФП, то вряд ли ваши решения будут иметь отношение к ФП. Если вы не видели букварь по ООП, то ваши решения вряд ли будут иметь отношение к ООП. У меня много примеров перед глазами. Сотни. ООП дается со скрипом даже тем, кто от него получает фан. Вы и тему-то именно об этом завели. Но продолжаете исходить из того что мозги работают объектно. Второй раз об этом пишу. И да, я намеренно пытаюсь свернуть полет вашей мысли к противоречию.

Здравствуйте, vdimas, Вы писали:

Коллега, плотность бреда на квадратный пост превысила ПДК. Ваши заблуждения настолько всеобъемлющи (я пока не нашёл области, где хотя бы 20% ваших утверждений соответствовали действительному положению вещей), что впредь я буду игнорировать все ваши посты на любые темы.

Здравствуйте, Sinclair, Вы писали:

S>>Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
S>Гипотеза интересная, но смолток из коробки был построен на сверхпозднем связывании. Экономить они научились уже потом — хотспоттинг и спекулятивные оптимизации были придуманы ровно для него, и уже потом перетащены в джаву.

Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП. Этот язык — Симула 67 — отличается от современных ООЯ только в деталях. К примеру, в нем небыло множественного наследования (ни в каком виде — ни в виде трейтсов, ни в виде интерфейсов), а конструктор был один на класс и тело конструктора и объявления класса были одним блоком (те, кто видел ООП в F#, например, должен понять о чем я говорю), неймспейсы реализовывались с помощью анонимных классов. Самые обычные ссылки, самые обычные классы с "наследованием", обычные методы, виртуальные методы. Никакого "есть только объекты, обменивающиеся сообщениями, которые сами объекты" (ну, были еще и легкие потоки, активные объекты и "дискретные симуляции" но от этого произошли другие ветки ООП и совсем не ООП).
Гипотеза samius отлично подтверждается фактами:
Первый ООЯ был диалектом процедурного языка Алгол 60. Первоначально создатели даже собирались ограничиться препроцессором Алгола, но потом им понадобились расширения Алгола 60 вроде ссылок.
Поэтому нет в мейнстрим-ооп никакой "объектной арифметики" и "блоков кода", которым посылается сообщение "выполняйся". ООП появилась как расширение обычного процедурного языка, который на первый взгляд от паскаля отличается только тем, что у него типы не постфиксно после двоеточия указываются, а префиксно — как в C. (Точнее, конечно, это паскаль от него почти не отличается и типы в C как в нем указываются)
Концепции ООП появлялись таким способом: вот интересный (и дешевый в реализации) эффект — как мы можем его использовать?
Началось все с того, что понадобилось придумать новый (быстрый) способ передачи параметров в процедуры. Стандартные алголовские способы: по значению и по имени были медленными по разным причинам. Тогда Хоар изобрел ссылки и null. Раз уж структурная эквивалентность оказалось сложной в реализации, сравнивать стали адреса, по которым "объекты" располагаются — появилось identity.
Обратили внимание на то, что блок памяти B, структурированный в начале так же, как и блок A можно обрабатывать процедурами, написанными для работы с A — появился "префиксинг" (даже синтаксически объявление класса родителя было префиксным), под который потом подвели идеологию и назвали "наследованием" (ну и понятно, почему сначала никаких "множественных наследований" не было — что такое "множественный префиксинг"?).
К рекордам добавили процедуры, диспетчеризующиеся по одному аргументу. Почему именно по одному? Потому что по n > 1 — сложно в реализации. и т.д.

Кей же и прочие смолтокеры захотели сделать не такой вот "натянутый" на структурное программирование ООП, а идеологически чистый и непротиворечивый. Для этого они подвели базу под все эти технические срезания углов. Получилась чистая реализация идей, придуманных для быстроты и простоты реализации, только медленная и сложная. Они не смогли все это заставить вертеться с приемлимой скоростью до 90-х годов, когда стало уже поздно. Чтоб ввести Симула-лайк ООП в мейнстрим понадобилось только (временно) отказаться от сборщика мусора.
Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП, загнувшееся, правда, раньше нем неправильное, пока по настоящему древнее ООП все продолжало умирать. Ну и, понятно, философия ООП, которая превратила все картины, загораживающие дырки на обоях, в "краеугольные камни" концепции и "имманентные особенности человеческого мЫшленья".

S>академический Оберон (явный научный успех и не менее явный провал в популярности)

Ничего академического в нем нет. Это — очевидно неудачная — попытка слепить как раз "практический" язык из академических наработок Algol, Simula, Mesa, Cedar, в очень незначительной степени — Smalltalk. Научная ценность и техническая новизна Оберона равна нулю. "Академическим" он тут называется практиками исключительно потому, что для "практика" "академический" — это ругательство, а общеупотребимые ругательства правилами запрещены.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.

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

> Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.
> Эрланг, Хаскель и Лисп, так любимые ботаниками-маргиналами, далеко в аутсайдерах. Но, их нежно и с любовью пользуют там где они уместны. Давно уже не рассуждая об этих вещах. И тактично обходя любые дискуссии, дабы не задеть легкоранимое самолюбие кухонных теоретиков от ФП, давно и основательно дистанцировавшихся от реальной жизни.

Прально говоришь, так ему и надо. Если есть аргумент противоречащий твоей теории, есть масса типовых способов его опровергнуть:
— каждый ребенок знает;
— это естественно как сама жизнь;
— а вы вообще ботаники-маргиналы, основательно дистанцированные от жизни;

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, pkl, Вы писали:

pkl>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта...
Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения".
Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение.
А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта.
В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.

Steamus,

M>>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

LCR>>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
LCR>>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

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

S>Что интересно, люди понимающие ООП, как правило имеют неплохое представление и об ФП. А вот обратное — неверно. ФПшники тотально не понимают на каком уровне ООП работает. Откуда и всё эти наивные вопросы, которые им самим кажутся прикольными и типа ООП-тупиковыми. И тема очень ярко это показывает. 40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.

Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.

А приблизит нас тоненькая брошюрка "Введение в динамику жидкости" товарища Бэтчелора и такая же тоненькая "Вычислительная математика" Тихонова+Самарского. В первой книжке мы найдём как выписать систему уравнений Навье-Стокса для нашей лужи, а во второй книжке мы найдём методы, как решать системы диффур численно. Покроем лужу достаточно мелкой сеткой, напишем алгоритм числнного решения (с прицелом на кластер) и вот тогда мы приблизимся таки к моделированию нашей действительности. И тут — о чудо — появятся объекты, да. Например, vector<Point3D>, matrix, обёртки над сокетами и тому подобные технические сущности. Причём набор этих сущностей будет существенно зависеть от выбранного способа решения. Однако куда делись лужа с камнем? Чёрт!

Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл:

1. Это когда действительность можно раздербанить на множество мелких кусочков (то есть объектов), не слишком много и не слишком мало. Когда объектов слишком много, мы обнаружим практическую непригодность нашей модели; когда объектов слишком мало (лужа и камень), мы обнаружим, что эти объекты слишком сложно взаимодействуют друг с другом, и ООП нам здесь не поможет.

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

3. Взаимодействия должны быть ассиметричными. Самое лучшее, если мы взаимодействие можем сформулировать в виде "с объектом А можно делать то, то и сё". Ассиметричность нам даст уверенность приклеить метод к данному объекту.

4. Можно вводить синтетические объекты для уменьшения количества методов и/или для упрощения методов. (Чаще всего нужно, многие паттерны об этом)

5. Можно вводить синтетические методы опять же для уменьшения количества и/или упрощения. (То же что и в 4)

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

Сабтайпинг. Он тоже необязателен. Когда-то, больше года назад я дискутировал с Klapaucius, он меня как-то попросил привести примеры, где сабтайпинг с его полиморфизмом был бы особенно органичен и полезен (ну ты знаешь, IFigure / метод draw

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

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

(Кстати, кто мне скажет, зачем у класса Complex определены методы '+','-','*' и '/'?)

Здравствуйте, Mamut, Вы писали:

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

S>>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

M>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

Здравствуйте, SV., Вы писали:

SV.>Просто потому, что мы мыслим объектами.
А это точно правда?

Здравствуйте, Mamut, Вы писали:

S>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>Только в реальной жизни они этих предков не имеют, вот ведь засада.

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

Представьте – разруха, зима (не в Молдавии). Вы в холодной квартире, где нет не только что воды/отопления и света, но даже интернет не работает. Температура около нуля (спокойно, по Цельсию). Всё что у вас есть – это камин. Дров нет разумеется. Но вокруг стоят табуретка, деревянная полка, железная кровать и раритетная акустическая система Танной. Стерео! 1972 года выпуска.

Внимание, ставлю вам задачу – сколько времени пройдет, пока нормальный здоровый мозг, выделит общий класс ‘Полено’ из табуретки, полки и акустической системы Танной 1972 года? И при какой температуре окружающей среды это произойдёт. Влияет ли температура окружающего воздуха на способность мозга к обучению абстрагированию/выделению общих сущностей?

Здравствуйте, pkl, Вы писали:
pkl>По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема?
Проблема — в том, что то, что вы описываете, никакого отношения ни к реальной жизни, ни к бытовому мышлению не имеет.
Получается какое-то двоемыслие: то есть начинаем со смелого утверждения "ООП лучше подходит для программирования потому, что человек мыслит объектами". А потом оказывается, что в этой самой парадигме для того, что человек мыслит простым и ясным образом, нужно вводить какие-то публичные переменные, исключения, isOpen(), и прочее — что не соответствует ничему из исходной ментальной модели.

Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.

V>Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?
В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.

SV.,

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

SV.>Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

О! А с лужами и камнями вам стало быть всё-всё понятно?

Знаете, нужно хотя бы разобраться с простыми вещами, такими как открывание двери и щипание травы. Потому как в данном симметричном взаимодействии присутствует неопределённость, люфт я бы даже сказал, что считать субъектом, а что объектом взаимодействия. Не хочешь говядину с травой, вот тебе более животрепещущий пример — бинарные операции над полями. Да, да, обычное сложение вещественных чисел.
1 + 2
Мы легко делаем финт ушами и трактуем сию запись как синтаксический сахар для 1.+(2). И типа никаких проблем. Если бы...
Сложение коммутативно. Это значит, что 1 + 2 должно быть то же самое, что и 2 + 1. Чтобы более рельефно отразить проблему я запишу это как 1.0 + 2. Внезапно классы Integer и Float оказались связанными одной цепью — метод Integer.+(Float) обязан быть тождественным методу Float.+(Integer). А если ты захочешь добавить класс Rational как пару целых чисел, и реализовать сложение с вещественными числами, тебе надо будет во-первых перечислить в этом классе все возможные случаи, а во вторых хакнуть все системные классы, и добавить туда _.+(Rational).

Поехали дальше. Есть ещё такие штуки как отношения — это подмножества декартова произведения множеств. Ну там <, =<, ==, какие-нибудь хитрые отношения частичного порядка. И частенько бывает, что от отношений требуется симметричность, и транзитивность. Симметричность, это когда x (R) y совпадает с y (R) x для любых x и y. Если мы реализуем отношение как приклеивание метода r к объекту, мы вступаем на зыбкую почву. Мы должны гарантировать, что x.r(y) есть то же самое, что и y.r(x) для любых пар (это довольно легко, если x и y одного класса), но что если x и y принадлежит различным классам, но как значения концептуально эквивалентны? Например, всё тот же класс Rational и мы хотим чтобы оно проверялось на равенство с вещественными числами. Или чуть сложнее: мы например можем ввести отношение == на списках, пусть они будут эквивалентны, если они поэлементно равны. Аналогично мы можем ввести отношение эквивалентности на хэш-таблицах. И вполне естественно, что мы можем захотеть, чтобы список [a,b,c] был эквивалентен хэштаблице [0->a,1->b,2->c]. Как будем реализовывать ==? А ввести отношение лексикографического порядка для всех сравнимых списков и хэшей?

Я уже не говорю о том, что если заданы операции == и <, то все остальные — !=, >, >=, =< определяются автоматически, но выразить этот автоматизм нет никакой возможности. Тем более, что сравнивать есть с чем: классы типов Eq и Ord сами знаете где.

Ещё? Хорошо. Конкатенация ленивых списков (их ещё в SICP зовут Streams).
a = ...
b = ...
func(a ::: b)
func принимает значения типа LazyList. Как будем реализовывать операцию :::? Ну казалось бы

public LazyList :::(LazyList that) {
  // приклеиваем к this that и возвращаем 
  return new LazyList(()->this)
}

Всё, мы в глубокой заднице. Представим теперь, что a — это очень большой, или даже бесконечный ленивый список. a ::: b будет преобразовано в a.:::(b), и затем чтобы вызвать метод ::: придётся вычислить a. Всё, мы зависли и/или сожрали всю память.

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

SV.>Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

Да, пример Account интересен, я тоже жду продолжения.

Здравствуйте, vdimas, Вы писали:

V>В модели графы объектов многих типов. Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов.

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

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

V>Т.е. ты уже замерил эффективность интрузивной очереди vs стандартной очереди?

Вообще это не надо, потому что даже стандартная очередь дает цыфры на порядок выше тобою указаных и никакого "падения навзничь" не обнаруживается.
Скромный подсчет, 1500 очередей, в 100 месаг в сек,длина очереди 500мс, дает следующий расклад — в каждой очереди 50 элементов * 1500 = всего 75 тыс элементов. У меня, для сравнения, десятки миллионов и то издержки на GC как то не впечатляют.

V>Не верю! (С)

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

>>>Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.

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

V>Ты скипнул аргумент о лишнем ветвлении в алгоритмах.

Не я, а ты. ты не в состоянии сравнить количество ветвлений в двух строчках кода.
Покажи тут разницу в количетсве ветвлений

return list ?? new ArrayList<T>();

return list ?? Static<ArrayList<T>>.Instance;

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

Ты не в состоянии выдать жосткие данные.

>забираемое сетью, еще порядка 1us на межпотоковую передачу сообщений. Все, что осталось — твоё.

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

>Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.

Зачем заранее создавать и хранить пустой список полей ? Это по требованию нужно делать. О чем я тебе и говорю уже в который раз.

V>Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.

Нет, все быстродействие съедает неэффективная очередь, а не GC. Профайлер показывает что издержки на GC ничтожные.

Здравствуйте, SV., Вы писали:

SV.>Нашелся один Sinclair, который привел целых два. Первый — бухгалтерия, которая оперирует счетами, но класс Account заводить неправильно, второй — решение квадратных уравнений, где ООП не нужно. Извините, если кого пропустил. Читал по диагонали, потому, что про коров читать не могу. Заратустра не позволяет.

SV.>Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).
Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом:

(T, T) resolveSqEq<T>(T a, T b, T c);

Потому, что алгоритму неважно, какая там точность. Ему важно, чтобы для T были определены операции умножения, сложения, возведения в степени -1 и 1/2, и получения обратного элемента. Всё. А, ещё пригодится константа 0.
Кормите алгоритм хоть октонионами, хоть матрицами — дайте определения операций, и дело в шляпе.

SV.>Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает.
У этого класса нет никакого поведения, поэтому совершенно непонятно, что именно инкапсулировать. "Состояние" объекта Account полностью прозрачно. Еще есть такая проблема, что в принципе понятие "состояние" у счёта штука очень условная. Грубо говоря, бухгалтерия — это набор проводок.
Исходя из этого набора мы можем высчитать всякие виртуальные вещи — типа "каков у нас остаток дебиторской задолженности на 1 августа 2012".
Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый. Есть ещё куча показателей, которые совсем никак не похожи на "объекты", существующие объективно и независимо от наблюдателя — к примеру, тот же "оборот дебиторской задолженности за период".
Решение, в котором счета — это объекты, а проводки — сообщения, которыми они обмениваются, потребует гонять эти проводки туда-сюда каждый раз, как мне захочется заглянуть в прошлое. Внезапно обнаруженный первичный документ, датированный прошлым сентябрём, сломает нафиг эту модель, т.к. его не "вставишь" между уже отправленными сообщениями.

Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор. Проводка — это тоже не объект, а просто запись некоторого факта. Поверх этого рисуются всякие расчётные операции, которые тоже нифига не объекты, а просто формулы (уровня пятого класса). Сведение баланса = проведение примитивного расчёта.

Здравствуйте, SV., Вы писали:

SV.> Просто потому, что мы мыслим объектами.

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

В конце концов ООП это не silver bullet, ООП довольно легко применить не к месту — "когда в руке молоток все становится похожим на гвоздь".

Функциональное программирование позволяет более понятно и просто решать некоторый класс задач:

When you anticipate a different kind of software evolution:

Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.

Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.

отсюда

Примеры достаточно хорошо изложены в SICP (я его читал не весь) из которого запомнилось подход к написанию кода, выполняющего символьное диффиренцирование.

Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.
Относительно ООП. Вот для меня что то в последнее время основное — чтобы поменьше писать кода, чтоб поменьше волноваться при очередных внезапных изменениях требований перед релизом. И у меня ООП, ФП и другие подходы служат одной основной цели — чтоб не копипастить, ибо если я начну такое делать, потребуется в 10 раз больше людей на развитие проекта. Итого — я вижу, что наследование позволит мне обеспечить расширяемость и избавиться от копипасты — я применяю наследование и не парюсь. Позволяет мне функциональный подход тоже писать компактно и снова избавляться от копипасты — применяю функциональный подход. Если это позволит писать меньше кода, я ко всему прочему еще и процедурный подход применяю. А если уж совсем прижмет, то и всякими DSL не брезгую. Мне на ООП и другие подходы полностью плевать, мне важно, чтоб в коде я мог разобраться и мне важно, чтоб соблюдался DRY принцип (Dont Repeat Youself, то есть поменьше копипасты чтоб). Пока применяемым мной подходом вполне доволен, ибо код в хаос не скатывается под воздействием внешних обстоятельств, а проекту уже года 2 и просто дикие изменения требований.

Здравствуйте, Steamus, Вы писали:

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

А мне нравится ООП в JS

И не нравится в C++/Java/C#

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

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

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.

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

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

Все борцы с ООП с маниакальным упорством выкусывают мелкий обозримый кусок и подсовывают его со словами ..ну давай-давай унаследуйся тут, декомпрозируй классом... мы поржём... Что так и будешь как дурак вместо 2+2=4 писать new Integer(2).добавить(new Integer(2)). Ха-ха-ха... и всё такое. Посрамили млин. Разумеется не буду. Я чё, кретин?

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

V>Ну дык, надо больше интересоваться как оно всё устроено и работает и меньше поддаваться догмам. Тогда бы ты понимал, скажем, чуть быстрее. А то мне приходится объяснять тебе простейшие вещи в десятках постов, в попытке преодолеть косность мышления.

V>То, что я высказываю точку зрения, не совпадающую со многими коллегами на этом сайте — я для этого сюда и пишу, собственно. Бо вторить банальностям как попугай — банально неинтересно, я их наизусть уже 20 лет знаю. Просто надо уметь смотреть на любой технический момент под разными углами, а не только с "единственно правильного".

Воинствующий Шериданизм на марше. Причем, текст почти один-в-один такой же

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Потому что ООП современное представляет собой варево из ООП и ФП

В практическом плане это совершенно пофигу, из чего варево. А обсуждать проблему с точки зрения истории программирования или CS мне здесь не интересно.

ВВ>, так что выламывание мозгов по крайней мере двойное

Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями.

ВВ>Ну тогда и кортежи надо убрать, это же просто синтаксис.

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

ВВ>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*.

Для чего важно?

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

Какая разница в практическом плане?

ВВ>Чистое ООП должно включать только то, что не вступает в противоречие с ООП.

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

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

Опять неаргументированный субъективизм. Если ты такой сторонник чистоты ООП, то должен понимать, что кеевскому определению SOA не противоречит. Идентити у сервисов есть — эндпоинт, обмениваться сообщениями они могут, детали реализации изолированы контрактом. А то что полиморфизма на базе иерархий наследования нет (полиморфизм реализаций контрактов есть) — так это вовсе необязательный признак ООП. Не ты ли недавно доказывал, что наследование контрактов не нужно?
Ну и главное — в практическом разрезе все это бесполежный буллшит. Главное — SOA удобно реализуется ОО-языками, и интерфейс ОО-языка 1 в 1 без смены модели меппится на контракт. А вот чисто функциональными — интересный вопрос, я бы с удовольствием послушал, какая сущность ФП будет описывать SOA контракт, чтобы его компилятор понимал и контролировал, а не только RPC фреймворк.

ВВ>А вот сервис в SOA имеет четкие границы, т.е. четкое различение между локальным и нелокальным вызовом, что в распределенке важно.

Круто. А еще есть четкая граница между персистентными данными в БД и неперсистентными в памяти. Тоже будем новую парадигму придумывать?

AVK>>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?

ВВ>Я думаю, меньше.

Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.

ВВ> Но всему требуется время.

Сколько? И ФП и гуевым фреймворкам уже много десятков лет, не новые, мягко говоря, вещи? Что танцору мешает?

ВВ>ФП построено на основе очень выразительной системы исчисления, но ФП довольно сложен в плане реализации

Ну то есть ФП уровня C# не достаточен? Почему и в каком месте?

ВВ>. Тот же Хаскелл — это такой большой исследовательский проект по разработке компилятора для ФЯ.

А казалось бы, какая связь.

ВВ>Думаю, UI пока еще не стал главным приоритетом

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

ВВ>Вообще ФП должно, наверное, противопоставляться не ООП, а императивному программированию

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

ВВ>. И по сравнению с императивным программированием ФП меняет просто все. Но до серьезной работы над UI пока еще не дошло, да.

Хуже то, что и направлений пока не очень то видно.

ВВ>Вообще ФП — сравнительно молодая парадигма.

Существенно старше ООП, что характерно.

AVK>>Что неудобно? Статические методы никаких проблем дизайна не решают.

ВВ>Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают.

Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом?

ВВ>Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными".

НУ И ЧТО?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

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

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

Здравствуйте, Steamus, Вы писали:

S>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

Понятие?

Здравствуйте, Mamut, Вы писали:

M>>>У нас вот, 100 человек функционально все описывают. Что мы делаем не так?

A>>а кто-то на асме код пишет, и что?

M>И то. Что твое заявление о неприспособленности ФП для реальной жизни, мягко говоря, смешно.

Смешно моделировать действительность функциональным языком. Хотя, скорее грустно.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Steamus, Вы писали:

IT>>>ЗЫ. Я могу ещё понапридумывать подобных существительных. Взять хоты бы объект или информация. Много их.

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

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

S>>Впрочем, всегда можно застолбить что-то типа — "Самая верхняя абстракиця!"

но и на это можно ответить — "Самое Умное слово". Всё так или иначе можно завернуть в некий класс/в некий верхний суперкласс, что бы оперировать им более общим способом. И тем самым упростить мозгу задачу.

IT>Если принести в жертву здравый смысл, то можно много чего куда поназаворачивать.

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

Здравствуйте, Mamut, Вы писали:

M>Только вот к реальной жизни это опять же не имеет никакого отношения.
...
M>И не имеет никакого отношения к реальной жизни.

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

Здравствуйте, vdimas, Вы писали:

S>>О, уже timeModel появилось.
V>Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.
Сколько ни кури, ООП в численном интегрировании так и не появится.

V>Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.
Давайте пока не будем отклоняться от темы в сторону UML и прочих левых нотаций. Пока что вы предлагаете переместить состояние timeModel из специального объекта-синглтона в специальный объект-синглтон. И не хотите, чтобы я задавал глупые вопросы. Я всё правильно понял?

V>Дык, а кто мешается этому синглтону уметь отправлять сообщения?
Лезвие Оккама. А больше — ничего. Мы можем сделать целый массив длины 1 из массивов длины 1 из объекта специального унитарного класса, который будет отправлять сообщения самому себе, и это всё ещё не будет ничему противоречить. Ну, кроме чувства прекрасного.

А ваше желание называть объектом всё, что угодно, неконструктивно. Потому как не позволяет провести границу между ООП и не-ООП.

V>После этого твоего поста я понимаю — почему. ))
Я так не думаю.

Здравствуйте, vdimas, Вы писали:

V>Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

Во-первых, причем тут побочный эффект. Во-вторых, то, что идет после then и else в хаскелле вообще-то не вычисляется.

V>Про последовательное исполнение в Хаскеле — do-стрелки.

Что такое do-стрелки? Do — это сахар для bind, стрелки это стрелки. Вообще стрелки и последовательное исполнение — это из области "слышал звон".
А через монады в Хаскелле как раз и описывается императивный код. Do-нотация так вообще специально гриммируется под императивную программу. Ну и что?

V>Про ветвление — уже сказал.
V>Про циклы будем или уже ну его? )))

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

Здравствуйте, AndrewVK, Вы писали:

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

В этом и состоит моя ирония, т.к.:
— по определению чистых ф-ий им не важен порядок вычисления операндов;
— ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;
— но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.

V>>Ну а теперь вики:
V>>Структу?рное программи?рование ...
V>>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
V>> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
V>> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
V>> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

AVK>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.

Заблуждение.

AVK>А логические ветвления присутствуют, наверное, в любой парадигме.

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

V>>Про последовательное исполнение в Хаскеле — do-стрелки.
AVK>А при чем тут Хаскелл?

А чтобы сферических коней не гонять туда-сюда.

V>>Про циклы будем или уже ну его? )))
AVK>Циклов в ФП тоже нет.

Таки будем? )))

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

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

* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

* В программировании рекурсия — вызов функции (процедуры) из неё же самой

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

Здравствуйте, vdimas, Вы писали:

V>В этом и состоит моя ирония, т.к.:
V>- по определению чистых ф-ий им не важен порядок вычисления операндов;
V>- ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;
V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.

Когда надоест писать чушь про Хаскелл, рекомендую сходить сюда: http://haskell.org

Здравствуйте, vdimas, Вы писали:

V>Ну а теперь вики:
V>

V>Структу́рное программи́рование ...
V>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

V> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

V> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;

V> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

V>В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.

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

V>Про последовательное исполнение в Хаскеле — do-стрелки.

Структурное программирование есть машина тьюринга. Функциональное — лямбда-счисление черча. Функциональное на низком уровне реализовано через структурное, так процессор работает, пока что в природе нет процессоров которые умеют лямбда-счисление.
Соответсвенно ты снова попутал идею и реализацию идеи

Здравствуйте, AndrewVK, Вы писали:

ВВ>>Ну раз к линку попривыкли, наверное, и до монад не так много осталось.
AVK>Возможно. Но почему тогда ООП обвиняется в мозговыламывании, а ФП нет?

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

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

Ну тогда и кортежи надо убрать, это же просто синтаксис.

ВВ>> Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым
AVK>Блин, ну что за любовь приписывать мне какие то странные мысли? Я не говорил, что ФП становится менее чистым. Речь о том, что в ФП королевстве все примерно так же, как и в ООП. Базовая концепция в какой то часто встречающейся ситуации приводит к неудобству.

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

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

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

Чистое ООП должно включать только то, что не вступает в противоречие с ООП. Алгебраические типы не вступают в противоречие с ФП. "Лямбды" и статические методы вступают в противоречии с ООП. Так что, извините, придется их редуцировать.

ВВ>>ФП это далеко не обязательно про иммутабельность.
AVK>Обязательно. По определению.

У тебя какое-то неправильное определение. А из него происходит и неправильное понимание ФП. ФП — это не иммутабельность. ФП — это функции и детерминизм. Но ФП вообще не против состояния, ФП против только *нелокального* состояния. ФП — это про referential transparency. Локальное состояние не противоречит RT, а следовательно — и чистому ФП.
Поэтому в рамках чистого ФП не только возможны, но и вполне активно используются мутабельные структуры данных.

ВВ>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел.
AVK>ОО-RPC кто то отменил уже? Ну и по мне так SOA вполне себе в духе ООП, и прекрасно с ОО-языками уживается.

По-моему, да

Я его видел и даже сам писал в 2002-2003. Потом оно стало куда-то упорно исчезать. Проектов разных я вижу довольно много, так что статистика определенная есть.
А SOA может и уживается с ОО языками, но оно вообще-то не очень в духе ООП. Я бы даже сказал, что оно принципиально не в духе ООП, там ООП нет ни грамма.

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

ВВ>> UI будет.
AVK>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?

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

Вообще ФП — сравнительно молодая парадигма. Идеи — да, давно витают. А реализации стали появляться-то сравнительно недавно. Та же Миранда — это уже середина 80х. А Миранда практически исключительно варилась в академии.

AVK>>>Нет, статические не выходят, потому что никаких проблем ООП не решают.
ВВ>>Как же не решают. Решают стандартную проблему — "неудобно".
AVK>Что неудобно? Статические методы никаких проблем дизайна не решают.

Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают. Решают проблему с "неудобством". Причем способами, которые ФП не противоречат, в отличие от.

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

Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными". Где здесь аналогия?

Здравствуйте, Mamut, Вы писали:

M>Ставлю тебе задачу:

M>Моделируем игровой мир. Дверь может открыть игрок, может открыть ветер, дверь может открыться, если она под наклоном, из-за силы тяжести.
M>Если ты опять сделаешь дверь.открыть(), то к реальному миру это опять не будет иметь никакого отношения.

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

Если дверь открывается от ветра и под наклоном, то, не исключено, что речь идёт о сельском сортире. Уже некая определённость с задачей. Хорошо. Предположим вы внутри, и дверь открылась. Невезуха, да. Но какая вам разница от чего она открылась? От ветра ли, от того что сосед накренил сортир или просто некий “пролетающий” мимо чибис дёрнул за ручку. Главное что дверь перешла из состояния ‘закрыта’ в состояние ‘открыта’. Да что там дверь, весь сортир перешёл из состояния ‘сортир с закрытой дверью’ в состояние ‘сортир с открытой дверью’. А вам то что до этого? Абстрагируйтесь-абстрагируйтесь... Кто-то дёрнул метод ‘открыть’, во делов то. Пока для вас это не важно, вы можете не обращать на это никакого внимания.

Ладно, допустим, для вас это всё-таки важно. Скажем, вы хотите начистить репу этому залётному чибису (накрайняк — соседу). Ну затребуйте в параметре какая сука вызвала метод ‘открыть’. Хозяин вы своему коду или не хозяин?

Допустим чибис практически не виноват. Он, пролетая, дёргает все попадающие на пути двери (натура такая, ищет где нарваться на приключения). Некие двери открываются, некие нет. Усложним модель. Введём в дверь метод ‘воздействовать’ с некими параметрами типа (ё.пнул ногой, дёрнул за ручку, зацепил сапогом/бампером, пальнул из РПГ и так далее). Внутри метода тщательно анализируем угол приложения усилия и саму его величину и, о чудо, сами вызываем свой метод ‘открыть’, переводя сортир в паблик/стриптиз состояние. И вот... наша пикантная модель заиграла новыми красками. Любой сторонний объект может воздействовать, а мы, подумав/посчитав (да хоть эрлангом) вежливо открываем дверь. Всё живёт, всё крутится...

Здравствуйте, Steamus, Вы писали:

S>И многие даже используют ФП языки, ибо инструмент в своей нише — мощный. В своей нише.

Вообще-то, ниша ФП — это любой код внутри метода.

SV.>Просто потому, что мы мыслим объектами.

Оставлю тут: Execution in the Kingdom of Nouns

Здравствуйте, samius, Вы писали:

S>Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
Гипотеза интересная, но смолток из коробки был построен на сверхпозднем связывании. Экономить они научились уже потом — хотспоттинг и спекулятивные оптимизации были придуманы ровно для него, и уже потом перетащены в джаву.
S>Отчасти поэтому мы и имеем кучу работы с сингатурами, сложными правилами совместимости и прочим, вплоть до несовместимости Func/Action в C#. В ФП с более накладным применением аргументов все как-то намного проще.
Я вижу пока что бурление языков; каждый автор имеет своё представление о том, что и кому нужно. Академики откатывают концепции, практики — прикручивают изолентой то, что может пригодиться. В итоге из паскаля мы имеем академический Оберон (явный научный успех и не менее явный провал в популярности) и практичный Delphi — с кучей посторонних вещей, включая (о, ужас!) динамическую типизацию, но категорически популярный.

Здравствуйте, samius, Вы писали:

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

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

Ничуть не далеко. Хотя ООП-дизайн состоит сплошь из абстрактных типов, но в рантайм работают вполне конкретные типы, которые орудуют вполне конкретными данными, ничуть не хуже, чем ФП орудует структурами. Там всех отличий в механике ФП vs ООП, что в первом случае мы просто трансформируем данные, а во втором случае мы эти трансформированные данные перезаписываем по одним и те же адресам, в которых хранится состояние объекта.

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

S>Все равно что сказать что паровоз это телега с самоваром, забыв упомянуть что ездит по рельсам и что чай не является побочным продуктом от езды.

На подобные кривые аналогии у меня всегда реакция как на кислый лимон. Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Предлагаю провести мысленный эксперимент. Двум тысячам одинаковым неглупым людям, девственным в программировании, поставим одинаковый набор задач, но разные учебники программирования. Половине букварь по ООП, другой — букварь по ФП. Каковы ваши ставки? Если вы считаете что ООП-шники напишут быстрее/качественнее и т.п. просто потому что мозги практикуют именно ООП, то к чему опять-таки тема про то как мало людей понимает ООП.

S>Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.

Вы уверены что большинство C++/Java/C# программистов прочитало хотя бы один букварь по ФП? Я не уверен.

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

интерфейс ИОткрывашка

класс Пинок : ИОткрывашка

класс Сквозняк : ИОткрывашка


класс Дверь
  метод Откройся(ИОткрывашка)

туц Дверь().Откройся(туц Сквозняк())

Навеяно by земля.копайся() (ц) Sinclair
З.Ы. туц == new

Здравствуйте, samius, Вы писали:

S>Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

Давай впредь обойдемся без диагнозов, ОК?

... << RSDN@Home 1.2.0 alpha 5 rev. 59 on Windows 7 6.1.7601.65536>>

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Здравствуйте, Mamut, Вы писали:

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

S>>>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

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

Что интересно, люди понимающие ООП, как правило имеют неплохое представление и об ФП. А вот обратное — неверно. ФПшники тотально не понимают на каком уровне ООП работает. Откуда и всё эти наивные вопросы, которые им самим кажутся прикольными и типа ООП-тупиковыми. И тема очень ярко это показывает. 40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:

У кого-то проблемы с дверью? А по физике разве ни одной задачи не решили в школе? А импульсы тел не находили?

LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).

Ну ты с ошибками описал. Конкретно здесь есть:
— состояние+поведение травы,
— состояние+поведение коровы.

Ты предложил некое действие, совершаемое кем? Коровой. корова.щипать(трава)
В результате действия изменяется состояние чего? Травы. трава.бытьОщипанной(кол-во ощипанного). Заметь, в твоем варианте интерфейс травы какой-то левый, нерелевантный исходному дизайну.

Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так:
Природа.поедание(коровы, трава).

И да, возможен аналогичный же сценарий: Коровник.поедание(коровы, комбикорм).

LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях. Думаешь, нахрена нужны суперкомпьютеры для вычисления результатов ядерного взрыва??? По-твоему, эти суперкомпьютеры нужны для вычисления смешной формулы с максимум всей сложности — возведением в 3-ю степень? ))

Здравствуйте, Steamus, Вы писали:

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

Здравствуйте, vdimas, Вы писали:

V>Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так:
V>Природа.поедание(коровы, трава).
Прекрасно. Ваши аргументы против ООП безупречны.

LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

V>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.
Осталось выяснить, какое место в этих видах моделирования занимает ООП.
Надо полагать, там молекула воды наследуется от двух атомов водорода и одного атома кислорода?
Или всё сводится к какому-то аналогу cluster.Compute(task)?

Здравствуйте, Steamus, Вы писали:

S>По правде говоря — забавно. Какие-такие иные особенные волшебные подходы предоставляют другие методологии проектирования/программирования, что люди их практикующие могут эдак снисходительно потешаться над ООП? Дескать... ООП клоуны вы все, вот у нас о-о-о как всё круто!
Никто не потешается над ООП. Потешаются над людьми, покусанными ООП, и пытающимися заменить всё на свете при помощи ООП.
ООП прекрасно работает там, где оно уместно. Но это никак не связано с особенностями того, как мыслит человек.

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

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

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

M>>Это такая масштабная попытка показать выделенное

AVK>Крайне неудачная, имхо.

Ну не писать же постоянно открытым текстом, что я думаю

Хоцца и попытаться подвести человека к каким-то выводам. Увы

Не всегда получается

Здравствуйте, vdimas, Вы писали:

V>ООП как и ФП зиждется на структурном программировании

Можно поподробнее раскрыть мысль, как основа основ структурного программирования, императивный алгоритм, послужил основной ФП?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Покажи сайд-эффект if-а Хаскеля, не балаболь.

V>В выделенном смысле уже показал.
выделенный смысл ты выдумал. Нет таких эффектов в выделенном тобой смысле.

S>>>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

S>>Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.

V>В исходнике, что ле? С ума сошел? Я могу рассуждать только о работе программы в рантайм. И я тебе уже всё показал.
Так порассуждай и о Логическом программировании в таком же ключе. Получишь что и Логическое выросло из структурного.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
I>>А что ты видел в дизайне распределенных ?

ВВ>Анемики, сервисы и иже с ними.

Это все православное ООП

Здравствуйте, Sinclair, Вы писали:

S>Оффтоп: всё же я люблю шарп

Ты его недостаточно любишь

public static class NotNullUtils {
    public static IList<T> AsNotNull<T>(this IList<T> list) {
        return list ?? EmptyArray<T>.Value;
    }

    public static String AsNotNull(this string str) {
        return str ?? "";
    }

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, grosborn, Вы писали:

G>А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas.
Если вы — второй аккаунт vdimas'а, то вас я тоже буду игнорировать.
А если нет, то мысль про отсутствие стека в C# я взял отсюда:

J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.

Вы точно уверены, что это не вы писали?

Здравствуйте, IT, Вы писали:

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

Здравствуйте, vdimas, Вы писали:

V>Как же назвать технику, на которой работают вложенные ф-ии Паскаля?

Техника называется "static chain", изобрели ее около 1964-го года Рэндалл и Рассел, описана в Algol 60 Implementation — B.Randell & L.J.Russell, Academic Press, 1964.
А технику "замыкание" изобрел в том же году Ландин и реализовал впервые в SECD.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

I>>>>"прирост до 50 раз " @ vdimas
V>>>Этот множитель сложился из двух множимых. См. исходный пост на русском языке: http://www.rsdn.ru/forum/philosophy/4843592.1.aspx.
I>>То есть, ты разницу между IList и List помножил на разницу между ручной и встроеной серилизацией ?

V>Наоборот, разделил общий эффект на разницу м/у ручной и встроенной сериализацией, чтобы получить прирост от тупой замены абстрактных типов на конкретные.

То есть во фразе "множитель сложился из двух множимых" слово "сложился" надо понимать как произведение, но при этом надо делить ?

I>>Итого, максимальная разница между List и IList в 2.5 раза. С valuetype вместо object разница еще меньше, всего 1.5 раза.
I>>Вероятно "от 3-х до ~10-ти" ты получил вообще на пустых итерациях

V>Итого, у тебя опять работает заведомо синтетика и заведомо некорректная.
V>Даю тебе вторую попытку. Вместо 10КК прогонов по циклу попробуй прогон по десяткам элементов (это ближе к реальной задаче сериализации разветвленного графа объекта в памяти), а внешний цикл пусть будет 10КК/x, где x — кол-во элементов.
V>Сразу получишь более 3-х раз разницы (у меня — 3.75).

Никакого "сразу" быть не может. Время колеблется от прогона к прогону, что для дотнета вобщем то норма.
Вот результаты 10 прогонов двух тестов — total(for IList<>)/total(for List<>)
4.0 3.5 2.0 2.5 2.7 2.9 2.3 2.4 2.9 2.3
Дальше мне стало лень

>Ну а потом погоняй стоимость вызова других методов, например стоимость обращения к элементу по индексу (иначе нахрена именно IList??).

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

V>В общем, более 8-ми раз на реальных задачах выходила разница из-за простой замены IList<> на конкретные типы. По приведенной ссылке — результаты с реального проекта.

После твоих "уточнений" я всерьез думаю ты или попутал результаты(массив вместо List и тд) или просто сочиняешь, выбирай сам.

V>Думаю, более корректным будет тест с глубиной вложенности объектов хотя бы 2. Т.е. было бы неплохо сделать коллекцию в коллекции, разбив эти 100 элементов хотя бы 10*10.

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

I>>Объясняю — использование List может быть очень дорогим удовольствием, а хочется, что бы некоторые функции вроде Linq2Objects работали крайне быстро, выход — IList<>

V>Это не объяснение, а туманность Андромеды. Покажи, где IList<> будет быстрее List<>.

Это очень просто, IList<> может иметь любую реализацию, т.е. оптимизация под конкретные сценарии, не любые а именно те что нужны. У меня вот нет ручной серилизации

Смотри внимательно, моя реализация IList
Contains O(N/K)
IndexOf O(N/K + K/4)
Remove — O(N/K)
RemoveAt — O(N/K + K/4)
RemoveAt(0) — O(1) для сравнения List имеет здесь O(N), что в линейном алгоритме даёт O(N^^2) — очень жОсткое ограничение, т.е. просто так использовать практически никак
Дополнительно моя реализация никогда не попадёт в LOH, например это проявляется в том, что в GC вызывается примерно на порядок реже и прога не валится от OOM после получаса зависания в GC.

В сумме это примерно так — операции которые педалили по 6 часов и более теперь укладываются в 5 минут, а время отклика UI уменьшилось в среднем в 10 раз.

V>>>Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.
I>>Ты похоже не понимаешь — если List это очень дорого, то и массив тоже будет так же дорого.

V>Да, пока что не понимаю, пока ты не показал, где IList<> будет быстрее List<>.

Вероятно ты IList<> понимаешь исключительно как ((IList<>)List<>)

I>>Реальная разница в 2.5 раза на почти пустой итерации. Если цикл чуть сложнее суммы элементов, эта разница становится ничтожной.

V>Для задач просто чтения элементов, о которой речь в сериализации, разница оказалась катастрофической. При десериализации тоже тоже оказалась в несколько раз, бо при десериализации используются те самые остальные методы интерфейса List/IList для наполнения коллекций.

Чушь, разница в добавлении от силы в 10% в вырожденых случаях.
Инлайн дает эффект только тогда, если тело метода тривиальное. Добавление "тяжелая" операция — раскрой метод тулом и посмотри, ты сэкономишь ровно один виртуальный вызов, что для Add вообще ничего. Скажем Array.Resize в сумме съест намного больше.

Здравствуйте, Ikemefula, Вы писали:

I>>>Это почему питон и руби не мейнстрим ?
K>>По факту.
I>Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

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

K>>В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.
I>Если смотреть внутрь реализации, то окажется что все мы пишем на ассемблере.

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

I>Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.

Это, скорее, в тему соседней ветки, где предсказывающий эффект по модели "замыкание" получает UB.

I>популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

Я об этом ниразу не сказал, потому что считаю это неправильным.
1) Не наблюдается никакой связи между тем, для чего язык разрабатывался и тем, для чего он применяется.
Мы живем в мире, в котором серверные приложения пишут на языках, которые разрабатывали например для программирования интерактивных телевизоров, "программирования" мигания текста на веб-страничке, скриптования обработки текстов.
Это объяснимо, конечно, потому что большинство языков, не смотря на заявляемую когда-то авторами "принадлежность", не имеют никакой специализации и являются языками общего назначения. Даже когда язык действительно специализирован — эта спецуиализация по мере развития разбавляется совершенно посторонними фичами. В SQL добавляют императивные конструкции, регулярные выражения перестают быть регулярными и т.д.
Подавляющее большинство языков не заточены под какую-то нишу.
2) Выбор языка определяется, в основном, возможностью нанять программиста на этом языке. Разумеется, имеющаяся в таком подходе положительная обратная связь раздувает любую флуктуацию до космических масштабов и делает популярность языка случайной. Невозможно предсказать какой из языков станет популярным, а какой канет в забвение: A или A', который от A отличается оттенком перламутровых пуговиц.
3) Если же язык выбирают по техническим причинам, то выбирают не языки, а реализации и инфраструктуру, причем набор неигрушечных реализаций для нужных платформ часто вообще отсутствует. Понятно, что и тут положительная обратная связь, выхватывающая из шума случайный кактус и заставляющая его есть десятилетиями.
4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
Сдвиг парадигмы не происходит от изменения задач, а ппоисходит от развития техники, которая начиная с какого-то момента позволяет иметь новый уровень удобств. ООП стал популярен, когда его стало можно себе позволить. И ФП становится популярным в последнее время по этим же причинам. Смолток просто морально устарел раньше, чем его смогли себе позволить использовать значительное количество программистов — вот и все.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>Надо определиться имеют ли смысл ЯП в отрыве от задач.

Никакой инструмент не имеет смысла в отрыве от задач. Проблема в том, что вы не понимаете для каких задач существуют обсуждаемые инструменты. Языки общего назначения — это инструменты для разработки инструментов: библиотек, ДСЛ, других языков общего назначения. Это и есть задача. Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
Выбор языка происходит не под задачу, а так:
1) Отсекаем все языки, для которых вы не найдете программистов.
2) Отсекаем все языки, для которых нет устраивающих вас реализаций.
3) отсекаем все языки, не имеющие набора библиотек, которые нужны для решения ваших задач.
Вот теперь мы переходим к сравнению языков:
4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
Чем продвинутее язык, тем сложнее его реализовать и тем позднее появится практически пригодная имплементация. У каждого нового языка первоначально нет библиотек. Почему же происходит смена? Продвинутый язык лучше подходит для написания библиотек и потому рано или поздно догоняет и перегоняет.

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

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

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

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

I>Внятно сказано — стек был и до алгола

Где?

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

"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.

I>Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.

Разделение на замыкание и static chain вполне имеет смысл. Это вы сами обосновали выше, сравнивая их. Это необходимые сущности, их введение обосновано.

I>Пустой контекст это просто конкретный случай а не новое понятие.

Новое понятие, которое вы вводите, для объединения замыкания с "не замыканием" — действие не только бесполезное, но и вредное, согласно вашему же обоснованию.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Не понял. А кто нам запрещает сообщения отсылать в инфиксной форме?
Инфиксность формы неважна.
ВВ>В Смолтоке, кстати, инфиксные сообщения были. А это, если не считать Симулы, самая заря ООП.
В Смолтоке сообщения отправлялись совершенно конкретному объекту. То, что в нём выглядело как инфиксная форма — всего лишь синтаксис.
А я говорю о семантике — когда я пишу 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__ — это уже отход от ООП и чудовищное неравноправие различных операций.
Вывод: диспетчеризация бинарных операций, в том числе отношений, плохо ложится на ООП.

Здравствуйте, DarkGray, Вы писали:

DG>вот, например, счет Xxx при доступе через инет-банк, банкомат и операциониста — это один и тот же счет или разный?

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>На Хаскеле МОЖНО писать чистые участки кода... это да....

Да, и весь код из таких участков и состоит.

V>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? ))

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

V>чистая ф-ия -> порядок вычисления аргументов не важен, так?

Нет, не так.

V>Ну т.е. прикол-оксюморон и ничего больше...

Ну, неправильная посылка -> абсурдный вывод. Все как обычно.

V>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.

В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.

V> Только из-за этого счел возможным проводить параллели м/у таким ФП и СП, бо происходящее аналогично

Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще. Чем дальше вы проводите аналогию — тем серьезнее проблемы с пониманием.

S>>Что за "экземпляр" монады?
V>Это такой функциональный объект.

Это не ответ на вопрос.

V>волнует конечная генерируемая программой польза, то бишь её побочные эффекты.

Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат.

V>и защиты от них НЕТ.

Наоборот — защита есть. Ради этого все и затевалось.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

> G>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.
>
> Нет, это не тот ООП, который выбираем мы. Когда вы пишете в скайп, вы всегда отправляете абстрактное сообщение, частным случаем которого является текст или файл? Вы в самом деле так мыслите? Или вы все же отправляете тексты и файлы?

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Философ, Вы писали:

V>>Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.

Ф>Оно там через векторные поля считается, никаких частиц.
Ф>http://ru.wikipedia.org/wiki/Векторное_поле

Да что ты говоришь? Термин "метод частиц" не слышал никогда?
Метод частиц в ячейках
Гидродинамика сглаженных частиц

Здравствуйте, kittown, Вы писали:

K>Введем в рассмотрение ФП, где на вход функции дается состояние, а на выходе получаем новое. С учетом работы GC каких-то практических отличий от изменяемых объектов будет негусто.

А какие вообще проблемы моделировать ФП на ООП или наоборот?

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

K>При этом еще интересно посмотреть на обьекты ocaml.

Как раз неинтересно, бо ocaml — мультипарадигменный язык. То бишь ему ничего не надо моделировать, у него и так всё есть.

Здравствуйте, Steamus, Вы писали:

S>Смешно моделировать действительность функциональным языком. Хотя, скорее грустно.
Смотря что вы называете действительностью. Моделировать "действительность" с помощью ООП значительно смешнее. Я пока ещё не встретил такого случая, где ООП было бы реально пригодно для моделирования "действительности". Скажем, в бухгалтерии делать class Account — верх глупости. Делать class FinancialDocument — ещё большая глупость. Какое-то место можно найти классам BalanceCalculation и TransferRestrictionRule. Но ни того, ни другого в "действительности" не наблюдается, по крайней мере на первый взгляд. Большинство из "объектов", наблюдаемых в дикой природе, не заслуживают в программе большего, чем некая структура данных.

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

Здравствуйте, samius, Вы писали:

S>>>Контрпример — ALGOL 68
I>>Там тоже есть замыкания.
S>Интересно, а авторы в курсе?

Насколько я знаю, стандарт не обязывает реализовывать замыкания. Т.е. решение upwards funarg problem не требуется. При том, что все что нужно для полноценных замыканий (включая GC) в Algol 68 есть. Видимо поэтому, в некоторых реализациях 70-х замыкания были, но не во всех. В той реализации (современной), которой я проверял этот код замыканий не было.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

> S>>То что ты называешь лексическим замыканием в паскале, всего лишь http://en.wikipedia.org/wiki/Lexically_scoped#Lexical_scoping, который распространяется на вложенные функции.

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

> Замыкание же позволяет использовать переменные ИЗВНЕ их lexical scope (http://en.wikipedia.org/wiki/Closure_%28computer_science%29)

Так же и во вложенной функции позволительно использовать переменные вышестоящего scope.
Внешние отличия чисто косметические. Внутренняя реализация конечно другая. Хотя строго говоря вложенные функции это не замыкания (технически и формально), но называть их замыканиями вполне можно, хотя путать их тоже нельзя. Это просто другая реализация с тем же смыслом и теми же целями. Там называлась так, здесь называется по другому, но это одно и то же.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, SV., Вы писали:

SV.>А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

ООП само по себе не делает код понятнее.
оно *может* сделать код понятнее, если его применить там где его надо применить,
и можте сделать код запутаннее, если его применить там где его не надо применять.

да, мало людей понимает ООП.
есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код,
и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код.

> Хотя ситуация вымышлена, пример самый настоящий:
>
>

>
> Что он отражает? Он отражает наши представления о мессенджерах. Допустим, это плохие, негодные представления. Мессенджеры так себя не ведут. Ладно, но вы же ВСЁ ПОНЯЛИ, что было в голове у архитектора? В этом и суть.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, SV., Вы писали:

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

Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?

Здравствуйте, Steamus, Вы писали:

S>То есть, к счастью, некие вещи таки устоялись в трёх мейнстримовских языках (Java, C++, C#). Класс/тип — чистая ментальная абстракция. Объект — осязаемый экземпляр класса, который вы создаёте (инстанциируете) когда нужно. Нет никаких догадок и автоматических инстанциаций. Классы могут наследоваться. Это абсолютно естественно, если отражает реальную модель мира, а не удобный способ "зацепить" функциональность.

А что такое "реальная модель мира"?

Здравствуйте, Mamut, Вы писали:

M>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду
создать объект "дверь". у двери могут быть состояния: открыта, закрыта, закрыта-и-замкнута, на-обслуживании. у двери есть методы...

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

возникает вопрос -- что общего между окном и ящиком? в процедурном программировании можно создать функцию open(obj) и абстрагироваться от объекта (в частности, у окна может быть свойство прозрачности/матовости).

в случае ооп мы пишем obj->open(). поскольку obj приходится наследовать от абстрактного класса, которому трудно дать осмысленное имя, то добавление новых объектов затруднено и реально только в рамках одного компилятора.

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

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

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

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, Mamut, Вы писали:

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

S>Мдя...

S>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу...
сарказм неуместен. открытие двери и окна реализуется практически идентичным кодом. писать псевдокод лень, но будет что-то типа -- объект заперт? если да, то вставить ключ и отомкнуть. повернуть ручку и сделать pull/push в зависимости от флажка.

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

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

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

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

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

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

S>Задач мне ставить не надо, право же, мне неловко бесплатно решать их для Вас...

S>Абстрагируйтесь-абстрагируйтесь...

А ну да. Внезапно «реальная жизнь прекрасно ложится на ООП и наоборот» первращается в «абстрагируйтесь»

S>Кто-то дёрнул метод ‘открыть’, во делов то. Пока для вас это не важно, вы можете не обращать на это никакого внимания.

Ага. То есть все сказки про то, как ООП отражает реальну жизнь являются строго сказками. Уже внезапно «неважно, кто дернул метод открыть». Ну-ну.

S>Ладно, допустим, для вас это всё-таки важно. Скажем, вы хотите начистить репу этому залётному чибису (накрайняк — соседу). Ну затребуйте в параметре какая сука вызвала метод ‘открыть’. Хозяин вы своему коду или не хозяин?

При чем тут хозяин-не хозяин? Хотя, я знаю при чем — попытка уйти с обсуждения куда-то не в ту степь.

S>Допустим чибис практически не виноват. Он, пролетая, дёргает все попадающие на пути двери (натура такая, ищет где нарваться на приключения). Некие двери открываются, некие нет. Усложним модель. Введём в дверь метод ‘воздействовать’ с некими параметрами типа (ё.пнул ногой, дёрнул за ручку, зацепил сапогом/бампером, пальнул из РПГ и так далее).

Только вот к реальной жизни это опять же не имеет никакого отношения.

S>Внутри метода тщательно анализируем угол приложения усилия и саму его величину и, о чудо, сами вызываем свой метод ‘открыть’, переводя сортир в паблик/стриптиз состояние. И вот... наша пикантная модель заиграла новыми красками. Любой сторонний объект может воздействовать, а мы, подумав/посчитав (да хоть эрлангом) вежливо открываем дверь. Всё живёт, всё крутится...

И не имеет никакого отношения к реальной жизни.

Здравствуйте, Steamus, Вы писали:

S>Внимание, ставлю вам задачу – сколько времени пройдет, пока нормальный здоровый мозг, выделит общий класс ‘Полено’ из табуретки, полки и акустической системы Танной 1972 года? И при какой температуре окружающей среды это произойдёт. Влияет ли температура окружающего воздуха на способность мозга к обучению абстрагированию/выделению общих сущностей?

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

Здравствуйте, Mamut, Вы писали:

F>>

F>>class Programmer
F>>{
F>>    open(Openable obj);
F>>}

F>>Programmer mamut = new Programmer();
F>>mamut.open(fridgeDoor);
F>>mamut.takeOut(beerBottle);
F>>

F>>Так сойдет?

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

Шо, опять?! Сильное упрощение?

Я уже приводил стандартный подход. Дверь наделяется методом 'воздействие'. Метод сам решает откроется она или нет.

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

Это что-ли малопопулярный Эрланг, который был изобретён лет на 10 раньше Джава вдруг вырос в такую мощную и культовую проектировочную дубину пока я тут спал? Да? Или старичок Хаскель заметно проклюнулся на свой дваццать какой-то там годок? Или никому неизвестный Немерле внезапно поутру попёр?

Здравствуйте, Steamus, Вы писали:

S>Да. Это я неправильно сказал употребив фразу ...мозг работает... Никто не знает как он там себе работает. Скажем так, было замечено, что для понимания проблемы мозг "опускает" незначащие детали и оперирует только теми, которые важны для понимания проблемы. То есть делает некое абстрагирование, декомпозицию.
Абстрагирование и декомпозиция в программировании не являются эксклюзивными инструментами ООП и появились задолго до его появления.

Здравствуйте, Mamut, Вы писали:

M>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

Вопрос, что характерно, демонстрирует непонимание тобой основ ОО проектирования.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 59 on Windows 7 6.1.7601.65536>>

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

S>40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.
Вот как раз демонстрация вашей наблюдательности. Я вижу там лишь 2 плюса на текущий момент.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, BrainSlug, Вы писали:

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

S>Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.

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

Здравствуйте, vdimas, Вы писали:

V>И ты до сих пор не выяснил?
Я как раз выяснил. Был разочарован.
V>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике?
Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть?
Используются ли виртуальные методы?

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

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Wolverrum, Вы писали:

W>>Мысль простая... и ложная.

W>>Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.

V>Мозг работает образно и это уже многократно доказано. Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...

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

M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

AVK>Вопрос, что характерно, демонстрирует непонимание тобой основ ОО проектирования.

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

Каки бы ни были задачи, любая модель (ООП, ФП, процедурная) к реальности будет относиться по стольку по скольку

Здравствуйте, minorlogic, Вы писали:

M>Это какой то неправильный ООП

Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

Здравствуйте, Sinclair, Вы писали:

S>Если у вас есть другая информация — поделитесь. А надувать щёки и переводить разговор на личности не надо — я вам уже говорил, здесь это оффтоп.

Ай, ладно, это норма и ты сам это показал сначала ad hominem "Надо полагать, там молекула воды наследуется ", "надувать щёки" а потом уже пальчиком погрозил за аналогичный пассаж

Вобщем

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

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

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

Здравствуйте, pkl, Вы писали:

pkl>Здравствуйте, samius, Вы писали:

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

В контексте того что некоторые чуваки действительно представляют мир в объеках (или думают что представляют в объектах), я соглашусь. Но приписывать такое мышление человечеству в среднем — это лишнее.

Здравствуйте, Sinclair, Вы писали:

S>Для этого "объект" избыточен. Достаточно иметь "указатель на значение", а эта штука работает задолго до ООП.

"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания.

Конкретно по теме, что координата, что многомерный вектор — во всех графических либах это несомненные объекты.

S>Вы же не считаете, скажем, дековский ассемблер ООП-шным?

Гы-гы... Показываю смертельный номер:
============
Ну в нем макросистема существенно мощнее, чем в Си, но вы же не считаете, скажем, дековский ассемблер вдохновителем Немерле?
============
Занавес.

Здравствуйте, Sinclair, Вы писали:

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

Сколько сахар не повторяй, во рту сладко не станет.

S>Пытаться программировать так, как мыслит человек, вообще вредно. Скажем, банальное сложение целых внутри компьютера устроено вовсе не так, как его делает человек — потому, что компьютер может лучше.

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

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

Гы, нубы думают, что задача диктует решение, а это встречается гораздо реже, чем они думают.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>значит крут

V>Крут? )))
V>Добро пожаловать в реальный мир, Нео:
V>

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

Покажи мне ту работу, которую ФП выполнить неспособен.

V>Реальность такова, что в ООП применимы любые наработки ФП безо-всяких адаптаций, зато наоборот — увы и ах.
твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.

S>>И причем тут ООП?

V>При том, что мы склонны наделять свои абстракции-образы:
V>- характеристиками;
V>- поведением, зависящим от характеристик;
V>- отношениями с другими абстракциями.

V>За счет этого мы можем моделировать поведение окружающего мира, в свою очередь за счет этого у человека работает воля, появляется вообще такое понятие как работать "на будущее", будь это будущее даже не далее сегодняшнего ужина.
Бла-бла

V>Указанный выше список разве не описывает ОО-парадигму?
и почему-же он описывает только лишь ее?

Здравствуйте, vdimas, Вы писали:

V>Предположу, что только у наследованных от структурной.
V>Например, в логическом программировании никакого ветвления нет.
Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет?

Здравствуйте, Sinclair, Вы писали:

S>Оффтоп: всё же я люблю шарп

Но не достаточно сильно. ))

...
      return list ?? Static<ArrayList<T>>.Instance;
...

Здравствуйте, Sinclair, Вы писали:

V>>Математика вполне делится на области, которые можно сложить иерархически. Другое дело, что там получается полноценный направленный граф, а не урезанный его вариант — дерево.
S>Иерархия и есть дерево. Появился цикл — прощай иерархия.

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

S>Я не очень понимаю, что вы называете "делением на области". Вот, скажем, топология и мат.анализ — это такие области? И как вы сложите их "иерархически"?

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

V>>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.
S>

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

А одна и есть, просто я привел базис, а ты производные:
анализ — от общего к частному;
сравнение — от общего к частному;
абстракция — умение отбрасывать детали;
обобщение — умение ограничивать сравнение неким уровнем абстракции;

V>>Производственное удобство связано с удобством для производителя-человека. Как ни крути, но он так мыслит. Как бы некоторым не хотелось думать, что уж они-то мыслят не так. Чем мутнее образ в мозгу, тем он абстрактнее... только и всего.
S>Не надо натягивать презерватив на глобус. Человек не мыслит объектами из ООП, как бы некоторым ни хотелось думать, что уж они-то мыслят именно объектами.

А что есть, по-твоему, объект в ООП? Почему в дизайне мы называем объекты и/или классы "сущностями"? Дай своими словами определение "сущности".

Здравствуйте, vdimas, Вы писали:

I>>А как охарктеризовать вот такое: "Утверждать что фп растет из структурного подкрепляя это википедией, не упомянуа ни машину Тьюринга ни лямбда-счисление Черча" ?

V>Дык, прочти еще раз что я писал в пред посте и перед ним по этой же ветке — там все ответы.

V>=========
V>Ответы:
V>1 — потому что ты скатился в сплошную теорию, хотя структурное программирование, это ес-но никакая не теория, это парадигма, то бишь набор практик. Итого, уход от обсужденией аналогичных практик в догмы.

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

Здравствуйте, Sinclair, Вы писали:

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

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

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

Сказано было:
"А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения."
Подобные реализации есть — и никто не стреляется. Т.е. это заявление уже является некоторым преувеличением. Кстати, зачем? Зачем изобретать какие-то проблемы у ООП, как будто там реальных проблем нет.

ВВ>>Я еще раз повторю свою мысль — есть языки, в которых это сделано именно вполне ООП-но, причем совсем не экзотические языки. И они как бы работают

S>Слово "как бы" тут является ключевым.

Нет, слово "как бы" является как бы моим способ выражать как бы мысли. Можешь считать это рукописным заиканием.

ВВ>>С утра мне казалось, что я вообще-то понимаю, что такое ADT. А еще мне казалось, что противопоставлять ООП-шные объекты ADT как-то не совсем корректно. В лучшем случае ADT можно рассматривать как некое надмножество. И вот тут ты уже начинаешь вводить какие-то различия — "идентичность и поведение". Осталось только объяснить, что такое а) идентичность, б) поведение. Ведь если это такие простые и очевидные вещи, то и объяснить их можно очень просто, без всяких там ссылок куда бы то ни было. Или не получится?
S>Конечно же получится. Идентичность — свойство объекта отличаться от всех других объектов, независимо от его состояния.

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

S>Поведение — умение объекта реагировать на посылаемые ему сообщения (путём посылки своих сообщений и изменения своего состояния). Состояние — способность объекта по-разному реагировать на одинаковые сообщения, в зависимости от предыстории.

Ну т.е. поведение — это состояние и недетерминизм. Так?

S>К примеру, в языке C есть встроенная поддержка для ADT. А для объектов встроенной поддержки нету.

Эта мысль мне неочевидна. Там, где есть "встроенная поддержка для АДТ", ООП можно слепить двумя пальцами.

ВВ>>Это уже больше вопрос реализации, наверное. И того, что null в целом не самая хорошая вещь на свете.
S>А тут ничего не сделаешь. Если обходиться без null, то быстро окажется, что мы получили value-семантику, т.е. отказались от ООП-шности.

S>А так — вполне такое разруливается, как в том же Питоне, через пару методов __add__/__radd__.
S>И как питон понимает, какой из методов вызывать для a + b?

Как-то так:
http://www.java2s.com/Tutorial/Python/0220__Class/raddHandlesRightSideAddition.htm
И повторюсь — это решает ту проблему, которую на мой взгляд вообще можно не решать, просто вырезав под корень неявные приведения (что, возможно, не так уж и плохо, как кажется).

ВВ>>Вообще это вопрос больше о том, кто тащит с собой таблицу методов — она приклеена к значению или же передается отдельно.
S>Совершенно верно. И ООП на этот вопрос отвечает однозначно — методы приклеены к значению. Если у вас "таблица методов" передаётся отдельно, то это не ООП.

Это, разумеется, так. Ты же и утверждаешь, как я понимаю, что передача таблицы отдельно является более удобным способом для реализации математики. Отдельная таблица явно предлагает более гибкую схему диспатча — а вместе с ней и неимоверно более сложна в реализации. См. OverlappingInstances, UndecidableInstances и пр. Люди диссертации об этом пишут. Таблица, засунутая в значение, это, напротив, очень просто.
А в реальных языках мы имеем что? Все нумерик классы в том же Хаскелле — один тайп параметр. Т.е. инты складывает только с интами — и не более того.

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

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

S>Пока что не продемонстрировано убедительной математики на основе ООП.
S>И есть опасение, что даже если её удастся продемонстрировать, то она окажется многословной для программиста и неэффективной для исполнения.

Что есть "убедительная математика"? Если есть желание покритиковать Питон или Руби, то я с удовольствием послушал бы.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну раз к линку попривыкли, наверное, и до монад не так много осталось.

Возможно. Но почему тогда ООП обвиняется в мозговыламывании, а ФП нет?

ВВ>Ну можешь считать это подпорками, если тебе так хочется. Странно еще, кстати, что ты ПМ не вспомнил.

Совсем не странно. Здесь речь про дизайн, а ПМ на уровне контрактов прямо не фигурирует.

ВВ>Это действительно неудобно.

Об этом и речь.

ВВ> Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым

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

AVK>>Все что я хотел, я уже сказал. Если тебе не нравится моя точка зрения, это вовсе не означает что я неправ или чего то не сказал.

ВВ>Точку зрения неплохо чем-либо аргументировать.

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

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

ВВ>ФП это далеко не обязательно про иммутабельность.

Обязательно. По определению.

ВВ>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел.

ОО-RPC кто то отменил уже? Ну и по мне так SOA вполне себе в духе ООП, и прекрасно с ОО-языками уживается.

ВВ> UI будет.

Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?

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

ВВ>Как же не решают. Решают стандартную проблему — "неудобно".

Что неудобно? Статические методы никаких проблем дизайна не решают.

ВВ>>>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП
AVK>>Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.

ВВ>Что, тоже?

Постоянно упираются в неудобство и тяжеловесность чистого ФП.

ВВ> ФЯ упираются в тяжеловесность ООП? Что-то я вообще не понял, о чем ты.

Все ты понял, но опять занимаешься софистикой.

ВВ>Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП.

Ага, а армяне лучше чем грузины. Если повторить это 1000 раз, может что то и получится.

ВВ>А что происходит в ООЯ? Появляются мегамонстры вроде Скалы?

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

ВВ>Причем ФЯ развиваются как раз именно как ФЯ, ООЯ же уносит черт знает куда, в какое-то монстроподобие

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

ВВ>>Потому что ООП современное представляет собой варево из ООП и ФП
AVK>В практическом плане это совершенно пофигу, из чего варево. А обсуждать проблему с точки зрения истории программирования или CS мне здесь не интересно.

"Практический план" у тебя только что подключился. До этого вроде бы как о парадигмах говорили.
В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает. ФП нормальное можно построить либо вообще без системы типов, либо на основе чего-то вроде System F. В ООП-ные системы типов — ну не пролезает оно, один ПМ с кортежами и достается.

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

ВВ>>, так что выламывание мозгов по крайней мере двойное
AVK>Не двойное, так как в ООП добавляют далеко не все из ФП и с существенными изменениями.

Смотря, где. В Скале, по-моему, уже скоро тройное будет — как раз благодаря этим "существенным изменениям".

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

В спецификациях — алгебраические типы. Кортеж просто синтаксис для конструкторов (в т.ч. и типов). Не более и не менее.

ВВ>>Не приписываю я тебе никакие мысли. То, что ФП не становится менее чистым — это *важно*.
AVK>Для чего важно?

Для того, чтобы наконец понять — утверждение, что ФП является более самодостаточной парадигмой, чем ООП — не голословно. Здесь как раз и приводятся причины, почему это так.

ВВ>>С ФП ситуация другая. Добавление алгебраических типов не делает функциональный код менее функциональным. И сдается мне, что здесь есть большая разница.
AVK>Какая разница в практическом плане?

У ФП есть будущее и почва для развития. У ООП — нет.
А больше никакой разницы.

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

ВВ>>Чистое ООП должно включать только то, что не вступает в противоречие с ООП.
AVK>Вот только, поскольку что такое чистое ООП по большому счету никто не знает, то и вопрос твой больше теоретический.

Ну ты вот любишь Синклера по этому поводу цитировать; я вот тут тоже по соседству пытаюсь у него выудить, что же такое "поведение". И что-то все идет к тому, что вот это самое "ООП — это про поведение" настолько это самое ООП сужает, что оно вообще в какую-то экзотическую концепцию превращается.
Вообще с "чистым ООП" должно быть все достаточно просто. Мы ведь можем определить, что такое ООП, я полагаю? Чистым, очевидно, будет такое ООП, в котором нет каких-либо "посторонних" концепций, с помощью которых задачи решаются не в ОО-стиле.

Вот только реальные языки обычно не такие.

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

А какая тебе тема интересна? Вроде как второй день говорим про ФП и ООП — теперь оказывается, что неинтересно

А чего говорил тогда?

ВВ>>А SOA может и уживается с ОО языками, но оно вообще-то не очень в духе ООП.
ВВ>> Я бы даже сказал, что оно принципиально не в духе ООП, там ООП нет ни грамма.
AVK>Опять неаргументированный субъективизм. Если ты такой сторонник чистоты ООП, то должен понимать, что кеевскому определению SOA не противоречит. Идентити у сервисов есть — эндпоинт, обмениваться сообщениями они могут, детали реализации изолированы контрактом. А то что полиморфизма на базе иерархий наследования нет (полиморфизм реализаций контрактов есть) — так это вовсе необязательный признак ООП.

Все, что ты тут перечислил, есть и в том же ФП. Но ФП от этого ООП не становится. У ООП есть еще одна такая маленькая деталь, которую вы постоянно упоминаете — поведение.

AVK>Не ты ли недавно доказывал, что наследование контрактов не нужно?

Я не доказывал, я спрашивал. Кстати, вопрос был не про ООП.

AVK>Ну и главное — в практическом разрезе все это бесполежный буллшит. Главное — SOA удобно реализуется ОО-языками, и интерфейс ОО-языка 1 в 1 без смены модели меппится на контракт. А вот чисто функциональными — интересный вопрос, я бы с удовольствием послушал, какая сущность ФП будет описывать SOA контракт, чтобы его компилятор понимал и контролировал, а не только RPC фреймворк.

Ага, знаю. Это трюк из области — формулируем задачу в терминах ООП, потом просим один-в-один перевести это в ФП. Влад одно время так развлекался — типа покажите мне абстракцию для последовательности в ФП типа IEnumerable.
И ты, Брут?

ВВ>>А вот сервис в SOA имеет четкие границы, т.е. четкое различение между локальным и нелокальным вызовом, что в распределенке важно.
AVK>Круто. А еще есть четкая граница между персистентными данными в БД и неперсистентными в памяти. Тоже будем новую парадигму придумывать?

Зачем? Она уже выдумана. Анемичная модель называется. И не ООП, и не... В общем неведома зверушка.
Кстати, хороший пример. Я сам хотел его привести. Тоже тот случай, когда ООП-ная косвенность как бы не сильно популярностью пользуется, и Фаулера с его репозитариями народ что-то не шибко не любит в общей-то массе своей.

AVK>>>Еще лет 30 ждать? Я периодически поглядываю, что в гуевом мире происходит — но там больше со всякими реактивностями экспериментируют, мутабельными по самые жабры, а не с чистым ФП. Так где та молодая шпана?
ВВ>>Я думаю, меньше.
AVK>Это круто, что ты так думаешь, но можно все таки примерчик? Я этот вопрос уже лет несколько задаю, пока безответно.

Примерчик чего?
Я вижу, что, скажем, за последние 10 лет в ФП неплохо прогрессирует. Так что 30 лет ждать, может, и не придется.

ВВ>> Но всему требуется время.
AVK>Сколько? И ФП и гуевым фреймворкам уже много десятков лет, не новые, мягко говоря, вещи? Что танцору мешает?

ФП настоящему не так много лет как тебе кажется. И танцор пока танцевать учится. Но у него есть преимущество перед остальными — обе ноги на месте.

ВВ>>ФП построено на основе очень выразительной системы исчисления, но ФП довольно сложен в плане реализации
AVK>Ну то есть ФП уровня C# не достаточен? Почему и в каком месте?

Что такое ФП на уровне C#? Какой еще ФП в C#?

AVK>Если за 30 лет UI не стал, не, не приоритетом, просто важной задачей ... Что то в датском королевстве ... Потому что ООП массово влез в мейнстрим как раз на волне GUI (текстово-псевдографического UI, если желаешь), и до сих пор это остается одной из важнейших задач промышленно применимых универсальных языков. И это, кстати, не только GUI касается, а вообще всех компонентных фреймворков. А в ФП с их идеологической правильностью вопрос компонентности, похоже, тоже пока неважен.

А что не так с компонентностью?

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

Мне казалось, что с целью разобраться в том, что же такое *в действительности* ФП. Если такой цели нет, то ничего противопоставлять действительно не нужно.

ВВ>>Вообще ФП — сравнительно молодая парадигма.
AVK>Существенно старше ООП, что характерно.

Симула появилась в конце 60х, Лисп — в конце 50х.
Вот только симула фактически заложила весь фундамент современного ООП, которое не шибко-то и поменялось с тех пор. А Лиспе от ФП — две чайных ложки и вообще это язык не функциональный.
Что-то более или менее похожее — это уже скорее Хоуп. И в большей степени Миранда.

AVK>>>Что неудобно? Статические методы никаких проблем дизайна не решают.
ВВ>>Ну так и "костыли" ФП, что характерно, тоже никаких проблем дизайна не решают.
AVK>Ой ли. Не было бы кортежей — что бы ты стал делать при необходимости возврата набора хорошо различимых значений? В ООП понятно — класс, а в ФП без кортежей? Список с maybe-типом?

Написал бы пару АлгТД типа Pair и Triple.

Оно и сейчас примерно так и сделано.

А можно просто вернуть вот такое:

\f -> f a b

a и b это как раз те значения, которые ты хотел передать через кортеж.
А можно сразу описать все это через CPS.
А можно еще лучше — сразу описать это через монаду.

Оставаясь при этом в рамках чистого ФП и не имея ничего кроме лямбд под рукой. Вариантов много.

ВВ>>Да нет тут никаких аналогичных процессов. ФЯ развиваются в рамках своей парадигмы. ООЯ в своем развитии впитывают "огрызки" из других парадигм и становятся "гибридными".
AVK>НУ И ЧТО?

ВВ>Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП.
Ага, а армяне лучше чем грузины. Если повторить это 1000 раз, может что то и получится.

Могу лишь повторить — ФП более самодостаточная концепция. Но тебе, похоже, это уже неинтересно.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>"Практический план" у тебя только что подключился.

Он у меня с самого начала был. Началось все с этого сообщения — Re[34]: Как мало людей понимает ООП.... Не заметить то, что речь в нем идет вовсе не о теоретике, довольно сложно, не находишь?

ВВ> До этого вроде бы как о парадигмах говорили.

И что? Парадигмы на практике не нужны?

ВВ>В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает.

Всемирный заговор разработчиков языков?

ВВ> ФП нормальное можно построить либо вообще без системы типов

Значит в жопу такое нормальное ФП, делов то.

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>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Он у меня с самого начала был. Началось все с этого сообщения — Re[34]: Как мало людей понимает ООП.... Не заметить то, что речь в нем идет вовсе не о теоретике, довольно сложно, не находишь?

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

ВВ>>В практическом плане это плохо тем, что самое основное из ФП как раз в эти гибриды-то и не попадает.
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>По барабану.

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

Здравствуйте, 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.

Здравствуйте, Sinclair, Вы писали:

I>>Массы и линейных размеров нет, зато поведение и свойства есть. Эта математическая абстракция есть заимствование из физического мира, представь, передача информанции на уровне сообщений, каналов и даже пакетов появилась еще в те времена, когда пароход феодосия еще шлюпкой был.
S>Брр. Давайте не будем углубляться в дебри. Математика и физика разделились относительно недавно; тем не менее, под термином "физический объект" подразумевают не просто "что-то со свойствами", а что-то с определёнными свойствами.

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

I>>Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает.
S>В том-то и дело, что учебники вводят иллюзию, что надо копировать объекты Реального Мира. Лужа и Камень являются очевидными вариантами.

Учебники не заставляют тебя вводить эти классы. Парадигма не говорит ни какая должна быть модель, ни правильная ли она. Парадигма говорит как модель перевести в код, всё ! Моделируешь ты сам точно так же как это делали до изобретения программирования.

I>>Физический объект имеется ввиду заимствование из реального мира, а не корова с выменем, рогами и хвостом.
S>Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.

19й век

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

Здравствуйте, samius, Вы писали:

S>>>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.

V>>Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?
S>В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.

А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо.
Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу.

Здравствуйте, Ikemefula, Вы писали:
S>>Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.

I>19й век
I>

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

Здравствуйте, Sinclair, Вы писали:

I>>Линейка.ВзятьСумму(5,3)

Причем это ровно тож самое, что и в анемиках TransferSevice.Transfer(acc1,acc2, amount)
S>Попробуйте этот трюк с реальной линейкой. Посмотрим, возьмёт ли она сумму.
S>Или всё-таки придётся самостоятельно выполнять действия с ней — руками, глазами, и мозгом.

Мы можем как угодно моделировать эту самостоятельность, ООП ничем не мешает.

I>>Внезапно, если вспомнить контекст, что вычислитель был нужен в примере про математические операции

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

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

S>А если у нас задача стоит чуть по-другому — например, начисление людям зарплаты, то внезапно окажется, что ни зарплата, ни люди объектами не являются. Хотя на основе учебников так и кажется, что класс Manager будет отнаследован от класса Employee.

Так это примеры в учебниках синтетически а не ООП плохое

>>>Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".

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

Так я про это и говорю уже второй или третий день

Здравствуйте, Sinclair, Вы писали:

S>Омг, омг. У нас была предметная область (вы называете её реальным миром), состоящая из коровы и травы.
S>Внезапно (ВНЕЗАПНО!) в этот реальный мир внедряется некое устройство, как идея вычислителя.

Эта идея была изначально. На этой идее построен сам процесс самоорганизации простой материи в сложные конструкции, в жизнь. Генерирование белков по шаблонным участкам ДНК — вполне себе АЛГОРИТМ. Безусловные реакции коровы на сигналы от желудка, трансформируемые в сложное поведение поиска и поедания травы — тоже АЛГОРИТМ, только чуть сложнее. Кароч, без вычислителя не было бы алгоритмов и не было бы способа сложной материи — жизни, которая являет нам своё многообразие как результат многообразия аналогичных описанным алгоритмов.

S>У пастуха, который пас корову, ни разу в жизни не возникло идеи про этот вычислитель.

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Ты описал модель, правильно ? ты не в состоянии повторить её или же она неадекватна ?

В модели графы объектов многих типов. Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов.

OK, поиграю на новом десктопе и на старом, бо разница на порядок — многовата.

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

Т.е. ты уже замерил эффективность интрузивной очереди vs стандартной очереди?
Не верю! (С)

>>Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.

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

Ты скипнул аргумент о лишнем ветвлении в алгоритмах. Похоже, ты не понимаешь, за какой порядок цифр идет борьба. Кол-во сообщений в сек уже дал. Вычти отсюда порядка 3us на сообщение, забираемое сетью, еще порядка 1us на межпотоковую передачу сообщений. Все, что осталось — твоё. Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.

Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.

Здравствуйте, Ikemefula, Вы писали:

K>>Ну да. И
K>>

Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.

K>>тоже, наверное, я сам написал, залогинившись под вашим именем, ага?

I>Покажи где в процитированом ты увидел "неадекватность"

Я тут не первый день пишу и знаю, что утверждение "имярек относится к иксу как к серебряной пуле" здесь используется для того, чтоб сказать, что у собеседника закатились шарики за ролики, но без нарушений правил форума. Других применений у него нет. Рассуждения при этом следующие:
1) Серебряной пули нет. Не важно, о чем написано в статье Брукса, в ее критике, в ответе на критику. Выражение прошло через "меметическую мутацию" и сейчас обозначает "панацея, которой нет".
2) Человек, который считает, что нечто несуществующее существует — неадекватен. Поэтому его аргументы можно игнорировать.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Да нет, я стою на месте.

V>Стоял бы на месте если бы не увиливал от аргументов:
V>

V>>>Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться.

Я уже на этот бред отвечал что с дверьми не разговариваю.

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

S>>Я не говорю о фиксации. Я говорю что дверь.Откройся() далека от рж безотносительно ТЗ.

V>Дык, разрешение абстрагироваться от подробностей тебе затем и дано, чтобы ты не вычислял лишнего в программе. Тики-то процессора не бесплатные и не бесконечные. Особенно во времена становления ООП. )))
Разговор о том и идет, что чтобы от рж перейти к модели, надо все подробности выкинуть, прикрутить что-то свое, а потом соврать что получилось один в один.

S>>Такая модель может соответствовать ТЗ, я ведь об этом ничего не говорю. Но далека от реальной двери.

V>Пофиг, в инженерии кач-во решения определяется степенью его соответствия функциональным и нефункциональным требованиям. Это всё!
Извини, но ты влез в спор на стороне, которая утверждала что ООП модель в точности соответствует реальной жизни. Причем утверждала это без всякого ТЗ. (*)

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

V>bool doorState;
V>

V>Вот почему я надоедаю со своим ТЗ, что мы-то обсуждаем решение, а условия никто еще не слышал. Дурдом? Натуральный. Отсюда и столь различные решения у всех участников, как в конкурсе "принеси то, не знаю что".
см. (*)

S>>Он может быть не такой и сложный, но ООП все поставит с ног на голову.

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

V>>>Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу!
S>>Видишь, ты сам понимаешь что модель далека от моделируемого.

V>Модель задачи и модель решения — это независимые модели, увы, до тех пор, пока такая зависимость не оговорена в ТЗ.
Но ты влез на ту сторону, короче см. (*)

V>>>Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе.
S>>Вот тут ты свою физику и слил. Дальше скипаю.

V>Ты как всегда скипнул неудобные аргументы. В данном случае вот эти:
V>

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

А, т.е. ты предлагаешь уже моделировать сингалы органов чувств, мозг, опыт и понимание? Извини что пропустил, очень интересно.

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

S>>ну, вспоминай физику, которую ты слил. Что-то я не помню что бы ты говорил о сообщениях в ней.

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

V>>>А как же ты её видишь и/или осязаешь? По закону сохранения энергии, сигналы в твоих рецепторах органов чувств не могут взяться из ниоткуда. Это, уважаемый коллега, пришло внешнее для тебя воздействие. Будь оно оптическое или ньютоновское.
S>>Все пропало!

V>Тебе еще не 90, еще есть шанс, не переживай.
Глядя на тебя, уже начинаю переживать.

S>>Двери воздействуют на людей ньютоновскими силами!

V>Домашнее задание: какой закон Ньютона имелся ввиду при физическом фзаимодействии руки с дверью?
да фиг знает, что ты имел в виду. При фосдействии на дверь рукой — второй описывает фосдействие на дверь, третий говорит что фосдействие на руку равно по модулю.

S>>Я пользуюсь рецепторами вне зависимости от наличия рядом двери. И это, отраженный свет послан мне внезапно не дверью вовсе.

V>Оп-па! Отраженный от двери свет послан не дверью. Я бы на месте твоего школьного учителя физики съел свою шляпу.

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

V>Ну а на месте ВУЗовского съел бы там, где ты плаваешь в вопросах информации.
Как шляпе повезло, мне не читали в ВУЗ-е теорию информации. Вообще. Зато целый год упрощенного паскаля

S>>И кстати, если я вижу дверь, то я ее вижу вне зависимости от того спрашивал я дверь о том, вижу ли ее или нет.

V>Как это вне зависимости, если ты свои органы чувств должен настроить таким образом, чтобы достоверно различить положение двери. То бишь, получить информацию о ней? Как минимум ты должен открыть глаза, посомтреть в ее сторону и сфокусировать кристаллики глаза. Ничего себе "не спрашивал"... Или ты буквально выразился в том плане, что решил с дверью поговорить? )))
Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

S>>Т.е. концепции единого сообщения нет. Пусть будет мульон сообщений. Но ведь в твоей модели лишь одно...

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

S>>Еще раз. Я писал о ЧИСТОМ языке. CL не чист.

V>Вообще-то ты писал о Лиспе.
Я писал о чистом языке.

S>>Ты хочешь что бы я как ты вилял? Мне это зачем?

V>Вилять можно только если влез, а потом понял, что не туда. Так что виляние уже де-факто происходит. Ты дважды оспорил, а потом так и не пояснил, ПОЧЕМУ ты спорил-то. Если не воспринимаешь оппонента всерьез, зачем столько пишешь ему в ответ?
Я уже задолбался писать, почему я спорю и за что. А про зачем столько пишешь — ну мне ведь интересно, куда ты дальше вильнешь.

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

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

Здравствуйте, DarkGray, Вы писали:

DG>Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.
Для ГУЯ сейчас актуально использовать какую-нибудь разновидность MVP.
Presenter — это как раз тот объект, который выполняет посредническую роль между Domain Model и представлением; он сам не соответствует ничему в предметной области.
Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.
Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.

Здравствуйте, vdimas, Вы писали:

V>>>Итого, в твоем примере я даже не вижу по какому критерию происходит сортировка. Полный мрак и непонятки. Вот причина "ключевых вопросов" — из-за нечитабельности кода.
I>>Не ври, видишь — по значению возвращаемому Apply.

V>Чего-чего???

Это шутка такая, все ты понял.

I>>На счет нечитаемости — так это твой С++ бекграунд даёт знать, раз уж ты одну строчку с лямбдойпрочесть ен можешь.

V>При чем тут С++, если вырезанный кусок не поймет ни я, ни компилятор? У меня нет остальных исходников, чтобы восстановить контекст происходящего.

Да ладно, на поверку ты все правильно восстановил. Так шта...

V>Это та самая процедурная декмопозиция по всем правилам процедурного искусства.

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

I>>Вот, появляется инфраструктура, ВНИМАНИЕ, для частного случая !

V>Мде... Это это локальная ф-ия. С каких пор локальные ф-ии стали инфраструктурой?

Инфраструктура это весь твой код который ты привел здесь.

V>Да лан, целая инфраструктура — это целый дотнет, где 50 метров зависимых бинарников грузятся в память, чтобы сделать простейший чих.
V>А моя "инфраструктура", как ты выразился:
V>- однократная;
V>- обощенная;
V>- поместится в 1к исходников. )))

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

V>На ней можно эмулироватьи твой случай с сортировкой и вообще любой другой, который ты только сможешь изобрести.

I>>Если вызова будет два, тебе надо будет написать два метода,

V>Нет.

Обоснования нет и не будет ?

I>>Если вызова будет три, тебе надо будет написать три метода,

V>Нет.

Обоснования нет и не будет ?

I>>Если ...

V>Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

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

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

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

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

I>>А теперь, внимание, меняются требования и критерий сортировки будет другой. Для тебя это бедствие — надо переписать N-методов и N-мест, но это еще не все, потому что ...

V>Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново.

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

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

Внимательнее читай.

I>>

I>>Order(x => operation.Apply(Mask(x)))
I>>

I>>Вот оно, бедствие — Mask это метод того же класса что и Order, а значит тебе надо еще накидать N-структур, то есть пары {SaltedModifier, SomeClass}.

V>Беда только в голове. Поскольку кол-во замыканий сосвободными переменными у нас не изменилось, то кол-во элементов программы в моем примере не изменится. Изменится тело локальной ф-ии CompareUsingModifier точно так же, как изменился твой локальный код. Вместо sm->Apply(a) будет sm->Apply(Mask(a)).

Локальные функции есть во всех языках ? Это новость

Замыкания контекстов вдруг перекочевали в процедурное программирование. А ты, не простой.

V>Ты просто опять подтверждаешь, что не знаешь как работает ФП и поэтому не понял моего примера. Еще раз, крупным по-белому: CompareUsingModifier никогда не вызывается явно, а передается как адрес ф-ии. Итого, ровно в стольки же N-местах я внесу такие же изменения в тела локальных ф-ий CompareUsingXXX, какие ты внесешь в свой код. См. свой пример насчет sm->Apply(Mask(a)).

Локальные функции я так поянял есть во всех процедурных языках ? Это новость

V>Да, именно, я руками делаю то, что за тебя делает сахарок. Я это где-то отрицал?

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

V>

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

Нет этого аналога, ты демонстрируешь ООП и ФП особенности.

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

Ты демонстрируешь ООП и ФП а не процедурное программирование. Нет в процедурном тех вещей которые ты использовал в своем коде.

I>>Чисто императивный аналог по скромным оценкам в 10...100 раз больше,

V>Гы-гы-гы... Мож хоть раз с тобой на что-то конкретное поспорить? Ты же даже функциональной декомпозицией не владеешь, пишешь и не понимаешь свой собственный код... Ты даже не понимаешь, что показал мне в скипнутых примерах сценарии использование всего двух (ДВУХ!) базовых комбинаторов.

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

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

Мы вообще не говорили про комбинаторы, не надо соскакивать на другую тему.

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

Вагона кода еще ни разу не приводили к чему то хорошему.

V>Ды, кода будет ес-но больше. Основная масса лишнего кода будет занята строками объявлениями сигнатур локальных ф-ий и лишней парой фигурных скобок после этого объявления. Тела этих ф-ий будут отличаться по размеру не особо от исходного варианта. Остальное будет решено через комбинаторы, как через базовые, так и производные. Но ни о каких 10 раз и тем более 100 речь идти не будет, ес-но.

Будет. У меня всей инфраструктуры — один метод Apply и ничего больше, всё остальное работает само.

>А если я зависимости разнес, то пахать буду не больше тебя.

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

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

Не расстраивайся, я учусь на чужих ошибках, в отличие от тебя

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

Ты вообще говоря так и не показал того, что обещал.

V>И да. Проблема на самом деле в моем решении есть и она серьезная, скажем, в координатах С++. Эта проблема — отсутствие GC, то бишь речь о времени жизни контекста.

Я тебе пять раз говорил про это и два из моих примеров это как раз и демонстрируют, разуй глаза.

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

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

>Надо было чуть подкорректировать свои примеры так, чтобы стал нужен GC и мне было бы сложнее отстреливаться. ))

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

V>В том-то и дело, что показал в точности. А ты показал непонимание относительно устройства и механики работы ФП, даже когда эту механику воспроизвели на твоих собственных примерах. Это полный П.

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

Когда ты используешь локальные фукнции — это все не процедурное, в процедурном ничего этого нет.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, elmal, Вы писали:

E>>Это считаем ОО подходом или нет?

V>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
Конечно же это бурная фантазия

Здравствуйте, vdimas, Вы писали:

V>>>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.

I>>" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов"
I>>"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @
I>>

V>И? поясни юмор?

Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).

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

И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики

Сколько это "достаточно велико", 10К, 100К, 1ККК ?

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, samius, Вы писали:

S>>Я уже на этот бред отвечал что с дверьми не разговариваю.

Ф>http://www.rsdn.ru/forum/test/4843258.1.aspx

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

> V>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
> S>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.
>
> Наоборот, я показываю правомочность того, что дверь мне "отвечает" на вопрос. То бишь показываю физический смысл этого явления. Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале.

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

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

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

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно. Говорить о замыканиях в паскале можно лишь с поздних версий. И то это будет уже не паскаль, а делфи.

I>Турбопаскаль уже считать дельфи или еще нет ?
Вообще-то нет. Да и в делфи замыкания появились лишь в 2009-м. Так что без разницы, чем ты будешь считать турбопаскаль.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет
S>>Это не замыкание, это вложенная процедура.

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Покажи недостающую разницу между замыканиями и локальными функциями.
S>>В паскале вложенные функции.
S>>Разница между замыканием и вложенной функции в том, что вложенная функция может быть вызвана лишь напрямую из внешней, т.к. ей нужен стек фрейм внешней функции. А замыкание продлевает время жизни связанного окружения до времени своего существования, которое не ограничено временем выполнения внешней функции.

I>Ты смешиваешь разные понятия — первоклассные функции и замыкания.
Нет, не смешиваю. Это разные вещи.
I>Очевидно, в языке который умеет ПФ , замыкания так же должны поддерживать все сценарии для ПФ.
Контрпример — ALGOL 68
I>Если язык не поддерживает ПФ, то нет никакой необходимости поддерживать эти сценарии в замыканиях.
Замыкание — это техника реализации определенного сценария. В паскале этот сценарий не был реализован до 2009-го года.
I>В дельфи 2009 появились именно ПФ, ага. Отсюда очевидно, что замыкания обязаны поддерживать эти сценарии.
Нет, замыкания лишь способ. Обрати внимание на то что нет языков с замыканием но без возможности возврата функции в качестве результата.
http://en.wikipedia.org/wiki/First-class_function#Language_support

I>http://c2.com/cgi/wiki?LexicalClosure

Улыбнуло что это всего лишь в "некотором смысле" (как у vdimas-а):

In PascalLanguage and AlgolLanguage, a function can be passed as an argument to another function, but cannot be stored in a variable or data structure, cannot be returned from a function, and cannot be created without being given a name. However, when a function is passed to another function and later called, it will execute in the lexical context it was defined in, so it is, in some sense, "closed over" that context.

А тут даже поржал:

In response to someone's addition of Pascal and Algol to the language list, I added a paragraph about 'closures' in languages lacking first-class functions.

То что ты называешь лексическим замыканием в паскале, всего лишь http://en.wikipedia.org/wiki/Lexically_scoped#Lexical_scoping, который распространяется на вложенные функции. Замыкание же позволяет использовать переменные ИЗВНЕ их lexical scope (http://en.wikipedia.org/wiki/Closure_%28computer_science%29)

A closure allows a function to access variables outside its immediate lexical scope.

Соответственно, раз нет возможности пользоваться переменными извне их lexical scope, то о чем говорить?

MSS>>Мыслим мы не объектами (Липперт, конечно, умнейший человек, судя по его комментам в книге Хейлсберга с соавторами, но таки уточню его мысль). Мыслим мы — _паттернами_. И каждый паттерн _зачем-то нужен_, а не _для красоты_.

I>Что значит "мыслить паттернами" ?

Считать себя самым крутым в мире Синглтоном, а на самом деле быть Абстракт Фактори любого бреда и Итератором походов в туалет

Здравствуйте, grosborn, Вы писали:

>> Раз переменные внешней функции определены для вложенной функции, значит они локальны для вложенной по этому определению.

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

G>Вложенные процедуры имеют пересекающиеся scop-ы.
О как. Я правильно понимаю, что в C++ фигурные скобочки — это уже замыкание???

void f(int parameter)
{
  int a1 = parameter;
  { 
    int a2 = a1; вот оно, наше замыкание. Так что ли?
  }

    сout << a1;
    cout << a2; 
}

G>Ну так верь ей. Значит процедуры паскаля — замыкания. По определению

У вас странное (для меня) понимание локальности. Но это, наверное, оттого, что я слишком много читаю Липперта.

G>А это ты сам придумал.
Профессионал должен уметь и размышлять, а не только цитировать авторитеты. Я с samius согласен.

G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте.
Коллега, вы меня пугаете! Можно пруфлинк в студию?

Здравствуйте, grosborn, Вы писали:

G>Бу-га-га-га

Ну, вашему определению удовлетворяет.

>> G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
>> Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте.
>> Коллега, вы меня пугаете! Можно пруфлинк в студию?
G>Ты опять потроллить решил и перевираешь слова. В лес.
Ну, то есть пруфлинка про нестековость машины C# мы не увидим? Тогда, конечно, в лес.

> G>А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas.
> Если вы — второй аккаунт vdimas'а, то вас я тоже буду игнорировать.
> А если нет, то мысль про отсутствие стека в C# я взял отсюда:
>

> J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.

> Вы точно уверены, что это не вы писали?

Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека. Это клинический троллинг в последней стадии, ради того что бы затроллить собеседника ты уже на все идешь.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>А толку, если на них можно огрести точно такие же побочные эффекты?

Об этом можно было бы поговорить, если бы можно было "огрести". Но, раз уж "огрести" (без лупхолов всяких) нельзя — то и говорить тут не о чем.

V>Какая разница на каком уровне абстракции

Если нет разницы на каком уровне абстракции — то в чем вообще может быть разница?

V>>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? ))
K>>Возражение простое, ваша посылка "все дело в ленивости" — неверная.

V>Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений.

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

V>>>чистая ф-ия -> порядок вычисления аргументов не важен, так?
K>>Нет, не так.
V>Ясно. Аргументов не будет.

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

-- определяем чистую функцию (||) двумя способами:
-- один сначала вычисляет правый аргумент
> let { _ ||> True = True; True ||> _ = True; _ ||> _ = False}
-- другой - левый
> let { True <|| _ = True; _ <|| True = True; _ <|| _ = False}
-- в "тотальном" языке разницы между ними действительно не было бы:
> [(a, b, a ||> b) | let xs = [True,False], a <- xs, b <- xs]
[(True,True,True),(True,False,True),(False,True,True),(False,False,False)]
> [(a, b, a <|| b) | let xs = [True,False], a <- xs, b <- xs]
[(True,True,True),(True,False,True),(False,True,True),(False,False,False)]
-- Но в тьюринг-полном разница есть:
> True <|| undefined
True
> True ||> undefined
*** Exception: Prelude.undefined
> undefined ||> True
True
> undefined <|| True
*** Exception: Prelude.undefined
-- именно это и имеет определяющее значение, а не чистота.
-- "левый" ИЛИ можно использовать для сворачивания бесконечных cons-списков: 
> foldr1 (<||) . repeat $ True
True
-- "правый" - нет.
> foldr1 (||>) . repeat $ True -- эта музыка будет вечной (если хватит места в куче)
-- в случае snoc-списка - все ровно наоборот.

Т.е. и в этом случае ваша посылка неверна.

K>>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще.
V>Это самообман, причем в клинической стадии.

Это реальность данная нам в ощущениях. Аналогия между декларативным ФП и императивным СП ложная — она не поможет понять ни того ни другого, а вот помешает — легко. Этот тред — очередное подтверждение.

S>>>>Что за "экземпляр" монады?
V>>>Это такой функциональный объект.
K>>Это не ответ на вопрос.
V>Это ответ. Курить что есть функциональынй объект.

И это — не ответ.

K>>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат.
V>Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.

Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов". 2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.

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

Никаких побочных эффектов вы без бекдоров не "проэмулируете". Все эффекты в чистом ФЯ прямые и явные — "побочных" без "бэкдоров" не бывает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

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

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

K>>Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?
I>Конечно. Позволяет вводить высокоуровневые оптимизации

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

I>в отличие от задач обработки данных

Не понятно, в чем отличие.

K>>Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++.
I>"В среднем" это неинтересно. Те же C# и Java порвут хаскель просто в хлам.

Насчет "в хлам" — это сомнительно, но думаю, что C# на CLR порвет, а C# на Mono — наоборот, глотнет пыли на обочине. Идея ясна? Разумеется, HotSpot и CLR входят в число десятка имплементаций, в которые труда вложено больше, чем во все остальные вместе взятые.

I>Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.

Пригодность реализации. До сравнения языков дело вообще не доходит.

K>>Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода?
I>Пока пишут, и доля С++ в этих областях сокращается.

Как же так? Ведь в вашей теории:
1) Один язык не может занимать несколько областей. Одна область — один идеально подходящий для нее язык.
2) Доля в области не может сократится. Язык — это ответ на появление новой области и пока существует область ее будет занимать один и тот же язык.
Вы эти следствия своей теории понимаете? В реальности их наблюдаете?

I>Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.

Я знал! Я знал!

Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?

I>С++ распространился в ответ на растущую сложность программ + сохранил все ниши что были за С.

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

I>Чисто экономические причины. Думаю вместо лиспа мог бы быть какой угодно язык, в т.ч. С++. Яха купил фактически пользовательскую базу, то есть бизнес, а сам язык никого не интересует, абы работало.

Если бы язык не интересовал — все бы оставили как есть. Но ведь переписали — потому, что язык интересовал. Только Грема один, а Яху — другой.

I>То есть, даже единичное использование означает что "задачи решали на С" ?

Куда больше, чем просто единичное. Куда деваться-то если "других языков у меня для вас нет"? Единичное использование для практически всех ниш — такое почти для каждого языка можно найти.

K>>Во-первых, я говорил про ФЯ, а не гибриды.
I>Тут можно и заканчивать, ибо нет ни одного языка не-гибрида

Ладно, под "гибридом" я имею в виду то, что обычно тут имеют в виду — императивный язык с несколькими функциональными финтифлюшками. Когда я говорил ФЯ в этой ветке я подразумевал полноценную поддержку ФП.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Ведь эту энергию поглотит "кто-то конкретный".
S>>Она не то что никуда не девается, она ниоткуда не берется.

V>Двойка по физике.
Эта твоя двойка для меня мало значит.

S>>Испускатель фотона не знает кто его получит.

V>Это аргумент за или против чего? я ХЗ чтоты имел ввиду, но его получит любой, вставший на пути следования фотона. И кто тебе мешает встать аналогично на "пути следования" любого события в WinForms?
Встать аналогично без идентичности не получится в случае событий WinForms.

S>>Предлагаешь поразговаривать с дверью-лампочкой по фотографии в интернете?

V>Предлагаю перестать юлить. ТЫ уже очень далеко убегаешь, но так и не сказал — зачем? Ты игноришь все прямые вопросы и откровенно юлишь. Поэтому отвечать тебе лишний раз неохота — ты мастер по замыливанию обсуждаемого.
Я не убегаю. Просто я не считаю что светящаяся дверь как-то меняет ситуацию. Даже светящаяся дверь ничего не знает о колбочках в твоем глазу. Ей на тебя все равно до лампочки.

S>>Покажи как вопрос от тебя доходит до двери

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

S>>Вот я тебе и талдычу о том что аналога в мире нет.

V>Я опроверг все твои аргументы (все два) многократно. Ты мои — ни разу. Талдыч своей жене.
Нет, не опроверг, ты даже с ними соглашаешься. Только делаешь это так, будто хочешь меня поучить моими же аргументами.

S>>Вместо того что бы натягивать реальный мир на ООП, программисты поступают ровно наоборот, только это не всем очевидно.

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

V>... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

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

S>>Типа вот если бы дверь была бы как бы компьютером, и мы могли бы ей посылать сообщение, вот было бы круто.

V>Я же говорю, у тебя пробелы в теории информации. Для тебя сообщение — это непременно набор байт. И если ты этого набора байт в жизни не видишь, то оп-па! Твоя программа не является моделью рж!!! Я такого откровеннго детсада уже 100 лет не видел. )
У меня действительно пробелы в теории информации и не надо мне об этом повторять в духе "ну я же говорил". Лучше поведай, что говорит теория информации об идентичности получателя фотона.

S>>Все, дальше выдумывать ничего не надо.

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

V>Читать Кея надо было не позже 3-го курса. А теперь всё, опоздал. Он тебе уже не поможет.
Я полагаю что это тебе поможет понять философию ООП.

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

V>Угу... Смотрю, ты готов юлить бесконечно... Дело твоё...
Действительно мое.

S>>>>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

S>>А у тебя-то!

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

S>>>>Необоснован твой абзац с подпиской на фотоны.

V>Обоснуй!
V>Ы?
идентичность

S>>А не ты мне хотел показать, как близко ООП к рж,

V>Я и показал.
Обломался

S>>но потом написал что на самом деле аналога нет?

V>Не надо меня перефразировать. Я говорил сугубо о ролях в модели. Но сама модель — из жизни, увы. Ты опять попался!

V>Просто ты не видишь, где проходят границы абстракций и что такое вообще модель.

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

V>... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

V>Плюс еще сама дверь! Не понял?

V>Смотри раза внимательней: для целей моделирования происходящего, упомянутого "фиктивного объекта, который будет делать это ВМЕСТО двери" — будет более чем достаточно, это ж модель!. то бишь, сама дверь нам не нужна, ууупс! А что остается? Чем будет являться этот "фиктивный объект"? А может он и будет моделью двери, коль именно через него мы получаем о двери необходимую информацию и взаимодействуем с дверью через него?

V>Хочешь того или нет, но всё это время ты спорил о том, что модель не есть реальная жизнь. Детсад, сорри за повторение. Модель и не должна быть рж, на то она и модель. Но она, тем не менее, модель реально происходящего.
Детсад здесь в том, что ты решил подменить предмет спора. Я спорил не с этим.

S>>Давай так, твоя модель — ты и обосновывай ее близость к рж.

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

S>>А единичный фотон — различает, ага

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

V>Я уже сказал, куда тебе смотреть — на медиатор. Фотоны тоже не во всякой среде распространяются. И они таки имеют вполне конкретное направление, которое можно назвать адресом. Твой медиатор — это единственный адрес, о котором знает источник события.
Я готов согласиться что вектор имеет идентичность, но с идентичностью получателя сообщения от вектора тут у тебя явные проблемы. Медиатор не приплетай, т.к. медиатор знает идентичности тех, с кем работает.

V>>>Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы.
S>>Что за на пути адреса?

V>Именно, это проекция на первые две составляющих полярных координат в 3-хмерном пространстве.
Так что там с идентичностью рецепторов?

S>>Расскажи мне о том как у рецептора есть свой адрес и как рецептор подписывается на сообщение от вектора.

V>Я уже рассказывал — как. Если конспектом — без фокусировки никак.
Верно, только и с фокусировкой тоже никак.

S>>В ООП нет произвольного адреса, есть только конкретные.

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

V>>>Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики?
S>>На твое усмотрение

V>ОК, Геометрическая оптика
Причем тут идентичность, казалось бы?

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

S>>Походу ты пропустил начало темы. Речь шла о другом.

V>Ну побегай, побегай.
А ты потопчись

S>>Ты так и не привел ни одного нечистого куска без использования бэкдоров.

V>Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить?
Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?

S>>А я тебе 10-ый пост объясняю что я не оспариваю твоего права раздавать роли как угодно. Я оспариваю то утверждение, что как угодно разданные роли естественным образом соответствуют рж.

V>Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.

Опять подмена тезиса

S>>Ну ты же высосал из пальца то что возражений нет. Есть возражения. Энергичные вычисления тоже могут быть чистыми.

V>Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.
Я не пытался это опровергнуть. Хорош спорить с голосами.

S>>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.

V>Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения?

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

S>>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

V>Ну побегай, побегай...
V>А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. ))
Ты пиши, пиши, только смотри чем и что аргументируешь.

S>>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.

V>Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому.

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

S>>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.

V>if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.
Нет, не десятое. Чистый statement в СП никому не нужен, ибо единственный эффект от него — счета за электричество.

V>>>Ну а остальное уже подытоживал:
V>>>

V>>>чистая ф-ия -> порядок вычисления аргументов не важен, так?

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

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

S>>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.

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

S>>А то что ты используешь некоторые смыслы и тебя не могут понять, то это сугубо твои тараканы.

V>Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо.
Я не отрицал упорядоченность.

S>>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.

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

S>>>>Что за "экземпляр" монады?
V>>>Это такой функциональный объект.
S>>Что за функциональный объект?

V>Это пара { ф-ия, контекст }.
Выглядит как замыкание

S>>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.
V>>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?
S>>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.

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

S>>Если ты поставил себе цель воплотить все необходимые побочные эффекты в конечной программе, то на что ты жалуешься?

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

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

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

V>>>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя.
S>>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления.

V>Да тут и школьнику было понятно, на что ты расчитывал. У тебя в каждом втором посте основной аргумент: "О нет! Неужели?!!" и далее в лицах расписывается трагизм происходящего. Имею полное морального право посшибать лулзов с такого абсолютно неадекватного на техническом форуме подхода к обсуждению.
Имеешь. Сшибай. Только не приписывай мне прозрения в твоих наблюдениях.

S>>Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать. Я лишь хотел сказать что возможность эмуляции не доказывает родство более близкое чем вычислительная эквивалентность ЛС и МТ.

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

V>Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...
Это не цинизм, это банальности. Извини, но мысли вроде "все равно ошибки будут" и "все программы грязны" немногого стоят.

Здравствуйте, vdimas, Вы писали:

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

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

V>о ленивости, которая... оп-па, заведомо не должна влиять на семантику.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>В том числе поэтому давай ты не будешь вписывать в законы идентичность получателя фотона

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

V>>>У меня испускает. Лампочка на звонке прямо на двери.
S>>Ты добрался в тонкостях до фотонов и тут же перестаешь отличать дверь от лампочки. Толсто.

V>В итернете ты можешь найти фото дверей, которые одна сплошная лампочка. Что было действительно толсто — так это сравнивать фотон с мячом. Спишем на кривые представления о происходящем...
Предлагаешь поразговаривать с дверью-лампочкой по фотографии в интернете?

V>>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
S>>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.

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

V>Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале.
Вот я тебе и талдычу о том что аналога в мире нет. Вместо того что бы натягивать реальный мир на ООП, программисты поступают ровно наоборот, только это не всем очевидно. Типа вот если бы дверь была бы как бы компьютером, и мы могли бы ей посылать сообщение, вот было бы круто. Все, дальше выдумывать ничего не надо. Читай Кея.
Только я вижу, что тебя таращит от твоей теории настолько, что ты не пытаешься понять, что тебе пишут в ответ.

S>>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

V>Подтроллировать надо уметь. А у тебя в каждом втором посте — серьезные ошибки.
А у тебя-то!

V>>>Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов".

S>>Необоснован твой абзац с подпиской на фотоны.

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

S>>По поводу концепции "непрерывного генерирования сигналов", то если ты говоришь о фотонах, а не о волне, то ничего непрерывного в той концепции нет.

V>Любая дискретность происходящего сглаживается физикой/химией колбочек глаза. Уже 100ГЦ человеческий глаз не различает.
А единичный фотон — различает, ага

S>>Что нет? Не натягивается?

V>В таком категоричном виде — нет ес-но. "События" в ООП в виде мультикаста — оно так прижилось фактически сразу. Объект шлет события и не знает кому.
знает кому. Делегату. А тот списку подписчиков. Никаких неизвестностей в ООП нет. См. observer.

S>>Мультикаст делегат является собственно объектом с конкретной идентичностью, и посылает он сообщения объектам с конкретной идентичностью.

V>Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы.
Что за на пути адреса? Расскажи мне о том как у рецептора есть свой адрес и как рецептор подписывается на сообщение от вектора.

S>>Разве что не только объектам. И ничего широковещательного аки в эфире в мултикаст делегате нет. Медиатор тоже не в тему, т.к. имеет конкретный адрес.

V>Я тебе уже сказал не раз, что есть дарес для фотонов. Хотя, ты и сам должен был знать. Чтобы доставлять фотоны по произвольному адресу, нужны волноводы соотв. радиодиапазона.
В ООП нет произвольного адреса, есть только конкретные.

S>>Расскажи теперь как твой глаз подписывается на сообщения от всевозможных векторов, входящих в него.

V>Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики?
На твое усмотрение

S>>Я знаю что развязаны, я выступаю против того что ООП естественным образом отражает мир.

V>Т.е. всё это время был лишь протест против словосочетания "естественным образом"?

Да. Жаль что до тебя это доходило так долго. Но боюсь, что еще не совсем дошло.

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

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

V>Мало ли что "считается". Ты уже достаточно его знаешь, чтобы понимать как на самом деле. На Хаскеле МОЖНО писать чистые участки кода... это да....
Ты так и не привел ни одного нечистого куска без использования бэкдоров.

S>>Разве же запрещаю? Я просто не делаю из них очень резкие выводы, как у тебя.

V>Я кроме "удобства" ещё ни одного вывода не сделал. Остальное — считай разминка для образного мышления и ничего более. Просто я ХЗ почему 10-й пост подряд должен объяснять тебе, что имею право раздавать роли объектам так, как мне, разработчику, удобно. Внося динамику в процесс, увы, удобнее всего наделить дверь "поведением", умением "отвечать" и т.д. Или нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

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

S>>А теперь о связи между боксированным представлением и вытеканием хаскеля из СП. Просим.

V>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) Я так и думал.
Ну ты же высосал из пальца то что возражений нет. Есть возражения. Энергичные вычисления тоже могут быть чистыми. Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.

V>А требование босксированого представления само по себе накладывает ограничения. То бишь для программы, генерирующей пользу во времени, ты должен понимать, что обработать такую "последовательность" с конца — неэффективно (в отличие от "последовательностей" на сравниваемом там же С/С++)... Хотя, казалось бы, одна строчка разницы в рекурсивном алгоритме... А всего-то добавилось понимание происходящего и ты уже более адекватен с т.з. инструмента.
В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

V>>>Насчет Хаскеля и СП — я ХЗ почему ты там так и не смог ответить аргументированно (и никто не смог), а здесь вспомнил опять.

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

V>Дословно было сказанно так: "в некотором смысле побочный эфект". Никто на молекулы ничего не разнес. Пару коллег решили что это их зведный час и поделились пониманием побочного эффекта на уровне вики. )) Но это как раз фигня и детсад. А вот то, что ты и еще кто-то (уже не помню) с разбега пытались опротестовать ФАКТ упорядочивания вычислений, но быстро обломались, взяв за труд немного подумать — это уже было чуть интересней.
Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен. Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.

V>Ну а остальное уже подытоживал:
V>

V>чистая ф-ия -> порядок вычисления аргументов не важен, так?

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

int add(int x, int y) { return x + y; }

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

S>>Я уже отвечал на это, что дело не только в ленивости, а еще и в отсутствии побочных эффектов. Ленивость здесь лишь снимает необходимость особой формы.

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

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

S>>А что, типы и в частности туплы это теперь прерогатива ООП?

V>Контракт на методы типа? — ес-но! Это непосредственная вотчина современного ООП. Но ты непременно оспариваешь мой тезис, что парадигмы воруют друг у друга наработки. "Баба Яга против!" во всей красе. )
Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.

S>>Что за "экземпляр" монады?

V>Это такой функциональный объект.
Что за функциональный объект?

S>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.

V>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?
Ты ответил на какой-то шум в своей голове, а не на мое утверждение.

V>>>Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира.

S>>во-первых, отличия на поверхности. Код эмуляции будет чистым.

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

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

V>О чудо, ты наконец попал!

V>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя.
Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления. Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать. Я лишь хотел сказать что возможность эмуляции не доказывает родство более близкое чем вычислительная эквивалентность ЛС и МТ.

Здравствуйте, Ikemefula, Вы писали:

...
I>>>То есть вложеные процедуры есть замыкания.

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

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

Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, icWasya, Вы писали:

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

W>>Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было

I>Почти. Вниз все работает:
I>

I>program test;
I>uses crt;
I>type
I>  MegaProc = procedure(s:string);

I>  procedure Main;


I>    procedure Suxx(p:Pointer);
I>              var proc:MegaProc;
I>    begin
I>     proc := MegaProc(p);

I>     proc('hello world');
I>    end;

I>    procedure Print(s:string);far;
I>    begin
I>     WriteLn(s);
I>    end;


I>  begin


I>    Suxx(@Print); {вызываем вложеную и передем как параметр вложуную}
I>  end;

I>  begin
I>  Main;
I>end.
I>

Ну ваша процедура Print не использует накаких переменных, которые локальны для Main и глобальны для Print.
С таким же успехом она могла быть описана и вне Main.

> G>Так же и во вложенной функции позволительно использовать переменные вышестоящего scope.
> Использовать переменные вышестоящего scope это не есть замыкание.

Это ты сам только что придумал.

> Пресловутая википедия говорит:
>

> In programming language theory, a non-local variable is a variable that is not defined in the local scope.

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

> Раз переменные внешней функции определены для вложенной функции, значит они локальны для вложенной по этому определению.

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

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

Ну так верь ей. Значит процедуры паскаля — замыкания. По определению

> Т.е. вложенная функция паскаля не является замыканием по определению с википедии (точнее по совокупности их).

А это ты сам придумал.

> Способ реализации "замыкание" в полный рост может использоваться и для вызовов вложенных функций внутри вложенной (т.е. без передачи вложенной функции наверх). Но это лишь потому, что некоторым компиляторам лень разбираться, в каком контексте будет вызываться вложенная функция. Так, например C# не разбирается и использует замыкание(т.е. технику реализации) даже там где передавать вложенную функцию вовне не надо, а можно было бы обойтись указателем на фрейм стека. Просто использовать замыкание дешевле в плане необходимости модифицировать рантайм.

Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.

> Возможно отсюда и путаница, что раз паскаль позволяет делать то, что позволяют замыкания в C# (но лишь во внутреннюю сторону, неестественную для замыканий), то типа и паскаль значит поддерживает замыкания. Но нет, не поддерживает по определению замыкания и нелокальной переменной.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, grosborn, Вы писали:

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

G>>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого.
G>>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.

I>Запусти программу из моего примера и объясни эффект.

Перепишем Ваш пример вот так:

type
  MegaProc = procedure(s:string); stdcall;

var
  GlobalParam:string;

procedure GlobalPrint(s:string); stdcall;
begin
    WriteLn(s,' GlobalParam = ',GlobalParam);
end;

procedure Main;stdcall;
var
  LocalParam:String;
  procedure Print(s:string);stdcall;
  begin
    WriteLn(s,' LocalParam = ',LocalParam);
  end;

  procedure Suxx(p:Pointer);stdcall;
  var proc:MegaProc;
  begin
    proc := MegaProc(p);

    Print('Local Ok!');       // 1 вызываем вложеную
    GlobalPrint('Global Ok'); // 2 вызываем глобальную

    proc('Pointer');          // 3 вызываем по указателю
  end;


begin
  LocalParam:=' Hello World!';
  GlobalParam:=' Hello Delphi!';

  Print('Main');       // 4 

  Suxx(@GlobalPrint); //  5 {вызываем вложеную и передем как параметр свободную}

  Suxx(@Print);       //  6 {вызываем вложеную и передем как параметр вложеную}
end;

stdcall — что бы параметры для наглядности передавались через стек.

тогда
в точке 1 генерится такой код

  mov eax,[ebp+$0c]  // копируем в регистр переданный контекст
  push eax            // кладётся в стек контекст
  push offset('Local Ok!') // кладётся в стек строка
  call Print          // собственно вызов
  pop ecx; // убираем лишний параметр из стека

в точке 2 генерится такой код

  pust ofset('Global Ok') // кладётся в стек строка
  call GlobalPrint; // собственно вызов

в точке 3 генерится такой код

  pust ofset('Pointer') // кладётся в стек строка
  mov ebx,[ebp+$08]     // кладётся в регистр адрес процедуры 
  call ebx;             // собственно вызов

в точке 4 генерится такой код

  push ebp; // кладётся в стек контекст
  pust ofset('Local Ok!') // кладётся в стек строка
  call Print; // собственно вызов
  pop ecx; // убираем лишний параметр из стека

в точке 5 генерится такой код

  push ebp                // кладётся в стек контекст
  pust ofset(GlobalPrint) // кладётся в стек адрес процедуры
  call Sucxx;             // собственно вызов
  pop ecx; // убираем лишний параметр из стека

в точке 6 генерится такой код

  push ebp                // кладётся в стек контекст
  pust ofset(Print)       // кладётся в стек адрес процедуры
  call Sucxx;             // собственно вызов
  pop ecx; // убираем лишний параметр из стека

отсюда видим — для вызова функции Print генерируется правильный код в точках 1 и 4
а в точке 3 — в стек НЕ кладётся нужный для процедуры параметр

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

и это несколько маскирует ошибку.

Функция GlobalPrint вызывается правильно отовсюду.

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

SV.>У нее есть одно большое преимущество — она интуитивно-понятна. Поэтому так строят реальные системы типа ShP OM. А других преимуществ — да, нет.
Интуитивно понятна она ровно до тех пор, пока не начинаются реальные вопросы типа тех, что я задал.

SV.>Есть и недостаток — ОМ чувствительна к дизайну. Кривые руки ее погубят. Поэтому, ШП ОМ — редкая гадость (когда я последний раз смотрел на их CAML, плакал горючими слезами — пакетные запросы адекватно представлены не были, пришлось плюнуть и переписать все на SQL).
Отож.

S>>Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него:
S>>

S>>BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();
S>>

SV.>Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден.
Как это "не виден"? Да он в плане счетов написан крупным шрифтом. То, что вы дали счёту какой-то внутренний служебный идентификатор — ваше личное решение; нужды в нём никакой нет.

SV.>Искать вы будете по внешним атрибутам счета, может быть, даже, в соответствии с правами доступа. Создаваться экземпляр будет фабрикой, внешний вид которой зависит от архитектуры. Разумеется, этот поисковый объект не будет исключительно фабрикой, и я никогда не соглашусь, что это нарушение SRP.
А придётся.
S>>А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()).

SV.>Да, хотел дописать почти теми же словами, но решил, что и так понятно. Это некий шорткат, который можно реализовать по-разному (хоть бы и дефолтным значением параметра).
Это — плохой способ. Вы прячете ту функциональность, которая должна быть на виду.
SV.>Зрение бывает у дизайнера, а не у дизайна. Как и точка, откуда дизайнер зрит. Это так, к слову.
Ну давайте не будем
SV.>С какой точки зрите вы, я не знаю. Мой поинт в том, чтобы сложность разложить по полочкам. Поставьте себя на место гуёвого программиста, которому дела нет до идентификаторов и базы. Зато у него на входе есть счет, который сводит дебит с кредитом по запросу. И полученный таким образом результат можно запихать в форму и отдать операционисту.
Я не понимаю вашу терминологию. Вы придумали какое-то решение и хотите общаться только в рамках него?
Ну, а я вижу это совершенно по-другому. Конечно же у гуёвого программиста на входе есть исключительно идентификатор. Потому, что ему приехал запрос .../ShowAccountTransactionHistory.aspx?Acc=78.01
И теперь ему из этого номера счёта нужно получить всю нужную по ТЗ информацию. Либо ему надо заниматься порождением нафиг ненужной объектной модели, либо можно скормить этот параметр в метод хелперного объекта AccountingService и получить всё, что нужно.

SV.>Это зависит от точки зрения дизайнера на responsibility. Если у вас есть дополнительные требования к работе с БД (допустим, поддержка в качестве БД чего угодно, в том числе NoSQL) — ну, введем посредника, который будет делать выборки и другие реляционные операции по чему ему скажут (а Account ему скажет — по проводкам). Если нет — ради бога, прячьте сиквел в реализацию, получите быстрособранную систему, которая жестко завяжется на структуру таблиц. И то, и другое будет понятной объектной моделью, но с разными достоинствами и недостатками в других областях.
Это будет нарушением SRP.

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>>Зачем всё это делать, совершенно непонятно.

SV.>Как же это непонятно? Допустим, мы завязались на структуру таблиц. Тогда, во-первых, а где это хранить? В каком месте? "Там, где архитектурно правильно" — это общие слова. Где конкретно? Помните про гуёвого программиста, которому нужно состояние счета, атрибуты, балансы и больше ничего? Его вы озаботите знанием этого запроса, в том или ином виде?
Как где? Внутри сервиса, который знает, как доставать проводки. Делов-то. У нас будет сервис, умеющий из проводок собирать различные отчёты, и будет сервис, умеющий доставать проводки из базы.
Если меняются правила построения отчётов — меняем ровно в одном месте ровно один сервис, и только его нужно тестировать. Если меняется структура таблиц — обратно меняем ровно один сервис и только его нужно тестировать.

SV.>Заглавное сообщение прочитайте еще раз. Всё, что нужно, прекрасно получается безо всяких объектов. Хоть на ассемблере. А вот если подумать о людях, которым с этим кодом работать...
То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.

Здравствуйте, Sinclair, Вы писали:

S>Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике?
S>Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть?
S>Используются ли виртуальные методы?

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

Здравствуйте, Ikemefula, Вы писали:

I>Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

Много коротких итераций по разветвленному графу. Профит был в снижении нагрузки на GC.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, samius, Вы писали:

V>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
S>Конечно же это бурная фантазия

Это исходная концепция.

S>>>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно, соответственно моделирование/проектирование/реализацию системы разумнее вести с учётом этой особенности мозга.

M>>Нуну. А банальное «открыть дверь» ты так и не смог описать так, чтобы оно легло на реальную жизнь.

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

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

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

S>


S>class Дверь {
S>  открыть();
S>  закрыть();
S>};

S>Дверь дверь = new Дверь();

S>дверь.открыть();
S>дверь.закрыть();

S>

Только это даже близко не относится к реальному миру. Потому что ты считаешь, что действие по открыванию двери принадлежат двери. Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

ООП всегда является очень грубой, и не всегда корректной моделью мира — как и любая другая модель. Продолжу оставлять это здесь: Execution in the Kingdom of Nouns

Здравствуйте, SV., Вы писали:

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

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

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

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

SV.>"Это" — это что? Сделать шорткат от Current'а на Date.Now?
Да.

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

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

SV.>Например, Васе поставили задачу — "построение таблицы [счет]-[текущий баланс]". Если вы опять напишете про своих теток, которые паразитируют на реальном труде, приводя сведения о реальном бизнесе в соотетствие с порождением советского Госплана (а откуда же еще высрались эти планы счетов?), которым такая таблица не нужна, не надо, пожалуйста.
Коллега, меньше эмоций. Бухгалтерию придумали вовсе не в СССР, и про тёток никто не писал. Если у Васи представления о счёте, как о баночке с деньгами — то это личные Васины проблемы. Точнее, это проблемы того, кто Васю нанял, потому что реальная бухгалтерия работает вовсе не так.
Реальная бухгалтерия — это, в первую очередь, механизм расчёта налогов. Без этого, грубо говоря, можно просто иметь одну баночку с деньгами, и просто брать из неё столько, сколько нужно.
SV.>Мир не крутится вокруг СССР. У других, знаете, тоже бывает бухгалтерия, в которой баланс счета — сумма проводок, а не состояние.
Совершенно верно. Вот только зачем вы хотите иметь именно счёт с состоянием вместо суммы проводок

?

SV.>Так вот, выше я предложил сделать шорткат на основе дефолтного параметра. Что вы изволили назвать плохим решением. Видимо, с точки зрения "Правильного Дизайна", который вы тут представляете на манер Лебедева. С точки зрения не Дизайна, а Васи, у него есть объект acc, у которого можно нажать точку и посмотреть, что будет. Вывалится список методов, среди которых не будет никакого CurrentBalance. А будет CalcBalance(Date forDate = Date.Now).
Нет, вы предлагали именно CalcCurrentBalance() — все ходы записаны. Далее, по вашим словам, мне совершенно непонятно, откуда это у Васи вдруг возьмётся объект acc, у которого можно нажать точку и посмотреть, что там выпадет.

Сопли, простите, поскипаны. Если вы хотите что-то написать — пишите по делу. А не драму про Васю, который, оказывается, с самого начала ничего не знает, зато каким-то волшебным образом всё узнаёт. И про Синклера, который сначана всё знает, а потом почему-то стремительно тупеет.

SV.>Гуёвый программист не занимается порождением объектной модели. Он отдает 78.01 в метод хелперного объекта AccountingService, и получает объект Account, который можно изучать через IDE. Оба они, AccountingService и Account, а также все реализации Account, описанные выше, являются частью объектной модели, создавать которую (и упаковывая реализацию в которую) дело архитектора.
Вопрос: зачем гуёвому программисту этот объект Account?
Что мешает ему сразу вызвать метод AccountingService.CalcBalance(...)?
Сколько разных реализаций вы себе представляете у класса Account?

SV.>Вы не читаете, что ли? Я же сказал: это зависит от точки зрения дизайнера на responsibility. Если думать о responsibility в терминах "функциональность по расчёту баланса", "функциональность по работе с базой" — тогда да, это нарушение SRP. Если считать responsibility этого класса "предоставить Васе доступ к балансам", тогда нет. Вот когда Account начнет заодно курсы валют возвращать, тогда это будет нарушение SRP.
Непонятно, где вы проводите границу responsibility. У классиков — всё понятно. Границы responsibility проходят там, где проходят разные причины для изменений. А с вашим подходом запихать вообще всё в функцию main — нормально, потому что ответственность программы это "сделать всё".
Я же вам привёл пример: сменили структуру базы или заменили хранилище — поправили код в одном месте. А у вас придётся править Account, Transaction, а то и всяких Person и прочих "активных классов", которые слишком много знают о доступе в базу.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?
S>В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

Здравствуйте, A13x, Вы писали:

A>Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.

В джава нет полной поддержки концепции замыканий и нет никакого линка. И тем не менее это самый популярный язык на планете. А ему то всего чуть более 15 лет. А вот функциональные языки существуют уже почти полвека и до сих пор используются исключительно для решения задач определённого класса. Никому не придёт в голову писать корпоративную систему в целом на лиспе/эрланге/хаскеле... Это говорит за себя куда как более весомо чем вкрапления нескольких особенностей в C#.

Здравствуйте, Steamus, Вы писали:

S>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
"Нечто"

А теперь объясни, что именно ты пытался доказать этим вопросом?

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

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

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

S>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.
Очень интересно, как из того что человек называет предметы существительными (а не глаголами или прилагательными) следует что это ложится на ООП парадигму?

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

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

Предлагаю провести мысленный эксперимент. Двум тысячам одинаковым неглупым людям, девственным в программировании, поставим одинаковый набор задач, но разные учебники программирования. Половине букварь по ООП, другой — букварь по ФП. Каковы ваши ставки? Если вы считаете что ООП-шники напишут быстрее/качественнее и т.п. просто потому что мозги практикуют именно ООП, то к чему опять-таки тема про то как мало людей понимает ООП.

Да, по поводу доказывать что их мозг не понимает абстракций... Вы это про кого? В ФП абстракции ничуть не беднее ООП-шных.

M>>И то. Что твое заявление о неприспособленности ФП для реальной жизни, мягко говоря, смешно.
S>Смешно моделировать действительность функциональным языком. Хотя, скорее грустно.

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

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>S>>>Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.

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

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

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

Здравствуйте, samius, Вы писали:

S>>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно,
S>Вот еще один пример. Вашу мысль о том что мозг мыслит объектно вы уже декларировали. Но ни одного подтверждающего обстоятельства не привели.

Для выражения ИМХО и не требуется ничего такого приводить. Приводи в ответ своё ИМХО... Правда, тут такой прикол, что как раз отрицание чужого ИМХО потребует аргументов. Не обратил внимание, что тем ИМХО и отличается от безусловной подачи информации, что нападающие и защищающиеся меняются в споре меняются местами? У тебя сейчас не было оснований для нападения, поэтому нападки выглядят криво... А в каче-ве защиты твоеё т.з. пост откровенно слаб... Потому что не был заточен заточен под защиту твоего ИМХО, очевидно.

S>Т.е. то что мозг мыслит объектно, выдвигается вами за постулат. Причем, выглядит это так, что утверждение абсолютно. Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

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

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

Здравствуйте, samius, Вы писали:

V>>Для выражения ИМХО и не требуется ничего такого приводить. Приводи в ответ своё ИМХО... Правда, тут такой прикол, что как раз отрицание чужого ИМХО потребует аргументов. Не обратил внимание, что тем ИМХО и отличается от безусловной подачи информации, что нападающие и защищающиеся меняются в споре меняются местами? У тебя сейчас не было оснований для нападения, поэтому нападки выглядят криво... А в каче-ве защиты твоеё т.з. пост откровенно слаб... Потому что не был заточен заточен под защиту твоего ИМХО, очевидно.
S>Надеюсь, это было твое ИМХО

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

S>>>Т.е. то что мозг мыслит объектно, выдвигается вами за постулат. Причем, выглядит это так, что утверждение абсолютно. Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

V>>Вообще-то да. Несмотря на хорошо понимаемую нашим братом-программистом бесконечность и непрерывность числового ряда, каждое конкретно взятое число мы представляем себе как отдельный объект. Взять те же самые значения временных переменных при вычислении факториала...
S>Мы вообще-то говорили об ООП. Это на тот случай, если ты решил контекст восстановить по одному лишь моему сообщению. В рамках того контекста, в котором я тут общаюсь, я делаю предположение о том что твое ИМХО считает что все, где встречается упоминание числа либо какой-то величины, можно смело относить к ООП...

Я понял твоё усиление и весь нагнетаемый трагизм. Надо было тебе еще н авсякий случай переспросить и поставить такой смайл:

.
Но ответ — да. Да, любое конкретное значение — это не абстракция, это выражение некоего понятия предметной области.

V>>==============
V>>Ну ты понял как надо будет строить возражение, если тебе захочется его строить.

S>Я не рассчитывал что ты влезешь с середины и не поймешь о чем речь (или сделал вид что не понял).

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

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

Здравствуйте, Sinclair, Вы писали:

I>>Я хочу увидеть робота на вычметодах,всякие там дифуры, новье-стокса и что бы это могло коннектиться к сайтами и там играть. ООП позволяет это почти что на раз. А вычметоды и дифуры ?
S>Не понимаю, зачем вы хотите Навье-Стокса для игры в Баккара.

Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.

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

Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

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

Ikemefula,

LCR>>Вот именно, ООП тут совершенно непричём! При этом задача поставлена, есть необходимость её решать, но ООП здесь совершенно никак не вклеивается — можно конечно создать классы "Лужа" и "Камень", и описать метод "взаимодействовать", но это даже на миллиметр не приблизит нас к моделированию действительности.

I>А с каких пор ООП это именно создавать классы Лужа и Камень ?

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

LCR>>Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл:
I>А с вычметодами разве не так же ? ну, по моему, вычметоды могут моделировать тоьлко ту действительность, которая, внезапно!, подходит к тому что бы быть промоделированой через вычметоды.

Да, согласен, вычметоды тоже имеют ограничения и хороши на своём месте. QR-разложение нет смысла применять для того, чтобы дёргать разные покерные АПИ; было бы странно применять метод Гаусса к решению задач скажем комбинаторики. (хотя... кто его знает

)

Здравствуйте, Sinclair, Вы писали:

S>Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор.

Тем не менее справочник счетов есть почти в любой реальной бухгалтерии. И там есть определенные данные. К примеру, во вполне реальной парусовой бухгалтерии у объекта Account есть такие свойства:

IAccountAnalyticDescriptorDetailCollection AnalyticDescriptors
Parus.Business.Bool Balance
Parus.Business.Bool InCurrency
AccountCode Code
Parus.Business.Note Note
IAccount Link
IAccountingKind AccountingKind
Parus.Net.Server.ISystemCatalog Catalog
IAccountCollection Children
IOperationJournal OperationJournal

Как видишь, довольно много состояния у объекта Account таки.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>>>Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет
S>>>>Это не замыкание, это вложенная процедура.

I>>>Это именно замыкание, а то про что ты говорил в дельфях, это анонимные функции.
S>>Ты ошибаешься

I>Покажи недостающую разницу между замыканиями и локальными функциями.
В паскале вложенные функции.
Разница между замыканием и вложенной функции в том, что вложенная функция может быть вызвана лишь напрямую из внешней, т.к. ей нужен стек фрейм внешней функции. А замыкание продлевает время жизни связанного окружения до времени своего существования, которое не ограничено временем выполнения внешней функции.
Таким образом, пока паскаль располагал локальные переменные на стеке, его вложенные функции не могли считаться замыканиями.

> А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

С какого перепугу наследование стало ближе к предметной области, чем к примеру копипастинг? Если бы интерфейсы можно было бы произвольно комбинировать и декомбинировать, это было бы ближе, но наследование и подгонка предметной области под наследование это клиника.

Posted via RSDN NNTP Server 2.1 beta

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

Posted via RSDN NNTP Server 2.1 beta

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

Здравствуйте, Abyx, Вы писали:

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

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

SV.>>>Просто потому, что мы мыслим объектами.

M>>Оставлю тут: Execution in the Kingdom of Nouns

[skip]

Кхм. В итоге ты размазываешь непонятно что десятком предложений

По ссылке — как раз яркий пример, что мы не мыслим объектами

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Steamus, Вы писали:

S>>Лишь то, что мозг всегда классифицирует окружающий мир, дабы упростить его отображение, отбросив несущественные детали. Просто для части людей это тяжело даётся. Обычно их называют лириками/художниками. Они склонны мыслить наблюдаемыми или осязаемыми образами, а не абстракциями. Им действительно сложно отбросить малозначащую шелуху, абстрагироваться от деталей и скацентироваться на главном.
0>Все это круто и я с этим не спорю.
0>Сомнения вызывает гомоморфизм описанного с ООП, особливо с тем ООП, которое мы наблюдаем в нынешнем мэйнстриме.

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

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

Здравствуйте, Steamus, Вы писали:

IT>>ЗЫ. Я могу ещё понапридумывать подобных существительных. Взять хоты бы объект или информация. Много их.

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

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

S>Впрочем, всегда можно застолбить что-то типа — "Самая верхняя абстракиця!"

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>>>А что такое "реальная модель мира"?

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

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

S>>PS: Но всегда найдется придурок, который возразит — а вдруг бухгалтер надышится парами плёнки покрывающей стол и вся бухгалтерия ляжет?! Нет-нет, ваше ООП определённо гамно...
S>Тут дело даже не в ООП, а в том что всегда найдется придурок, который скажет что ваше ХХХ определенно гамно, что бы там ни было. Но это банальность.
S>Давайте лучше поговорим об отношении ООП к некой модели, отражающей реальный мир с достаточной точностью, необходимой для решения конкретной задачи.

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

Здравствуйте, IT, Вы писали:

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

Понимаете, что бы я не сказал, вы на всё можете отписаться в духе .. не могу получить внятные ответы... и всё такое. Имеете полное право. А я имею полное право не тратить своё время на убеждения. Вы не обязаны следовать ООП. Я начинал осмысливать ООП с Турбо Паскаля 5.5. в махровых девяностых. Также многие вещи мне казались алогичны, а я стремился казатьтся умным. Был не прав. Теперь немного делюсь опытом. Но вы можете на это класть.

Здравствуйте, Steamus, Вы писали:

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

Никак не могу понять откуда все эти домыслы про меня и про ООП?

S>Я начинал осмысливать ООП с Турбо Паскаля 5.5. в махровых девяностых. Также многие вещи мне казались алогичны, а я стремился казатьтся умным. Был не прав. Теперь немного делюсь опытом. Но вы можете на это класть.

Делиться опытом — это хорошо. Уметь излагать свои мысли и убеждать людей в своей правоте — ещё лучше. Я ещё раз перечитал исходное сообщение и опять не нашёл в нем внятного изложения мыслей. Оттого и сами мысли мне и многим в этом топике непонятны. Может стоит попробовать ещё раз?

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>>Здравствуйте, samius, Вы писали:

S>>Предлагаю провести мысленный эксперимент.

Вы правы в том, что обычный среднестатистический человек (пусть даже и программист) не способен безболезненно переучиться на другую технологию, с той, которую он освоил первой. Он будет рвать и кусаться. Кричать что только из его мёртвых рук можно отнять Фортран, лучший язык всех времён и народов. Я помню как люди переходили с Dos на Windows. Они чуть ли не рыдали — как же так, мы помним все номера прерываний, мы помним с какого адреса грузятся TSR, как же... как же так, за что это глупая попугайская среда убивает нашу мечту !!! :D

Здравствуйте, Steamus, Вы писали:

S>Моя мысль проста как слеза — мозг мыслит объектно

Мысль простая... и ложная.

Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.

Здравствуйте, Mamut, Вы писали:

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

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

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

S>>


S>>class Дверь {
S>>  открыть();
S>>  закрыть();
S>>};

S>>Дверь дверь = new Дверь();

S>>дверь.открыть();
S>>дверь.закрыть();

S>>

M>Только это даже близко не относится к реальному миру. Потому что ты считаешь, что действие по открыванию двери принадлежат двери. Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, мыщъх, Вы писали:

М>>>Здравствуйте, Mamut, Вы писали:

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

S>>Мдя...

S>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу...
М>сарказм неуместен. открытие двери и окна реализуется практически идентичным кодом. писать псевдокод лень, но будет что-то типа -- объект заперт? если да, то вставить ключ и отомкнуть. повернуть ручку и сделать pull/push в зависимости от флажка.

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

М>вам не кажется, что на определенном уровне абстракции наши действия не зависят от того пытаемся ли мы открыть ящик стола или дверь автомобиля?

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

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

М>проблема в том, что общему предку трудно дать осмысленное название.

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

мыщъх, тут есть нюансы.

Скажем, открыть дверь и открыть банку пива, несколько разные вещи. В случае двери, мы говорми о предмете который делает дырку в другом предмете (это дверь). В случае открыть банку, мы говорим о предмете в котором делается дырка (банка). Если перевернуть адекватно, то в случае двреи банкой будет комната/дом. А в случае банки пива, дверью будет это вот колечко за которое мы дёргаем, дабы сделать в банке дырку. Эти вещи путать не нужно. Термин один, но семантика разная.

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

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, мыщъх, Вы писали:

М>>>вношу правку:
М>>>mamut.takeOut(beerBottle).open();

забавно всё это.
после takeOut() мы имеем систему beerBottle<->mamut
и это поинтереснее выключателя для лампочки.
Мамут здесь, например может эту самую бутылку швырнуть в оппонента.
Запишем, как бутылка.швырнись()???

а вот нифига!
интереснее выглядит вот такой подход:
мамут.Достать(бутылка)
мамут.ШвырнутьПредмет(топикстартер)

учитывая последнее получаем:
mamut.takeOut(beerBottle).open(beerBottle);

и всё равно меня смущает beerBottle в конце этой строки
mamut.takeOut(beerBottle).OpenCapacity()

М>тут drink() возвращает beerBottle и потому можно вызывать throw_out().
М>beerBottle.throw_out()

земля.Копайся()

Здравствуйте, pkl, Вы писали:

M>>А вы в кусрес, что в реальной жизни таких предков не существует?
pkl>1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.
pkl>2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП. Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

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

M>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.

M>>>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>>>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

M>>Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.
pkl>Зачем повторяться всяким бредом?

Где ты видишь бред? Бред пока у людей, которые неспособны подтвердить свой тезис, что ООП прекрасно моделирует реальность.

Здравствуйте, rusted, Вы писали:

R>Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия.

Это не ООП концентрируется, а применятели.

R>но мы ведь так и не приблизились к решеню проблемы

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

... << RSDN@Home 1.2.0 alpha 5 rev. 59 on Windows 7 6.1.7601.65536>>

Здравствуйте, BrainSlug, Вы писали:

S>>Давайте уже сразу с этим покончим — Господь Бог!
BS>это не понятие. это существительное , которое является обозначением для http://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B3 . Читаем определение http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B5

Речь и шла о существительных. Слово 'понятие' было лишь одним из них. Вместо того, что бы ходить и старательно минусовать мои посты, лучше перечитайте тред.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

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

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Вот как раз демонстрация вашей наблюдательности. Я вижу там лишь 2 плюса на текущий момент.

S>Я не очень силён в непонятной системе оценок RSDN.
Имхо, не только в ней
S>Я увидел вес 40 и решил что так. Полагаете, что это двое челов нафигачили столько любви? Или вы не видите что сообщение имеет вес 40?

S>http://www.rsdn.ru/forum/philosophy/4834049.1.aspx
Поясняю. Там одна оценка и два плюса. Отметилось всего два человека.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>>>http://www.rsdn.ru/forum/philosophy/4834049.1.aspx
S>>>Поясняю. Там одна оценка и два плюса. Отметилось всего два человека.

S>>Верю. А что значит 40? Поясните, ото я...ну вы понимаете.
S>40 это текущий рейтинг Mamut-а (20), помноженный на поставленную им оценку (2).

Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг?

Здравствуйте, BrainSlug, Вы писали:

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

Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.

Здравствуйте, Wolverrum, Вы писали:

W>Мысль простая... и ложная.

W>Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.

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

Здравствуйте, pkl, Вы писали:R>>Понимане ерез органы чувств хоть и ограниченное, но зато наиболее естественное и простое для восприятия. Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия. Вы ввели абстрактную сущность IОткрываемое, описали состояния двери, да, это ООП, но мы ведь так и не приблизились к решеню проблемы — дверь всё еще закрыта. И чтобы нам её открыть, нужно совершить действие — тот самый глагол, который во всем этом примере первичен для обычного человеческого восприятия. Для решения задачи нужно разложение этого открыть на последовательность более мелких действий. А назначение всех этих иерархий наследования — лишь натянуть на всю эту ситуацию ООП ради самого ООП.
pkl>Вот мне даже в реальной жизни пофигу на процесс, происходящий с дверью во время открытия. Я её толкнул или пнул ногой или повернул ключ — это такие ерундовые для меня действия, что я вполне назову это "вызов метода open()". Мне важно, чтобы объект поменял состояние на "открыто" и я смог войти, а как она конкретно открывается — в какую сторону, каким ключём — мне до такой большой лампочки, что просто нет такого подъёмного крана на свете, чтобы эту лампочку поднять. Для меня открытие двери — как она движется, вися на петлях, как в ней работает замок, — это всё инкапсулировано в методе "open()".
Прекрасно. Вот для вас, получается, важен не процесс открытия, а результат. То есть в вашей модели у двери есть свойство, которое может принимать два состояния "открыто" и "закрыто" (опустим пока подробности промежуточных состояний). Для вашей задачи естественным будет такой язык, в котором вы можете потребовать theDoor.state = open и всё. Зато вам может оказаться важно, что дверь была уже открыта, чтобы не делать лишних действий.
Для таких задач REST-архитектуры подходят гораздо больше, чем ООП.

Здравствуйте, Философ, Вы писали:
AC>>Тем не менее, ООП должно умереть!

Ф>какой странный вывод.
Ф>почему должно?
потому что all the beauty must die

Здравствуйте, minorlogic, Вы писали:

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

Здравствуйте, Sinclair, Вы писали:

Минус за откровенную низкопробность в фразе относительно наследования.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

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

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

V>Ничуть не далеко. Хотя ООП-дизайн состоит сплошь из абстрактных типов, но в рантайм работают вполне конкретные типы, которые орудуют вполне конкретными данными, ничуть не хуже, чем ФП орудует структурами. Там всех отличий в механике ФП vs ООП, что в первом случае мы просто трансформируем данные, а во втором случае мы эти трансформированные данные перезаписываем по одним и те же адресам, в которых хранится состояние объекта.
Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии. Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции. Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.

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

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

S>>Все равно что сказать что паровоз это телега с самоваром, забыв упомянуть что ездит по рельсам и что чай не является побочным продуктом от езды.

V>На подобные кривые аналогии у меня всегда реакция как на кислый лимон.
Лимон? Ну и что... Вот если бы ты сказал как на пенку от кипяченого молока... Лимон-то это круто.

V>Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет.
Вопросы воспроизводимости механизмов и возможности эмуляции одного на другом вторичны и не особо меня интересуют, как ты уже наверное понял. Мне любопытны наборы практик, а не выводы типа "все **П выполняются в машинных кодах => произошли от него".

Здравствуйте, Sinclair, Вы писали:

V>>И ты до сих пор не выяснил?
S>Я как раз выяснил. Был разочарован.
V>>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
S>Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике?
S>Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть?
S>Используются ли виртуальные методы?

Зачем виртуальные методы?

S>Я вот имею основания полагать, что никакого ООП там и в помине нет, несмотря на изменяемое состояние.

Полагай что хочешь.

ООП уместно там, где речь идет об изменяемом состоянии.

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

ООП не запрещает никакую математику.

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

Да ради бога. Но спекулирование такого рода не запрещают ООП для этой задачи. Собсно, она и так уже ООП, т.к. моделирование идет от иммитации объектов прикладного мира. А исопльзовались ли там ключевые слова из ООП или ООП-язык — до фени. ООП — это точка зрения и способ решения задачи. Это не обязательно виртуальные методы, но обязательно обособленное состояние. Не ты ли как-то упоминал такую важную часть ООП как identity объектов?

S>Если у вас есть другая информация — поделитесь. А надувать щёки и переводить разговор на личности не надо — я вам уже говорил, здесь это оффтоп.

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

Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

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

Здравствуйте, Mamut, Вы писали:

M>[skip]

M>Кхм. В итоге ты размазываешь непонятно что десятком предложений

По ссылке — как раз яркий пример, что мы не мыслим объектами

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

Здравствуйте, Философ, Вы писали:

Здравствуйте, Sinclair, Вы писали:

>Ф>С "Вычислителем" было бы интереснее, ведь это вполне его метод:
>Ф>вычислитель.РешитьУравнение()
S>>Ага. Смотрели на то, как Bart de Smet прикручивал linq к Z-theorem prover? Вот это — ГОСТ 13345-85.

http://community.bartdesmet.net/blogs/bart/archive/2009/04/15/exploring-the-z3-theorem-prover-with-a-bit-of-linq.aspx

Скрытый текст

Wouldn’t it be nice if we could write something like this:

static void Main() 
{ 
    Solve((a, b) => a && b); 
    Solve((a, b) => !(a && b)); 
    Solve((a, b) => a || b); 
    Solve((a, b) => !(a || b)); 
    Solve((a, b) => a ^ b); 
    Solve((a, b) => !(a ^ b)); 
    Solve(a => a && !a); 
    Solve(a => a || !a); 
}

удареный он чувак

Оно?

S>Есть всего два показателя:
S>1. Эффективность работы программиста. Т.е. сколько времени потребуется, чтобы написать, прочесть, отладить, и впоследствии исправить. В первом приближении обратно-линейно зависит от объёма кода.
S>2. Эффективность работы компилятора. Т.е. насколько эффективный целевой код удастся получить по данному исходнику.

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

Здравствуйте, dilmah, Вы писали:

D>ну так, afaiu, в этом и суть претензий -- абстракция, модульность, изменяемое состояние это все общечеловеческие ценности и элементы общей культуры.

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

D>И люди недоумевают, почему некоторые сторонники ООП присваивают их себе.

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

Парадигма программирования — это лишь способ комбинировать технические приёмы/паттерны для достижения неких уже известных (для данной комбинации) плюшек.

Здравствуйте, pkl, Вы писали:
S>>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.
pkl>Человек мыслит просто и ясно объектами,
Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП?
pkl>никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно.
Спасибо, что подтверждаете мою точку зрения.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Но пока никто с помощью ООП дверь не открыл.

Это умозрительное твое мнение или у тебя есть какие-то неоспоримые док-ва?

Объясни проблему открыть дверь с помощью ООП? ИМХО, дверь — отличный пример изменяемого состояния с зависимым от состояния поведением. Спекулировать тут можно только на степени подробности происходящего. Но, к счастью, в реальной работе любые спекуляции заканчиваются там, где фиксируется ТЗ.

LCR>Я так и не понял почему взаимодействие между одной коровой и травой (которая представлена одним или несколькими объектами?) свелось ко множеству коров и повторному взаимодействию.

Я не вижу никакого повторного взаимодействия. Конкретно в этом в этом примере цепочка событий выглядит так:
— [природа] заставляет [каждую] [корову] есть [траву];
— [корова] съедает некоторое [количество] этой [травы];

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

LCR>В моём детском саду я честно говоря подозревал, что максимум можно только во вторую степень,

Увы, распространение энергии в пространстве описывается уравнениями 3-й степени.

LCR>а суперкомпьютеры я думал они для обогрева помещения...

Они для обогрева улицы по большей части.

LCR>И да, порезать лужу на квадратики — тоже один из самых популярных видов моделирования в этих областях. Но мне так и не стало яснее, какой вклад в эту модель составляет именно ООП.

Уже отвечал на этот вопрос: http://www.rsdn.ru/forum/philosophy/4834765.1.aspx

Здравствуйте, Sinclair, Вы писали:

pkl>>Человек мыслит просто и ясно объектами,
S>Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП?

Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
1) Создания абстракций с формальным описанием внешних свойств
2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>> Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.
S>Не вижу ничего аналогичного. Уравнение Навье-Стокса и ООП не являются членами одного и того же понятийного ряда. С тем же успехом можно было предложить построить робота для карточной игры на деепричастиях.

Тебя эта разница не смутила когда ты ему оценку ставил. Робот на деепричастиях — это такая же аналогия как и моя

I>>Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

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

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

Здравствуйте, Философ, Вы писали:

Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.

И не придумаете, поскольку это простейшая функция (добавить NaN или исключение по вкусу).

void CalcQuadraticEquation(double a, double b, double c, double& x1, double& x2, double* pDiscriminant = nullptr);

Здравствуйте, AndrewVK, Вы писали:

AVK>Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.

С этим я согласен на все 100%.

AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.

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

AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше.

А вот у ФП проблем, наоборот, поменьше. Лучше всего с 2), с 1) проблемы есть, но их меньше, чем в ООП. В тотальном ФП проблемы с 1) более-менее исправляются.

AVK>Поэтому приходится либо склеивать с ООП,

Склеивание с ООП возможно при отказе от всех преимуществ по пункту 1), польза же по пункту 2) неочевидна.

Реальное преимущество ООП — простота реализации ОО-языка.

AVK>либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа. Если уж приводить пример дополнительной сущности для этой цели, то это язык модулей a-la ML.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, AndrewVK, Вы писали:

V>Легко. Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный. То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

Какой-какой побочный эффект

In computer programming, a function may be described as pure if both these statements about the function hold:
The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

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

V>Ну а теперь вики:
V>Структу?рное программи?рование ...
V>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
V> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
V> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
V> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

V>Про последовательное исполнение в Хаскеле — do-стрелки.

А при чем тут Хаскелл?

V>Про циклы будем или уже ну его? )))

Циклов в ФП тоже нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

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

Так обо что именно ломаются мозги? Можно все-таки это как-то объяснить? Линк на твой взгляд тоже взрывает мозг?

ВВ>>Слишком многословным — да. Недостачно абстрактным — нет. Тут важно понимать, что эти, как ты их называешь, подпорки не вводят какие-то новые уровни абстракции, которых до этого не было
AVK>А я этого нигде и не писал.

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

ВВ>>Они просто позволяют писать короче и выразительнее.
AVK>А ФП и ООП в целом, это тоже про короче и выразительнее.

Остается понять, у кого это получается лучше.

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

Здесь, видимо, неплохо бы объяснить, чем же хуже, и о каких бревнах речь.
Я вот замечаю обратное — при программировании на ОО языке постоянно выходишь за рамки парадигмы, как раз чтобы код был короче и понятнее. И гибче. Развитие того же шарпа хорошо это показывает. В ФЯ же такое происходит гораздо реже.

ВВ>> И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.
AVK>Подпоркой, потому что это дополнительные концепции к базовым, появившиеся из-за их (базовых концепций) недостаточной краткости и выразительности.

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

Я чего-то тут явно не понимаю.

Здравствуйте, vdimas, Вы писали:

V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.
Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

V>>>Ну а теперь вики:
V>>>Структу?рное программи?рование ...
V>>>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
V>>> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
V>>> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
V>>> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

AVK>>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.

V>Заблуждение.
Тут вообще в SP речь об операциях, точнее об statement-ах (см http://en.wikipedia.org/wiki/Structured_programming).
Согласно http://en.wikipedia.org/wiki/Imperative_programming

In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state.

В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы. Т.е. 3/3х конструкций структурного программирования не про чистый ФЯ.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике. И там абстракции находятся в более сложных отношениях, чем отношения иерархии.

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

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

Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.

S>а по более банальным причинам: производственное удобство.

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

S>Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

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

ИМХО, всё гораздо проще — ООП предлагает два вида декомпозиции: объектную и процедурную, а ФП — только функциональную, которая несильно отличается от процедурной. И что характерно, что в том же ООП объектная декомпозиция на первом месте на высоких уровнях, на уровне общей структуры/архитектуры, а процедурная декомпозиция на первом месте лишь в самых глубоких подробностях реализаций алгоритмов/методов. В этом смысле ФП выглядит как бедный родственник рядом с ООП, т.к. способен выполнять лишь ту работу, которая с т.з. ООП самая непрестижная.

Здравствуйте, vdimas, Вы писали:
S>>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты?
V>Как минимум глаза, получающие сообщения от рецепторов света.
Вы уверены, что эта мысль выражена внутри сознания именно в терминах глаз, рецепторов, и сообщений?
Я говорю не про реализацию, а про абстракцию.

Здравствуйте, vdimas, Вы писали:

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

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

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

Здравствуйте, elmal, Вы писали:

E>Здравствуйте, SV., Вы писали:

SV.>>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.
E>

E>public class NotNullUtils {
E>    public static <T> List<T> processNull(List<T> list) {
E>        if (list == null) {
E>            return new ArrayList<T>();
E>        }
E>        return list;
E>    }

E>    public static String processNull(String string) {
E>        if (string == null) {
E>            return "";
E>        }
E>        return string;
E>    }
E>...
E>

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

public static class NotNullUtils {
    public static List<T> processNull<T>(List<T> list) {
        return list ?? new ArrayList<T>();
    }

    public static String processNull(String string) {
        return string ?? "";
    }
...

Здравствуйте, AndrewVK, Вы писали:

AVK>Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.

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

AVK>Только вот твои качественно-экспертные оценки лично меня нисколечко не убеждают.

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

K>>1) — абстракции в ООП слабенькие и протекающие, но это можно исправить
AVK>Субъективно

Объективно. ООП-шные абстракции 1) теряют информацию 2) легко "вскрываются" штатными средствами. При этом первое диктует необходимость второго.

K>>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств
AVK>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

Объективно. Формальное описание нетривиального ООП — это высшая точка TAPL — самая сложная часть требующая (почти) всех знаний приобретаемых в ходе этого курса. Забавный факт: это формальное описание оказалось достаточно мозгоразрывающим даже для Пирса (самого настоящего, а не форумного эксперта по обсуждаемому вопросу) так что он совершил ошибку, которую потом пришлось исправлять.
Это формальное описание требует F^omega_sub, которая, собственно, содержит все мозгоразрывающее из ФЯ (то, что разрывает мозги сильнее уже и языками-то не считается, а считается приф-ассистантами) + нешуточная экстра. С половиной из этих ужасов программист на ФЯ вообще не сталкивается, а с большей частью из того, с чем сталкивается — сталкивается меньшую часть времени.
Самое же обидное, что при такой сложности извлекать из этого формального описания затруднительно.

AVK>Вообще какая то игра терминами. Наследование и агрегация — основные способы комбинирования в ООП — вполне себе удобные способы комбинирования, хоть и не идеальные.

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

AVK>У чистого ФП — больше. Сигнатура функции слишком примитивна,

Это можно как-то раскрыть подробнее?

AVK>приходится даже на нижнем уровне вводить всякие подпорки типа карринга,

Почему карринг — подпорка?

AVK>туплов, АлгТД и т.п.

Туплы — это и есть АлгТД.

AVK>Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

То, что сущностей в ФП больше — голословное утверждение.

AVK>Набор функций как раз и потребовался

Вопрос в том, в чем "дополнительность сущности" набора функций по отношению к набору функций. Функция и функция — одна и та же сущность.

AVK>из-за проблем с хранением всей спецификации в сигнатурах функций.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

V>>"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания.
S>В С и паскале ссылочные типы данных имеются в полный рост, без малейших признаков ООП.

Отличный пример, ЧТД. Поэтому получили из него совместимый по исходникам С++.
Насчет паскаля ты в курсе.

S>В коде x86 есть понятие указателей, но нет понятия объектов.

Даже есть условные переходы, но нет циклов. Есть вызов подпрограмм по неизвестному в compile-time адресу, но нет ФВП. Продолжить?

V>>Занавес.
S>Опять клоунада? Я говорю не про макросистему, а про команды косвенной адресации.

Дык, а чего бы мне не поклоунадничать, если косвенная адресация — это и есть на сегодня вотчина ООП. Заметь, что ФП старательно этого вопроса избегает или прячет его от программиста. Например, явная косвенная адресация ставит раком т.н. иммутабельность в Немерле, т.к. непонятно, к чему начинает относится та самая иммутабельность: к ссылочной переменной или к ссылаемому объекту... И не понятно, как далеко ее можно распространить, даже если сделать так, чтобы иммутабельность относилась к ссылаемому объекту. Кстате, это перекликается с обсуждаением const, бо константность можно распространить и на мемберы (хотя тоже с оговорками).

Здравствуйте, Sinclair, Вы писали:

S>Коллега, плотность бреда на квадратный пост превысила ПДК. Ваши заблуждения настолько всеобъемлющи (я пока не нашёл области, где хотя бы 20% ваших утверждений соответствовали действительному положению вещей), что впредь я буду игнорировать все ваши посты на любые темы.

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

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

Здравствуйте, vdimas, Вы писали:

V>Но не достаточно сильно. ))

V>

V>...
V>      return list ?? Static<ArrayList<T>>.Instance;
V>...
V>

Скажи пожалуйста а какой профит даёт эта конструкция и в каких условиях получается монетизировать этот профит ?

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

20 лет назад адепты ООП уже проходили это — http://lib.rus.ec/b/163426/read

Здравствуйте, samius, Вы писали:

V>>Это не только я нахожу и не я это изобрел. Эта лишь одна из практик, которая дополняет современное многопоточное ООП. Ведь ООП не отменяет ни атомарности, ни транзакционности. А понятие валидности состояния в нем было изкаробки.
S>Многопоточный ООП? Ты опять что-то намешал.

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

Помнишь я тебе говорил про быстрое устаревание любого догматического подхода что к ООП, что к ФП? По мне порядка 15 лет — таки быстро.

S>Ну и другими словами ты хочешь сказать что ООП без ФП не самодостаточен? Веский довод...

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

V>>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но.
S>нет, не могу. Уже надоедает.

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

V>>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.
S>А что делает ссылочный тип в чистом ФП (это раз)?

А возражает на твою фразу:

Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>Это банально справедливо для всей статики

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

S>А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).

О чем и речь, что эти вещи появились в Хаскеле не сразу... Собственно как и все вещи, связанные с требованиями мутабельности в реальных программах. Я просто ХЗ зачем отрицать факт заимствования из императивного мира.

S>А что там с Немерле?

Дык, когда мы объявляем иммутабельную переменную ссылочного типа, как далеко, по-твоему, распространяется иммутабельность? Предполагаемые участники:
1. сама ссылочная переменная;
2. объект, на который cсылается п.1;
3. объекты, на которые ссылается п.2.

Здравствуйте, vdimas, Вы писали:

V>>>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.
S>>

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

V>А одна и есть, просто я привел базис, а ты производные:

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

Здравствуйте, SV., Вы писали:

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

BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();

А что такое "Current"? Наверное, есть операция CalcBalanceForDate(Date targetDate), и есть важный инвариант CalcCurrentBalance() == CalcBalanceForDate(new Date()). Этот инвариант верен для всех счетов; то есть, с точки зрения правильного дизайна надо его выносить наружу. Ок, CalcCurrentBalance мы отобрали.
Теперь, код, который я привёл, работать не будет — счёту надо откуда-то взять доступ до своих проводок. Сам он рассчитать баланс никак не сможет.
Откуда он будет брать эти проводки? Из базы? Ну, тогда надо научить его общаться с базой, а это — прямое нарушение SRP. Придётся отпилить от него какую-то функциональность — либо по расчёту баланса, либо по работе с базой.
Если оставить в нём работу с базой, тогда непонятно, почему в нём — почему нам не иметь класс DbManager с методами GetTransfers(Predicate where), кроме которого, в общем-то, ничего и не нужно?
Если оставить в нём работу с расчётом баланса, а проводки отдавать снаружи, то получается, что мы завели целый отдельный класс для примитивов типа

Decimal static CalcBalanceForDate(Date date, allTransfers) 
 return (from t in allTransfers where t.Date <= date select t.Amount).Sum();

Зачем всё это делать, совершенно непонятно.
Всё, что нужно, прекрасно получается безо всяких объектов Account.

Здравствуйте, 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 — которого в динамике все равно в привычном смысле нет — решает ее практически полностью. Остается вопрос оправданности (разумности) такого дизайна, т.е. представления математики в ООП ключе. Но не вопрос принципиальной возможности.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

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

V>Дык, а я и рассуждаю обязательно. Язык — это ведь инструмент, им надо уметь пользоваться. Поэтому факты и правила в Пролог надо понимать в каком порядке подавать, чтобы не получить проседание быстродействия на порядок на ровном месте из-за непонимания работы вычислителя Пролога.

V>Но ветвления в языке (относящимся к языку, а не расширениям) таки нет.
В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.

Здравствуйте, SV., Вы писали:

SV.>Я, наверное, плохо выразился. Ваш продукт что делает? Кучку разрозненных сервисов типа проверки на null предоставляет? Или что-то полезное? Это та же дверь и корова, извиняюсь за выражение (см. ниже по ветке).
Проверка на null (точнее обработка null) — это пример использования не ООП подхода.
Ладно. Другой пример. В проекте все данные хранятся в DTO. Пришел запрос с клиента, этот запрос десериализуется в DTO и путем цепочек преобразований попадает частично в локальный кеш, частично уходит через вебсервисы на сторону. DTO никаких зависимостей на другие классы не содержит, и если там есть логика, то тривиальная.
Запросы идут параллельно много, преобразования тоже идут параллельно. Да, проект представляет собой набор классов, и даже в некоторых случаев наследование там, вот только эти классы все stateless, существуют в единственном экземпляре и хоть и имеет приватные проперти, но они все инициализируются фреймворком, упрощающим dependency injection. SOLID, кстати, в основном соблюдается. Это считаем ОО подходом или нет? Учитывая что объекты не хранят состояния, и если б не были нужны фичи вроде АОП и удобного тестирования, то вообще б по существу там были б сплошные статические методы.

Здравствуйте, samius, Вы писали:

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

V>>Дык, а я и рассуждаю обязательно. Язык — это ведь инструмент, им надо уметь пользоваться. Поэтому факты и правила в Пролог надо понимать в каком порядке подавать, чтобы не получить проседание быстродействия на порядок на ровном месте из-за непонимания работы вычислителя Пролога.

V>>Но ветвления в языке (относящимся к языку, а не расширениям) таки нет.
S>В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.

Вот та самая догматика. А кто мешает считать, что вычисления в ложных ветках if всё-таки производятся, но потом отбрасываются? Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть)

Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости.

Помнишь еще, я как-то спрашивал твое мнение относительно того, почему одна и та же конструкция if-the-else может использоваться как для чистых ф-ий, так и для IO? На тот момент ты еще соглашался, но мне было бы интересно услышать сегодняшнее твоё мнение. Похоже оно чуть трансформировалось. ))

Здравствуйте, vdimas, Вы писали:

I>>На мой взгляд (подсмотрел в профайлере) ты экономишь около нуля(но справа) ресурсов и для этого создал целую инфраструктуру.

V>Умножай свой около нуля на порядка 90-150тыщ сообщений в сек. GC ложится навзничь.

Не ложится

Тест в студию, то есть, давай таки не общие слова а жосткие данные.
Если я тебе скажу, что GC выдерживает 20млн инстанцирований в секунду и память не растет вообще, ты сильно удивишься ?

I>>Итого, п.1 — прояснить не удалось п.2 жостких данных не было, были общие слова

V>Итого ты мистер-торопыжка. Сам спросил, сам же в своем посте не увидел ответа, сам же распинаешься по этому поводу. ))

Итого — ты в первом сообщении ничего не выдал, тоьлко общие слова и до сих пор только общие слова.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Соответственно, вопрос уже переносится из ниши "можно ли нормально представить математику в ООП" в нишу "насколько удачным может быть такое представление".
"нормально" и "удачно" в данном контексте — практически синонимы.

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

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

ВВ>Я еще раз повторю свою мысль — есть языки, в которых это сделано именно вполне ООП-но, причем совсем не экзотические языки. И они как бы работают

Слово "как бы" тут является ключевым.

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

ВВ>Это уже больше вопрос реализации, наверное. И того, что null в целом не самая хорошая вещь на свете.
А тут ничего не сделаешь. Если обходиться без null, то быстро окажется, что мы получили value-семантику, т.е. отказались от ООП-шности.

А так — вполне такое разруливается, как в том же Питоне, через пару методов __add__/__radd__.
И как питон понимает, какой из методов вызывать для a + b?

ВВ>Вообще это вопрос больше о том, кто тащит с собой таблицу методов — она приклеена к значению или же передается отдельно.
Совершенно верно. И ООП на этот вопрос отвечает однозначно — методы приклеены к значению. Если у вас "таблица методов" передаётся отдельно, то это не ООП.

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

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

Здравствуйте, Klapaucius, Вы писали:

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

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

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

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

K>Объективно. Формальное описание нетривиального ООП — это высшая точка TAPL
K>Это формальное описание требует F^omega_sub
K>Самое же обидное, что при такой сложности извлекать из этого формального описания затруднительно.

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

K>Комбинатор в ФП — это обычная функция, которую можно применить к другим и получить нужную "комбинацию" функций.

Спасибо тебе, КО.

K>Нельзя скомбинировать объекты послав им какие-то "сообщения" — можно только произвести "комбинирование" в уме и записать его результат в коде.

А наследование, агрегация, композиция, это, по твоему, не комбинирование?

AVK>>приходится даже на нижнем уровне вводить всякие подпорки типа карринга,

K>Почему карринг — подпорка?

Потому что без него объем писанины возрастает.

AVK>>туплов, АлгТД и т.п.

K>Туплы — это и есть АлгТД.

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

K>Претензия к "автоматическому протягиванию" тайпклассов через неявный параметр — это претензия к дополнительной сущностности того же уровня, что претензия к неявному this в ООП.

В какой то мере, да. Но я нигде и не писал, что ООП идеален.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>В этом и состоит моя ирония, т.к.:

Мне так кажется, кроме тебя самого никто твоей иронии не понял.

V>- по определению чистых ф-ий им не важен порядок вычисления операндов;

Не важен.

V>- ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;

Да.

V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль.

Нет, не начинает.

V> Некие выражения вычисляются заведомо РАНЬШЕ других

Ну и что? Это не приводит к ни к каким сайд-эффектам.

AVK>>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.

V>Заблуждение.

Факт.

AVK>>А логические ветвления присутствуют, наверное, в любой парадигме.
V>Предположу, что только у наследованных от структурной.
V>Например, в логическом программировании никакого ветвления нет.

Есть. Предикаты как раз ветвление для тел правил и задают.

V>>>Про последовательное исполнение в Хаскеле — do-стрелки.
AVK>>А при чем тут Хаскелл?
V>А чтобы сферических коней не гонять туда-сюда.

Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию.

V>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл.

Нет, не дает. Кури определение чистоты. Цикл не может быть чистым, рекурсия может.

V>[q]
V>* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

V>И да, изначально далеко не все языки позволяли рекурсивные вызовы. Вот как раз в ф-ых языках она и появилась в кач-ве способа организации цикла.

Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>До определенного момента, если не вникать, нет. Потом — да. Я это лично наблюдал, к примеру, на Платформе 2006, кажется, года, когда почти весь зал просто подвис через какое то время на нашем с IB докладе про LINQ. Сейчас такого эффекта уже нет, попривыкли.
AVK>А в функциональных языках монады существенно более бесчеловечны, чем специально заточенный под конкретные задачи линк.

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

AVK>>>А я этого нигде и не писал.
ВВ>>Ты писал, что код станет недостаточно абстрактным.
AVK>Где?

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

ВВ>>И мне не очень понятно, почему ты считаешь это подпорками
AVK>Потому что это подпорки к базовой концепции ФВП+иммутабельность. Большая часть вещей выражается только через это, но неудобно.

Ну можешь считать это подпорками, если тебе так хочется. Странно еще, кстати, что ты ПМ не вспомнил. Непонятно только, что это тебе дает. Ты хотел только чистую лямбду увидеть? Это действительно неудобно. Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым. АлгТД те же в общем ортогональны ФП. А вот статические методы как раз очень даже противоречат ООП с его объектами и поведениями.

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

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

ВВ>>Я вот замечаю обратное

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

ФП это далеко не обязательно про иммутабельность.

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

Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.

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

Как же не решают. Решают стандартную проблему — "неудобно". Причем это вам не тюплы в ФП, статические методы как раз явно вступают в интерференцию с ООП.

ВВ>>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП
AVK>Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.

Что, тоже? ФЯ упираются в тяжеловесность ООП? Что-то я вообще не понял, о чем ты.

ВВ>>Я чего-то тут явно не понимаю.
AVK>Скорее не хочешь.

Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП. Да и собственно та форма рантайм полиморфизма, которая обеспечивается ООП, прекрасно достигает и ФП, причем родными средствами. Причем даже императивный код на Хаскелле более выразителен, чем на шарпе. Это в do нотации, про стрелки я уж молчу. Есть конечно и свои проблемы, но они решаются со временем.

А что происходит в ООЯ? Появляются мегамонстры вроде Скалы? И что это дикая солянка — наше светлое будущее?

Причем ФЯ развиваются как раз именно как ФЯ, ООЯ же уносит черт знает куда, в какое-то монстроподобие. Какие тут преимущества можно усмотреть?

> Я пытался поддержать мысль, но получил возражение. В недоумении.

Перечитал еще раз твой пост. Теперь понял

Posted via RSDN NNTP Server 2.1 beta

DG>>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования)
S>А моя основная мысль, что счёт не ведёт себя как объект в ООП. Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".

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

Соответственно, по этому определению, например, и linux-овый file и winapi-шный файл — являются объектами. И тред на форуме rsdn.ru тоже является объектом.

Здравствуйте, grosborn, Вы писали:

>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.

G>Это общий механизм мышления.

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

>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов.

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

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Массы и линейных размеров нет, зато поведение и свойства есть. Эта математическая абстракция есть заимствование из физического мира, представь, передача информанции на уровне сообщений, каналов и даже пакетов появилась еще в те времена, когда пароход феодосия еще шлюпкой был.
Брр. Давайте не будем углубляться в дебри. Математика и физика разделились относительно недавно; тем не менее, под термином "физический объект" подразумевают не просто "что-то со свойствами", а что-то с определёнными свойствами.

I>Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает.
В том-то и дело, что учебники вводят иллюзию, что надо копировать объекты Реального Мира. Лужа и Камень являются очевидными вариантами.

I>Физический объект имеется ввиду заимствование из реального мира, а не корова с выменем, рогами и хвостом.
Сумматора в реальном мире нет. И вычислителя съеденной травы в реальном мире нет. В реальном мире есть корова и трава.

> G>2 + 4
> G> — модель мира?
>
> Математика — это инструмент для описания закономерностей мира.

То есть инструмент, не модель. И не является частью модели. В программировании инструментальных средств — внезапно! — большая часть.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, samius, Вы писали:

S>>Соглашусь, посетитель был бы кстати. Но ничто не мешает прикрутить внешнюю диспетчеризацию

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

S>>или dynamic-ах.

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

Здравствуйте, Воронков Василий, Вы писали:

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

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

ВВ>Просто забавно, было наблюдать, как ты весьма охотно со мной спорил о чистоте концепций

Тебе показалось.

ВВ>Вообще уровень дискуссии очень характерно развивается — посчитай, сколько раз в твоем сообщении слово "жопа" встречается.

Ты бы вместо жоп посчитал количество подтасовок в своих сообщениях.

Вобщем, общайся с кем нибудь другим.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

I>>Для GC это мизер

Издержки на очереди много больше издержек на выделение памяти. Я накидал тест, как ты говоришь, и в ём инстанцирований в 8 раз меньше, нежели без очередей,

V>Всё с вами ясно... Умудриться написать очередь, которая в 8 раз тяжелее GC — это весчь... )))

Как ты мерял тяжесть GC ?
Разница в количестве инстанцирований с очередями и без очередей. Как это можно понять как "в 8 раз тяжелее GC " мне очень интересно. Ты вероятно думаешь, что инстанцирование это такая дорогая операция, отсюда твои "хи хи"

V>У нас она намного легче, чем GC. Не пробовал такую штуку, как "интрузивный список"?

Что значит "легче, чем GC" ? Ты в курсе, что издержки на интрузивные списки намного выше твоей экономии на пустом списке ?

I>>А то что вы храните ссылки на пустые списки — это ваша проблема.

V>Этот пустой список в моем варианте — один на всех.

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

V>>>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.
I>>Так тест будет а то опять окажется что у тебя условие снова изменилось ?

V>Дык, ты не привел своих данных. Сколько сообщений в секунду ты выжал на выхолощенном примере?

Ты не смог поделить 20млн на 8 ? Бывает. Коллекции стандартные, без изысков. Полученное число на порядок больше твоих данных.

V>А мне сюда исходники ложить, чтобы ты их тестировал или как?

Ты описал модель, правильно ? ты не в состоянии повторить её или же она неадекватна ?

V>>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.
I>>Проблемы оттого что вы хранили ссылки на пустые коллекции.

V>Не только. Проблемы от того, что мы храним сами сообщения.

После упоминания интрузивных списков я еще больеш уверен, что никакой экономии твоя статика не даёт, разве что пустой список у тебя не весит в 100кб

>Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.

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

DG>>Как минимум стоит тогда вернуться к основам.
DG>>Я утверждаю, что объект — это ментальная модель служающая для удобства описания происходящего, обладающая рядом характеристик (а дальше по любому классическому учебнику ООП).
S>Вы путаете две вещи. Начинаете вы с философского понятия "объект", который всего лишь противопоставляется субьекту. Такой объект вполне может быть нечётким, и недоопределённым, и т.п.

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

DG>>Соответственно, по этому определению, например, и linux-овый file и winapi-шный файл — являются объектами. И тред на форуме rsdn.ru тоже является объектом.
S>А потом вы внезапно перепрыгиваете в ООП-шное определение объекта, которое значительно более строгое. Но при этом почему-то пользуетесь двумя разными определениями взаимозаменяемо.
S>Файл в винде и линуксе как раз похож на ООП-шный объект, и ОО-дизайн в WinAPI торчит довольно сильно.
S>Но ООП требует от объекта некоторых минимальных вещей, в частности — идентичности. Философский объект "верёвка" запросто может состоять из двуз философских объектов "конец верёвки" и одного "середина верёвки". ООП-шный объект так построить не удастся — потому, что нет возможности провести чёткую границу между "серединой" и "несерединой". См. "где начало того конца, которым заканчивается начало".

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

> ООП-шный объект так построить не удастся — потому, что нет возможности провести чёткую границу между "серединой" и "несерединой".

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.

V>А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо.
Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.

V>Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу.
Еще раз. Речь идет об ветвлении исполнения стейтментов, где стейтменты изменяют состояние программы. В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.

Здравствуйте, AndrewVK, Вы писали:

K>>Так вы же сами писали
K>>

Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
K>>1) Создания абстракций с формальным описанием внешних свойств

K>>А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?

AVK>Да что ж такое то — неужели так увлекательно заниматься подтасовками? Я писал про формальное описание сущностей решаемой задачи, ты же писал про формальное описание самого ООП.

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

AVK>Я нигде ни разу не писал, что карринг это плохо.

Ну вот вы пишете:

Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга

Причем в качестве возражения на то, что дела в ФП получше обстоят. Извините, но я так понял, что указывается на что-то плохое. Выясняется, что подпорка — хорошо. Карринг — хорошо. ОК. Но тогда не могли бы вы в двух словах пояснить, в чем же упомянутая вами проблема заключается? Или нет никакой проблемы?

По поводу композиции и АлгТД возражений больше, как я понял, нет?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.

V>Кстате, хотел бы я увидеть побочный эффект на операторе if для императивного языка. Будем считать, что ветвимся по уже вычисленной переменной. Дерзай.

static int i = 0;
void Foo()
{
    if (true)
      i = 1;
}

Или я что-то не понял?

Здравствуйте, DarkGray, Вы писали:

DG>значит для этой системы будет

DG>

DG>class БухСчет
DG>{
DG>  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
DG>  }
DG>}
DG>Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>

То есть ты непонятно на каком основании сделал кредитный счет важнее дебетового. Зачем?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, DarkGray, Вы писали:

AVK>>Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?

DG>ты мне сейчас рассказываешь про SRP

Нет.

DG>. SRP никакого отношения к объектной оболочке отношения не имеет, а имеет отношение лишь к процессу хранения состояния.

Вообще смысл не уловил. SRP относится к дизайну в рамках любой парадигмы, а не эксклюзивно к ООП. И уж тем более не ограничен рамками хранения состояния. SRP просто мнемоническое правило для следования критериям low coupling/high cohesion, и касается исключительно связей между сущностями в коде, и ничего более.

DG>SRP никак не мешает иметь два метода, которые делают похожую работу:

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

DG>

DG>class БухСчет
DG>{
DG>  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
DG>  }
DG>  public Tx[] ОплатитьИз(БухСчет source, Товарный_Чек чек)
DG>  {
DG>    return DocTxService.MakeDocTx(CreateDocument(source, this, чек));
DG>  }
DG>}

А зачем? Какой юзкейс такие методы упрощают?

DG>и соответственно, обе следующие операции равноправны:
DG>[c#]
DG>Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>//или
DG>Основные_Фонды.Оплатить_Из(Нал, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
DG>

Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

Потому что так удобно — в частности, повышается обзорность.
так же есть принцип "there's more than one way to do it", который в частности входит в unix-way

ps
например, при решении задачи:
сидя вечером разобраться почему в кармане сейчас нала 600р, а бух. система говорит, что баланс 970р, то мне проще работать с объектом Нал, параллельно вспоминая что произошло за день, разыскивая чеки и применяя их к счету Нал, отслеживая сошелся баланс по счету с действительностью или нет?

pps
если же речь идет про программиста, то тот же Gui проще строить по такой объектной оболочке (при этом элементы на экране и кнопки в один к одному соответствуют объектной оболочке, что упрощает построяние скриптов и их освоение пользователем: пользователь просто записывает в скрипте то, что он делал до этого руками), чем строить его к "атомарному" api.

AVK>А зачем? Какой юзкейс такие методы упрощают?

Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.

Gui удобнее строит поверх объектной оболочки, имея соответствие элементов-на-экране к объектам-в-коде, а также кнопок/пунктов-в-меню/элементов-в-палитре-инструментов к методам-объекта — как 1 к 1 по двум основным причинам:
1. упрощается тестирование и сопровождение. Можно отдельно простыми unit-тестами проверить правильность объектной оболочки, и потом для Gui-я лишь проверить, что соответствующая кнопка вызывает соответствующий метод
2. api скриптов и командой строки соответствует действиям GUI-я 1 к 1

Здравствуйте, DarkGray, Вы писали:

AVK>>Т.е. одно и то же можно сделать двумя способами. Вопрос все тот же — зачем?

DG>Потому что так удобно

Чем удобно? Тем, что надо непонятно откуда доставять экземпляр счета?

DG> — в частности, повышается обзорность.

Какая такая обзорность? Если ты про discoverability, то она прекрасно повышается extension методами без измывательств над публичными контрактами бизнес-сущностей. Но в данном случае мне совершенно непонятно, зачем может понадобиться цепочка discovery от счета к проводке.

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

Все равно непонятно, откуда там объекты Счет появятся. Сперва в системе ты заводишь документ — чек. Далее вызываешь для него метод Отработать, и внутренняя логика формирует проводку. Счета при этом даже не вводятся тобой руками, а определяются типом документа и его содержимым в алгоритме формирования отработки, т.е. внутри твоего "Оплатить".

DG>если же речь идет про программиста, то тот же Gui проще строить по такой объектной оболочке

Чем проще?

DG> (при этом элементы на экране и кнопки в один к одному соответствуют объектной оболочке

Давай на реальном примере. http://www.parus.ru/tornado/node/78 — расходник. Вот где там Нал.Отработать() упростит жизнь?

DG>, что упрощает построяние скриптов и их освоение пользователем: пользователь просто записывает в скрипте то, что он делал до этого руками), чем строить его к "атомарному" api.

Мне все меньше и меньше понятно, о чем ты.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Давай на реальном примере. http://www.parus.ru/tornado/node/78 — расходник. Вот где там Нал.Отработать() упростит жизнь?

тут, вообще, достаточно (если, конечно, цель — дружественная система, а не сделай всё сам):

ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5);

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

можно, конечно, задать и в ручную

ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5, 
  From: Источник_обеспечения.Бюджет, 
  Debet: КБК.11.Счет.12.Косгу.13,
  Credit: КБК.10.Счет.1.Косгу.14
)

Здравствуйте, vdimas, Вы писали:

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

А я ничего такого не решал. Я решил что накапливать отсутствие памяти дешевле чем накапливать любую память в том числе из пула.

I>>У меня в тесте тоже нет нулевого поколения. Так ты выдашь внятный тест или будешь и дальше сочинять ?

V>Я тебе уже сказал, что тебе надо делать.

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

DG>>Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.
S>Для ГУЯ сейчас актуально использовать какую-нибудь разновидность MVP.

MVP — это ответ на вопрос, как реализовывать gui
OOUI — это ответ на вопрос, на основе каких принципов проектировать gui

и друг другу эти ответы ортогональны, и соответственно выбор реализации, как MVP — никак не противоречит пострению GUI-я как OOUI.

ps
стоит хоть иногда книжки читать, хотя бы классику: Нильсен, Коллинз, Раскин

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

Здравствуйте, vdimas, Вы писали:

V>http://www.rsdn.ru/forum/philosophy/4838064.1.aspx

V>Смотри какое дальше идет бурление овн. ))

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

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

Здравствуйте, Sinclair, Вы писали:

I>>Вобщем расслабься, больше от тебя ничего не нужно, все жосткие данные уже получены от AVK и DarkGray.
S>Ну и к тому же видно, кто из участников понимает, что он делает. AVK возвращает пустой массив, который иммутабелен по определению.

Зато использование IList в коде сжирает любой предполагаемый профит. А что надо делать с иммутабельностью — я тебе уже говорил там, где скипаешь неудобные аргументы. IList по дизайну нифига не иммутабельный.

S>А коллега vdimas предлагает глупость отдавать наружу разделяемый экземпляр мутабельного ArrayList<T>.
S>Это грабли, заботливо разложенные на пустом месте: однажды в каком-то углу кода кто-то сделает someArbitraryArg.Add(42) и пипец наступит повсеместно. Такую багу можно искать неделями.

Ох, уже не знаем что на ровном месте изобрести. Поздно, все ходы записаны.
1. В исходном примере вообще null, то бишь сценарий изначально подразумевал только чтение.
2. В твой вариант можно точно так же вставить someArbitraryArg.Add(42), всё-равно это будет бага, и всё-равно это может быть сколько угодно далее распространяемая бага, т.к. вопрос относительно того, насколько бага пойдет далеко за пределы примера — вопрос исключительно спекуляционый.
3. Конкретные типы могли быть вполне иммутабельные, т.е. что автор примера, что ты, что я — все показывали только принцип. Теперь же тебя дважды ткнули носом и тебе банально обидно... Но с этим детсадом к доктору, а не ко мне.

Здравствуйте, vdimas, Вы писали:

I>>Это попытка в десятке сообщений выдавить из тебя то, чего Avk выдал одной строчкой.

V>Сказано было именно это с самого начала, просто конкретно ты неадекватно вопринимаешь информацию.

Если почистить от дезы и скорректировать цифры которые отличаются на два порядка, то да

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

Здравствуйте, vdimas, Вы писали:

V>Зато использование IList в коде сжирает любой предполагаемый профит. А что надо делать с иммутабельностью — я тебе уже говорил там, где скипаешь неудобные аргументы. IList по дизайну нифига не иммутабельный.

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

Здравствуйте, vdimas, Вы писали:

V>>>Дык, именно в этом соль.
AVK>>Соль в том, что ты неверно трактуешь понятие чистоты функции, не смотря на довольно простое и однозначное определение.

V>Потому что не в этом определении соль

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

V>, а в том, что само простое определение опирается на определение побочного эффекта, а вот оно уже вызывает постоянные споры.

Это оно только у тебя вызывает споры.

V>чистая ф-ия -> порядок вычисления аргументов не важен, так?

Что такое "вычисление аргументов"?

V>То бишь юмор был в том, что программа на Хаскеле, составленная из чистых ф-ий, на самом деле НЕ МОЖЕТ быть выполнена в чистой манере.

Что такое "выполнена в чистой манере"? И какая связь между этим загадочным термином и происхождением ФП от структурного?

AVK>>Порядок вычислений в семантику чистого Ф-кода не входит, в отличие от императивного.
V>Для Хаскеля именно что входит.

Как из этого следует развитие ФП из структурного?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>>>Смотрите, в чём затык: для вывода баланса на экран придётся построить новый счёт и попросить данные у него:
S>>>

S>>>BalanceLabel.Text = (new Account("03")).CalcCurrentBalance().ToString();
S>>>

SV.>>Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден.
S>Как это "не виден"? Да он в плане счетов написан крупным шрифтом. То, что вы дали счёту какой-то внутренний служебный идентификатор — ваше личное решение; нужды в нём никакой нет.

После таких слов Лука Пачоли в гробу перевернулся.

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

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

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

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

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

SV.>>Да, хотел дописать почти теми же словами, но решил, что и так понятно. Это некий шорткат, который можно реализовать по-разному (хоть бы и дефолтным значением параметра).
S>Это — плохой способ. Вы прячете ту функциональность, которая должна быть на виду.

"Это" — это что? Сделать шорткат от Current'а на Date.Now?

SV.>>Зрение бывает у дизайнера, а не у дизайна. Как и точка, откуда дизайнер зрит. Это так, к слову.
S>Ну давайте не будем

А почему не будем? Очень даже будем. Дизайн — он безответный, и, прикрываясь его интересами (которых у него нет), можно что угодно запроектировать. Вы ровно это и делаете. Берете произвольное решение, которое нравится вам ("надо его выносить наружу"), и пишете "с точки зрения правильного дизайна". Пойди поспорь. Или надо соглашаться, или начнется совершенно идиотский спор "какой дизайн трушнее". Который закончится взаимным посыланием нафиг и тем, что каждый останется при своем мнении.

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

Например, Васе поставили задачу — "построение таблицы [счет]-[текущий баланс]". Если вы опять напишете про своих теток, которые паразитируют на реальном труде, приводя сведения о реальном бизнесе в соотетствие с порождением советского Госплана (а откуда же еще высрались эти планы счетов?), которым такая таблица не нужна, не надо, пожалуйста. Мир не крутится вокруг СССР. У других, знаете, тоже бывает бухгалтерия, в которой баланс счета — сумма проводок, а не состояние.

Так вот, выше я предложил сделать шорткат на основе дефолтного параметра. Что вы изволили назвать плохим решением. Видимо, с точки зрения "Правильного Дизайна", который вы тут представляете на манер Лебедева. С точки зрения не Дизайна, а Васи, у него есть объект acc, у которого можно нажать точку и посмотреть, что будет. Вывалится список методов, среди которых не будет никакого CurrentBalance. А будет CalcBalance(Date forDate = Date.Now). Вася, НЕ ЧИТАЯ ДОКУМЕНТАЦИИ, НЕ ИЗУЧАЯ БУХГАЛТЕРИЮ, приобретет новое знание — что баланс счета есть функция от даты и текущий баланс лишь частный случай. При этом Вася останется в блаженном неведении о проводках. Пока что. Пока он находится в рамках своей задачи.

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

Дальше начинается самое интересное. По мере того, как они будут получать новые задачи и решать их, они будут углубляться в объектную модель. Sinclair увидит, что не все счета базируются на проводках. Вася увидит, что CalcBalance() возвращает не Decimal, а Money. У которого есть члены Amount и Currency. И Вася сразу поймет, что он не в шарашкиной палатке работает, а в международной палатке, и счета тут мультивалютные. Следовательно, решит он, должен быть и способ задать интересующую его валюту. Валюту-то он задаст, а получать баланс все равно будет в рублях. И вот Вася задается осмысленным вопросом (НЕ ЧИТАЯ ДОКУМЕНТАЦИИ! НЕ ИЗУЧАЯ БУХГАЛТЕРИЮ В КОНКРЕТНО ВЗЯТОМ ПРЕДПРИЯТИИ!!): почему я передаю в CalcBalance Currency.USD, а мне все приходят наши, деревянные? А если архитектор еще подумает, "No connection to Forex" — ответит Васе на его вопрос исключение.

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

SV.>>С какой точки зрите вы, я не знаю. Мой поинт в том, чтобы сложность разложить по полочкам. Поставьте себя на место гуёвого программиста, которому дела нет до идентификаторов и базы. Зато у него на входе есть счет, который сводит дебит с кредитом по запросу. И полученный таким образом результат можно запихать в форму и отдать операционисту.
S>Я не понимаю вашу терминологию. Вы придумали какое-то решение и хотите общаться только в рамках него?
S>Ну, а я вижу это совершенно по-другому. Конечно же у гуёвого программиста на входе есть исключительно идентификатор. Потому, что ему приехал запрос .../ShowAccountTransactionHistory.aspx?Acc=78.01
S>И теперь ему из этого номера счёта нужно получить всю нужную по ТЗ информацию. Либо ему надо заниматься порождением нафиг ненужной объектной модели, либо можно скормить этот параметр в метод хелперного объекта AccountingService и получить всё, что нужно.

Гуёвый программист не занимается порождением объектной модели. Он отдает 78.01 в метод хелперного объекта AccountingService, и получает объект Account, который можно изучать через IDE. Оба они, AccountingService и Account, а также все реализации Account, описанные выше, являются частью объектной модели, создавать которую (и упаковывая реализацию в которую) дело архитектора.

SV.>>Это зависит от точки зрения дизайнера на responsibility. Если у вас есть дополнительные требования к работе с БД (допустим, поддержка в качестве БД чего угодно, в том числе NoSQL) — ну, введем посредника, который будет делать выборки и другие реляционные операции по чему ему скажут (а Account ему скажет — по проводкам). Если нет — ради бога, прячьте сиквел в реализацию, получите быстрособранную систему, которая жестко завяжется на структуру таблиц. И то, и другое будет понятной объектной моделью, но с разными достоинствами и недостатками в других областях.
S>Это будет нарушением SRP.

Вы не читаете, что ли? Я же сказал: это зависит от точки зрения дизайнера на responsibility. Если думать о responsibility в терминах "функциональность по расчёту баланса", "функциональность по работе с базой" — тогда да, это нарушение SRP. Если считать responsibility этого класса "предоставить Васе доступ к балансам", тогда нет. Вот когда Account начнет заодно курсы валют возвращать, тогда это будет нарушение SRP.

Еще раз. Вы просто не ставите такой задачи, которую решает ООП, допустим, в том же самом MS ShP.

Здравствуйте, samius, Вы писали:

S>видишь ли, под пунктом 2 управляющая структура, которая выполняет подпрограммы. хаскель-if их не выполняет, а лишь выбирает ветку. У нас есть гарантия что выбранная ветка будет вычислена хоть когда-нибудь?

Я так и знал. )))
Молодца, ты попался на тривиальный очевидный момент. Потому что поторопимшись. Давай ты напишешь пример, где предикат при if ОБЯЗАТЕЛЬНО вычисляется, но не будет вычислена возвращаемая if ветка. Ты увидишь кое-что важное, когда наконец сможешь этот пример породить. Что именно? А достаточно будет сравнить полученный вариант с вариантом работы некоего вычислителя на энергичной технике и попробовать найти отличия в семантике. Будет тоже самое, что в энергичной технике исполнения, близкой к императивному способу вычислений. Просто ты упускаешь тот момент, что семантика ленивого и энергичного вычисления должна сохраняться идентичной, а в энергичной семантике предикат при if ОБЯЗАН быть вычисленным раньше любой ветки... иначе у тебя банальная ф-ия вычисления факториала может уйти в вечную рекурсию по ложным веткам.

Так что ваш аргумент, по-сути, о том, что ф-ия if, как и все остальные ф-ии Хаскеля — ленивые. Это был, конечно, очень крутой и правильный аргумент. Только ни о чем, бо он сугубо о семантике низлежащего вычислителя. Т.е. ты имеешь полное право писать свои чистые ф-ии вовсе не заботясь о низлежащей семантике вычислителя. Где-то так...

S>По другим пунктам тоже можно поглядеть.
S>1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается.

Я таки вижу, что именно само вычисление раскладывают на шаги: сначала задают промежуточные данные (let var=...), потом из них — конечные (in expr). Опять и снова, тот факт что вычисление производится в ленивой манере — ненужные подробности. Теперь найди отличия в описании шагов таких вычислений от описаний точно таких же шагов, записанных в императивном языке (порой с точностью до синтаксиса в compile-time и конечного кода в runtime). Другая модель? Хмм... арифметика, она и в Африке арифметика, как раз на арифметике можно абстрагироваться от любых низлежащих моделей вычислетелей.

S>А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.

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

S>3. Выполнение подпрограммы пока ...уже бессмыслица в хаскеле, т.к. подпрограмма это выражение, которое сколько не выполняй, результат будет тот же самый ... пока булево выражение является true — тоже бессмысленно, т.к. в хаскеле выражение чему равно, тому и равно, сколько его не вычисляй, и выполнение подпрограммы на результат выражения не влияет.

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

S>В итоге, все 3 пункта не о хаскеле.

Да ради бога. Мне просто опять прикольно как ты скачешь с теории на сугубо подробности (ленивое выполнение в случае if) и потом обратно. Эдак даже не получается ровненько провести границы догм, приходится бегать подправлять?

V>>Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?
S>выше две мысли. Одна — if не выполняет ветки, вторая — (*)побочные эффекты не влияют на вычислимость функций, о которой писали авторы теоремы.

S>Если ты хочешь притянуть за уши ФП к СП, то тебе придется обойтись без IO. Потому что (*). А так же потому что имея IO, мы можем на ФП спародировать любую императивную программу. Но ведь ФП Тьюринг-полна вовсе не потому что IO, так ведь?

Ес-но, она Тьюринг-полна, потому что может быть исполнено на конечном вычислителе, который ВЫНУЖДЕН аргументы некоторых ф-ий считать в определенном порядке.

На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
S>>Конечно же это бурная фантазия

V>На всяк случай для ленивых:
V>

V>Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.

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

Здравствуйте, vdimas, Вы писали:

I>>Если весь эффект это "сумма отдельных слагаемых не равна сумме" то этим свойством обладает любой отрезок кода который затрагивает кеш. Делаешь прогоны через паузу — опаньки, суммарное время прогонов меньше суммарного времени прогонов без пауз. GC здесь ничего не меняет.

V>Паузы не в счет, ес-но.

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

>И да, в тесте можно выявить зависимость по двум координатам — по паузам и по кол-ву повторно неиспользуемого кода.

"Количество повторно неиспользуемого кода" это что за термин ?

I>>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.

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

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

I>>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.

V>GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.

Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.

I>>Ты для начала внятно опиши, что же это за эффект такой.

V>Ты уже сам его описал — эффект от выталкивания полезных данных из кеша. Кеш многоуровневый, эффект тоже.

Это не требует разнообразия типов, хватит и просто большого количества объектов.

I>>2 количество узлов в дереве

V>Поправлю, кол-во постоянно обновляемых объектов.

Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep

I>>3 глубина стека

V>Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.

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

I>>4 степень фрагментации

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

Это не важно, чего у вас есть а чего нет, важно что степень фрагментации слишком сильно влияет на скорость GC. Как аргумент — вы от пулами именно с фрагментацией и боретесь.

S>Отчасти поэтому мы и имеем кучу работы с сингатурами,

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

S>сложными правилами совместимости

ИМХО, никаких сложностей: ковариантность и контрвариантность зависит от направления аргумента в сигнатуре in/out, т.е. возвращаемое значение ничем от out аргумента в этом плане не отличается. Сложно запутаться.

S>и прочим, вплоть до несовместимости Func/Action в C#.

Да, в дотнете делегаты не абстрактные типы, а вполне конкретные. За это их пинали с самого начала. Даже напиши рядом такой же Action2 через copy&paste и он будет несовместим с исходным Action.

S>В ФП с более накладным применением аргументов все как-то намного проще.

Тебе проще из-за абстрактности функциональных типов + обобщенного программирования. Это фишка конкретного языка, а не ФП как такового.

Здравствуйте, Ikemefula, Вы писали:

I>>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.
V>>Дык, тогда ты попался. ))
V>>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.
I>А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?

Выделенное не по-русски разве?

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

I>Отключи кеш да замерь разницу.

И какие проблемы? Отключать надо для обоих вариантов для сравнения. Давай тест, отключу да проверю.

Небольшая разница может быть только на многоканальном контроллере, но никак не в 100 раз, ес-но.

Хотя и 100 раз — че-то дофига. Я максимум вручную насильно добивался ухудшения на этом эффекте в ~20 раз на шестиядернике. Мне уже любопытно, как ты получил свои 100 раз?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

V>>>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.
I>>>>Давай, покажи на примере Enumerable.ElementAt, вперёд.

V>>>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))

I>>"прирост до 50 раз " @ vdimas

V>Этот множитель сложился из двух множимых. См. исходный пост на русском языке: http://www.rsdn.ru/forum/philosophy/4843592.1.aspx.

То есть, ты разницу между IList и List помножил на разницу между ручной и встроеной серилизацией ?

Но по любому , ты снова ошибся хотя уже не на порядок

Проверяем "разница м/у использованием List<> и IList<> в коде от 3-х до ~10-ти раз (от стоимости тела цикла зависит)"
Итерации по контейнерам длиной N, где в цикле выполняется единственная строчка в виде обращения к элементу для того что бы все итерации были в равных условиях, элементов 10КК, 10 прогонов + вычисление среднего.
Для сравнения приведены результаты по ArrayList и LinkedList и Array
цикл контейнер время_относительно_первой_строчки
foreach object[] 1
for object[] 1
foreach IList<object> 3.5
for IList<object> 4
for List<object> 1.7
foreach List<object> 2
ForEach List<object> 1.7
foreach ArrayList 6
for ArrayList 3
foreach LinkedList<object> 4

Итого, максимальная разница между List и IList в 2.5 раза. С valuetype вместо object разница еще меньше, всего 1.5 раза.
Вероятно "от 3-х до ~10-ти" ты получил вообще на пустых итерациях

V>А теперь тебе надо бъяснить пассаж насчет Enumerable.ElementAt.

Объясняю — использование List может быть очень дорогим удовольствием, а хочется, что бы некоторые функции вроде Linq2Objects работали крайне быстро, выход — IList<>

I>>Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются.
I>>Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.

V>Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.

Ты похоже не понимаешь — если List это очень дорого, то и массив тоже будет так же дорого.
Реальная разница в 2.5 раза на почти пустой итерации. Если цикл чуть сложнее суммы элементов, эта разница становится ничтожной.

Здравствуйте, Ikemefula, Вы писали:

I>Если бы ты читал внимательно, то заметил бы, что эта разница целиком и полностью из за очереди

Это личные твои домыслы, из-за чего получилась такая разница. Я ХЗ что и как ты смотрел.

I>при том что издержки на GC ничтожны.

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

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

Меня твоя разница пока натолкнула на две мысли:
1. Не понял, что надо в тестах замерять.
2. Не знаешь куда смотреть в результатах теста.

V>>Дык, это ведь ты код требуешь. Я-то эту тему давно прошел и все выводы давно сделал. Мне лишь для своей эрудиции интересно понагибать последний дотнет.

V>>В плане числодробления уже нагибал — сосет не нагибаясь как и прежде. В плане GC они там что-то сильно много хвалились — надо проверить насколько соответсвует действительности.

I>Ничего, если я тебе твои слова покажу ?
I>

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

Именно, а ты как хотел? Любые тесты вокруг ненулевого поколения в GC заведомо нетривиальны.

I>

I>И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.

Не могу сам с собой не согласиться. ))

Здравствуйте, Ikemefula, Вы писали:

I>>>"прирост до 50 раз " @ vdimas
V>>Этот множитель сложился из двух множимых. См. исходный пост на русском языке: http://www.rsdn.ru/forum/philosophy/4843592.1.aspx.
I>То есть, ты разницу между IList и List помножил на разницу между ручной и встроеной серилизацией ?

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

I>Но по любому , ты снова ошибся хотя уже не на порядок

Нет.

I>Итого, максимальная разница между List и IList в 2.5 раза. С valuetype вместо object разница еще меньше, всего 1.5 раза.
I>Вероятно "от 3-х до ~10-ти" ты получил вообще на пустых итерациях

Итого, у тебя опять работает заведомо синтетика и заведомо некорректная. Даю тебе вторую попытку. Вместо 10КК прогонов по циклу попробуй прогон по десяткам элементов (это ближе к реальной задаче сериализации разветвленного графа объекта в памяти), а внешний цикл пусть будет 10КК/x, где x — кол-во элементов.

Сразу получишь более 3-х раз разницы (у меня — 3.75). Ну а потом погоняй стоимость вызова других методов, например стоимость обращения к элементу по индексу (иначе нахрена именно IList??).
В общем, более 8-ми раз на реальных задачах выходила разница из-за простой замены IList<> на конкретные типы. По приведенной ссылке — результаты с реального проекта.

Думаю, более корректным будет тест с глубиной вложенности объектов хотя бы 2. Т.е. было бы неплохо сделать коллекцию в коллекции, разбив эти 100 элементов хотя бы 10*10.

V>>А теперь тебе надо бъяснить пассаж насчет Enumerable.ElementAt.

I>Объясняю — использование List может быть очень дорогим удовольствием, а хочется, что бы некоторые функции вроде Linq2Objects работали крайне быстро, выход — IList<>

Это не объяснение, а туманность Андромеды. Покажи, где IList<> будет быстрее List<>.

I>>>Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются.
I>>>Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.

V>>Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.
I>Ты похоже не понимаешь — если List это очень дорого, то и массив тоже будет так же дорого.

Да, пока что не понимаю, пока ты не показал, где IList<> будет быстрее List<>.

I>Реальная разница в 2.5 раза на почти пустой итерации. Если цикл чуть сложнее суммы элементов, эта разница становится ничтожной.

Для задач просто чтения элементов, о которой речь в сериализации, разница оказалась катастрофической. При десериализации тоже тоже оказалась в несколько раз, бо при десериализации используются те самые остальные методы интерфейса List/IList для наполнения коллекций.

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, samius, Вы писали:

S>>А теперь представьте что потребовалось решить уравнение с комплексными коэффициентами.

SV.>Тогда вы наУчите свои числовые обертки не только точности, но и мнимости. Как это конкретно сделать — в смысле, с наследованием реализаций или нет, а если с наследованием, то чего от чего — я с ходу не соображу, поскольку соответствующую математику со второго курса не использовал. Если кто-то поможет, то заранее ему спасибо.
В том и фишка, что хочется работать с разными представлениями одним кодом, а не запихивать в один класс все возможные представления.
По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

SV.>>>Если мы не заворачиваем конвертации, хранение и расчеты в класс, то где мы их имеем? Во что превратится код без него? Напишите и выложим оба API на голосование. Вот и будет "точная наука".
S>>Точная наука голосованием? До сих пор бы катались в тарелке на спине у слонов.

SV.>Вы видите, что "точная наука" взята в кавычки? Это саркастическая ссылка на "точную науку дизайна", в которую я не верю ни на грамм, из параллельной дискуссии в соседней подветке.
А в проблемы неудачного дизайна верите?

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

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

Здравствуйте, samius, Вы писали:

V>>Оп-па! Отраженный от двери свет послан не дверью. Я бы на месте твоего школьного учителя физики съел свою шляпу.

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

Конечно виноват, он не проверил у тебя раздел оптики и взаимодействия элементарных частиц.
1. Не существует способа узнать, был ли фотон отражен, или сгенерирован.
2. Более того, отраженный фотон не факт, что это тот же самый фотон, который падал на поверхность. Отражение фотона от электрона (а ты видишь 99.9999% отраженных фотонов именно от электронов) описывается как поглощение одного фотона и испускание другого.

V>>Как это вне зависимости, если ты свои органы чувств должен настроить таким образом, чтобы достоверно различить положение двери. То бишь, получить информацию о ней? Как минимум ты должен открыть глаза, посомтреть в ее сторону и сфокусировать кристаллики глаза. Ничего себе "не спрашивал"... Или ты буквально выразился в том плане, что решил с дверью поговорить? )))
S>Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

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

V>>Да, повторно переданная одна и та же информация не изменяет энтропию, увы. Поэтому ленивые программисты поступают с лишней информацией... впрочем, ты уже в курсе как.
S>Ну вот я и утверждаю что модель далека. А ты решил поспорить.

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

V>>Вообще-то ты писал о Лиспе.
S>Я писал о чистом языке.

Совсем чистый язык совсем бесполезен как прикладной. Например, совсем чистые языки док-ва теорем нужны для того, чтобы компилятор сказал — компиллируется или нет программа. Это всё. Но для меня этого бесконечно мало.

V>>Вилять можно только если влез, а потом понял, что не туда. Так что виляние уже де-факто происходит. Ты дважды оспорил, а потом так и не пояснил, ПОЧЕМУ ты спорил-то. Если не воспринимаешь оппонента всерьез, зачем столько пишешь ему в ответ?
S>Я уже задолбался писать, почему я спорю и за что. А про зачем столько пишешь — ну мне ведь интересно, куда ты дальше вильнешь.

Нет, ты таки не пояснил:

Кэй писал что вдохновлялся атомами Лиспа. На самом деле от Лисп-атома до кортежа функций не так далеко.

Но ты спорил, когда я поправлял тебя, что бесконечно далеко. Вот мне и любопытно — это что за спор был такой?

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

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

Вооот. "Мешок". Т.е. "нечто", собраное воедино и относящееся к одному и тому же... )))
Понимаешь... Если обмен сообщениями рассматривать как обмен информацией (а оно именно так), то ничуть не далеко.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

V>>>Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

I>>Ты утверждаешь выше, что тебе на все случаи не нужно писать разные версии этой процедуры. А я утрвеждаю, что надо.

V>Тогда ты не читал или не понял моих примеров. Не желаешь их верифицировать на предмет семантики происходящего?
V>Я тебе специально оставляю своё цитирование — в нем ключ для понимания.

Нет там никаких ключей, посмотри свой код, разуй глаза.

V>Проблема может быть только от непонимания собственного кода. Ты привел некий код и даже не понимаешь как он работает. Вернее так — ты настаиваешь, что имеешь право не понимать, как работает твой код, потому что "пусть всё будет само". Стремный подход, как по мне.

Вообще речь о том, что ты обещался показать процедурное программирование к контексте лямбд, а показал ФП и ООП. Это залет

I>>Ну да и разбираться где в каком случае надо создавать новые экземляры, а где реюзать контекст.

V>Гы-гы 2 раза. Вот это жжешь...
V>Понимаешь... Вернее наоборот — если ты этих вещей не понимаешь (ну не приучен твой мозжечек читать код на автомате), то твои творения — претендент №1 на мильон фейерических нежданчиков, сопровождающих автоматический захват контекста по мутабельным переменным.

Если ты не понял, то это вопрос про GC.

V>Я тебе расписал уже два твоих примера. До тех пор, пока ты не буешь в состоянии полноценно верифиицировать первых два, двигаться дальше нет никакого смысла. Для тебя уж точно. А для меня — тем более, ведь я уже начинаю повторяться. Техника-то одна и та же.

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

V>Там, кстате, кое-какая семантика изменена в моих примерах. Ты и этого не увидел. Но она не относится к ФП/ПП, а сугубо по прикладной части, т.к. интерфейс для сортировок в дотнете безбожно кривой... За верту несет индусятиной.

Это не важно, ты не раскрыл свой основной поинт.

V>>>Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново.
I>>Мне как раз все что надо это лямбду поправить. Правка лямбды это уже смена дизайна ? А ты не простой.

V>Поправка лямбды тебе поможет не всегда из-за ограничений сигнатуры показанного метода для сортировки.

А в твоем случае как максимум не лучше.

I>>Внимательнее читай.
I>>>>

I>>>>Order(x => operation.Apply(Mask(x)))
I>>>>

V>Внимательней пиши. Тут не видно, что это экземплярный мембер.

Это очевидно.

I>>Локальные функции есть во всех языках ? Это новость

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

Нет. Покажи мне локальные функции для языка Си. Спасибо.

I>>Замыкания контекстов вдруг перекочевали в процедурное программирование. А ты, не простой.

V>Нет никаких замыканий в процедурном программировании. Я ручками расписываю то, что у тебя происходит "само". А "само" у тебя происходит исключительно раскладка граблей, бо ты смелО замыкаешь мутабельные данные/объекты, включая this.

Правильно, нет. А ты использовал именно их.

I>>Локальные функции я так поянял есть во всех процедурных языках ? Это новость

V>Дык, даже в отце всех процедурных языков — в Фортране.
V>И если это твой "последний аргумент", то я признаю себя заведомо победителем этого спора.

Покажи локальные функции в языке Си.

I>>Нет этого аналога, ты демонстрируешь ООП и ФП особенности.

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

Ты показал что функциональщина это функциональщина, а обещал показать что функциональщина это процедурное.

I>>Ты демонстрируешь ООП и ФП а не процедурное программирование.

V>Мне виднее, я успел на ПП пописать несколько лет до полноценного переползания на ООП. Реально ООП и ФП используют практические наработки процедурного/структурного программирования, а вовсе не наоборот.

Из твоих примеров это не следует.

I>>А мы договаривались что я покажу тебе все комбинаторы ? Или ты просто решил намекнуть непойми на что ?

V>Ты можешь показать что угодно, но 3 базовых комбинатора существуют независимо от тебя. Остальные комбинаторы — производные. И уж мне хватит соображалки выразить любой из них через базовые. Это задача примерно 8-го класса.

Не важно. Мы говорим совсем на другую тему и количетсво комбинаторов в моих примерах не имеет значения

Здравствуйте, vdimas, Вы писали:

I>>

I>>void f()
I>>{
I>>   int x;
I>>   class XXX {
I>>      int& x_;
I>>   public:
I>>      XXX(int& x) : x_(x) {}
I>>      void operator()() { ... }
I>>   } _xxx(x);

I>>   ...
I>>}
I>>

V>Так тоже можно и не только в новом С++. Но под локальностью подразумевалось не это, а видимость процедуры/ф-ии из всего проекта.

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

V>==========
V>Показанный вариант имеет кое-какие ограничения при использовании его как параметров шаблонов, поэтому в таком виде его не используют. Он подойдет только если объявить в нем статические методы — они и будут те самые локальные ф-ии, которые придется связывать с аргументами посредством заранее объявленного шаблонного ф-ого типа, например, через boost::bind.

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

Здравствуйте, samius, Вы писали:

I>>Это никакое не требование. ООП всего лишь инструмент для перевода модели в код. Эффективность меряешь сам. ООП здесь ничем не помогает. То есть неэффективная модель может быть переведена в неэффективный код и ООП здесь ни при чем.
S>http://www.rsdn.ru/forum/philosophy/4850451.1.aspx
S>

S>Этот "вычислитель" требует ООП, а не уравнения.

S>Так значит это все-таки не требование?

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

Здравствуйте, samius, Вы писали:

V>>Она не моя. Законы оптики существует независимо от нас с тобой в частности и от человека в общем.
S>В том числе поэтому давай ты не будешь вписывать в законы идентичность получателя фотона

Увы, получить информацию можно только поглотив энергию. Поэтому идентичность никуда не денется. )))
Ведь эту энергию поглотит "кто-то конкретный".

S>>>В быту двери не испускают свет.
V>>У меня испускает. Лампочка на звонке прямо на двери.
S>Ты добрался в тонкостях до фотонов и тут же перестаешь отличать дверь от лампочки. Толсто.

В итернете ты можешь найти фото дверей, которые одна сплошная лампочка. Что было действительно толсто — так это сравнивать фотон с мячом. Спишем на кривые представления о происходящем...

V>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
S>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.

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

V>>Ты сам разве не видишь, как далеко ты уже пытаешься убежать от банальных, вообще-то, вещей?

S>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

Подтроллировать надо уметь. А у тебя в каждом втором посте — серьезные ошибки.

V>>Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов".

S>Необоснован твой абзац с подпиской на фотоны.

Дык, давай аргументы. Твоя необоснованность- она в отсутствии обоснования, если ты забыл смысл этого слова.

S>По поводу концепции "непрерывного генерирования сигналов", то если ты говоришь о фотонах, а не о волне, то ничего непрерывного в той концепции нет.

Любая дискретность происходящего сглаживается физикой/химией колбочек глаза. Уже 100ГЦ человеческий глаз не различает.

S>>>Что бы послать сообщение, нужна идентичность. Подписка — это передача идентичности. Выходит что прежде чем предмет начнет высылать тебе информацию, ты должен передать ему свою идентичность.
V>>Опять нет.
S>Что нет? Не натягивается?

В таком категоричном виде — нет ес-но. "События" в ООП в виде мультикаста — оно так прижилось фактически сразу. Объект шлет события и не знает кому.

V>>Это отличное ООП, см. мультикаст делегаты. Ведь "адрес" тоже может быть не конкретикой, а абстракцией. Для событий дотнета приемником события является на самом деле мультикаст делегат, то бишь некая "шина", имеющая собственный "адрес".
S>Мультикаст делегат является собственно объектом с конкретной идентичностью, и посылает он сообщения объектам с конкретной идентичностью.

Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы.

S>Разве что не только объектам. И ничего широковещательного аки в эфире в мултикаст делегате нет. Медиатор тоже не в тему, т.к. имеет конкретный адрес.

Я тебе уже сказал не раз, что есть дарес для фотонов. Хотя, ты и сам должен был знать. Чтобы доставлять фотоны по произвольному адресу, нужны волноводы соотв. радиодиапазона.

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

Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики?

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

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

Т.е. всё это время был лишь протест против словосочетания "естественным образом"?

Когда такое говорят о технических моментах, то подразумевают, что некий технический момент для неких условий/ограничений/задачи наиболее удобен.
S>>>Твои проблемы не являются аргументом в споре.

V>>Являются. На абсолютно чистом языке невозможно написать полезную программу, ведь она не сможет ввод-вывод, то бишь ты никогда даже не узнаешь, запущена она или нет. Это будет фантом, а не программа. ))
S>Ты от исходного тезиса отклонился уже на 120 градусов. И напомню, хаскель все еще считается чистым языком общего назначения.

Мало ли что "считается". Ты уже достаточно его знаешь, чтобы понимать как на самом деле. На Хаскеле МОЖНО писать чистые участки кода... это да....

V>>Это от непонимания происходящего, от цепляние за догмы как за соломинки. Зачем ты запрещаешь сам себе ставить мысленные эксперименты? )) Смысл?
S>Разве же запрещаю? Я просто не делаю из них очень резкие выводы, как у тебя.

Я кроме "удобства" ещё ни одного вывода не сделал. Остальное — считай разминка для образного мышления и ничего более. Просто я ХЗ почему 10-й пост подряд должен объяснять тебе, что имею право раздавать роли объектам так, как мне, разработчику, удобно. Внося динамику в процесс, увы, удобнее всего наделить дверь "поведением", умением "отвечать" и т.д. Или нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

S>А теперь о связи между боксированным представлением и вытеканием хаскеля из СП. Просим.

Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) Я так и думал.

А требование босксированого представления само по себе накладывает ограничения. То бишь для программы, генерирующей пользу во времени, ты должен понимать, что обработать такую "последовательность" с конца — неэффективно (в отличие от "последовательностей" на сравниваемом там же С/С++)... Хотя, казалось бы, одна строчка разницы в рекурсивном алгоритме... А всего-то добавилось понимание происходящего и ты уже более адекватен с т.з. инструмента.

V>>Насчет Хаскеля и СП — я ХЗ почему ты там так и не смог ответить аргументированно (и никто не смог), а здесь вспомнил опять.

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

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

Ну а остальное уже подытоживал:

В данном же случае речь шла о таком забавном замеченном моменте:
чистая ф-ия -> порядок вычисления аргументов не важен, так?
Для Хаскеля порядок вычисления аргументов важен -> чистая ли ф-ия??? )))

Ну т.е. прикол-оксюморон и ничего больше...

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

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

V>>Тупл вполне себе тип. А уж АлгТД — не просто тип, а натуральный абстрактный тип, на котором сидит весь хаскелевский рантайм-полиморфизм.
S>А что, типы и в частности туплы это теперь прерогатива ООП?

Контракт на методы типа? — ес-но! Это непосредственная вотчина современного ООП. Но ты непременно оспариваешь мой тезис, что парадигмы воруют друг у друга наработки. "Баба Яга против!" во всей красе. )

V>>Кому не нужна? Насколько я вижу программы на хаскеле — экземпляр какой-нить монады (не только IO) вполне себе обеспечивает "рамки" некоего вычислительного процесса. А идентичность — это и есть способ отличить одно от другого, расставить те самые "рамки".
S>Что за "экземпляр" монады?

Это такой функциональный объект.

S>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.

Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?

V>>Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира.

S>во-первых, отличия на поверхности. Код эмуляции будет чистым.

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

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

О чудо, ты наконец попал!

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

Здравствуйте, Ikemefula, Вы писали:

I>Так дверь испускает свет или лампочка что на двери испускает свет ?

Все зависит от того, что от чего наследовали: дверь от лампочки или наоборот.

Здравствуйте, samius, Вы писали:

I>>Покажи недостающую разницу между замыканиями и локальными функциями.
S>В паскале вложенные функции.
S>Разница между замыканием и вложенной функции в том, что вложенная функция может быть вызвана лишь напрямую из внешней, т.к. ей нужен стек фрейм внешней функции. А замыкание продлевает время жизни связанного окружения до времени своего существования, которое не ограничено временем выполнения внешней функции.

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

http://c2.com/cgi/wiki?LexicalClosure

Здравствуйте, grosborn, Вы писали:

>> Если переменной дается local scope (т.е. не глобальный), и этот scope распространяется на вложенную функцию, то согласно этим определениям будет ли переменная внешней функции локальна для внутренней или нет?

G>Ошибочный тезис о том, что переменные из внешнего по отношению к исполняемому scope, внесенные каким-то механизмом в контекст исполнения становятся локальными, выдвинул ты. Я тебе его разрушил простым примером глобальных переменных. Кроме него есть и другие. Так что ты не крутись перебирая все ссылки википедии, а просто признай ошибочность тезиса.
Ты разрушил не тезис, ты разрушил мое предположение о том что ты можешь работать с определениями. При том что мы будем пользоваться различными определениями/понятиями мы ни о чем не договоримся, а лишь потратим время.
Вобщем, если я в чем-то и ошибаюсь, то убедить меня в этом ты сможешь лишь вникнув в определения википедии, а не продавливая мнение что я ошибся, игнорируя что я пишу в ответ.

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

Здравствуйте, Sinclair, Вы писали:

G>>А это ты сам придумал.
S>Профессионал должен уметь и размышлять, а не только цитировать авторитеты. Я с samius согласен.

С чем именно ты согласен ?Вот два его высказывания:

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

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

Глобальный — видим во всех скопах
Локальный — это не глобальный, то есть видим не во всех скопах
непосредственно локальный — в единственном скопе, в котором определен
общий — в нескольких скопах

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

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

Здравствуйте, Ikemefula, Вы писали:

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

I>Ты показал что функциональщина это функциональщина, а обещал показать что функциональщина это процедурное.

Я и показал, бо никаких функциональных вещей НЕ использовал. Вообще никаких. Ссылка на процедуру известна со времен ассемблера еще до появления ЯВУ и присутствует во всех сколь-нибудь важных для индустрии императивных языках. Даже там где нет аналога AdressOf (например, в Фортране), там аналогичная техника работает через Computed GOTO.

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

Просто ты отрицаешь само наличие декомпозиции задачи в рамках процедурного подхода (или не понимаешь её, ХЗ). В процедурном подходе декомпозиция отталкивается от данных и алгоритмов их обработки. Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн. И ты попался! ))) Мне доставляет определенный фан наблюдение за тем, как оппоненты ловятся на том, что соглашаются о близости ООП и процедурного подхода (наверно из-за застилающей им глаза мутабельности/императивности), но спорят насчет близости процедурного подхода и ФП. С т.з. дизайна программ всё наоборот, ес-но.

I>>>Ты демонстрируешь ООП и ФП а не процедурное программирование.
V>>Мне виднее, я успел на ПП пописать несколько лет до полноценного переползания на ООП. Реально ООП и ФП используют практические наработки процедурного/структурного программирования, а вовсе не наоборот.
I>Из твоих примеров это не следует.

Боюсь, в ответ на мои обоснования тебе придется привести свои. Простое "нет" не канает.

I>Не важно. Мы говорим совсем на другую тему и количетсво комбинаторов в моих примерах не имеет значения

Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лмбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.

V>>Локальные есть во всех процедурных языках, а что? Это ф-ии, видимые лишь из одной единицы компиляции. То бишь нигде более не объявляемые и никуда не экспортируемые.
I>Нет.

Да.

I>Покажи мне локальные функции для языка Си. Спасибо.

Такая пойдет: void function_57C24FEC93AC4ED0867305FE733CF6E1() {}? )))

> G>Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека.
> Ок, отлично. Вы попали в мой личный игнор-лист. Прощайте.

Я безмерно счастлив, вспоминая все твои перевирания слов и тролление.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

I>Ты использовал для аргумента локальные функции == без пяти минут лямбды, это и есть функциональщина.
I>Указатель на функцию — снова поддержка ФП.

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

Ес-но в Паскале вложенные ф-ии являются полноценными замыканиями сами по себе. Но из-за b[ ограничений в подробностях Паскаля хрен ты подашь AddressOf этой вложенной ф-ии куда-то вне вышестоящей ф-ии, в которой она объявлена — будет маленький бумц с большими последствиями.

V>>Просто ты отрицаешь само наличие декомпозиции задачи в рамках процедурного подхода (или не понимаешь её, ХЗ). В процедурном подходе декомпозиция отталкивается от данных и алгоритмов их обработки.
I>Ага, а указатель на функцию это данные, да ?

Это указатель на алгоритм. Да, алгоритмы можно привязать к данным. А ты думал, ООП с луны свалилось? Оно уже вовсю использовалось в модульном программировании, только ручками.

Или тебя смущает именно указатель?

Ноу проблема, пронумеруй алгоритмы и диспатч их на switch/case. Та же фигня, вид в профиль. То бишь, появление адреса ничего не меняет в дизайне, просто дает более эффективный способ переключения алгоритмов.

>>Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн.
I>В твоей трактовке это так потому что в процедурное ты записываешь фичи из ФП.

Это с каких пор ФП оперирует адресом ф-ии??? В ФП ф-ия представлена малость сложнее, чем просто адрес. Собсно, всю механику я тебе уже показал.

V>>Боюсь, в ответ на мои обоснования тебе придется привести свои. Простое "нет" не канает.
I>Все аргументы я привел, возможно ты их не понял, это другой разговор.

Дай ссылку или процитируй те аргументы, которые еще не были опровергнуты. ))

V>>Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лямбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.
I>Нет, не имеет.

Будь мужиком, скажи прямо — насчет своей оценки в 10 раз ты откровенно лажанул.
Такое резкое сокращение кода вообще способны дать только макросы или обобщенное программирование, но не разница в парадигмах. Они им перпендикулярны.

I>Тогда покажи аналог моего кода на языке СИ.

У тебя в коде используется обобщенное программирование, поэтому я тоже применил обобщенное программирование для аналога. Но я не использовал никакого ООП. Обобщенное программирование было применено к структурам и свободным процедурам/ф-ям. Если ваять на чистом С, то моя инфраструктура переползет на макросы. И то и то — кодогенерация, но обобщенное программирование типобезопасно, поэтому показалось мне более интересным для демонстрации.

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

Мне и не надо ничего захватывать. Захватить я могу явно.

I>1. описать структуру для захвата

Можно. А в 99% случаев хватит некоего обобщенного Tuple.

I>2. описать функцию которая будет работать с этой структурой

Дык и в ФП целевую ф-ию описывать надо.

I>3. выполнить захват, то есть создать экземпляр, инициализировать

В C/С++ это выполняется в человеческом синтаксисе:

struct { int a; int b; } context1 = { 42, 43 };
TUPLE((int, float)) context2 = { 42, 43.44 };

I>4. освободить память (хрен знает когда)

Да. Но техника GC, оп-па, тоже нейтральна к парадигмам.

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

Дык, в STL ф-ия qsort — это внешняя свободная ф-ия, а не метод объекта. И работает над любыми итераторами произвольного доступа и с любыми предикатами сравнения.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>которое не ограничено временем выполнения внешней функции.

V>Для Паскаля именно временем выполнения внешней ф-ии и было ограничено.
Да не может быть

S>>Таким образом, пока паскаль располагал локальные переменные на стеке, его вложенные функции не могли считаться замыканиями.

V>Замыканию вообще фиолетово, как переменные располагаются. Локальный контекст одних вычислений доступен в контексте других. Это всё.
V>Вот определение из вики:
V>

V>Замыкание (англ. closure) в программировании — процедура или функция, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции и не в качестве её параметров (а в окружающем коде). Говоря другим языком, замыкание — это процедура или функция, которая ссылается на свободные переменные в своём лексическом контексте.

V>Паскалевские локальные процедуры/ф-ии в точности соответствуют.
Читаем дальше

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

туманно, но паскаль отпал. А в английской вики про паскаль прямо и написано что не поддерживает. Да, и не только в ней. На haskell.org тоже написано. Уж там-то наверное в замыканиях знают толк? Хотя, может они не знают толк в паскале

Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь. Как именно — это видно из контекста вокруг определения. Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался.

V>Ну дык, я же не виноват, что ты не поспеваешь за мной. )
V>Итого:
V>1. аргумент-предикат вычисляется тогда, когда надо будет вычислить одну из веток then-else.
V>2. аргумент-предикат обязательно вычисляется перед вычислением удачной выбранной ветки.

V>Уффффф... ))
ну да

S>>Ты уже задолбал делать выводы по вычислителю.

V>Дело не в выводах, а в том, что все рассуждения должны сойтись на всех моделях, соответствующих рассматриваемому (в данном случае — чистому ФП). ИМХО, полезно крутить в голове семантику собственного кода в случае его ленивого и не ленивого исполнения, верифицируя её идентичность — это как проверка уравнения после решения... поможет, в случае чего, найти ошибки в неверном решении.
О неверном решении чего ты говоришь?

S>>Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто.

V>Это НЕ принципиально. В насквозь императивном языке вычисление ветки тоже может быть чисто, даже если будет мутабельность в каждой строчке кода. И прямо отсюда тебе надо искать еще аргументы в разнице происходящего.
Да, вычисление стейтмента может быть чисто. Но толку в этом чистом вычислении не больше чем в Sleep(xxx);

S>>отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись.

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

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

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

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

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

V>Собсно, я начинаю понимать причины твоего спора со мной. )))
V>Это уже даже не догматика, а натуральное плавание в базовых понятиях...
А ты, вижу, их совсем перескочил.

S>>А мне прикольно как ты опять влез на МТ

V>Я влез только для демонстрациия обязательного взаимного аналогичного отображения. А то некоторые порой забываются...
Ты опять из отображения сделал какие-то нелепые выводы

S>>Твоя аргументация убивает

V>Опять показываешь всю степень трагизма? )
V>А меня убивает твоя оторванность от понимания работы ФП, хотя ты выступаешь последнее время со стороны этого "лагеря".

А меня твоя отрованность от ФП, ИП, ООП, базовых понятий и прочего.

V>В общем, рядом более грамотный в ФП-лагере товарищь мне вторит: http://www.rsdn.ru/forum/philosophy/4853976.1.aspx
V>

V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.
V>В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.

V>И далее почитай ветку, там более-менее по-делу.
А я с ним согласен. Это ты что-то вбил себе в голову будто я отрицаю порядок вычислений в ФП.

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

V>>>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.

S>>Что-то много букав.

V>Блин, хорош прикалываться. А так и будем ни о чем.
V>Я думал, что очевидно было это: для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным. А все мои якобы "провокационные" заявления об идентичности происходящего что в ФП, что в императиве исходили из того, что в энергичной технике исполнения ФП будет ровно аналогичное (почему так — уже доказал), а семантика ленивого вычисления не должна отличаться от семантики энергичных. Всё!
Много букв, а требование это вовсе не требование, см. ниже.

S>>Да, конкретно в хаскеле K/KI будет вычислено раньше.

V>Да в любом, хоть в чистом, хоть в глязном, хоть в ленивом, хоть в энергичном — везде будет раньше. Через это не перепрыгнуть.
С этим можно спорить. Безусловно это повлияет на класс вычислимости языка, но можно сначала вычислить векти, потом выбрать нужный результат.

S>>понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).

V>Ээээ... а причем тут это и ветки if?
Притом что структурный if управляет выполнением именно стейтментов

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

if (condition)
{
    5;
}
else
{
    3;
}

Кому это нужно, если if это стейтмент, а не выражение?

Здравствуйте, vdimas, Вы писали:

I>>Ты использовал для аргумента локальные функции == без пяти минут лямбды, это и есть функциональщина.
I>>Указатель на функцию — снова поддержка ФП.

V>Блин, да ты код из 5 строк прочесть уже не в состоянии?
V>Ты сейчас имел ввиду локальные ф-ии наподобии паскалевских вложенных? Покажешь в моих примерах аналогичное, не? )))
V>Ес-но в Паскале вложенные ф-ии являются полноценными замыканиями сами по себе. Но из-за b[ ограничений в подробностях Паскаля хрен ты подашь AddressOf этой вложенной ф-ии куда-то вне вышестоящей ф-ии, в которой она объявлена — будет маленький бумц с большими последствиями.

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

V>Это указатель на алгоритм. Да, алгоритмы можно привязать к данным. А ты думал, ООП с луны свалилось? Оно уже вовсю использовалось в модульном программировании, только ручками.

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

V>Или тебя смущает именно указатель?

V>Ноу проблема, пронумеруй алгоритмы и диспатч их на switch/case. Та же фигня, вид в профиль. То бишь, появление адреса ничего не меняет в дизайне, просто дает более эффективный способ переключения алгоритмов.

Со свичем тебе понадобится кода почти в 100 раз больше

>>>Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн.
I>>В твоей трактовке это так потому что в процедурное ты записываешь фичи из ФП.

V>Это с каких пор ФП оперирует адресом ф-ии??? В ФП ф-ия представлена малость сложнее, чем просто адрес. Собсно, всю механику я тебе уже показал.

ФП реализовано в С чз указатели на функции.

V>>>Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лямбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.
I>>Нет, не имеет.

V>Будь мужиком, скажи прямо — насчет своей оценки в 10 раз ты откровенно лажанул.

Ни в коем случае. Ниже ты подтвердил именно то, о чем я говорил в самом начале
1. тебе надо описывать структуру для захвата + делать поддержку этого в инфраструктуре
2. описывать функцию для работы со структуриной — кода в любом случае больеш чем для лямбды
3. выполнять сам захват
4. эмулировать GC

Теперь представь, изменились требования а с ними контекст... Тебе придется переписать вообще всё, кроме инфраструктуры. Мне — только лямбды.

V>Такое резкое сокращение кода вообще способны дать только макросы или обобщенное программирование, но не разница в парадигмах. Они им перпендикулярны.

Макры и обобщенное программирование это тоже парадигмы.

I>>Тогда покажи аналог моего кода на языке СИ.

V>У тебя в коде используется обобщенное программирование, поэтому я тоже применил обобщенное программирование для аналога. Но я не использовал никакого ООП. Обобщенное программирование было применено к структурам и свободным процедурам/ф-ям. Если ваять на чистом С, то моя инфраструктура переползет на макросы. И то и то — кодогенерация, но обобщенное программирование типобезопасно, поэтому показалось мне более интересным для демонстрации.

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

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

V>Мне и не надо ничего захватывать. Захватить я могу явно.

Чушь. Покажи полноценный пример, который можно скомпилировать. Я сделаю тоже самое, результат сравним. Идёт ?

I>>1. описать структуру для захвата

V>Можно. А в 99% случаев хватит некоего обобщенного Tuple.

ФП тебе не помогло, ты решил взять в помощь парадигму обобщенного программирования ?

I>>2. описать функцию которая будет работать с этой структурой

V>Дык и в ФП целевую ф-ию описывать надо.

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

I>>3. выполнить захват, то есть создать экземпляр, инициализировать

V>В C/С++ это выполняется в человеческом синтаксисе:
V>

V>struct { int a; int b; } context1 = { 42, 43 };
V>TUPLE((int, float)) context2 = { 42, 43.44 }; 
V>

А у меня здесь будет одно лямбда выражение.

I>>4. освободить память (хрен знает когда)

V>Да. Но техника GC, оп-па, тоже нейтральна к парадигмам.

То есть, тебе и здесь надо руками пихать ?

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

V>Дык, в STL ф-ия qsort — это внешняя свободная ф-ия, а не метод объекта. И работает над любыми итераторами произвольного доступа и с любыми предикатами сравнения.

STL это ни структурное, ни процедурное, это совершенно иная парадигма, точнее целых три — ООП + ФП + обобщенное.

Здравствуйте, vdimas, Вы писали:

I>>То есть, ты только что удесятерил минимально необходимое количество кода.

V>Ты так и не показал удесятирение. А разговаривать ярлыками со мной бесполезно.

Ты сам показал все что нужно

Хочешь — берем один из моих примеров и делаем код компилирующимся и пригодным для общего случая. Ты на Си, я на C# и сравниваем количество кода.

У тебя варианты — 1 вилять и уклоняться 2 показать код

I>>А это именно то о чем я говорил — ручное связывание.

V>Не вседа это связывание (пытаюсь опять обратить на этот ВАЖНЫЙ аспект твоё внимание). Зачастую выгодней или надежней создать копию значения для замыкания. Но тебе как об стенку горох. Да, в процедурном программировании способ передачи данных в процедуры — это часть дизацна и часть работы программиста.

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

V>Т.е. да, я ручками тебе показал то, что в лямбдах происходит автоматом. Я именно это и обещал показать.

От тебя требовалось не это, а вот что "функциональная композиация несильно отличается от процедурной." — здесь ты слился, тк. показал ФП против ФП.

I>>Ты бил себя пяткой в грудь что это не надо.

V>Фантазии. Ветка на месте, можно освежить, коль забыл.

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

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

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

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

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

Локальные функции == вложеные функции.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

S>>На бумажке в клеточку. Там же была документация по паскалю, срисованная с доски. Время на писюках предоставляли лишь с 3-го курса, и то его хватало лишь на вбить код и получить результат. Т.е. возможности для глумления над паскалем не было.

V>Т.е. специальность непрофильная...
Ну как, специальность — математик. С компами тогда напряженка была.

V>Наверно, поэтому не хватает здравого цинизма во взгляде на вещи ))
Я вижу, твой здравый цинизм ни к чему хорошему пока не привел.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

I>>Вот-вот. А отсутствие локальных функций означает количество кода примерно в 10 раз больше того, что ты показал.

V>Просто шедеврально!
V>Я ведь и написал пример в отсутствии локальных функций. Уууппссс??? ))

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

Здравствуйте, Sinclair, Вы писали:

I>>Это тоже нормально реализуется в ООП

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

Проектирование глобального рендерера это задача мягко говоря не простая. В WPF микрософт отказались той моджели что WinForms и во многих сценариях перформанс стал ещё хуже.

Здравствуйте, Ikemefula, Вы писали:

I>>>Берём Хаскель и делаем всякие вычисления — хаскель крут.
K>>Вычисления? Вы шутите?
I>Вычисления и прочие алгоритмические задачи.

Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?

I>Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++. Скорость в данном случае — в первую очередь вопрос имплементации (некоторые языковые фичи вроде динамики ограничивают скорость принциписально).
И, собственно про скорость (в числе прочего) я и говорю "(не)можем себе позволить".

I>С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

Ну, для написания ОС нельзя (с незначительными в контексте дискуссии оговорками) ничего себе позволить кроме C++ и C. Значит и сравнивать можно только С++ с C. Т.е. пример это вырожденный — если бы были ОС с равной функциональностью на разных языках — можно было бы сравнивать код и определить какой язык лучше подходит. Но в условиях, когда выбор языка себе прозволить нельзя — и сравнивать нечего.

I>>>и компактно
I>см выше.

Что это за язык такой, на котором код менее компактный, чем на C++? Брейнфак? Лисп? C? Java? Вот, пожалуй и все — на остальных будет компактнее.

K>>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
I>Не правильно. См выше.

Да все правильно. Выше и сравнивается C++ с самим собой.

K>>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.
I>Очень просто, С это всегда С++, С++ не всегда С.
Во-первых, С — это не всегда С++, ну да ладо. Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода? В ответ на какой вызов "появился" C++? Когда возникла задача "написание операционнх систем"? "Написание почтовых клиентов"? "Написание поисковых движков"? "Написание компиляторов"? "Программирование марсоходов"? Ведь по вашей теории все это просто не может быть написано на одном языке — иначе языки общего назначения действительно языки общего назначения, как утверждаю я, а не "нишевые", как утверждаете вы. Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?
Как ваша теория объясняет, например, написание интернет-магазина Гремом на лиспе, а потом его переписывание на C++?

В рамках моей теории это все естественно. На C++ переходят, когда (считают что) могут себе это позволить. К примеру, разработчики gcc могут позволить с 14-го числа этого месяца. А когда могут себе позволить что-то более продвинутое — начнут использовать это что-то. Если же "продвинутое" позволить себе уже нельзя — откатываются вниз.

K>>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.
I>Если точнее, то такого никогда не было.

На планете Земля вполне было. Не существует на нашей планете такой ниши, где бы C не отметился.

K>>Какие еще ФЯ, кроме "некоторых лабораторных"?
I>Erlang, Ocaml

Во-первых, я говорил про ФЯ, а не гибриды. Во-вторых, Окамл — еще "лабораторнее" (в плохом смысле этого слова) Хаскеля. Было, конечно, время, когда Окамл был вообще единственной хоть сколько нибудь пригодной для использования реализацией (недо)ФЯ, но эти времена миновали. В-третих, Эрланг — это как раз один из немногих реально существующих представителей выдуманного вами мира непонятных языков которые то ли общего назначения — то ли ДСЛ, по крайней мере 1% задач он решает лучше, чем 99% языков, а для оставшихся 99% вообще не пригоден.

I>Конечно. Напиши драйвер на хаскеле, питоне, руби... Можешь даже на дельфи попробовать — реализуемо, но в своем уме никто этим не занимается.

Все тот же случай "не можем себе позволить" и соревнующийся сам с собой C.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Воронков Василий, Вы писали:

AVK>>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.

ВВ>Вообще в Хаскелле кортежи это:
...

Это из-за бедности системы типов. Берут АлгТД с всего одним дискриминатором и пользуют его аргументы как тупл, игнорируя сам дискриминант. В общем, чем-то смахивает на матлаб, где скаларные значения на самом деле матрицы [1,1]. ))

И по-хорошему надо писать так:
ВВ>

ВВ>data Pair a b = PairCtor a b

ВВ>data Triple a b c = TripleCtor a b c 
ВВ>

ВВ>и т.д.
ВВ>А (,) и (,,) — это просто такие конструкторы вместо Pair и Triple. Они, кстати, так и описываются в инстансах.

Здравствуйте, samius, Вы писали:

Веселый у тебя пост получился. Ты решил сдуться сразу по половине вопросов и вместо аргументов ухватился за последнюю соломинку — за "идентичность"? ))
Ню-ню..

[скипнул 50 вопросов "а где идентичность?"]

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

Да двойка опять, се ля ви. Идентичность — это тоже элемент модели, то бишь тоже результат абстрагирования.

Кароч, ликбез: тела в рж могут состоять из разнородных элементов — частиц, те в свою очередь из более мелких и т.д... и даже на сегодня науке ХЗ из чего состоят кварки. Набор тел, в свою очередь, может образовывать некую макросистему. Задача "идентити" в модели — представить экземпляр некоей логической сущности как неделимое понятие, асбтрагировавшись от её устройства. Всё!

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

V>>ОК, Геометрическая оптика
S>Причем тут идентичность, казалось бы?

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

Это уже 80-й лвл по замыливанию темы.

V>>Асбтракция — это естественное для человека понятие, т.к. сам человек склонен мыслить абстрактно, выкидывая ненужные детали.
S>Ну т.е. уже переметнулся в мой лагерь и пытаешься меня из него выбить, будто так все и было...

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

V>>Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить?
S>Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?

Ес-но юлишь только ты, я готов подробно и терпеливо отвечать на что угодно. Конкретно здесь я тебе на это уже неоднократно возражал: если мы можем повторить все побочные эффекты без бэкдоров, то какая разница, что некий отдельный кусочек твоего кода чист? А вот ты, увы, на это ответить не смог ни разу. Ты лишь способен цепляться за тот факт, кто некая выделенная ф-ия в Хаскеле чиста. И, выждав паузу после очередного неотвеченного возражения, приводишь этот факт опять. Детсад... потому что дальше этого полный ступор в рассуждениях. Разве не видишь перехода от комбинации чистых ф-ий к точно таким же побочным эффектам, как в императиве? Это же простейший переход через трюк ассоциативности. Что здесь сложного?

Этот трюк в наверняка используется в любой более-менее большой программе многократно.

V>>Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.

S>Опять подмена тезиса

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

V>>Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.
S>Я не пытался это опровергнуть. Хорош спорить с голосами.

Ес-но пытался, но был пойман.

S>>>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.

V>>Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения?

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

Ты читать не умеешь? Как это в Хаскеле не записать if, если я же тебе и сказал, что в Хаскеле if представима в виде обычной ф-ии из-за ленивости?

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

S>>>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

V>>Ну побегай, побегай...
V>>А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. ))
S>Ты пиши, пиши, только смотри чем и что аргументируешь.

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

S>>>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.

V>>Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому.

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

Т.е. ты опять решил убежать? Но я тебе освежу. Я утверждал, что на if происходит та же механика в ФП, что в процедурном подходе (по фундаметальным причинам). Ты сначала пытался возразить, что не та же (как обычно, все возражение я в духе "неужели???" и смайлов

). А когда не смог доказать, то дважды повторил, что тебе это, оказывается, не интересно. Слабовато это как-то выглядит.

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

S>>>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.

V>>if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.
S>Нет, не десятое. Чистый statement в СП никому не нужен, ибо единственный эффект от него — счета за электричество.

Ну опять тебе двойка. Курить определение чистоты до просветления.
Вот тебе пример мутабельной ф-ии на С++, которая абсолютно чиста:

int sum(int a, int b, int c) {
  a += b;
  a += c;
  return a;
}

Я уже где-то рядом ловил тебя на том, что ты не понимаешь, что есть чистота вычислений. Собственно, о чем ты тогда спорил?

V>>>>Ну а остальное уже подытоживал:
V>>>>

V>>>>чистая ф-ия -> порядок вычисления аргументов не важен, так?

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

V>>Я не вижу, чтобы ты это показал для чистого ФП.
S>Я показал ложность твоего утверждения.

Еще раз, приведи такой пример, который, по твоим же словам:

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

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

S>>>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.

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

Акцент был на том, что это упорядочивание вычислений ОБЯЗАТЕЛЬНО, невзирая на всю чистоту. Поэтому и говорилось, что происходящее при ветвлении в ПП и ФП фактически не отличается (ньюансы мы уже обсуждали, в т.ч. ньюансы во время ленивости). Ты прекрасно вначале уловил акцент и оспаривал именно его в течении нескольких постов, пока не понял свою ошибку. Но теперь пытаешься вернуться к самому началу и пытаться начать цепляться к словам. Поздно, все ходы записаны. Я обещал показать аналогичное происходящее в ФП и ПП? — я показал. Будешь опять здесь юлить — попрошу "помощь зала" рассудить, делов-то. Увидишь во всей красе новую тему со всеми твоими цитатами в хронологическом порядке...

V>>Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо.
S>Я не отрицал упорядоченность.

Кто-то вскрыл твой аккаунт и писал от твоего имени?

S>>>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.

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

Легко. Курить историю IDL-языков.
Кстате, для начала даже саму аббревиатуру. ))

S>>>>>Что за "экземпляр" монады?
V>>>>Это такой функциональный объект.
S>>>Что за функциональный объект?

V>>Это пара { ф-ия, контекст }.
S>Выглядит как замыкание

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

S>>>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.
V>>>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?
S>>>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.

V>>Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
S>Значит опять невпопад.

Значит проблема с восприятием информации.

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

О! Таки перешел уже от утверждения абсолюта к обсужденю оттенков?
Молодец. Не прошло и сотни постов.

А я именно с этого начал.

Ну что, по новой с новым пониманием? Или ты и сам теперь можешь понять то, что я писал выше?

V>>Дык, это я же тебе и говорю, что тебя боле интересуют догмы. А меня интересует исключительно кач-во конечной программы. Поэтому я закоренелый циник. Мне все ср-ва хороши, если они работают.
S>Работают практически все средства. Но не все одинаково хороши. Во всяком случае для меня.

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

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

V>>Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...

S>Это не цинизм, это банальности. Извини, но мысли вроде "все равно ошибки будут" и "все программы грязны" немногого стоят.

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

Рядом я обсуждал, что именно было бы неплохо добавить в императивный ЯП, чтобы делать меньше тех самых ошибок. Я предлагал для С++ аналог pure из D. И заметь, что ФП в данном случае вообще никаким боком, бо функция/метод может быть чистым, он даже может изменять внешние (поданные по ссылке) данные, но при этом быть абсолютно pure. То бишь, легким движением руки я показывал, как можно преодолевать все "ужасы" императива, не плятя при этом высокую цену в виде ограничений, присущих "чистому ФП".

Здравствуйте, Ikemefula, Вы писали:

I>Цель у человека это не написание библиотеки

Если человек художник или повар — то цель у него, конечно, не написание библиотеки. Даже если человек программист, то цель у него, скорее всего не написание библиотек и даже не программирование как таковое. Но чтоб добится всех этих целей, программисту нужны, например, деньги, которые он зарабатывает. Как? Программированием! А программирование — это написание библиотек и/или "склеивание" их между собой. не обработка видео. Да, возможность хорошо "склеивать" библиотеки — это даже еще более важное свойство языка (есть же скрипты, которые для написания библиотек подходят плохо, а заточены исключительно на склеивание).

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

Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).

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

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

K>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>ну вот, "можем себе позволить" ты определил через "можем себе позволить"

Какие проблемы с пониманием смысла "что может себе позволить"? Допустим, что кто-то имеет желание купить дом, но не имеет возможности. Но имеет возможность купить козу, но не имеет желания. В вашем мире уже не надо пить за то, чтоб желания совпадали с возможностями, потому что вы их и так не различаете.

I>Передача вниз нужна для упрощения связывания

Что за "упрощение связывания" такое? Чего с чем? Понятно, что не кода с кодом — иначе вы защитили бы мою точку зрения. Вы ответте, как это помогает видео обрабатывать, ну или там уголь добывать. Какие еще перед программистами задачи стоят?

I>Разница между ними в том передача вниз безвредна для управления ресурсами и вычислениями и это вобщем то свойство этой самой передачи как способа использования а не замыканий.

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

I>Зеваю — лямбда-лифтинг в общем случае не поможет.

А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.

I>>>Внятно сказано — стек был и до алгола
K>>Где?

I>Мне не интересно, я показал тебе слова автора алгола, а ты думай сам.

У алгола больше авторов чем в "словах автора алгола" слов. Закавыченные слова без ссылки не интересны, реальный контрпример — наоборот — может изменить ход дискуссии.

K>>"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.
I>То есть, хаскель непригоден для решения таких задач, ЧТД.

Не подходит его имплементация. Вот авторы имплементаций C++ отлично понимали в чем тут разница, поэтому сейчас его имплементации для этих задач вполне подходят.

I>Я вобщем то и написал что это одно и то же. А то что свойства различные если по разному использовать — так это и ежу понятно, то есть разница в свойствах операций а не самих замыканий. Операции — передача ввехр или вниз.

Вы тут противоречия не видите? Например, между "одно и то же" и "есть разница"?

I>>>Пустой контекст это просто конкретный случай а не новое понятие.
K>>Новое понятие, которое вы вводите, для объединения замыкания с "не замыканием" — действие не только бесполезное, но и вредное, согласно вашему же обоснованию.
I>Выделеное прочесть не алё?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>Это тебе хочется назвать это доменом.

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

I>Я специально использовал слово "задачи" да во множественном числе что бы дистанцироваться от конкретного домена.

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

Это все нас возвращает к вопросам:
Из предложения

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

следует связь: задача A -> язык A, задача B -> язык B. Но практике такого не наблюдается.
Под какие задачи проектировался C++? Под все, для решения которых он применяется? Если нет, то почему применяется и для тех, под которые он не проектировался? И почему для решения тех, под которые он проектировался, применяют и другие языки? Как получается, что фичи подбираются под задачу, а для решения одной и той же задачи применяют языки с разными фичами?

I>НАпример в С++ можно управлять ресурсами,

Это та самая вышеупомянутая задача бизнеса, надо полагать?

I>обрабатывать данные — опаньки

Я, честно говоря, не представляю, как можно решать какие-то проблемы с помощью программирования, но не обрабатывать при этом данные.

I>один язык для минимум для двух разных доменов. При этм "определенные задачи" смысла не теряет в отличие от "домен".

Если домен теряет, а "определенные задачи" — не теряет, то это может быть только в одном случае: "задача" — специальное слово, которое ни в коем случае не означает "домен", но может и будет означать все что потребуется для сохранения видимости смысла.

Т.е. фактически ваш тезис теперь можно без потери смысла записать

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

Прозреваю, что если у обеих сторон хватит упрямства (за себя не ручаюсь) вы будете отступать вплоть до точки

сепулька сепулируется ... под сепульные сепульки которые могут сепулить, а могут и не сепулить сепульные сепульки

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.

SV.>На протяжении долгих лет я встретил ровно одного человека, который излагал (насколько я его понял) то же самое — Эрика Липперта. По удивительному совпадению (это сарказм), кокреатора одного из лучших языков — C#, а также отца Roslyn. На следы жизнедеятельности таких людей я натыкался чаще (взять тот же .NET FCL), но не сильно. Так вот, не дайте угаснуть моей вере в человечество или добейте ее окончательно.

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

Здравствуйте, Abyx, Вы писали:

A>да, мало людей понимает ООП.
A>есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код,
A>и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код.
Я скажу проще: мало людей умеет хорошо программировать.
Хороший программист сделает понятным код и с ООП и без него.
Плохой программист сделать непонятным код и с ООП и без негою

Здравствуйте, 0x7be, Вы писали:

A>>есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код,
A>>и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код.
0>Я скажу проще: мало людей умеет хорошо программировать.
0>Хороший программист сделает понятным код и с ООП и без него.

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

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

Здравствуйте, 0x7be, Вы писали:

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

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

попытка применить чистые функции выродится в вызовы
data1, data2, data3 = some_pure_fn(data1, data2, data3)
итого мы получим кучу мелких чистых функций и другую кучу не-чистых функций

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

пример из реальной жизни — файлы, сокеты и другие источники/приемники данных

Здравствуйте, A13x, Вы писали:

A>Функциональное программирование позволяет более понятно и просто решать некоторый класс задач:

A>

A>When you anticipate a different kind of software evolution:

A>Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.

A>Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.

A>Примеры достаточно хорошо изложены в SICP (я его читал не весь) из которого запомнилось подход к написанию кода, выполняющего символьное диффиренцирование.

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

вот и работает ФП только для задач типа символьного дифференцирования,
а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++

Здравствуйте, SV., Вы писали:

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

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, A13x, Вы писали:

A>>Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.

S>В джава нет полной поддержки концепции замыканий и нет никакого линка. И тем не менее это самый популярный язык на планете.

К слову, Jetbrains, собаку съевшая на яве, сейчас активно делает Kotlin, а так же развивает MPS.

И я не спорю, что ООП — это плохо, а ФП — панацея, просто есть разные случаи, когда к месту разные инструменты.

Здравствуйте, 0x7be, Вы писали:

SV.>>Просто потому, что мы мыслим объектами.
0>А это точно правда?

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

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, 0x7be, Вы писали:

SV.>>>Просто потому, что мы мыслим объектами.
0>>А это точно правда?

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

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

A>вот и работает ФП только для задач типа символьного дифференцирования,
A>а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++

У нас вот, 100 человек функционально все описывают. Что мы делаем не так?

Здравствуйте, grosborn, Вы писали:

>> А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

G>С какого перепугу наследование стало ближе к предметной области, чем к примеру копипастинг? Если бы интерфейсы можно было бы произвольно комбинировать и декомбинировать, это было бы ближе, но наследование и подгонка предметной области под наследование это клиника.

Если оно там (в предметной области) присутствовало изначально, значит ближе. Если изначально присутствовал копипакостинг, значит, ближе он.

Хотя ситуация вымышлена, пример самый настоящий:

// Any protocol supports plain text.
interface IMessenger
{
    void SendMessage(string text);
}

// No protocols support file transport only. If there is one, the contract is not valid anymore.
interface IFileSender : IMessenger
{
    void SendFile(File file);
}

class SkypeMessenger : IFileSender; // It's easy to support both text and file sending via Skype.
class SmsMessenger : IMessenger; // ...But not via SMS.

class MyApp : Application
{
...
    void SurpriseAdminInChief(IFileSender messenger)
    {
        messenger.SendFile(_dumpFile);
        messenger.SendText(_criticalErrorMessage); // We are absolutely sure we can send text if we can send files.
    }

    void SurpriseApprenticeAdmin(IMessenger messenger)
    {
        messenger.SendText(_warningMessage);
    }
    ...
}

Что он отражает? Он отражает наши представления о мессенджерах. Допустим, это плохие, негодные представления. Мессенджеры так себя не ведут. Ладно, но вы же ВСЁ ПОНЯЛИ, что было в голове у архитектора? В этом и суть.

Мой (воображаемый) собеседник предложил использовать вот такую штуку, исключающую необходимость в наследовании:

void SurpriseAdminInChief<T>(T messenger) where T : IFileSender, IMessenger

И предсказуемо сломался на простом вопросе: как построить плагинную архитектуру, когда одни реализуют обертки над SMS-гейтами и скайпами, другие их используют, а ты должен написать базовое приложение, которые не допустит конфликтов. Что если первый плагин вернет реализацию ТОЛЬКО IFileSender, а второму подавай оба? Ах, еще раз писать where T? Ну, это и будет поддержка ОБЪЕКТИВНОГО (не объектного) наследования, выполненная самым кривым и неочевидным способом. Да, можно, конечно, и так, но ЗАЧЕМ?

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

Здравствуйте, Mamut, Вы писали:

SV.>>Просто потому, что мы мыслим объектами.

M>Оставлю тут: Execution in the Kingdom of Nouns

Автор простую мысль — заставь дурака богу молиться — размазывает по пяти страницам.

Лично мне Ява никогда не нравилась как раз поэтому: будучи формально весьма объектно-ориентированным языком, она утратила дух ОО напрочь. Когда нам нужен предикат или обработчик события, нормальный человек обычно пропускает их абстрагирование и переходит к сути. Нет, это, конечно же, объекты, имеющие общие свойства, мы должны иметь возможность посмотреть на них под таким углом, например, когда мы занимаемся сугубо административной деятельностью, типа раздачи указаний и их ведения в органайзере. Но такой взгляд нам нужен нечасто. Ява, которая заставляет помнить об этом ВСЕГДА, меня дико напрягает. Посмотрите на C# с его лямбдами.

Так вот, когда ООП применяют не по делу, это говорит о том, что его плохо понимают. Почему я и сказал, что нет в Яве духа ООП.

Да, самое главное. Надо помнить, что эволюция идет постепенно. Может быть, через пару лет и в Яве будет все в порядке с обработчиками и предикатами. А вот если они упрутся, и по идеологическим причинам не станут их вводить, тогда и скажем — заставь дурака...

Здравствуйте, Artifact, Вы писали:

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

Моя первая программа решала квадратные уравнения и работала на МК-52. Сначала требовалось ввести коэффициенты при членах, потом она выводила дискриминант и корни (или гогу). По замыслу создателя, она должна была облегчать школьные будни, но пока пять километров в ~~гору~~ школу зимой... сами понимаете, ППЗУ не было рассчитано на сибирские морозы. Каждый раз с утра приходилось набивать листинг заново, пока не затрахало. Основана программа была на перемещениях значений из одних ячеек памяти в другие. Такой там был подход. Если только склероз меня не подводит.

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

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, SV., Вы писали:

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

0>Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?

Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

Здравствуйте, Abyx, Вы писали:

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

A>попытка применить чистые функции выродится в вызовы
A>data1, data2, data3 = some_pure_fn(data1, data2, data3)
A>итого мы получим кучу мелких чистых функций и другую кучу не-чистых функций
И? "Куча мелких чистых функций" — это однозначно хуже, чем "стопка крупных грязных классов"?

A>попытка применить процедурный подход сведется к использованию абстрактного типа данных, т.е. ООП.
Поскольку
Разве "ADT" == "OOP"?
Зачем тогда выдумывать новый термин "ООП"?

A>пример из реальной жизни — файлы, сокеты и другие источники/приемники данных

Здравствуйте, Mamut, Вы писали:

A>>вот и работает ФП только для задач типа символьного дифференцирования,
A>>а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++

M>У нас вот, 100 человек функционально все описывают. Что мы делаем не так?

а кто-то на асме код пишет, и что?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Steamus, Вы писали:

S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

IT>Понятие?

Форма мысли, Общая идея.

Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Steamus, Вы писали:

S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
0>"Нечто"

0>А теперь объясни, что именно ты пытался доказать этим вопросом?

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

Здравствуйте, Steamus, Вы писали:

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

M>>У нас вот, 100 человек функционально все описывают. Что мы делаем не так?

A>а кто-то на асме код пишет, и что?

И то. Что твое заявление о неприспособленности ФП для реальной жизни, мягко говоря, смешно.

S>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

Время?
Категория?

Здравствуйте, IT, Вы писали:

IT>Осталось только купить икону и молиться святой троице, наследованию, инкопсуляции и полиморфизму, за спасение душ невоООПленых.
А как быть с CLOS-еретиками? Сжечь FOR TEH EMPEROR?

Здравствуйте, Wolverrum, Вы писали:

S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

W>Время?
Измерение
W>Категория?
Элемент классификации

Здравствуйте, 0x7be, Вы писали:

IT>>Осталось только купить икону и молиться святой троице, наследованию, инкопсуляции и полиморфизму, за спасение душ невоООПленых.
0>А как быть с CLOS-еретиками? Сжечь FOR TEH EMPEROR?

Понять и простить.

Здравствуйте, Steamus, Вы писали:

S>>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
IT>>Понятие?
S>Форма мысли, Общая идея.

Это не более высокое понятие, а описание.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Steamus, Вы писали:

S>>>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
IT>>>Понятие?
S>>Форма мысли, Общая идея.

IT>Это не более высокое понятие, а описание.

Форма мысли — описание? То есть вы искренне полагаете, что от того что я сходу не нашёл более удачного термина, то это слово является венцом цепочки абстракций? Вроде же моя мысль понятна, что сказать хотите?

Здравствуйте, Steamus, Вы писали:

IT>>Это не более высокое понятие, а описание.
S>Форма мысли — описание?

Описание, определение, то, через что можно описать понятие 'понятие'. Базовой абстракции здесь пока не просматривается.

S>То есть вы искренне полагаете, что от того что я сходу не нашёл более удачного термина, то это слово является венцом цепочки абстракций? Вроде же моя мысль понятна, что сказать хотите?

Я задал вопрос и пока не получил на него внятного ответа.

ЗЫ. Я могу ещё понапридумывать подобных существительных. Взять хоты бы объект или информация. Много их.

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

Здравствуйте, IT, Вы писали:

IT>ЗЫ. Я могу ещё понапридумывать подобных существительных. Взять хоты бы объект или информация. Много их.

Их нет вообще. Есть тезаурус конкретного человека. Плохо, если вы не можете придумать абстракции для ходовых слов. Впрочем, всегда можно застолбить что-то типа — "Самая верхняя абстракиця!"

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>То есть, к счастью, некие вещи таки устоялись в трёх мейнстримовских языках (Java, C++, C#). Класс/тип — чистая ментальная абстракция. Объект — осязаемый экземпляр класса, который вы создаёте (инстанциируете) когда нужно. Нет никаких догадок и автоматических инстанциаций. Классы могут наследоваться. Это абсолютно естественно, если отражает реальную модель мира, а не удобный способ "зацепить" функциональность.

S>А что такое "реальная модель мира"?

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

PS: Но всегда найдется придурок, который возразит — а вдруг бухгалтер надышится парами плёнки покрывающей стол и вся бухгалтерия ляжет?! Нет-нет, ваше ООП определённо гамно...

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>А что такое "реальная модель мира"?

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

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

S>PS: Но всегда найдется придурок, который возразит — а вдруг бухгалтер надышится парами плёнки покрывающей стол и вся бухгалтерия ляжет?! Нет-нет, ваше ООП определённо гамно...
Тут дело даже не в ООП, а в том что всегда найдется придурок, который скажет что ваше ХХХ определенно гамно, что бы там ни было. Но это банальность.
Давайте лучше поговорим об отношении ООП к некой модели, отражающей реальный мир с достаточной точностью, необходимой для решения конкретной задачи.

Здравствуйте, Steamus, Вы писали:

S>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.
Это, мягко говоря, смелое допущение.
Его бы надо научно обосновать.

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

Это аргументация такая?

Здравствуйте, elmal, Вы писали:

E>Относительно ООП. Вот для меня что то в последнее время основное — чтобы поменьше писать кода, чтоб поменьше волноваться при очередных внезапных изменениях требований перед релизом. И у меня ООП, ФП и другие подходы служат одной основной цели — чтоб не копипастить, ибо если я начну такое делать, потребуется в 10 раз больше людей на развитие проекта.

Т.е. ООП, ФП и другие подходы для тебя просто инструменты для достижения определённых целей? А твоя цель — "чтоб не копипастить"?

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, Wolverrum, Вы писали:

S>>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

W>>Время?
S>Измерение
Это только в физике и около нее.
Кстати, даже в физике — что там насчет абстрагирования понятия ПВМ (ПВ-многообразия)?

W>>Категория?
S>Элемент классификации
"Категория — наиболее общее или специальное априорное понятие, используемое при построении теорий"

Пока что пролёт с абстракциями. Давай еще позащищай ложь.

Здравствуйте, IT, Вы писали:

IT>Т.е. ООП, ФП и другие подходы для тебя просто инструменты для достижения определённых целей?
Создать из подхода/методологии секту прикажешь?

Здравствуйте, Wolverrum, Вы писали:

IT>>Т.е. ООП, ФП и другие подходы для тебя просто инструменты для достижения определённых целей?
W>Создать из подхода/методологии секту прикажешь?

Нет.

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, Wolverrum, Вы писали:

S>>>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.

W>>>Время?
S>>Измерение
W>Это только в физике и около нее.
W>Кстати, даже в физике — что там насчет абстрагирования понятия ПВМ (ПВ-многообразия)?

W>>>Категория?
S>>Элемент классификации
W>"Категория — наиболее общее или специальное априорное понятие, используемое при построении теорий"

W>Пока что пролёт с абстракциями. Давай еще позащищай ложь.

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

Здравствуйте, SV.
SV:

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

SV.>...и это невероятно печально.
Это невероятно нормально, потому что:
ООП — это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

ЗЫ Вот Вы так о духе ООП категорично рассуждаете, а свой сайт на php написан... И тормозит. Если первое простительно то второе на фоне рассуждений кажется неприемлемым.

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, SV.
W>SV:
W>

W>Надо признаться себе, наконец, в том, что все эти вещи, которыми так гордится современная молодежь – автоматический контроль памяти, суперстрогая типизация, встроенный компилятор и обработка исключений – это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

SV.>>...и это невероятно печально.
W>Это невероятно нормально, потому что:
W>ООП — это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

W>ЗЫ Вот Вы так о духе ООП категорично рассуждаете, а свой сайт на php написан... И тормозит. Если первое простительно то второе на фоне рассуждений кажется неприемлемым.

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

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

Здравствуйте, samius, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>Предлагаю провести мысленный эксперимент. Двум тысячам одинаковым неглупым людям, девственным в программировании, поставим одинаковый набор задач, но разные учебники программирования. Половине букварь по ООП, другой — букварь по ФП. Каковы ваши ставки? Если вы считаете что ООП-шники напишут быстрее/качественнее и т.п. просто потому что мозги практикуют именно ООП, то к чему опять-таки тема про то как мало людей понимает ООП.

Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.
Эрланг, Хаскель и Лисп, так любимые ботаниками-маргиналами, далеко в аутсайдерах. Но, их нежно и с любовью пользуют там где они уместны. Давно уже не рассуждая об этих вещах. И тактично обходя любые дискуссии, дабы не задеть легкоранимое самолюбие кухонных теоретиков от ФП, давно и основательно дистанцировавшихся от реальной жизни.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>>>Предлагаю провести мысленный эксперимент. Двум тысячам одинаковым неглупым людям, девственным в программировании, поставим одинаковый набор задач, но разные учебники программирования. Половине букварь по ООП, другой — букварь по ФП. Каковы ваши ставки? Если вы считаете что ООП-шники напишут быстрее/качественнее и т.п. просто потому что мозги практикуют именно ООП, то к чему опять-таки тема про то как мало людей понимает ООП.

S>>Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.

S>Вы уверены что большинство C++/Java/C# программистов прочитало хотя бы один букварь по ФП? Я не уверен.

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

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

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, A13x, Вы писали:

A>>>Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.

S>>В джава нет полной поддержки концепции замыканий и нет никакого линка. И тем не менее это самый популярный язык на планете.

A>К слову, Jetbrains, собаку съевшая на яве, сейчас активно делает Kotlin, а так же развивает MPS.

A>И я не спорю, что ООП — это плохо, а ФП — панацея, просто есть разные случаи, когда к месту разные инструменты.

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

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

S>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

Здравствуйте, IT, Вы писали:

IT>Другими словами твоя цель — контроль над сложностью проекта. Остальное побоку. Я прав?
Угу. А что, могут быть другие цели

? Типа фен шуй рулит

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>>Здравствуйте, samius, Вы писали:

S>Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.

широко используется си (без плюсов). широко используется питон (на нем вроде как ютуб частями написан). широко используются JS и AS.

Здравствуйте, 0x7be, Вы писали:

0> с тем ООП, которое мы наблюдаем в нынешнем мэйнстриме.

а мне вот больше нравится реализация ооп в MASM'е — вот там чистейшее ооп.

Здравствуйте, Mamut, Вы писали:

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

Правильно — воздержись.

Здравствуйте, Steamus, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>>Любой чел, который не спал последние 10 лет, хорошо знает, что этот эксперимент, совсем даже не мысленный, а чётко осязаемый, поставила сама жизнь. И в нём, со счётом миллион к одному, выиграли C++, Java и C#.

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

S>Рад, что оправдал Ваши ожидания, но я тут (и не только тут) уже столько написал, что упрекать меня в том, что я чего-то там где-то избегаю — просто неприлично.
Вместо аргументации одного сомнительного тезиса вы приводите другой сомнительный тезис. А вместо его аргументации следуют эпитеты. Когда я вам указываю на противоречия, вы их скипаете. Имхо, упреки справедливы.

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

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Mamut, Вы писали:

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

Мдя...

Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.

SV.>Примеры. Допустим, некто спрашивает, зачем нужно наследование интерфейсов. Я привожу пример, когда оно нужно. В ответ приводится пример, как то же самое можно сделать без наследования интерфейсов. История, конечно, вымышлена, все возможные совпадения случайны. Как хотите, а для меня такой ответ — признак полнейшего непонимания ООП. Оно нужно не потому, что без него не обойтись, и не потому, что сокращает количество кода, и не потому, что что-то там гарантирует (на любую хитрую жопу, как известно всегда что-нибудь найдется). Любой ОО-код переписывается в процедурный роботом на автомате. Не говоря про машину Тьюринга. А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

SV.>Другой пример. Когда я обсуждал эту (конечно же, чисто гипотетическую) ситуацию, один человек прямо сказал: все дело в бэкграунде. У тебя, грит, оопный бэкграунд, а придет нуб с функциональным бэкграундом и скажет — ни хрена непонятно. А были бы, грит, чистые функции, он бы все понял мгновенно. И такое высказывание для меня другой признак непонимания ООП. Во-первых, ООП не находится в антагонистических отношениях с ФП. Они отлично уживаются, просто потому, что нужны в разных местах. Во-вторых, НЕТ, НЕПРАВДА, с любым бэкграундом (ФП, ООП, лапша) проект, выдержанный в ОО-духе понять легче. Просто потому, что мы мыслим объектами.

SV.>На протяжении долгих лет я встретил ровно одного человека, который излагал (насколько я его понял) то же самое — Эрика Липперта. По удивительному совпадению (это сарказм), кокреатора одного из лучших языков — C#, а также отца Roslyn. На следы жизнедеятельности таких людей я натыкался чаще (взять тот же .NET FCL), но не сильно. Так вот, не дайте угаснуть моей вере в человечество или добейте ее окончательно.
Какая цель топика? Повозмущаться существованием в природе всяких уродов? Ну дальше что? Сам без греха? А ну ка быстро кинул в меня стотонный камень.

Здравствуйте, 0x7be, Вы писали:

S>>Назовите какое-нибудь, хотя бы одно, существительное для которого нет более высокого абстрактного понятия.
0>"Нечто"

Это не существительное, это местоимение.

S>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно, соответственно моделирование/проектирование/реализацию системы разумнее вести с учётом этой особенности мозга.

Нуну. А банальное «открыть дверь» ты так и не смог описать так, чтобы оно легло на реальную жизнь.

Здравствуйте, samius, Вы писали:

S>ИОткрывашка
ТКласс!

Здравствуйте, D. Mon, Вы писали:

DM>Это не существительное, это местоимение.
В именительном и винительном падежах "нечто" применяется как существительное.

Здравствуйте, Mamut, Вы писали:

S>>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно, соответственно моделирование/проектирование/реализацию системы разумнее вести с учётом этой особенности мозга.

M>Нуну. А банальное «открыть дверь» ты так и не смог описать так, чтобы оно легло на реальную жизнь.

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


class Дверь {
  открыть();
  закрыть();
};

Дверь дверь = new Дверь();

дверь.открыть();
дверь.закрыть();

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, Steamus, Вы писали:

S>>Моя мысль проста как слеза — мозг мыслит объектно

W>Мысль простая... и ложная.

W>Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.

Да. Это я неправильно сказал употребив фразу ...мозг работает... Никто не знает как он там себе работает. Скажем так, было замечено, что для понимания проблемы мозг "опускает" незначащие детали и оперирует только теми, которые важны для понимания проблемы. То есть делает некое абстрагирование, декомпозицию.

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

Расскажи об открытии двери так, чтобы это легло на существуюзую ООП-парадигму и продолжало отражать реальный мир

Здравствуйте, 0x7be, Вы писали:

DM>>Это не существительное, это местоимение.
0>В именительном и винительном падежах "нечто" применяется как существительное.

Оно в других не применяется просто. А вместо существительного — так на то оно и местоимение.

Здравствуйте, SV., Вы писали:
SV.>...Просто потому, что мы мыслим объектами.
На самом деле люди мыслят нервными импульсами "странствующими" по нейросети мозга. "Люди мыслят объектами" лишь теория(теоретическая модель) пытающаяся объяснить мышление на чуть более высоком абстрактном уровне(по отношению к нейросети), на подобии теории относительности Эйнштейна, питающейся объяснить чево-то там в физике. Чтобы извлечь из этой(и любой другой) т.модели максимальную пользу нужно пройти три этапа её изучения: узнать -> понять -> научится использовать.
-------------------
ООП даже в чистом виде, понять не так то просто(по сравнению например с ИмперативнымП),потому что:
1)IRL люди очень редко используют такие высокоабстрактные понятия как "объект","класс" etc., т.к. больше взаимодействуют с конкретными вещами. Из-за чего им сложно представить объект как собственно "объект" а не как нечто конкретное.
2)IRL людям редко приходится абстрагировать/классифицировать, в большинстве случаев используются готовые классификации и абстракции.
3)IRL люди не очень часто используют композицию-декомпозицию, а это ключевые навыки для любого конструирования(не столько программ).
4)IRL люди не часто пользуются воображением, дающим возможность представить нечто одно как нечто другое, например представить габариты здания как структуру из трёх переменных.
Все эти(а может быть и не только эти) скиллы требуют серьёзной прокачки только для того чтобы человек смог собрать что нибудь из набора готовых ООП объектов(как например в QT конструкторе можно складывать простенькие приложения), ну а осилить магию превращения объекта реальности в конструкцию из методов и свойств, та ещё задача.
Но я так-же считаю что, не смотря на высокий порог вхождения(возможно даже более высокий чем у ФП), на сегодня ООП наиболее мощная из реально используемых парадигм.
-------------------
Тем не менее, ООП должно умереть!

SV.>Да, самое главное. Надо помнить, что эволюция идет постепенно. Может быть, через пару лет и в Яве будет все в порядке с обработчиками и предикатами. А вот если они упрутся, и по идеологическим причинам не станут их вводить, тогда и скажем — заставь дурака...

В Java 8 лямбды будут. И много чего еще.

Здравствуйте, D. Mon, Вы писали:

DM>Оно в других не применяется просто. А вместо существительного — так на то оно и местоимение.
Все это круто, конечно, только что это означает в контексте обсуждаемого вопроса?

Здравствуйте, Mamut, Вы писали:

S>>>>Ещё раз — я нигде не говорил, что ФП это плохо. Моя мысль проста как слеза — мозг мыслит объектно, соответственно моделирование/проектирование/реализацию системы разумнее вести с учётом этой особенности мозга.

M>>>Нуну. А банальное «открыть дверь» ты так и не смог описать так, чтобы оно легло на реальную жизнь.
pkl>>А чё там сложного? Дверь — это не объект штоле?

M>Ну, давай дальше. Напомню утверждение
M>

M>человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

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

M>>Расскажи об открытии двери так, чтобы это легло на существуюзую ООП-парадигму и продолжало отражать реальный мир
pkl>Дверь — объект, может находиться в разных состояниях. Всё.

Нет, далеко не все. Процесс открывания двери ты так и не описал

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

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

Ссылку Executin in the Kingdom of Nouns я не зря здесь оставляю. Далеко не все в нашем мире и мышлении отталкивается от существительных.

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

S>>>


S>>>дверь.открыть();
S>>>дверь.закрыть();

S>>>

M>>Только это даже близко не относится к реальному миру. Потому что ты считаешь, что действие по открыванию двери принадлежат двери. Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

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

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

Ставлю тебе задачу:

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

Здравствуйте, Mamut, Вы писали:

M>>>Расскажи об открытии двери так, чтобы это легло на существуюзую ООП-парадигму и продолжало отражать реальный мир
pkl>>Дверь — объект, может находиться в разных состояниях. Всё.

M>Нет, далеко не все. Процесс открывания двери ты так и не описал
А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

S>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

Только в реальной жизни они этих предков не имеют, вот ведь засада.

Здравствуйте, BrainSlug, Вы писали:

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

Давайте уже сразу с этим покончим — Господь Бог!

S>Давайте уже сразу с этим покончим — Господь Бог!
это не понятие. это существительное , которое является обозначением для http://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B3 . Читаем определение http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B5

S>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

А вы в кусрес, что в реальной жизни таких предков не существует?

S>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>Только в реальной жизни они этих предков не имеют, вот ведь засада.

S>О нет, в реальной жизни они оч-чень даже имеют этих предков.
[skipped]

Ах, сколько слов ни о чем. Только вот «открыть дверь» не имеет отношения ни к «ДыреВСтене», ни к «ЭлементуИнтерьера» ни к любой другой фантазии.

Опять всё что ООП не имеет отношения к жизни? Да забросьте вы свой дебильный Эрланг и оглянитесь вокруг... Как свободный человек.

Здравствуйте, Mamut, Вы писали:

S>>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

M>А вы в кусрес, что в реальной жизни таких предков не существует?
1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.
2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП. Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

Здравствуйте, Steamus, Вы писали:

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

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

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

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

S> Это некие такие омонимы. Омонимизм не повод для того, что бы помещать действие в одну иерархию.
хорошо, вот такой пример. рыбалка и пикап -- это разные понятия или нет? понятия разные, а последовательность действий очень близка. выйти на озеро/парк культуры, закинуть наживку/наживку, ждать по не клюнет. как клюнуло -- подсекай/тащи в постель.

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

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

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

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

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

Здравствуйте, Mamut, Вы писали:

S>>


S>>class Дверь {
S>>  открыть();
S>>  закрыть();
S>>};

S>>Дверь дверь = new Дверь();

S>>дверь.открыть();
S>>дверь.закрыть();

S>>

class Programmer
{
    open(Openable obj);
}

Programmer mamut = new Programmer();
mamut.open(fridgeDoor);
mamut.takeOut(beerBottle);

Так сойдет?

Здравствуйте, femidav, Вы писали:

F>Здравствуйте, Mamut, Вы писали:

F>Programmer mamut = new Programmer();
F>mamut.open(fridgeDoor);
F>mamut.takeOut(beerBottle);

F>Так сойдет?
вношу правку:
mamut.takeOut(beerBottle).open();

исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....

Здравствуйте, мыщъх, Вы писали:

М>вношу правку:
М>mamut.takeOut(beerBottle).open();

М>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....

а что должен возвращать метод takeOut()
?

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, мыщъх, Вы писали:

М>>вношу правку:
М>>mamut.takeOut(beerBottle).open();

М>>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....
Ф>а что должен возвращать метод takeOut()
очевидно beerBottle. что еще он может возвращать?

это слегка иной тип наследования, но он очень удобен.
mamut.takeOut(beerBottle).open().drink().throw_out()

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, мыщъх, Вы писали:

М>>>вношу правку:
М>>>mamut.takeOut(beerBottle).open();

М>>>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....
Ф>>а что должен возвращать метод takeOut()
М>очевидно beerBottle. что еще он может возвращать?

да, точно, сорри
это было вполне логично

Samius> если табуретку намочить (или покрыть огнеупорным составом), то она внезапно поменяет базовый класс.
Принцип неопределенности базового класса

Mamut> Открыть дверь
Система "Открыватель — Дверь" находится в запутанном состоянии

SV> Как мало людей понимает ООП
Квантовые явления вообще мало кто хоть как-то заметно хорошо понимает

F>class Programmer
F>{
F>    open(Openable obj);
F>}

F>Programmer mamut = new Programmer();
F>mamut.open(fridgeDoor);
F>mamut.takeOut(beerBottle);
F>

F>Так сойдет?

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

M>>>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>>>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

M>>А вы в кусрес, что в реальной жизни таких предков не существует?
pkl>1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.

Кхм. То есть еще есть идеальный мир?

pkl>2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП.

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

pkl>Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

Рассмотрели. Дальше что?

M>>Ах, сколько слов ни о чем. Только вот «открыть дверь» не имеет отношения ни к «ДыреВСтене», ни к «ЭлементуИнтерьера» ни к любой другой фантазии.

S>Что, правда?

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

M>>И не имеет никакого отношения к реальной жизни.

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

Эта твоя модель никакого отношения к действительности не имеет.

Здравствуйте, Mamut, Вы писали:

M>>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

M>Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.
Зачем повторяться всяким бредом?

Здравствуйте, Mamut, Вы писали:

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

Так это без нас произошло. Нам надо только описать состояние двери (открыта). Мы же управляем сквозняком только косвенно, значит можем максимум сказать создатьСквозняк, а уж что он там наломает...

Здравствуйте, Steamus, Вы писали:

S>Давайте уже сразу с этим покончим — Господь Бог!
Полагаю, это надо читать как:

"Давайте уже сразу с этим покончим"
— Господь Бог.

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

Здравствуйте, Философ, Вы писали:

Ф>учитывая последнее получаем:
Ф>mamut.takeOut(beerBottle).open(beerBottle);

try {
    mamut.open(fridge);
    mamut.drink(mamut.takeOut(fridge, beerBottle));
}
catch(CapacityExceededException e) {
    mamut.runToBath();
    mamut.throwUp();
}

Исключение кидает само-собой мамут, а не бутылка. Хотя если из mamut.open(fridge) вернуть холодильник, то мы очень близко подойдем к функциональному стилю:

    mamut.drink(mamut.takeOut(mamut.open(fridge), beerBottle));

тут уже один шаг до

    drink(takeOut(open(mamut, fridge), beerBottle));

Дело вкуса, короче...

Сокращение к-ва кода это довольно однобокое понимание ООП.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Внимание, ставлю вам задачу – сколько времени пройдет, пока нормальный здоровый мозг, выделит общий класс ‘Полено’ из табуретки, полки и акустической системы Танной 1972 года? И при какой температуре окружающей среды это произойдёт. Влияет ли температура окружающего воздуха на способность мозга к обучению абстрагированию/выделению общих сущностей?

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

Зачем мочить? Можно просто сжечь. И она поменяет свой статус.

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

Здравствуйте, Mamut, Вы писали:

F>>

F>>class Programmer
F>>{
F>>    open(Openable obj);
F>>}

F>>Programmer mamut = new Programmer();
F>>mamut.open(fridgeDoor);
F>>mamut.takeOut(beerBottle);
F>>

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

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, мыщъх, Вы писали:

М>>Здравствуйте, Философ, Вы писали:

Ф>забавно всё это.
Ф>после takeOut() мы имеем систему beerBottle<->mamut
Ф>и это поинтереснее выключателя для лампочки.
Ф>Мамут здесь, например может эту самую бутылку швырнуть в оппонента.
Ф>Запишем, как бутылка.швырнись()???

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

вообще, объекту "мамут" необходим пул объектов, которые можно швырнуть. и метод "швырнуть" выбирает из них наиболее подходящий.

Ф>учитывая последнее получаем:
Ф>mamut.takeOut(beerBottle).open(beerBottle);
Ф>и всё равно меня смущает beerBottle в конце этой строки
Ф>mamut.takeOut(beerBottle).OpenCapacity()
вот примерно это я и предлагаю -- open может принимать в качестве аргументов как открыть, таймайт (в смысле как долго отрывать, прежде чем плюнуть и решить, что завтра докуем).

меня коробит, когда в питоне приходится писать f = open("demo.txt", 'rb');
путем легкой химии превратил это в f = "demo.txt".fopen('rb'). так красивше ИМХО.

суть в том, что теперь у меня работает это:
['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen()

и оно возвращает список открытых файловых объектов,

соотвественно:
['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen().fread()

возвращает список прочитанных данных. но это фигня, это только "сахар", а вот:

for lines in ['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen()
print lines

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

Ф>земля.Копайся()

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

Здравствуйте, samius, Вы писали:

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

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

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>Для выражения ИМХО и не требуется ничего такого приводить. Приводи в ответ своё ИМХО... Правда, тут такой прикол, что как раз отрицание чужого ИМХО потребует аргументов. Не обратил внимание, что тем ИМХО и отличается от безусловной подачи информации, что нападающие и защищающиеся меняются в споре меняются местами? У тебя сейчас не было оснований для нападения, поэтому нападки выглядят криво... А в каче-ве защиты твоеё т.з. пост откровенно слаб... Потому что не был заточен заточен под защиту твоего ИМХО, очевидно.
Надеюсь, это было твое ИМХО

S>>Т.е. то что мозг мыслит объектно, выдвигается вами за постулат. Причем, выглядит это так, что утверждение абсолютно. Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

V>Вообще-то да. Несмотря на хорошо понимаемую нашим братом-программистом бесконечность и непрерывность числового ряда, каждое конкретно взятое число мы представляем себе как отдельный объект. Взять те же самые значения временных переменных при вычислении факториала...
Мы вообще-то говорили об ООП. Это на тот случай, если ты решил контекст восстановить по одному лишь моему сообщению. В рамках того контекста, в котором я тут общаюсь, я делаю предположение о том что твое ИМХО считает что все, где встречается упоминание числа либо какой-то величины, можно смело относить к ООП...

V>==============
V>Ну ты понял как надо будет строить возражение, если тебе захочется его строить.

Я не рассчитывал что ты влезешь с середины и не поймешь о чем речь (или сделал вид что не понял).

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

S>>40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.
S>Вот как раз демонстрация вашей наблюдательности. Я вижу там лишь 2 плюса на текущий момент.

Я не очень силён в непонятной системе оценок RSDN. Я увидел вес 40 и решил что так. Полагаете, что это двое челов нафигачили столько любви? Или вы не видите что сообщение имеет вес 40?

http://www.rsdn.ru/forum/philosophy/4834049.1.aspx

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

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

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

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

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

Здравствуйте, Steamus, Вы писали:

S>Причём тут вообще ООП? ООП — это методологический подход, построенный на декомпозиции задачи/системы с целью снижения её сложности.
То же самое можно сказать и почти про все другие парадигмы программирования.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Steamus, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>>>Вот как раз демонстрация вашей наблюдательности. Я вижу там лишь 2 плюса на текущий момент.

S>>Я не очень силён в непонятной системе оценок RSDN.
S>Имхо, не только в ней
S>>Я увидел вес 40 и решил что так. Полагаете, что это двое челов нафигачили столько любви? Или вы не видите что сообщение имеет вес 40?

S>>http://www.rsdn.ru/forum/philosophy/4834049.1.aspx
S>Поясняю. Там одна оценка и два плюса. Отметилось всего два человека.

Верю. А что значит 40? Поясните, ото я...ну вы понимаете.

Ээээ, а синглтон?

... << RSDN@Home 1.2.0 alpha 5 rev. 43>>

Здравствуйте, rusted, Вы писали:

R>Здравствуйте, pkl, Вы писали:

M>>>А вы в кусрес, что в реальной жизни таких предков не существует?
pkl>>1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.
pkl>>2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП. Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

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

Здравствуйте, Steamus, Вы писали:

S>>>http://www.rsdn.ru/forum/philosophy/4834049.1.aspx
S>>Поясняю. Там одна оценка и два плюса. Отметилось всего два человека.

S>Верю. А что значит 40? Поясните, ото я...ну вы понимаете.
40 это текущий рейтинг Mamut-а (20), помноженный на поставленную им оценку (2).

Здравствуйте, мыщъх, Вы писали:

S>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу...
М>сарказм неуместен. открытие двери и окна реализуется практически идентичным кодом. писать псевдокод лень, но будет что-то типа -- объект заперт? если да, то вставить ключ и отомкнуть. повернуть ручку и сделать pull/push в зависимости от флажка.

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

Здравствуйте, Mamut, Вы писали:

M>>>>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>>>>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

M>>>Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.
pkl>>Зачем повторяться всяким бредом?

M>Где ты видишь бред? Бред пока у людей, которые неспособны подтвердить свой тезис, что ООП прекрасно моделирует реальность.
А если способные люди подтвердят, а вы напишете "ты не подтвердил" — то кто будет прав? Или истина проверяется вашим восприятием? А оно прошло тестирование в палате мер и весов? А сертификат есть?

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

Здравствуйте, Mamut, Вы писали:

M>Только вот к реальной жизни это опять же не имеет никакого отношения.

В реальной жизни классы создаются из обьектов, а не наоборот.

Здравствуйте, 0x7be, Вы писали:

SV.>>Просто потому, что мы мыслим объектами.
0>А это точно правда?

Я добавлю: не просто объектами, а физическими объектами и их траекториями. Плюс — символьные манипуляции.

Здравствуйте, A13x, Вы писали:

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

Здравствуйте, kittown, Вы писали:

K>Здравствуйте, мыщъх, Вы писали:

K>Еще одна проблема — в реальном мире состояние "открыта-закрыта" субъективно со стороны наблюдателя.
K>Одному надо, чтобы было герметично закрыто, иначе не считает что закрыто, другому нужно, чтобы была заперта, иначе не закрыта.

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

> Объективно только геометрическое положение двери. К вопросу о соответствии реальности.
если набросить на дверь цепочку -- ее геометрическое состояние не измениться. а евроокна могут быть открыты тремя положениями рычага.

но я не об этом. я о том, что если для двух разных obj (например, объет "земля" и объект "конь") мы имеем идентичный код, работающий с ним ("копать от забора до обеда", "ехать от утра до ночлега"), то зачем дублировать этот код? duck typing избавляет нас от необходимости наследования земли и коня от общего предка, который в данном случае отсутствует.

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

Здравствуйте, Steamus, Вы писали:

S>Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг?

За статьи оценки удесятиряются.

Здравствуйте, trophim, Вы писали:

T>Ээээ, а синглтон?

Синглтон не обладет той разрушительной силой как визитор, поэтому мало интересен.

Здравствуйте, AlexCab, Вы писали:

AC>на сегодня ООП наиболее мощная из реально используемых парадигм.
AC>-------------------
AC>Тем не менее, ООП должно умереть!

какой странный вывод.
почему должно?

Здравствуйте, Sinclair, Вы писали:

V>>Далее ты задашь некую систему объектов, назовем эту систему "Природа", и вполне пристало задать этой системе способ активизировать свои внутренние объекты. Только тебя надо поправить так:
V>>Природа.поедание(коровы, трава).
S>Прекрасно. Ваши аргументы против ООП безупречны.

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

LCR>>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

V>>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.
S>Осталось выяснить, какое место в этих видах моделирования занимает ООП.

И ты до сих пор не выяснил?
Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)

S>Надо полагать, там молекула воды наследуется от двух атомов водорода и одного атома кислорода?

Надо полагать, что ты решил опустить обсуждение ООП на уровень 1-го курса ВУЗа... Твой выбор, но это без меня. Правильный ответ тут такой: наследование — лишь удобный инструмент, но не обязательная часть ООП-программы. Обсуждать в эту область я не буду, бо неинтересно. При последущем ответе всё-равно скипну.

S>Или всё сводится к какому-то аналогу cluster.Compute(task)?

Нет, всё сводится исключительно к тому, что без состояния нет поведения. См. пометку (*). Кто этого не понимает, тот не понимает как устроено и работает ООП. Тот не понимает фундаментальное отличие повдеения от безусловнх реакций. ООП — это такой механизм моделирования "поведения сущностей", который реализован через изменяемое состояние.

Здравствуйте, Sinclair, Вы писали:

S>Потому, что объекты в жизни никак не хотят вести себя как объекты в ООП. Понятия идентичности в реале совсем другие; понятия классификации тоже.
Хех. Я помню дискуссии о том, какой же отстой этот ООП. Ведь им придётся имитировать плевок в лужу в виде обмена сообщений между молекулами лужи.

Здравствуйте, Cyberax, Вы писали:

S>>Потому, что объекты в жизни никак не хотят вести себя как объекты в ООП. Понятия идентичности в реале совсем другие; понятия классификации тоже.
C>Хех. Я помню дискуссии о том, какой же отстой этот ООП. Ведь им придётся имитировать плевок в лужу в виде обмена сообщений между молекулами лужи.
Ну вот по соседству мы как раз вернулись к плевку и луже. http://rsdn.ru/forum/philosophy/4834765.1.aspx

Здравствуйте, vdimas, Вы писали:

V>Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.

V>детсад как он есть.

Оно там через векторные поля считается, никаких частиц.

http://ru.wikipedia.org/wiki/Векторное_поле#.D0.92.D0.B5.D0.BA.D1.82.D0.BE.D1.80.D0.BD.D1.8B.D0.B5_.D0.BF.D0.BE.D0.BB.D1.8F_.D0.B2_.D1.82.D1.80.D1.91.D1.85.D0.BC.D0.B5.D1.80.D0.BD.D0.BE.D0.BC_.D0.BF.D1.80.D0.BE.D1.81.D1.82.D1.80.D0.B0.D0.BD.D1.81.D1.82.D0.B2.D0.B5

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Надеюсь, это было твое ИМХО

V>Это был здравый смысл. В пылу спора коллеги на этом сайте как-то охотно забывают о субъективном характере практически любой информации, которой обмениваются.
Вот и ты не забывай. Помни, что твой здравый смысл — не более чем чье-то имхо.

S>>Мы вообще-то говорили об ООП. Это на тот случай, если ты решил контекст восстановить по одному лишь моему сообщению. В рамках того контекста, в котором я тут общаюсь, я делаю предположение о том что твое ИМХО считает что все, где встречается упоминание числа либо какой-то величины, можно смело относить к ООП...

V>Я понял твоё усиление и весь нагнетаемый трагизм. Надо было тебе еще н авсякий случай переспросить и поставить такой смайл:

.
V>Но ответ — да. Да, любое конкретное значение — это не абстракция, это выражение некоего понятия предметной области.
Я принял к сведению твое имхо

S>>Я не рассчитывал что ты влезешь с середины и не поймешь о чем речь (или сделал вид что не понял).

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

V>Кароч, неблагодарное это дело... Хотя бы потому, что эти наборы практик постоянно развиваются. То бишь любая твоя т.з., пусть даже самая адекватная, назавтра безбожно устареет.

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

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

Здравствуйте, мыщъх, Вы писали:

K>>Еще одна проблема — в реальном мире состояние "открыта-закрыта" субъективно со стороны наблюдателя.
K>>Одному надо, чтобы было герметично закрыто, иначе не считает что закрыто, другому нужно, чтобы была заперта, иначе не закрыта.

М>так я же и пишу: открыта/закрыта/заперта. еще можно добавить "зафиксирована" в открытом, закрытом или промежуточном состоянии.

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

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

Здравствуйте, vdimas, Вы писали:

V>И ты до сих пор не выяснил?
V>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)

V>Нет, всё сводится исключительно к тому, что без состояния нет поведения. См. пометку (*). Кто этого не понимает, тот не понимает как устроено и работает ООП. Тот не понимает фундаментальное отличие повдеения от безусловнх реакций. ООП — это такой механизм моделирования "поведения сущностей", который реализован через изменяемое состояние.

Введем в рассмотрение ФП, где на вход функции дается состояние, а на выходе получаем новое. С учетом работы GC каких-то практических отличий от изменяемых объектов будет негусто. При этом еще интересно посмотреть на обьекты ocaml.

V>Мозг работает образно
Я бы сказал, что точно неизвестно, наука тем и занимается, что выясняет, но один из видов мышления — образами.
V> и это уже многократно доказано.
Где? Ссылки?
V> Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...

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

Здравствуйте, Философ, Вы писали:
AC>>Тем не менее, ООП должно умереть!

Ф>почему должно?
Such a plan

Здравствуйте, Sinclair, Вы писали:
AC>>>Тем не менее, ООП должно умереть!

Ф>>почему должно?
S>потому что all the beauty must die

В каком оно месте "beauty"?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, jazzer, Вы писали:
J>>Например (я конкретно о том, с чем имел дело, буду говорить — моделирование полевого транзистора методом частиц), поле можно представлять очень по-разному — в виде прямоугольной сетки, в виде треугольной сетки, в виде смеси обеих по произвольным границам. Также можно по-разному интерполировать поле внутри каждого конечного элемента. Все это замечательно укладывается в ООП — частица просто спрашивает у объекта соответствующего полевого класса, какой вектор поля в той точке, где она находится, пользуясь только базовым интерфейсом, а реализация может быть какой угодно.
J>>А у базового интерфейса, по сути, всего два метода: один я уже озвучил, а второй — пересчитать себя из внешнего поля и коллекции частиц.
J>>Вполне себе ООП.
S>Прекрасно, прекрасно. В итоге оказалось, что от "объектов", которые мы наблюдаем в "реальности" (скажем, частицы и их взаимодействие) мы тут же отказались, и ввели совершенно другие понятия. И вместо облака миллионов объектов, обменивающихся сообщениями, мы получили три "объекта" — массив частиц, векторное поле, и "вычислитель" (отсутствующий в природе совсем), который выполняет шаги вычисления. Причём сама процедура вычисления построена на ФП-основе — чистые арифметические функции, а вовсе никакие не методы объектов класса Double.

Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием

Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.

А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

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

S>Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.

Осталось понять:
— каким образом обсуждение моей личности является напряженной, интересной дискуссией?
— почему человек, считающий обсуждение моей личности напряженной интересной дискуссией, думает, что он не школьник?

Здравствуйте, Mamut, Вы писали:

M>Каки бы ни были задачи, любая модель (ООП, ФП, процедурная) к реальности будет относиться по стольку по скольку

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

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

Это какой то неправильный ООП

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

M>>Каки бы ни были задачи, любая модель (ООП, ФП, процедурная) к реальности будет относиться по стольку по скольку

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

Это такая масштабная попытка показать выделенное

Ну и троллинг, не без этого

Здравствуйте, Mamut, Вы писали:

M>Это такая масштабная попытка показать выделенное

Крайне неудачная, имхо.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>в чистом ООП решение квадратного уравнения

Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.
Разве что само уравнение представить в виде объекта

class QuadraticEqu
{
public QuadraticEqu(CComplex a, CComplex b, CComplex c);
public CComplex GetD();
public CComplex GetX();
public CComplex GetY();
}

S>вы устанете читать, и ... понимать

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

Здравствуйте, jazzer, Вы писали:

J>Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием

Вопрос не в том, "ложатся или не ложатся". Если поднапрячься, то можно и круглой пробкой квадратное отверстие заткнуть.
Вопрос в том, даёт ли ООП тут хоть какое-то преимущество перед не-ООП, или нет. Надо понимать, что наличие одного метода, который удалось сделать виртуальным, не даёт нам никакого ощутимого выигрыша. Вот вы сумели декомпозировать задачу так, что устройство сетки можно менять независимо от алгоритма расчёта новых параметров частиц, я вас правильно понял?
Пока что выглядит всё так, что этому алгоритму достаточно иметь функцию Double getFieldValues(Point point).
Ради одной функции городить типы с полиморфизмом и наследованием выглядит, скажем так, избыточным.

J>Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
А что у вас там такого особенного с этими коллекциями, что не укладывается в банальный массив? Что именно вы инкапсулируете?

J>Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.

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

J>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?

Здравствуйте, Sinclair, Вы писали:

M>>Это какой то неправильный ООП

S>Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
S>А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, minorlogic, Вы писали:

M>>Это какой то неправильный ООП

S>Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
S>А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

Тогда резонно изложить ваше понимание "настоящий ООП".

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

Здравствуйте, Воронков Василий, Вы писали:

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

Здравствуйте, Философ, Вы писали:

Ф>Оно там через векторные поля считается, никаких частиц.

Оно по-разному считается. Но чем мощнее со временем компы, тем более популярны методы на основе моделирования частиц.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, jazzer, Вы писали:

J>>Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием

S>Вопрос не в том, "ложатся или не ложатся". Если поднапрячься, то можно и круглой пробкой квадратное отверстие заткнуть.
Оно, конечно, да, но тут не в тему немного.

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

S>Пока что выглядит всё так, что этому алгоритму достаточно иметь функцию Double getFieldValues(Point point).
S>Ради одной функции городить типы с полиморфизмом и наследованием выглядит, скажем так, избыточным.

Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps).
Еще надо хранить всю структуру полевой модели (разные типы сеток).
Имхо, вполне достаточно для класса, не?

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

J>>Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.
S>

Как раз удобство — единственное, что тут важно. Вычислительная мощность у всех моделей совершенно одинакова.
Именно, удобство — важно, а массив — нет.

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

J>>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

S>Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?
Не, координатный оператор не перемещает, он ищет координату.
Любая временная эволюция осуществляется оператором эволюции, который экспонента от гамильтониана и времени.

Но вообще да, любой квантовомеханический оператор имеет один и тот же интерфейс:
1) подействовать на данную волновую функцию.
2) посчитать свое среднее на данной волновой функции.
3) посчитать свои собственные значения.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос в том, даёт ли ООП тут хоть какое-то преимущество перед не-ООП, или нет.

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

Или тебя интересует, можно ли тоже самое оформить не в виде ООП? )))
Ес-но можно. Как и любую другую задачуЮ, решенную в ООП-стиле.

Здравствуйте, Воронков Василий, Вы писали:

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

ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

+1
В Руби то же самое, ЕМНИП.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Sinclair, Вы писали:

S>>в чистом ООП решение квадратного уравнения

Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.
Ф>Разве что само уравнение представить в виде объекта

Ф>class QuadraticEqu
Ф>{
Ф> public QuadraticEqu(CComplex a, CComplex b, CComplex c);
Ф> public CComplex GetD();
Ф> public CComplex GetX();
Ф> public CComplex GetY();
Ф>}

S>>вы устанете читать, и ... понимать

Ф>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...
Ну как же. Это вы только начали. Теперь давайте попробуем расписать хотя бы GetD() — вы же понимаете, что в православном ООП никаких инфиксных операторов быть не может. У нас только посылка сообщения. И нам ещё надо решить, делать ли Add методом CComplex, или всё-таки CArithmetic, чтобы была возможность реализовывать разные стратегии округления. Непонятно, почему мы взяли CComplex за основу — очень жёсткие зависимости получаются между классами решения.

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

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

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

Здравствуйте, jazzer, Вы писали:

J>Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps).
Вот как раз такие штуки и выдают, скажем так, малопригодность ООП для вычметодов. Потому что непонятно, updateField — это метод у Field, у Environment, или у Particles.

J>Еще надо хранить всю структуру полевой модели (разные типы сеток).
J>Имхо, вполне достаточно для класса, не?

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

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

var hotElectrons = from e in allElectrons where e.getEnergy() >= hotBoundary select e;

J>Именно, удобство — важно, а массив — нет.
Массив — это такая коллекция, которая предоставляет произвольный доступ за O(1). Если у вас нет особенных потребностей по заменяемости таких коллекций, то абстрагировать их никакого смысла нет.

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

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

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

J>Но вообще да, любой квантовомеханический оператор имеет один и тот же интерфейс:
J>1) подействовать на данную волновую функцию.
J>2) посчитать свое среднее на данной волновой функции.
J>3) посчитать свои собственные значения.
Очень странно. А почему вы сделали волновую функцию такой пассивной? С чего это вы взяли что оператор должен считать своё среднее на ней, а не она его среднее на себе?
Вы, кстати, собираетесь пользоваться шредингеровским или гейзенберговским представлением?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, Sinclair, Вы писали:

S>>>в чистом ООП решение квадратного уравнения

Ф>>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.
Ф>>Разве что само уравнение представить в виде объекта

Ф>>class QuadraticEqu
Ф>>{
Ф>> public QuadraticEqu(CComplex a, CComplex b, CComplex c);
Ф>> public CComplex GetD();
Ф>> public CComplex GetX();
Ф>> public CComplex GetY();
Ф>>}

S>>>вы устанете читать, и ... понимать

Ф>>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...
S>надо решить, делать ли Add методом CComplex, или всё-таки CArithmetic
да, этот метод — та ещё задачка %)

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

S>Вот решатель уравнений первого и третьего порядков...
это дополнительные требования, в ТЗ не было — оплачиваются отдельно

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

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

Мелковата эта задачка для ООП, ибо моделировать здесь нечего.
Нет никакого смысла моделировать ни числа, ни уравнение — не обладает оно ни состоянием, ни поведением.
С "Вычислителем" было бы интереснее, ведь это вполне его метод:
вычислитель.РешитьУравнение()
или что-нибудь, типа вычислитель.ПосчитатьСреднее()

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

Здравствуйте, Философ, Вы писали:
Ф>И какие-такие зависимости?
Очень простые — допустим, вас перестала устраивать точность даблов. Вы хотите работать в арифметике тройной разрядности.
Как нам воспользоваться готовым решением уравнения, без копипасты?
Или вы просто хотите перетащить ваше решение туда, где повсюду используются кватернионы.
Или хотя бы другая реализация комплексных чисел. Вам недостаточно просто скопировать код решателя — надо тянуть все эти CComplex, или заменять их, и т.п.

S>>Вот решатель уравнений первого и третьего порядков...
Ф>это дополнительные требования, в ТЗ не было — оплачиваются отдельно

Ну так в жизни-то всегда есть дополнительные требования. Что ж это за технология такая, где каждое решение — непохоже на соседнее, и его невозможно повторно использовать?

Ф>Не, мой мозг — слишком большая цена.

Вот и я об этом же.

Ф>Мелковата эта задачка для ООП, ибо моделировать здесь нечего.
А задача обработки particle system слишком велика для ООП.

Ф>Нет никакого смысла моделировать ни числа, ни уравнение — не обладает оно ни состоянием, ни поведением.
Абсолютно согласен. Хотя Кей всё-таки собрал из ~~ледяных кристаллов~~ объектов слово Арифметика.

Ф>С "Вычислителем" было бы интереснее, ведь это вполне его метод:
Ф>вычислитель.РешитьУравнение()
Ага. Смотрели на то, как Bart de Smet прикручивал linq к Z-theorem prover? Вот это — ГОСТ 13345-85.

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

Здравствуйте, Sinclair, Вы писали:

J>>Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps).
S>Вот как раз такие штуки и выдают, скажем так, малопригодность ООП для вычметодов. Потому что непонятно, updateField — это метод у Field, у Environment, или у Particles.

Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так:
timeModel.update(Environment e, Particles ps).

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

Здравствуйте, samius, Вы писали:

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

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

Но читать твой ответ было таки забавно... Ты прекрасно всё понял... хоть и не был этому рад. ))

========
И да... насчет устаревания — увы и ах. Обсуждаемые наборы практик (ООП и ФП) не мертвы, а вовсе наоборот — активно развиваются и дополняются. И даже заимствуют практики друг у друга.

Здравствуйте, kittown, Вы писали:

V>>Мозг работает образно и это уже многократно доказано. Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...

K>Обрзность и мышление обтектами — это не так уж рядом.

Рядом, рядом...

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

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

K>а потом в течение времени или сожаление от опоздания на поезд,

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

K>по самого разного рода ассоциативным связям.

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

Здравствуйте, Sinclair, Вы писали:

S>Если нет разнообразия в поведении механизмов решения, а вся сложность перенесена на обрабатываемые данные, то РА и языки вроде SQL (или Linq) будут значительно более уместны, чем ООП или рукопашное ФП.

Что такое "поведение механизмов решения"?

S>Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу. Я пока смотрю на этот подход с осторожным оптимизмом.

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

Здравствуйте, 0x7be, Вы писали:

0>У меня складывается впечатление, что мантру о том что "ООП естественно для человека, потому что мы мыслим объектами" многие заучили ещё в университетах, не пытаясь осмыслить её критически.

0>Вот упомянул понятийное мышление — а ты уверен, что понятия тождественны классам ООП (и какой, кстати, разновидности его)?

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

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

Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения.
Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.

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

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:

pkl>>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта...
S>Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения".
S>Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение.
S>А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта.
S>В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.
Я чё-то охладел к разговору (-;

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:

pkl>>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта...
S>Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения".
S>Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение.
S>А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта.
S>В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.
По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема?

Здравствуйте, samius, Вы писали:

S>Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии.

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

S>Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции.

Это типа решил поупражняться в искусстве "лечения по фотографии"? Я тут с одним клиентом уже на эту тему работаю, в очередь, в очередь. )))

В общем, всё что Я сказал — запечателось в подветке. То бишь если подзабыл — можно освежить.

S>Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.

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

V>>Кароч, нет в ФП никакой магии, котрую ты уже примерно второй год пытаешься найти. Это естественное развитие процедурного подхода, точно так же как ООП является развитием процедурного подхода.
S>В ФП нет магии, но развитием процедурного подхода оно не является. Соглашусь лишь что в развитии ФП и ООП многое шло параллельно и они безусловно влияли друг на друга.

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

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

Поэтому, поэтому. Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.

V>>На подобные кривые аналогии у меня всегда реакция как на кислый лимон.
S>Лимон? Ну и что... Вот если бы ты сказал как на пенку от кипяченого молока... Лимон-то это круто.

Я бы на нашей 40-й жаре холодного пивка лучше навернул... )))

V>>Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет.
S>Вопросы воспроизводимости механизмов и возможности эмуляции одного на другом вторичны и не особо меня интересуют, как ты уже наверное понял.

Э нет, речь не об эмуляции одного на другом, а о прямой подержке в языке этих парадигм. Эмуляция — это всегда разновидность анонизма. Хотя порой без этого никак... Увы, современные языки несовершенны. А если даже язык попадается неплохой, то у него самый ужасный в мире компилятор и порождаемый конечный образ. Так что, исходим из того, что есть. ))

S>Мне любопытны наборы практик,

Во, о чем и речь. А практики эти сложились от системы гарантий.

S>а не выводы типа "все **П выполняются в машинных кодах => произошли от него".

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:R>>Понимане ерез органы чувств хоть и ограниченное, но зато наиболее естественное и простое для восприятия. Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия. Вы ввели абстрактную сущность IОткрываемое, описали состояния двери, да, это ООП, но мы ведь так и не приблизились к решеню проблемы — дверь всё еще закрыта. И чтобы нам её открыть, нужно совершить действие — тот самый глагол, который во всем этом примере первичен для обычного человеческого восприятия. Для решения задачи нужно разложение этого открыть на последовательность более мелких действий. А назначение всех этих иерархий наследования — лишь натянуть на всю эту ситуацию ООП ради самого ООП.
pkl>>Вот мне даже в реальной жизни пофигу на процесс, происходящий с дверью во время открытия. Я её толкнул или пнул ногой или повернул ключ — это такие ерундовые для меня действия, что я вполне назову это "вызов метода open()". Мне важно, чтобы объект поменял состояние на "открыто" и я смог войти, а как она конкретно открывается — в какую сторону, каким ключём — мне до такой большой лампочки, что просто нет такого подъёмного крана на свете, чтобы эту лампочку поднять. Для меня открытие двери — как она движется, вися на петлях, как в ней работает замок, — это всё инкапсулировано в методе "open()".
S>Прекрасно. Вот для вас, получается, важен не процесс открытия, а результат. То есть в вашей модели у двери есть свойство, которое может принимать два состояния "открыто" и "закрыто" (опустим пока подробности промежуточных состояний). Для вашей задачи естественным будет такой язык, в котором вы можете потребовать theDoor.state = open и всё. Зато вам может оказаться важно, что дверь была уже открыта, чтобы не делать лишних действий.
S>Для таких задач REST-архитектуры подходят гораздо больше, чем ООП.
Открывание и закрывание двери можно описать в любой парадигме, какой захочется. Что означает "какая лучше подходит"? По какой формуле вычислить показатель лучшести?

vdimas,

LCR>>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
V>У кого-то проблемы с дверью? А по физике разве ни одной задачи не решили в школе? А импульсы тел не находили?

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

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

Я так и не понял почему взаимодействие между одной коровой и травой (которая представлена одним или несколькими объектами?) свелось ко множеству коров и повторному взаимодействию. Ещё комбикорм откуда-то появился...

LCR>>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.
V>Это не хардкор, а детсад как он есть. Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях. Думаешь, нахрена нужны суперкомпьютеры для вычисления результатов ядерного взрыва??? По-твоему, эти суперкомпьютеры нужны для вычисления смешной формулы с максимум всей сложности — возведением в 3-ю степень? ))

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

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

Здравствуйте, Философ, Вы писали:

Ф>логично было взять самое широкое множество.
Октонионы? Тока не забываем, что тогда x.Add y это совершенно не то же самое, что y.Add x

Здравствуйте, dilmah, Вы писали:

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

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

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

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, Философ, Вы писали:

Ф>>логично было взять самое широкое множество.
W>Октонионы?

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии.

V>Вот именно с таким антогонизмом я и спорю. Ты правильно уловил суть. Набор практик не такой уж несовместимый.
Я не говорил что он несовместимый. Я говорил что он разный.

S>>Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции.

V>Это типа решил поупражняться в искусстве "лечения по фотографии"? Я тут с одним клиентом уже на эту тему работаю, в очередь, в очередь. )))

V>В общем, всё что Я сказал — запечателось в подветке. То бишь если подзабыл — можно освежить.
Дык, это была гипербола была

S>>Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.

V>Да, вроде, ты пока споришь с собой, а со всем сказанным мной — пока что согласился.

Я тебе рассказываю о ценности твоих выводов, а не спорю с тобой.

S>>В ФП нет магии, но развитием процедурного подхода оно не является. Соглашусь лишь что в развитии ФП и ООП многое шло параллельно и они безусловно влияли друг на друга.

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

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

(снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)

S>>смотрится неплохо, но причина вовсе не "поэтому".

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

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

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

V>Хотя порой без этого никак... Увы, современные языки несовершенны. А если даже язык попадается неплохой, то у него самый ужасный в мире компилятор и порождаемый конечный образ. Так что, исходим из того, что есть. ))

S>>Мне любопытны наборы практик,

V>Во, о чем и речь. А практики эти сложились от системы гарантий.
От систем. Системы-то разные.

S>>а не выводы типа "все **П выполняются в машинных кодах => произошли от него".

V>А уже где-то был такой вывод? Или как? Или это опять то, о чем я подумал?
Это опять была гипербола. И она не так далека от выводов, которые ты предлагаешь.

V>Ты бы эта... без вот этих мансов, что ле... "Не читай Синклера, Вольфхаундом станешь". ))
Я лучше тебя не буду читать.

Здравствуйте, pkl, Вы писали:

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

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

Здравствуйте, Философ, Вы писали:
Ф>удареный он чувак
Отож. Жаль, редко пишет.
Ф>Оно?
Ага.

Здравствуйте, vdimas, Вы писали:

V>Что такое "поведение механизмов решения"?
Сложно объяснить формально, оставаясь за рамками конкретной парадигмы. Скажем так — количество возможных траекторий изменения состояния.
Интуитивно понятно, что интерфейс с одним методом — это оверкилл. Есть же delegate Func<T, R>. Да и делегат оверкилл — со всеми его BeginInvoke и прочим — там, где достаточно простого замыкания.

V>Как раз таки DSL меньше всего должны быть мультипарадигменными, иначе это будет профанацией на фоне мультипарадигменных языков общего назначения.
Ну, у меня опыта применения DSL практически нет. Скорее всего да — лишние парадигмы будут только мешать. Но надо смотреть на конкретные примеры.
Вот, скажем, SQL прекрасно работает там, где он остаётся декларативным языком описания запросов.
Когда из него делают процедурный язык, получается многословное и неэффективное гуано. Ещё хуже, когда в него пытаются засунуть ООП.
V> То бишь, ваяние нескольких DSL в процессе решения задачи по-прежнему может означать то самое переключение м/у парадигмами.
Да, скорее всего так.

Здравствуйте, vdimas, Вы писали:

V>Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так:
V>timeModel.update(Environment e, Particles ps).
О, уже timeModel появилось.
V>А гду-то унутрях timeModel будет подавать на вычисления некое dt, по которому происходит численное интегрирование. Но опять же, если dt не константа... А если константа, тогда состояние timeModel перемещается в глобальную область вслед за этой константой и остается просто оригинальный update().
Какая ещё "глобальная область" в каноническом ООП? Там нет ничего, кроме объектов, обменивающихся сообщениями.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:

pkl>>Открывание и закрывание двери можно описать в любой парадигме, какой захочется. Что означает "какая лучше подходит"? По какой формуле вычислить показатель лучшести?
S>Есть всего два показателя:
S>1. Эффективность работы программиста. Т.е. сколько времени потребуется, чтобы написать, прочесть, отладить, и впоследствии исправить. В первом приближении обратно-линейно зависит от объёма кода.
S>2. Эффективность работы компилятора. Т.е. насколько эффективный целевой код удастся получить по данному исходнику.

S>Если мне для открывания двери нужно написать шесть страниц кода, то парадигма плохая. Если на моём четырёхядерном ноуте не удаётся открыть больше сотни дверей в секунду — парадигма плохая.
Это слишком абстрактно, реальные языки часто мульти-парадигменны.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:
pkl>>По-моему вы сами себя загоняете в рамки. Я в своём воображении могу представить эту дверь в любой парадигме. По вкусу добавляются исключения, методы, состояния — что угодно. Например обнаруживать факт открытости двери можно в любой парадигме — исключение, isOpen(), чтение публичной переменной "вручную" и т.п. — всеми этими вещами в любой момент вы можете назвать "обнаружил, что дверь была закрыта". Где проблема?
S>Проблема — в том, что то, что вы описываете, никакого отношения ни к реальной жизни, ни к бытовому мышлению не имеет.
S>Получается какое-то двоемыслие: то есть начинаем со смелого утверждения "ООП лучше подходит для программирования потому, что человек мыслит объектами". А потом оказывается, что в этой самой парадигме для того, что человек мыслит простым и ясным образом, нужно вводить какие-то публичные переменные, исключения, isOpen(), и прочее — что не соответствует ничему из исходной ментальной модели.

S>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.
Человек мыслит просто и ясно объектами, никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно.

Здравствуйте, Философ, Вы писали:

Ф>во-первых, я не знаю что это такое,
http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0_%D0%9A%D1%8D%D0%BB%D0%B8
Ф>а во-вторых, при решении квадратного уравнения запросто могут получиться комплексные корни — почему-бы его тогда с самого начала не решать с комплексными коэффициентами?
Вы пишете странные вещи. Комплексные корни при решении квадратного уравнения не могут появиться сами по себе.
Просто комплексные числа — замкнуты относительно операций возведения в степень; поэтому они предоставляют минимум, необходимый для того, чтобы получить два корня у любого квадратного уравнения. Как вы помните, в школе всех устраивало наличие от нуля до двух вещественных корней.
Это не значит, что выбор поля исчерпывается вещественными либо комплексными числами.
Понятия операций умножения и сложения введены много для чего. Например, для кватернионов, октонионов. Для матриц, например. Что нам может помешать искать решение уравнения A*X*X + B*X + C = 0, где A, B, C, X — квадратные матрицы?

Здравствуйте, Sinclair, Вы писали:

V>>Всё чем понятно. Смотрите в сигнатуру, на ней всё написано. Это внешнее, по отношению к Environment и Particles, событие. Само событие заключается в прошедшем временном тике. То бишь можно было написать как-то так:
V>>timeModel.update(Environment e, Particles ps).
S>О, уже timeModel появилось.

Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.

V>>А гду-то унутрях timeModel будет подавать на вычисления некое dt, по которому происходит численное интегрирование. Но опять же, если dt не константа... А если константа, тогда состояние timeModel перемещается в глобальную область вслед за этой константой и остается просто оригинальный update().
S>Какая ещё "глобальная область" в каноническом ООП?

Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.

S>Там нет ничего, кроме объектов, обменивающихся сообщениями.

Дык, а кто мешается этому синглтону уметь отправлять сообщения?

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, pkl, Вы писали:
S>>>Это не говорит о том, что ООП плохое. Это говорит о том, что представления о волшебном соответствии ООП нашему мышлению — заблуждение.
pkl>>Человек мыслит просто и ясно объектами,
S>Я не знаком с человеком, о котором вы говорите. Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты? Чем они похожи на объекты в ООП?
pkl>>никаких публичных переменных, исключений и т.п. для самого процесса мышления не нужно.
S>Спасибо, что подтверждаете мою точку зрения.
Имеется ввиду, что ООП хорошо ложится на мышление о сложных механизмах, типа ткацкой фабрики.

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

Здравствуйте, Ikemefula, Вы писали:

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

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

I>Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения.
I>Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.
Меня смущает "понятие" высококлассный программист. Что ты в него вкладываешь?

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

Здравствуйте, vdimas, Вы писали:

V>Мозг работает образно и это уже многократно доказано.

Кем доказано ? Можно взглянуть на доказательства ? А то в книгах по когнитивной психологии ни разу не встречал "мозг работает образно"

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

Вот бы узнать, что же такое "образность"

Здравствуйте, pkl, Вы писали:

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

Если почитать Dr. Kay-я, то он под каждой вещью подразумевает компьютер. Это вовсе не хорошо ложится, это способ представления природы вещей такой. Пусть заяц будет компьютером и морковка будет компьютером, и пусть они обмениваются сообщениями. Подробнее http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

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

Здравствуйте, Sinclair, Вы писали:

V>>Что такое "поведение механизмов решения"?
S>Сложно объяснить формально, оставаясь за рамками конкретной парадигмы. Скажем так — количество возможных траекторий изменения состояния.
S>Интуитивно понятно, что интерфейс с одним методом — это оверкилл. Есть же delegate Func<T, R>. Да и делегат оверкилл — со всеми его BeginInvoke и прочим — там, где достаточно простого замыкания.

Ну ок. Просто пока плохо понятна связь с последующим выводом в оригинальном посте.

V>>Как раз таки DSL меньше всего должны быть мультипарадигменными, иначе это будет профанацией на фоне мультипарадигменных языков общего назначения.
S>Ну, у меня опыта применения DSL практически нет. Скорее всего да — лишние парадигмы будут только мешать. Но надо смотреть на конкретные примеры.

Я возражал лишь на это:

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

V>> То бишь, ваяние нескольких DSL в процессе решения задачи по-прежнему может означать то самое переключение м/у парадигмами.
S>Да, скорее всего так.

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

Спорить не буду, но и соглашаться тоже. Я видел много кода на оракловом процедурном SQL в т.ч. реализованную интероперабельность с java-объектами, которые хостятся на серваке (тут Оракл был раньше MS). И скажу так, что претензии у меня по большей части к динамической природе языка, а не к его мультипарадигменности. Заметь, что этот момент неплохо перекликается с твоими собственными утверждениями об умении переключаться м/у парадигмами. Я бы добавил, что переключение — относительная фигня. Коль речь всё еще об одном проекте, то нам эту мультипарадигменную солянку надо как-то спрягать саму с собой.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, pkl, Вы писали:

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

S>Если почитать Dr. Kay-я, то он под каждой вещью подразумевает компьютер. Это вовсе не хорошо ложится, это способ представления природы вещей такой. Пусть заяц будет компьютером и морковка будет компьютером, и пусть они обмениваются сообщениями. Подробнее http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

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

Здравствуйте, Sinclair, Вы писали:

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

Здравствуйте, 0x7be, Вы писали:

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

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

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

ООП без абстракций это новость

0>По мне это самый сомнительный момент в аргументации. Как можно с уверенностью заявлять о гомоморфизме чего-то нечеткого с чем-то непонятным?

Есть несколько теорий мышления.

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

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

0>тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.

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

I>>Есть заблуждение, что дескать ориентироваться надо только высококлассных программистов. Высококлассный программист не пишет даже прикладной код не говоря о скриптах, кастомизации и тд. Просто потому что таких специалистов на порядки меньше чем этого хотелось бы. Более того — тенденция идет в сторону ухудшения этого соотношения.
I>>Такой человек обычно пишет ядро/фреймворк или разрабатывает архитектуру системы. Все остальное это труд десятков, сотен, тысячи и даже десятков и сотен тысяч людей.
0>Меня смущает "понятие" высококлассный программист. Что ты в него вкладываешь?

Примерно как в шахматах — первый разряд, кмс, мс, гроссмейстер

I>>Функционалисты хотят что бы один мега-специалист вооружившись мега-языком накодил небольшое ядро и сгенерил код для всего остального. Это утопия, просто потому что задач очень много, просто вникнуть в эти задачи это адское количетсво времени, хватит на сотню а то и тысячу лет жизни одного такого функционалиста.
0>Осторожно предположу, что ты превратно трактуешь идеи "функционалистов"

Может и так.

Здравствуйте, Sinclair, Вы писали:

J>>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

S>Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?

Вобще говоря так и делается в целях оптимизации.

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

Здравствуйте, Ikemefula, Вы писали:

I>Вобще говоря так и делается в целях оптимизации.
А можно поподробнее? Что именно вы оптимизируете?

Здравствуйте, vdimas, Вы писали:

V>Я возражал лишь на это:
V>

V>Серебряной пулей тут является умение мыслить несколькими парадигмами и свободное переключение между ними. Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу.

Ну так DSL вовсе не обязан быть мультипарадигменным. Представим, что у нас нет, скажем, Пролога. В его отсутствие мы можем быть вынуждены писать решение на адской смеси из, скажем, SQL (для хранения фактов) и, скажем, Java (для собственно обработки). А можем родить Пролог и получить "однопарадигменный" язык, который окажется удобнее, чем сразу две парадигмы.

V>Спорить не буду, но и соглашаться тоже. Я видел много кода на оракловом процедурном SQL в т.ч. реализованную интероперабельность с java-объектами, которые хостятся на серваке (тут Оракл был раньше MS). И скажу так, что претензии у меня по большей части к динамической природе языка, а не к его мультипарадигменности.
Ну, а я вот видел много кода на T-SQL. В основном в хранимках. И там сразу видно, что те вещи, которые должны быть простыми, выглядят просто чудовищно. Банальные "из двух мест взяли, в третье положили", которые так и пишутся тремя строчками на приличном general purpose language — это адский взрыв мозга на T-SQL.
Интероперабельность с объектами — это всё цветочки. Вы посмотрите на OQL — вот где тру ООП-в-SQL. Он так и не взлетел никогда по причине чудовищной ужасности.

V>Заметь, что этот момент неплохо перекликается с твоими собственными утверждениями об умении переключаться м/у парадигмами. Я бы добавил, что переключение — относительная фигня. Коль речь всё еще об одном проекте, то нам эту мультипарадигменную солянку надо как-то спрягать саму с собой.
Да, конечно же. Имелся в виду контекст одного проекта. Между разными проектами переключение парадигмы никакой проблемы не представляет.

LCR>Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП. Моё неправильное понимание ООП позволяет сформулировать несколько условий для того, чтобы это имело смысл:

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

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

Здравствуйте, Sinclair, Вы писали:

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

Здравствуйте, Sinclair, Вы писали:

I>>Вобще говоря так и делается в целях оптимизации.
S>А можно поподробнее? Что именно вы оптимизируете?

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

Здравствуйте, Ikemefula, Вы писали:

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

Здравствуйте, Ikemefula, Вы писали:

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

Здравствуйте, Steamus, Вы писали:

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

Что характерно, в ФП ровно тоже самое — абстрагироваться от неважного

И ФП дает синтаксический способ фиксации этих вещей.

Здравствуйте, Sinclair, Вы писали:

I>>Если не согласен, то например, напиши робота который умеет играть в покер на нескольких популярных сайтах и что бы чисто вычметоды были никакого ООП. Не нравится покер — пусть будет блекджек или баккара.
S>По легенде, первый покерный робот был разработан задолго до появления ООП. Примерно в те времена, когда фон Неймановская архитектура была непроверенной новинкой.

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

Здравствуйте, Ikemefula, Вы писали:

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

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

Нуууу... а как быть с бесклассовыми вариантами ООП?

0>>По мне это самый сомнительный момент в аргументации. Как можно с уверенностью заявлять о гомоморфизме чего-то нечеткого с чем-то непонятным?

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

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

0>>тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.
I>"отупления" нет. Есть снижение среднего уровня за счет притока свежих и как правило низкоквалифицированых специалистов. Нужно только понимать, что низкоквалифицированые они как программисты, а как специалисты в другой области наоборот, бывает очень даже высококвалифицированые.
Но нет снижения *среднего уровня* трудных для понимания возможностей ЯП.

I>Примерно как в шахматах — первый разряд, кмс, мс, гроссмейстер

Ну это так... абстрактно

Я пока знаю одну характеристику, неплохо кореллирующую: опыт интенсивной работы программистом в годах.
Но и то не всегда надежно.

Здравствуйте, Mamut, Вы писали:

M>Кхм. В итоге ты размазываешь непонятно что десятком предложений

По ссылке — как раз яркий пример, что мы не мыслим объектами

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

Допонятийная [стадия] — это начальный этап развития мышления у ребенка, когда последнее имеет иную, чем у взрослых, организацию. Суждения детей — единичные, о данном конкретном предмете. При объяснении чего-либо все сводится ими к частному, знакомому. Большинство суждений — по сходству или по аналогии, поскольку на этой стадии главную роль в мышлении играет память. Самая ранняя форма доказательства — пример. Учитывая такую особенность мышления ребенка, когда его убеждают или что-то ему объясняют, необходимо подкреплять свою речь наглядными примерами.

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

Здравствуйте, -VaS-, Вы писали:

SV.>>Да, самое главное. Надо помнить, что эволюция идет постепенно. Может быть, через пару лет и в Яве будет все в порядке с обработчиками и предикатами. А вот если они упрутся, и по идеологическим причинам не станут их вводить, тогда и скажем — заставь дурака...

VS>В Java 8 лямбды будут. И много чего еще.

Будет интересно посмотреть.

Здравствуйте, elmal, Вы писали:

IT>>Т.е. ООП, ФП и другие подходы для тебя просто инструменты для достижения определённых целей? А твоя цель — "чтоб не копипастить"?
E>Цель — чтобы гораздо меньшими усилиями выполнить работу и чтоб потом это можно было поддерживать. Я на проектах обычно долго сижу, и последствия принимаемых решений мне видны. Накосячу — разгребать и отвечать мне. Даже ненависть к копипасту — это следствие. А чтоб сделать именно так круто, как в книжке написано — у меня этой цели уже очень и очень давно нет.

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

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

Что касается "чтоб потом это можно было поддерживать". У вас новые кадры подключаются к проекту? Бывает такое? Или, может быть, новые кадры используют библиотеки/API, которые вы пишете? Если да, то ООП помогает им быстрее соотнести ваш код с решаемыми им задачами. Не больше и не меньше. Избавляться от копипаста оно определенно не помогает.

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

Здравствуйте, Wolverrum, Вы писали:

W>SV:
W>

W>Надо признаться себе, наконец, в том, что все эти вещи, которыми так гордится современная молодежь – автоматический контроль памяти, суперстрогая типизация, встроенный компилятор и обработка исключений – это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

SV.>>...и это невероятно печально.
W>Это невероятно нормально, потому что:
W>ООП — это костыли для рожденных ползать. С их помощью они с грехом пополам могут привстать и пойти, но тем, кто умеет бегать по краю пропасти, они не нужны.

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

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

W>ЗЫ Вот Вы так о духе ООП категорично рассуждаете, а свой сайт на php написан... И тормозит. Если первое простительно то второе на фоне рассуждений кажется неприемлемым.

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

Здравствуйте, pkl, Вы писали:

pkl>Какая цель топика? Повозмущаться существованием в природе всяких уродов? Ну дальше что? Сам без греха? А ну ка быстро кинул в меня стотонный камень.

Цель — послушать вас. Узнать, согласны, не согласны.

Здравствуйте, AndrewVK, Вы писали:

AVK>Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.

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

Здравствуйте, kittown, Вы писали:

K>Уточню — сложные иерархии строятся на этапе обучения и освоения.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, SV., Вы писали:

SV.>

SV.>Допонятийная [стадия] — это начальный этап развития мышления у ребенка, когда последнее имеет иную, чем у взрослых, организацию. Суждения детей — единичные, о данном конкретном предмете. При объяснении чего-либо все сводится ими к частному, знакомому. Большинство суждений — по сходству или по аналогии, поскольку на этой стадии главную роль в мышлении играет память. Самая ранняя форма доказательства — пример. Учитывая такую особенность мышления ребенка, когда его убеждают или что-то ему объясняют, необходимо подкреплять свою речь наглядными примерами.

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

Здравствуйте, SV., Вы писали:

SV.>Что касается "чтоб потом это можно было поддерживать". У вас новые кадры подключаются к проекту? Бывает такое? Или, может быть, новые кадры используют библиотеки/API, которые вы пишете? Если да, то ООП помогает им быстрее соотнести ваш код с решаемыми им задачами. Не больше и не меньше. Избавляться от копипаста оно определенно не помогает.
А почему именно ООП помогает? Я же говорю, что помогать может не только ООП, но и ФП, АОП, Декларативный П, и даже Императивный П. В проекте много различных задач, для одних лучше один подход, для других другой. И рулит именно комбинация подходов. Применять же ООП вообще ко всему слепо, просто потому, что оно ООП и оно рулит — путь к провалу проекта.

Здравствуйте, Ikemefula, Вы писали:

I> Lazy Cjow Rhrr предложил пример для ООП : вычисление состояния поверхности лужи в которую бросили камень. Я предложил аналогичный пример — интернет робот для карточной игры на дифурах и новье-стокса.
Не вижу ничего аналогичного. Уравнение Навье-Стокса и ООП не являются членами одного и того же понятийного ряда. С тем же успехом можно было предложить построить робота для карточной игры на деепричастиях.

I>Не, неинтересно. Lazy Cjow Rhrr изрек и подкрепил дополнениями следующее "Так что ООП может моделировать только ту действительность, которая (внезапно!) подходит к тому, чтобы быть промоделированной через ООП"

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

Здравствуйте, 0x7be, Вы писали:

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

Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."

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

0>Нуууу... а как быть с бесклассовыми вариантами ООП?

Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."

0>>>По мне это самый сомнительный момент в аргументации. Как можно с уверенностью заявлять о гомоморфизме чего-то нечеткого с чем-то непонятным?

I>>Есть несколько теорий мышления.
0>Очень хорошо, с какой из них проводилось сравнение?

Точное название я не помню

Все книги по этому вопросу дома и где то полгода я в них не заглядывал.

0>Вообще, кстати, вопрос интересный — есть ли научное подкрепление это мантры про людей, которые мыслят объектами?

Спроси у автора этой мантры а не у меня, я вроде как говорил про понятия и абстракции а не объекты.

0>>>тем больше заимствований из "гиковских" языков мы будем видеть в мэйнстриме. Какого-то особенного движения в сторону отупления программистов я не вижу.
I>>"отупления" нет. Есть снижение среднего уровня за счет притока свежих и как правило низкоквалифицированых специалистов. Нужно только понимать, что низкоквалифицированые они как программисты, а как специалисты в другой области наоборот, бывает очень даже высококвалифицированые.
0>Но нет снижения *среднего уровня* трудных для понимания возможностей ЯП.

I>>Примерно как в шахматах — первый разряд, кмс, мс, гроссмейстер

0>Ну это так... абстрактно

Результаты в соревнованиях можно заменить результатами по всем проектам.

0>Я пока знаю одну характеристику, неплохо кореллирующую: опыт интенсивной работы программистом в годах.
0>Но и то не всегда надежно.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Человеческое мышление — штука мутная. Поэтому опираться тут можно только на эмпирику. И вот что примечательно — инженерная дисциплина развивается уже лет 200 точно, но до сих пор основным инструментом борьбы со сложностью остается введение абстракций, иерархических абстракций. А программирование, если речь о реальности, а не о безумии в этом топике с дверями, все таки раздел инженерии, а не шаманство. Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
AVK>1) Создания абстракций с формальным описанием внешних свойств
AVK>2) Группировки этих абстракций в более крупные с неограниченным количеством уровней вложенности.
AVK>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.
AVK>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше. Поэтому приходится либо склеивать с ООП, либо придумывать дополнительные, помимо ФВП, сущности типа хаскелевских классов типов.
Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике. И там абстракции находятся в более сложных отношениях, чем отношения иерархии.
Имхо, ООП успешно не потому, что оно как-то особенно похоже на привычный нам способ выделения абстракций, а по более банальным причинам: производственное удобство. Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

Здравствуйте, Sinclair, Вы писали:

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

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

Что, если немного приблизить сложность задачи к той, которую мы видим в реальным проектах? Скажем, надо решить квадартное уравнение... с точностью до i-ого знака, i может быть любым (в разумных пределах). И арифметику желательно сделать реюзабельной, чтобы студенты из соседнего отдела на ее основе написали решатель линейного уравнения. Вот теперь и поговорим про нечитабельность оошного кода.

Здравствуйте, grosborn, Вы писали:

G>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Есть класс координат нужен для оптимизации по перформансу и памяти. В кратце нужно сделать так что бы каждый экземпляр обновлялся ровно один раз. Если координаты это просто значения, то это не выйдет. А если объект, то у него есть идентити и можно сократить физически количество экземпляров и обновлять без лишних издержек.
S>Для этого "объект" избыточен.

"обновлять без лишних издержек" тут наверное надо подробнее — вся логика обновлений координат инкапсулирована в один класс, в ём два метода invalidate и update + свойства для доступа к значениям в конкретной системе координат.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос сложный. Основной опыт формализации знаний накоплен более-менее в математике.

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

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

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

S> Инкапсуляция позволяет нам провести границы взаимодействия между программистами (а то и командами) и вести более-менее независимую разработку.

Это уже следствие из необходимости применения абстракций. В проектировании реальных железок все тоже самое — двигатель авто, к примеру, проектируется независимым КБ обычно, и на входе формальные спецификации. Поэтому с терминами можно играться как угодно, но практический выхлоп пока строго один.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

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

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

Здравствуйте, Ikemefula, Вы писали:

I>Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."
I>Цитирую себя: "Классы это один из способов работы с абстракциями, не единственный..."
I>Спроси у автора этой мантры а не у меня, я вроде как говорил про понятия и абстракции а не объекты.
Ну так я его спросил, он пока ничего не ответил.

I>Результаты в соревнованиях можно заменить результатами по всем проектам.
Результат игры в шахматы просто интепретировать.
Результат в проекте — нет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, kittown, Вы писали:

K>>Уточню — сложные иерархии строятся на этапе обучения и освоения.

AVK>Сложные иерархии строятся на этапе проектирования сложных систем. Обучение тут совсем за рамками. А использование готовых систем без создания нового, это уже не инженерная дисциплина.

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

Здравствуйте, 0x7be, Вы писали:

I>>Результаты в соревнованиях можно заменить результатами по всем проектам.
0>Результат игры в шахматы просто интепретировать.
0>Результат в проекте — нет.

А кто говорил что это легко ? Во всяком случае более мнее отранжировать специалистов все таким можно.

Здравствуйте, kittown, Вы писали:

K>Я про другое. Мы (люди) сознательно оперируем иерархическими абстракциями (в том числе, строим их) в основном на этапе обучения и освоения новых данных

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Klapaucius, Вы писали:

K>А вот вывод меня просто таки обескураживает.

Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле. Только вот твои качественно-экспертные оценки лично меня нисколечко не убеждают.

K>1) — абстракции в ООП слабенькие и протекающие, но это можно исправить

Субъективно

K>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств

Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

K>2) у ООП не то что плохо — 2) там нет вообще, ведь комбинаторы объектов не могут существовать в коде на ООП языках — они существуют только в уме ООП программистов в виде "паттернов" и не формализованы.

Вообще какая то игра терминами. Наследование и агрегация — основные способы комбинирования в ООП — вполне себе удобные способы комбинирования, хоть и не идеальные.

AVK>>ФП этому тоже в какой то мере соответствует за счет комбинирования ФВП, но ограничений у этой техники побольше.
K>А вот у ФП проблем, наоборот, поменьше.

У чистого ФП — больше. Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга, туплов, АлгТД и т.п. Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

K>Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа.

Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Klapaucius, Вы писали:

AVK>>Это, конечно же, не обязательно приводит к современному ООП, но таки ООП неплохо этому соответствует.

K>А вот вывод меня просто таки обескураживает. Потому, что у ООП плохо с 1) — абстракции в ООП слабенькие и протекающие,

Это зависит от задачи.

K>А вот у ФП проблем, наоборот, поменьше. Лучше всего с 2), с 1) проблемы есть, но их меньше, чем в ООП. В тотальном ФП проблемы с 1) более-менее исправляются.

А как быть с чистотой АПИ у ФП ? Здесь, мягко говоря, конь не валялся.

AVK>>Поэтому приходится либо склеивать с ООП,

K>Реальное преимущество ООП — простота реализации ОО-языка.

Простота реализации вообще ничего не значит, наглядным примером является такой язык как С++

Здравствуйте, AndrewVK, Вы писали:

K>>Я про другое. Мы (люди) сознательно оперируем иерархическими абстракциями (в том числе, строим их) в основном на этапе обучения и освоения новых данных

AVK>Я думал здесь все таки применение тех или иных подходов в промышленном программировании обсуждали. Для обучения или в качестве зарядки для ума совсем другие критерии требуются.

Я не про критерии.

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

AVK>Не вижу логической связи. И почему за несколько веков никто не додумался до лучшей альтернативы?

Лучшей альтернативы чему ? Это и есть наиболее эффективная организация работы — одни оперируют абстракциями и пишут процедуры, другие их используют как есть. Первые при этом тормозные исполнители, а вторым лучше не доверять работу на высоких уровнях абстракции. Хорошо проявляется на примере стандартных библиотек. Наиболее эффективна разработка там, где готовых библиотек уже достаточно, и надо лишь связать компоненты glue-кодом с минимум специфичной логики (настолько минимумом, что он весь легко описывается блок-схемами).

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

Здравствуйте, kittown, Вы писали:

K>Я не про критерии.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>>>О, уже timeModel появилось.
V>>Дык, курить численное интегрирование. Куда же без них-то в моделировании процессов во времени, без аттрибутов времени T0, Tn и dt? Аж никуда.
S>Сколько ни кури, ООП в численном интегрировании так и не появится.

ООП рулит в области иммитации/моделирования. А если это моделирование во времени, то аппарат численного интегрирования тоже всех заруливает. Да собственно, на этом построена вся современная обработка сигналов. Посмотри хотя бы на графы DirectShow. Как ты думаешь, что там в узлах графа? Ууупссс? ))

V>>Самая обыкновенная глобальная область, которая на известных тебе структурных диаграммах UML обозначается в виде специального объекта-синглтона. Чтобы некоторые не задавали глупых вопросов.
S>Давайте пока не будем отклоняться от темы в сторону UML и прочих левых нотаций.

На примере нотации можно объяснить людям происходящее.

S>Пока что вы предлагаете переместить состояние timeModel из специального объекта-синглтона в специальный объект-синглтон.

timeModel не обязан быть ни специальным, ни синглтоном. Я могу его переместить лишь в случае, когда этот объект является константой, то бишь в программе будет не предусмотрена настройка параметров численного интегрирования.

S>И не хотите, чтобы я задавал глупые вопросы.

Да ради бога, задавайте. Только никто не запретит мне называть глупые вопросы глупыми.

S>Я всё правильно понял?

Пока что всё неправильно. Наверно в пылу спора забыл, что в любимом дотнете не бывает экземплярных констант, то бишь они всегда глобальные (с т.з. экземплярности). Разве не упс? ))

V>>Дык, а кто мешается этому синглтону уметь отправлять сообщения?
S>Лезвие Оккама. А больше — ничего. Мы можем сделать целый массив длины 1 из массивов длины 1 из объекта специального унитарного класса, который будет отправлять сообщения самому себе, и это всё ещё не будет ничему противоречить. Ну, кроме чувства прекрасного.

Это у тебя какое-то неправильное чувство. Оно у тебя забывает, что отправку сообщений надо как-то инициировать, из воздуха сообщения не берутся. Поэтому существует понятие т.н. "активный объект". Это тот, который получив управление в некоем потоке исполнения генерит события для остальных. Даже для самого себя. Даже если тупо в цикле от T0 до Tn вызывается update(..., dt).

Например, в любимом тобой DirectShow этими активными объектами являются... являются.... о нет, только не это... ТАЙМЕРЫ! Ууупссс? )))

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

Граница проходит по выбранным технологиям, и больше ни по чему. Сама процедура выбора — это проявление воли разработчика и ничего более. Бога с т.з. IT нет.

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

Здравствуйте, AndrewVK, Вы писали:

K>>Я не про критерии.

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

И я про него. Возвращаясь к вашему первоначальному:

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

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

Здравствуйте, AndrewVK, Вы писали:

K>>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств
AVK>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

Какими?

AVK>У чистого ФП — больше. Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга, туплов, АлгТД и т.п. Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.

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

K>>Это не дополнительная сущность. Это просто подстановка набора функций в ФВП в зависимости от типа.
AVK>Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

Тайп-классы нужны, чтобы вместо того, чтобы писать:

doSomeMath (+) (-) x y = ...

Написать просто:

doSomeMath x y = ...

Набор "спецификаций", что характерно, как был, так и остался в сигнатурах функций.

Здравствуйте, kittown, Вы писали:

K>Одни люди разрабатывают абстракции,

Про них и речь.

K> другие — пишут конечный софт с их применением.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Воронков Василий, Вы писали:

AVK>>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.

ВВ>Какими?

Монады сгодятся?

ВВ>Каким образом карринг может являться подпоркой чего-либо?

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

ВВ>Кортежи и алгебраические типы не нужны — они не являются дополнительными сущностями, и введены просто для удобства

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

AVK>>Ага, веревка суть вервие простое. Набор функций как раз и потребовался из-за проблем с хранением всей спецификации в сигнатурах функций.

ВВ>Набор "спецификаций", что характерно, как был, так и остался в сигнатурах функций.

Только вот задавать его стало проще.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vdimas, Вы писали:

V>>Я возражал лишь на это:
V>>

V>>Серебряной пулей тут является умение мыслить несколькими парадигмами и свободное переключение между ними. Правда, некоторые передовики производства утверждают, что ещё лучше — умение ваять DSL под каждую задачу.

S>Ну так DSL вовсе не обязан быть мультипарадигменным. Представим, что у нас нет, скажем, Пролога. В его отсутствие мы можем быть вынуждены писать решение на адской смеси из, скажем, SQL (для хранения фактов) и, скажем, Java (для собственно обработки). А можем родить Пролог и получить "однопарадигменный" язык, который окажется удобнее, чем сразу две парадигмы.

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

V>>Спорить не буду, но и соглашаться тоже. Я видел много кода на оракловом процедурном SQL в т.ч. реализованную интероперабельность с java-объектами, которые хостятся на серваке (тут Оракл был раньше MS). И скажу так, что претензии у меня по большей части к динамической природе языка, а не к его мультипарадигменности.
S>Ну, а я вот видел много кода на T-SQL. В основном в хранимках. И там сразу видно, что те вещи, которые должны быть простыми, выглядят просто чудовищно. Банальные "из двух мест взяли, в третье положили", которые так и пишутся тремя строчками на приличном general purpose language — это адский взрыв мозга на T-SQL.

Простое взяли и положили как раз таки выглядит легко:

select a into b.

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

S>Интероперабельность с объектами — это всё цветочки. Вы посмотрите на OQL — вот где тру ООП-в-SQL. Он так и не взлетел никогда по причине чудовищной ужасности.

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

Здравствуйте, samius, Вы писали:

V>>То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

S>Какой-какой побочный эффект

В упомянутом смысле.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>То бишь в чистом ФП (якобы чистом) оператор if создает побочный эффект в том смысле, что задает порядок вычислений трех выражений-аргументов ф-ии if: predicate, then и else.

S>>Какой-какой побочный эффект

V>В упомянутом смысле.
Не имею понятия о побочных эффектах в упомянутом смысле. Ты походу описываешь C++ if-оператор, нет? Там — да, там then/else выполняются и портят мир. А хаскель даже не вычисляет then/else, потому оператор if эквивалентен соответствующей функции с точностью до некоторых нюансов, не имеющих отношение к побочным эффектам.
http://www.haskell.org/haskellwiki/If-then-else

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.
ВВ>>Какими?
AVK>Монады сгодятся?

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

var x = 2;
x = 3;

он посидит, подумает, и через какое-то время сам изобретет что-то вроде bind-а.

Во-вторых, монада как абстракция может вообще рассматриваться как простая абстракция для контейнера с двумя функциями, одна это обычный map, вторая — join. На примере списка — map это map, join — это concat, т.е. concat [1,2],[3,4]] = [1,2,3,4]. Пока ничего мозговзрывающего, правда? К тому же все это есть в линке, который вроде тоже мозги не взрывает.
Имея эти две функции, мы можем написать третью на их основе — join (map f xs). Надо полагать, что именно тут мозги и взрываются? А ведь это же просто SelectMany

И по сути — это все.
Если, конечно, пользоваться bind напрямую, то синтаксис получается не очень, но для того и ввели do нотацию. Код в do нотации вообще выглядит как самый обычный императивный код.

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

Да нету никакого акта каррирования, все функции "по умолчанию" и так каррированы. Ты видимо все же имеешь в виду частичное применение — ну так они является естественным следствием того, что функции с несколькими параметрами имитируются вложенными функциями. Это же вообще голая лямбда.

ВВ>>Кортежи и алгебраические типы не нужны — они не являются дополнительными сущностями, и введены просто для удобства
AVK>Так и я про то, что для удобства в ФП точно так же приходится вводить ряд подпорок, потому что без них код станет слишком многословным и недостаточно абстрактным.

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

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

Разве это плохо? И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

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

S>>>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

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

Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).

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

Здравствуйте, Воронков Василий, Вы писали:

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

Ага, все просто когда наконец мозги себе поломаешь. Ну так и в ООП тоже все просто в таком разрезе.

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

А я этого нигде и не писал.

ВВ>Они просто позволяют писать короче и выразительнее.

А ФП и ООП в целом, это тоже про короче и выразительнее.

ВВ>>>Набор "спецификаций", что характерно, как был, так и остался в сигнатурах функций.
AVK>>Только вот задавать его стало проще.

ВВ>Разве это плохо?

Разве я писал что плохо? Я писал о другом — ФП как парадигма не лучше ООП, а в чем то даже хуже. И если уж искать в ООП соринки, то и бревна ФП неплохо бы тогда упоминать.

ВВ> И почему это является подпоркой? Мы не вышли здесь за рамки чистого ФП.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, elmal, Вы писали:

SV.>>Что касается "чтоб потом это можно было поддерживать". У вас новые кадры подключаются к проекту? Бывает такое? Или, может быть, новые кадры используют библиотеки/API, которые вы пишете? Если да, то ООП помогает им быстрее соотнести ваш код с решаемыми им задачами. Не больше и не меньше. Избавляться от копипаста оно определенно не помогает.
E>А почему именно ООП помогает? Я же говорю, что помогать может не только ООП, но и ФП, АОП, Декларативный П, и даже Императивный П. В проекте много различных задач, для одних лучше один подход, для других другой. И рулит именно комбинация подходов. Применять же ООП вообще ко всему слепо, просто потому, что оно ООП и оно рулит — путь к провалу проекта.

Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.

Здравствуйте, AndrewVK, Вы писали:

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

Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы. Но кое-какие абстракции вносить разрешается (вьюшки с вычисляемыми полями в базе). Другим — Objective-C или Java.

Здравствуйте, SV., Вы писали:

SV.>Мужики, вы чем ваще занимаетесь, а? Дверь, корова — вы взрослые люди, инженеры, или кто? У каждого, кто хотя бы лет 5 проработал в нашей промышленности примеров и контрпримеров должно быть полные карманы.

1)
В чистом виде ООП практически не встречается — не следит никто за чистотой парадигмы. Почти везде компромис между сложностью/трудоёмкостью и ленью программистов.
Идеальный код — название книжки, а в реальной жизни он не встречается.

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

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

Здравствуйте, kittown, Вы писали:

K>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы

Это не программисты уже в привычном понимании.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, SV., Вы писали:

SV.>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.

public class NotNullUtils {
    public static <T> List<T> processNull(List<T> list) {
        if (list == null) {
            return new ArrayList<T>();
        }
        return list;
    }

    public static String processNull(String string) {
        if (string == null) {
            return "";
        }
        return string;
    }
...

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

Здравствуйте, SV., Вы писали:

SV.>Sinclair'у про квадратные уравнения я ответил, что это — простейшая функция, которую проходят в средних классах школы и он бы еще 2 + 2 складывал в объектной парадигме. Если взять реальную (по сложности) инженерную задачу, типа, написать тот же решатель квадратных уравнений, НО! с любой заданной точностью, с реюзабельной арифметикой и хорошей интегративностью, ООП будет вне конкуренции по понятности кода такого проекта для новичков (а других свойств я ООПу и не приписывал).
Выделенное неплохо бы обосновать. Но только не тем, что новички сначала проходят ООП, а потом все остальное. Бывает и по-другому.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Сложение коммутативно. Это значит, что 1 + 2 должно быть то же самое, что и 2 + 1. Чтобы более рельефно отразить проблему я запишу это как 1.0 + 2. Внезапно классы Integer и Float оказались связанными одной цепью — метод Integer.+(Float) обязан быть тождественным методу Float.+(Integer). А если ты захочешь добавить класс Rational как пару целых чисел, и реализовать сложение с вещественными числами, тебе надо будет во-первых перечислить в этом классе все возможные случаи, а во вторых хакнуть все системные классы, и добавить туда _.+(Rational).

LCR>Поехали дальше. Есть ещё такие штуки как отношения — это подмножества декартова произведения множеств. Ну там <, =<, ==, какие-нибудь хитрые отношения частичного порядка. И частенько бывает, что от отношений требуется симметричность, и транзитивность. Симметричность, это когда x (R) y совпадает с y (R) x для любых x и y. Если мы реализуем отношение как приклеивание метода r к объекту, мы вступаем на зыбкую почву. Мы должны гарантировать, что x.r(y) есть то же самое, что и y.r(x) для любых пар (это довольно легко, если x и y одного класса), но что если x и y принадлежит различным классам, но как значения концептуально эквивалентны? Например, всё тот же класс Rational и мы хотим чтобы оно проверялось на равенство с вещественными числами. Или чуть сложнее: мы например можем ввести отношение == на списках, пусть они будут эквивалентны, если они поэлементно равны.

...

LCR>Да, пример Account интересен, я тоже жду продолжения.

Сильно. Да. Очень сложно приткнуться к дискуссии. Про Account — согласен.

Здравствуйте, samius, Вы писали:

S>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

Что значит "рулит"?

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

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

Здравствуйте, Mamut, Вы писали:

M>Где ты видишь бред? Бред пока у людей, которые неспособны подтвердить свой тезис, что ООП прекрасно моделирует реальность.

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

Здравствуйте, Sinclair, Вы писали:

Противоречие самому себе:

* специальный метод bool isOpen().
* видите, открыта ли дверь.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

V>Что значит "рулит"?
значит крут

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

V>Уже смогли.
Можно пример с убедительным доказательством что модель является действительно минимальной?

V>Мозг мыслит абстракциями, то бишь упрощениями. Именно абстрагирование от подробностей позволяет мозгу систематизировать и накапливать знания. Иначе не было бы никакого "обучен".
И причем тут ООП?

Здравствуйте, Sinclair, Вы писали:

S>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты?

Как минимум глаза, получающие сообщения от рецепторов света.

Здравствуйте, Mamut, Вы писали:

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

Враки. Если бы действие по открыванию двери принадлежало самой двери, то он бы написал this.открыть(), а если он пишет дверь.открыть(), то явно эту дверь открывает кто-то другой.

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

M>Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

Дык, если ты хочешь совершить бредовую замену, типа: мусор.выкидывайся(), то да, а если небредовую с т.з. реального мира: мусороконтейнер.принять(мусор), то сразу всё ОК.

M>ООП всегда является очень грубой, и не всегда корректной моделью мира — как и любая другая модель.

Любое ПО является лишь моделью мира.

Здравствуйте, samius, Вы писали:

S>>>Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

V>>Что значит "рулит"?
S>значит крут

Крут? )))
Добро пожаловать в реальный мир, Нео:

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

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

V>>Мозг мыслит абстракциями, то бишь упрощениями. Именно абстрагирование от подробностей позволяет мозгу систематизировать и накапливать знания. Иначе не было бы никакого "обучен".
S>И причем тут ООП?

При том, что мы склонны наделять свои абстракции-образы:
— характеристиками;
— поведением, зависящим от характеристик;
— отношениями с другими абстракциями.

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

Указанный выше список разве не описывает ОО-парадигму?

Здравствуйте, samius, Вы писали:

V>>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль. Некие выражения вычисляются заведомо РАНЬШЕ других, формируя итоговый порядок вычислений. И что характерно, в Хаскеле на этот заданный порядок вычислений можно полагаться безо-всяких монад. Как раз было обсуждение насчет комбинаторных парсеров на Хаскеле в тему.
S>Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться.

S>Тут вообще в SP речь об операциях, точнее об statement-ах (см http://en.wikipedia.org/wiki/Structured_programming).
S>Согласно http://en.wikipedia.org/wiki/Imperative_programming
S>

S>In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state.

S>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

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

Здравствуйте, samius, Вы писали:

S>Это не ООП находит для себя удобным. Это ты находишь для себя удобным. Говорить о том что это общепринято в ООП рановато. ООП может делать обновление состояний и без ФП вобщем-то.

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

V>>а в ФП изо всех сил лезут гарантии обслуживания "одних и тех же логических экземпляров сущностей", в виде разного рода монад, задача большиснтва которых — изолировать независимые вычислительные потоки друг от друга без механизма многопоточности.
S>А, ну точно, монады в ФП прилезли ведь из ООП, что бы обходиться без механизма многопоточности, в точности как у ООП

(снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)

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

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

Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?
S>>В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

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

Здравствуйте, elmal, Вы писали:

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

Отличный пример. Борьба с нулевыми ссылками — это главная на сегодня фишка ООП.

Здравствуйте, Философ, Вы писали:

Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.

А зачем его туда тулить? У тебя методы объектов из чего состоят-то? Из вызовов методов других объктов? А те, в свою очередь? А где же, собственно, начинается полезный код?

А то тут уже некоторые предлагали изъять арифметику из ООП.

Ф>Разве что само уравнение представить в виде объекта

Если требуется изменяемое состояние — то можно и представить? Или не требуется?

Ф>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...

От задачи зависит. В какой-нить моделирующей штуке с квадратичной зависимостью от чего-либо вычисление квадратного уравнения могло быть частью какого-нить метода.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Так продемонстрируй этот рояль, сделай его семантически обозримым. Тока без бэкдоров c IO.

V>Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться.
Покажи сайд-эффект if-а Хаскеля, не балаболь.

S>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

V>Полнейшее бла-бла-бла...
V>Функциональная программа так же состоит из выражений языка, которые в процессе работы меняют состояние программы. Просто некоторые слишком молодые адепты ФП в пылу споров забывают, что состояние стека вычислений + положение указателя инструкций в потоке исполнения образуют то самое состояние программы.
Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.

Здравствуйте, vdimas, Вы писали:

V>Противоречие самому себе:
V>

V>* специальный метод bool isOpen().
V>* видите, открыта ли дверь.

Где противоречие?

Здравствуйте, vdimas, Вы писали:
V>"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания.
В С и паскале ссылочные типы данных имеются в полный рост, без малейших признаков ООП.
В коде x86 есть понятие указателей, но нет понятия объектов.

V>Занавес.
Опять клоунада? Я говорю не про макросистему, а про команды косвенной адресации.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Это не ООП находит для себя удобным. Это ты находишь для себя удобным. Говорить о том что это общепринято в ООП рановато. ООП может делать обновление состояний и без ФП вобщем-то.

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

S>>А, ну точно, монады в ФП прилезли ведь из ООП, что бы обходиться без механизма многопоточности, в точности как у ООП

(снова гипербола. Буду обозначать, что бы ты мной свою очередь не занимал)

V>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но.
нет, не могу. Уже надоедает.

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

V>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.
А что делает ссылочный тип в чистом ФП (это раз)? А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).

А что там с Немерле?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".
1. Тут нет ничего ОО-шного. Напомню, что ООП — это про посылку сообщений. То, что у нас операция сложения "внутри" реализована через отправку сообщений, вообще говоря лишняя подробность. Если ещё поглубже копнуть, то окажется, что и объектов никаких нету, а происходит банальный лукап по символьной таблице, а потом косвенный вызов.
2. Я вовсе не уверен в том, что операция __add__ реализована "объектным" образом, а не является всего лишь частью описания ADT. Ну вот struct-типы в дотнете, строго говоря, объектами не являются (не будучи забоксенными).
3. Проблемы, к которым приводит такой подход, хорошо описаны у Lazy Crow Rhrr: http://rsdn.ru/forum/philosophy/4837534.1.aspx

Здравствуйте, AndrewVK, Вы писали:

K>>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы

AVK>Это не программисты уже в привычном понимании.

Привычном для кого ?

Здравствуйте, Ikemefula, Вы писали:

I>Это зависит от задачи.

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

I>А как быть с чистотой АПИ у ФП ? Здесь, мягко говоря, конь не валялся.

Не понял вопроса.

K>>Реальное преимущество ООП — простота реализации ОО-языка.
I>Простота реализации вообще ничего не значит, наглядным примером является такой язык как С++

Эта проблема становится понятна в сравнении. Простота (сложность) реализации имеет значение, поэтому существующие реализации ФЯ делятся на три категории: игрушечные, компромиссные-и-недоделанные и несуществующие. При этом еще совсем недавно категории было две — первая и третья.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Sinclair, Вы писали:

S>Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом:
S>

S>(T, T) resolveSqEq<T>(T a, T b, T c);
S>

S>Потому, что алгоритму неважно, какая там точность. Ему важно, чтобы для T были определены операции умножения, сложения, возведения в степени -1 и 1/2, и получения обратного элемента. Всё. А, ещё пригодится константа 0.
S>Кормите алгоритм хоть октонионами, хоть матрицами — дайте определения операций, и дело в шляпе.

Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа (формат IEEE-666, 50 знаков). i = 100. Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?

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

SV.>>Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает.
S>У этого класса нет никакого поведения, поэтому совершенно непонятно, что именно инкапсулировать. "Состояние" объекта Account полностью прозрачно. Еще есть такая проблема, что в принципе понятие "состояние" у счёта штука очень условная. Грубо говоря, бухгалтерия — это набор проводок.
S>Исходя из этого набора мы можем высчитать всякие виртуальные вещи — типа "каков у нас остаток дебиторской задолженности на 1 августа 2012".

Ну а кто должен считать баланс? "Мы" — это кто? Состояния у нас нет, а есть обработчик суммы проводок, но где он у вас сидит? Кроме того, есть же еще функциональность типа обработки и хранения внешних атрибутов счета, не связанных с балансом.

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

У кого попросите? Да, забыл упомянуть. Если счет мультивалютный, то где и как мультивалютность будет обеспечиваться?

>Есть ещё куча показателей, которые совсем никак не похожи на "объекты", существующие объективно и независимо от наблюдателя — к примеру, тот же "оборот дебиторской задолженности за период".

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

S>Решение, в котором счета — это объекты, а проводки — сообщения, которыми они обмениваются, потребует гонять эти проводки туда-сюда каждый раз, как мне захочется заглянуть в прошлое. Внезапно обнаруженный первичный документ, датированный прошлым сентябрём, сломает нафиг эту модель, т.к. его не "вставишь" между уже отправленными сообщениями.

Это плохое решение, но оно результат плохой декомпозиции, а не подхода.

S>Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор. Проводка — это тоже не объект, а просто запись некоторого факта. Поверх этого рисуются всякие расчётные операции, которые тоже нифига не объекты, а просто формулы (уровня пятого класса). Сведение баланса = проведение примитивного расчёта.

Немного позже покажу, как такую задачу решал я.

Здравствуйте, samius, Вы писали:

V>>Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться.
S>Покажи сайд-эффект if-а Хаскеля, не балаболь.

В выделенном смысле уже показал.

S>>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.

V>>Функциональная программа так же состоит из выражений языка, которые в процессе работы меняют состояние программы. Просто некоторые слишком молодые адепты ФП в пылу споров забывают, что состояние стека вычислений + положение указателя инструкций в потоке исполнения образуют то самое состояние программы.
S>Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.

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

Здравствуйте, samius, Вы писали:

V>>Предположу, что только у наследованных от структурной.
V>>Например, в логическом программировании никакого ветвления нет.
S>Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет?
S>

Ты точно на этот пост хотел ответить? (см выделенное)

Здравствуйте, SV., Вы писали:

SV.>Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа X(формат IEEE-666, 50 знаков). i = 100.
Что такое i?
Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?
Я не понимаю вашего вопроса.
SV.>Надо ли говорить, что первой моей мыслью при ознакомлении с подобным проектом будет поискать класс, инкапсулирующий число, который умеет хранить его с заданной точностью, и поддерживает вход и выход?
Надо. Потому что эта мысль совершенно неочевидна. Зачем вы собрались искать "класс" для штуки, которая не обладает идентичностью и поведением?
Почему вы не хотите найти АТД, т.е. штуку, которая принимает некоторые значения и имеет некоторое определённое поведение?
То, что вы ищете "класс", выдаёт наличие шрамов в сознании, оставленных С++.

SV.>Ну а кто должен считать баланс? "Мы" — это кто? Состояния у нас нет, а есть обработчик суммы проводок, но где он у вас сидит?
Там, где удобно с точки зрения архитектуры программы.

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

S>>Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый.
SV.>У кого попросите?
Я — попрошу у программы. Мне всё равно, я пользователь.
SV.>Да, забыл упомянуть. Если счет мультивалютный, то где и как мультивалютность будет обеспечиваться?
Ну, я не настолько хорошо разбираюсь в бухгалтерии, чтобы сходу написать архитектуру мультивалютности. Но, надо полагать, что она будет обеспечиваться там же, где и всё остальное.

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

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

Здравствуйте, Sinclair, Вы писали:
S>Надо. Потому что эта мысль совершенно неочевидна. Зачем вы собрались искать "класс" для штуки, которая не обладает идентичностью и поведением?
S>Почему вы не хотите найти АТД, т.е. штуку, которая принимает некоторые значения и ~~имеет некоторое определённое поведение~~?
Тьфу блин, зарапортовался. Имелось в виду "для неё задан некоторый определённый набор операций". Поведения никакого у чисел нет.

Здравствуйте, samius, Вы писали:

V>>Реальность такова, что в ООП применимы любые наработки ФП безо-всяких адаптаций, зато наоборот — увы и ах.
S>твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.

Дык, в том-то и дело, что нет в природе никакого "нечистого ООП". Есть просто некие вычисления и есть сохранение результатов вычислений в полях объектов или передача их как сообщений другим объектам. Способ вычислений в ООП никогда не ограничивался, в отличие от чистого ФП, где полно ограничений.

А "нечистое ФП" — это процедурный подход + функциональный тип. ))

S>>>И причем тут ООП?

V>>При том, что мы склонны наделять свои абстракции-образы:
V>>- характеристиками;
V>>- поведением, зависящим от характеристик;
V>>- отношениями с другими абстракциями.

V>>За счет этого мы можем моделировать поведение окружающего мира, в свою очередь за счет этого у человека работает воля, появляется вообще такое понятие как работать "на будущее", будь это будущее даже не далее сегодняшнего ужина.
S>Бла-бла

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

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

V>>Указанный выше список разве не описывает ОО-парадигму?
S>и почему-же он описывает только лишь ее?

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

С отношениями в ФП тоже большие проблемы из-за наличия лишь одного вида декомпозиции — функционального.

Здравствуйте, SV., Вы писали:

SV.>Немного позже покажу, как такую задачу решал я.

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

Так вот. Свой счет я посадил бы поверх таблицы проводок, и он бы хранил внутренний уникальный идентификатор плюс банковскую атрибутику. Получение состояния на любой момент времени, оборотов за период (а также входящее и исходящее сальдо периода) было бы реализовано в нем в виде методов. Там же — валютный пересчет на основе входящей ссылки на объект, представляющий Форекс (или, по-простому, конфиг текущей сессии). И это как раз и есть модель реального счета. С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках. С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы.

Вся эта штука называется объектная модель.

S>Проводки так и останутся структурами, счета останутся идентификаторами.

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

Счет-то все равно объектом остается с соответствующими сообщениями:
— зарегистрировать еще одну операцию,
— вывести текущее состояние по счету,
— вывести историю операций и т.д.

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

Здравствуйте, Sinclair, Вы писали:

S>>>Вот выражение некоторой более-менее изолированной мысль: "скоро начнёт смеркаться". Какие тут можно выделить объекты?
V>>Как минимум глаза, получающие сообщения от рецепторов света.
S>Вы уверены, что эта мысль выражена внутри сознания именно в терминах глаз, рецепторов, и сообщений?

Внутри эта мысль выражена несомненно в терминах "прикладных" сигналов, получаемых от рецепторов. Лично я на твою фразу представил себе:
1. небо
2. оно еще не потемнело, но уже скоро
3. представил потемневшее небо

S>Я говорю не про реализацию, а про абстракцию.

Ты говоришь про процесс и результат, это совсем не тоже самое, что абстракция и подробности. Да, я представил себе сразу результаты, то бишь предполагаемую серию сигналов рецепторов, соответствующие словесному описанию образа, не замувашись о том, как именно это сигналы генерируются механизмом глаз и трансформируются в моей голове. Точно так же как юзверь программы получает сразу готовую форму на экране... В твоеём примере я юзверь, мне ООП не нужен ес-но, но для механизма реализации этой формы — бы неплохо. Вот почему я тебе привел "механизм". Ты же сам когда-то писал, что ООП — это не про задачу, а про решение. АБСОЛЮТНО верно.

Здравствуйте, Sinclair, Вы писали:

V>>Противоречие самому себе:
V>>

V>>* специальный метод bool isOpen().
V>>* видите, открыта ли дверь.

S>Где противоречие?

Осмотр двери — это получение неких ее визуальных характеристик. В т.ч. ее положения.

Здравствуйте, samius, Вы писали:

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

Это значит, что у ФП больше ограничений и границы проявляются очень четко.

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

DG>Например, когда заходишь в инет-банк, то со счетами работаешь как с объектами: выбираешь объект (счет, транзакцию) и посылаешь ему сообщение посредством нажатия соответствующей кнопки.
Очень странно. Лично я, когда захожу в инет-банк, никаких сообщений счетам я не посылаю. Сообщения я посылаю исключительно серверу, а сервер мне отвечает.
DG>При этом не важно, как он реализован в js-е или на сервере: как идентификатор, как запись в базе, как еще что-то — для использования через gui инет-банка, счет удобнее воспринимать как объект.
DG>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования)
А моя основная мысль, что счёт не ведёт себя как объект в ООП. Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".

Здравствуйте, Sinclair, Вы писали:

S>

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

Это не формы мышления, а высшие психические функциии.

Здравствуйте, Sinclair, Вы писали:

ВВ>>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".
S>1. Тут нет ничего ОО-шного. Напомню, что ООП — это про посылку сообщений. То, что у нас операция сложения "внутри" реализована через отправку сообщений, вообще говоря лишняя подробность.

Не понял. А кто нам запрещает сообщения отсылать в инфиксной форме? Это все сводится к семантике конкретного языка. В Смолтоке, кстати, инфиксные сообщения были. А это, если не считать Симулы, самая заря ООП.

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

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

S>2. Я вовсе не уверен в том, что операция __add__ реализована "объектным" образом, а не является всего лишь частью описания ADT.

Я не улавливаю разницы между "реализована объектным образом" и "является всего лишь частью описания ADT". Можно пояснить?
К слову, уверенным в чем-либо ты можешь быть лишь в рамках семантики конкретного языка, что логично. В Питоне ты вполне можешь быть в этом уверен.

S>Ну вот struct-типы в дотнете, строго говоря, объектами не являются (не будучи забоксенными).

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

S>3. Проблемы, к которым приводит такой подход, хорошо описаны у Lazy Crow Rhrr: http://rsdn.ru/forum/philosophy/4837534.1.aspx

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

По поводу конкатенации ленивых списков я вообще не понял проблему. Если ленивые списки превратить в IEnumerable, то в рамках того же C# контактенация двух бесконечных последовательностей описывается без всяких проблем во вполне объектном ключе. Вот только эта конкатенация не будет in-place что-либо модифицировать, а просто вернет новый "список". Неужто иммутабельные структуры данных противоречат ООП?

Здравствуйте, vdimas, Вы писали:

V>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному.

N+1 велосипед в этом топике про человеческое мышление.

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

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

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

Покажи на примере, как функциональная композиация несильно отличается от процедурной.

Здравствуйте, Ikemefula, Вы писали:

S>>

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

I>Это не формы мышления, а высшие психические функциии.

Анализ, синтез, сравнение и тд == Интеллектуальные функции, а не впф (мышление, речь, память).

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет?
S>>

V>Ты точно на этот пост хотел ответить? (см выделенное)

Точно

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.

V>Дык, в том-то и дело, что нет в природе никакого "нечистого ООП". Есть просто некие вычисления и есть сохранение результатов вычислений в полях объектов или передача их как сообщений другим объектам. Способ вычислений в ООП никогда не ограничивался, в отличие от чистого ФП, где полно ограничений.
Твои представления об ООП наивны.

V>А "нечистое ФП" — это процедурный подход + функциональный тип. ))
нечистое ФП вполне может быть испачкано ООП-ой

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

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

V>>>Указанный выше список разве не описывает ОО-парадигму?
S>>и почему-же он описывает только лишь ее?

V>Из-за поведения. В чистом ФП нет поведения, бо поведение — это побочный эффект, эта реакция, которая зависит от всей истории предыдущих воздействий. В ФП же "реакции" функций безусловные, зависят только от текущего воздействия.
С реакцией от истории в ФП все впорядке. Да и вся история как на ладони заодно.

V>С отношениями в ФП тоже большие проблемы из-за наличия лишь одного вида декомпозиции — функционального.
что не так с отношениями?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Ну вот а я считаю что там не точка соприкосновения, я считаю что ниши у подходов пересекаются в значительной мере. Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

I>Это значит, что у ФП больше ограничений и границы проявляются очень четко.
Так обозначь их

Здравствуйте, Ikemefula, Вы писали:

I>А что значит "мутнее образ" ? Вот скажем дорогу на работу я представляю как три отрезка примерно одинаковой длины. Это вроде как чистой воды абстракция. И где здесь "мутность" ?

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

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

I>Покажи на примере, как функциональная композиация несильно отличается от процедурной.

Легко. Для примера, любое замыкание — это пара: { ф-ия, замкнутый_контекст }. ФП-языки представляют эту пару в виде неделимого объекта. Заметь, исходно декомпозиция может идти по двум координатам, то бишь как по ф-ии, так и по замкнутому контексту, но реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии). Возвращаясь к декомпозиции по замкнутому контексту — этот вид декомпозиции присутствует в подробностях кода, то бишь на уровне дизайна им можно пренебречь. Аналогично как можно пренебречь процедурной декомпозицией в подробностях реализаций методов в ООП.

Здравствуйте, Sinclair, Вы писали:

SV.>>Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа X(формат IEEE-666, 50 знаков). i = 100.
S>Что такое i?

Точность числа, выраженная как количество цифр мантиссы (если не путаю, это называется количество верных значащих цифр).

S>Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?
S>Я не понимаю вашего вопроса.

var a = 10500L;
var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
    "578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
    "286583653786537568327856378256237238598978182371283e150";
var c = (byte[]) GetIeee666(d);

var aT = ...;
var bT = ...;
var cT = ...;

var Xs = resolveSqEq<T>(aT, bT, cT);

var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
    "вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
    "с небывалой точностью (100 знаков). Он равен: {0)", ... xS[0] ...);
var bin = ... Xs[1] ...;

db3000.SaveIeee666((byte[]) bin);

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

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, samius, Вы писали:

S>>>Ну вот а я считаю что там не точка соприкосновения, я считаю что ниши у подходов пересекаются в значительной мере. Причем я затрудняюсь назвать области, где рулит ООП и не рулит ФП. А наоборот — легко.

I>>Это значит, что у ФП больше ограничений и границы проявляются очень четко.
S>Так обозначь их

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

Здравствуйте, vdimas, Вы писали:

I>>А что значит "мутнее образ" ? Вот скажем дорогу на работу я представляю как три отрезка примерно одинаковой длины. Это вроде как чистой воды абстракция. И где здесь "мутность" ?

V>Мутность в том, что ты не помнишь каждый кустик, встречаемый тебе по дороге.

То есть, мутный у тебя стало синонимом абстрактный ?

Вообще говоря мутный это нечто, мешающее построить абстракцию.

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

I>>Покажи на примере, как функциональная композиация несильно отличается от процедурной.

V>Легко. Для примера, любое замыкание — это пара: { ф-ия, замкнутый_контекст }. ФП-языки представляют эту пару в виде неделимого объекта. Заметь, исходно декомпозиция может идти по двум координатам, то бишь как по ф-ии, так и по замкнутому контексту, но реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии).

Вот функциональная декомпозиция
Order(x => x.ABC)

А вот процедурная

OrderByHellKnowsWhat

Надо ли объяснять разницу ?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Это не только я нахожу и не я это изобрел. Эта лишь одна из практик, которая дополняет современное многопоточное ООП. Ведь ООП не отменяет ни атомарности, ни транзакционности. А понятие валидности состояния в нем было изкаробки.
S>>Многопоточный ООП? Ты опять что-то намешал.

V>Ох блин... Зачем МНЕ что-то намешивать, если за нас это намешивает окружающая действительность, то бишь для нас программистов — поступающие задачи. На сегодня многопоточное ООП считай что дано сверху. А требование валидности состояния всегда было. Вот и происходит в ООП наработка новых практик, доселе неактуальных.
Тут понимаешь ли, если в программе на ООП присутствует многопоточность, то многопоточность сама по себе, а ООП само по себе. А многопоточное ООП — это что-то новое.

V>Помнишь я тебе говорил про быстрое устаревание любого догматического подхода что к ООП, что к ФП? По мне порядка 15 лет — таки быстро.
Потоки родились не 15 лет назад. И ООП тоже постарше. Почему до сих пор нет парадигмы МООП или хотя бы статей или книг по нему?

S>>Ну и другими словами ты хочешь сказать что ООП без ФП не самодостаточен? Веский довод...

V>Что я хотел сказать, я уже сказал — методологии воруют полезные практики друг у друга. В этом смысле ФП точно так же не самодостаточен, т.к. тоже является комплексным набором практик. Забери любую из них и сделаешь ему хуже или вообще поломаешь.
так что же конкретно ФП своровал у ООП? Предлагаешь забрать, но не называешь что именно.

V>>>Монады в Хаскеле появились далеко не сразу, это факт. Класы типов — тоже. Иронизировать можешь до бесконечности, ес-но.
S>>нет, не могу. Уже надоедает.

V>Дык, тогда можно было бы по делу высказать/подумать, зачем в Хаскель появились монады?
Для удобства.

V>>>Глупости. Банальное понятие ссылочного типа ставит твой ФП раком, и никакая статика не помогает. См. Немерле.
S>>А что делает ссылочный тип в чистом ФП (это раз)?

V>А возражает на твою фразу:
V>

V>Мы гоняемся за гарантиями, мы хотим, чтобы компилятор нам помогал.
S>>Это банально справедливо для всей статики

ссылочный тип не имеет отношение к этой фразе. Компилятор помогает и без него.

V>Простых гарантий типобезопасности для работы ФП мало. Нужны еще ограничения на разновидности структур данных.
Ты же сам сказал о том что гоняемся за гарантиями. Не нужны гарантии, которые дают ФП структуры данных — велкам в ООП.

S>>А если очень надо, то IO в руки, как и с MutVar в соседней ветке (два).

V>О чем и речь, что эти вещи появились в Хаскеле не сразу... Собственно как и все вещи, связанные с требованиями мутабельности в реальных программах. Я просто ХЗ зачем отрицать факт заимствования из императивного мира.
Так что было заимствовано?

S>>А что там с Немерле?

V>Дык, когда мы объявляем иммутабельную переменную ссылочного типа, как далеко, по-твоему, распространяется иммутабельность? Предполагаемые участники:
V>1. сама ссылочная переменная;
V>2. объект, на который cсылается п.1;
V>3. объекты, на которые ссылается п.2.
Так это проблема не ФП в целом. Это проблема ФП на рантайме, заточенного под императив.

Здравствуйте, 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>

S>var aT = ConvertLongToHighPrecisionNumber(a);
S>var bT = ConvertStringToHighPrecisionNumber(b);
S>var cT = ConvertIeee666ToHighPrecisionNumber(c);
S>

S>Идея понятна?

Нет, поскольку вы недопереписали вывод типов. Что вернут конвертеры?

Здравствуйте, vdimas, Вы писали:

V>Гы, абстракция — это упрощение.
V>Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не?

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

I>>Вот функциональная декомпозиция
I>>Order(x => x.ABC)

I>>А вот процедурная

I>>OrderByHellKnowsWhat

I>>Надо ли объяснять разницу ?

V>Ес-но надо.
V>Для начала приведи эквивалентный по функциональности код и там и там.

Ну, имя неудачное, так будет яснее OrderByAbc

V>Если с наскока не получится — см. мою подсказку насчет того, что есть замыкание.

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

Ikemefula,

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

I>20 лет назад адепты ООП уже проходили это — http://lib.rus.ec/b/163426/read

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Это значит, что у ФП больше ограничений и границы проявляются очень четко.
S>>Так обозначь их

I>Легко, фп — вычислительные задачи "унутре" метода которые, кроме того, не требуют изменяемого состояния и всяких числодробилок.
Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.

I>Использование ФП на уровене АПИ пока что возможно только в закрытой нише, вроде Эрланга.
В закрытой от ООП языков что ли?

Здравствуйте, SV., Вы писали:

S>>

S>>Decimal static CalcBalanceForDate(Date date, allTransfers) 
S>> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>>

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

Здравствуйте, Sinclair, Вы писали:

S>

S>Decimal static CalcBalanceForDate(Date date, allTransfers) 
S> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>

И, кстати, откуда у вас статичность взялась?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Твои представления об ООП наивны.

V>Это твои представления об ФП догматичны. А мои об ООП ровно такие, каково состояние дел в ООП прямо на сегодня у лидеров рынка.

Прям пичалька за рынок взяла

V>>>А "нечистое ФП" — это процедурный подход + функциональный тип. ))
S>>нечистое ФП вполне может быть испачкано ООП-ой

V>Увы, тогда это будет уже скорее ООП. Оно итак испачкано ФП-ой чуть ли не изначально.
нечистое ФП — это скорее ООП.

V>>>Ключевое в связи ООП с мышлением я вижу именно в способности мышления человека моделировать окружающий мир.
S>>Ничего что до ООП человек тоже мог моделировать окружающий мир? Или возможность моделирования открыл Др. Кэй?

V>Гы, ничего, что сейчас ты показал умение переворачивать всё с ног на голову почище моего?

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

S>>С реакцией от истории в ФП все впорядке. Да и вся история как на ладони заодно.

V>Увы, если брать отдельно взятый функциональный объект — то не в порядке. В порядке там только при наличии состояния. А в чем оно заключается в "чистом ФП" (которое даже без монад) — я тебе уже писал... про стек вычислений и положение указателя команд в потоке исполнения.
Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал. Не занимается ФП отдельно взятыми из ООП объектами.

S>>что не так с отношениями?

V>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
Объекты — замыкания для бедных

V>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this.

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

Здравствуйте, samius, Вы писали:

I>>Легко, фп — вычислительные задачи "унутре" метода которые, кроме того, не требуют изменяемого состояния и всяких числодробилок.
S>Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.

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

I>>Использование ФП на уровене АПИ пока что возможно только в закрытой нише, вроде Эрланга.
S>В закрытой от ООП языков что ли?

В закрытой вообще от других языков. см выше.

Здравствуйте, DarkGray, Вы писали:

DG>Счет-то все равно объектом остается с соответствующими сообщениями:
DG>- зарегистрировать еще одну операцию,

Ох, не стал бы я так делать!

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Если ты решил не пускать ФП дальше нутра метода объекта, то это границы не ФП, это границы твоего применения ФП.

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

S>>В закрытой от ООП языков что ли?

I>В закрытой вообще от других языков. см выше.
Закрытость от других языков — слишком сильное утверждение.

Здравствуйте, samius, Вы писали:

I>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
S>внезапно с помощью декаррирования.

Покажи пример. А как быть с вариантами ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
S>>внезапно с помощью декаррирования.

I>Покажи пример. А как быть с вариантами ?

uncurr:: (a -> b -> c) -> (a,b) -> c
uncurr f = \(a,b) -> f a b

f' = uncurr f

А что с вариантами?

Здравствуйте, elmal, Вы писали:

SV.>>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки.
E>

E>public class NotNullUtils {
E>    public static <T> List<T> processNull(List<T> list) {
E>        if (list == null) {
E>            return new ArrayList<T>();
E>        }
E>        return list;
E>    }

E>    public static String processNull(String string) {
E>        if (string == null) {
E>            return "";
E>        }
E>        return string;
E>    }
E>...
E>

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

Я, наверное, плохо выразился. Ваш продукт что делает? Кучку разрозненных сервисов типа проверки на null предоставляет? Или что-то полезное? Это та же дверь и корова, извиняюсь за выражение (см. ниже по ветке).

P.S.

public static string SafeToString(this object o)
{
     return o == null ? "" : o.ToString();
}

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

I>>А с каких пор ООП это именно создавать классы Лужа и Камень ?

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

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

Что касается симметричных операторов, то в ООП решением будет введение например сумматора — вполне себе физический объект. И точно так же с задачей про Account и перевод средств между оным естественным образом решение выливается в некоего вычислителя, и это будет TransferService.

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

В ООП же все просто — решение нужно предложить в терминах физических объектов. Например в игрушке, где вместо коровы были медведи и ели они мертвечину, у каждого медведя был метод Act, внутри его была стратегия действия на текущий квант времени — выжидать, караулить, атаковать, искать, есть, защищаться, принимать дамаг, раздавать дамаг, умирать, тухнуть и тд и тд.
То есть всего то решение в конкретных терминах физических объектов и поведения. К слову, Act был почти единственным пабликовым методом.
Например действие есть сводилось к изменению некоторых характеристик поедаемого объекта и своих собственных. Дейтсвие тухнуть это просто генерация эффекта "смрад" который был точнотаким же физическим объектом как и медведь только с другими характеристиками и поведением + модификация собтсвенных характеристики.

Нужно всего то понять простую вещь — ООП(ООД) не даёт ответа на вопрос, какая модель будет наиболее подходящей для задачи и дать в принципе не может. Ровно тоже самое с ФП и любой другой парадигмой. Парадигма дает ответ, как именно выразить конкретное решение в виде кода.
То есть, если решение "медведь ест героя", то это будет this.Eat(World.Hero) а если "к медведю и герою применяется эффект пожирание" то World.EffectsRepository(Effects.Eating).Apply(bear, hero). Ничего странного — сколько решений, столько и моделей и это абсолютно нормально. Может даже так, эгоцентричный или hero-centric подход — все что ни делается делается с героем, тогда hero.devouredBy(bear)

Здравствуйте, samius, Вы писали:

I>>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
S>>>внезапно с помощью декаррирования.

I>>Покажи пример. А как быть с вариантами ?
S>

S>uncurr:: (a -> b -> c) -> (a,b) -> c
S>uncurr f = \(a,b) -> f a b

S>f' = uncurr f
S>

То есть, дополнительные приседания ?

S>А что с вариантами?

Как выставить их из ФЯ что бы удобно было работать в C# ?

Здравствуйте, samius, Вы писали:

V>>Это твои представления об ФП догматичны. А мои об ООП ровно такие, каково состояние дел в ООП прямо на сегодня у лидеров рынка.

S>Прям пичалька за рынок взяла

А какие проблемы? Конкуренция абсолютно честна и доступна всем желающим. Покажите сравнимые результаты на "остальных" парадигмах. Но пока что разница в характеристиках на порядок и больше не в пользу "остальных".

V>>Увы, тогда это будет уже скорее ООП. Оно итак испачкано ФП-ой чуть ли не изначально.
S>нечистое ФП — это скорее ООП.

Не надоело со сфероконями бодаться? ))

Любое решение не столько от языка зависит, сколько от выбранного человеком подхода к решению задачи. На то она и парадигма. Даже на Хаскеле можно решать задачи в ООП-стиле, эмулируя недостающие в языке вещи. Другой вопрос — нужно ли маяться такой фигней, при наличии более подходящих под ОО-парадигму языков?

V>>Гы, ничего, что сейчас ты показал умение переворачивать всё с ног на голову почище моего?

V>>именно способность человека моделировать окружающий мир лежит в идее ООП. Никак не наоборот, ес-но. Ведь это человек назначает объектам роли, то бишь это не происходит "само по себе".
S>Способность человека моделировать лежит во всех других идеях ничуть не меньше, чем в ООП.

Объекты реального мира имеют характеристики, состояние и поведение. ООП тупо полностью копирует такой взгляд на вещи. А подход ФП заключается в полном абстракции от всего, включая способ работы вычислителя, на котором работает конечная программа. ИМХО, над излишним усердием в этом направлении я и иронизирую, явно сердя некоторых на этом сайте (судя по реакции). ))

V>>Увы, если брать отдельно взятый функциональный объект — то не в порядке. В порядке там только при наличии состояния. А в чем оно заключается в "чистом ФП" (которое даже без монад) — я тебе уже писал... про стек вычислений и положение указателя команд в потоке исполнения.
S>Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал.

Значит, плохо слушал.

S>Не занимается ФП отдельно взятыми из ООП объектами.

Объект — это не только термин из ООП.

V>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
S>Объекты — замыкания для бедных

Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь.

V>>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this.

S>напомни, откуда в свою очередь позаимствовали LISP-атомы

Да что же за такое???
3-й раз уже этот аргумент про несчастные классы типов скипают.
С вами каши не сваришь. )))

=============
Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.

Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... ))
Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>>>Покажи как выставить в апи карированую функцию что бы её можно было легко использовать из любого другого доступного языка.
S>>>>внезапно с помощью декаррирования.

I>>>Покажи пример. А как быть с вариантами ?
S>>

S>>uncurr:: (a -> b -> c) -> (a,b) -> c
S>>uncurr f = \(a,b) -> f a b

S>>f' = uncurr f
S>>

I>То есть, дополнительные приседания ?
Конечно. Без приседаний ты и "C++" из "C" не вызовешь и тем более C#.
Я думал что ты меня спросил за каррирование. Если тебя интересует именно "интероп" в широком смысле, то ситуация с интеропом конкретно хаскеля не распространяется на все языки функциональной парадигмы. А что бы вызвать функцию из конкретно хаскеля, нужно курить FFI, и декаррирование там не поможет.

S>>А что с вариантами?

I>Как выставить их из ФЯ что бы удобно было работать в C# ?
Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#. Ну а раз в C# нет и не предвидится паттерн-матчинга, то работать на C# с этими вариантами будет куда менее удобно, чем на F#/Nemerle.
Вобщем, ты не захочешь объект описывать в C# делегируя его методы в реализации на другом языке. Проще выставить из C# интерфейс и реализовать его в F#/Nemerle, т.к. они для работы с ООП куда более приспособлены, чем C# для работы с ФП

Здравствуйте, Ikemefula, Вы писали:

I>На мой взгляд (подсмотрел в профайлере) ты экономишь около нуля(но справа) ресурсов и для этого создал целую инфраструктуру.

Умножай свой около нуля на порядка 90-150тыщ сообщений в сек. GC ложится навзничь.

I>Итого, п.1 — прояснить не удалось п.2 жостких данных не было, были общие слова

Итого ты мистер-торопыжка. Сам спросил, сам же в своем посте не увидел ответа, сам же распинаешься по этому поводу. ))

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Прям пичалька за рынок взяла

V>А какие проблемы? Конкуренция абсолютно честна и доступна всем желающим. Покажите сравнимые результаты на "остальных" парадигмах. Но пока что разница в характеристиках на порядок и больше не в пользу "остальных".
Я уже отвечал здесь про Автоваз и Китай.

S>>нечистое ФП — это скорее ООП.

V>Не надоело со сфероконями бодаться? ))
Надоело. Завязывай с ними.

V>Любое решение не столько от языка зависит, сколько от выбранного человеком подхода к решению задачи. На то она и парадигма. Даже на Хаскеле можно решать задачи в ООП-стиле, эмулируя недостающие в языке вещи. Другой вопрос — нужно ли маяться такой фигней, при наличии более подходящих под ОО-парадигму языков?
А зачем выбирать ОО-решение, если собираешься писать на ФП языке? Бросай эту фигню. Писать на ОО языке функционально тоже не сахар.

S>>Способность человека моделировать лежит во всех других идеях ничуть не меньше, чем в ООП.

V>Объекты реального мира имеют характеристики, состояние и поведение. ООП тупо полностью копирует такой взгляд на вещи. А подход ФП заключается в полном абстракции от всего, включая способ работы вычислителя, на котором работает конечная программа. ИМХО, над излишним усердием в этом направлении я и иронизирую, явно сердя некоторых на этом сайте (судя по реакции). ))
Мы уже выяснили, что у двери поведения нет. И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.

S>>Отдельно взятый функциональный объект ты походу взял из ООП. В ФП я о таких не слышал.

V>Значит, плохо слушал.
Возможно

S>>Не занимается ФП отдельно взятыми из ООП объектами.

V>Объект — это не только термин из ООП.
Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.

V>>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
S>>Объекты — замыкания для бедных

V>Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь.
а мне кажется что ты клоунадничаешь. И я не одинок в этом.

V>>>Ну а про классы типов я тебе уже говорил — тоже позднее заимствование (хоть ты старательно игноришь неудобные аргументы). Это же натуральный контракт, который в ООП есть кортеж обязательных методов, а в ФП кортеж обязательных ф-ий (тоже почему-то называемых методами в Хаскеле)... то бишь, ф-ий над аргументом некоего типа, проводя аналогию в ООП — подаваемого как this.

S>>напомни, откуда в свою очередь позаимствовали LISP-атомы

V>Да что же за такое???
V>3-й раз уже этот аргумент про несчастные классы типов скипают.
V>С вами каши не сваришь. )))
Ох, а ты сколько скипаешь... Не пробовал считать?

V>=============
V>Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.

V>Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... ))
V>Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.
Кэй писал что вдохновлялся атомами Лиспа. На самом деле от Лисп-атома до кортежа функций не так далеко. Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.

Здравствуйте, Ikemefula, Вы писали:

V>>Гы, абстракция — это упрощение.
V>>Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не?
I>Нет. Представь себе, что часть дороги накрыл туман. Если тумана нет, дорогая представляется тремя отрезками. А если туман есть, то ...

Насколько сильный туман? ))
Если тумана нет, то на дороге я вижу кучу подробностей, а если есть, то максимум вижу общее направление дороги.

I>>>Вот функциональная декомпозиция
I>>>Order(x => x.ABC)

I>>>А вот процедурная

I>>>OrderByHellKnowsWhat

I>>>Надо ли объяснять разницу ?

V>>Ес-но надо.
V>>Для начала приведи эквивалентный по функциональности код и там и там.

I>Ну, имя неудачное, так будет яснее OrderByAbc

Так и думал. ))
Все-равно не эквивалент.

Эквиваленты будут такие (исходный пример тоже подрихтую):

Order(listOfX, x => x.ABC)
vs
Order(listOfX, &CompareABC) или Order(listOfX, &ExtractABC), где

bool CompareABC(x, x) или
ABC ExtractABC(x)

V>>Если с наскока не получится — см. мою подсказку насчет того, что есть замыкание.
I>Это не важно, что есть замыкание.

Как только выяснилось — важно, эквивалентный пример ты так и не привел.

I>Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает.

Мде? А qsort в чистом Си видел?
Как эмулируется замыкание — я уже показал. С помощью указанной пары {ф-ия, контекст} можно делать в точности аналогичное на процедурном подходе. Достаточно умения вызывать обычную ф-ию по ссылке.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>В хаскеле тоже нет ветвления в структурном смысле просто потому что язык не описывает выполнение стейтментов и не оперирует побочными эффектами.

V>Вот та самая догматика. А кто мешает считать, что вычисления в ложных ветках if всё-таки производятся, но потом отбрасываются?

Считай, не буду мешать.

V>Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть)
Тоже можно считать. Только результат if-а очень даже повторимый. Сколько не будешь вычислять с теми же аргументами, получишь то же самое.

V>Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости.
Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.

V>Помнишь еще, я как-то спрашивал твое мнение относительно того, почему одна и та же конструкция if-the-else может использоваться как для чистых ф-ий, так и для IO? На тот момент ты еще соглашался, но мне было бы интересно услышать сегодняшнее твоё мнение. Похоже оно чуть трансформировалось. ))
Не помню что ты спрашивал, но отвечу.
Любые допустимые взаимодействия с IO a кроме unsafePerformIO и подобных ему не делают побочных эффектов. Потому, если ты решил скомбинировать IO a в ветке if-а, то никакого криминала в этом нет. Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.

Здравствуйте, Ikemefula, Вы писали:

V>>Умножай свой около нуля на порядка 90-150тыщ сообщений в сек. GC ложится навзничь.

I>Не ложится

Тест в студию, то есть, давай таки не общие слова а жосткие данные.
I>Если я тебе скажу, что GC выдерживает 20млн инстанцирований в секунду и память не растет вообще, ты сильно удивишься ?

На синтетическом тесте, где все объекты 0-го поколения это ерунда.
Эффективность GC зависит от общего кол-ва живых объектов в системе, а если в системе уже есть десятки тыщ объектов и вновь создаваемые с такой скоростю по new переживают 0-е поколение, то тут и кирдык.

Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.

Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.

I>Итого — ты в первом сообщении ничего не выдал, тоьлко общие слова и до сих пор только общие слова.

Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

V>>>Гы, абстракция — это упрощение.
V>>>Я так всегда считал, что смутное представление о чем-либо — это и есть чрезмерное упрощенное представление, не?
I>>Нет. Представь себе, что часть дороги накрыл туман. Если тумана нет, дорогая представляется тремя отрезками. А если туман есть, то ...

V>Насколько сильный туман? ))
V>Если тумана нет, то на дороге я вижу кучу подробностей, а если есть, то максимум вижу общее направление дороги.

Представь, что тебя интересует только дистанция и промежуточные точки (кафе, магазин). Теперь вопрос- почему при наличии тумана нельзя ввести абстрации ?

I>>Ну, имя неудачное, так будет яснее OrderByAbc

V>Так и думал. ))
V>Все-равно не эквивалент.

Эквивалент.

V>Эквиваленты будут такие (исходный пример тоже подрихтую):
V>

V>Order(listOfX, x => x.ABC)
V>vs
V>Order(listOfX, &CompareABC) или Order(listOfX, &ExtractABC), где

V>bool CompareABC(x, x) или
V>ABC ExtractABC(x)
V>

Указатель на функцию это уже ФП, опаньки ! Процедурная парадигма не умеет никаких таких вещей.
Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.
То есть, понять, что же будет сделано, можно только глядя в код конкретного метода.
В моем случае все это по месту вызова.

I>>Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает.

V>Мде? А qsort в чистом Си видел?

А ты перестал опохмеляться ?

V>Как эмулируется замыкание — я уже показал. С помощью указанной пары {ф-ия, контекст} можно делать в точности аналогичное на процедурном подходе. Достаточно умения вызывать обычную ф-ию по ссылке.

А ты хорошо понимаешь, что такое эмуляция ? ты хорошо понимаешь, что код по месту вызова не то же самое что и код хрен знает где ? ты хорошо понимаешь, что привел пример фактически из ФП ?

Здравствуйте, vdimas, Вы писали:

I>>Не ложится

Тест в студию, то есть, давай таки не общие слова а жосткие данные.
I>>Если я тебе скажу, что GC выдерживает 20млн инстанцирований в секунду и память не растет вообще, ты сильно удивишься ?

V>На синтетическом тесте, где все объекты 0-го поколения это ерунда.
V>Эффективность GC зависит от общего кол-ва живых объектов в системе, а если в системе уже есть десятки тыщ объектов и вновь создаваемые с такой скоростю по new переживают 0-е поколение, то тут и кирдык.

Живых объектов минимум несколько миллионов и как то не заметно что складывается GC от мелких объектов. Он морозит совершенно в других сценариях.

V>Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.

Так у вас что, живые ссылки на эти пустые списки ?

Похоже вы придумали проблему что бы элегантно решить по месту возникновения

Дешевле хранить нуль и создавать пустой список.

V>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.

I>>Итого — ты в первом сообщении ничего не выдал, тоьлко общие слова и до сих пор только общие слова.

V>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.

Ты привел конкретные цифры только с третьей попытки.

Здравствуйте, Ikemefula, Вы писали:

I>ООП работает там где в __решении__ задачи фигурируют физические объекты. Физический объект он с поведением и со свойствами.
Ничего подобного. Ну нету физического объекта "socket", который бы моделировался экземплярами класса CSocket. Это — математическая абстракция. У него нет физических свойств, таких как масса и линейные размеры.

I>Вот здесь ООП работает. Собственно по этому во всех букварях по дизайну говорят, что надо моделировать объекты реального мира, но почему то этот совет понимается именно как генерация классов Лужа и Камень.
Ну, а какие объекты реального мира вы видите во взаимодействии лужи и камня?

I>Что касается симметричных операторов, то в ООП решением будет введение например сумматора — вполне себе физический объект. И точно так же с задачей про Account и перевод средств между оным естественным образом решение выливается в некоего вычислителя, и это будет TransferService.
Давайте мы слово "физический" не будем упоминать всуе, ок?

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, Sinclair, Вы писали:

SV.>>>До- и переписывайте как угодно, но форматирование строк, хранение в бинарном формате IEEE-666 и заданную точность оставьте, это условия задачи, которые к ООП отношения не имеют.
S>>

S>>var aT = ConvertLongToHighPrecisionNumber(a);
S>>var bT = ConvertStringToHighPrecisionNumber(b);
S>>var cT = ConvertIeee666ToHighPrecisionNumber(c);
S>>

S>>Идея понятна?

SV.>Нет, поскольку вы недопереписали вывод типов. Что вернут конвертеры?
Экземпляры какого-то абстрактного типа данных.

Здравствуйте, kittown, Вы писали:

K>>>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
AVK>>Это не программисты уже в привычном понимании.

K>Привычном для кого ?

Для людей, присутствующих в софтверном бизнесе.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, Sinclair, Вы писали:

S>>

S>>Decimal static Decimal CalcBalanceForDate(Date date, allTransfers) 
S>> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>>

SV.>И, кстати, откуда у вас статичность взялась?
Как откуда? В приведённом коде метода нет никаких обращений к нестатическим мемберам. Так нахрена ему быть экземплярным?

Здравствуйте, Sinclair, Вы писали:

I>>ООП работает там где в __решении__ задачи фигурируют физические объекты. Физический объект он с поведением и со свойствами.
S>Ничего подобного. Ну нету физического объекта "socket", который бы моделировался экземплярами класса CSocket. Это — математическая абстракция. У него нет физических свойств, таких как масса и линейные размеры.

Массы и линейных размеров нет, зато поведение и свойства есть. Эта математическая абстракция есть заимствование из физического мира, представь, передача информанции на уровне сообщений, каналов и даже пакетов появилась еще в те времена, когда пароход феодосия еще шлюпкой был.

I>>Вот здесь ООП работает. Собственно по этому во всех букварях по дизайну говорят, что надо моделировать объекты реального мира, но почему то этот совет понимается именно как генерация классов Лужа и Камень.
S>Ну, а какие объекты реального мира вы видите во взаимодействии лужи и камня?

Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает.

I>>Что касается симметричных операторов, то в ООП решением будет введение например сумматора — вполне себе физический объект. И точно так же с задачей про Account и перевод средств между оным естественным образом решение выливается в некоего вычислителя, и это будет TransferService.
S>Давайте мы слово "физический" не будем упоминать всуе, ок?

Физический объект имеется ввиду заимствование из реального мира, а не корова с выменем, рогами и хвостом.

> Любое ПО является лишь моделью мира.

2 + 4
— модель мира?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Писать хороший код, это как раз не делать как мыслить или моделировать реальность, а использовать соответствующие правильные методики для решения конкретных задач, опробованные и одобренные.
Супер!
Нужно именно моделировать решение, а не решать задачу в супер-моделированной реальности. Это безотносительно парадигмы.

Здравствуйте, Sinclair, Вы писали:

SV.>>>>До- и переписывайте как угодно, но форматирование строк, хранение в бинарном формате IEEE-666 и заданную точность оставьте, это условия задачи, которые к ООП отношения не имеют.
S>>>

S>>>var aT = ConvertLongToHighPrecisionNumber(a);
S>>>var bT = ConvertStringToHighPrecisionNumber(b);
S>>>var cT = ConvertIeee666ToHighPrecisionNumber(c);
S>>>

S>>>Идея понятна?

SV.>>Нет, поскольку вы недопереписали вывод типов. Что вернут конвертеры?
S>Экземпляры какого-то абстрактного типа данных.

А хранение и вычисление где будут реализованы?

Здравствуйте, vdimas, Вы писали:

V>На синтетическом тесте, где все объекты 0-го поколения это ерунда.
V>Эффективность GC зависит от общего кол-ва живых объектов в системе, а если в системе уже есть десятки тыщ объектов и вновь создаваемые с такой скоростю по new переживают 0-е поколение, то тут и кирдык.

V>Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.

Для GC это мизер

Издержки на очереди много больше издержек на выделение памяти. Я накидал тест, как ты говоришь, и в ём инстанцирований в 8 раз меньше, нежели без очередей, то есть GC в 8 раз меньше работы. Памяти съедается примерно 150мб но это опять же не фатально, при чем загружены работой все 4 ядра

Профайлер упорно показывает что узкое место по перформансу никак не выделение. А то что вы храните ссылки на пустые списки — это ваша проблема.

Как экономию памяти это можно принять, правда не ясно, зачем вообще хранить ссылку на пустой список

V>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.

Так тест будет а то опять окажется что у тебя условие снова изменилось ?

I>>Итого — ты в первом сообщении ничего не выдал, тоьлко общие слова и до сих пор только общие слова.

V>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.

Проблемы оттого что вы хранили ссылки на пустые коллекции.

> G>Писать хороший код, это как раз не делать как мыслить или моделировать реальность, а использовать соответствующие правильные методики для решения конкретных задач, опробованные и одобренные.
> Супер!
> Нужно именно моделировать решение, а не решать задачу в супер-моделированной реальности. Это безотносительно парадигмы.

Программирование, это не моделирование задачи, а построение своей модели.
Если мне нужно написать калькулятор, то я не моделирую математические вычисления, а по большей части рисую формочки, то есть создаю свою модель, свою реальность. Ты конечно можешь попробовать притянуть за уши, что формочки калькулятора это входит в задачу моделирования математических вычислений. Попробуй, было бы интересно.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Sinclair, Вы писали:

S>>>

S>>>Decimal static Decimal CalcBalanceForDate(Date date, allTransfers) 
S>>> return (from t in allTransfers where t.Date <= date select t.Amount).Sum();
S>>>

SV.>>И, кстати, откуда у вас статичность взялась?
S>Как откуда? В приведённом коде метода нет никаких обращений к нестатическим мемберам. Так нахрена ему быть экземплярным?

А идентификатор счета где?

Здравствуйте, AndrewVK, Вы писали:

K>>>>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
AVK>>>Это не программисты уже в привычном понимании.

K>>Привычном для кого ?

AVK>Для людей, присутствующих в софтверном бизнесе.

Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ? Вы на них смотрите, как еще недавно асм-кодеры смотрели на паскаль-кодеров и на си-кодеров. Как раз эти люди занимаются делом (работают в терминах предметной области), а не всякой абстрактной блажью.

Здравствуйте, grosborn, Вы писали:

G>Программирование, это не моделирование задачи, а построение своей модели.
G>Если мне нужно написать калькулятор, то я не моделирую математические вычисления, а по большей части рисую формочки, то есть создаю свою модель, свою реальность. Ты конечно можешь попробовать притянуть за уши, что формочки калькулятора это входит в задачу моделирования математических вычислений. Попробуй, было бы интересно.
Я пытался поддержать мысль, но получил возражение. В недоумении.
А рисование формочек — это не совсем и программирование. Вообще говоря, в некоторых организациях программистами зовут тех, кто знает как подпнуть принтер, что бы он включился, и куда воткнуть витую пару, если кто-то запнулся об шнурок и разъем вылетел. Мы же здесь не о таком программировании...

Здравствуйте, Воронков Василий, Вы писали:

AVK>>Ага, все просто когда наконец мозги себе поломаешь. Ну так и в ООП тоже все просто в таком разрезе.

ВВ>Так обо что именно ломаются мозги? Можно все-таки это как-то объяснить? Линк на твой взгляд тоже взрывает мозг?

До определенного момента, если не вникать, нет. Потом — да. Я это лично наблюдал, к примеру, на Платформе 2006, кажется, года, когда почти весь зал просто подвис через какое то время на нашем с IB докладе про LINQ. Сейчас такого эффекта уже нет, попривыкли.
А в функциональных языках монады существенно более бесчеловечны, чем специально заточенный под конкретные задачи линк.

AVK>>А я этого нигде и не писал.

ВВ>Ты писал, что код станет недостаточно абстрактным.

Где?

ВВ>И мне не очень понятно, почему ты считаешь это подпорками

Потому что это подпорки к базовой концепции ФВП+иммутабельность. Большая часть вещей выражается только через это, но неудобно.

ВВ>>>Они просто позволяют писать короче и выразительнее.
AVK>>А ФП и ООП в целом, это тоже про короче и выразительнее.
ВВ>Остается понять, у кого это получается лучше.

И это очень непростой вопрос. Одно знаю точно, крайности типа как у Клапауция или у Икемефулы, точно далеки от реальности. Моя ИМХА — у ООП получается лучше начиная с компонентов и выше по абстракции, у ФП — оттуда же ниже.

ВВ>Здесь, видимо, неплохо бы объяснить, чем же хуже, и о каких бревнах речь.

Все что я хотел, я уже сказал. Если тебе не нравится моя точка зрения, это вовсе не означает что я неправ или чего то не сказал.

ВВ>Я вот замечаю обратное

А я нет. Дальше то что? Опять скатываемся в субъективно-экспертный подход? Да, если мы цепочку данных иммутабельно трансформируем, ФП скорее всего даст более короткий и понятный код. Но вот, к примеру, для дизайна GUI фреймворков все что я в функциональном мире видел, это либо подточеный под ФП классический ОО подход, либо такие страшные чудовища, да еще и без дизайнера, что мама дорогая. С дизайном распределенных систем у функционального подходя я тоже каких то особых прорывов не видел. И т.д.

ВВ>Ну если мы не выходим за рамки ФП, то это никак не может являться новой концепцией.

Это все спор о терминах. Не нравится слово "концепция", замени на "сущность".

ВВ>В ООП же, для сравнения, у нас действительно появляются подпорки. Даже банальные статические методы уже выходят за рамки ООП.

Нет, статические не выходят, потому что никаких проблем ООП не решают.

ВВ>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП

Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.

ВВ>Я чего-то тут явно не понимаю.

Скорее не хочешь.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, kittown, Вы писали:

K>Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ?

Нет, это не софтверный бизнес такой, это ты продолжаешь приписывать мне утверждения, которые я не делал.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

S>Это будет нарушением SRP.
И чо?
Индусы код не поймут?
Система работать не будет?
Цена поддержки многократно вырастет?
Чувству прекрасного будет нанесен невосполнимый урон?

S>То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.
Выделенное плохо?
Подчеркнутое обязательно?

>anemic model:
>"Logic cannot be implemented in a truly object-oriented way"

Какая невосполнимая потеря

> То что мы мыслим объектами — не означает, что этот тип мышления самый лучший. Под него заточнен наш мозг — потому что он развивался в направлении улучшения взаимодействия с реальными физическими объектами и предсказания их поведения.

Человек мысли не объектами. Мыслительный процесс человека образный, как раз ближе к ФП.
Мозг это в основном память. В определенных структурах запечатлеваются образы. Берем простой пример — это машина, она зеленая. Объект и свойство? Нихрена.
"Это машина" — ассоциативным запросом выбирается из долговременной памяти образ машины в структуры формирующие образ. Либо сразу образ зеленой машины если образ конкретной зеленой машины (где зеленое это не свойство), либо образ какой-то пока еще не зеленой машины. Теперь нужно перейти к зеленой машине. Дергаем метод покрасить образа машины?? Нихрена. "Зеленый", это отдельный образ. Переход к зеленой машине, это ассоциативный запрос образ машины + образ зеленая => выбирается из долговременной памяти ряд ассоциаций, из которой выбирается образ зеленой машины в те же структуры работы с образами, либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах. Это типично функциональный подход.

ООП, это примерно такой же процес, только структурно более сложный, и в струтурах больше привычных к логическому мышлению. То есть дальше от простого естественного способа мышления. Переход же к ООП от естественного образного мышления, это уже как переход от "бей ломай" к писменности.

Posted via RSDN NNTP Server 2.1 beta

> Я пытался поддержать мысль, но получил возражение. В недоумении.

Пытаюсь донести мысль, что в программировании больше синтеза, чем моделирования как такового.

> А рисование формочек — это не совсем и программирование.

Аргумент

Но вот только кода, выполняющего далекие от модели основной задачи функции, внезапно больше.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> То что мы мыслим объектами — не означает, что этот тип мышления самый лучший. Под него заточнен наш мозг — потому что он развивался в направлении улучшения взаимодействия с реальными физическими объектами и предсказания их поведения.

G>Человек мысли не объектами. Мыслительный процесс человека образный, как раз ближе к ФП.
G>Мозг это в основном память. В определенных структурах запечатлеваются образы. Берем простой пример — это машина, она зеленая. Объект и свойство? Нихрена.
G>"Это машина" — ассоциативным запросом выбирается из долговременной памяти образ машины в структуры формирующие образ. Либо сразу образ зеленой машины если образ конкретной зеленой машины (где зеленое это не свойство), либо образ какой-то пока еще не зеленой машины. Теперь нужно перейти к зеленой машине. Дергаем метод покрасить образа машины?? Нихрена. "Зеленый", это отдельный образ. Переход к зеленой машине, это ассоциативный запрос образ машины + образ зеленая => выбирается из долговременной памяти ряд ассоциаций, из которой выбирается образ зеленой машины в те же структуры работы с образами, либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах. Это типично функциональный подход.

Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.

> либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах.

"Затирая" тут как бы не совсем правильно написал. Когда один образ заменяется другим, это не значит что он попадает в те же нейроны. Но для простоты понимания можно и так.

Posted via RSDN NNTP Server 2.1 beta

> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.

Это общий механизм мышления. Логическое мышление построено на этом же принципе, но структурно сложнее и с непринципиальными вариациями. Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов. Вообще добиться того, что бы следующий снимок не накладывался на предыдущий и не разрушал его, а это требуется для логического мышления, это человеку специально приходится приучиваться и напрягаться и формировать специальные, контролируемые образы. А в ООП просто Машина.Цвет = Зеленый, никакого риска разрушения образа объекта.
В общем естественное мышление и ООП это не рядом.
.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, AndrewVK, Вы писали:

Нда ?

Воспроизведу весь контекст, покоцав свои цитаты:

K>Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
AVK>Это не программисты уже в привычном понимании.
K>>Привычном для кого ?
AVK>Для людей, присутствующих в софтверном бизнесе.
K>Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ?
AVK>Нет, это не софтверный бизнес такой, это ты продолжаешь приписывать мне утверждения, которые я не делал.

Читайте выше про языки для создания бизнес-правил. Это и есть языки высокого уровня, применимые в рамках предметной области, о которых я говорил. Любые другие языки, моделирующие элементы предметной области через дополнительные абстракции со своей (обусловленной особенностями языка) структурой — языки более низкого уровня, будь то хаскел, Java, си, асм, или байткод на перфокартах. Я понимаю, очень приятно смотреть на такие языки как на что-то "убогое" или "для быдлокодеров", но надо все же помнить, что предельно высокий уровень языка — там, где можно выразить термины предметной области наиболее кратко и точно, и угадайте, какие языки для этого лучше подходят — специально разработанные для заданной предметной области, или набор "сделай сам на коленке" из Java, си, итд. Не случайно тут битвы про account-ы и про идентификатор счета идут, такая свобода интерпретаций в конкретной заданной предметной области только во вред.

Здравствуйте, grosborn, Вы писали:

>> Я пытался поддержать мысль, но получил возражение. В недоумении.

G>Пытаюсь донести мысль, что в программировании больше синтеза, чем моделирования как такового.
Мысль ясна, но их не надо противопоставлять. Моделирование — тоже синтез. Нет такого что снэпшот мысли внезапно оказался моделью в ООП стиле.

>> А рисование формочек — это не совсем и программирование.

G>Аргумент

Но вот только кода, выполняющего далекие от модели основной задачи функции, внезапно больше.
А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.

Здравствуйте, AndrewVK, Вы писали:

K>>Туплы — это и есть АлгТД.
AVK>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.

Вообще в Хаскелле кортежи это:

data Pair a b = Pair a b

data Triple a b c = Triple a b c

и т.д.
А (,) и (,,) — это просто такие конструкторы вместо Pair и Triple. Они, кстати, так и описываются в инстансах.

А что такое РА?

> А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.

Эээ.... Я могу вспомнить только скрипты. Там нет кода не относящегося к решению задачи.

Posted via RSDN NNTP Server 2.1 beta

DG>>Это детали реализации.
S>Это устройство архитектуры.

от того, что слово "хрен" заменить на слово "редька" смысл не изменится.

DG>>Счет-то все равно объектом остается с соответствующими сообщениями:
S>Откуда это внезапно взялось?

Потому что если по счету нет возможности проводить операции, их смотреть тем или иным способом, а также вычислять тот или иной баланс, то это уже не счет.
При чем речь не про варианты — когда возможность отключена, не реализована, временно недоступна, недоступна в данных условиях и т.д., а вообще таких возможностей нет, даже теоретически.

DG>>- зарегистрировать еще одну операцию,
S>На всякий случай, напомню, что "регистрация операции" работает с двумя счетами. Кому из них мы посылаем сообщение? Первому попавшемуся? Кто обязан проверять соответствие операции бизнес-правилам?

Кому удобнее, тому и посылаем. С каких это пор в ООП появилось требование однозначности способа выполнения действия?

DG>>- вывести текущее состояние по счету,
S>Я уже писал о том, что понятие "текущее состояние" в бухгалтерии не существует. Существует "состояние на дату".

Операция "текущее состояние" — это частный случай операции "состояние на дату". Просто дата не фиксирована, а берется из текущего момента времени.

DG>>- вывести историю операций и т.д.

DG>>Например, когда заходишь в инет-банк, то со счетами работаешь как с объектами: выбираешь объект (счет, транзакцию) и посылаешь ему сообщение посредством нажатия соответствующей кнопки.
S>Очень странно. Лично я, когда захожу в инет-банк, никаких сообщений счетам я не посылаю. Сообщения я посылаю исключительно серверу, а сервер мне отвечает.

Это уже другой уровень абстрагирования, соответственно и другие объекты. Если уж на то пошло, то ни каких сообщений ты серверу не посылаешь, а индуцируешь (или модулируешь) электромагнитный сигнал в проводе (или в воздухе) — если в качестве границы системы берется комната в которой ты находишься.

DG>>При этом не важно, как он реализован в js-е или на сервере: как идентификатор, как запись в базе, как еще что-то — для использования через gui инет-банка, счет удобнее воспринимать как объект.
DG>>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования)
S> Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".

Это лишь твои ментальные ограничения. И твои ментальные ловушки, когда ты пытаешься реальные явления ограничить рамками слов, которыми ты эти явления обозначаешь.

Здравствуйте, grosborn, Вы писали:

>> А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.

G>Эээ.... Я могу вспомнить только скрипты. Там нет кода не относящегося к решению задачи.
Наверное это тоже зависит от конкретных скриптов. Если взять js, то там традиционно толпится куча кода по обходу проблем совместимости браузеров.

Здравствуйте, kittown, Вы писали:

(1) K>>Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
(2) AVK>>Это не программисты уже в привычном понимании.
K>>>Привычном для кого ?
AVK>>Для людей, присутствующих в софтверном бизнесе.
(3) K>>Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ?
AVK>>Нет, это не софтверный бизнес такой, это ты продолжаешь приписывать мне утверждения, которые я не делал.

K>Читайте выше про языки для создания бизнес-правил.

Если ты настаиваешь, я тебе продемонстрирую, где ты подменил мое высказывание. Сперва смотрим (1) — речь зашла о языках бизнес-правил, которые не создают новые абстракции. В (2) мое утверждение, раскрываю с учетом (1): "Написатели бизнес-правил на спецязыке без создания абстракций — не программисты в привычном понимании". А в (3) ты переиначиваешь мое высказывание, легким движением руки заменяя "языки бизнес-правил без абстракций" на языки высокого уровня. Это, батенька, называется подтасовка.

K>Я понимаю, очень приятно смотреть на такие языки

Какие такие? Давай конкретные примеры в студию.
Вот в нашей платформе (Парус Торнадо) есть несколько языков, имеющих отношение к бизнес-правилам. Например, язык метаданных платформы, описывающий прикладные сущности (текстовый декларативный язык + гуевый дизайнер). Но, вот что характерно, этот язык напрямую предназначен для создания новых абстракций. А вот есть еще язык (в какой то мере, это не текстовый язык) задания правил обработок (проводок) документов. В нем таки нет никаких средств создания новых абстракций, только использование существующих. И таки те, кто этим пользуется, нифига не программисты, а всякие внедренцы и админы.

K> как на что-то "убогое" или "для быдлокодеров"

Ты опять приписываешь мне то, чего я не писал.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.

G>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов.

Так устроен разве что только внутренний диалог, или в других терминах — высший уровень сознания.
При этом большая часть мышления приходится на подсознание, где выполнее проще описать, как сеть из функциональных блоков. На этих уровнях последовательности снимков скорее нет, чем есть.

Здравствуйте, Воронков Василий, Вы писали:

AVK>>Но вот, к примеру, для дизайна GUI фреймворков все что я в функциональном мире видел, это либо подточеный под ФП классический ОО подход, либо такие страшные чудовища, да еще и без дизайнера, что мама дорогая. С дизайном распределенных систем у функционального подходя я тоже каких то особых прорывов не видел. И т.д.

ВВ>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.

А что ты видел в дизайне распределенных ?

Здравствуйте, Ikemefula, Вы писали:

ВВ>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
I>А что ты видел в дизайне распределенных ?

Анемики, сервисы и иже с ними.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А что такое РА?

Реляционная Алгебра

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

I>Указатель на функцию это уже ФП, опаньки ! Процедурная парадигма не умеет никаких таких вещей.

Дудки, ФП — это где есть механизм ФВП. А если речь об адресе статической ф-ии, видимой в compile-time, то это не ФП, а банальный AddressOf из махровых императивных 70-х.

I>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.

Ниче не понял, перефразируй, плиз.

I>То есть, понять, что же будет сделано, можно только глядя в код конкретного метода.
I>В моем случае все это по месту вызова.

Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))

I>>>Важно что лямбда позволяет сделать инверсию, а процедурная композиция никакой инверсии не предполагает.
V>>Мде? А qsort в чистом Си видел?
I>А ты перестал опохмеляться ?

Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.

V>>Как эмулируется замыкание — я уже показал. С помощью указанной пары {ф-ия, контекст} можно делать в точности аналогичное на процедурном подходе. Достаточно умения вызывать обычную ф-ию по ссылке.
I>А ты хорошо понимаешь, что такое эмуляция ? ты хорошо понимаешь, что код по месту вызова не то же самое что и код хрен знает где ? ты хорошо понимаешь, что привел пример фактически из ФП ?

Да, я привел основную концепцию ФП на не ФП. Именно это я и хотел тебе показать, см своё исходное утверждение:

I>Покажи на примере, как функциональная композиация несильно отличается от процедурной.

Потому что на "голых" сях тоже успел пошпилить в задачах поболе даже тысячи строк... и все эти приемчики, ес-но, очень даже в ходу. Даже можно на досуге полистать код ядра линухов и основные внутренние интерфейсы (не в смысле интерфемов дотнета или джавы). Код на чистом Си, но незамыленным глазом ты будешь натыкаться на IOC-подход постоянно.

Здравствуйте, grosborn, Вы писали:

G>2 + 4
G> — модель мира?

Математика — это инструмент для описания закономерностей мира.

Здравствуйте, samius, Вы писали:

S>Мы уже выяснили, что у двери поведения нет.

Значит, так выясняли. Поведение ес-но есть. И уже раз 100 говорили, что дело в подробностях задачи, которые надо зафиксировать в ТЗ.

S>И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.

Где ты эту траву берешь?

V>>Объект — это не только термин из ООП.
S>Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.

Ох... Было сказано "функциональный объект".
А почему так? — из-за природы ФВП, т.к. они прямо по определению хранят в замкнутом контексте некоторые данные.

V>>>>Функциональная декомпозиция выглядит как набор независимых ф-ий. Сравни с иерархией ООП.
S>>>Объекты — замыкания для бедных

V>>Так и есть. Т.е. таки понимаешь, но абзацем раньше клоунадничаешь.
S>а мне кажется что ты клоунадничаешь. И я не одинок в этом.

Ну да, вас 3-5. Как и во все времена. Просто самые плодовитые. Один из этой "группы" какой-то неактивный в последнее время, дык, смотрю, замена подоспела... ))

V>>Да что же за такое???
V>>3-й раз уже этот аргумент про несчастные классы типов скипают.
V>>С вами каши не сваришь. )))
S>Ох, а ты сколько скипаешь... Не пробовал считать?

Я скипаю то, на что уже отвечал или несущественное по теме (на мой взгляд). Если же задают скипнутый вопрос повторно — обязательно отвечаю.
Скажем так, сам пинг-понг вопросов-ответов трекаю многократно тщательнее тебя и других популярных "писателей".

V>>=============
V>>Кстате, полную семантику "атомов" в языках, не только в Лисп, а атк же истоки этого термина и его мутирование с течением времени я же и пояснял на этом сайте несколько лет назад. Если тебе интересно — поиск в руки.

V>>Просто как бы в разное время были написаны интерпретаторы Лиспа на С++ и потом Схемы на дотнете... ))
V>>Мне их внутренняя механика нужна была как p-код для своих DSL. Ну и плюс библиотечный код есть в исходниках. Так что, можешь о механике работы Лиспа задавать любые вопросы... Если догмы не помешают, ес-но.

S>Кэй писал что вдохновлялся атомами Лиспа.

Дык, а про что конкретно он так писал? Есть брать атомы в смысле атомов из Лиспа, то их можно натянуть разве что на объектную identity.

S>На самом деле от Лисп-атома до кортежа функций не так далеко.

Бесконечно далеко.

S>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.

А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле?

Принципиальное отличие я уже объяснял: http://www.rsdn.ru/forum/decl/4691158.1.aspx

Здравствуйте, samius, Вы писали:

V>>Что в итоге у нас получается единственный и неповторимый результат всех вычислений после всех if, это те ветки, которые не были отброшены? А что мешает считать, что если результаты вычисления отбрасываются, то их и не было вовсе? (для Хаскеля так и есть)
S>Тоже можно считать. Только результат if-а очень даже повторимый. Сколько не будешь вычислять с теми же аргументами, получишь то же самое.

"единственный и неповторимый" — это аллегория, результат будет только один.

V>>Ну и верну тебя в русло: фокус был таки на том, что в конструкциях ПМ и if-then-else, учитывая только что сказанное, можно различить явный порядок вычисления аргументов. Ф-ия-предикат и тела при then-else в любом случае будут упорядочены в своих вычислениях за счет компоновки функциональных объектов и наложенного на эту компоновку механизма ленивости.
S>Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.

Я уже все показал, опять? http://www.rsdn.ru/forum/philosophy/4837590.1.aspx
Речь не о самом побочном эффекте (я же уже всё раскрывал), а о таких замеченных св-вах происходящего, что:
— последовательность вычисления важна для побочных эффектов, но для чистого кода — не важна;
— то бишь все 3 аргумента if могут вычисляться в произвольном порядке.. теоретически;
— фактически же порядок их вычислений гарантируется, что позволяет писать программы навроде комбинаторных парсеров с бесконечными рекурсиями, которые, однако, вполне конечны на конечных данных, из-за ленивости вычислений вкупе с гарантированным порядком вычисления аргументов в ПМ и if-then-else.

S>Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.

О, блин, наконец-то.
Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка?
Ес-но, в случае аналога бинарного дешифратора на вложенных if сначала будут вычислены все предикаты, и только "когда-нибудь потом" выбранная, в ходе ветвления, ветка.

Здравствуйте, samius, Вы писали:

S>Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#.

Спорно. Как минимум вариант посетителя, пусть даже на базе ФВП, для большого количества значений дискриминанта был бы удобнее рукопашной проверки этого дискриминанта.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Мы уже выяснили, что у двери поведения нет.

V>Значит, так выясняли. Поведение ес-но есть. И уже раз 100 говорили, что дело в подробностях задачи, которые надо зафиксировать в ТЗ.
Нет никакого поведения у двери кроме как подчиняться законам природы. А то что ты совокупность действующих на дверь сил заменяешь методом Откройся() — так это не двери забота. Это особенности твоей модели, а не двери вовсе.

S>>И собственного компьютера (о котором писал Др. Кэй и который принимает сообщения от сквозняка) у двери тоже нет. Так что с копированием ты преувеличиваешь.

V>Где ты эту траву берешь?
У Кэя взял.

V>>>Объект — это не только термин из ООП.
S>>Термин объект из ООП — это только термин объект из ООП. С объектом из реальной жизни он никак не связан, кроме лишь того что призван представлять его в программе.

V>Ох... Было сказано "функциональный объект".
V>А почему так? — из-за природы ФВП, т.к. они прямо по определению хранят в замкнутом контексте некоторые данные.
хранят, но с ООП-шностью этих данных в чистом языке напряг. Так что в топике об ООП лучше не называть эти данные объектом.

S>>а мне кажется что ты клоунадничаешь. И я не одинок в этом.

V>Ну да, вас 3-5. Как и во все времена. Просто самые плодовитые. Один из этой "группы" какой-то неактивный в последнее время, дык, смотрю, замена подоспела... ))
Самый плодовитый тут однозначно ты.

S>>Ох, а ты сколько скипаешь... Не пробовал считать?

V>Я скипаю то, на что уже отвечал или несущественное по теме (на мой взгляд). Если же задают скипнутый вопрос повторно — обязательно отвечаю.
V>Скажем так, сам пинг-понг вопросов-ответов трекаю многократно тщательнее тебя и других популярных "писателей".
конечно, ты скипаешь несущественное. Для тебя.

S>>Кэй писал что вдохновлялся атомами Лиспа.

V>Дык, а про что конкретно он так писал? Есть брать атомы в смысле атомов из Лиспа, то их можно натянуть разве что на объектную identity.
да, об identity items речь была.

S>>На самом деле от Лисп-атома до кортежа функций не так далеко.

V>Бесконечно далеко.
ну-ну

S>>Так что то что хаскель заимствовал классы типов из ООП — ну это немного натянуто, особенно учитывая природу реализаци полиморфизма в нем.

V>А какая там природа? Ну подается неявно vtable рядом с целевым типом и? В ООП этот vtable прибит гвоздями к экземпляру типа и подется всегда "автоматически" вместе с экземпляром. Это принципиальное отличие, что-ле?
Конечно. Примерно как между статикой и динамикой.

V>Принципиальное отличие я уже объяснял: http://www.rsdn.ru/forum/decl/4691158.1.aspx
Лень подымать контекст

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Дался тебе порядок вычисления чистых выражений. Ты мне побочный эффект покажи, а не порядок вычислений.

V>Я уже все показал, опять? http://www.rsdn.ru/forum/philosophy/4837590.1.aspx
Ты не показал побочный эффект. А то что ты показал — это не про Хаскель во всяком случае.

V>Речь не о самом побочном эффекте (я же уже всё раскрывал), а о таких замеченных св-вах происходящего, что:
Ты говорил о самом побочном эффекте, если чо.
V>- последовательность вычисления важна для побочных эффектов, но для чистого кода — не важна;
V>- то бишь все 3 аргумента if могут вычисляться в произвольном порядке.. теоретически;
V>- фактически же порядок их вычислений гарантируется, что позволяет писать программы навроде комбинаторных парсеров с бесконечными рекурсиями, которые, однако, вполне конечны на конечных данных, из-за ленивости вычислений вкупе с гарантированным порядком вычисления аргументов в ПМ и if-then-else.
Ну и где побочный эффект-то?

S>>Особенно учитывая то, что if не выполняет ветки, а просто их возвращает.

V>О, блин, наконец-то.
V>Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка?
Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.
V>Ес-но, в случае аналога бинарного дешифратора на вложенных if сначала будут вычислены все предикаты, и только "когда-нибудь потом" выбранная, в ходе ветвления, ветка.
Ага, и чо?

Здравствуйте, AndrewVK, Вы писали:

V>>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль.
AVK>Нет, не начинает.

Начинает для заведомо рекурсивных и бесконечных программ, будучи исполненными в энергичной манере.

V>> Некие выражения вычисляются заведомо РАНЬШЕ других
AVK>Ну и что? Это не приводит к ни к каким сайд-эффектам.

Приводит к тому, что заведомо неудачные ветки не вычисляются. Вроде бы и не сайд-эффект, если представить вычислитель с бесконечным быстродейтсвием и бесконечной памятью... А в конечных характеристиках этот момент — разминка для воображения.

AVK>>>А логические ветвления присутствуют, наверное, в любой парадигме.
V>>Предположу, что только у наследованных от структурной.
V>>Например, в логическом программировании никакого ветвления нет.

AVK>Есть. Предикаты как раз ветвление для тел правил и задают.

Ну дык, это в процессе работы вычислителя происходит ветвление. Просто в ФП-языке можно глазами пробежаться по коду и сэмулировать поток исполнения в любой единице программы. В императивном ПО и подавно. То бишь ветвление будет прямо перед глазами. А в Прологе так не пробежишься, бо правила могут быть объявлены в произвольном порядке, затрудняющем восстановить ход работы (поток исполнения) вычислителя.

V>>>>Про последовательное исполнение в Хаскеле — do-стрелки.
AVK>>>А при чем тут Хаскелл?
V>>А чтобы сферических коней не гонять туда-сюда.

AVK>Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию.

Дык, если брать OCaml — то там перечисление последовательности операций тоже изкаробки. Nemerle — тоже. Лисп, Схема — тоже. Про Хаскель сказал. Другие функциональные достаточно подробно не смотрел, чтобы делать какие-то утверждения. ИМХО, другие ФП-языки еще более экзотичные, чем перечисленные.

V>>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл.
AVK>Нет, не дает. Кури определение чистоты.

Дык, уже год как бросил...

V>>

V>>* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

AVK>А теперь включаем моск и осмысливаем написанное.

Коллега, я привел три составляющие. Они или работают все вместе, раскрываясь в одно общее определение, или вообще ничего не работают. Достаточно было оставить всего любые два компонента и уже было бы неубедительно... А ты решил ткнуть мне всего одним. ))

AVK>Если при последовательном исполнении можно придумать условие, которое изменится на очередной итерации внутри одной функции — налицо сайд-эффект, которого в чистом ФП быть не может по определению.

* Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы.

Сайд-эффект маскируется созданием нового значения из старого и ростом стека. Но в координатах очередного фрейма стека на каждом новом витке рекурсии мы имеем абсолютно такую же диспозицию данных, как на предыдущем витке. Наложи один идентичный фрейм локальных переменных на другой и ты увидишь такие же точно отличия, как если бы это был всё тот же самый фрейм стека + сайд-эффект.

Именно на этом важном принципе работает раскрутка рекурсии в цикл, даже если на каждом шаге изменяется более одной переменной-параметров ф-ии.

AVK>В то же время при чистой рекурсии любое условие всегда будет давать один и тот же результат для заданных аргументов, и каждая последующая итерация вызывает функцию с другими аргументами, так что условие чистоты на 100% соблюдается.
AVK>Меня совершенно потрясает, что ты местами забираешься глубоко в хитрые детали, а местами демонстрируешь зияющие пробелы в базовых знаниях.

А меня всегда потрясает, как можно предполагать второе из первого...
Всего-то требовалось немного воображения относительно аргументов оппонентов и хотя бы на минуту перестать считать окружающих дураками.

V>>И да, изначально далеко не все языки позволяли рекурсивные вызовы. Вот как раз в ф-ых языках она и появилась в кач-ве способа организации цикла.

AVK>Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?

Фортран, ес-но.
В первых стандартах не было RECURSIVE и я даже успел пройти на таком диалекте нем выч-практику на первом курсе на старой EC-1025.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, samius, Вы писали:

S>>Опять, смотря в каком языке. В F# и Nemerle они уже выставлены. И работать с ними из C# не менее удобно, чем если бы ты варианты руками выписывал на C#.

AVK>Спорно. Как минимум вариант посетителя, пусть даже на базе ФВП, для большого количества значений дискриминанта был бы удобнее рукопашной проверки этого дискриминанта.
Соглашусь, посетитель был бы кстати. Но ничто не мешает прикрутить внешнюю диспетчеризацию (фактически таже рукопашка) или dynamic-ах.

Здравствуйте, samius, Вы писали:

V>>Т.е. ты уже понял, что в любом случае, сначала будет вычислено выражение-предикат, и только "когда-нибудь потом" удачная ветка?
S>Да я знал об этом до тебя. Речь о том, что никакого побочного эффекта это не дает, и повода для сношения со Структурным Программированием нет.

Ты отрицал ветвление в заданном порядке исполнения. Уже не отрицаешь? Можно двигаться дальше?

Здравствуйте, Ikemefula, Вы писали:

V>>Предлагаю написать тест тебе. Пусть будет 1500 FIFO очередей. В каждую очередь поступает 100 пакетов в секунду. Длина очереди — порядка 500ms. По истечении этого времени пакет из очереди изымается и больше не нужен. Помимо этого, пусть к каждой очереди будет приклеплен "живой" граф из полусотни объектов.

I>Так у вас что, живые ссылки на эти пустые списки ?

Конечно, живые. Пока живо сообщение, жив список его полей, даже если он пуст. Сообщение-то будет обработано именно после того, как извлекут из списка. Это очередь задержки на выравнивание джиттинга UDP-пакетов.

I>Похоже вы придумали проблему что бы элегантно решить по месту возникновения

Дешевле хранить нуль и создавать пустой список.

Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...

V>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.
I>Ты привел конкретные цифры только с третьей попытки.

С первой, после того, как ты попросил конкретные цифры. Со второй я привел сценарий.

Издержки на очереди много больше издержек на выделение памяти. Я накидал тест, как ты говоришь, и в ём инстанцирований в 8 раз меньше, нежели без очередей,

Всё с вами ясно... Умудриться написать очередь, которая в 8 раз тяжелее GC — это весчь... )))
У нас она намного легче, чем GC. Не пробовал такую штуку, как "интрузивный список"?

I>А то что вы храните ссылки на пустые списки — это ваша проблема.

Этот пустой список в моем варианте — один на всех.

I>Как экономию памяти это можно принять, правда не ясно, зачем вообще хранить ссылку на пустой список

Рядом ответил на этот же вопрос от тебя же.

V>>Интересно глянуть нагрузку процессора в таком выхолощенном примере, учитывая, что в реальном примере пакеты приходят по сети и уходят в сеть и на каждый пакет есть кое-какая небесплатная логика.
I>Так тест будет а то опять окажется что у тебя условие снова изменилось ?

Дык, ты не привел своих данных. Сколько сообщений в секунду ты выжал на выхолощенном примере?
А мне сюда исходники ложить, чтобы ты их тестировал или как?

V>>Я привел конкретные цифры, на которых GC ложился навзничь (техника 5-тилетней давности, как и задача). Проблемы были именно в GC, потому что переиспользование объектов это дело лечит.
I>Проблемы оттого что вы хранили ссылки на пустые коллекции.

Не только. Проблемы от того, что мы храним сами сообщения. Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.
В общем, лечение было многостадийное. Объекты внутри "выпрямлялись". Те объекты по сценарию, которые переживают 0-е поколение — переиспользовались. Разумеется, рано или поздно объекты из пула они вообще уходят во 2-е поколение и GC их "не видит", поэтому такое большое кол-во объектов его перестает напрягать. Главное в этих объектах — ссылки не дергать. Поэтому, сообщения без дополнительных полей берутся из одного пула, а с полями — из другого. То бишь фактически такое присвоение пустого списка вообще идет однократное в момент создания объекта и затем при переиспользовании из пула никаких лишних телодвижений. В "разогретой" системе фактически никаких new. Операции с сокетами были переписаны на интеропе на свой интерфейс, бо родной дотнетный корявый и тормозной.

Здравствуйте, samius, Вы писали:

S>Соглашусь, посетитель был бы кстати. Но ничто не мешает прикрутить внешнюю диспетчеризацию

Только это уже куча писанины, и, в отличие от внутреннего визитора, обработка всех вариантов компилятором не гарантируется.

S>или dynamic-ах.

Ты это серьезно?

... << 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. В этом плане у кого больше статики?

Здравствуйте, AndrewVK, Вы писали:

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>Это все?

Если речь об истоках, должно было хватить.

Здравствуйте, 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

Насколько это ФП — это уже ХЗ

SV.>А хранение и вычисление где будут реализованы?

Хм. Всю жизнь математика была, по сути, чистейшим ФП. И тут ВНЕЗАПНО сложности понять, как она реализована

Классическая математика:

a = f(), // вычислили и сохранили
b = g(), // вычислили и сохранили
c = a + b. // вычислили и сохранили
...

// вычислили и сохранили
// каждая из функций — просто функция
// сумма — банальный ленивый foldl по списку

$z=\[\sum_{i=1}^{\left[\frac{n}{2}\right]}\binom{x_{i,i+1}^{i^{2}}} {\left[\frac{i+3}{3}\right]}\frac{\sqrt{\mu(i)^{\frac{3} {2}}(i^{2}-1)}}{\sqrt[3]{\rho(i)-2}+\sqrt[3]{\rho(i)-1}}\]$

Но ведь это так сложно!!! Ни вычислить ни сохранить!

Здравствуйте, 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. В этом плане у кого больше статики?
А если наследование есть, то не заменяет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Если ты настаиваешь, я тебе продемонстрирую, где ты подменил мое высказывание. Сперва смотрим (1) — речь зашла о языках бизнес-правил, которые не создают новые абстракции. В (2) мое утверждение, раскрываю с учетом (1): "Написатели бизнес-правил на спецязыке без создания абстракций — не программисты в привычном понимании". А в (3) ты переиначиваешь мое высказывание, легким движением руки заменяя "языки бизнес-правил без абстракций" на языки высокого уровня. Это, батенька, называется подтасовка.

Я их не заменяю на языки высокого уровня. Я их считаю языками наиболее высокого уровня из возможных, так как меряю уровень по числу конструкций языка, требуемых для выражения понятийного аппарата предметной области. Чем этих конструкций меньше (и соответственно, меньше деталей реализации), тем уровень выше. Вне рамок предметной области оценка высоты уровня языка не имеет смысла. У вас тут тоже спор идет по большей части о применимости т.н. языков общего применения к конкретным, пусть и более широким, предметным областям, а не "вообще, в целом".

Если есть возможность рисовать абстракции более высокого уровня, то в зависимости от предметной области, это может быть интересно. Хотя в том же форексе почти все абстракции-классы по факту, сколько помню, ложились на понятия предметной области один к одному. Более высоких не требовалось.

K>>Я понимаю, очень приятно смотреть на такие языки

AVK>Какие такие? Давай конкретные примеры в студию. Вот в нашей платформе (Парус Торнадо) есть несколько языков, имеющих отношение к бизнес-правилам. Например, язык метаданных платформы, описывающий прикладные сущности (текстовый декларативный язык + гуевый дизайнер). Но, вот что характерно, этот язык напрямую предназначен для создания новых абстракций.

Примеры полезных абстракций, пожалуйста.

AVK>А вот есть еще язык (в какой то мере, это не текстовый язык) задания правил обработок (проводок) документов. В нем таки нет никаких средств создания новых абстракций, только использование существующих. И таки те, кто этим пользуется, нифига не программисты, а всякие внедренцы и админы.

Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь. Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.

Здравствуйте, vdimas, Вы писали:

I>>Так у вас что, живые ссылки на эти пустые списки ?

V>Конечно, живые. Пока живо сообщение, жив список его полей, даже если он пуст.

Вот это и есть ошибка. Скорее всего вы создали для GC проблемы в другом месте и ему стало проблематично рабоать даже с нулевым поколением. Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами.

I>>Похоже вы придумали проблему что бы элегантно решить по месту возникновения

Дешевле хранить нуль и создавать пустой список.

V>Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...

Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно:

return list ?? new ArrayList<T>();

return list ?? Static<ArrayList<T>>.Instance;

Соответсвенно экономия в перформансе за счет инстанцирований и GC, на тех цифрах, что ты показал, оно вообще не заметно. Экономию по памяти — это исправление ошибки дизайна низкоуровневой техникой.

Если от тебя примера не будет — не надо ничего писать, идёт ?

Здравствуйте, vdimas, Вы писали:

V>Дык, именно в этом соль.

Соль в том, что ты неверно трактуешь понятие чистоты функции, не смотря на довольно простое и однозначное определение.

V>Мало ли, что компилятор в процессе оптимизации переписывает?

Он, такие дела, и порядок вычислений тоже меняет. Так что в общем случае нет, порядок вычислений определить по Ф-программе нельзя.

V>Точно так же и компилятор ФП, он может переписать много, но семантика результата должна быть точно такая же, как я получаю, пробегаясь по коду глазами... Иначе, как программировать-то?

Порядок вычислений в семантику чистого Ф-кода не входит, в отличие от императивного.

V>>>Фортран, ес-но.
AVK>>Это все?
V>Если речь об истоках, должно было хватить.

Т.е. это все. ЧТД.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, kittown, Вы писали:

K>Я их не заменяю на языки высокого уровня.

Я, кажется, прекрасно продемонстрировал твой финт ушами.

K> Я их считаю языками наиболее высокого уровня из возможных

Считай наздоровье. Только это не имеет вообще никакого отношения к моему утверждению. В нем в качестве критерия использовалось вполне конкретное отсутствие средств создания абстракций, а вовсе не мифическая высота уровня.

AVK>>Какие такие? Давай конкретные примеры в студию. Вот в нашей платформе (Парус Торнадо) есть несколько языков, имеющих отношение к бизнес-правилам. Например, язык метаданных платформы, описывающий прикладные сущности (текстовый декларативный язык + гуевый дизайнер). Но, вот что характерно, этот язык напрямую предназначен для создания новых абстракций.

K>Примеры полезных абстракций, пожалуйста.

Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?

K>Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь.

А я — нет. Потому что они не программируют.

K> Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.

Ух ты. Ты внедренец, что ли?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Mamut, Вы писали:

M>Подумалось мне что-то... А ведь классическое «висит окно, принимает события» — это классический Erlang

Висит, принимает ... Куда интереснее что происходит, когда я в дизайнере надпись на кнопочке меняю. Или в рантаме жамкаю по чекбоксу.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, samius, Вы писали:

S>Если бы визитора генерил компилятор ФП, то он мог бы давать какие-то гарантии.

Мог бы. Но ведь не генерит.

S> Но в рукописном внутреннем визиторе тоже нет гарантий обработки всех вариантов.

Есть. Ну если специально не вредить. Абстрактный AcceptVisitor в базовом классе заставит себя реализовать во всех неабстрактных потомках.

S>>>или dynamic-ах.
AVK>>Ты это серьезно?
S>почему бы и нет, для случаев где за тактами бегать не надо

Да при чем тут такты? Это прежде всего отказ от статического контроля типов со всеми вытекающими.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

I>>Указатель на функцию это уже ФП, опаньки ! Процедурная парадигма не умеет никаких таких вещей.

V>Дудки, ФП — это где есть механизм ФВП. А если речь об адресе статической ф-ии, видимой в compile-time, то это не ФП, а банальный AddressOf из махровых императивных 70-х.

В структурном программировании нет никаких указателей на функции.

Ну ладно, хрен с ним , вот еще пример

Mod modifier = GetSalt();
Ctx ctx = GetContext();

Order(x => modifier[ctx].Apply(x))

Покажи такой же фокус, что бы все было так же прозрачно.

I>>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.

V>Ниче не понял, перефразируй, плиз.

В моем примере лямбды дают инверсию и прозрачность, нет нужны ковырять внутренности. В твоем ничего этого нет, можно догадываться только исходя из имен методов.

I>>В моем случае все это по месту вызова.
V>Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))

Лямбды избавлдяют от нехобходимости проектировать структуры данных и сигнатуры для взаимодействия, тупо берешь локальный контекст и используешь. Изменился контекст — не надо ничего менять снаружи. В твоем случае надо перепахивать все подряд,ибо надо проектировать и структуры данных и сигнатуры.

V>Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
V> Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.

Там нет никакого IoC. не веришь — покажи аналог для моего кода выше.

V>Да, я привел основную концепцию ФП на не ФП. Именно это я и хотел тебе показать, см своё исходное утверждение:

То есть, все атки ФП ? Опаньки ! А надо было показать разницу между функционально и процедурной.

Здравствуйте, samius, Вы писали:

S>>>Нет никакого поведения у двери кроме как подчиняться законам природы.
V>>Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться.
S>Это не дверь отказывается, а ты делаешь что-то не так.

Это вы, батенька, уже малость забегали.

V>>То бишь, послать сообщение "откройся внутрь" объекту-двери и само открытие двери — это разные события.
S>В реальной жизни я с дверьми не разговариваю. Я их открываю без посылок сообщений.

Одновременными события могут быть только в квантовой механике у запутанных частиц. В макромире же события обзательно имеют причину. На этом держится закон сохранения энергии. Ты не открываешь дверь, ты прикладываешь усилие. И дверь будет открыта только если:
— приложенное усилие будет в нужном направлении;
— замок не закрыт;
— петли смазаны... или не смазаны, но приложенного твоего усилия хватит преодолеть силу трения покоя.

Вам ведь уже давно сказали, что обсуждать дверь без фиксации подробностей модели двери в ТЗ — это натуральное сумашедствие. Добавлю от себя, если не понятно: потому что можно спекулировать и измываться над любым оппонентом и его здравым смыслом сколь угодно долго, достаточно "играть" подробностями модели в споре, корректируя их как тебе будет удобно для целей язвительного ответа. Ты 3-й пост ровно это пытаешься делать.

S>То что дверь становится открытой или продолжает оставаться закрытой — это безусловно мессадж. Но не от двери конечно же. Это мессадж от меня самого, что если буду заходить в закрытую дверь — расшибу лоб. В моей реальной жизни все именно так.

В твоей реальной жизни еще играют рояль твои органы чувств, как минимум зрение и/или осязание. И цикл обработки сигналов от органов чувств тоже не такой уж чтобы сложный для моделирования в ООП.

S>Но когда я делаю ООП модель с методом у двери, все мои представления о реальной жизни сливаются в унитаз и появляется грубая шизофреническая пародия, где дверь отвечает, открыта ли она.

Дык, надо было учить физику в школе, тогда ничего в унитаз бы не слилось. ))

Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят в потенциальные, импульс поглощается притолокой или твоей руйкой и т.д. и т.п., ты той же рукой осязаешь положение двери и/или контроллируешь ее положение взглядом, сигналы органов чувств попадает тебе в мозг, накладываются на твой опыт и понимание, как выглядит/озязается открытая и закрытая дверь, и после сопоставления своего опыта и сигналов рецепторов ты делаешь вывод о том, открыта ли она... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу! Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе. Если эти события не единомоментны в твоей модели, то это будут два разнесенных во времени события, связанных причино-следственной связью. И ты применишь какой-нить паттерн асинхронного вызова с калбэком, где экземпляр калбэка и отвечает в упрощенной модели за причинно-следственную связь. Если же мы абстрагируемся и от фактора времени, то вернуть результат можно сразу же, как результат вызова ф-ии, итого:

enum State { Open, Closed }

class Door {
  public State Open() {}
  public State Close() {}
}

Учитывая целеустремленность человеческой психики, кому-то нейтральное описание событий покажется пресным и он предложит другой вариант:

enum Achievement { Success, Fail }

class DoorAsTarget {
  public Achievement Open() {}
  public Achievement Close() {}
}

Но т.к. оба варианта могут быть выражены один из другого взимно однозначно, то лично мне фиолетофо. ))

S>То как будет сформулировано ТЗ не повлияет на возможность реальной двери рассылать сообщения. Это свидетельствует в пользу того что ООП-изация двери далека от рж.

Пока что это свидетельствует о, скажем, недоформулированном ТЗ и больше ни о чем.

Как это дверь в реальной жизни не рассылает сообщения? )))
А как же ты её видишь и/или осязаешь? По закону сохранения энергии, сигналы в твоих рецепторах органов чувств не могут взяться из ниоткуда. Это, уважаемый коллега, пришло внешнее для тебя воздействие. Будь оно оптическое или ньютоновское.

V>>Такой у него точно не было ))
S>Значит ты его точно не читал

А что, он писал про сквозняк и всё что ты там предполагал ты, оказывается, его цитировал? )))
Не обижай старика-то...

V>>Позволь мне разобраться самостоятельно, что как называть. "функциональный объект" — это известный устоявшийся термин. Это именно то, как выглядит ФВП с точки зрения ООП, то бишь его внутренняя конструкция. И да, замыкания могут быть мутабельными... Хотя бы в Лиспе.
S>Я написал о чистом языке. Мутабельные замыкания в чистом языке — это определенно прорыв.

Увы, если замыкание реализовано by-name, или мутирующие ф-ии для переменных не создают нового одноименного значения в контексте, а изменяют старое — то так и есть. Просто есть много реализаций и проблема совместимости Лиспового кода как раз и состоит в разной семантике замыканий и операций над т.н. "контекстом". Но популярный CL — самый "грязный" из всех реализаций...

S>>>>>На самом деле от Лисп-атома до кортежа функций не так далеко.
V>>>>Бесконечно далеко.
S>>>ну-ну
V>>По-я-сни.
S>Я на самом деле не в теме, но речь явно не о бесконечности.

5 баллов! )))
Я бы под пиво или что покрепче такой ход беседы понял бы... Но вот так здесь и сейчас...

V>>Дык, если наследования нету, то компилятор С++ вообще виртуальные вызовы на обычные заменяет аж бегом. В обход vtable. В этом плане у кого больше статики?
S>А если наследование есть, то не заменяет.

А если у хаскеля более одного типа в обобщенной рекурсии, типизированной тайпклассом, то механика протягивания vtable ничем не лучше как в С++. Он выбирает конкретный vtable ес-но в рантайм.

По указанной в пред посте ссылке, рядом с этим постом в обсуждении есть разбор механики тайпклассов для таких сценариев.

Здравствуйте, vdimas, Вы писали:

V>Даже есть условные переходы, но нет циклов.

Инструкцию loop уже отменили?

V> Есть вызов подпрограмм по неизвестному в compile-time адресу, но нет ФВП.

Если учесть отсутвие контроля сигнатуры функции, то все признаки ФВП имеются. Признаки у ФВП такие:
Functions can consume functions as arguments
Functions can produce functions as return values

Очевидно, что и то и другое в ассемблере х86 делается без каких либо проблем.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

M>>Подумалось мне что-то... А ведь классическое «висит окно, принимает события» — это классический Erlang

AVK>Висит, принимает ... Куда интереснее что происходит, когда я в дизайнере надпись на кнопочке меняю. Или в рантаме жамкаю по чекбоксу.

Отослали сообщение куда надо

Только вот что именно является этим «куда надо» — хз

В случае с Эрлангом это таки будет процесс, держащий в себе состояние

Здравствуйте, AndrewVK, Вы писали:

AVK>Есть. Ну если специально не вредить. Абстрактный AcceptVisitor в базовом классе заставит себя реализовать во всех неабстрактных потомках.

Дык, если потомки сложатся в иерархию, то система ломается, когда реализация только в ее корне. Вот этим мне визитор и не нравится, что легко для некоего наследника забыть переопределить метод посещения. На самом деле только ради убежать от этих граблей я пришел к тому трюку с замыканием, который недавно показывал, — он полностью безопасен.

Здравствуйте, DarkGray, Вы писали:
DG>лучше на пальцах покажи.
DG>вот, например, счет Xxx при доступе через инет-банк, банкомат и операциониста — это один и тот же счет или разный?
DG>идентичность при этом у него строго определенная, а вот набор операций меняется, доступное состояние тоже.
В зависимости от реализации

И идентичность у него может быть тоже совершенно разной. То, что тебе кажется одним и тем же объектом, окажется принципиально разными пятью, когда ты придёшь в банк.

DG>во-первых, какое отношение определенность(или неопределенность) границы объекта имеет к идентичности?
Очень простое — идентичность должна всегда давать однозначный результат. Для неё должны сохраняться требования транзитивности и симметричности.
А "нечёткая" идентичность этому не будет соответствовать.
DG>во-вторых, при необходимости всегда можно построить две последовательности определений, которые будут задавать границу с заданной точностью.
Тогда мы получим какую-то другую математику, не ООП.

Здравствуйте, AndrewVK, Вы писали:

K>>Я их не заменяю на языки высокого уровня.

AVK>Я, кажется, прекрасно продемонстрировал твой финт ушами.

Какой финт ушами ? Вы подразумевали не то, что подразумевал я, и все.

K>> Я их считаю языками наиболее высокого уровня из возможных

AVK>Считай наздоровье. Только это не имеет вообще никакого отношения к моему утверждению. В нем в качестве критерия использовалось вполне конкретное отсутствие средств создания абстракций, а вовсе не мифическая высота уровня.

У меня другой — необходимость использования этих средств для моделирования предметной области, или ее отсутствие. Т.е. может и можно, может и нет — это по большому счету несущественно.

K>>Примеры полезных абстракций, пожалуйста.

AVK>Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?

Это не абстракция над предметной областью. Это в предметной области есть само по себе.

K>>Именно этих людей (внедренцев) я и причисляю к программистам в первую очередь.

AVK>А я — нет. Потому что они не программируют.

Сыграю в капитана. У вас вполне определенное понятие, что есть программирование, а что — нет. Но это лишь ваше определение слова, не более того. Как и мое. Есть и другие. Существенна может быть лишь разница в отношении того, что они определяют.

K>> Хотите — не соглашайтесь. Просто в современной разработке им повезло сбросить наиболее нудную часть кодинга и проектирования программистам попроще (гикам), кто сидит в офисе и получает готовое разжеванное ТЗ.

AVK>Ух ты. Ты внедренец, что ли?

Сейчас нет. Зато я постоянно наблюдаю пагубные последствия отсутствия такого опыта на коллегах. Для некоторых даже понятие тестирования результатов их творчества на фокус-группах — непонятная ересь, мол мы сами лучше знаем, как должен быть сделан интерфейс, "и как мы можем кому-то там верить???". Вместо этого тратят время на архитектурные изыски в отдельных коммитах и заумные рассуждения о парадигмах. Сервер может упасть, ну так чо, поднимем... тоже мне невидаль. Потом приходит маркетинг и объясняет, сколько лавэ слили в унитаз из-за даунтайма, понимающе кивают и гудят, через месяц все по-прежнему.

А вот разбить эту команду на пишущих конечный код, и готовящих вспомогательные инструменты (и проблемно-ориентированные языки), и глядишь, у первых времени на весь этот гундеж не останется.

Я уже вообще молчу про двух программистов-менеджеров в двух разных компаниях, один напирал на новые фичи (проект грозились закрыть из-за нерабочести старых), другой — что проект готов, его надо использовать как есть, на новые фичи время тратить не надо (проект вместо с отделом закрыли из-за отсутствия видимого развития). Тоже чувство реальности на нуле, как и у гундящих программистов из абзаца выше.

Вообще, если человек никогда не участвовал во всем цикле, начиная со сбора требований, продолжая реализацией и саппортом, и заканчивая переводом на новую систему после end of life старой, я бы ему не доверял.

Но это мы уже совсем ушли в сторону.

Здравствуйте, vdimas, Вы писали:

V>Дык, если потомки сложатся в иерархию, то система ломается, когда реализация только в ее корне.

Это можно сделать только сознательно.

V> Вот этим мне визитор и не нравится, что легко для некоего наследника забыть переопределить метод посещения.

Невозможно забыть реализовать абстрактный метод. А реализация AcceptVisitor в нетерминальном классе лишена какого либо смысла и может быть сделана только с целью вредительства.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, kittown, Вы писали:

AVK>>Я, кажется, прекрасно продемонстрировал твой финт ушами.
K>Какой финт ушами ?

AVK>>Считай наздоровье. Только это не имеет вообще никакого отношения к моему утверждению. В нем в качестве критерия использовалось вполне конкретное отсутствие средств создания абстракций, а вовсе не мифическая высота уровня.

K>У меня другой

Это и называется подтасовкой.

AVK>>Зачем? Примеры специфичны для конкретных предметных областей. Например "Проводка бухгалтерской справки". Сильно полегчало?
K>Это не абстракция над предметной областью. Это в предметной области есть само по себе.

Мдя. Это даже не смешно.

AVK>>Ух ты. Ты внедренец, что ли?

K>Сейчас нет.

То есть был. Ясно, больше вопросов не имею.

K>Но это мы уже совсем ушли в сторону.

Это вы ушли.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

S>>Если бы визитора генерил компилятор ФП, то он мог бы давать какие-то гарантии.

AVK>Мог бы. Но ведь не генерит.
Увы и ах

S>> Но в рукописном внутреннем визиторе тоже нет гарантий обработки всех вариантов.

AVK>Есть. Ну если специально не вредить. Абстрактный AcceptVisitor в базовом классе заставит себя реализовать во всех неабстрактных потомках.
Гарантия наличия реализации есть, но гарантии корректной реализации нет. Потому, не особо важно, где мы будем руками вписывать диспетчеризацию. Либо руками в каждом наследнике, либо руками где-то еще, с соответствующей ручной гарантией "зуб даю".

S>>>>или dynamic-ах.
AVK>>>Ты это серьезно?
S>>почему бы и нет, для случаев где за тактами бегать не надо

AVK>Да при чем тут такты? Это прежде всего отказ от статического контроля типов со всеми вытекающими.
Да, с вытекающим рантайм контролем, который нехило бы чекнуть тестами. Что, собственно, не вредно сделать и с рукописным визитором, т.к. компилятор корректность диспетчеризации не контроллирует.

Здравствуйте, AndrewVK, Вы писали:

V>>Даже есть условные переходы, но нет циклов.
AVK>Инструкцию loop уже отменили?

Поймал. Действительно, в x86 есть, но не рекомендован, поэтому в ассемблерных распечатках плюсовых программ давно не видел.

Но в >90% других архитектур — аналога нет.

V>> Есть вызов подпрограмм по неизвестному в compile-time адресу, но нет ФВП.

AVK>Если учесть отсутвие контроля сигнатуры функции, то все признаки ФВП имеются. Признаки у ФВП такие:
AVK>Functions can consume functions as arguments
AVK>Functions can produce functions as return values

AVK>Очевидно, что и то и другое в ассемблере х86 делается без каких либо проблем.

Тогда из иронии оно превращается этов аргумент в мою пользу. Правда, боюсь, если бы эту мысль высказал не ты, а я, Синклер нашел что возразить. Впрочем, и уменя есть что возразить, но против агрумента на моей стороне пока не буду. ))

Здравствуйте, samius, Вы писали:

S>Гарантия наличия реализации есть, но гарантии корректной реализации нет.

Нет, но это не страшно. Все таки программные проверки это не безопасность, рассчитывать надо прежде всего на случайные ошибки, а не на сознательное вредительство.

AVK>>Да при чем тут такты? Это прежде всего отказ от статического контроля типов со всеми вытекающими.
S>Да, с вытекающим рантайм контролем, который нехило бы чекнуть тестами. Что, собственно, не вредно сделать и с рукописным визитором, т.к. компилятор корректность диспетчеризации не контроллирует.

Я категорически против отказа от статики ради решения каких то внутрипрограммных задач. Так что для меня это не вариант.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Sinclair, Вы писали:

I>>В двадцатом уже были универсальные вычислители. А про логарифмическую линейку, счеты ты тоже забыл ?
S>Линейка и счёты не ведут себя как объекты.

Линейка.ВзятьСумму(5,3)

Причем это ровно тож самое, что и в анемиках TransferSevice.Transfer(acc1,acc2, amount)

I>>Соответсвено идея вычислителя, как некоего устройства, есть заимствование из реального мира.
S>Омг, омг. У нас была предметная область (вы называете её реальным миром), состоящая из коровы и травы.
S>Внезапно (ВНЕЗАПНО!) в этот реальный мир внедряется некое устройство, как идея вычислителя.

Внезапно, если вспомнить контекст, что вычислитель был нужен в примере про математические операции

S>А вот ООП-программа почему-то совершенно не обращает внимания на корову и траву, а вместо этого моделирует вычислитель, которого вовсе нет и никогда не было.
S>И это совершенно правильно и корректно. Вот только учебники ООП почему-то как правило при рассмотрении коровы и травы не предлагают моделировать машину Бэббиджа, зато предлагают моделировать корову и траву.

Я привел пример где моделируется именно корова и трава, только коровой был медведь, а травой — мертвечина. Чем тебя этот пример не устроил ?

>Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".

Ну так в учебниках синтетические задачи, это общая беда без малого всех учебников по программированию, при чем в ФП это вообще считается за норму. Просто авторы смешивают программирование и моделирование.

Здравствуйте, Ikemefula, Вы писали:

I>Линейка.ВзятьСумму(5,3)

Причем это ровно тож самое, что и в анемиках TransferSevice.Transfer(acc1,acc2, amount)
Попробуйте этот трюк с реальной линейкой. Посмотрим, возьмёт ли она сумму.
Или всё-таки придётся самостоятельно выполнять действия с ней — руками, глазами, и мозгом.

I>Внезапно, если вспомнить контекст, что вычислитель был нужен в примере про математические операции

Ну, а вот в пятом классе, при решении квадратных уравнений, почему-то обходятся безо всяких вычислителей.

I>Я привел пример где моделируется именно корова и трава, только коровой был медведь, а травой — мертвечина. Чем тебя этот пример не устроил ?
Долго рассказывать. Вкратце: игры, где задача сводится именно к моделированию поведения медведей, суть редкое исключение из правила — там, действительно, есть шанс получить first-class objects из "реальных сущностей".
А если у нас задача стоит чуть по-другому — например, начисление людям зарплаты, то внезапно окажется, что ни зарплата, ни люди объектами не являются. Хотя на основе учебников так и кажется, что класс Manager будет отнаследован от класса Employee.

>>Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".

I>Ну так в учебниках синтетические задачи, это общая беда без малого всех учебников по программированию, при чем в ФП это вообще считается за норму. Просто авторы смешивают программирование и моделирование.
Ну вот и не надо повторять ошибки этих учебников. Надо отказаться от желания моделировать реальный мир там, где задача не стоит в моделировании реального мира, и сразу ООП заиграет яркими красками.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Это не дверь отказывается, а ты делаешь что-то не так.

V>Это вы, батенька, уже малость забегали.
Да нет, я стою на месте.

S>>В реальной жизни я с дверьми не разговариваю. Я их открываю без посылок сообщений.

V>Одновременными события могут быть только в квантовой механике у запутанных частиц. В макромире же события обзательно имеют причину. На этом держится закон сохранения энергии. Ты не открываешь дверь, ты прикладываешь усилие. И дверь будет открыта только если:
V>- приложенное усилие будет в нужном направлении;
V>- замок не закрыт;
V>- петли смазаны... или не смазаны, но приложенного твоего усилия хватит преодолеть силу трения покоя.
Видишь, как все сложно в реальной жизни!

V>Вам ведь уже давно сказали, что обсуждать дверь без фиксации подробностей модели двери в ТЗ — это натуральное сумашедствие. Добавлю от себя, если не понятно: потому что можно спекулировать и измываться над любым оппонентом и его здравым смыслом сколь угодно долго, достаточно "играть" подробностями модели в споре, корректируя их как тебе будет удобно для целей язвительного ответа. Ты 3-й пост ровно это пытаешься делать.
Я не говорю о фиксации. Я говорю что дверь.Откройся() далека от рж безотносительно ТЗ. Такая модель может соответствовать ТЗ, я ведь об этом ничего не говорю. Но далека от реальной двери.

V>В твоей реальной жизни еще играют рояль твои органы чувств, как минимум зрение и/или осязание. И цикл обработки сигналов от органов чувств тоже не такой уж чтобы сложный для моделирования в ООП.
Он может быть не такой и сложный, но ООП все поставит с ног на голову.

S>>Но когда я делаю ООП модель с методом у двери, все мои представления о реальной жизни сливаются в унитаз и появляется грубая шизофреническая пародия, где дверь отвечает, открыта ли она.

V>Дык, надо было учить физику в школе, тогда ничего в унитаз бы не слилось. ))
Ты сам сливаешь всю физику (ниже)

V>Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу!
Видишь, ты сам понимаешь что модель далека от моделируемого.

V>Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе.
Вот тут ты свою физику и слил. Дальше скипаю.

S>>То как будет сформулировано ТЗ не повлияет на возможность реальной двери рассылать сообщения. Это свидетельствует в пользу того что ООП-изация двери далека от рж.
V>Пока что это свидетельствует о, скажем, недоформулированном ТЗ и больше ни о чем.
ну, вспоминай физику, которую ты слил. Что-то я не помню что бы ты говорил о сообщениях в ней.

V>Как это дверь в реальной жизни не рассылает сообщения? )))
V>А как же ты её видишь и/или осязаешь? По закону сохранения энергии, сигналы в твоих рецепторах органов чувств не могут взяться из ниоткуда. Это, уважаемый коллега, пришло внешнее для тебя воздействие. Будь оно оптическое или ньютоновское.
Все пропало! Двери воздействуют на людей ньютоновскими силами! Спасайтесь кто может!
Я пользуюсь рецепторами вне зависимости от наличия рядом двери. И это, отраженный свет послан мне внезапно не дверью вовсе. И кстати, если я вижу дверь, то я ее вижу вне зависимости от того спрашивал я дверь о том, вижу ли ее или нет. Т.е. концепции единого сообщения нет. Пусть будет мульон сообщений. Но ведь в твоей модели лишь одно...

V>>>Такой у него точно не было ))
S>>Значит ты его точно не читал

V>А что, он писал про сквозняк и всё что ты там предполагал ты, оказывается, его цитировал? )))
V>Не обижай старика-то...
Про сквозняк нет, но про воображаемые компьютеры — это его мысль.

S>>Я написал о чистом языке. Мутабельные замыкания в чистом языке — это определенно прорыв.

V>Увы, если замыкание реализовано by-name, или мутирующие ф-ии для переменных не создают нового одноименного значения в контексте, а изменяют старое — то так и есть. Просто есть много реализаций и проблема совместимости Лиспового кода как раз и состоит в разной семантике замыканий и операций над т.н. "контекстом". Но популярный CL — самый "грязный" из всех реализаций...
Еще раз. Я писал о ЧИСТОМ языке. CL не чист.

V>>>По-я-сни.
S>>Я на самом деле не в теме, но речь явно не о бесконечности.

V>5 баллов! )))
V>Я бы под пиво или что покрепче такой ход беседы понял бы... Но вот так здесь и сейчас...
Ты хочешь что бы я как ты вилял? Мне это зачем?

V>А если у хаскеля более одного типа в обобщенной рекурсии, типизированной тайпклассом, то механика протягивания vtable ничем не лучше как в С++. Он выбирает конкретный vtable ес-но в рантайм.
А я не говою что она лучше. Я говорю что она другая.

V>По указанной в пред посте ссылке, рядом с этим постом в обсуждении есть разбор механики тайпклассов для таких сценариев.
разбор механики ничего не говорит о заимствовании.

Здравствуйте, AndrewVK, Вы писали:

AVK>Если учесть отсутвие контроля сигнатуры функции, то все признаки ФВП имеются. Признаки у ФВП такие:
AVK>Functions can consume functions as arguments
AVK>Functions can produce functions as return values

AVK>Очевидно, что и то и другое в ассемблере х86 делается без каких либо проблем.

В ассемблере x86 нет никаких функций, соответственно нет ни consume ни produce. Функции это уже абстракция, появляется в ЯВУ. Макроассемблер — фактически ЯВУ, а не просто ассемблер и там функции есть, как и положено. При чем писать можно так (IDEAL)

call F arg1 arg2 arg3

Все это выльется в N ассемблерных инструкций, в зависимости от модели памяти, соглашения о вызовах и декларации функции F.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, samius, Вы писали:

S>>Гарантия наличия реализации есть, но гарантии корректной реализации нет.

AVK>Нет, но это не страшно. Все таки программные проверки это не безопасность, рассчитывать надо прежде всего на случайные ошибки, а не на сознательное вредительство.
да, и что-то можно не реализовать случайно, особенно после генерации заглушки с исключением.
Я согласен, что для взаимодействия с C# и VB лучше было бы генерить визитора для вариантов, но это не основной сценарий, потому генерить его компилятором ФЯ для всех вариантов может быть накладно (можно было бы использовать атрибут для маркировки актуальных типов).

S>>Да, с вытекающим рантайм контролем, который нехило бы чекнуть тестами. Что, собственно, не вредно сделать и с рукописным визитором, т.к. компилятор корректность диспетчеризации не контроллирует.

AVK>Я категорически против отказа от статики ради решения каких то внутрипрограммных задач. Так что для меня это не вариант.
Хорошо, нечего возразить и добавить. Точка.

Здравствуйте, AndrewVK, Вы писали:

AVK>А реализация AcceptVisitor в нетерминальном классе лишена какого либо смысла и может быть сделана только с целью вредительства.

Это исключительно от самой иерархии зависит. В том же дотнете полно наследников от неабстрактных классов.

Здравствуйте, samius, Вы писали:

V>>А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо.
S>Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.

Какое мне дело, что именно тебя не интересует?

V>>Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу.
S>Еще раз. Речь идет об ветвлении исполнения стейтментов,

Речь идёт о ветвлении как таковом. Остальное — твои личные фантазии и неуклюжие попытки ограничить меня уютными тебе рамками.

S>В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.

Я про возможность применения его в IO без каких-либо доработок вроде бы сказал сразу, не? Тебе это сколько еще повторять? Побочный эффект возникает ПОСЛЕ применения if, ес-но, как результат выполнения хвоста в цепочке IO-вычислений. Ес-но не в момент вычисления предиката при if, а в момент прохождения потока вычисления только по одной из двух веток, описанных в исходнике. Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?

Здравствуйте, samius, Вы писали:

S>Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.

Кстате, хотел бы я увидеть побочный эффект на операторе if для императивного языка. Будем считать, что ветвимся по уже вычисленной переменной. Дерзай.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
I>>>А что ты видел в дизайне распределенных ?
ВВ>>Анемики, сервисы и иже с ними.

I>Это все православное ООП

Анемик — православное ООП? Фаулер бы поспорил с вами: http://martinfowler.com/bliki/AnemicDomainModel.html

А каким образом SOA со своими политиками, stateless (в большинстве случаев) сервисами (а следовательно, и лишенными поведения) и совершенно другими принципами декомпозиции становится ООП да еще православным?

Здравствуйте, samius, Вы писали:

S>>>Это не дверь отказывается, а ты делаешь что-то не так.

V>>Это вы, батенька, уже малость забегали.
S>Да нет, я стою на месте.

Стоял бы на месте если бы не увиливал от аргументов:

V>>Поведение — это реакция на внешние раздражители. Например, при попытке открыть дверь не в ту сторону, поведение двери будет вполне предсказуемым — она откажется открываться.

S>Видишь, как все сложно в реальной жизни!

Это я еще не всё описал. Но я и не собрался, просто ХЗ сколько тебе надо подробностей, чтобы показать причинно-следственную связь событий, которую ты перед этим показательно проигнорировал.

V>>Вам ведь уже давно сказали, что обсуждать дверь без фиксации подробностей модели двери в ТЗ — это натуральное сумашедствие. Добавлю от себя, если не понятно: потому что можно спекулировать и измываться над любым оппонентом и его здравым смыслом сколь угодно долго, достаточно "играть" подробностями модели в споре, корректируя их как тебе будет удобно для целей язвительного ответа. Ты 3-й пост ровно это пытаешься делать.
S>Я не говорю о фиксации. Я говорю что дверь.Откройся() далека от рж безотносительно ТЗ.

Дык, разрешение абстрагироваться от подробностей тебе затем и дано, чтобы ты не вычислял лишнего в программе. Тики-то процессора не бесплатные и не бесконечные. Особенно во времена становления ООП. )))

S>Такая модель может соответствовать ТЗ, я ведь об этом ничего не говорю. Но далека от реальной двери.

Пофиг, в инженерии кач-во решения определяется степенью его соответствия функциональным и нефункциональным требованиям. Это всё!

Опять же — модель двери ни в коем случае не самоцель. Парадигма вообще не может быть самоцелью. Модель двери — это инструмент, помогающий упорядочить наше понимание о происходящем в собственном коде, это элемент решения задачи. В конкретной иерархии объектов это мог быть элемент декомпозии по принципу SRP и ничего более. И то, если дверь имеет поведение в том смысле как показал, например, существует в коде возможность "попытаться открыть дверь не в ту сторону", а дверь "умно" реагирует. А так-то если никакого поведения нет, то объект можно смело заменять данными, в данном случае:

bool doorState;

Вот почему я надоедаю со своим ТЗ, что мы-то обсуждаем решение, а условия никто еще не слышал. Дурдом? Натуральный. Отсюда и столь различные решения у всех участников, как в конкурсе "принеси то, не знаю что".

V>>В твоей реальной жизни еще играют рояль твои органы чувств, как минимум зрение и/или осязание. И цикл обработки сигналов от органов чувств тоже не такой уж чтобы сложный для моделирования в ООП.
S>Он может быть не такой и сложный, но ООП все поставит с ног на голову.

Ну как раз, если моделировать сложные системы изначально наделенные состоянием и ср-вами обмена сообщениями, типа подсистем организма человека, то ООП ничего с ног на голову не поставит. Оно может тупо отразить такую систему и взаимодействие в ней со сколь угодной степенью подробностей. Пока хватит выч-ресурсов.

V>>Ты даешь двери воздействие. Затем "что-то происходит": силы складываются по-ньютоновски, кинетические энергии переходят... Но сорри, мы же программисты — ленивый народ и не делаем лишнюю работу!
S>Видишь, ты сам понимаешь что модель далека от моделируемого.

Модель задачи и модель решения — это независимые модели, увы, до тех пор, пока такая зависимость не оговорена в ТЗ.

V>>Коль тебя интересует лишь конечный результат, то мы абстрагируемся от подробностей и просто хотим получить результат — дверь открыта в итоге или нет? Итого всё взаимодействие с дверью сводится к посылке двух сообщений: от тебя к двери и от двери к тебе.
S>Вот тут ты свою физику и слил. Дальше скипаю.

Ты как всегда скипнул неудобные аргументы. В данном случае вот эти:

ты той же рукой осязаешь положение двери и/или контроллируешь ее положение взглядом, сигналы органов чувств попадает тебе в мозг, накладываются на твой опыт и понимание, как выглядит/озязается открытая и закрытая дверь, и после сопоставления своего опыта и сигналов рецепторов ты делаешь вывод о том, открыта ли она...

Объективно тебе необходимо взаимодействовать с дверью, чтобы узнать постфактум события открытия двери. Будь то оптическое взаимодейтвие, либо физическое. В любом случае переносится информация именно от двери именно к тебе и энтропия в момент доставки информации к тебе падает.

S>ну, вспоминай физику, которую ты слил. Что-то я не помню что бы ты говорил о сообщениях в ней.

Гы-гы. А что есть сообщения, по-твоему?
Термин "информация" имеет вполне определенный физический смысл.

V>>Как это дверь в реальной жизни не рассылает сообщения? )))
V>>А как же ты её видишь и/или осязаешь? По закону сохранения энергии, сигналы в твоих рецепторах органов чувств не могут взяться из ниоткуда. Это, уважаемый коллега, пришло внешнее для тебя воздействие. Будь оно оптическое или ньютоновское.
S>Все пропало!

Тебе еще не 90, еще есть шанс, не переживай.

S>Двери воздействуют на людей ньютоновскими силами!

Домашнее задание: какой закон Ньютона имелся ввиду при физическом фзаимодействии руки с дверью?

S>Я пользуюсь рецепторами вне зависимости от наличия рядом двери. И это, отраженный свет послан мне внезапно не дверью вовсе.

Оп-па! Отраженный от двери свет послан не дверью. Я бы на месте твоего школьного учителя физики съел свою шляпу.

Ну а на месте ВУЗовского съел бы там, где ты плаваешь в вопросах информации.

S>И кстати, если я вижу дверь, то я ее вижу вне зависимости от того спрашивал я дверь о том, вижу ли ее или нет.

Как это вне зависимости, если ты свои органы чувств должен настроить таким образом, чтобы достоверно различить положение двери. То бишь, получить информацию о ней? Как минимум ты должен открыть глаза, посомтреть в ее сторону и сфокусировать кристаллики глаза. Ничего себе "не спрашивал"... Или ты буквально выразился в том плане, что решил с дверью поговорить? )))

S>Т.е. концепции единого сообщения нет. Пусть будет мульон сообщений. Но ведь в твоей модели лишь одно...

Да, повторно переданная одна и та же информация не изменяет энтропию, увы. Поэтому ленивые программисты поступают с лишней информацией... впрочем, ты уже в курсе как.

V>>Увы, если замыкание реализовано by-name, или мутирующие ф-ии для переменных не создают нового одноименного значения в контексте, а изменяют старое — то так и есть. Просто есть много реализаций и проблема совместимости Лиспового кода как раз и состоит в разной семантике замыканий и операций над т.н. "контекстом". Но популярный CL — самый "грязный" из всех реализаций...
S>Еще раз. Я писал о ЧИСТОМ языке. CL не чист.

Вообще-то ты писал о Лиспе.

S>Ты хочешь что бы я как ты вилял? Мне это зачем?

Вилять можно только если влез, а потом понял, что не туда. Так что виляние уже де-факто происходит. Ты дважды оспорил, а потом так и не пояснил, ПОЧЕМУ ты спорил-то. Если не воспринимаешь оппонента всерьез, зачем столько пишешь ему в ответ?

V>>По указанной в пред посте ссылке, рядом с этим постом в обсуждении есть разбор механики тайпклассов для таких сценариев.
S>разбор механики ничего не говорит о заимствовании.

Согласен, на уровне механики заимствование не считается, это лишь подробности. Но на уровне концепции это есть контракт, который сам по себе концепция в ООП в таком точно виде. Т.е. в кач-ве концепции дизайна тайпклассы и контракты в ООП настолько близки, насколько это вообще возможно, т.к. и те и другие задают набор операций над одним и тем же элементом дизайна, в обоих случаях над типом.

Здравствуйте, Воронков Василий, Вы писали:

I>>Это все православное ООП

ВВ>Анемик — православное ООП? Фаулер бы поспорил с вами: http://martinfowler.com/bliki/AnemicDomainModel.html

Фаулер думает про ООП в симуловский концепции — данные + методы, так что его точка зрения вполне понятна. Зато анемик ничем не мешает ООП если посмотреть людей вроде Скотт Мейерс и Алан Кей.

ВВ>А каким образом SOA со своими политиками, stateless (в большинстве случаев) сервисами (а следовательно, и лишенными поведения) и совершенно другими принципами декомпозиции становится ООП да еще православным?

Если отталкиваться от симуловской концепции ОО, то да, это не ОО

Здравствуйте, Ikemefula, Вы писали:

ВВ>>Анемик — православное ООП? Фаулер бы поспорил с вами: http://martinfowler.com/bliki/AnemicDomainModel.html
I>Фаулер думает про ООП в симуловский концепции — данные + методы, так что его точка зрения вполне понятна. Зато анемик ничем не мешает ООП если посмотреть людей вроде Скотт Мейерс и Алан Кей.

Кей — это объекты, поведения, сообщения. Никаким анемиком и не пахнет. Это ж это один из тех мужиков, которые смолток сделали. Он точно не по ошибке сюда попал?

ВВ>>А каким образом SOA со своими политиками, stateless (в большинстве случаев) сервисами (а следовательно, и лишенными поведения) и совершенно другими принципами декомпозиции становится ООП да еще православным?
I>Если отталкиваться от симуловской концепции ОО, то да, это не ОО

Мне не знакома такая траковка ООП, которая бы вмещала в себя еще и все принципы SOA. Зачем ее сейчас выдумывать?

Принципы ООП были заложены в Симуле и оформились в Смолтоке. По сути ООП это и есть Кей и Смолток. А это значит "состояние", "поведение", "все есть объект" и проч. SOA тут как-то немножко мимо.

Здравствуйте, AndrewVK, Вы писали:

K>>Начинаем с голословного утверждения о моей неадекватности.

AVK>Какая, нафик, неадекватность? Сочиняешь на ходу?

Ну да. И

Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.

тоже, наверное, я сам написал, залогинившись под вашим именем, ага?

AVK>считаешь что ФП безусловно лучше и перспективнее ООП.

Условно лучше и безусловно перспективнее. Ну так что? Как из этого утверждения можно вывести, что я считаю ФП — серебряной пулей? Или лучше ООП только "серебряная пуля" может быть?

AVK>Только там таких статей, что за, что против ООП

Статьи пишут не "за и против"

AVK>что можно найти любую заранее заданную точку зрения.

Я сомневаюсь, что вы найдете статью с простым формальным описанием нетривиального ООП.

AVK>Одна проблема — формальное описание интересно в основном только математикам и любителям CS.

Так вы же сами писали

Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
1) Создания абстракций с формальным описанием внешних свойств

А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?

AVK>А наследование, агрегация, композиция, это, по твоему, не комбинирование?

Повторяю: "агрегация" и "композиция" в ФП — это функции, агрегирующие и композирующие. А в ООП это слова — никакой реальный код им не соотвествует и на ООЯ не выражается. На ООЯ выражается только конечный результат композиции, произведенной программистом в уме, без всякой помощи компьютера.
Комбинаторы функций есть, комбинаторов классов — нет. Понятно теперь, о чем я?

AVK>Потому что без него объем писанины возрастает.

Все, без чего объем писанины вырастает — это подпорка? Т.е. "подпорка" никаких отрицательных коннотаций не имеет? А если вы таки говорили "подпорка" так, как будто это что-то плохое — объясните что же плохо в карринге?

K>>Туплы — это и есть АлгТД.
AVK>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.

Нет? Это, конечно, заблуждение. Алгебраические типы — это типы-произведения (туплы, кортежи) и типы-суммы (размеченные объединения, варианты). Вторые, понятно, дискриминант имеют, а первым он без надобности.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>Вот это и есть ошибка. Скорее всего вы создали для GC проблемы в другом месте и ему стало проблематично рабоать даже с нулевым поколением.

Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки. Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.

I>Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами.

Вооот, а у нас реалтайм, мы не можем позволить GC педалить более ~50ms. Собственно, с этим борьба.

V>>Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...

I>Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно:
I>

I>return list ?? new ArrayList<T>();

I>return list ?? Static<ArrayList<T>>.Instance;
I>

Эта операция однократна, я тебе уже про пулы сказал... в отличие от операции обращения к полям.

I>Соответсвенно экономия в перформансе за счет инстанцирований и GC, на тех цифрах, что ты показал, оно вообще не заметно. Экономию по памяти — это исправление ошибки дизайна низкоуровневой техникой.

Я пока не увидел никакой указанной тобой ошибки дизайна. Неужели, опять это началось? )))

I>Если от тебя примера не будет — не надо ничего писать, идёт ?

Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать..

Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )

Здравствуйте, Klapaucius, Вы писали:

AVK>>Одна проблема — формальное описание интересно в основном только математикам и любителям CS.

K>Так вы же сами писали
K>

Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
K>1) Создания абстракций с формальным описанием внешних свойств

K>А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?

Да что ж такое то — неужели так увлекательно заниматься подтасовками? Я писал про формальное описание сущностей решаемой задачи, ты же писал про формальное описание самого ООП.

K>Все, без чего объем писанины вырастает — это подпорка? Т.е. "подпорка" никаких отрицательных коннотаций не имеет? А если вы таки говорили "подпорка" так, как будто это что-то плохое — объясните что же плохо в карринге?

Какие то у вас приемчики все одинаковые. Я нигде ни разу не писал, что карринг это плохо. Это ты все плохое в ООП выискиваешь.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, vdimas, Вы писали:

V>Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки.

Для для чего инстанцировать на момент попадания в очередь, если обработка будет после выхода из неё ?

>Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.

У меня в тесте тоже нет нулевого поколения. Так ты выдашь внятный тест или будешь и дальше сочинять ?

I>>Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами.
V>Вооот, а у нас реалтайм, мы не можем позволить GC педалить более ~50ms. Собственно, с этим борьба.

Ну так вы этот вырожденый сценарий сами же и заимплементили, ищите проблемы в управлении памятью, а не в пустых списках.

I>>Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно:
I>>

I>>return list ?? new ArrayList<T>();

I>>return list ?? Static<ArrayList<T>>.Instance;
I>>

V>Эта операция однократна, я тебе уже про пулы сказал... в отличие от операции обращения к полям.

То есть, про количество ветвлений был пустой прогон ?

I>>Соответсвенно экономия в перформансе за счет инстанцирований и GC, на тех цифрах, что ты показал, оно вообще не заметно. Экономию по памяти — это исправление ошибки дизайна низкоуровневой техникой.

V>Я пока не увидел никакой указанной тобой ошибки дизайна. Неужели, опять это началось? )))

Ну с тем, что ты чего то не видишь, никто и не спорит. см самое первое сообщение.

I>>Если от тебя примера не будет — не надо ничего писать, идёт ?
V>Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать..

Будем считать что ты знаешь куда тебе идти, ок ?

V>Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )

У меня стиль простой — пока ты не выложишь внятную модель или жосткие данные я ничего выкладывать от себя не собираюсь.

Здравствуйте, Klapaucius, Вы писали:

AVK>>Какая, нафик, неадекватность? Сочиняешь на ходу?

K>Ну да. И
K>

Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.

K>тоже, наверное, я сам написал, залогинившись под вашим именем, ага?

Покажи где в процитированом ты увидел "неадекватность"

>>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
>
> G>Это общий механизм мышления.
>
> Это общий механизм воссоздания образов, то есть воображения. Назвать это мышлением слишком сильно, нужно какое то подтверждение.

Вы оба почему-то думаете, что образное мышление и логическое это разные вещи, разные механизмы. Открою вам маленький не секрет — высшее логическое мышление это и есть образное. Физический механизм один и тот же. Нет у человека в голове специальной шишки мозга производящей числовые вычисления. Хотя некоторые структуры мозга бывают специализированными, но вот логической нет. Подтверждение? Легко. Вспомни как ты учил таблицу умножения. 2+2=4, 12^2=144 — ассоциативная выборка из памяти результата. Вот тебе и "высшая нервная деятельность" или "абстрактное мышление". То есть условно говоря, считаем деньги мы почти тем же местом, что и смотрим кино. В отдельной шишке не было необходимости, мы еще в позапрошлом веке все поголовно неграмотные были и считать почти не умели, все по памяти.

>>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов.
>
> Даже образное мышление трудно назвать набором образов, а есть еще понятийное, сиречь абстрактное мышление.

Понятийное мышление это полный синоним образного. Просто сложное понятие состоит из множества образов и связей.

>>Вообще добиться того, что бы следующий снимок не накладывался на предыдущий и не разрушал его, а это требуется для логического мышления,
>
> Не совсем ясно откуда следует что какой то снимок накладывается на предыдущий ? Это имеется ввиду какая то конкретная модель мышления ? Честно, в книгах по когнитивной психологии такого не встречал.

Скорее всего встречал, но в других формулировках или проявлениях. Не накладывается на предыдущий, а правильнее сказать образы интерферируют друг с другом. В силу разных вещей — мощность структур выборки образов меньше мощности всей памяти, место проявления образа задано физической структурой нейронов и плюс еще сам механизм ассоциативных связей дает эффект.

Posted via RSDN NNTP Server 2.1 beta

S>В зависимости от реализации

S>И идентичность у него может быть тоже совершенно разной. То, что тебе кажется одним и тем же объектом, окажется принципиально разными пятью, когда ты придёшь в банк.

и почему в границах моей системы меня должны волновать, как это устроено внутри банка? для меня это уже деталь реализации.

в границах моей системы есть объект — счет, у него есть идентификатор: z1tr5/bis, поэтому идентификатору я могу получить объект-счет хоть через инет-банк, хоть через банкомат, хоть через операциониста.
чего здесь не хватает?

DG>>во-первых, какое отношение определенность(или неопределенность) границы объекта имеет к идентичности?
S>Очень простое — идентичность должна всегда давать однозначный результат. Для неё должны сохраняться требования транзитивности и симметричности.
S>А "нечёткая" идентичность этому не будет соответствовать.

Вернемся к верёвке:


   var rope = new Rope();

      class Rope
      {
        public Rope()
        {
          this.Points = new double[100];
        }

        public double[] Points;

        public RopeEnd Start
        {
          get { return new RopeEnd(this, 0); }
        }
        public RopeEnd End
        {
          get { return new RopeEnd(this, 1); }
        }
      }
      class RopeEnd
      {
        public RopeEnd(Rope rope, int endNumber)
        {
          this.Rope = rope;
          this.EndNumber = endNumber;
        }
        public readonly Rope Rope;
        public readonly int EndNumber;

        public override bool Equals(object obj)
        {
          var ropeEnd = obj as RopeEnd;
          return object.Equals(this.Rope, ropeEnd != null ? ropeEnd.Rope : null)
            && EndNumber == (ropeEnd != null ? ropeEnd.EndNumber : (int?)null);
        }
        public override int GetHashCode()
        {
          return this.Rope.GetHashCode() ^ this.EndNumber;
        }

        static Random rnd = new Random();

        public void Change(double x)
        {
          var points = this.Rope.Points;
          if (EndNumber != 0)
            points = points.Reverse().ToArray();

          var len = rnd.Next(30);

          points = points.Select((v, i) => {var r = len - i; return r > 0 ?  v + x * r / len : v;}).ToArray();

          if (EndNumber != 0)
            points = points.Reverse().ToArray();
          this.Rope.Points = points;
        }
      }

rope.Start и rope.End являются объектами? идентичность у них есть?
граница RopeEnd относительно Rope задана однозначно или задана нечетко?

Здравствуйте, SV., Вы писали:

SV.>Ох, не стал бы я так делать!

А никто так и не делает в реальности.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Вы говорите о разных вещах. Синклер о бухгалтерском счете, ты о банковском. Это совсем не одно и тоже.

Согласен, но при этом бух. счет все равно есть ООП-объект.

AVK> В случае бухгалтерского счета в реальных системах действительно, никто не хранит в этом счете операции.

какая разница где хранится состояние объекта? это деталь реализации

AVK> Операции между счетами, проводки, это независимые сущности, которые всегда ссылаются на два счета в справочнике счетов — дебетовый и кредитный. Поведения у самого счета никакого нет, это просто маркер.

Скорее ты хочешь сказать, что у бух. счета нет атомарного поведения, все его поведение композитное и выражается через поведение других объектов, но при этом не правильно утверждать, что у счета нет поведения.

композитная операция следующего вида у счета никуда не девается:

class БухСчет
{
  public Проводка Провести(double сумма, БухСчет target, string description = null)
  {
    return журналСчетов.ДобавитьПроводку(this, target, сумма, description);
  }
}

и во многих случаях — эта операция удобнее, чем напрямую лезть в журнал счетов

Нал.Провести(-20000, Основные_Фонды, "Компьютер для Васи Пупкина");

AVK> Формируют проводки как правило специальные процедуры (методы сервисов), в особо запущенных случаях (1С) проводки формирует бухгалтерский документ. В результате хребет всех бухгалтерских данных это журнал проводок, большая часть остального навешивается на него по ссылкам, а счет это просто запись в справочнике с некоторым набором метаданных.

здесь ты также про детали реализации, и о том, как можно построить "скелет" бух. системы, используя минимальное кол-во сущностей и минимальное кол-во кода.

Здравствуйте, DarkGray, Вы писали:

AVK>> В случае бухгалтерского счета в реальных системах действительно, никто не хранит в этом счете операции.

DG>какая разница где хранится состояние объекта? это деталь реализации

При чем тут реализация? Даже на уровне дизайна системы никаких отношений принадлежности между проводкой и счетом нет. Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?

DG>Скорее ты хочешь сказать, что у бух. счета нет атомарного поведения, все его поведение композитное и выражается через поведение других объектов

Нет, я хочу сказать ровно то что сказал.

DG>композитная операция следующего вида у счета никуда не девается:
DG>

DG>class БухСчет
DG>{
DG>  public Проводка Провести(double сумма, БухСчет target, string description = null)
DG>  {
DG>    return журналСчетов.ДобавитьПроводку(this, target, сумма, description);
DG>  }
DG>}
DG>

Нет такого, я же явно написал. В реальности есть такое:

class DocTxService
{
  public Tx[] MakeDocTx(Document doc) {...}
}

// Или в стиле 1C
class Document
{
  public Tx[] MakeTx();
}

DG>и во многих случаях — эта операция удобнее, чем напрямую лезть в журнал счетов

Что значит лезть? В бухгалтерии любые проводки делаются исключительно на основании документов. Нельзя просто взять, и сделать проводку без основания (в 1С можно, но это бред). Таким образом, документ есть всегда. А вот конкретные счета вычисляются на основании все того же документа в методе формировапния проводки.

DG>здесь ты также про детали реализации

Нет, здесь лично я — исключительно про дизайн.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Нет такого, я же явно написал. В реальности есть такое:
AVK>

AVK>class DocTxService
AVK>{
AVK>  public Tx[] MakeDocTx(Document doc) {...}
AVK>}

значит для этой системы будет

class БухСчет
{
  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
  {
    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
  }
}

Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.

V>Какое мне дело, что именно тебя не интересует?
если нет дела, то пиши, пиши. А я буду скипать, скипать. Только без обид.

S>>Еще раз. Речь идет об ветвлении исполнения стейтментов,

V>Речь идёт о ветвлении как таковом. Остальное — твои личные фантазии и неуклюжие попытки ограничить меня уютными тебе рамками.
Давай заглянем в http://en.wikipedia.org/wiki/Structured_program_theorem
там написано очень конкретно что требуется не ветвление, а выполнение.

 In other words, any algorithm can be expressed using only three control structures. They are

1    Executing one subprogram, and then another subprogram (sequence)
2    Executing one of two subprograms according to the value of a boolean expression (selection)
3    Executing a subprogram until a boolean expression is true (iteration)

видишь ли, под пунктом 2 управляющая структура, которая выполняет подпрограммы. хаскель-if их не выполняет, а лишь выбирает ветку. У нас есть гарантия что выбранная ветка будет вычислена хоть когда-нибудь?

По другим пунктам тоже можно поглядеть.
1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается. А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.

3. Выполнение подпрограммы пока ...уже бессмыслица в хаскеле, т.к. подпрограмма это выражение, которое сколько не выполняй, результат будет тот же самый ... пока булево выражение является true — тоже бессмысленно, т.к. в хаскеле выражение чему равно, тому и равно, сколько его не вычисляй, и выполнение подпрограммы на результат выражения не влияет.

В итоге, все 3 пункта не о хаскеле.

S>>В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.

V>Я про возможность применения его в IO без каких-либо доработок вроде бы сказал сразу, не? Тебе это сколько еще повторять? Побочный эффект возникает ПОСЛЕ применения if, ес-но, как результат выполнения хвоста в цепочке IO-вычислений.
Так это побочный эффект не от if-а, конечно же. Это побочный эффект от выполнения действия, вернувшегося в качестве результата вычисления ветки. Если внимательно, то if тебе вернул ветку, результатом которой когда-то будет являться действие. Так вот, когда это действие получит мир, оно его испортит. Только причем тут if?

Да и что ты носишься с этим IO? Побочные эффекты на вычислимость функций не влияют и для вычислений не требуются.

V>Ес-но не в момент вычисления предиката при if, а в момент прохождения потока вычисления только по одной из двух веток, описанных в исходнике.
Еще раз. В момент прохождения потока вычисления по ветке мы получим лишь IO a, которое само по себе чисто. А грязь будет только когда мы IO a скормим мир.

V>Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?
выше две мысли. Одна — if не выполняет ветки, вторая — (*)побочные эффекты не влияют на вычислимость функций, о которой писали авторы теоремы.

Если ты хочешь притянуть за уши ФП к СП, то тебе придется обойтись без IO. Потому что (*). А так же потому что имея IO, мы можем на ФП спародировать любую императивную программу. Но ведь ФП Тьюринг-полна вовсе не потому что IO, так ведь?

Здравствуйте, grosborn, Вы писали:

>>>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
>>
>> G>Это общий механизм мышления.
>>
>> Это общий механизм воссоздания образов, то есть воображения. Назвать это мышлением слишком сильно, нужно какое то подтверждение.

G>Вы оба почему-то думаете, что образное мышление и логическое это разные вещи, разные механизмы. Открою вам маленький не секрет — высшее логическое мышление это и есть образное.

Пруф.

>Физический механизм один и тот же. Нет у человека в голове специальной шишки мозга производящей числовые вычисления. Хотя некоторые структуры мозга бывают специализированными, но вот логической нет. Подтверждение? Легко. Вспомни как ты учил таблицу умножения. 2+2=4, 12^2=144 — ассоциативная выборка из памяти результата. Вот тебе и "высшая нервная деятельность" или "абстрактное мышление".

Это просто память а не абстрактное мышление. Абстрактное это возмжность представлять одно и то же разными способами.

>То есть условно говоря, считаем деньги мы почти тем же местом, что и смотрим кино. В отдельной шишке не было необходимости, мы еще в позапрошлом веке все поголовно неграмотные были и считать почти не умели, все по памяти.

А тесты показывают, что кровоток в мозгу выглядит совершенно по разному.

>> Даже образное мышление трудно назвать набором образов, а есть еще понятийное, сиречь абстрактное мышление.

G>Понятийное мышление это полный синоним образного. Просто сложное понятие состоит из множества образов и связей.

Нет, это дихотомия.

>> Не совсем ясно откуда следует что какой то снимок накладывается на предыдущий ? Это имеется ввиду какая то конкретная модель мышления ? Честно, в книгах по когнитивной психологии такого не встречал.

G>Скорее всего встречал, но в других формулировках или проявлениях. Не накладывается на предыдущий, а правильнее сказать образы интерферируют друг с другом. В силу разных вещей — мощность структур выборки образов меньше мощности всей памяти, место проявления образа задано физической структурой нейронов и плюс еще сам механизм ассоциативных связей дает эффект.

До свидания.

AVK>Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?

ты мне сейчас рассказываешь про SRP. SRP никакого отношения к объектной оболочке отношения не имеет, а имеет отношение лишь к процессу хранения состояния.

SRP никак не мешает иметь два метода, которые делают похожую работу:

class БухСчет
{
  public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
  {
    return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
  }
  public Tx[] ОплатитьИз(БухСчет source, Товарный_Чек чек)
  {
    return DocTxService.MakeDocTx(CreateDocument(source, this, чек));
  }
}

и соответственно, обе следующие операции равноправны:
[c#]
Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));

//или

Основные_Фонды.Оплатить_Из(Нал, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));

Здравствуйте, DarkGray, Вы писали:

DG>Весь gui сейчас строится по ООП-метафоре: либо простой — объект + действия, либо сложной — объект + палитра инструментов.

Здорово. Осталось понять, какая связь с объектом Счет.

DG>1. упрощается тестирование и сопровождение. Можно отдельно простыми unit-тестами проверить правильность объектной оболочки, и потом для Gui-я лишь проверить, что соответствующая кнопка вызывает соответствующий метод
DG>2. api скриптов и командой строки соответствует действиям GUI-я 1 к 1

Я рядом ссылочку на скринкаст привел. Жду конкретики.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

I>

I>Mod modifier = GetSalt();
I>Ctx ctx = GetContext();

I>Order(x => modifier[ctx].Apply(x))
I>

I>Покажи такой же фокус, что бы все было так же прозрачно.

Ничего прозрачного я не вижу. Что возвращает modifier[ctx]?

I>>>Кроме того, в твоем примере все точно так же упирается в имена функций при том что один из методов, там где ExtractABC хуже некуда.

V>>Ниче не понял, перефразируй, плиз.

I>В моем примере лямбды дают инверсию и прозрачность, нет нужны ковырять внутренности. В твоем ничего этого нет, можно догадываться только исходя из имен методов.

Дык и у тебя без именнованного метода было бы не понятно, с какой целью надо было извлечь поле ABC из x.

I>>>В моем случае все это по месту вызова.
V>>Тю блин, в твоем случае была одна полезная строчка. В случае же тысяч полезных строчек, удачно подобранные имена идентификаторов становятся всё более востребованными, не находишь? ))

I>Лямбды избавлдяют от нехобходимости проектировать структуры данных и сигнатуры для взаимодействия, тупо берешь локальный контекст и используешь. Изменился контекст — не надо ничего менять снаружи.

Гы-гы... в паскалеподобных языках есть локальные процедуры в процедурах и т.д. рекурсивно. Причем, локальным процедурам доступен контекст вышестоящих процедур. В итоге — такое же точно замыкание безо-всяких лямбд.

I>В твоем случае надо перепахивать все подряд,ибо надо проектировать и структуры данных и сигнатуры.

Структуры данных в любом случае проектировать надо. Подозреваю, что ты таки имел ввиду локальность видимости? Но в С++ я могу эти структуры или объекты с методами проектировать внутри других методов для решения локальных задач:

void Method() {
  Obj1 x;
  vector<Obj2> vec;
  
  struct : Base {
    Obj * x;
    void operator()(Obj2 y) { x->do(y); }
  } lambda = { &x };

  foreach(vec, lambda);
}

Пример просится на частичное применение через boost:bind без дополнительных локальных структур:

void Method() {
  Obj1 x;
  vector<Obj2> vec;

  foreach(vec, bind(&Obj1::do, x, _1));
}

Но будем считать, что в сложном случае частичным применением не отделаешься, поэтому первый вариант безымянных объектов в помощь.

В общем, свои наработки для локализации видимости элементов программы есть во многих языках. В Джава для этого есть анонимные объекты, в которых ты можешь переопределять виртуальные методы, захватывать контекст и т.д. и всё это в рамках всего одной операции SomeObject obj = new SomeObject() { /* расширение объекта */};

То бишь, лямбда, как элемент лямбда исчисления, — это уникальный момент, а как элемент локализации видимости кода — ни разу не новость.

V>>Так видел или не видел? http://cplus.about.com/od/learningc/ss/pointers2_8.htm
V>> Там же такое же точно IoC в полный рост. И это императив из махровых 70-х. А при вызове мы совершаем над qsort то самое DI, подавая адрес ф-ии-компаратора.

I>Там нет никакого IoC.

Я тебе показал IoC в qsort прямо по определению IoC.

I>не веришь — покажи аналог для моего кода выше.

Конечно не верю. Никакой другой пример не отменяет дизайна qsort. Для твоего кода тоже покажу, ес-но, только ответь там на вопрос.

I>То есть, все атки ФП ? Опаньки ! А надо было показать разницу между функционально и процедурной.

Кто здесь?
)))
Я и показал в процедурном стиле... пытаюсь сфокусировать тебя, что это тоже самое, что на функциональном подходе. Это не оппаньки, это и есть цель, см. историю этой ветки.

ИМХО, замыкания и ФВП отличаются от рукопашного процедурного кода лишь тем, что сами протягивают свой контекст за собой, а в процедурном мире этот контекст приходится протягивать ручками через доп. аргументы. Но если ты понимаешь, как работает ФП, ничто не мешает воспроизвести аналог в любой технике. Особенно легко это в ООП+GC. Собсно, ты это в примерах и показываешь на анонимных делегатах дотнета. ))

Здравствуйте, grosborn, Вы писали:

>> Математика — это инструмент для описания закономерностей мира.

G>То есть инструмент, не модель.

Модель — тоже инструмент. Математика описывает модели. Прикладные разделы математики — это и есть модели, опирающиеся на более атомарные разделы математики (описываемые с помощью них).

G>И не является частью модели.

С ума сошел? Модель всегда работает по неким законам.

G>В программировании инструментальных средств — внезапно! — большая часть.

По русски можно?

Здравствуйте, Ikemefula, Вы писали:

V>>Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки.
I>

Для для чего инстанцировать на момент попадания в очередь, если обработка будет после выхода из неё ?

На выходе точный таймер, собственно, тебе длина очереди дана чтобы сгладить все эффекты с быстродействием, то бишь дать некую фору во времени. Да и с чего ты решил, что накапливать нейтивную память дешевле, чем объекты из пула? Однофигственно.

>>Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.

I>У меня в тесте тоже нет нулевого поколения. Так ты выдашь внятный тест или будешь и дальше сочинять ?

Я тебе уже сказал, что тебе надо делать.

V>>Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )
I>У меня стиль простой — пока ты не выложишь внятную модель или жосткие данные я ничего выкладывать от себя не собираюсь.

ЧТД. Демонстрировать серьезность намерений — это не твой стиль. Приятно было поболтать ни о чем.

Здравствуйте, Ikemefula, Вы писали:

I>Если ты внимательно читал,то у меня самая плохая реализация выдаёт в 10 раз больше того, чем тебе хочется.

Сравнение на разной технике может показать что угодно.
Современная итак в 10 раз быстрее той, итого, ты сожрал на бесполезном GC все выч ресурсы той техники. Работать программе некогда. Поздравляю.

>>Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.

I>Зачем заранее создавать и хранить пустой список полей ?

Потому что с пустым списком идут большинство полей, вестимо.

I>Это по требованию нужно делать. О чем я тебе и говорю уже в который раз.

Этот детсад хорошо смотрится для одноразовых вычислений, а не для поточной обработки с объектами из пула.

V>>Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.

I>Нет, все быстродействие съедает неэффективная очередь, а не GC. Профайлер показывает что издержки на GC ничтожные.

Что ты мне неткаешь, если твои 10 раз отожрали весь выч.ресурс тех машин? Кароч, не компосируй мне процессор. Пример нетривиальный, с 0-ля делать ради тебя не буду. Ты говоришь у тебя что-то уже есть — дык давай. Я все-равно минимум вдвое твой пример ускорю сугубо за счет уже описанных словами техник. Более того, пытливый ум может интересовать исключительно сравнительные цифры на одной и той же технике, а не абсолютные на разных. Смысл выкатить только один мой пример? А может ты банально испугался?

Здравствуйте, AndrewVK, Вы писали:

http://www.rsdn.ru/forum/philosophy/4838064.1.aspx

Смотри какое дальше идет бурление овн. ))

AVK>Я рядом ссылочку на скринкаст привел. Жду конкретики.

Вообще, пример ужасный. При таком ведении бухучета, я не вижу как можно будет проводить вменяемый фин. анализ для данной компании.

>>> Математика — это инструмент для описания закономерностей мира.

> G>То есть инструмент, не модель.
>
> Модель — тоже инструмент. Математика описывает модели. Прикладные разделы математики — это и есть модели, опирающиеся на более атомарные разделы математики (описываемые с помощью них).

В твоем представлении что-нибудь кроме моделей существует? Или в твоем представлении мы все созерцательные кони в вакууме? Что, никак-никаких-совсем никаких средств воздействия на окружающий мир? Совсем никаких новых сущностей, только отражение "реального мира"?

> G>И не является частью модели.
>
> С ума сошел? Модель всегда работает по неким законам.

Ну по крайней мере я умею разделять модели и понятия, отделяю инструментальные средства от объектов их применения. А ты этого не можешь. Так что кто тут сошел с ума это пока вопрос.

> По русски можно?

По русски тут будет три буквы.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, AndrewVK, Вы писали:

AVK>Вы говорите о разных вещах. Синклер о бухгалтерском счете, ты о банковском.
Да, совершенно верно. Ок, банковский счёт можно рассматривать как объект — в некоторых изолированных сценариях.
Вопрос о том, в каких именно, и насколько это будет уместно, я пока опущу.

Здравствуйте, vdimas, Вы писали:

I>>

I>>Mod modifier = GetSalt();
I>>Ctx ctx = GetContext();

I>>Order(x => modifier[ctx].Apply(x))
I>>

I>>Покажи такой же фокус, что бы все было так же прозрачно.

V>Ничего прозрачного я не вижу. Что возвращает modifier[ctx]?

В каждом контексте сортировки работают чуток по разному, хотя алгоритм один и тот же. Сортировать нужно по значению, которое складывается из полей объекта и значений в некотором контексте.
Ты заметил, что ключевой вопрос у тебя появился сразу, без заглядывания в соседние модули, файлы, проекты ?

I>>В моем примере лямбды дают инверсию и прозрачность, нет нужны ковырять внутренности. В твоем ничего этого нет, можно догадываться только исходя из имен методов.

V>Дык и у тебя без именнованного метода было бы не понятно, с какой целью надо было извлечь поле ABC из x.

Сортировка по конкретному колумну для тебя новость ? В твоем случае ты даже не узнаешь, по чем сортирует вообще, придется раздранонить все подряд.

I>>Лямбды избавлдяют от нехобходимости проектировать структуры данных и сигнатуры для взаимодействия, тупо берешь локальный контекст и используешь. Изменился контекст — не надо ничего менять снаружи.
V>Гы-гы... в паскалеподобных языках есть локальные процедуры в процедурах и т.д. рекурсивно. Причем, локальным процедурам доступен контекст вышестоящих процедур. В итоге — такое же точно замыкание безо-всяких лямбд.

Покажи хороший пример вроде того, что я показал.

"реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции" — собтсенно это ты и не можешь показать.

V>Структуры данных в любом случае проектировать надо.

Нет, не надо. Замыкания решают этот вопрос на 100%

>Подозреваю, что ты таки имел ввиду локальность видимости? Но в С++ я могу эти структуры или объекты с методами проектировать внутри других методов для решения локальных задач:

V>

V>void Method() {
V>  Obj1 x;
V>  vector<Obj2> vec;
  
V>  struct : Base {
V>    Obj * x;
V>    void operator()(Obj2 y) { x->do(y); }
V>  } lambda = { &x };

V>  foreach(vec, lambda);
V>}
V>

Ну и снова ты отошел от структурного программирования. Покажи внятный аналог моего кода.

V>Пример просится на частичное применение через boost:bind без дополнительных локальных структур:
V>

V>void Method() {
V>  Obj1 x;
V>  vector<Obj2> vec;

V>  foreach(vec, bind(&Obj1::do, x, _1));
V>}
V>

V>Но будем считать, что в сложном случае частичным применением не отделаешься, поэтому первый вариант безымянных объектов в помощь.

Покажи внятный аналог моего кода.

V>В общем, свои наработки для локализации видимости элементов программы есть во многих языках. В Джава для этого есть анонимные объекты, в которых ты можешь переопределять виртуальные методы, захватывать контекст и т.д. и всё это в рамках всего одной операции SomeObject obj = new SomeObject() { /* расширение объекта */};

Покажи внятный аналог моего кода и не соскакивай со стурктурного .

V>То бишь, лямбда, как элемент лямбда исчисления, — это уникальный момент, а как элемент локализации видимости кода — ни разу не новость.

А про новости никто и не говорил, важно что это новые возможности для дизайна которых в структурном и близко нет. Даже в ООП и то нет.

I>>Там нет никакого IoC.

V>Я тебе показал IoC в qsort прямо по определению IoC.

Покажи общий случай IoC а не вырожденый, мой пример выше.

I>>не веришь — покажи аналог для моего кода выше.
V>Конечно не верю. Никакой другой пример не отменяет дизайна qsort. Для твоего кода тоже покажу, ес-но, только ответь там на вопрос.

Покажи внятный аналог моего кода.

V>Я и показал в процедурном стиле... пытаюсь сфокусировать тебя, что это тоже самое, что на функциональном подходе. Это не оппаньки, это и есть цель, см. историю этой ветки.

Ты вообще то говорил что "реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"
Собтсенно это ты и не можешь показать.

V>ИМХО, замыкания и ФВП отличаются от рукопашного процедурного кода лишь тем, что сами протягивают свой контекст за собой, а в процедурном мире этот контекст приходится протягивать ручками через доп. аргументы. Но если ты понимаешь, как работает ФП, ничто не мешает воспроизвести аналог в любой технике. Особенно легко это в ООП+GC. Собсно, ты это в примерах и показываешь на анонимных делегатах дотнета. ))

Не надо врать. "реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"
В другой технике у тебя просто нет аналога, потому что
1. связывание придется делать вручную
2. управлять контекстом придется вручную
3. проектировать структуры данных для взаимодейтсвия придется вручную

Здравствуйте, DarkGray, Вы писали:

DG>тут, вообще, достаточно (если, конечно, цель — дружественная система, а не сделай всё сам):
DG>

DG>ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5);
DG>

А ничего что таких целей 100500 может быть? Будем на каждую по методу заводить?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, DarkGray, Вы писали:

AVK>>Я рядом ссылочку на скринкаст привел. Жду конкретики.

DG>Вообще, пример ужасный.

Пример реальный.

DG> При таком ведении бухучета, я не вижу как можно будет проводить вменяемый фин. анализ для данной компании.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты его недостаточно любишь

AVK>

AVK>public static class NotNullUtils {
AVK>    public static IList<T> AsNotNull<T>(this IList<T> list) {
AVK>        return list ?? EmptyArray<T>.Value;
AVK>    }
AVK>

Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

S>Для ГУЯ сейчас актуально использовать какую-нибудь разновидность MVP.
S>Presenter — это как раз тот объект, который выполняет посредническую роль между Domain Model и представлением; он сам не соответствует ничему в предметной области.

При этом остается основной вопрос, а как организована Model?
Я утверждаю, что она должна быть организована в виде объектной оболочки к атомарному api.

S>Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.

ужасное утверждение, т.к. используется неопределяемое понятие "внутренняя модель".

Для меня как раз пример из ролика AndrewVK показывает, что в gui-е тупо показывается сущности внутренней модели (сущности атомарного api), например, даже никто не озаботился, чтобы число 20тыс. р не надо было вводить два раза, не говоря уже про какие-то более удобные вещи.

S>Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.

Так объектная оболочка как раз и спроектирована от сценариев пользователей.

Если я руководитель небольшой ООО компании, то я:
— хочу выдавать распоряжения без всякой прослойки в виде бухгалтера (который лишь жрет мою прибыль),
— хочу чтобы система мне на основе бух. данных строила полноценных фин. анализ,
— хочу видеть Иванов.Выдать_Зарплату,
— хочу чтобы все КГОСУ проставлялись автоматически на основе лучших рекомендаций бух. консультантов по оптимизации налогооблажения,
— хочу видеть следующий сценарий использования бух. системы:
— подписался на пакет рекомендаций от консультанта бух. учета,
— вводишь Иванов.Выдать_Зарплату,
— бух. система сама проставляет все бюджетные коды на основе скаченного пакета рекомендаций.

DG>>тут, вообще, достаточно (если, конечно, цель — дружественная система, а не сделай всё сам):
DG>>

DG>>ООО_Маша_И_Сыновья.Иванов_А_К.Выдать_Зарплату(20000, 2012, 5);
DG>>

AVK>А ничего что таких целей 100500 может быть? Будем на каждую по методу заводить?

так вроде программистам платят за то, чтобы как раз использование всех этих 100500 целей они сделали удобными, а не для того, чтобы они баклуши били.

Здравствуйте, DarkGray, Вы писали:

AVK>>А ничего что таких целей 100500 может быть? Будем на каждую по методу заводить?

DG>так вроде программистам платят за то, чтобы как раз использование всех этих 100500 целей они сделали удобными, а не для того, чтобы они баклуши били.

Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Пример реальный.

в реальном качественном примере должно быть:


ООО_Маша_и_Сыновья.Иванов_А_К.Начислить_Зарплату(2012, май, Трудовой_Договор.37, 15отработанных-дней, 5больничных);
ООО_Маша_и_Сыновья.Иванов_А_А.Покрыть_Долг(20000, From: Источник_обеспечения.Бюджет);

иначе не очень понятно на основе чего Иванову были выданы деньги.

DG>> При таком ведении бухучета, я не вижу как можно будет проводить вменяемый фин. анализ для данной компании.

AVK>

Видишь ли, никому не интересен гипотетический и не существующий в природе идеальный бухучет. Есть законодательство, которое довольно жестко регламентирует, что и как, и никто в нашей стране от него не освобожден.

проблема в том, что ты берешь только одну задачу:
— ведение бух. учета для того, чтобы отчитаться перед бюджетными органами

и выкидываешь все остальные задачи, которые ставятся перед бух. учетом:
— обеспечение учета в рамках договорных отношений(если Иванов будет говорить, что ему не доплатили за работу на основе имеющихся у него трудового договора и приказов о поощрении, то именно бух. система должна уметь грамотно построить баланс между всеми выплатами Иванова и имеющимися документами: трудовой договор, приказы о поощрении, табель посещаемости, отчеты с командировок и т.д.)
— фин. анализ

поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный (это лишь говорит об ужасной безграмотности в области фин. менеджмента ваших заказчиков), т.к. обе указанные задачи на основе строки "выдать Иванову 20000 за май в качестве зарплаты" не решишь.

AVK>>

AVK>>public static class NotNullUtils {
AVK>>    public static IList<T> AsNotNull<T>(this IList<T> list) {
AVK>>        return list ?? EmptyArray<T>.Value;
AVK>>    }
AVK>>

I>Вот эта оптимизация, в каких реальных сценариях она тебе понадобилась ? Какой был профит ?

для развесистого объектного дерева в котором пустой список — это норма, может дать экономию памяти в размере 5-15%, и ускорение работы gc процентов на 20-30

Здравствуйте, AndrewVK, Вы писали:

ВВ>>Ну да, для того, чтобы рассуждать о парадигмах, разбираться в них совершенно необязательно.
AVK>Опять грубая подтасовка. То, что я не хочу выискивать абстрактную чистоту принципов, вовсе не означает, чтьо я не разбираюсь в парадигмах. Я так понимаю, конструктивный разговор закончился.

Я не хотел тебе отвечать, но все-таки отвечу.
Я тебя не обвинял в том, что ты не разбираешься в парадигмах; мне жаль, что ты понял эту фразу именно так, в ней перехода на личности не было. Но мне показался странным твой неожиданный отказ обсуждать теоретическую часть, т.к. к практике мы все же приходим через теорию. И да, вопрос "какая мне от этого польза на практике" должен быть неким итоговым вопросом, который должен быть задан, когда все понятия будут окончательно определены, и все собеседники с ними согласятся.

Какой смысл, скажем, рассуждать об ФП на практике, когда каждый вкладывает в это понятие что-то свое, причем с остальными принципиально не согласен? Данный тред явно показывает, что по крайней мере ФП мы уж точно понимаем по-разному.

ВВ>>Просто забавно, было наблюдать, как ты весьма охотно со мной спорил о чистоте концепций
AVK>Тебе показалось.
ВВ>>Вообще уровень дискуссии очень характерно развивается — посчитай, сколько раз в твоем сообщении слово "жопа" встречается.
AVK>Ты бы вместо жоп посчитал количество подтасовок в своих сообщениях.

В моих сообщениях не было подтасовок; тебе показалось. Если какая-то твоя мысль была неправильно понята, то вместо того, чтобы обвинять других в подтасовках, проще переформулировать, чем обвинять других в подтасовках.

As of now, мне, например, непонятна большая часть того, что ты писал в этом треде. К чему, например, ты писал о "костылях" в ФП?

Чтобы показать, что даже такие базовые вещи как АлгТД вносят в ФП нечистоту концепции? Как оказалось, нет.
Чтобы показать, что ФП изначально не предоставляет нужных абстракций? Опять же нет.

Ты можешь сейчас сказать, какие именно твои мысли были "подтасованы" и как их следовало понимать?

AVK>Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

Если это сделано грамотно, то бух. учет из обузы (и расходной статьи) превращается в доходный инструмент финансового управления.
О чем и рассказывают в любом курсе финансового менеджмента, но насколько я понял — забыли об этом рассказать программистам бух. систем.

Здравствуйте, DarkGray, Вы писали:

DG>в реальном качественном примере должно быть:
DG>


DG>ООО_Маша_и_Сыновья.Иванов_А_К.Начислить_Зарплату(2012, май, Трудовой_Договор.37, 15отработанных-дней, 5больничных);
DG>ООО_Маша_и_Сыновья.Иванов_А_А.Покрыть_Долг(20000, From: Источник_обеспечения.Бюджет);
DG>

DG>иначе не очень понятно на основе чего Иванову были выданы деньги.

Что то я окончательно перестал тебя понимать. Ты предлагаешь отказаться от статической типизации или завести на каждого Иванова отдельное свойство в объекте предприятия?

AVK>>

Видишь ли, никому не интересен гипотетический и не существующий в природе идеальный бухучет. Есть законодательство, которое довольно жестко регламентирует, что и как, и никто в нашей стране от него не освобожден.

DG>проблема в том, что ты берешь только одну задачу:
DG>- ведение бух. учета для того, чтобы отчитаться перед бюджетными органами

Это не я беру, это клиенты мне за это платят. А за сферическую бухгалтерию в вакууме нифига не платят.

DG>- обеспечение учета в рамках договорных отношений(если Иванов будет говорить, что ему не доплатили за работу на основе имеющихся у него трудового договора и приказов о поощрении, то именно бух. система должна уметь грамотно построить баланс между всеми выплатами Иванова и имеющимися документами: трудовой договор, приказы о поощрении, табель посещаемости, отчеты с командировок и т.д.)

Это все, как несложно догадаться, тоже есть. Но я так и не получил от тебя ответов на кучу заданных вопросов. Я правильно понимаю, что для ввода первички и формирования хозопераций объект Счет все таки не нужен?

DG>поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный

Приведи другой реальный, но не ужасный.

DG> (это лишь говорит об ужасной безграмотности в области фин. менеджмента ваших заказчиков)

Давай мы не будем обсуждать чью либо безграмотность, ок?

DG>, т.к. обе указанные задачи на основе строки "выдать Иванову 20000 за май в качестве зарплаты" не решишь.

Я не знаю что ты так уцепился за финансовый менеджмент и анализ, но на практике с ним тоже никаких проблем нет.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, DarkGray, Вы писали:

AVK>>Интересный подход. Т.е. программисты должны наплодить кучу никому не нужных методов, потратить массу времени на это, а конечному пользователю в итоге ни холодно ни жарко?

DG>Если это сделано грамотно

Опять общие слова. Ты мне покажи как грамотно и почему. Пока что все твои примеры только приводят к распуханию и усложнению кода.

DG>О чем и рассказывают в любом курсе финансового менеджмента, но насколько я понял — забыли об этом рассказать программистам бух. систем.

То есть ты знаешь, как надо, но объяснить почему не можешь? Но сама идея того, что курс финансового менеджмента должен повлиять на микродизайн программного продукта, это довольно необычно, скажем так.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

AVK>Опять общие слова. Ты мне покажи как грамотно и почему. Пока что все твои примеры только приводят к распуханию и усложнению кода.

основу я уже сказал.
Поверх атомарного api наворачивается несколько уровней объектной оболочки, которые приближают объектную модель программы к понятийной модели пользователя, позволяя ему единообразным способом работать — с GUI, CLI и скриптами, а также разгововарить на едином языке с программистами при постановке задач по разработке.
В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат. На практике — смешивается автоматическое построение объектной оболочки с ручным заданием.

Из твоих слов следует, что для тебя таких задач не существует, и для тебя это всего лишь разбухание кода.

И соответственно тогда основной вопрос: как я могу тебе показать, что эти задачи есть, важны, и нужны?

Здравствуйте, DarkGray, Вы писали:

DG>основу я уже сказал.

Лично у меня только больше вопросов появилось и ни одного ответа. Ты прямые вопросы пропускаешь, и вместо этого переключаешься на что то еще. А в последних сообщениях так и вовсе решил обсудить мою, Синклера и моих заказчиков квалификацию.

DG>Поверх атомарного api

Что такое атомарный api и как он должен выглядеть?

DG> наворачивается несколько уровней объектной оболочки, которые приближают объектную модель программы к понятийной модели пользователя

Зачем? И с какой стати ты решил, что в понятийной модели пользователя хозоперация является частью кредитного счета?

DG>, позволяя ему единообразным способом работать — с GUI, CLI

Что такое CLI?

DG> и скриптами

Пользователю со скриптами? Ты ничего не перепутал?

DG>, а также разгововарить на едином языке с программистами при постановке задач по разработке.

Пользователю разговаривать напрямую с программистами? Все страньше и страньше.

DG>В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат.

Ух ты. Автоматически на основании чего? И зачем какая то оболочка, не привносящая в систему новой информации?

DG> На практике — смешивается автоматическое построение объектной оболочки с ручным заданием.

Продемонстрируй. Пока что я вижу только лозунги, что все круто и никакой конкретики.

DG>Из твоих слов следует, что для тебя таких задач не существует

Каких таких?

DG>, и для тебя это всего лишь разбухание кода.

Для меня разбухание кода это создание методов для операций, не фигурирующих ни в одном юзкейсе. Напоминаю, что на вопрос о том, в каком юзкейсе понадобилась связь от объекта Счет к хозоперации, в которой этот счет фигурирует как кредитный, ты нее ответил.
Во избежание дальнейших инсинуаций, люди, которые проектировали показанную мной бухгалтерию, занимаются непосредственно этим больше 10 лет, и лично мне до их квалификации в этой области довольно далеко, как, думаю, и тебе тоже. Поэтому обсуждать сам подход, как, куда и что вводить, неконструктивно. А вот обсудить программный дизайн кода для реализации этого вполне можно.

DG>И соответственно тогда основной вопрос: как я могу тебе показать, что эти задачи есть, важны, и нужны?

Начни с описания одной подобной задачи. Реальной, а не "сижу, ~~примус починяю~~чеки разбираю". Потому что если реальной задачи нет — все это превращается в очередной бредогенератор типа ветки про открывание двери.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Ikemefula, Вы писали:

I>В каждом контексте сортировки работают чуток по разному, хотя алгоритм один и тот же. Сортировать нужно по значению, которое складывается из полей объекта и значений в некотором контексте.
I>Ты заметил, что ключевой вопрос у тебя появился сразу, без заглядывания в соседние модули, файлы, проекты ?

Ты не ответил ни здесь, ни на пред топик. Где сама-то сортируемая коллекция?

Где аннотации как минимум еще двух типов?
Ну и каша...

А вопрос был ключевой лишь потому, что речь идет о статически-типизированном языке, то бишь, что бы не возвращал modifier[ctx] (скажем, SortModifier), и что бы не возвращаел затем Apply(x), — независимо от исходного модификатора это будет значение одного и того же типа. А я не вижу аннотаций в примере.

Итого, в твоем примере я даже не вижу по какому критерию происходит сортировка. Полный мрак и непонятки. Вот причина "ключевых вопросов" — из-за нечитабельности кода.

Ну ок, буду разгребать твою кашу.

Помнишь, я писал тебе тебе, что есть замыкание? Вот часть инфраструктуры вне примера:

// лямбда
template<typename F, typename C>
struct Fn { F f; C c; };

// хелпер создания
template<typename F, typename C>
Fn make_fn(F f, C c) {...}

// хелперы использования

template<typename R, typename A, typename Fn>
Ret call(Fn f, A * a) {
  return fn.f(c, a);
}

template<typename R, typename A1, typename A2, typename Fn>
Ret call(Fn f, A1 * a1, A2 * a2) {
  return fn.f(c, a1, a2);
}  
...

Имеем некую обобщенную процедуру сортировки (показываю ключевые моменты):

template<typename Fn>
inline void qsort(CollectionOfX * collection, Fn f) {
  // blah-blah
  int compareRеsult = call<int>(f, x1, x2);
  
  switch(compareRеsult) {
    // blah-blah
  }
}

Далее, я из головы дополню отсутствующие нотации типов в твоем примере.

struct SaltedModifier;  // это то, что возвращается выражением modifier[ctx]
struct ModifiedX;       // это то, что подлежит сравнению

// исходная ф-ия - компаратор, подразумеваемая в твоем примере
int CompareByModifiedX(ModifiedX * a, ModifiedX * b);

А теперь само решение. Смотрим на твой код и отделяем мух от котлет, то бишь свободные переменные от связанных в замыкании:

int CompareUsingModifier(SaltedModifier * sm, X * a, X * b) {
  return CompareByModifiedX(sm->Apply(a), sm->Apply(b));
}

Mod modifier = GetSalt();
Ctx ctx = GetContext();
SaltedModifier sm = modifier[ctx];

qsort(collectionOfX, make_fn(CompareUsingModifier, &sm));

I>Покажи хороший пример вроде того, что я показал.

Ты показал плохой пример. Ничего не понятно. В отличие от моего конечного варианта, который отличается одной доп. ф-ей CompareUsingModifier.

V>>Структуры данных в любом случае проектировать надо.
I>Нет, не надо. Замыкания решают этот вопрос на 100%

Они их решают только если вообще весь код написан в CPS, а вообще весь код не пишут в CPS даже в самом махровом ФП. Бо фиксировать упорядоченные наборы простых типов в составные структуры банально удобно для понимания человеком происходящего. К тому же, номативная система строгой типизации позволяет отделять одни похожие наборы данных от других, помогая нам блюсти исходную семантику задачи, то бишь оберегая нас от случайных ошибок. Ты же предлагаешь игнорировать инструмент системы типов.

>>Подозреваю, что ты таки имел ввиду локальность видимости? Но в С++ я могу эти структуры или объекты с методами проектировать внутри других методов для решения локальных задач:

V>>

V>>void Method() {
V>>  Obj1 x;
V>>  vector<Obj2> vec;
  
V>>  struct : Base {
V>>    Obj * x;
V>>    void operator()(Obj2 y) { x->do(y); }
V>>  } lambda = { &x };

V>>  foreach(vec, lambda);
V>>}
V>>

I>Ну и снова ты отошел от структурного программирования.

А в какую сторону я отошел-то? Тебя идентификатор lambda смутил? А если бы я назвад его object?
Например, куда здесь отошла ф-ия драйвера, которой сам драйвер подается как контекст?

void ioctl(IODriver * driver, int param, void * arg);

В какую сторону ты видишь тут "отход от структурного программирования" (С)? В ФП или ООП?

Заметь, отход-то равнозначный... что как бэ намекает на истоки озвученного мною мнения. Я ведь не с потолка утверждение сделал, а после изготовления пары интерпретаторов ф-х языков.

V>>В общем, свои наработки для локализации видимости элементов программы есть во многих языках. В Джава для этого есть анонимные объекты, в которых ты можешь переопределять виртуальные методы, захватывать контекст и т.д. и всё это в рамках всего одной операции SomeObject obj = new SomeObject() { /* расширение объекта */};

I>Покажи внятный аналог моего кода и не соскакивай со стурктурного .

Т.е. тебе опять нечего ответить? ЧТД.

I>>>Там нет никакого IoC.
V>>Я тебе показал IoC в qsort прямо по определению IoC.

I>Покажи общий случай IoC а не вырожденый, мой пример выше.

Общий случай в qsort и есть. Похоже, ты не понимаешь, где в твоем собственном примере IoC, а где ФП. См внимательно мой вариант твоего примера.

V>>Я и показал в процедурном стиле... пытаюсь сфокусировать тебя, что это тоже самое, что на функциональном подходе. Это не оппаньки, это и есть цель, см. историю этой ветки.

I>Ты вообще то говорил что "реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"
I>Собтсенно это ты и не можешь показать.

О, уже пошел разговор сам с собой. ))

V>>ИМХО, замыкания и ФВП отличаются от рукопашного процедурного кода лишь тем, что сами протягивают свой контекст за собой, а в процедурном мире этот контекст приходится протягивать ручками через доп. аргументы. Но если ты понимаешь, как работает ФП, ничто не мешает воспроизвести аналог в любой технике. Особенно легко это в ООП+GC. Собсно, ты это в примерах и показываешь на анонимных делегатах дотнета. ))

I>Не надо врать.

Т.е. ты не понял, что я только что написал? ЧТД.

I>"реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"

Именно, твой пример — тому пример. Твоего замыкание в дизайне не видно. А вот упущенные в примере аннотации типов и сам Order — они видны в полный рост. Просто их скромно прячешь, превращая свой пример в кашу.

I>В другой технике у тебя просто нет аналога, потому что
I>1. связывание придется делать вручную

Да похрен, это глубокие подробности кода, которые из дизайна не торчат ни разу. Абсолютно ничего не изменилось от того, что я прилепил локальную ф-ию CompareUsingModifier. Ну разве что сэкономил тебе немного на исходнике и осводил тебя от надобности писать комменты из-за самодокументирумости моего варианта.

I>2. управлять контекстом придется вручную

Ну да. Подавать "контекст" придется вручную. Более того, у контекста теперь появится... оп-па! Экземпляр!

I>3. проектировать структуры данных для взаимодейтсвия придется вручную

Структура данных нужна будет для отображения контекста, а не дляя взаимодействия. Например в ООП, объект — это контекст самому себе. Так же смотри мой пример с IODriver. Я бы не сказал, что выделение контекста в отдельный тип IODriver такая уж плохая идея...

============================
Кстати, у тебя, походу, проблемы с оперативной памятью:
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.
I>Покажи внятный аналог моего кода.

Здравствуйте, DarkGray, Вы писали:

DG>При этом остается основной вопрос, а как организована Model?
DG>Я утверждаю, что она должна быть организована в виде объектной оболочки к атомарному api.
Что такое "атомарный API"?

S>>Если ваш UI показывает сущности вашей внутренней модели, то в 99% случаев это плохо спроектированный UI.
DG>ужасное утверждение, т.к. используется неопределяемое понятие "внутренняя модель".
Оно вполне определяемое. Просто внутренняя модель сильно зависит от применяемой архитектуры.
Скажем, если мы работаем в традиционной для 90х годов клиент-серверной архитектуре, то внутренняя модель — это таблички и хранимые процедуры. В неё нет никаких объектов (и они нафиг не нужны).
Если мы работаем в традиционной для ранних 2000 SOA-архитектуре или трёхзвенке, то внутренняя модель — это сервис (или несколько сервисов) с RPC-style дырками в них. Опять никаких объектов нету (ну, кроме объекта "ендпоинт", который никак предметной области не соответствует).
Можно ещё поиграть в рич-модель, но она, по моему опыту, затрудняет работу как тому, кто её мучительно пишет, так и тому, кто её мучительно потребляет.

DG>Для меня как раз пример из ролика AndrewVK показывает, что в gui-е тупо показывается сущности внутренней модели (сущности атомарного api), например, даже никто не озаботился, чтобы число 20тыс. р не надо было вводить два раза, не говоря уже про какие-то более удобные вещи.
У меня IE x64, ролики кажет через раз. Так что не могу конструктивно обсуждать пример AVK.
S>>Пользовательский интерфейс должен проектироваться от сценариев пользователя; и объекты в нём будут такие, чтобы соответствовать сценариям пользователя.
DG>Так объектная оболочка как раз и спроектирована от сценариев пользователей.
Непонятно. Сценарий — это, грубо говоря, набор глаголов.
DG>Если я руководитель небольшой ООО компании, то я:
DG>- хочу выдавать распоряжения без всякой прослойки в виде бухгалтера (который лишь жрет мою прибыль),
Много эмоций, мало смысла.
DG>- хочу чтобы система мне на основе бух. данных строила полноценных фин. анализ,
Много эмоций, мало смысла.
DG>- хочу видеть Иванов.Выдать_Зарплату,
А это ещё зачем?
DG>- хочу чтобы все КГОСУ проставлялись автоматически на основе лучших рекомендаций бух. консультантов по оптимизации налогооблажения,
DG>- хочу видеть следующий сценарий использования бух. системы:
DG>- подписался на пакет рекомендаций от консультанта бух. учета,
DG>- вводишь Иванов.Выдать_Зарплату,
DG>- бух. система сама проставляет все бюджетные коды на основе скаченного пакета рекомендаций.
Чушь какая. Вы вообще реальных пользователей видели когда-нибудь? У них нет терминов "скачанного пакета" и "вводишь".

AVK>Что то я окончательно перестал тебя понимать. Ты предлагаешь отказаться от статической типизации или завести на каждого Иванова отдельное свойство в объекте предприятия?

1. автоматически завести отдельное свойство в объекте орг. структуры предприятия
2. статически проверять валидность операций
3. при сбоях в статических проверках — по максимуму локализовывать ошибку, и обеспечивать работоспособность остальной системы

требование на статическую проверяемость возникает из того факта, что при увольнение Иванова за пьянство хочется сразу видеть в каких скриптах он присутствует, а не удивляться тому, что Иванова уже как полгода уволили, а за бензин скрипт до сих пор ему доплачивает, а также не удивляться тому, что на носу сдача отчетности, а скрипты валятся не находя уволенного Иванова, потому что никто так и не удосужился поправить скрипты после того, как Иванова уволили. Бух. система про эти проблемы может заранее предупредить только в случаях, когда она поддерживает статическую типизацию для ссылок на сотрудников.

AVK>Но я так и не получил от тебя ответов на кучу заданных вопросов. Я правильно понимаю, что для ввода первички и формирования хозопераций объект Счет все таки не нужен?

Необходимо сначала договориться о терминах: что такое первичка, и что такое счет?

Потому что для меня первичные документы — это трудовой договор, приказ о премировании, табель о кол-ве выпущенных деталей при сдельной оплате, товарный чек, выписка с банковского счета о приходе денежных средств, закрытый акт выполненных работ, судебное постановление о выплате неустойки, строка в договоре с контрагентом о выплате аванса до 15-го числа и т.д.
Большая часть бухгалтерских документов — это уже вторичные документы, которые выпускаются для толкования первичных документов перед налоговой и другими бюджетными органами.

Также для меня Иванов.Начисленный_Доход, Иванов.Отработанные_Дни, Иванов.Расходы_из_его_собственных_средств — это тоже Счета, но уже больше в парадигме финансового и управленческого учета.

DG>>поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный

AVK>Приведи другой реальный, но не ужасный.

Я его привел:
1. сначала начисляем Иванову зарплату на основании трудового договора и табеля об отработанных днях
2. затем закрываем обязательства перед Ивановым в размере 20тыс. рублей

хочется видеть как это делается в парусе: как через Gui (в виде скринкаста), так и через CLI или скрипт (в виде примера кода).

AVK>Я не знаю что ты так уцепился за финансовый менеджмент и анализ, но на практике с ним тоже никаких проблем нет.

потому что для меня как для руководителя — фин.менеджмент — это первично, а бух. учет в разрезе кодов КБК — это вторично, который лишь навязан мне бюджетными органами, и для меня ничего полезного не делает.

Здравствуйте, DarkGray, Вы писали:
DG>MVP — это ответ на вопрос, как реализовывать gui
DG>OOUI — это ответ на вопрос, на основе каких принципов проектировать gui
Я, наверно, вас разочарую, но OOUI сейчас несколько вышло из моды.
Я читал Мандела — доктор наук, как никак. Но невооруженным мозгом понятно, что с тех пор, как он проектировал интерфейс для полуоси, человечество ушло далеко вперёд.
OOUI начинает со страшной силой сливать в случае более-менее сложных моделей, где объектов — много. Слишком много нужно умственных усилий, чтобы найти нужный объект, догадаться, что с ним делать, и выполнить действие. Особенно это здорово заметно, когда для действия нужно более одного объекта.

DG>и друг другу эти ответы ортогональны, и соответственно выбор реализации, как MVP — никак не противоречит пострению GUI-я как OOUI.
Совершенно верно. При этом надо понимать, что объектная ориентированность самого UI никакого отношения к внутреннему устройству не имеет. OOUI можно писать хоть на фортране-77.

DG>ps
DG>стоит хоть иногда книжки читать, хотя бы классику: Нильсен, Коллинз, Раскин
Можно цитату, где они настаивают на OOUI?
DG>pps
DG>ты лучше про веревку ответь, в фундаменте ООП — ты более подкован, и там с тобой интересно дискутировать, а про дизайн систем — не очень.
Что-то у меня запал иссяк. Там в верёвках и концах — сплошной косяк. Начиная с того, что у вашей верёвки произвольное количество концов.
Если непонятно, почему для непрерывно переходящих друг в друга объектов нельзя ввести identity, то я — пас.

AVK>Что такое атомарный api и как он должен выглядеть?

Фактически — это то, как ты сейчас для себя определяешь правильный дизайн системы.
Для меня — это лишь фундамент, на котором строится большая часть системы.
Надеюсь мы друг друга поняли, и можно не расписывать это детально.

DG>> наворачивается несколько уровней объектной оболочки, которые приближают объектную модель программы к понятийной модели пользователя

AVK>Зачем? И с какой стати ты решил, что в понятийной модели пользователя хозоперация является частью кредитного счета?

потому что для меня как для руководителя, знающего фин. менеджмент — каждая операция тесно связана с каким-то из счетов в момент совершения.

DG>>, позволяя ему единообразным способом работать — с GUI, CLI

AVK>Что такое CLI?

command-line interface, командная строка

DG>> и скриптами

AVK>Пользователю со скриптами? Ты ничего не перепутал?

Конечно, любой сотрудник с высшим образованием должен уметь (или как минимум должен способен научиться) автоматизировать свою работу, в том числе с помощью скриптов. Иначе непонятно за что ему выдали диплом о высшем образовании..

DG>>, а также разгововарить на едином языке с программистами при постановке задач по разработке.

AVK>Пользователю разговаривать напрямую с программистами? Все страньше и страньше.

Всё тот же вопрос: зачем мне как руководителю платить деньги еще кому-то за испорченный телефон, если эффективнее напрямую соединить пользователя и программиста?
Или зачем мне держать программиста который не может поговорить с пользователем, или зачем нужен сотрудник, который не может объяснить программисту что он хочет?

DG>>В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат.

AVK>Ух ты. Автоматически на основании чего? И зачем какая то оболочка, не привносящая в систему новой информации?

Потому что способности человека по комбинированию и запоминанию информации сильно ограничены, в отличии — от компьютера.
Соответственно, такая объектная оболочка — уменьшает временные затраты человека за счет того, что все необходимые данные для конкретной операции собраны вместе, а также благодаря тому — что большинство настроек выставлены автоматически на основе лучших рекомендаций от лучших консультантов. И соответственно, человек вводит только ту информацию и принимает только те решения, которые действительно необходимы в этот момент.

DG>> На практике — смешивается автоматическое построение объектной оболочки с ручным заданием.

AVK>Продемонстрируй. Пока что я вижу только лозунги, что все круто и никакой конкретики.

каким образом тебе это можно продемонстрировать?

AVK>Начни с описания одной подобной задачи. Реальной, а не "сижу, ~~примус починяю~~чеки разбираю". Потому что если реальной задачи нет — все это превращается в очередной бредогенератор типа ветки про открывание двери.

1. На основе данных за год из учетных систем (бухгалтерской и тайм-менеджмента) выдать рекомендации, что выгоднее: заключить контракт (и по какому тарифу?) на курьерское обслуживание с компанией "Скороход" или выгоднее продолжать в качестве курьера гонять Смирнова из отдела продаж и доплачивать ему за бензин?
2. Заказчик прочухался и шандарахнул на счет сразу куча бабла. Получить рекомендации от бух. системы, как эти деньги лучше дальше распределить и оформить, чтобы минимизировать расходы на налоги и минимизировать "заморозку" денег.
3. На основе данных из учетных систем посчитать норму прибыли для каждого сотрудника за последний год, и сравнить ее с нормой прибыли сотрудников в других компаниях из той же отрасли.

Здравствуйте, Ikemefula, Вы писали:
I>Вобщем расслабься, больше от тебя ничего не нужно, все жосткие данные уже получены от AVK и DarkGray.
Ну и к тому же видно, кто из участников понимает, что он делает. AVK возвращает пустой массив, который иммутабелен по определению.
А коллега vdimas предлагает глупость отдавать наружу разделяемый экземпляр мутабельного ArrayList<T>.
Это грабли, заботливо разложенные на пустом месте: однажды в каком-то углу кода кто-то сделает someArbitraryArg.Add(42) и пипец наступит повсеместно. Такую багу можно искать неделями.

Здравствуйте, Ikemefula, Вы писали:

I>Это попытка в десятке сообщений выдавить из тебя то, чего Avk выдал одной строчкой.

Сказано было именно это с самого начала, просто конкретно ты неадекватно вопринимаешь информацию.

I>В твоей модельке издержки на GC и близко не являются основным, она у тебя ни разу не адекватная, т.к. ошибся ты примерно на два порядка, вдобавок ко всему прочему добавил кучку дезы вроде "интрузивный список" и "должны обрабатываться после линии задержки".

Да лан, что тебе надо делать — я уже сказал. Но ты испарился там и материализовался здесь. Давай-ка лучше наоборот.

I>Вобщем расслабься, больше от тебя ничего не нужно, все жосткие данные уже получены от AVK и DarkGray.

Это ровно такие же жосткие данные, как и мои. Если ты не понял, что были упомянуты разные сценарии и поэтому наблюдали разный результат — то это опять твои проблемы.

Но, чтобы мне показать эту разницу (ключевое выделил), давай свой вариант решения "в лоб", чтобы было с чем сравнить. Хотя, собсно, ты бегаешь уже 3-й пост... И я даже знаю, почему, бо уже показывал здесь похожие трюки не раз, вызывая недовольство "высокоуровневых программистов"... Не боись, набираться опыта не так страшно, как кажется.

Здравствуйте, vdimas, Вы писали:

V>Ты не ответил ни здесь, ни на пред топик. Где сама-то сортируемая коллекция?

Где аннотации как минимум еще двух типов?
V>Ну и каша...

Это абсолютно неважно, но раз ты так хочешь:

interface IOperation<T, TR>
{
    TR Apply(T t);
    // остальные методы для простоты опущены
}

Mod modifier = GetSalt();
Ctx ctx = GetContext();
var operation = modifier[ctx]; // надеюсь тебя это не испугает

Order(x => operation.Apply(x)) // ты должен понимать, что это частный случай, то есть контекст сводится к готовому экземпляру

private void Order(Func<Item, int> => selector)
{
   _precachedResult = _items.OrderBy(selector).ToList();
}

V>А вопрос был ключевой лишь потому, что речь идет о статически-типизированном языке, то бишь, что бы не возвращал modifier[ctx] (скажем, SortModifier), и что бы не возвращаел затем Apply(x), — независимо от исходного модификатора это будет значение одного и того же типа. А я не вижу аннотаций в примере.

Это неважно.

V>Итого, в твоем примере я даже не вижу по какому критерию происходит сортировка. Полный мрак и непонятки. Вот причина "ключевых вопросов" — из-за нечитабельности кода.

Не ври, видишь — по значению возвращаемому Apply. На счет нечитаемости — так это твой С++ бекграунд даёт знать, раз уж ты одну строчку с лямбдойпрочесть ен можешь.

V>Ну ок, буду разгребать твою кашу.
V>Помнишь, я писал тебе тебе, что есть замыкание? Вот часть инфраструктуры вне примера:

Мусор скипнул и это ни разу не процедурное программирование, но уже целая инфраструктура

V>Имеем некую обобщенную процедуру сортировки (показываю ключевые моменты):
V>

V>template<typename Fn>
V>inline void qsort(CollectionOfX * collection, Fn f) {
V>

И это мусор, см выше

V>Далее, я из головы дополню отсутствующие нотации типов в твоем примере.

Мусор скипнул, см выше

V>А теперь само решение. Смотрим на твой код и отделяем мух от котлет, то бишь свободные переменные от связанных в замыкании:
V>

V>int CompareUsingModifier(SaltedModifier * sm, X * a, X * b) {
V>  return CompareByModifiedX(sm->Apply(a), sm->Apply(b));
V>}

Вот, появляется инфраструктура, ВНИМАНИЕ, для частного случая !  :))) 


V>Mod modifier = GetSalt();
V>Ctx ctx = GetContext();
V>SaltedModifier sm = modifier[ctx];

V>qsort(collectionOfX, make_fn(CompareUsingModifier, &sm));
V>

Итого — тебе понадобилась целая инфраструктура только для того, что бы сэмулировать один случай использования лямбды и передачи её в функцию сортировки

Если вызова будет два, тебе надо будет написать два метода,
Если вызова будет три, тебе надо будет написать три метода,
Если ...

При чем это частный случай, когда контекст сводится к уже имеющемуся экземпляру, опаньки...

А теперь, внимание, меняются требования и критерий сортировки будет другой. Для тебя это бедствие — надо переписать N-методов и N-мест, но это еще не все, потому что ...

Order(x => operation.Apply(Mask(x)))

Вот оно, бедствие — Mask это метод того же класса что и Order, а значит тебе надо еще накидать N-структур, то есть пары {SaltedModifier, SomeClass}.
Требования меняются снова:

Order(x => operation.Apply(Mask(x, code)))

Снова бедствие — перегрузка Mask приняла параметром значение параметра из вызывающего метода... И значит тебе снова надо переписать сигнатуры методов, изменить структуры {SaltedModifier, SomeClass, SomeParameter} и поменять связывание

Мне же надо поправить N-мест на каждый случай изменений. Итого — трудоемкость твоего подхода по скромной оценке на порядок выше.
Ты хорошо понимаешь, чего предлгаешь ? В твоем вариант надо метод, структуру и связывание, делать руками для каждого случая лямбды и метода который её принимает
На примере, смотри внимательно:
group.PullAction((a) =>
{
a.Location.Logical = new VectorD(dmGroup.OffsetX + dmGroup.PhysicalX, dmGroup.OffsetY + dmGroup.PhysicalY); // просто тянем из локального контекста
a.Caption = dmGroup.Name;
a.CustomGlyph = GetTypeIcon(propertyCache, dmGroup.GroupType); // снова локальный контекст но уже другой
... целая пачка свойство обновляется по требованию —
});
Так настраивается обновление и это очень, очень скромный пример, хотя экономит вагон кода и добавление нового свойства делается ровно в одну строчку, методов PullAction несколько штук...
Вот посложнее:

                case PaintMode.Routing:
                    return (s1, services, a) =>  
                    {
                        var query = new Collector(Properties.DepthMode);

                        query.Run(s1, services, (es, rt) => a(es, ToCategories(rt))); // лямбда принимает лямбду и это экономит вагон кода
                    };

А вот вещь которая тебя убьёт,

        public void MergeGroupsCategories(ObjectCategories mergeMask)
        {
            var mergeResult = ObjectCategories.None;

            Children
             .Apply( When:x => x.Visible && x as Group != null,   // не твой день, целых три лямбды и две из них рекурсивные
             visitOpen => x =>  // обычная лямбда-рекурсия
             {
                if((x as Group).IsOpen)
                {
                   visitOpen(x);
                   return; 
                }

                mergeResult = 0;
                group.Nested
                 .Apply(When:y => y.Visible
                 merge => y =>  // снова лямбда-рекурсия
                 {
                    mergeResult |= y.State.CheckCategories(mergeMask);
                    y.Children.Apply(merge);
                 });
                group.State.SetCategories(mergeMask, mergeResult);
            });
        }

Чисто императивный аналог по скромным оценкам в 10...100 раз больше, теперь представь, что такие функции на каждом шагу... Конечно, встроив всякие композиты-итераторы, получится сократить код, но все равно будет намного, намного больше и будут проблемы разных сортов.

Теперь заметь, мне надо ввести еще один параметр для обхода, опаньки, ничего сложного. А твоей эмуляции надо перепахать всё, вообще всё!

V>Ты показал плохой пример. Ничего не понятно. В отличие от моего конечного варианта, который отличается одной доп. ф-ей CompareUsingModifier.

Ты снова забыл, что обещал показать процедурное, а показал ООП+ФП. Если тебе нечего добавить, то будем считать что твоя ТЗ про процедурное неверна.

I>>Ну и снова ты отошел от структурного программирования.

V>А в какую сторону я отошел-то? Тебя идентификатор lambda смутил? А если бы я назвад его object?
V>Например, куда здесь отошла ф-ия драйвера, которой сам драйвер подается как контекст?
V>

V>void ioctl(IODriver * driver, int param, void * arg);
V>

V>В какую сторону ты видишь тут "отход от структурного программирования" (С)? В ФП или ООП?

V>Заметь, отход-то равнозначный... что как бэ намекает на истоки озвученного мною мнения. Я ведь не с потолка утверждение сделал, а после изготовления пары интерпретаторов ф-х языков.

Ты похоже не пониаешь, что в процедурном нет указателей на функции, потому даже ООП уже мягко говоря сильно затруднено.

I>>Покажи внятный аналог моего кода и не соскакивай со стурктурного .

V>Т.е. тебе опять нечего ответить? ЧТД.

Я так и не увидел "практически полный аналог процедурной декомпозиции". Пока что ты для честного случая задействовал почему то ФП и ООП, хотя обещал процедурное

I>>Покажи общий случай IoC а не вырожденый, мой пример выше.

V>Общий случай в qsort и есть. Похоже, ты не понимаешь, где в твоем собственном примере IoC, а где ФП. См внимательно мой вариант твоего примера.

Частный. Потому что лямбды используются повсеместно и тебе везде придется проектировать взаимодейтсвие. см мой пример про метод Mask

I>>"реально в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции"

V>Именно, твой пример — тому пример. Твоего замыкание в дизайне не видно.

ну да — не надо сотни классов генерить, не надо сотни методов писать — в дизайне не видно

I>>В другой технике у тебя просто нет аналога, потому что
I>>1. связывание придется делать вручную

V>Да похрен, это глубокие подробности кода, которые из дизайна не торчат ни разу. Абсолютно ничего не изменилось от того, что я прилепил локальную ф-ию CompareUsingModifier. Ну разве что сэкономил тебе немного на исходнике и осводил тебя от надобности писать комменты из-за самодокументирумости моего варианта.

Ну да, целая инфраструктура что бы сортировке передать параметр. Теперь вернись и посмотри состальные мои примеры.

I>>2. управлять контекстом придется вручную

V>Ну да. Подавать "контекст" придется вручную. Более того, у контекста теперь появится... оп-па! Экземпляр!

А толку ? Вместо одной строчки у тебя будет десяток другой на каждую лямбду и метод который её принимает.

I>>3. проектировать структуры данных для взаимодейтсвия придется вручную

V>Структура данных нужна будет для отображения контекста, а не дляя взаимодействия.

Неважно, её надо проектировать

V>============================
V>Кстати, у тебя, походу, проблемы с оперативной памятью:
I>>Покажи внятный аналог моего кода.

Ты так и не показал "практически полный аналог процедурной декомпозиции", как только покажешь, поговорим про твой пример

S> Там в верёвках и концах — сплошной косяк. Начиная с того, что у вашей верёвки произвольное количество концов.

согласен, замечание принимается.

что в следующем коде не так с identity?

      class Rope
      {
        public Rope()
        {
          this.Points = new double[100];
        }

        public double[] Points;

        public RopeEnd Start
        {
          get { return new RopeEnd(this, true); }
        }
        public RopeEnd End
        {
          get { return new RopeEnd(this, false); }
        }
      }
      class RopeEnd
      {
        public RopeEnd(Rope rope, bool isStart)
        {
          this.Rope = rope;
          this.IsStart = isStart;
        }
        public readonly Rope Rope;
        public readonly bool IsStart;

        public override bool Equals(object obj)
        {
          var ropeEnd = obj as RopeEnd;
          if (ropeEnd == null)
            return false;
          
          return object.Equals(this.Rope, ropeEnd.Rope)
            && IsStart == ropeEnd.IsStart;
        }
        public override int GetHashCode()
        {
          return this.Rope.GetHashCode() ^ this.IsStart.GetHashCode();
        }

        static Random rnd = new Random();

        public void Change(double x)
        {
          var points = this.Rope.Points;
          if (!IsStart)
            points = points.Reverse().ToArray();

          var len = rnd.Next(30);

          points = points.Select((v, i) => {var r = len - i; return r > 0 ?  v + x * r / len : v;}).ToArray();

          if (!IsStart)
            points = points.Reverse().ToArray();
          this.Rope.Points = points;
        }
      }

S>Если непонятно, почему для непрерывно переходящих друг в друга объектов нельзя ввести identity, то я — пас.

а вот тут ты передернул: я говорил о том, что границы объектов могут быть нечеткие, а не о том, что они непрерывно переходят друг в друга — это два совершенно ортогональных друг друга свойства.

вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity?

     class RopePoint
      {
        static readonly Random rnd = new Random();

        public RopePoint(Rope rope, int index)
        {
          this.Rope = rope;
          this.Index = index;
        }
        public readonly Rope Rope;
        public readonly int Index;

        public override bool Equals(object obj)
        {
          var other = obj as RopePoint;
          if (other == null)
            return false;
          return object.Equals(this.Rope, other.Rope) && this.Index == other.Index;
        }
        public override int GetHashCode()
        {
          return Rope.GetHashCode() ^ Index.GetHashCode();
        }
        public void Change(double x)
        {
          var center = Index * 10 + rnd.Next(16) - 8;
          var len = rnd.Next(20);

          Rope.Points = Rope.Points.Select((v, i) => { var r = Math.Abs(i - center); return r < len ? (v + x * (len - r) / len) : v; }).ToArray();

        }
      }

S>Я, наверно, вас разочарую, но OOUI сейчас несколько вышло из моды.

и по какой модели построен, например, интерфейс gmail-а, интерфейс редактора Drawing из google docs, интерфейс Visual Studio, интерфейс инет-банка СберБанка?
или это всё устаревшие примеры GUI? что тогда не устаревший GUI?

Здравствуйте, Ikemefula, Вы писали:

I>Ну-ка, подробнее про зависимость затрат на уробрку мусора от количества типов.

Да, кстати.
Отвечу и покажу, когда проберемся через уровень 0 по кол-ву объектов. На их кач-во зайдем на след. итерации.
В двух словах — речь об т.н. эффекте "протухания кеша". Воспроизводится только на примере де-факто большого кол-ва пробегаемого кода и различных структур данных на каждом шаге алгоритма. Этот эффект, к слову, хорошо показывает такое удивительное на несведущий взгляд отличие в эффективности синтетических тестов и реального кода. Т.е. тот самый случай, когда результат не равен сумме слагаемых.

Здравствуйте, vdimas, Вы писали:

V>Да, кстати.
V>Отвечу и покажу, когда проберемся через уровень 0 по кол-ву объектов. На их кач-во зайдем на след. итерации.
V>В двух словах — речь об т.н. эффекте "протухания кеша". Воспроизводится только на примере де-факто большого кол-ва пробегаемого кода и различных структур данных на каждом шаге алгоритма. Этот эффект, к слову, хорошо показывает такое удивительное на несведущий взгляд отличие в эффективности синтетических тестов и реального кода. Т.е. тот самый случай, когда результат не равен сумме слагаемых.

Не напрягайся, я лучше подожду когда про протухание кеша будет говорить ктото другой

Здравствуйте, Ikemefula, Вы писали:

V>>Сказано было именно это с самого начала, просто конкретно ты неадекватно вопринимаешь информацию.

I>Если почистить от дезы и скорректировать цифры которые отличаются на два порядка, то да

Дальше я скипнул, извини, буду считать что ты ничего не писал, а это мне привиделись твои сообщения.

Таки струсил. ))

Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так?

Итого, ты даже не смог вложиться в разницу быстродействия техники 5-тилетней давности и современной. Твой голый пример на той технике даже не взлетит, хотя пока не начинал делать ничего полезного.

Здравствуйте, Ikemefula, Вы писали:

I>Не напрягайся, я лучше подожду когда про протухание кеша будет говорить ктото другой

ОК, а я подожду пока ты наберешься смелости показать пример, который на 2 порядка отличается от моих цифр. Ну или пока что-то другой сможет аналогичное.

Здравствуйте, vdimas, Вы писали:

V>Таки струсил. ))

V>Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так?

А почему на 16 а не на 1023429879345 ?

Здравствуйте, vdimas, Вы писали:

I>>Не напрягайся, я лучше подожду когда про протухание кеша будет говорить ктото другой

V>ОК, а я подожду пока ты наберешься смелости показать пример, который на 2 порядка отличается от моих цифр. Ну или пока что-то другой сможет аналогичное.

Надеюсь твоё ожидание не будет потреблять твои ресурсы.

> I>Ну-ка, подробнее про зависимость затрат на уробрку мусора от количества типов.
>
> Да, кстати.
> Отвечу и покажу, когда проберемся через уровень 0 по кол-ву объектов. На их кач-во зайдем на след. итерации.
> В двух словах — речь об т.н. эффекте "протухания кеша". Воспроизводится только на примере де-факто большого кол-ва пробегаемого кода и различных структур данных на каждом шаге алгоритма. Этот эффект, к слову, хорошо показывает такое удивительное на несведущий взгляд отличие в эффективности синтетических тестов и реального кода. Т.е. тот самый случай, когда результат не равен сумме слагаемых.

Тоже очень интересно про зависимость уборки мусора от количества типов и протухание кэша. Новые для меня концепции.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

V>>Итого, в твоем примере я даже не вижу по какому критерию происходит сортировка. Полный мрак и непонятки. Вот причина "ключевых вопросов" — из-за нечитабельности кода.
I>Не ври, видишь — по значению возвращаемому Apply.

Чего-чего???

I>На счет нечитаемости — так это твой С++ бекграунд даёт знать, раз уж ты одну строчку с лямбдойпрочесть ен можешь.

При чем тут С++, если вырезанный кусок не поймет ни я, ни компилятор? У меня нет остальных исходников, чтобы восстановить контекст происходящего.

V>>Ну ок, буду разгребать твою кашу.
V>>Помнишь, я писал тебе тебе, что есть замыкание? Вот часть инфраструктуры вне примера:

I>Мусор скипнул и это ни разу не процедурное программирование, но уже целая инфраструктура

Это та самая процедурная декмопозиция по всем правилам процедурного искусства.
Мне уже любопытно, а как ты себе вообще представлял процедурную декомпозицию?

V>>Имеем некую обобщенную процедуру сортировки (показываю ключевые моменты):
V>>

V>>template<typename Fn>
V>>inline void qsort(CollectionOfX * collection, Fn f) {
V>>

I>И это мусор, см выше

Хорошо себя чувствуешь? Это тот самый целевой аналог твоего _items.OrderBy(), ради которого всё. Т.е. оно мусор только если _items.OrderBy() тоже мусор... Хотя не, вру, _items.OrderBy() мусор заведомо, т.к. не позволяет выбрать алгоритм сортировки. Сравни с qsort, выполненным в лучших традициях слабой связанности + IoC.

V>>А теперь само решение. Смотрим на твой код и отделяем мух от котлет, то бишь свободные переменные от связанных в замыкании:
V>>

V>>int CompareUsingModifier(SaltedModifier * sm, X * a, X * b) {
V>>  return CompareByModifiedX(sm->Apply(a), sm->Apply(b));
V>>}

I>Вот, появляется инфраструктура, ВНИМАНИЕ, для частного случая !

Мде... Это это локальная ф-ия. С каких пор локальные ф-ии стали инфраструктурой?

V>>Mod modifier = GetSalt();
V>>Ctx ctx = GetContext();
V>>SaltedModifier sm = modifier[ctx];

V>>qsort(collectionOfX, make_fn(CompareUsingModifier, &sm));
V>>

I>Итого — тебе понадобилась целая инфраструктура только для того, что бы сэмулировать один случай использования лямбды и передачи её в функцию сортировки

Да лан, целая инфраструктура — это целый дотнет, где 50 метров зависимых бинарников грузятся в память, чтобы сделать простейший чих.
А моя "инфраструктура", как ты выразился:
— однократная;
— обощенная;
— поместится в 1к исходников. )))

На ней можно эмулироватьи твой случай с сортировкой и вообще любой другой, который ты только сможешь изобрести.

I>Если вызова будет два, тебе надо будет написать два метода,

Нет.

I>Если вызова будет три, тебе надо будет написать три метода,

Нет.

I>Если ...

Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

А замыкание без свободных переменных можно реализовывать как часть вышестоящих замыканий (процедур) без изменения семантики. То бишь, в реальном коде одной процедурой можно заменить сразу несколько замыканий.

I>При чем это частный случай, когда контекст сводится к уже имеющемуся экземпляру, опаньки...

I>А теперь, внимание, меняются требования и критерий сортировки будет другой. Для тебя это бедствие — надо переписать N-методов и N-мест, но это еще не все, потому что ...

Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново. Ты ведь, сдуру отнес CompareUsingModifier к инфраструктуре, хотя это локальный метод на стороне вызывающего. Вернись и посмотри на код внимательней еще раз. CompareUsingModifier никогда не вызывается явно, а передается как адрес ф-ии. То бишь, если тебе надо другой критерий — подай адрес другой локальной ф-ии.

I>

I>Order(x => operation.Apply(Mask(x)))
I>

I>Вот оно, бедствие — Mask это метод того же класса что и Order, а значит тебе надо еще накидать N-структур, то есть пары {SaltedModifier, SomeClass}.

Беда только в голове. Поскольку кол-во замыканий сосвободными переменными у нас не изменилось, то кол-во элементов программы в моем примере не изменится. Изменится тело локальной ф-ии CompareUsingModifier точно так же, как изменился твой локальный код. Вместо sm->Apply(a) будет sm->Apply(Mask(a)).

I>Требования меняются снова:

I>

I>Order(x => operation.Apply(Mask(x, code)))
I>

I>Снова бедствие — перегрузка Mask приняла параметром значение параметра из вызывающего метода... И значит тебе снова надо переписать сигнатуры методов, изменить структуры {SaltedModifier, SomeClass, SomeParameter} и поменять связывание

SaltedModifier — это твой тип, который ты НЕ указал, я придумал ему имя сам.
Связывание измениться НЕ может, т.к. кол-во свободных переменных не поменялось, у тебя поменялось количество связанных переменных. Поэтому code уйдет в context. Будь хоть мильон связанных переменных, они все пойдут в один и тот же контекст. Единственное заметное изменение — это когда в контексте была одна переменная, а стало две. Вот тут для контекста потребуется ваять локальную структуру, вот тут уж дааааа... Особенно это будет "дааа" если я исопльзую заготовки обощенных структур, и назову эти структуры, скажем, Tuple.

Но от второй переменной и дальше — никаких изменений кроме тех, которые будут и в твоем коде.

I>Мне же надо поправить N-мест на каждый случай изменений. Итого — трудоемкость твоего подхода по скромной оценке на порядок выше.

Ты просто опять подтверждаешь, что не знаешь как работает ФП и поэтому не понял моего примера. Еще раз, крупным по-белому: CompareUsingModifier никогда не вызывается явно, а передается как адрес ф-ии. Итого, ровно в стольки же N-местах я внесу такие же изменения в тела локальных ф-ий CompareUsingXXX, какие ты внесешь в свой код. См. свой пример насчет sm->Apply(Mask(a)).

I>Ты хорошо понимаешь, чего предлгаешь ? В твоем вариант надо метод, структуру и связывание, делать руками для каждого случая лямбды и метода который её принимает

Да, именно, я руками делаю то, что за тебя делает сахарок. Я это где-то отрицал? Да я же наоборот, вызвался так сделать. Похоже, ты же совсем уже в своем соку сварился, я тебя освежу:

в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии). Возвращаясь к декомпозиции по замкнутому контексту — этот вид декомпозиции присутствует в подробностях кода, то бишь на уровне дизайна им можно пренебречь.

В общем, если единственно за что ты меня ругаешь, что где-то глубоко в подробностях кода у меня будет не так посахарено как у тебя, то большое спасибо, это означает полное и бесповоротное согласие с моей точкой зрения.

В остальном... я почитал ниже и, не побоюсь этого слова, с удовольствием подтверждаю твою правоту относительно того, то с синтаксическим сахарком получше чем без. Жаль, что ты не понимаешь кол-во полученного мною фана и удовлетворения в этой беседе. ))

Правда, вот эти моменты:

В твоем вариант надо метод, структуру и связывание, делать руками для каждого случая лямбды

конкретно для C# вызывают у меня жуткое неудовлетворение... При всёй красоте и удостве сахарка, техника автоматического захвата контекста безопасна только в условиях иммутабельности. А что происходит в случае захвата мутабельного контекста — видно было на этом форуме в профильных разделах, когда обсуждали мильон комбинаторно накладывающихся побочных эффектов, с которыми народ выходил жаловаться на жисть еще со времен появления анонимных делегатов в старом синтаксисе во 2-м дотнете.

I>Чисто императивный аналог по скромным оценкам в 10...100 раз больше,

Гы-гы-гы... Мож хоть раз с тобой на что-то конкретное поспорить? Ты же даже функциональной декомпозицией не владеешь, пишешь и не понимаешь свой собственный код... Ты даже не понимаешь, что показал мне в скипнутых примерах сценарии использование всего двух (ДВУХ!) базовых комбинаторов. Не стыдно??? На самом деле их ровно три, этих комбинатора. То бишь, что произойдет с моей т.н. "инфраструктурой", которую я, ес-но, на голубом глазу вынесесу из конечного решения и внесу в некий фреймворк, скажем, "Прелюдный", ты уже прямо сейчас можешь догадаться.

I>теперь представь, что такие функции на каждом шагу...

Да хоть десять на шаг. Важно понимать, что происходит.

I>Конечно, встроив всякие композиты-итераторы, получится сократить код, но все равно будет намного, намного больше и будут проблемы разных сортов.

Проблемы разных сортов бывают лишь от захвата контекста по мутабельной ссылке. А если ручкамми аккуратно захватывать копии значений в опасных местах (а я смогу этим управлять, в отличие от тебя), то проблем будет на-а-а-амного меньше.

Ды, кода будет ес-но больше. Основная масса лишнего кода будет занята строками объявлениями сигнатур локальных ф-ий и лишней парой фигурных скобок после этого объявления. Тела этих ф-ий будут отличаться по размеру не особо от исходного варианта. Остальное будет решено через комбинаторы, как через базовые, так и производные. Но ни о каких 10 раз и тем более 100 речь идти не будет, ес-но.

I>Теперь заметь, мне надо ввести еще один параметр для обхода, опаньки, ничего сложного. А твоей эмуляции надо перепахать всё, вообще всё!

Дык, если ты принцип действия IoC не понимаешь (смотри свой перл, что qsort это не IoC), если для тебя акты DI — темный лес, то ес-но тебе всё надо перепахать. А если я зависимости разнес, то пахать буду не больше тебя. Просто тебе дали такой инструмент... такой инструмент... где ты пишешь код и даже не понимаешь, какими приёмами пользуешься. Ты научился этому коду по образу и подобию на примерах более опытных товарищей, а не потому что сам понял, что так тоже можно... xz: Ей-богу, не ожидал таких перлов-комментариев на показанные мною кишки реально происходящего. Видишт ли... оно принципиально не могло отличаться от твоего решения, т.к. я его дословно эмулировал. Но ты, увы, этого не разглядел.

И да. Проблема на самом деле в моем решении есть и она серьезная, скажем, в координатах С++. Эта проблема — отсутствие GC, то бишь речь о времени жизни контекста. Проблема возникнет тогда, когда мы его используем не оперативным образом как в твоих примерах, а сохраняем для последующего использования. Скажем так, я же вижу, что ты из-зо всех сил лезешь подковырнуть оппонента, а как это сделать задешево — не понял. Надо было чуть подкорректировать свои примеры так, чтобы стал нужен GC и мне было бы сложнее отстреливаться. )) Но, справедливости ради, эта проблема ортогональна ООП/ФП/ПП. Например, в D есть GC, будет считать, что примеры можно было бы с минимальными телодвижениями переписать на нем, бо он тоже позволяет глобальные процедуры и ф-ии.

I>Ты так и не показал "практически полный аналог процедурной декомпозиции", как только покажешь, поговорим про твой пример

В том-то и дело, что показал в точности. А ты показал непонимание относительно устройства и механики работы ФП, даже когда эту механику воспроизвели на твоих собственных примерах. Это полный П.

Здравствуйте, AndrewVK, Вы писали:

V>>Дык, именно в этом соль.
AVK>Соль в том, что ты неверно трактуешь понятие чистоты функции, не смотря на довольно простое и однозначное определение.

Потому что не в этом определении соль, а в том, что само простое определение опирается на определение побочного эффекта, а вот оно уже вызывает постоянные споры. Потому что некоторые спешат ставить знак равенства м/у мутабельностью и побочными эффектами. Собсно, поэтому мне понятие ссылочной прозрачности нравится больше, что оно более конкретное.

В данном же случае речь шла о таком забавном замеченном моменте:
чистая ф-ия -> порядок вычисления аргументов не важен, так?
Для Хаскеля порядок вычисления аргументов важен -> чистая ли ф-ия??? )))

Ну т.е. прикол-оксюморон и ничего больше... А ты, как всегда, с ликбезом.

То бишь юмор был в том, что программа на Хаскеле, составленная из чистых ф-ий, на самом деле НЕ МОЖЕТ быть выполнена в чистой манере. И даже не потому, что в main подается IO, а потому что вычислитель конечный, и этот конечный вычислитель ОБЯЗАН упорядочивать вычисления, невзирая на то, что порядок якобы не важен. Механизм упорядочивания в Хаскеле автоматический — на ленивости, мемоизации и гарантиях порядка вычислений аргументов при if-then-else и в конструкциях ПМ. Вот то надо выучить, чтоб от зубов отскакивало, это принципиально. Так вот, принципиально, что порядок этот гарантируется и программист может на него можно полагаться в "чистой" программе. То бишь, если бы программы на Хаскеле писали исходя из предположения, что они будут выполняться абстрактным вычислителем, который вычисляет аргумнты ф-ий в произвольном порядке, согласно их чистоты, то эти программы надо было бы писать по-другому. Вот всё что было сказано, не надо было изборетать лишнего.

V>>Мало ли, что компилятор в процессе оптимизации переписывает?
AVK>Он, такие дела, и порядок вычислений тоже меняет. Так что в общем случае нет, порядок вычислений определить по Ф-программе нельзя.

Я уже сказал, для каких конструкций этот порядок заведомо известен при любом виде вычслений, что на IO, что на чистых. Без этих гарантий программы уходили бы в вечную рекурсию. Если помнишь, был здесь такой thesz, большой любитель Хаскеля, он подробно объяснял этот момент на примере комбинаторных парсеров. Я ХЗ что в этих объясениях могло быть непонятно...

V>>Точно так же и компилятор ФП, он может переписать много, но семантика результата должна быть точно такая же, как я получаю, пробегаясь по коду глазами... Иначе, как программировать-то?
AVK>Порядок вычислений в семантику чистого Ф-кода не входит, в отличие от императивного.

Для Хаскеля именно что входит. Ты можешь на него полагаться в конструкциях if и ПМ.

V>>>>Фортран, ес-но.
AVK>>>Это все?
V>>Если речь об истоках, должно было хватить.

AVK>Т.е. это все. ЧТД.

Эх, ничто не меняется в этом мире...

Здравствуйте, vdimas, Вы писали:

V>>>А теперь само решение. Смотрим на твой код и отделяем мух от котлет, то бишь свободные переменные от связанных в замыкании:
V>>>

V>>>int CompareUsingModifier(SaltedModifier * sm, X * a, X * b) {
V>>>  return CompareByModifiedX(sm->Apply(a), sm->Apply(b));
V>>>}
V>

I>>Вот, появляется инфраструктура, ВНИМАНИЕ, для частного случая !

V>Мде... Это это локальная ф-ия. С каких пор локальные ф-ии стали инфраструктурой?

Чисто для интереса, это в С++0x или ты имеешь ввиду локальные классы вроде

void f()
{
   int x;
   class XXX {
      int& x_;
   public:
      XXX(int& x) : x_(x) {}
      void operator()() { ... }
   } _xxx(x);

   ...
}

Здравствуйте, vdimas, Вы писали:

V>То бишь юмор был в том, что программа на Хаскеле, составленная из чистых ф-ий, на самом деле НЕ МОЖЕТ быть выполнена в чистой манере. И даже не потому, что в main подается IO, а потому что вычислитель конечный, и этот конечный вычислитель ОБЯЗАН упорядочивать вычисления, невзирая на то, что порядок якобы не важен. Механизм упорядочивания в Хаскеле автоматический — на ленивости, мемоизации и гарантиях порядка вычислений аргументов при if-then-else и в конструкциях ПМ. Вот то надо выучить, чтоб от зубов отскакивало, это принципиально. Так вот, принципиально, что порядок этот гарантируется и программист может на него можно полагаться в "чистой" программе. То бишь, если бы программы на Хаскеле писали исходя из предположения, что они будут выполняться абстрактным вычислителем, который вычисляет аргумнты ф-ий в произвольном порядке, согласно их чистоты, то эти программы надо было бы писать по-другому. Вот всё что было сказано, не надо было изборетать лишнего.

Ты лучше пример покажи, а то я чет не понимаю, какая то новая концепция в хаскеле, что надо запоминать какой то механизм упорядочивания. Может я не те книги по Хаскелю купил

Здравствуйте, vdimas, Вы писали:

V>То бишь юмор был в том, что программа на Хаскеле, составленная из чистых ф-ий, на самом деле НЕ МОЖЕТ быть выполнена в чистой манере. И даже не потому, что в main подается IO, а потому что вычислитель конечный, и этот конечный вычислитель ОБЯЗАН упорядочивать вычисления, невзирая на то, что порядок якобы не важен. Механизм упорядочивания в Хаскеле автоматический — на ленивости, мемоизации и гарантиях порядка вычислений аргументов при if-then-else и в конструкциях ПМ. Вот то надо выучить, чтоб от зубов отскакивало, это принципиально. Так вот, принципиально, что порядок этот гарантируется и программист может на него можно полагаться в "чистой" программе. То бишь, если бы программы на Хаскеле писали исходя из предположения, что они будут выполняться абстрактным вычислителем, который вычисляет аргумнты ф-ий в произвольном порядке, согласно их чистоты, то эти программы надо было бы писать по-другому. Вот всё что было сказано, не надо было изборетать лишнего.

Хм. В таком случае чистых функций вообще не существует, поскольку в лямбда-исчислении могут получаться разные результаты в зависимости от выбраной стратегии редукции (я имею в виду, что при аппликативном порядке редукции нормальная форма не всегда достижима).

Здравствуйте, DarkGray, Вы писали:

AVK>>Что такое атомарный api и как он должен выглядеть?

DG>Фактически — это то, как ты сейчас для себя определяешь правильный дизайн системы.

Как я его определяю? Ты хоть на один вопрос можешь прямо ответить?

DG>Надеюсь мы друг друга поняли, и можно не расписывать это детально.

Зря надеешся, я тебя почти не понимаю, потому что вместо четких и ясных ответов на конкретные вопросы получаю какое то малопонятное философствование.

AVK>>Зачем? И с какой стати ты решил, что в понятийной модели пользователя хозоперация является частью кредитного счета?
DG>потому что для меня как для руководителя, знающего фин. менеджмент — каждая операция тесно связана с каким-то из счетов в момент совершения.

Ну вот, опять. Этот ответ логически равноценен ответу "потому что я так хочу". Ты, как руководитель, знающий финансовый менеджмент, можешь привести конкретный юзкейс, когда в бухгалтерии нужно переходить от кредитного счета к созданию хозоперации? Если да — юзкейс в студию. Если нет — о чем мы тогда говорим?

AVK>>Что такое CLI?

DG>command-line interface, командная строка

Пользователь, работающий с бухгалтерской системой через командную строку? Можно название продукта?

DG>>> и скриптами
AVK>>Пользователю со скриптами? Ты ничего не перепутал?

DG>Конечно, любой сотрудник с высшим образованием должен уметь (или как минимум должен способен научиться) автоматизировать свою работу, в том числе с помощью скриптов. Иначе непонятно за что ему выдали диплом о высшем образовании..

Можно название продукта, позволяющего обычному пользователю-бухгалтеру писать свои скрипты? 1С, если что, не позволяет.

AVK>>Пользователю разговаривать напрямую с программистами? Все страньше и страньше.

DG>Всё тот же вопрос: зачем мне как руководителю платить деньги еще кому-то за испорченный телефон, если эффективнее напрямую соединить пользователя и программиста?

Затем что бизнес-аналитик, это не испорченный телефон, это специальный, очень важный человек, который, с одной стороны, досконально знает предметную область и реальные потребности клиентов, а с другой, в отличие от клиентов, понимает как формализовать требования.

DG>Или зачем мне держать программиста который не может поговорить с пользователем

Т.е. ты предполагешь, что программист будет ходить по предприятию, общаться с заказчиками и не вылазить из командировок? Или ты рассматриваешь исключительно ситуацию внутренней автоматизации илир конторы с меньше чем десятком заказчиков?

DG>>>В идеале — объектная оболочка строится автоматически, требуя минимальных трудозатрат.
AVK>>Ух ты. Автоматически на основании чего? И зачем какая то оболочка, не привносящая в систему новой информации?

DG>Потому что способности человека по комбинированию и запоминанию информации сильно ограничены, в отличии — от компьютера.

Пример в студию.

DG>Соответственно, такая объектная оболочка — уменьшает временные затраты человека за счет того, что все необходимые данные для конкретной операции собраны вместе, а также благодаря тому — что большинство настроек выставлены автоматически на основе лучших рекомендаций от лучших консультантов. И соответственно, человек вводит только ту информацию и принимает только те решения, которые действительно необходимы в этот момент.

Пример в студию.

AVK>>Продемонстрируй. Пока что я вижу только лозунги, что все круто и никакой конкретики.

DG>каким образом тебе это можно продемонстрировать?

Примером.

AVK>>Начни с описания одной подобной задачи. Реальной, а не "сижу, ~~примус починяю~~чеки разбираю". Потому что если реальной задачи нет — все это превращается в очередной бредогенератор типа ветки про открывание двери.

DG>1. На основе данных за год из учетных систем (бухгалтерской и тайм-менеджмента) выдать рекомендации, что выгоднее: заключить контракт (и по какому тарифу?) на курьерское обслуживание с компанией "Скороход" или выгоднее продолжать в качестве курьера гонять Смирнова из отдела продаж и доплачивать ему за бензин?

Где там нужна возможность создания хозоперации по кредитному счету?

DG>2. Заказчик прочухался и шандарахнул на счет сразу куча бабла. Получить рекомендации от бух. системы, как эти деньги лучше дальше распределить и оформить, чтобы минимизировать расходы на налоги и минимизировать "заморозку" денег.

Где там нужна возможность создания хозоперации по кредитному счету?

DG>3. На основе данных из учетных систем посчитать норму прибыли для каждого сотрудника за последний год, и сравнить ее с нормой прибыли сотрудников в других компаниях из той же отрасли.

Где там нужна возможность создания хозоперации по кредитному счету?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, DarkGray, Вы писали:

AVK>>Что то я окончательно перестал тебя понимать. Ты предлагаешь отказаться от статической типизации или завести на каждого Иванова отдельное свойство в объекте предприятия?

DG>1. автоматически завести отдельное свойство в объекте орг. структуры предприятия

И перекомпилировать при каждом изменении?

DG>2. статически проверять валидность операций

Каких операций? Как проверять? Кому проверять?

AVK>>Но я так и не получил от тебя ответов на кучу заданных вопросов. Я правильно понимаю, что для ввода первички и формирования хозопераций объект Счет все таки не нужен?

DG>Необходимо сначала договориться о терминах: что такое первичка, и что такое счет?

Очень странные вопросы ты задаешь. А ведь только что упрекал в некомпетентности. Это базовые термины.
Первичка:
http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B2%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82
Бухгалтерский счет ... Мне даже неловко отвечать на этот вопрос. О чем ты тогда так много писал? http://ru.wikipedia.org/wiki/%D0%91%D1%83%D1%85%D0%B3%D0%B0%D0%BB%D1%82%D0%B5%D1%80%D1%81%D0%BA%D0%B8%D0%B9_%D1%81%D1%87%D1%91%D1%82

DG>Потому что для меня первичные документы — это трудовой договор, приказ о премировании, табель о кол-ве выпущенных деталей при сдельной оплате, товарный чек, выписка с банковского счета о приходе денежных средств, закрытый акт выполненных работ, судебное постановление о выплате неустойки, строка в договоре с контрагентом о выплате аванса до 15-го числа и т.д.

И?

DG>Также для меня Иванов.Начисленный_Доход, Иванов.Отработанные_Дни, Иванов.Расходы_из_его_собственных_средств — это тоже Счета, но уже больше в парадигме финансового и управленческого учета.

Слова все знакомые, а смысл полностью ускользает.

DG>>>поэтому я и утверждаю, что пример ужасный, не смотря на то, что он реальный
AVK>>Приведи другой реальный, но не ужасный.

DG>Я его привел:

Где скриншот формы? Я что то не приметил.

DG>1. сначала начисляем Иванову зарплату на основании трудового договора и табеля об отработанных днях
DG>2. затем закрываем обязательства перед Ивановым в размере 20тыс. рублей

Вот ты даже не понял. Иванов в видео, это не кому зарплату начисляют, это получатель денег из кассы. Там оснований может быть вагон и маленькая тележка. Для реальной выдачи зарплаты вообще бухгалтерия не используется, есть специальный программный продукт, Зарплата, и там есть специальный документ на выдачу зарплаты, зарплатная ведомость, которая формируется автоматически. В бухгалтерии же либо импортируют это все из зарплаты, либо вообще формируют на всю зарплату подразделения один расходник, и в таком случае Иванов это работник, выдающий зарплату.
"Иванов.Начисленный_Доход, Иванов.Отработанные_Дни, Иванов.Расходы_из_его_собственных_средств" — вообще ни в каком известно мне сценарии не нужны, потому что все зарплатные операции групповые, минимум по подразделению.

DG>хочется видеть как это делается в парусе: как через Gui (в виде скринкаста), так и через CLI или скрипт (в виде примера кода).

Это другой продукт, и он только в декабре релизится, так что никаких скринкастов нет. И никакого доступного коммандлайна для пользователя тоже нет. Но во всех зарплатах, что я видел, это делается примерно так:
Начисление:

foreach (var empl in Empls.Select(...))
{
  CalculateIncome(empl);
  CalculateTaxes(empl);
}

Выдача зарплаты

var payList = new PayList();
foreach (var empl in Empls.Select(...))
{
  var salary = GetSalary(empl, date);
  if (salary > 0)
    payList.Add(empl, salary);
}

AVK>>Я не знаю что ты так уцепился за финансовый менеджмент и анализ, но на практике с ним тоже никаких проблем нет.

DG>потому что для меня как для руководителя — фин.менеджмент — это первично, а бух. учет в разрезе кодов КБК — это вторично

Если ты руководитель, тебя вообще не должны колыхать внутрипрограммные модели. Ты получаешь готовый продукт и документацию к нему, а не конструктор "напрограммируй чего нибудь через командную строку". А теперь давай вернемся к программистам, только для которых software architect и разрабатывает дизайн.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

DG>>1. автоматически завести отдельное свойство в объекте орг. структуры предприятия

AVK>И перекомпилировать при каждом изменении?

да. инкрементальные компиляторы уже давно не редкость.

DG>>2. статически проверять валидность операций

AVK>Каких операций? Как проверять? Кому проверять?

Для всех операций проверять (до выполнения самой операции):
соответствие идентификаторов справочникам и реестрам,
соответствие свойств друг другу: если Иванов в июне в отпуске, то нельзя в июне выпускать документы от его имени.

AVK>>>Но я так и не получил от тебя ответов на кучу заданных вопросов. Я правильно понимаю, что для ввода первички и формирования хозопераций объект Счет все таки не нужен?

DG>>Необходимо сначала договориться о терминах: что такое первичка, и что такое счет?

AVK>Очень странные вопросы ты задаешь. А ведь только что упрекал в некомпетентности. Это базовые термины.

Как минимум необходимо тогда добавлять, что это бухучет по-российски, что к реальному бухучету имеет отдаленное отношение, и тем более имеет слабое отношение к фин. анализу, которые тем не менее строится поверх бухгалтерского учета.

Принципиальное различие российской и американской учетных систем можно заметить сразу, как только мы чуть более внимательно присмотримся к их определению. В общепризнанном американском определении финансового учета говорится, что “Финансовый учет — процесс, заканчивающийся приготовлением финансовой отчетности относительно предприятия в целом, которая используется как внешними, так и внутренними пользователями... Эта отчетность обеспечивает последовательную и непрерывную выраженную в денежном измерении историю экономических ресурсов и обязательств предприятия и экономической деятельности, которая изменяет эти ресурсы или обязательства”. Определение же бухгалтерского учета по российской традиции несколько отличается: “Бухгалтерский учет — это система наблюдения, измерения, регистрации, обработки и передачи информации в стоимостной оценке об имуществе, источниках его формирования (обязательствах), и хозяйственных операциях хозяйствующего субъекта (юридического лица)”.

Основное различие можно выделить в том, на что обращено основное внимание определяющего. В первом случае, учет — это процесс, приводящий к результату (финансовой отчетности), правильное представление которого и является целью учета. Основным является не сам процесс, а именно результат. Во втором случае учет рассматривается как система, которая существует ради самого процесса.

Цели учета в России и США достаточно сильно различаются. Если выделять главное требование, предъявляемое к отчетности, то можно сказать, что если в США главное требование — разумность и полезность информации для принятия пользователем коммерческих решений, то в России главное требование — соблюдение различных правил ведения учета, предоставление формально правильной информации контрольного характера

AVK>Первичка:
AVK>http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B2%D0%B8%D1%87%D0%BD%D1%8B%D0%B9_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82
AVK>Бухгалтерский счет ... Мне даже неловко отвечать на этот вопрос. О чем ты тогда так много писал? http://ru.wikipedia.org/wiki/%D0%91%D1%83%D1%85%D0%B3%D0%B0%D0%BB%D1%82%D0%B5%D1%80%D1%81%D0%BA%D0%B8%D0%B9_%D1%81%D1%87%D1%91%D1%82

тут тоже сразу стоило тебе добавить, что и понятие "первичный документ" и "бух.счет" ты понимаешь в узком жестком смысле, как это зафиксировано в России бюджетными контролирующими органами.
Какое это отношение имеет к реальным "первичным документам" и "бух. счетам" — это вопрос отдельного рассмотрения..

AVK> Но во всех зарплатах, что я видел, это делается примерно так:

при этом сразу появился и объект для каждого сотрудника, и императивщина.

AVK>Ну вот, опять. Этот ответ логически равноценен ответу "потому что я так хочу". Ты, как руководитель, знающий финансовый менеджмент, можешь привести конкретный юзкейс, когда в бухгалтерии нужно переходить от кредитного счета к созданию хозоперации?

погасить долг перед контр-агентом Zzz

Здравствуйте, DarkGray, Вы писали:

AVK>>Ну вот, опять. Этот ответ логически равноценен ответу "потому что я так хочу". Ты, как руководитель, знающий финансовый менеджмент, можешь привести конкретный юзкейс, когда в бухгалтерии нужно переходить от кредитного счета к созданию хозоперации?

DG>погасить долг перед контр-агентом Zzz

И зачем там бухгалтерский счет?

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, DarkGray, Вы писали:

AVK>>И перекомпилировать при каждом изменении?

DG>да.

Собственно, дальше уже стало совсем не интересно. Твои рассказы ничего общего с реальными системами не имеют.

AVK>>Каких операций? Как проверять? Кому проверять?

DG>Для всех операций проверять (до выполнения самой операции):
DG>соответствие идентификаторов справочникам и реестрам,

Жесть то какая. Т.е. код пишется ровно под одно единственное предприятие? Так о какой, все таки, системе идет речь? Открой уже секрет, жутко интересно где при добавлении записи в справочник физлиц происходит кодогенерация и полная перекомпиляция прикладного кода.

DG>Принципиальное различие российской и американской учетных систем

Ну то есть вся проблема в российских стандартах бухучета? Именно они не позволяют правильный ОО дизайн использовать? Жжешь.

DG>тут тоже сразу стоило тебе добавить, что и понятие "первичный документ" и "бух.счет" ты понимаешь в узком жестком смысле, как это зафиксировано в России бюджетными контролирующими органами.

Ты уже забыл с чего эта нитка началась? С Re[24]: хихи — и именно там я явно сказал о каком именно счете идет речь.
Ну да бог с ним. Я так понимаю, что ты согласен с тем, что для систем бухучета, рассчитанных на стандарты РФ, твой дизайн не годен?

DG>Какое это отношение имеет к реальным "первичным документам" и "бух. счетам" — это вопрос отдельного рассмотрения..

Ну да, переключение разговора на спор о терминах очень удобно. Мы ведь не проблемы дизайна ПО обсуждаем, а особенности американского бухучета.

AVK>> Но во всех зарплатах, что я видел, это делается примерно так:
DG>при этом сразу появился и объект для каждого сотрудника, и императивщина.

Объект в ОО дизайне для сотрудника будет в любом случае, в том числе и в твоих примерах кода он есть. Если без объекта, то это будет другая модель. Отсутствие императивщины тоже вроде бы никто не обещал. Да и твои примеры ее отсутствием не страдают. Но может вернемся к теме? Где в этом коде вдруг понадобится объект Счет или специальное статически контроллируемое свойство для каждой записи в справочнике физлиц.

... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>

Здравствуйте, Wolverrum, Вы писали:

S>>Это будет нарушением SRP.
W>И чо?
W>Индусы код не поймут?
W>Система работать не будет?
W>Цена поддержки многократно вырастет?
W>Чувству прекрасного будет нанесен невосполнимый урон?

Как сказал один журналист, то, что одному — статья 134 УК РФ, другому — большая и чистая любовь. То есть, это всё конкретные правовые системы, в то время как преступление — понятие межсистемное.

Так же и здесь. Нарушение SRP обычно очень плохо, вне зависимости от подхода к проектированию. Если вы сами видите, что нарушаете SRP, надо исправлять. Другое дело, что один и тот же класс может нарушать SRP или нет, в зависимости от того, что считать его ответственностью.

Почему нарушение SRP очень плохо? С моей точки зрения, потому, что Васе такую систему понять труднее. Или Раманатану, в контексте вашего вопроса. Например, когда один и тот же класс возвращает балансы счета и курсы валют, это неочевидное для Раманатана поведение. Что бы там не говорили об индусах. Даже если они такое пишут, читать такое они обламываются.

Почему плохо, когда один класс суммирует проводки в базе по идентификатору, это спрашивайте у того, кто так утверждает.

S>>То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.
W>Выделенное плохо?
W>Подчеркнутое обязательно?

Подчеркнутое не то, чтобы не обязательно, это просто неправда. У счета может быть такая тонкая структура, как агрегатор других счетов согласно плану (циркуляру, спущенному Минфином, между нами говоря — исключительно в его, минфиновских, целях). ООП же нужен для того, чтобы Sinclair и дальше продолжал думать, что у счета нет никакой тонкой структуры.

>>anemic model:
>>"Logic cannot be implemented in a truly object-oriented way"

W>Какая невосполнимая потеря

Я бы сказал, вот что бывает, когда думаешь о Дизайне с большой буквы Ъ, а реальных людей (Васи и Раманатана) в упор не замечаешь.

Здравствуйте, Sinclair, Вы писали:

SV.>>А хранение и вычисление где будут реализованы?
S>В операциях, заданных над этим ADT. Для этого нет необходимости в ООП.

...на мосту мочало, начинай все сначала. Вот ниже вы пишете Wolverrum'у:

С точки зрения функциональных требований все парадигмы совершенно одинаковы — см. тезис Чёрча. То есть в принципе нет такой программы, которую можно было бы написать на ФП, но нельзя на ООП — как и наоборот.
Отличия — только в нефункциональных требованиях. Например, в том, сколько стоит отладка (т.е. доказательство корректности, хотя бы и нестрогое) и внесение изменений. Или в том, насколько эффективный код получается в результате.
Ну так вот понятность кода напрямую влияет на стоимость его поддержки.
Возможность изолировать эффекты локальных изменений — тоже.
Именно ради неё Кей вводил эти "чёрные ящики", а не потому, что они как-то особенно подходят к устройству мозга.

Если вы в самом деле это понимаете, как у вас рука поворачивается написать: "Для этого нет необходимости в ООП"? Да, для этого нет необходимости в ООП. ЕЕ ВООБЩЕ НИКОГДА НЕТ. БЕЗ ООП ВСЕГДА МОЖНО ОБОЙТИСЬ. ОНО ОБХОДИМО.

Покажите, где и как будут реализованы хранение и вычисление, чтобы мы могли сравнить стоимость отладки. Нет, не кода, который хранит и вычисляет, а кода, который будет написан для расчета линейных уравнений на его основе. И не надо писать "в операциях, заданных над этим ADT". Это не значит НИЧЕГО. Конкретизируйте. Я, если угодно, сделаю то же для ООП. Не сделал только потому, что верю, что все и так представляют, как это будет выглядеть.

Здравствуйте, grosborn, Вы писали:

>> G>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.
>>
>> Нет, это не тот ООП, который выбираем мы. Когда вы пишете в скайп, вы всегда отправляете абстрактное сообщение, частным случаем которого является текст или файл? Вы в самом деле так мыслите? Или вы все же отправляете тексты и файлы?

G>Писать хороший код, это как раз не делать как мыслить или моделировать реальность, а использовать соответствующие правильные методики для решения конкретных задач, опробованные и одобренные.
G>Вот как я понял, этот пример кода это написано как "автор мыслил", то есть в стиле ООПГМ. И мне сразу видно, что код неправильный, неоптимальный. В моем замечании я исходил из опыта, как такие задачи решаются в типовых случаях — сообщение поддерживающее разные форматы данных.
G>Ведь задача программиста не смоделировать реальность, а кратчайшим путем решить поставленную задачу, с учетом некоторых требований и условий.
G>Может быть в ООПГМ и есть свои преимущества, но приведенный пример их никак не продемонстрировал, понятности коду не добавил.

К счастью, авторы Skype'а до такого бреда не додумались ни на уровне протокола, ни на уровне объектной модели. У них есть чат, есть файлтрансферт. Сообщения, частным случаем которого является текст или файл, у них нет. А вашей объектной моделью пусть мои враги пользуются.

Здравствуйте, elmal, Вы писали:

E>Ладно. Другой пример. В проекте все данные хранятся в DTO. Пришел запрос с клиента, этот запрос десериализуется в DTO и путем цепочек преобразований попадает частично в локальный кеш, частично уходит через вебсервисы на сторону. DTO никаких зависимостей на другие классы не содержит, и если там есть логика, то тривиальная.
E>Запросы идут параллельно много, преобразования тоже идут параллельно. Да, проект представляет собой набор классов, и даже в некоторых случаев наследование там, вот только эти классы все stateless, существуют в единственном экземпляре и хоть и имеет приватные проперти, но они все инициализируются фреймворком, упрощающим dependency injection. SOLID, кстати, в основном соблюдается. Это считаем ОО подходом или нет? Учитывая что объекты не хранят состояния, и если б не были нужны фичи вроде АОП и удобного тестирования, то вообще б по существу там были б сплошные статические методы.

Не знаю: мало данных.

> К счастью, авторы Skype'а до такого бреда не додумались ни на уровне протокола, ни на уровне объектной модели. У них есть чат, есть файлтрансферт. Сообщения, частным случаем которого является текст или файл, у них нет. А вашей объектной моделью пусть мои враги пользуются.

И тут мы вдруг понимаем, что ты обсуждаешь то в чем не имеешь ни малейшего опыта. Предположить, что содержимое файла упаковывается в сообщение, мог только абсолютно не разбирающийся в теме человек.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> К счастью, авторы Skype'а до такого бреда не додумались ни на уровне протокола, ни на уровне объектной модели. У них есть чат, есть файлтрансферт. Сообщения, частным случаем которого является текст или файл, у них нет. А вашей объектной моделью пусть мои враги пользуются.

G>И тут мы вдруг понимаем, что ты обсуждаешь то в чем не имеешь ни малейшего опыта. Предположить, что содержимое файла упаковывается в сообщение, мог только абсолютно не разбирающийся в теме человек.

Называется, "сначала я пишу так, что не понять, потом злобно кусаюсь, когда меня пытаются понять и не понимают" (кстати, не факт, что не понимают — упаковка это ваши домыслы, приписанные мне). Дискурс а-ля рюс. Когда меня не понимают (пример ниже, где мой вопрос не понимает Sinclair), я же не быкую, а переписываю другими словами.

К вопросу об опыте. Каких только экземпляров для кунсткамеры я не повидал в реальных проектах! Сообщение для скайпа на их фоне — семечки.

Ладно, вернемся к теме. Вот ваши слова:

>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.

Что сие значит? Напишите так, чтобы исключить домыслы.

> Ладно, вернемся к теме. Вот ваши слова:
>
>>Интерфейс должен описывать отсылку сообщения, а сообщение может поддерживать разные форматы.
>
> Что сие значит? Напишите так, чтобы исключить домыслы.

Что тут непонятного? Обсуждаемый интерфейс, тот пример, является интерфейсом транспортного уровня, ибо для предметного он вообще непригоден, ибо сообщение это НЕ только текст или только файл. И для транспортного уровня он тоже неграмотен, ибо на транспортном уровне содержимое сообщения для интерфейса должно быть абстракцией. Выбор же послать с использованием протокола коротких сообщений или протокола передачи файлов должен осуществляться в зависимости от объема передаваемых данных. То есть грубо говоря небольшие файлы будут отосланы по протоколу коротких сообщений. И вообще, на транспортном уровне не должно быть метода .ПослатьФайл(), ибо файлы вообще-то в отличие от реального мира не передаются, а скачиваются по запросам принимающей стороны после разбора сообщения о передаче файла и если на принимающей стороне вообще разрешено принимать файлы.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

V>>Зато использование IList в коде сжирает любой предполагаемый профит. А что надо делать с иммутабельностью — я тебе уже говорил там, где скипаешь неудобные аргументы. IList по дизайну нифига не иммутабельный.

I>Не любой, он только инлайниться не будет,

А вообще по опыту вылизывания критического кода до микросекунд — разница м/у использованием List<> и IList<> в коде от 3-х до ~10-ти раз (от стоимости тела цикла зависит). В первом случае итератор будет представлен в бинарнике значением регистра, а во втором — будут два честных виртуальных вызова на каждом шаге.

I>зато этот интерфейс поддерживается во всяких оптимизациях например в Linq2Objects.

Эта мелочь в самом конце вычислений. Просто на задаче ручной сериализации я получил сначала выигрыш порядка 5-8 раз. А как только я попросил всех отказаться от IList<> в коде (и оп-па!!! это произошло абсолютно безболезненно), то тот же самый код на конкретных типах стал давать прирост до 50 раз в ручной бинарной сериализации в сравнении со встроенной. И сама задача обрела черты заведомо решаемой на дотнете. До этого были обоснованные сомнения.

I>Иммутабельный не IList, а пустой массив, это именно то что говорил Синклер

Синклер-то прекрасно знает, на какой неиммутабельный дизайн я ему намекал. Недавно я показывал всю кривизну такого подхода в споре о const. То бишь, все эти рассуждения у меня вызывают только иронию и мысль о поговорке "мыши плакали, кололись...", а далее ты в курсе. ))

Здравствуйте, grosborn, Вы писали:

G>Тоже очень интересно про зависимость уборки мусора от количества типов и протухание кэша. Новые для меня концепции.

Тогда это тебе не надо.

Но если любопытно, то понаблюдать самому проще простого: попробуй на досуге автонагенерить несколько сотен каких-нить синтетических тестов, надо чтобы их код не бы в бинарнике взаимно повторно используемым (можно брать пару десятков синтетических тестов и раширить их на несовместимые типы: int, long, double, float, complex<float>, complex<double>, coordinate<xxx> и т.д., можно это наполовину автоматизировать на генериках + value type). Затем, тем же автогенеренным кодом надо прогнать сначала в цикле каждый из синтетических тестов в отдельности, чтобы длительность каждого была сотню миллисекунд минимум, запомнить медиану результатов и вывести общую стоимость прогона, если бы каждый тест прогнали по 1-му разу. Затем надо все вместе тесты гонять по 1-му разу в цикле с паузой 100ms, 10ms, 1ms, 100us, 50us, 20us (пауза м/у полными циклами переборов тестов). Над результатами медитировать.

> G>Тоже очень интересно про зависимость уборки мусора от количества типов и протухание кэша. Новые для меня концепции.
>
> Тогда это тебе не надо.
>
> Но если любопытно, то понаблюдать самому проще простого: попробуй на досуге автонагенерить несколько сотен каких-нить синтетических тестов, надо чтобы их код не бы в бинарнике взаимно повторно используемым (можно брать пару десятков синтетических тестов и раширить их на несовместимые типы: int, long, double, float, complex<float>, complex<double>, coordinate<xxx> и т.д., можно это наполовину автоматизировать на генериках + value type). Затем, тем же автогенеренным кодом надо прогнать сначала в цикле каждый из синтетических тестов в отдельности, чтобы длительность каждого была сотню миллисекунд минимум, запомнить медиану результатов и вывести общую стоимость прогона, если бы каждый тест прогнали по 1-му разу. Затем надо все вместе тесты гонять по 1-му разу в цикле с паузой 100ms, 10ms, 1ms, 100us, 50us, 20us (пауза м/у полными циклами переборов тестов). Над результатами медитировать.

Ну опять туману напустил, скорчил умную рожу и общаешься через три губы. Даже не интересно стало у тебя что-то спрашивать.
Я-то наивно предполагал, что для работы самого GC именно количество типов, то есть их разнообразие не важно. Вот я конечно в деталях реализации GC не очень, у меня задачи совсем не реалтайм, но хочу уточнить одну вещь: ты когда гонял тесты GC, учитывал что от количества размещаемых типов зависит в первую очередь время выделения памяти под эти типы за счет кэширования и предсказаний? И сравнивал ты на примерно одинаковых рабочих объемах памяти? Твои эксперименты были чистыми с пониманием принципов работы?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Ну опять туману напустил, скорчил умную рожу и общаешься через три губы. Даже не интересно стало у тебя что-то спрашивать.

Это ты пошутил, или тебе всерьез не понятен принцип тестирования эффекта протухания кеша? Заметь, я НЕ предлагаю тестировать пока никакой GC, ты спросил сугубо о кеше — я тебе даю сценарий, как задешево наблюдать эффект, о котором ты спросил. Сам эффект заключается в том, что сумма отдельных слагаемых не равна сумме. )) Причем, чем больше пауза м/у целевыми тестами, тем больше это отклонение.

G>Я-то наивно предполагал, что для работы самого GC именно количество типов, то есть их разнообразие не важно. Вот я конечно в деталях реализации GC не очень, у меня задачи совсем не реалтайм, но хочу уточнить одну вещь: ты когда гонял тесты GC, учитывал что от количества размещаемых типов зависит в первую очередь время выделения памяти под эти типы за счет кэширования и предсказаний?

Че-то ты уже совсем потерялся. Выделение в GC быстрое. Оптимизировать всегда надо затраты на уборку. GC интерпретирует метаинформацию о типах по мере обхода графа объектов. Чем больше разнообразие типов, тем вероятнее будет эффект, который ты увидишь в приведенном сценарии теста. Почему речь о вероятности? Потому что размеры кеш-памяти разные. На какой-то машине эффект уже начнет проявляться, на какой-то еще нет или слабо.

G>И сравнивал ты на примерно одинаковых рабочих объемах памяти? Твои эксперименты были чистыми с пониманием принципов работы?

На одной и той же машине. Второй вопрос я не понял, перефразируй.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>видишь ли, под пунктом 2 управляющая структура, которая выполняет подпрограммы. хаскель-if их не выполняет, а лишь выбирает ветку. У нас есть гарантия что выбранная ветка будет вычислена хоть когда-нибудь?

V>Я так и знал. )))
V>Молодца, ты попался на тривиальный очевидный момент. Потому что поторопимшись. Давай ты напишешь пример, где предикат при if ОБЯЗАТЕЛЬНО вычисляется, но не будет вычислена возвращаемая if ветка.

Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался.
V>Ты увидишь кое-что важное, когда наконец сможешь этот пример породить. Что именно? А достаточно будет сравнить полученный вариант с вариантом работы некоего вычислителя на энергичной технике и попробовать найти отличия в семантике.
Ты уже задолбал делать выводы по вычислителю.

V>Так что ваш аргумент, по-сути, о том, что ф-ия if, как и все остальные ф-ии Хаскеля — ленивые. Это был, конечно, очень крутой и правильный аргумент. Только ни о чем, бо он сугубо о семантике низлежащего вычислителя. Т.е. ты имеешь полное право писать свои чистые ф-ии вовсе не заботясь о низлежащей семантике вычислителя. Где-то так...
Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто.

S>>По другим пунктам тоже можно поглядеть.
S>>1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается.

V>Я таки вижу, что именно само вычисление раскладывают на шаги: сначала задают промежуточные данные (let var=...), потом из них — конечные (in expr). Опять и снова, тот факт что вычисление производится в ленивой манере — ненужные подробности. Теперь найди отличия в описании шагов таких вычислений от описаний точно таких же шагов, записанных в императивном языке (порой с точностью до синтаксиса в compile-time и конечного кода в runtime). Другая модель? Хмм... арифметика, она и в Африке арифметика, как раз на арифметике можно абстрагироваться от любых низлежащих моделей вычислетелей.
отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись.

S>>А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.

V>Ну, если подходить догматически, расставить рамки и т.д. то пролететь может что угодно. А если рассматривать лямда-исчисление только как входные описания для некоего вычислителя на машине Тьюринга (а оно так и есть) — то я имею право искать похожие механизмы. ИМХО, ветвление и разложение сложных вычислений на более простые шаги — это фундаментальные практики, и там и там.
Да, я вижу что сводимость вычислителей к МТ дает тебе право не только искать, но даже утверждать об императивности всего что шевелится вплоть до языков высокого уровня. Неясно только, почему Пролог оттуда выбился.

S>>3. Выполнение подпрограммы пока ...уже бессмыслица в хаскеле, т.к. подпрограмма это выражение, которое сколько не выполняй, результат будет тот же самый ... пока булево выражение является true — тоже бессмысленно, т.к. в хаскеле выражение чему равно, тому и равно, сколько его не вычисляй, и выполнение подпрограммы на результат выражения не влияет.

V>Цикл — это повтор одного и того же кода. И ты тут пытаешься манипулировать, бо результат подпрограммы будет один и тот же только при одних и тех же входных данных. А если входные аргументы на каждом шаге цикла разные, то и результат будет разный. Почему-то комбинатор неподвижной точки так и называют — циклом или рекурсией, а вы тут упрямитесь? ))
Тебе уже намекали что у тела цикла нет результата, потому цикл без побочных эффектов способен лишь греть атмосферу.

S>>В итоге, все 3 пункта не о хаскеле.

V>Да ради бога. Мне просто опять прикольно как ты скачешь с теории на сугубо подробности (ленивое выполнение в случае if) и потом обратно. Эдак даже не получается ровненько провести границы догм, приходится бегать подправлять?

А мне прикольно как ты опять влез на МТ

V>>>Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?
S>>выше две мысли. Одна — if не выполняет ветки, вторая — (*)побочные эффекты не влияют на вычислимость функций, о которой писали авторы теоремы.

S>>Если ты хочешь притянуть за уши ФП к СП, то тебе придется обойтись без IO. Потому что (*). А так же потому что имея IO, мы можем на ФП спародировать любую императивную программу. Но ведь ФП Тьюринг-полна вовсе не потому что IO, так ведь?

V>Ес-но, она Тьюринг-полна, потому что может быть исполнено на конечном вычислителе, который ВЫНУЖДЕН аргументы некоторых ф-ий считать в определенном порядке.

Твоя аргументация убивает

V>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.

Что-то много букав. Да, конкретно в хаскеле K/KI будет вычислено раньше. Только причем здесь последовательность императивных стейтментов, задаваемая вручную?
понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).

S>Вы уверены что большинство C++/Java/C# программистов прочитало хотя бы один букварь по ФП? Я не уверен.

Более того, большинство программистов (в том числе C++/Java/C#) не прочитало ни одного букваря по ООП.

Здравствуйте, -VaS-, Вы писали:

S>>Вы уверены что большинство C++/Java/C# программистов прочитало хотя бы один букварь по ФП? Я не уверен.

VS>Более того, большинство программистов (в том числе C++/Java/C#) не прочитало ни одного букваря по ООП.

Можно переформулировать вопрос, о чем большинство программистов C++/Java/C# прочитало больше (ООП/ФП)?

Здравствуйте, vdimas, Вы писали:

V>Эта мелочь в самом конце вычислений.

Разница межу O(1) и O(N) стала мелочью ? А ты, непростой

>А как только я попросил всех отказаться от IList<> в коде (и оп-па!!! это произошло абсолютно безболезненно), то тот же самый код на конкретных типах стал давать прирост до 50 раз в ручной бинарной сериализации в сравнении со встроенной. И сама задача обрела черты заведомо решаемой на дотнете. До этого были обоснованные сомнения.

Зеваю. Такое утверждение требует некоторых жостких данных, которые я вряд ли дождусь.

I>>Иммутабельный не IList, а пустой массив, это именно то что говорил Синклер

V>Синклер-то прекрасно знает, на какой неиммутабельный дизайн я ему намекал. Недавно я показывал всю кривизну такого подхода в споре о const. То бишь, все эти рассуждения у меня вызывают только иронию и мысль о поговорке "мыши плакали, кололись...", а далее ты в курсе. ))

А по моему ты просто хочешь увильнуть в сторону.

Здравствуйте, vdimas, Вы писали:

V>Но если любопытно, то понаблюдать самому проще простого: попробуй на досуге автонагенерить несколько сотен каких-нить синтетических тестов, надо чтобы их код не бы в бинарнике взаимно повторно используемым (можно брать пару десятков синтетических тестов и раширить их на несовместимые типы: int, long, double, float, complex<float>, complex<double>, coordinate<xxx> и т.д., можно это наполовину автоматизировать на генериках + value type). Затем, тем же автогенеренным кодом надо прогнать сначала в цикле каждый из синтетических тестов в отдельности, чтобы длительность каждого была сотню миллисекунд минимум, запомнить медиану результатов и вывести общую стоимость прогона, если бы каждый тест прогнали по 1-му разу. Затем надо все вместе тесты гонять по 1-му разу в цикле с паузой 100ms, 10ms, 1ms, 100us, 50us, 20us (пауза м/у полными циклами переборов тестов). Над результатами медитировать.

Мне интересно, как ты делал такие задежрки в виндовсе ? Известно, что винда не умеет делать точные задержки длиной менее кванта, да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел.

Здравствуйте, samius, Вы писали:

S>Можно переформулировать вопрос, о чем большинство программистов C++/Java/C# прочитало больше (ООП/ФП)?

О технологиях всяких, это ж очевидно.

Здравствуйте, vdimas, Вы писали:

V>Это ты пошутил, или тебе всерьез не понятен принцип тестирования эффекта протухания кеша? Заметь, я НЕ предлагаю тестировать пока никакой GC, ты спросил сугубо о кеше — я тебе даю сценарий, как задешево наблюдать эффект, о котором ты спросил. Сам эффект заключается в том, что сумма отдельных слагаемых не равна сумме. )) Причем, чем больше пауза м/у целевыми тестами, тем больше это отклонение.

Если весь эффект это "сумма отдельных слагаемых не равна сумме" то этим свойством обладает любой отрезок кода который затрагивает кеш. Делаешь прогоны через паузу — опаньки, суммарное время прогонов меньше суммарного времени прогонов без пауз. GC здесь ничего не меняет.
Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем. Если в кеше в основном метаданные, очевидно, разнообразие типов заставит кеш "протухать" чаще. Но это только теория. На практике GC сам по себе осязаемо замедляется при большом расходе памяти. Это ожидаемый эффект и хотелось бы увидеть адекватную модель, которая позволит сравнить разницу между временем прогонов с большим количетсвом типов и с маленьким.

У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.

V>Че-то ты уже совсем потерялся. Выделение в GC быстрое. Оптимизировать всегда надо затраты на уборку. GC интерпретирует метаинформацию о типах по мере обхода графа объектов. Чем больше разнообразие типов, тем вероятнее будет эффект, который ты увидишь в приведенном сценарии теста. Почему речь о вероятности? Потому что размеры кеш-памяти разные. На какой-то машине эффект уже начнет проявляться, на какой-то еще нет или слабо.

Ты для начала внятно опиши, что же это за эффект такой.

На мой взгляд единственные адекватные характеристики которые отражают время работы GC
1 это глубина дерева объектов.
2 количество узлов в дереве
3 глубина стека
4 степень фрагментации

Здравствуйте, SV., Вы писали:

SV.>Если вы в самом деле это понимаете, как у вас рука поворачивается написать: "Для этого нет необходимости в ООП"? Да, для этого нет необходимости в ООП. ЕЕ ВООБЩЕ НИКОГДА НЕТ. БЕЗ ООП ВСЕГДА МОЖНО ОБОЙТИСЬ. ОНО ОБХОДИМО.
Хорошо. Напишем тогда так: преимущества у ООП — нету.

SV.>Покажите, где и как будут реализованы хранение и вычисление, чтобы мы могли сравнить стоимость отладки. Нет, не кода, который хранит и вычисляет, а кода, который будет написан для расчета линейных уравнений на его основе. И не надо писать "в операциях, заданных над этим ADT". Это не значит НИЧЕГО. Конкретизируйте. Я, если угодно, сделаю то же для ООП. Не сделал только потому, что верю, что все и так представляют, как это будет выглядеть.
А код для расчёта линейных уравнений так и будет написан, как учили в унивеситете.
Ну, вот для квадратных уравнений мы будем иметь

D = b*b - 4*a*c;
x1 = (-b - Sqrt(D)) / (2 * a);
x2 = (-b + Sqrt(D)) / (2 * a);

Дальщше что?

Здравствуйте, DarkGray, Вы писали:
DG>и по какой модели построен, например, интерфейс gmail-а, интерфейс редактора Drawing из google docs, интерфейс Visual Studio, интерфейс инет-банка СберБанка?
DG>или это всё устаревшие примеры GUI? что тогда не устаревший GUI?
Интерфейс гмейла построен, в первую очередь, на search & navigation. Интерфейс VS — объектно-ориентированный, но это большая редкость. И целевая аудитория у студии, скажем так, нетипичная. Интерфейс Сбера я не видел, а вот интерфейс Собиндиректа — классический navigation (с поправкой на некомпетентность архитекторов, но она вообще типична для веб-приложений).

Тьфу-ты. То есть речь идет просто об общей эффективности работы с большим количеством типов и алгоритмы GC тут не при чем. "Протухание кэша"

Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, DarkGray, Вы писали:

DG>что в следующем коде не так с identity?
Не могу понять смысл процедуры Сhange. Лучше реализуйте процедуру Cut, которая режет верёвку на две верёвки, причём идентичность концов сохраняется.
А по поводу идентити — у вас есть Equals, который зачем-то отличается от ReferenceEquals. Кто из них определяет Identity в вашем случае?

S>>Если непонятно, почему для непрерывно переходящих друг в друга объектов нельзя ввести identity, то я — пас.

DG>а вот тут ты передернул: я говорил о том, что границы объектов могут быть нечеткие, а не о том, что они непрерывно переходят друг в друга — это два совершенно ортогональных друг друга свойства.

DG>вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity?
Ну какой же он нечёткий? Он вполне чёткий. Вы порезали верёвку на целое количество частей. Смысл этого непонятен — у реальной верёвки между любыми двумя точками есть ещё одна.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Можно переформулировать вопрос, о чем большинство программистов C++/Java/C# прочитало больше (ООП/ФП)?

I>О технологиях всяких, это ж очевидно.

Очевидно что ты не понял вопрос. Слэш (/) в частности между ООП и ФП в нем употреблен вместо "или". Контекст вопроса тоже не подразумевал "всяких технологий".

Здравствуйте, samius, Вы писали:

I>>О технологиях всяких, это ж очевидно.

S>Очевидно что ты не понял вопрос. Слэш (/) в частности между ООП и ФП в нем употреблен вместо "или". Контекст вопроса тоже не подразумевал "всяких технологий".

Небольшая часть читает и ООП и ФП примерно поравну, остальные не читают ничего из этого.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Небольшая часть читает и ООП и ФП примерно поравну, остальные не читают ничего из этого.
Я думаю что это несложно опровергнуть по количеству изданий и их тиражам. Но не собираюсь этим заниматься.

Здравствуйте, samius, Вы писали:

I>>Небольшая часть читает и ООП и ФП примерно поравну, остальные не читают ничего из этого.
S>Я думаю что это несложно опровергнуть по количеству изданий и их тиражам. Но не собираюсь этим заниматься.

Конечно, и сначала надо выяснить, как "читает" соотносится с "издаётся".

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Небольшая часть читает и ООП и ФП примерно поравну, остальные не читают ничего из этого.
S>>Я думаю что это несложно опровергнуть по количеству изданий и их тиражам. Но не собираюсь этим заниматься.

I>Конечно, и сначала надо выяснить, как "читает" соотносится с "издаётся".
"Читает" соотносится с "тиражем". Косвенно, конечно. Кроме этого можно смело предположить что количество прочтений больше соотносится с тиражами изданий, нежели с твоей оценкой "порАвну", не зависящей от тиражей.

Вот тебе еще одна косвенная оценка.

Здравствуйте, samius, Вы писали:

I>>Конечно, и сначала надо выяснить, как "читает" соотносится с "издаётся".
S>"Читает" соотносится с "тиражем". Косвенно, конечно. Кроме этого можно смело предположить что количество прочтений больше соотносится с тиражами изданий, нежели с твоей оценкой "порАвну", не зависящей от тиражей.

Тиражи они разные, если исключить студентов и преподавателей, то вобщем выбор невелик. Для оытного разработчика что по ООП, что по ФП почти ничего нет.

S>Вот тебе еще одна косвенная оценка.

То есть, если некто ищет и читает про монады в эту статистике не попадёт, правильно ?

S>Лучше реализуйте процедуру Cut, которая режет верёвку на две верёвки, причём идентичность концов сохраняется.

постановка непонятна — идентичность чего с чем должна сохраниться?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Тиражи они разные, если исключить студентов и преподавателей, то вобщем выбор невелик. Для оытного разработчика что по ООП, что по ФП почти ничего нет.
Изначально речь шла о букварях

S>>Вот тебе еще одна косвенная оценка.

I>То есть, если некто ищет и читает про монады в эту статистике не попадёт, правильно ?
Смотря как искать. Если q="monad object oriented programming", то попадет и скажется на графике ООП.

Здравствуйте, samius, Вы писали:

I>>Тиражи они разные, если исключить студентов и преподавателей, то вобщем выбор невелик. Для оытного разработчика что по ООП, что по ФП почти ничего нет.
S>Изначально речь шла о букварях

Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Изначально речь шла о букварях

I>Это не важно. Минимум 90% не читают вообще ничего
Слова этой песни с припевом про нужды отрасли я уже слышал.

I> и это не мешает им освоить ООП и это же мешает освоить ФП.
А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).

S> Не могу понять смысл процедуры Сhange.

Меняет пространственное положение участков веревки в вертикальной плоскости, если считать, что сама веревка растянута в горизонтальной плоскости.

S> А по поводу идентити — у вас есть Equals, который зачем-то отличается от ReferenceEquals. Кто из них определяет Identity в вашем случае?

Идентити определяется с помощью функции Equals.

DG>>вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity?
S>Ну какой же он нечёткий? Он вполне чёткий. Вы порезали верёвку на целое количество частей. Смысл этого непонятен — у реальной верёвки между любыми двумя точками есть ещё одна.

Повторю, что есть два различных свойства(и понятия): классы эквивалентности элементов, и нечеткость положения и границ элемента.

Классов эквивалентности для RopePoint — здесь, да — четкое кол-во.
Но положение и граница каждого элемента RopePoint-а уже нечеткая. Попробуй ответить на простые вопросы:
— где центр каждого RopePoint-а относительно веревки, исходя из поведения функции Chnage?
— где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change?

на эти два вопроса можно ответить только используя вероятностное распределение, а это и есть симптом нечеткости и неопределенности.

Здравствуйте, Ikemefula, Вы писали:

I>Мне интересно, как ты делал такие задежрки в виндовсе ? Известно, что винда не умеет делать точные задержки длиной менее кванта,

Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...
Понятно, что из-за особенностей общего использования ресурсов в многозадачной ОС всегда будет некая погрешность и некое распределение... примерно такая же, как на "родном" sleep(x), даже если x кратен системному тику. То бишь всё ок, ка в реальной жизни. Нужную картинку ты увидишь все-равно, даже с учетом всех погрешностей, бо статистика она и в Африке статистика.

I>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел.

Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.

Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.

Здравствуйте, samius, Вы писали:

I>>Это не важно. Минимум 90% не читают вообще ничего
S>Слова этой песни с припевом про нужды отрасли я уже слышал.

Это реальность.

I>> и это не мешает им освоить ООП и это же мешает освоить ФП.
S>А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).

Это реальность.

Здравствуйте, vdimas, Вы писали:

V>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...
V>Понятно, что из-за особенностей общего использования ресурсов в многозадачной ОС всегда будет некая погрешность и некое распределение... примерно такая же, как на "родном" sleep(x), даже если x кратен системному тику. То бишь всё ок, ка в реальной жизни. Нужную картинку ты увидишь все-равно, даже с учетом всех погрешностей, бо статистика она и в Африке статистика.

Ты бы замерил что ли

I>>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел.
V>Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.

Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100)
Повторяю — это особенность виндовса.

V>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.

Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Это не важно. Минимум 90% не читают вообще ничего
S>>Слова этой песни с припевом про нужды отрасли я уже слышал.

I>Это реальность.

I>>> и это не мешает им освоить ООП и это же мешает освоить ФП.
S>>А это из анекдота про Изю и скрипку (там где он отвечает что еще не пробовал играть на ней).

I>Это реальность.

Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.

Здравствуйте, samius, Вы писали:

I>>Это реальность.

S>Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.

Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Это реальность.

S>>Пока ты не привел подтверждающих фактов (пусть даже косвенно указывающих на утверждаемое тобой), это твоя субъективная реальность.

I>Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно.
Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.

Здравствуйте, samius, Вы писали:

I>>Я поделился тем что вижу на собеседованиях, в числе стран есть и Россия, если тебе интересно.
S>Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.

Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Ты лишь подтверждаешь написанное мной — ты опираешься не на данные о программистах вообще, а на твои субъективные впечатления о программисах, прошедших через твои собеседования. Выборка нерепрезентативна.

I>Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.

А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?

DG>>или это всё устаревшие примеры GUI? что тогда не устаревший GUI?
S>Интерфейс гмейла построен, в первую очередь, на search & navigation.

Не понятно откуда взялось противопоставление парадигмы Search&Navigation парадигме OOUI. Это две ортогональные друг другы парадигмы — и использование одной из них никак не отрицает и не уменьшает использование другой.

В gmail явно используется OOUI парадигма.
Есть объекты — папка, цепочка-писем, письмо, набор цепочек-писем, адресат и т.д.
У объектов есть методы, которые можно вызвать.
Например, у цепочки-писем есть методы:
— Archive
— Report Spam
— Delete
— Move to ..
— Label as ..
— Mark as unread
— Mark as read
— Mark as important
— Mark as not important
— Add to Tasks
— Add star
— Filter messages like these
— Mute

Здравствуйте, samius, Вы писали:

I>>Это тебе хочется додумывать чего то. Я кроме собеседований еще и общаюсь с людьми которые такие же собеседования проводят. Разные страны, разные города, разные организация а ситуация примерно одна и та же.

S>А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?

Ты опросил людей не менее сотни, согласны ли они с моей позицией, изложив перед этим мою позицию без передергиваний ?
В этой сотне, буде таковая в наличии, люди помногу проводят собеседования а не просто поговорить ?

Шота мне кажется и там и там ответ "нет".

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>А ничего что на том же rsdn согласных с твоей оценкой ситуации еще поискать придется?

I>Ты опросил людей не менее сотни, согласны ли они с моей позицией, изложив перед этим мою позицию без передергиваний ?
I>В этой сотне, буде таковая в наличии, люди помногу проводят собеседования а не просто поговорить ?

I>Шота мне кажется и там и там ответ "нет".

Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.

Здравствуйте, samius, Вы писали:

I>>Шота мне кажется и там и там ответ "нет".

S>Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.

Я считаю, что N в данном случае пока что равно 1, это ты, по той простой причине что по озвученому вопросу выдал свою позицию ровно один раз. Подумай хорошенько, что это значит

Конкретно про "N << M". Если ты опросил некие N человек выбраных случайно и обладающих признаками дадеными в предыдущем посте и при этом N позволяет обобщить результаты...
Но у тебя ведь ничего такого нет, правда ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Если ты считаешь что раз твою позицию оспорило всего N человек << M числа посетителей сайта означает что остальные с ней согласны, то не буду шатать твой мирок.

I>Я считаю, что N в данном случае пока что равно 1, это ты, по той простой причине что по озвученому вопросу выдал свою позицию ровно один раз. Подумай хорошенько, что это значит

I>Конкретно про "N << M". Если ты опросил некие N человек выбраных случайно и обладающих признаками дадеными в предыдущем посте и при этом N позволяет обобщить результаты...
I>Но у тебя ведь ничего такого нет, правда ?

Правда в том, что я видел что другие тоже не соглашались с твоим мнением. А защитников твоего мнения кроме тебя не нашлось.
По поводу опросов мной случайной выборки — естественно этого не было. Но это не аргумент в пользу реальности твоей оценки.

Здравствуйте, samius, Вы писали:

S>Правда в том, что я видел что другие тоже не соглашались с твоим мнением.

Повторяю еще раз — мнение по вопросу кто чего читает или не читает я озвучил ровно один раз — сегодня.

>А защитников твоего мнения кроме тебя не нашлось.

Ты не то прочитать не можешь, не то еще что, разбирайся сам.

Здравствуйте, Ikemefula, Вы писали:

I>Если весь эффект это "сумма отдельных слагаемых не равна сумме" то этим свойством обладает любой отрезок кода который затрагивает кеш. Делаешь прогоны через паузу — опаньки, суммарное время прогонов меньше суммарного времени прогонов без пауз. GC здесь ничего не меняет.

Паузы не в счет, ес-но. Интересует сугубо полезная нагрузка. И да, в тесте можно выявить зависимость по двум координатам — по паузам и по кол-ву повторно неиспользуемого кода. Просто для второй координаты есть некий минимум, с которого эффект начинает наблюдаться устойчиво. То бишь, коль меня спросили о самом существовании эффекта — я ответил как на него посмотреть.

I>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.

Я не зря тебе дал вполне жОсткую (С) временную сетку. Тебе уже не надо гадать и нащупывать нужные области. Предлагаю проводить тест тогда, когда вообще "ничего такого" с машиной не происходит. То бишь, когда она ничем больше не занята. Результаты тебя всё-равно удивят.

I>Если в кеше в основном метаданные, очевидно, разнообразие типов заставит кеш "протухать" чаще. Но это только теория. На практике GC сам по себе осязаемо замедляется при большом расходе памяти.

На практике GC удачно обслуживает поколения даже при большом расходе памяти. А вообще, основная мысль верная — надо заставлять GC опрашивать как можно меньше памяти в абсолютном выражении на каждой итерации уборки мусора. Именно поэтому, запустив вечный цикл создания/уборки объектов нулевого поколения ты получаешь описанное тобой быстродейтсвие, что (1) циклы уборки 0-го поколения относительно частые и короткие, сам тест ты гоняешь без пауз. Создатели GC не дураки. Но как только уходим за пределы 0-го поколения, то... таки да, пулы объектов даже в Джава и Дотнете поднимают быстродействие некоторых сценариев в 2-3 раза. Сведения из биржевой области, там, где счет идет на на десятки микросекунд (для нейтива — на единицы микросекунд).

I>Это ожидаемый эффект и хотелось бы увидеть адекватную модель, которая позволит сравнить разницу между временем прогонов с большим количеством типов и с маленьким.

А что тебе мешает написать модель интерпретатора метаинформации и погонять ее при различном кол-ве обходимых структур описания метаинформации на каждом шаге?

I>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.

GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.

V>>Че-то ты уже совсем потерялся. Выделение в GC быстрое. Оптимизировать всегда надо затраты на уборку. GC интерпретирует метаинформацию о типах по мере обхода графа объектов. Чем больше разнообразие типов, тем вероятнее будет эффект, который ты увидишь в приведенном сценарии теста. Почему речь о вероятности? Потому что размеры кеш-памяти разные. На какой-то машине эффект уже начнет проявляться, на какой-то еще нет или слабо.

I>Ты для начала внятно опиши, что же это за эффект такой.

Ты уже сам его описал — эффект от выталкивания полезных данных из кеша. Кеш многоуровневый, эффект тоже.

I>На мой взгляд единственные адекватные характеристики которые отражают время работы GC
I>1 это глубина дерева объектов.

Ну да, это степенная ф-ия к суммарному кол-ву объектов, начиная от объектов самого верхнего уровня. Про "выпрямление" объектов в памяти я тоже упоминал. Очень много в дизайне value-type, которые, однако, безопасно использовать только в кач-ве приватных полей других объектов.

I>2 количество узлов в дереве

Поправлю, кол-во постоянно обновляемых объектов.

I>3 глубина стека

Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.

I>4 степень фрагментации

При нашем малом кол-ве объектов, да еще устойчиво живущих во 2-м поколении + крайне редком выделении памяти, считай, что фрагментации нет совсем. От дотнетного сетевого стека с его пинами тоже отказались. В общем, мое дело было лишь обрисовать эффект, ваше дело — принять во внимание или нет. До всех оптимизаций сервер принимал буквально 3-4 десятка клиентов, если больше — звук периодическя "вякал" и "квакал", после указанных оптимизаций — держал под тысячу на той же технике. ХЗ сколько будет на современной.

Здравствуйте, grosborn, Вы писали:

G>Тьфу-ты. То есть речь идет просто об общей эффективности работы с большим количеством типов и алгоритмы GC тут не при чем. "Протухание кэша"

Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?

Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.

Здравствуйте, Ikemefula, Вы писали:

V>>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...

I>Ты бы замерил что ли

Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.

I>>>да и в случае длины более кванта времени у ней тоже косяки случаются,наприме вместо 100мс может находиться в ожидании до 15сек. больше у меня выходило но говорят это не предел.
V>>Это от неумения готовить GC. А у нас более 50ms никогда не выходило. Как и почему — уже объяснял.

I>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100)
I>Повторяю — это особенность виндовса.

Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...

Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.

V>>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.
I>Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать

Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике.

Здравствуйте, Ikemefula, Вы писали:

I>Разница межу O(1) и O(N) стала мелочью ? А ты, непростой

Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ, то бишь собственно затраты на каждый шаг тоже... бо обработка данных по большей части порционная, где размеры самих порций не так, чтобы очень большие. И вот в этой самой оценке снизу IList сливает по самое нехочу.

>>А как только я попросил всех отказаться от IList<> в коде (и оп-па!!! это произошло абсолютно безболезненно), то тот же самый код на конкретных типах стал давать прирост до 50 раз в ручной бинарной сериализации в сравнении со встроенной. И сама задача обрела черты заведомо решаемой на дотнете. До этого были обоснованные сомнения.

I>Зеваю. Такое утверждение требует некоторых жостких данных, которые я вряд ли дождусь.

Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не?

I>>>Иммутабельный не IList, а пустой массив, это именно то что говорил Синклер

V>>Синклер-то прекрасно знает, на какой неиммутабельный дизайн я ему намекал. Недавно я показывал всю кривизну такого подхода в споре о const. То бишь, все эти рассуждения у меня вызывают только иронию и мысль о поговорке "мыши плакали, кололись...", а далее ты в курсе. ))

I>А по моему ты просто хочешь увильнуть в сторону.

Ух, зануда...
Сюда: http://www.rsdn.ru/forum/philosophy/4836724.aspx
И ниже по ветке.

Здравствуйте, Ikemefula, Вы писали:

V>>Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так?

I>А почему на 16 а не на 1023429879345 ?

Т.е. в плане некорректности теста возражений нет?

Здравствуйте, elmal, Вы писали:

E>Это считаем ОО подходом или нет?

В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
Причем, я сильно подозреваю, что без ущерба для ООП такие сообщения могут быть даже иммутабельными.

Здравствуйте, samius, Вы писали:

V>>В ОО сами сообщения, которыми обмениваются объекты, являются... тоже объектами. ))
S>Конечно же это бурная фантазия

На всяк случай для ленивых:

Первоначально (например, в том же Smalltalk) взаимодействие объектов представлялось как «настоящий» обмен сообщениями, то есть пересылка от одного объекта другому специального объекта-сообщения.

Здравствуйте, DarkGray, Вы писали:

DG>Меняет пространственное положение участков веревки в вертикальной плоскости, если считать, что сама веревка растянута в горизонтальной плоскости.
А зачем?

S>> А по поводу идентити — у вас есть Equals, который зачем-то отличается от ReferenceEquals. Кто из них определяет Identity в вашем случае?
DG>Идентити определяется с помощью функции Equals.
Прекрасно.

DG>>>вот, например, объект RopePoint с нечеткой границей и нечетким положением относительно Rope, какие у него проблемы с identity?
S>>Ну какой же он нечёткий? Он вполне чёткий. Вы порезали верёвку на целое количество частей. Смысл этого непонятен — у реальной верёвки между любыми двумя точками есть ещё одна.
DG>Повторю, что есть два различных свойства(и понятия): классы эквивалентности элементов, и нечеткость положения и границ элемента.
DG>Но положение и граница каждого элемента RopePoint-а уже нечеткая. Попробуй ответить на простые вопросы:
DG>- где центр каждого RopePoint-а относительно веревки, исходя из поведения функции Chnage?
Да нету там никакого поведения у функции Change. Понятия "центр" тоже нету.
DG>- где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change?
Ну как где? Это же дискретные объекты — значит, RopePoint "заканчивается" ровно там, где начинается второй.
У вас нет никакой меры близости RopePoint.
Поймите, реальная верёвка не состоит из счётного количества фрагментов (если мы не переходим на уровень молекулярного моделирования).
Река — не состоит из счётного количества капелек. Между любыми двумя точками верёвки можно найти ещё одну.
Чтобы смоделировать Rope Point с нечёткими границами, вам придётся заменить результат функции Equals с bool на double. И это всё ещё будут полумеры — потому, что double на самом деле тоже дискретен.

DG>на эти два вопроса можно ответить только используя вероятностное распределение, а это и есть симптом нечеткости и неопределенности.
Да ничего полезного на эти риторические вопросы ответить нельзя. Ваши RopePoint изоморфны натуральным числам. Где заканчивается 4 и начинается 5?

Здравствуйте, DarkGray, Вы писали:

S>>Лучше реализуйте процедуру Cut, которая режет верёвку на две верёвки, причём идентичность концов сохраняется.

DG>постановка непонятна — идентичность чего с чем должна сохраниться?
Ну как же? Концов верёвки. Одним концом верёвка привязана к DarkGray:

darkGray.tie = ropeEnd1;

Другим концом — к батарее:

heatTube.tie = ropeEnd2;

Мы можем убедиться, что DarkGray никуда не сбежит:

Debug.Assert(darkGray.tie.Rope.Equals(heatTube.tie));

А теперь разрежьте верёвку пополам. При этом heatTube.tie и darkGray.tie менять нельзя — они уже привязаны.
Но в результате у нас должны получиться две верёвки:

Debug.Assert(!darkGray.tie.Rope.Equals(heatTube.tie));

Здравствуйте, Ikemefula, Вы писали:

I>Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП.
1. Да, не читают. Это понятно и очевидно. В частности, видно по вопросам вокруг JS — из них видно, что большинство программистов на нём садятся и начинают писать. Поведение машины выясняется методом проб и ошибок, а не чтением литературы.
2. Не понятно, как оно помогает одному и мешает другому?

DG>>постановка непонятна — идентичность чего с чем должна сохраниться?
S>Ну как же? Концов верёвки. Одним концом верёвка привязана к DarkGray:
S>

S>darkGray.tie = ropeEnd1;

S>heatTube.tie = ropeEnd2;

S>

странный дизайн. Почему у каждого объекта только одна привязка?

S>Мы можем убедиться, что DarkGray никуда не сбежит:
S>

S>Debug.Assert(darkGray.tie.Rope.Equals(heatTube.tie));
S>

здесь по идее имеется в виду

S>Debug.Assert(darkGray.tie.Rope.Equals(heatTube.tie.Rope));

верно?

S>А теперь разрежьте верёвку пополам. При этом heatTube.tie и darkGray.tie менять нельзя — они уже привязаны.
S>Но в результате у нас должны получиться две верёвки:
S>

S>Debug.Assert(!darkGray.tie.Rope.Equals(heatTube.tie));
S>

и здесь таже самая неточность

S>Debug.Assert(!darkGray.tie.Rope.Equals(heatTube.tie.Rope));

Здравствуйте, DarkGray, Вы писали:

DG>странный дизайн. Почему у каждого объекта только одна привязка?
В общем случае — сколько угодно привязок.

S>>Мы можем убедиться, что DarkGray никуда не сбежит:
S>>

S>>Debug.Assert(darkGray.tie.Rope.Equals(heatTube.tie));
S>>

DG>здесь по идее имеется в виду
DG>

S>>Debug.Assert(darkGray.tie.Rope.Equals(heatTube.tie.Rope));
DG>

DG>верно?
Да, конечно.

DG>>- где начинается и заканчивается каждый RopePoint относительно веревки, исходя из поведения функции Change?
S>Ну как где? Это же дискретные объекты — значит, RopePoint "заканчивается" ровно там, где начинается второй.

и мы можешь доказать это утверждение, что всегда из первого следует второе? ты можешь доказать, что всегда из дискретности следует четкость границы?

Здравствуйте, DarkGray, Вы писали:

DG>и мы можешь доказать это утверждение, что всегда из первого следует второе? ты можешь доказать, что всегда из дискретности следует четкость границы?
Не очень понял, что именно нужно доказать. Аксиому?
У вас над точками не определено никаких бинарных операций, кроме Equals. А для неё границы совершенно чётко очерчены: каждая "точка" эквивалентна только самой себе, и абсолютно неэквивалентна любой другой точке.

Здравствуйте, samius, Вы писали:

S>В оригинальной концепции сообщения тоже были объектами, нашел подтверждение у Кея. А у Пирса в минимальном можестве фич ничего такого уже не упоминается. Да и во множестве ООЯ идентифицировать method invoke не представляется возможным.

Да фиг с ним, с Пирсом. Как ты собрался вообще представлять сообщения в своём ООЯ? Тупл неких значений-аргументов obj.f(x, y, x)? Какое же это ООП? )))
Хотя, де-факто так имеем в мейнстиме.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

I>>Разница межу O(1) и O(N) стала мелочью ? А ты, непростой

V>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.

Давай, покажи на примере Enumerable.ElementAt, вперёд.

I>>Зеваю. Такое утверждение требует некоторых жостких данных, которые я вряд ли дождусь.

V>Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не?

От тебя по прежнему нет кода

Тенденция-с.

Здравствуйте, vdimas, Вы писали:

V>>>Кстате, твой тест, судя по твоему же описанию, всё еще некорректен, то бишь исходные 2 порядка надо делить не на 8, а на 16? То бишь, 100/16=~6, так?

I>>А почему на 16 а не на 1023429879345 ?

V>Т.е. в плане некорректности теста возражений нет?

Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.

Здравствуйте, Sinclair, Вы писали:

I>>Это не важно. Минимум 90% не читают вообще ничего и это не мешает им освоить ООП и это же мешает освоить ФП.
S>1. Да, не читают. Это понятно и очевидно. В частности, видно по вопросам вокруг JS — из них видно, что большинство программистов на нём садятся и начинают писать. Поведение машины выясняется методом проб и ошибок, а не чтением литературы.

S>2. Не понятно, как оно помогает одному и мешает другому?

"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.

Здравствуйте, vdimas, Вы писали:

V>>>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...

I>>Ты бы замерил что ли

V>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.

Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки

I>>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100)
I>>Повторяю — это особенность виндовса.

V>Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...

Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.

V>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.

В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.

V>>>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша.
I>>Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать

V>Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике.

"Дергать GC" это например вызывать new для референстайпов.

Здравствуйте, Ikemefula, Вы писали:

I>Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.

Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.

И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.

Здравствуйте, vdimas, Вы писали:

G>>Тьфу-ты. То есть речь идет просто об общей эффективности работы с большим количеством типов и алгоритмы GC тут не при чем. "Протухание кэша"

Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?

V>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.

" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов"
"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @

Здравствуйте, Ikemefula, Вы писали:

V>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.
I>Давай, покажи на примере Enumerable.ElementAt, вперёд.

Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))
Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?

V>>Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не?
I>От тебя по прежнему нет кода

Тенденция-с.

Дык, мне оно и не надо, я это уже многнократно проходил во всех позах. И вообще, List<> vs IList<> как-нить сам. Это не тот нетривиальный пример, о котором говорили выше.

Здравствуйте, Ikemefula, Вы писали:

V>>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.

I>" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов"
I>"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @
I>

И? поясни юмор?
Не пробовал на досуге сравнивать размеры своих объектов vs размеры их метаописания?
Если кол-во метаинформации, необходмой для интерпретирования (во время уборки мусора) достаточно велико, то эффект протухания кеша ты получишь в квадрате, вот и всё, что имелось ввиду. Просто по своей наивности мне всегда кажется, что читатели и так должны знать, о чем речь. Фрум-то не для домохозяек...

Здравствуйте, vdimas, Вы писали:

I>>Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.

V>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...

То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.

V>Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.
V>И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.

"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas

Здравствуйте, Ikemefula, Вы писали:

V>>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.
I>Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки

Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.

I>>>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100)
I>>>Повторяю — это особенность виндовса.

V>>Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...

I>Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.

Боюсь, что это зависит больше от драйвера, а не от операционки.

V>>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.
I>В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.

Ничего от "просто нагрузки" не зависит. Запусти несколько процессов 10 GOTO 10 на многоядерной машинке и убедись. Речь может идти только о реалтаймовых потоках в виндах или случая запрета прерываний на подзадержавшемся DMA. Как раз второй момент по-идее одинаково работает для любых операционок.

V>>Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике.
I>"Дергать GC" это например вызывать new для референстайпов.

Опять и снова — интересуют всегда затраты на уборку, а не на выделение. Выделение относительно дешевое (не ахти, в сравнении с самописными аллокаторами, но достаточно дешевое для обсуждаемого). А вот уборкой ты управлять особо и не можешь. А интересует таки сугубо ограничение сверху на паузы GC в реальной проге и ничего более.

Здравствуйте, Ikemefula, Вы писали:

I>"Количество повторно неиспользуемого кода" это что за термин ?

Это речь о раздельных кешах для данных и для инструкций.

I>>>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.

V>>Я не зря тебе дал вполне жОсткую (С) временную сетку. Тебе уже не надо гадать и нащупывать нужные области. Предлагаю проводить тест тогда, когда вообще "ничего такого" с машиной не происходит. То бишь, когда она ничем больше не занята. Результаты тебя всё-равно удивят.

I>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.

Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.

I>>>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.

V>>GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.

I>Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.

Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.

I>Это не требует разнообразия типов, хватит и просто большого количества объектов.

Гы, и обратное тоже верно. Молодца, хорошо споришь.

I>>>2 количество узлов в дереве

V>>Поправлю, кол-во постоянно обновляемых объектов.
I>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep

В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД.

V>>Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.
I>Принципиально, ибо стек сканируется в лоб, в случае рекурсивных алгоритмов в стеке нужно сканировать _мегабайты_.

Я бы уволил такого программиста... Пользоваться инструментом надо уметь.
Не напомнишь выделяемую потоку глубину стека по-умолчанию?

V>>При нашем малом кол-ве объектов, да еще устойчиво живущих во 2-м поколении + крайне редком выделении памяти, считай, что фрагментации нет совсем.
I>Это не важно, чего у вас есть а чего нет, важно что степень фрагментации слишком сильно влияет на скорость GC. Как аргумент — вы от пулами именно с фрагментацией и боретесь.

Мы вообще с издержками боремся, а эти издержки очень многофакторны. Да, пул объектов позволяет эффетивно использовать хотя бы кеш второго уровня в процессоре. Тем более, что правильный пул объектов обязательно работает по схеме LIFO, в отличие от стратегии выделения памяти в GC.

Здравствуйте, vdimas, Вы писали:

V>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.
I>>Давай, покажи на примере Enumerable.ElementAt, вперёд.

V>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))

"прирост до 50 раз " @ vdimas

V>Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?

Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются.
Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.

Здравствуйте, vdimas, Вы писали:

V>>>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.
I>>Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки

V>Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.

Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.
Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.

I>>Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.

V>Боюсь, что это зависит больше от драйвера, а не от операционки.

Неправильно думаешь. ОСРВ гарантирует с большой точностью время работы системных вызовов. В QNX поток, который выполняет ожидание на момент окончания этого ожидания имеет наивысший приоритет, а в винде этого нет. Ну и инверсию приоритетов не надо забывать и много чего еще, например обработку аппаратных прерываний, здесь тоже есть ключевые различия, например в QNX ни просыпающийся веник, ни говнодрайвер в принципе не способны заморозить систему, а в винде это норма.
Собственно, что это я тебе рассказываю, ты ведь специалист по реалтайму вроде и сам всё знаешь и понимаешь.

V>>>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.
I>>В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.

V>Ничего от "просто нагрузки" не зависит.

Зависит.

I>>"Дергать GC" это например вызывать new для референстайпов.

V>Опять и снова — интересуют всегда затраты на уборку, а не на выделение.

Да-да. Все правильно. new инициирует уборку. Это что, новость ?

Здравствуйте, vdimas, Вы писали:

I>>"Количество повторно неиспользуемого кода" это что за термин ?

V>Это речь о раздельных кешах для данных и для инструкций.

Это я догадался, хотелось бы точное определение, а не то через 5 сообщений ты снова скажешь, что GC работает быстро если его не трогать.

I>>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.

V>Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.

Подай в суд на вындоус за эти неожиданности

I>>Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.

V>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.

Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?

I>>Это не требует разнообразия типов, хватит и просто большого количества объектов.
V>Гы, и обратное тоже верно. Молодца, хорошо споришь.

Моя модель более простая, понимаешь что это значит с т.з. диагностики ?

I>>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep

V>В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД.

Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC

V>Мы вообще с издержками боремся, а эти издержки очень многофакторны.

Буду знать, а то я было решил что ты акк кому то дал.

Здравствуйте, vdimas, Вы писали:

I>>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.

V>Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.

Задачка.

Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд.
Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10.
Никакого дотнета, олдскульный С даже без плюсов.

Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

Здравствуйте, Ikemefula, Вы писали:

I>Задачка.

I>Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд.
I>Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10.
I>Никакого дотнета, олдскульный С даже без плюсов.

I>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

просто любопытствую:
реально с таким сталкивался?
как заборол(и)?

Здравствуйте, Ikemefula, Вы писали:

I>Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд.
I>Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10.
I>Никакого дотнета, олдскульный С даже без плюсов.

Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.

I>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. ))
Ты показал эффект от нелокальности данных для потока, более ничего.

Здравствуйте, Философ, Вы писали:

Ф>как заборол(и)?

Борется выравниванием и пропусками в разделяемых данных, чтобы данные для разных потоков заведомо попали в разные линейки.

Здравствуйте, vdimas, Вы писали:

I>>Никакого дотнета, олдскульный С даже без плюсов.

V>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.

Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.

I>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

V>Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. ))
V>Ты показал эффект от нелокальности данных для потока, более ничего.

Я не знаю какой смысл ты вкладываешь в "протухание кеша"

Здравствуйте, Философ, Вы писали:

I>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

Ф>просто любопытствую:
Ф>реально с таким сталкивался?

Да.

Ф>как заборол(и)?

Просто по другому озадачили треды, они перестали сбрасывать друг другу линейки кеша.

Здравствуйте, Ikemefula, Вы писали:

V>>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.
I>Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?

Словами ты описал мне именно это. Код всё-равно не показал. И да, не уходи от ответа на вопрос: в синтетических тестах получал ли свои 15 сек паузы на GC?

I>>>Это не требует разнообразия типов, хватит и просто большого количества объектов.
V>>Гы, и обратное тоже верно. Молодца, хорошо споришь.

I>Моя модель более простая,

Она более однобока с т.з. происходящего в реальном коде.

Хотя, если речь о твоём клиническом случае в десятки миллионов объектов, то... то какого хрена там делает дотнет, не пояснишь? Он не для этих сценариев.

I>понимаешь что это значит с т.з. диагностики ?

Ес-но понимаю. Это означает нерелевантность любых синтетических результатов по такой модели.

I>>>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep
V>>В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД.
I>Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC

Нет, речь не о кол-ве узлов, а именно что об простом обновлении ссылочных полей "старых" объектов. Попробуй еще раз.

V>>Мы вообще с издержками боремся, а эти издержки очень многофакторны.
I>Буду знать, а то я было решил что ты акк кому то дал.

Да не будешь ты знать... ты пытаешься модель заранее урезать и высмеиваешь любые попытки сделать наоборот.

Здравствуйте, Ikemefula, Вы писали:

V>>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
I>То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.

Ты сказал о 8, и я по твоему описанию увидел некорректность в сценарии.

V>>Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.
V>>И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.

I>"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas

Дык, это ведь ты код требуешь. Я-то эту тему давно прошел и все выводы давно сделал. Мне лишь для своей эрудиции интересно понагибать последний дотнет.

В плане числодробления уже нагибал — сосет не нагибаясь как и прежде. В плане GC они там что-то сильно много хвалились — надо проверить насколько соответсвует действительности.

Здравствуйте, vdimas, Вы писали:

V>>>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.
I>>Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?

V>Словами ты описал мне именно это. Код всё-равно не показал.

Это ты додумал как тебе удобно было. Начни со своей модельки с очередями, только подумай сам, где ты ошибся на два порядка и при чем здесь миллионы объектов.

>И да, не уходи от ответа на вопрос: в синтетических тестах получал ли свои 15 сек паузы на GC?

Уже отвечал — 15 сек задержки было получено в нативном приложении, которое в цикле крутило QPC, Sleep, QPC + printf если время намного больше ожидаемого.

I>>Моя модель более простая,

V>Она более однобока с т.з. происходящего в реальном коде.

Правильно, для того что бы исследовать наблюдаемый эффект.

V>Хотя, если речь о твоём клиническом случае в десятки миллионов объектов, то... то какого хрена там делает дотнет, не пояснишь? Он не для этих сценариев.

Это заблуждение.

I>>понимаешь что это значит с т.з. диагностики ?

V>Ес-но понимаю. Это означает нерелевантность любых синтетических результатов по такой модели.

Это означает что модель легко использовать для исследования эффекта.

I>>Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC

V>Нет, речь не о кол-ве узлов, а именно что об простом обновлении ссылочных полей "старых" объектов. Попробуй еще раз.

Я именно про это и говорю, без этой оптимизации GC придется обходить весь граф объектов.

I>>Буду знать, а то я было решил что ты акк кому то дал.

V>Да не будешь ты знать... ты пытаешься модель заранее урезать и высмеиваешь любые попытки сделать наоборот.

Я пытаюсь упростить модель до предела, что успешно получается.

Здравствуйте, vdimas, Вы писали:

V>>>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
I>>То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.

V>Ты сказал о 8, и я по твоему описанию увидел некорректность в сценарии.

Если бы ты читал внимательно, то заметил бы, что эта разница целиком и полностью из за очереди при том что издержки на GC ничтожны. Эта разница как раз и натолкнула меня на мысль о том, что твои данные отличаются от реальных минимум на порядок-другой.

I>>"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas

V>Дык, это ведь ты код требуешь. Я-то эту тему давно прошел и все выводы давно сделал. Мне лишь для своей эрудиции интересно понагибать последний дотнет.

V>В плане числодробления уже нагибал — сосет не нагибаясь как и прежде. В плане GC они там что-то сильно много хвалились — надо проверить насколько соответсвует действительности.

Ничего, если я тебе твои слова покажу ?

Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.

И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.

Здравствуйте, Ikemefula, Вы писали:

V>>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.
I>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.

Дык, тогда ты попался. ))
На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.

I>>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.

V>>Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. ))
V>>Ты показал эффект от нелокальности данных для потока, более ничего.

I>Я не знаю какой смысл ты вкладываешь в "протухание кеша"

Это вытеснение из кеша нужных для нашей задачи данных/кода конкурирующими задачами. У тебя же такой заметный эффект мог получиться не от вытеснения, а от блокировки разделяемых линеек кеша во время их синхронизации на аппаратном когерентном движке ассоциативной памяти.

Здравствуйте, Ikemefula, Вы писали:

V>>И? поясни юмор?
I>Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).

А на мой взгляд твоя область деятельности настолько далека от вопросов гарантий эффективности, что тебе любые замеченные эффекты насчет быстродейтвия кажутся сигналами с далекой вселенной. по оценке снизу, ес-но.

V>>Не пробовал на досуге сравнивать размеры своих объектов vs размеры их метаописания?

I>И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики

Сколько это "достаточно велико", 10К, 100К, 1ККК ?

В боевом приложении может быть несколько тысяч типов и лишь по некоторым из них коллекции заметных размеров. Размеры самих объектов, например на 32-битной архитектуре, в среднем довольно малы. Я получал в статистике порядка 2-3 десятка байт в среднем на объект.

Здравствуйте, vdimas, Вы писали:

V>>>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.
I>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.

V>Дык, тогда ты попался. ))
V>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.

А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?

I>>Я не знаю какой смысл ты вкладываешь в "протухание кеша"

V>Это вытеснение из кеша нужных для нашей задачи данных/кода конкурирующими задачами.

Правильно.

>У тебя же такой заметный эффект мог получиться не от вытеснения, а от блокировки разделяемых линеек кеша во время их синхронизации на аппаратном когерентном движке ассоциативной памяти.

Отключи кеш да замерь разницу.

Здравствуйте, Ikemefula, Вы писали:

V>>Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.

I>Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.

Тривиальнейшая задача что под виндами, что под линухами.

I>Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.

По опыту, лишние подробности вызывают негодование "высокоуровневых программистов". Особенно когда приводишь тесты... Начинают искать то забытий Dispose в конце теста (хотя не требовался), то им не нравится что использовал для замера DateTime.Now вместо QueryPerformanceCounter (всегда так делаю на "длинных" тестах, системный таймер более точен, несмотря на более грубое квантование) и т.д. до бесконечности. Могу кинуть ссылку, где этот бред во всей красе. ))

Кароч, на указанных временных отрезках ньюансами можешь пренебречь. Сценарий тут ровно наоборот, то бишь подразумеваемые тобой ньюансы существенны лишь точного замера времени, но не для показанной задачи. Ссылки на сами эти ньюансы я же здесь и давал и объяснял когда-то, какой смысл повторяться?

В общем, мне было интересно, чтобы ты пошевелил процессором — но увы. Ес-но, у нас многозадачная ОСь, а данные нужны релевантные. Очевидно, над тупо собирать статистику и выкидывать нерелевантные данные. Например, те, где мы хотели получить задержку ~50us, а получили по-факту 50ms. "Ширину" допуска для временного интервала можешь выбрать сам. Это не бог весть какая наука, чтобы нельзя было догадаться самому.. ес-но, стоило тебе только быть чуть заинтересованней в обсуждении и вообразить себе сценарий реального генерирования необходимых задержек для целей тестирования, ты бы справился легко. В общем, я-то твоё "лишь бы поболтать" и так вижу, просто показываю твой абсолютно незаинтересованный в техническом плане подход к обсуждению тебе же самому.

Собсно, поэтому лень строчить для тебя нехилый исходник... что он тебе заранее неинтересен, увы, даже если покажет всё, что я хотел показать.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

V>>>И? поясни юмор?
I>>Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).

V>А на мой взгляд твоя область деятельности настолько далека от вопросов гарантий эффективности, что тебе любые замеченные эффекты насчет быстродейтвия кажутся сигналами с далекой вселенной. по оценке снизу, ес-но.

Ты мягко говоря ошибся, последний год я постоянно сталкиваюсь с оптимизацией по памяти и перформансу, а последние три месяца только этим и занимаюсь.
Тебе трудно признать, что критерии эффективности и оптимизации бывают разные ?

I>>И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики

Сколько это "достаточно велико", 10К, 100К, 1ККК ?

V>В боевом приложении может быть несколько тысяч типов и лишь по некоторым из них коллекции заметных размеров. Размеры самих объектов, например на 32-битной архитектуре, в среднем довольно малы. Я получал в статистике порядка 2-3 десятка байт в среднем на объект.

Внятно пожалуйста — количетсво типов, средний размер и что нужно делать, желательно кодом.

Здравствуйте, Ikemefula, Вы писали:

V>>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ.
I>>>Давай, покажи на примере Enumerable.ElementAt, вперёд.

V>>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))

I>"прирост до 50 раз " @ vdimas

Этот множитель сложился из двух множимых. См. исходный пост на русском языке: http://www.rsdn.ru/forum/philosophy/4843592.1.aspx.

А теперь тебе надо бъяснить пассаж насчет Enumerable.ElementAt.

V>>Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?

I>Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются.
I>Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.

Дык, никто не мешает использовать любые конкретные типы, в т.ч. обычный массив. И таки, если речь об итерировании, то итерирование по List<> нифига не дорогое удовольствие, в отличие от IList<>.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>В оригинальной концепции сообщения тоже были объектами, нашел подтверждение у Кея. А у Пирса в минимальном можестве фич ничего такого уже не упоминается. Да и во множестве ООЯ идентифицировать method invoke не представляется возможным.

V>Да фиг с ним, с Пирсом. Как ты собрался вообще представлять сообщения в своём ООЯ?
В том и дело, что кроме как представлять их (воображать), ничего с ними сделать нельзя. Ну или если очень надо, то завести класс Message/Command, который передавать внутри сообщения и идентифицировать как сообщение его экземпляры.

V>Тупл неких значений-аргументов obj.f(x, y, x)? Какое же это ООП? )))
V>Хотя, де-факто так имеем в мейнстиме.
Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.

Здравствуйте, samius, Вы писали:
S>Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.
Просто мейнстрим, в отличие от академики, требует реальных решений для реальных проблем.
Поэтому встраивают поддержку паттернов, отличных от "отправить один объект в качестве сообщения другому объекту".
Ну, вот как с теми же енумами в Джаве.
С точки зрения теории кристалла, енум можно эмулировать при помощи класса, у которого есть финитное количество экземпляров. Экземпляры созданы до начала работы пользовательского кода и никогда не умирают.
Для того, чтобы этот класс изобразить, нужно много "подпорок" и надстроек над исходной минимальной ООП-моделью. Нужна поддержка статических методов; нужна поддержка запечатанных классов; нужна поддержка приватных конструкторов.

И даже когда всё это есть, желателен синтаксический сахар, потому что руками описывать все эти public static readonly Color.Red = new object(); — занудство.

После этого при использовании можно опираться на ссылочную эквивалентность.

Понятно, что всё это — изоморфно подмножеству натуральных чисел, поэтому в некоторых языках, которые не стесняются мультипарадигменности, енумы реализуются не как сахар над ООП, а по-настоящему.

Примерно то же самое мы имеем по отношению к абстрактной "передаче сообщения" vs. "вызов метода".
В абстрактной академике биндинг выполняется полностью принимающей стороной, а в качестве сообщения может выступать всё, что угодно.
В конкретном мейнстриме имеются методы, сигнатуры, сложные правила совместимости, статический биндинг и прочее. Потому, что надо работать, а не доказывать достаточность минимального базиса.

Здравствуйте, Ikemefula, Вы писали:

I>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.

Т.е. имеется в виду т.н. "сетевой эффект", да?
Когда 99% кода, который ты встречаешь в жизни, написано с использованием ООП, и только 1% — с использованием ФП, то это и формирует твою квалификацию. В таком случае — согласен.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:
S>>Де-факто в мейнстриме мы и этого не имеем. Тупл-то вообразить можем, а проверить идентичность — нет.
S>Просто мейнстрим, в отличие от академики, требует реальных решений для реальных проблем.
S>Поэтому встраивают поддержку паттернов, отличных от "отправить один объект в качестве сообщения другому объекту".
S>Ну, вот как с теми же енумами в Джаве.
По поводу енумов в Джаве согласен.

S>Примерно то же самое мы имеем по отношению к абстрактной "передаче сообщения" vs. "вызов метода".
S>В абстрактной академике биндинг выполняется полностью принимающей стороной, а в качестве сообщения может выступать всё, что угодно.
S>В конкретном мейнстриме имеются методы, сигнатуры, сложные правила совместимости, статический биндинг и прочее. Потому, что надо работать, а не доказывать достаточность минимального базиса.

Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
Отчасти поэтому мы и имеем кучу работы с сингатурами, сложными правилами совместимости и прочим, вплоть до несовместимости Func/Action в C#. В ФП с более накладным применением аргументов все как-то намного проще.

Здравствуйте, Sinclair, Вы писали:

I>>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия. А вот с ФП нужно уже что называется долбить.

S>Т.е. имеется в виду т.н. "сетевой эффект", да?

Я не сильно понимаю этот термин. По ООП если в вакууме, как бы тоже надо читать. Но в реальности это не нужно т.к. грубо говоря среда сама предоставляет все необходимое.

S>Когда 99% кода, который ты встречаешь в жизни, написано с использованием ООП, и только 1% — с использованием ФП, то это и формирует твою квалификацию. В таком случае — согласен.

Примерно так.

Здравствуйте, vdimas, Вы писали:

I>>Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.

V>Тривиальнейшая задача что под виндами, что под линухами.

А еще ты забыл рассказать про "/usepmtimer", affinity, rdtscp и ничего не рассказал как влияет кеш на результаты таких измерений.

I>>Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.

V>Кароч, на указанных временных отрезках ньюансами можешь пренебречь. Сценарий тут ровно наоборот, то бишь подразумеваемые тобой ньюансы существенны лишь точного замера времени, но не для показанной задачи. Ссылки на сами эти ньюансы я же здесь и давал и объяснял когда-то, какой смысл повторяться?

см выше

V>Собсно, поэтому лень строчить для тебя нехилый исходник... что он тебе заранее неинтересен, увы, даже если покажет всё, что я хотел показать.

Ты только не волнуйся, я еще на прошлой неделе понял, что от тебя кода не будет

Здравствуйте, vdimas, Вы писали:

I>>>>Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.
V>>>Дык, тогда ты попался. ))
V>>>На однопроцессорной одноядерной машине никакое распараллеливание не ухудшало результаты настолько.
I>>А где сказал сказал, что процессор был "одноядерный", дашь ссылку ? Может быть тебе лучше прекратить додумывать ?

V>Выделенное не по-русски разве?

Выделенное выражает степень уверенности и там не содержится утверждение про какие то конкретные процы. Что бы было понятно — я просто не помню на каких процах какие именно были результаты, я привел только наихудший результат который запомнился.

I>>Отключи кеш да замерь разницу.

V>И какие проблемы? Отключать надо для обоих вариантов для сравнения. Давай тест, отключу да проверю.

Вариантов гораздо больше чем "обоих".

V>Небольшая разница может быть только на многоканальном контроллере, но никак не в 100 раз, ес-но.

Ай, не гони, сравнивать нужно пропускную способность памяти и L1, поделить одно на другое и будет разница в производительность для "памятезависимых" приложений.

V>Хотя и 100 раз — че-то дофига. Я максимум вручную насильно добивался ухудшения на этом эффекте в ~20 раз на шестиядернике. Мне уже любопытно, как ты получил свои 100 раз?

В зависимости от структуры процессора, особенностей чипсета, разница между частотами ядра и памяти, оптимизаций конкретного кода разница может быть и больше 100 раз. Только L2 может давать до 30% времени.

Здравствуйте, Sinclair, Вы писали:

SV.>>>>Нет, поскольку где ж вы возьмете идентификатор? Вообще, идентификатор сугубо служебен и снаружи вам не виден.
S>>>Как это "не виден"? Да он в плане счетов написан крупным шрифтом. То, что вы дали счёту какой-то внутренний служебный идентификатор — ваше личное решение; нужды в нём никакой нет.
SV.>>После таких слов Лука Пачоли в гробу перевернулся.
S>С чего бы это вдруг?

Ну как же. Как он смел заниматься бухгалтерией без плана счетов, утвержденных Минфином РФ с его идентификаторами? Ладно, это была шутка. Не обращайте внимания.

SV.>>Ваш план счетов — это один-единственный аспект, отчетный. А вы на основе его идентификаторов делаете уникальные ключи, хотя это всего лишь внешние атрибуты (и то, не факт, что прямые, очень может быть, что вычисляемые).
S>Не очень понятно, что значит "вычисляемые".

Я имел в виду запись в отдельной таблице с указанием текущего справочника и вхождения в него.

SV.>>Во-первых, план счетов — хронотопический стандарт, он действует на территории отдельного государства, и его средняя продолжительность жизни — пять лет. По уму, место его — в справочнике. Чтобы любое количество реальных счетов можно было отнести на счет из текущего плана, а исчезновение из плана идентификаторов не приводило к необходимости переоткрывать счета. Если подумать, из счета даже ссылаться на справочник текущего плана напрямую нельзя.
S>Совершенно верно. Именно поэтому идея представить счёт в виде объекта — порочна. Потому что все необходимости что-там "переоткрывать" связаны исключительно с представлением о счёте как о чём-то таком, у чего есть своё собственное поведение.
SV.>>Нужно делать промежуточную таблицу с историей ссылок.
S>Это ещё зачем? Такая таблица нужна только тогда, когда вы придаёте счёту идентичность. А у счёта её нет — вы только что сами написали об этом.
S>Если у вас в таблице проводок пишутся только идентификаторы счетов (в соответствии с той версией плана, которая актуальна на момент действия проводки), то никаких исторических таблиц делать не надо.

Один простой вопрос. Как вы в этой системе будете вести лицевые счета? Они не видны в отчете, но видны операционисту.

SV.>>Во-вторых, план счетов — внешний по отношению к организации стандарт. Есть ведь и другие аспекты помимо налогово-отчетных. В реальной организации на один внешний счет, включенный в отчет, может приходиться 10 внутренних, которые вообще в вышеупомянутом аспекте не видны.
S>Ну и что? Каким образом нам тут поможет ООП-шный объект "счёт"? То, что вы описываете, прекрасно реализуется на декларативном Екселе, не то что без ООП, а даже и без структурного программирования.

А я и не говорю про ООП. Я переключился на уникальные искусственные идентификаторы счета, которые (не) нужны.

SV.>>"Это" — это что? Сделать шорткат от Current'а на Date.Now?
S>Да.

SV.>>А почему не будем? Очень даже будем. Дизайн — он безответный, и, прикрываясь его интересами (которых у него нет), можно что угодно запроектировать. Вы ровно это и делаете. Берете произвольное решение, которое нравится вам ("надо его выносить наружу"), и пишете "с точки зрения правильного дизайна". Пойди поспорь. Или надо соглашаться, или начнется совершенно идиотский спор "какой дизайн трушнее". Который закончится взаимным посыланием нафиг и тем, что каждый останется при своем мнении.
S>Есть объективная реальность. Вообще дизайн — на удивление точная наука, даже если мы говорим о веб-дизайне или дизайне интерьеров. Всё в нём подчинено требованиям удобства сиреч эргономики.
S>А уж дизайн софта — и подавно. Есть совершенно объективные критерии того, какой дизайн лучше другого — это стоимость внесения изменений.
S>А рассуждения о субьективности критериев дизайна — это, простите, махровая гуманитарщина. То есть отказ от пользования логическим мыслительным аппаратом.

Вот опять мы говорим не про ООП. И опять я скажу, что тут шайбочкой не обойтись.

То, что прочитал, для меня звучит дико. В центре любого дизайна для меня стоит ЧЕЛОВЕК. Юзер. Покупатель и пользователь. С одной стороны дизайн продает. Если ЧЕЛОВЕКУ не нравится, он не купит. С другой — если вас этот покупатель интересует в будущем (он честно и регулярно платит), то даже после продажи надо обеспечить ЧЕЛОВЕКУ какое-то минимальное удовлетворение от покупки. Видите, сколько раз я сказал "ЧЕЛОВЕК"? А теперь вспомните, как "человечный" будет по латыни? Humanus. Да, представьте себе, это махровая гуманитарщина.

Теперь про логический аппарат. Аппарат вам не поможет, извините. Вся история IT — это история того, как тупорылый юзер похерил все достижения точных наук и чистого разума ~~и купил себе айфон~~. Угадать ход его мысли логически? Ха-ха-ха. Вся наука сводится к тому, чтобы либо быть с ним в резонансе, как это делал Джобс, либо ориентироваться по другим продуктам, фокус-группам и так далее. То есть, изучать человека без фиги (точной науки) в кармане. Кто бы мог подумать, что главное в мобильной операционной системе — блестящие иконки. Это я такой умный задним умом, как все русские. Когда игра уже сыграна.

Что эти немного абстрактные рассуждения значат применительно к ООП и счетам? Я делаю утверждение, основанное на наблюдениях, а не на какой-то там мифической науке: никто не любит писать объектные модели, но все очень любят ими пользоваться, поскольку они снижают порог вхождения. Я делаю второе утверждение — нет, и не может быть никакой науки, чтобы доказать или опровергнуть первое утверждение. Максимум, что мы можем сделать — это провести опрос или посмотреть на эволюцию имеющихся программных систем. Мое третье утверждение — вам же самому будет лучше, если программисты по проекту под вашим началом смогут быстро в нем осваиваться. Экономически. Поскольку есть и такая точка зрения — мы привлекаем лучших специалистов, вот пусть они и нюхнут дерьмеца. Монстры-инженеры, как-никак. Лапшу там поразгребают, знание о проводках постаскают из модуля в модуль. Люди такие есть, но вы их сначала наймите, а потом окажется, что бросать их на бухгалтерию — как микроскопом гвозди забивать.

SV.>>Например, Васе поставили задачу — "построение таблицы [счет]-[текущий баланс]". Если вы опять напишете про своих теток, которые паразитируют на реальном труде, приводя сведения о реальном бизнесе в соотетствие с порождением советского Госплана (а откуда же еще высрались эти планы счетов?), которым такая таблица не нужна, не надо, пожалуйста.
S>Коллега, меньше эмоций. Бухгалтерию придумали вовсе не в СССР, и про тёток никто не писал. Если у Васи представления о счёте, как о баночке с деньгами — то это личные Васины проблемы. Точнее, это проблемы того, кто Васю нанял, потому что реальная бухгалтерия работает вовсе не так.
S>Реальная бухгалтерия — это, в первую очередь, механизм расчёта налогов. Без этого, грубо говоря, можно просто иметь одну баночку с деньгами, и просто брать из неё столько, сколько нужно.

Нет, нет и еще раз нет. Реальная бухгалтерия обслуживает реальный бизнес. А ему надо вести счета, основанные на проводках, не для того, чтобы рассчитывать долю государства, а для того, чтобы этим самым бизнесом оперировать. Я знаю, что говорю, поскольку имел такие заказы. Когда у вас сотня клиентов, у каждого свой мультивалютный счет, а у вас свои внутренние служебные счета, вы не можете оперировать баночкой. 95% времени вы осуществляете переводы в рамках своей финансовой деятельности, а к моменту подготовки налоговой отчетности у вас все эти пачки и пачки счетов суммируются и относятся на несколько позиций из плана. Люди заранее ПРОСИЛИ, чтобы все эти лицевые счета были отмаркированы в целях облегчения дальнейшего суммирования.

Без эмоций, вполне спокойно, я заявляю: то, что вы описываете, это паразитизм. Минфин в роли краба, который лицо закрывает, и личинка чужого в виде собственной бухгалтерии, которая грызет бизнес изнутри. Борьба с безработицей по-русски. Все понятно, но за пределами этих уродливых перекосов жизнь тоже есть.

Опять же, причем тут Лука Пачоли. А чем они все эти века занимались, пока Госплан не выкатил план счетов, интересно?

SV.>>Мир не крутится вокруг СССР. У других, знаете, тоже бывает бухгалтерия, в которой баланс счета — сумма проводок, а не состояние.
S>Совершенно верно. Вот только зачем вы хотите иметь именно счёт с состоянием вместо суммы проводок

?

У счета нет состояния. Он его эмулирует. Я, вроде, не скупился в словах, когда это описывал.

SV.>>Так вот, выше я предложил сделать шорткат на основе дефолтного параметра. Что вы изволили назвать плохим решением. Видимо, с точки зрения "Правильного Дизайна", который вы тут представляете на манер Лебедева. С точки зрения не Дизайна, а Васи, у него есть объект acc, у которого можно нажать точку и посмотреть, что будет. Вывалится список методов, среди которых не будет никакого CurrentBalance. А будет CalcBalance(Date forDate = Date.Now).
S>Нет, вы предлагали именно CalcCurrentBalance() — все ходы записаны. Далее, по вашим словам, мне совершенно непонятно, откуда это у Васи вдруг возьмётся объект acc, у которого можно нажать точку и посмотреть, что там выпадет.

Это я сначала предложил CalcCurrentBalance(). А уже потом развил свою мысль до CalcBalance(Date forDate = Date.Now). Дорогу, тыскызыть, осиливает идущий. Но я не настаиваю, пусть будет CalcCurrentBalance() и CalcBalance(Date forDate). Это все равно несравненно лучше суммирования проводок везде, где нужен баланс.

Откуда у Васи acc — как откуда? От AccountingService'а. Как он достукивается до сериса — это платформозависимые вещи. Если Вася пишет плагин (допустим, вебпарт), то и ссылку получает на входе. Если пишет standalone-страницу, просто обращается к сервису и получает у него интерфейс. Затем — что-то типа:

var acc = theService.GetAccountByReportIdentifier('78.01');

S>Сопли, простите, поскипаны. Если вы хотите что-то написать — пишите по делу. А не драму про Васю, который, оказывается, с самого начала ничего не знает, зато каким-то волшебным образом всё узнаёт. И про Синклера, который сначана всё знает, а потом почему-то стремительно тупеет.

Вася этот сидит у меня за спиной сейчас. Только зовут его Катя. Все взято с натуры.

Дальше, а почему Синклер тупеет? Цель была показать, что имплементация полна сюрпризов, а вы от них ограждены. Можете подставить СВ. Я люблю, когда ОМ скрывает от меня реализацию на первых порах и тупым себя по этой причине не считаю. Если и считаю, то не по этой. Главное, чтобы она (ОМ) по мере "врубания" и роста хотелок не становилась гирей на ногах, как это случилось с ShP OM.

SV.>>Гуёвый программист не занимается порождением объектной модели. Он отдает 78.01 в метод хелперного объекта AccountingService, и получает объект Account, который можно изучать через IDE. Оба они, AccountingService и Account, а также все реализации Account, описанные выше, являются частью объектной модели, создавать которую (и упаковывая реализацию в которую) дело архитектора.
S>Вопрос: зачем гуёвому программисту этот объект Account?
S>Что мешает ему сразу вызвать метод AccountingService.CalcBalance(...)?

А вот ЭТО и будет нарушением SRP, о котором столько говорилось. По сути, будет одна большая общая куча функций. Что-то типа WinAPI. Словами не передать, как я ненавижу изучать такие API.

S>Сколько разных реализаций вы себе представляете у класса Account?

Я привел пример с двумя реализациями: "реального" счета, то есть, счета, который пасется на базе, и агрегирующего счета, который агрегирует "реальные" счета по заданному признаку. Но это, подчеркиваю, не обязательно. Даже если у вас одна реализация, не надо свинячить и пихать в AccountingService everything and kitchen sink.

SV.>>Вы не читаете, что ли? Я же сказал: это зависит от точки зрения дизайнера на responsibility. Если думать о responsibility в терминах "функциональность по расчёту баланса", "функциональность по работе с базой" — тогда да, это нарушение SRP. Если считать responsibility этого класса "предоставить Васе доступ к балансам", тогда нет. Вот когда Account начнет заодно курсы валют возвращать, тогда это будет нарушение SRP.
S>Непонятно, где вы проводите границу responsibility. У классиков — всё понятно. Границы responsibility проходят там, где проходят разные причины для изменений. А с вашим подходом запихать вообще всё в функцию main — нормально, потому что ответственность программы это "сделать всё".

Про классиков я не знаю. Можете показать, что надо прочитать и соотнести — я прочитаю и соотнесу.

Запихать вообще всё в функцию main — НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать что? Декомпозируйте.

S>Я же вам привёл пример: сменили структуру базы или заменили хранилище — поправили код в одном месте. А у вас придётся править Account, Transaction, а то и всяких Person и прочих "активных классов", которые слишком много знают о доступе в базу.

SV.>>Еще раз. Вы просто не ставите такой задачи, которую решает ООП, допустим, в том же самом MS ShP.
S>Возможно, возможно. Я не говорю, что ООП вообще не нужно. Но в подавляющем большинстве софта для масс-процессинга ООП — это оверкилл. А бухгалтерия — это типичный пример масс-процессинга, где проводок — сотни и тысячи.

В реальности, вы же знаете, люди пишут код без комментов и переменные называют однобуквенными именами, чтоб с работы не выгнали. В подавляющем большинстве мест, я подозреваю. Какой тут ООП. Но если вы, допустим, архитектор и совладелец?

Про сотни и тысячи я не понял. Да хоть миллионы. ООП же не роняет производительность сама по себе.

Здравствуйте, Sinclair, Вы писали:

SV.>>Если вы в самом деле это понимаете, как у вас рука поворачивается написать: "Для этого нет необходимости в ООП"? Да, для этого нет необходимости в ООП. ЕЕ ВООБЩЕ НИКОГДА НЕТ. БЕЗ ООП ВСЕГДА МОЖНО ОБОЙТИСЬ. ОНО ОБХОДИМО.
S>Хорошо. Напишем тогда так: преимущества у ООП — нету.

SV.>>Покажите, где и как будут реализованы хранение и вычисление, чтобы мы могли сравнить стоимость отладки. Нет, не кода, который хранит и вычисляет, а кода, который будет написан для расчета линейных уравнений на его основе. И не надо писать "в операциях, заданных над этим ADT". Это не значит НИЧЕГО. Конкретизируйте. Я, если угодно, сделаю то же для ООП. Не сделал только потому, что верю, что все и так представляют, как это будет выглядеть.
S>А код для расчёта линейных уравнений так и будет написан, как учили в унивеситете.
S>Ну, вот для квадратных уравнений мы будем иметь
S>

S>D = b*b - 4*a*c;
S>x1 = (-b - Sqrt(D)) / (2 * a);
S>x2 = (-b + Sqrt(D)) / (2 * a);
S>

S>Дальщше что?

Нет, надо было мне написать код, все же.

class HighPrecisionNumber
{
    public HighPrecisionNumber(decimal source) { ... }
    public HighPrecisionNumber(string source) { ... }
    public HighPrecisionNumber(byte[] bin) { ... }
...
    public static operator +(HighPrecisionNumber n1, n2) { ... }
...
    public string ToString() { ... }
    public byte[] ToArray() { ... }
...
    public Precision { get { ... }; set { ... };
...
    private T data;
}

Вот когда такой классец у вас написан, его как черный ящик можно дергать хоть откуда, особо ни о чем не заботясь.

void ResolveSqEq(HighPrecisionNumber a, HighPrecisionNumber b, HighPrecisionNumber c,
                 ref HighPrecisionNumber x1, ref HighPrecisionNumber x2)
{
    var D = b * b - new HighPrecisionNumber(4) * a * c;
    var minusB = new HighPrecisionNumber(-1) * b;
    var a2 = new HighPrecisionNumber(2) * a;
    x1 = (minusB - D.Sqrt()) / a2;
    x2 = (minusB + D.Sqrt()) / a2;
}

var a = 10500L;
var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
    "578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
    "286583653786537568327856378256237238598978182371283e150";
var c = (byte[]) GetIeee666(d);

var aHpn = new HighPrecisionNumber(a);
var bHpn = new HighPrecisionNumber(b);
var cHpn = new HighPrecisionNumber(c);

a.hPn.Precision = 100;
b.hPn.Precision = 100;
c.hPn.Precision = 100;

HighPrecisionNumber x1, x2;
ResolveSqEq(aT, bT, cT, ref x1, ref x2);

var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
    "вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
    "с небывалой точностью (100 знаков). Он равен: {0)", x1.ToString());

db3000.SaveIeee666(x2.ToArray());

Если мы не заворачиваем конвертации, хранение и расчеты в класс, то где мы их имеем? Во что превратится код без него? Напишите и выложим оба API на голосование. Вот и будет "точная наука".

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, Sinclair, Вы писали:

SV.>Нет, надо было мне написать код, все же.

SV.>

SV.>class HighPrecisionNumber
SV.>

SV.>Вот когда такой классец у вас написан, его как черный ящик можно дергать хоть откуда, особо ни о чем не заботясь.
А теперь представьте что потребовалось решить уравнение с комплексными коэффициентами.

SV.>

SV.>void ResolveSqEq(HighPrecisionNumber a, HighPrecisionNumber b, HighPrecisionNumber c,
SV.>                 ref HighPrecisionNumber x1, ref HighPrecisionNumber x2)
SV.>

SV.>Если мы не заворачиваем конвертации, хранение и расчеты в класс, то где мы их имеем? Во что превратится код без него? Напишите и выложим оба API на голосование. Вот и будет "точная наука".
Точная наука голосованием? До сих пор бы катались в тарелке на спине у слонов.

Здравствуйте, SV., Вы писали:
SV.>Ну как же. Как он смел заниматься бухгалтерией без плана счетов, утвержденных Минфином РФ с его идентификаторами? Ладно, это была шутка. Не обращайте внимания.
Непонятная шутка. Минфин — ни при чём. Даже если это ваша личная бухгалтерия, с именами счетов "левый карман" и "правый карман", ничего не меняется.

SV.>Я имел в виду запись в отдельной таблице с указанием текущего справочника и вхождения в него.
Я вас по-прежнему не понимаю. Вы мыслите в терминах какого-то конкретного решения, а не в терминах задачи. При чём тут справочник? Справочник можно построить на ходу, просто сделав select distinct sourceAccount from transactions.

SV.>Один простой вопрос. Как вы в этой системе будете вести лицевые счета? Они не видны в отчете, но видны операционисту.
Точно так же.

Математика никак не меняется.
SV.>А я и не говорю про ООП. Я переключился на уникальные искусственные идентификаторы счета, которые (не) нужны.
Отлично. Я по прежнему не понимаю, для чего вам суррогатные ключи.

SV.>Вот опять мы говорим не про ООП. И опять я скажу, что тут шайбочкой не обойтись.
Беллетристика поскипана. Не имеет отношения к делу.

SV.>Что эти немного абстрактные рассуждения значат применительно к ООП и счетам? Я делаю утверждение, основанное на наблюдениях, а не на какой-то там мифической науке: никто не любит писать объектные модели, но все очень любят ими пользоваться, поскольку они снижают порог вхождения.
О, вот теперь мы подошли к сути. Наконец-то вы делаете хоть какое-то утверждение, которое можно обсуждать.

SV.>Я делаю второе утверждение — нет, и не может быть никакой науки, чтобы доказать или опровергнуть первое утверждение.

То есть мы резко перешли к религии. Порог, по-вашему, существует, но измерить его невозможно.
Простите, но на этом нам придётся дискуссию свернуть. Потому что иначе мне придётся в ответ заявить, что анемичные модели имеют по сравнению с объектными моделями значительно более высокую аладибобберность, которая крайне важна, но измерить её научным методом невозможно.

SV.>Нет, нет и еще раз нет. Реальная бухгалтерия обслуживает реальный бизнес.
Вы сейчас смешиваете бухгалтерский учёт и финансовый учёт. Это во-первых.
Во-вторых, финансовый учёт точно так же не работает ни с какими "обьектами", у которых бы было состояние и поведение.

SV.>Без эмоций, вполне спокойно, я заявляю:
Мнение по поводу нужности бухучёта отправлено в дев/нулл как нерелевантное к теме топика.
SV.>Опять же, причем тут Лука Пачоли. А чем они все эти века занимались, пока Госплан не выкатил план счетов, интересно?
Неужели отправляли сообщения объектам?
А, нет — записывали проводки в гроссбухи, и готовили отчёты.

SV.>У счета нет состояния. Он его эмулирует. Я, вроде, не скупился в словах, когда это описывал.
Отлично. То есть на самом деле объекта нет, есть некая эмуляция. "Состояние" объекта меняется не в результате взаимодействия с ним других объектов, а в результате действий, произошедших в какой-то посторонней части системы. Ок.

SV.>Это я сначала предложил CalcCurrentBalance(). А уже потом развил свою мысль до CalcBalance(Date forDate = Date.Now). Дорогу, тыскызыть, осиливает идущий. Но я не настаиваю, пусть будет CalcCurrentBalance() и CalcBalance(Date forDate). Это все равно несравненно лучше суммирования проводок везде, где нужен баланс.

Непонятно. Вы предлагаете суммировать проводки везде, где нужен баланс. Но при этом это почему-то лучше, чем суммировать проводки везде, где нужен баланс. По-моему, вы спорите с голосами в голове.

SV.>Откуда у Васи acc — как откуда? От AccountingService'а. Как он достукивается до сериса — это платформозависимые вещи. Если Вася пишет плагин (допустим, вебпарт), то и ссылку получает на входе. Если пишет standalone-страницу, просто обращается к сервису и получает у него интерфейс. Затем — что-то типа:

SV.>

SV.>var acc = theService.GetAccountByReportIdentifier('78.01');
SV.>

О, отлично. То есть вы предлагаете Васе писать код вот так:

var acc = theService.GetAccountByReportIdentifier('78.01');
var balance = acc.CalcBalance();

Да?
И полагаете, что ему это понятнее и удобнее, чем делать всё в одну строчку:

var acc = theService.GetBalance('78.01');

?
Простите, такие смелые утверждения нужно как-то обосновывать.

SV.>Вася этот сидит у меня за спиной сейчас. Только зовут его Катя. Все взято с натуры.

SV.>Дальше, а почему Синклер тупеет? Цель была показать, что имплементация полна сюрпризов, а вы от них ограждены. Можете подставить СВ. Я люблю, когда ОМ скрывает от меня реализацию на первых порах и тупым себя по этой причине не считаю.
Если и считаю, то не по этой. Главное, чтобы она (ОМ) по мере "врубания" и роста хотелок не становилась гирей на ногах, как это случилось с ShP OM.

Рич-модель практически всегда становится рано или поздно гирей на ногах. Увы.

SV.>А вот ЭТО и будет нарушением SRP, о котором столько говорилось.
С чего бы это вдруг? Обоснуйте своё утверждение.

SV.>По сути, будет одна большая общая куча функций. Что-то типа WinAPI. Словами не передать, как я ненавижу изучать такие API.
С чего это вы взяли? Вы почему-то думаете, что если вы эту кучу функций засунете в класс Account и заставите порождать его экземпляры на каждый чих, то всё станет понятнее. Я не вижу никаких к этому причин.
Вот как я себе представляю "объектную" модель:

var acc1 = accountingService.GetAccount('78.01');
var acc2 = accountingService.GetAccount('62.03');
var transaction = accountingService.NewTransaction(acc1, acc2, amount);
accountingService.Commit();

Видим четыре объекта, четыре метода.
Вот как бы выглядела анемичная модель:

var result = accountingService.NewTransaction('78.01', '62.03', amount)

Один объект, один метод.

S>>Сколько разных реализаций вы себе представляете у класса Account?

SV.>Я привел пример с двумя реализациями: "реального" счета, то есть, счета, который пасется на базе, и агрегирующего счета, который агрегирует "реальные" счета по заданному признаку.

К сожалению, они не являются взаимозаменяемыми. Я не могу сделать перевод с агрегирующего счёта, не указав, какой "реальный" счёт мне нужен. То есть весь полиморфизм у вас — внутри CalcBalance, а точнее — внутри того метода, который выбирает проводки для суммирования. Ну так и выполняйте декомпозицию по этой границе.

Но это, подчеркиваю, не обязательно. Даже если у вас одна реализация, не надо свинячить и пихать в AccountingService everything and kitchen sink.
А что вы называете Everything? Простите, но API AccountingService будет практически 1:1 совпадать c API класса Account.

SV.>Про классиков я не знаю. Можете показать, что надо прочитать и соотнести — я прочитаю и соотнесу.

SV.>Запихать вообще всё в функцию main — НЕнормально, как раз потому, что ответственность нельзя описать словами "сделать всё". Сделать что? Декомпозируйте.

SV.>В реальности, вы же знаете, люди пишут код без комментов и переменные называют однобуквенными именами, чтоб с работы не выгнали. В подавляющем большинстве мест, я подозреваю. Какой тут ООП. Но если вы, допустим, архитектор и совладелец?
То я буду вводить только те объекты, которые обладают поведением. У AccountingService поведение есть.
У Account — нету. Account — это всего лишь строчка '78.01'. Вся политика по поводу того, куда и что можно переводить, а куда нельзя, реализована снаружи Account. Это сегодня нельзя, а завтра — можно. И вообще можно всегда, вопрос только в том, будет ли результирующая отчётность устраивать ограничениям или нет.

SV.>Про сотни и тысячи я не понял. Да хоть миллионы. ООП же не роняет производительность сама по себе.

Вернитесь к тому месту в разговоре, где вы рассказывали про вашу борьбу с прямыми запросами к базе в ShP. Зачем вы это делали, если производительности чистого ООП самого по себе хватало?

Здравствуйте, SV., Вы писали:

SV.>Вот когда такой классец у вас написан, его как черный ящик можно дергать хоть откуда, особо ни о чем не заботясь.

SV.>

SV.>void ResolveSqEq(HighPrecisionNumber a, HighPrecisionNumber b, HighPrecisionNumber c,
SV.>                 ref HighPrecisionNumber x1, ref HighPrecisionNumber x2)
SV.>{
SV.>    var D = b * b - new HighPrecisionNumber(4) * a * c;
SV.>    var minusB = new HighPrecisionNumber(-1) * b;
SV.>    var a2 = new HighPrecisionNumber(2) * a;
SV.>    x1 = (minusB - D.Sqrt()) / a2;
SV.>    x2 = (minusB + D.Sqrt()) / a2;
SV.>}

SV.>var a = 10500L;
SV.>var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
SV.>    "578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
SV.>    "286583653786537568327856378256237238598978182371283e150";
SV.>var c = (byte[]) GetIeee666(d);

SV.>var aHpn = new HighPrecisionNumber(a);
SV.>var bHpn = new HighPrecisionNumber(b);
SV.>var cHpn = new HighPrecisionNumber(c);

SV.>a.hPn.Precision = 100;
SV.>b.hPn.Precision = 100;
SV.>c.hPn.Precision = 100;

SV.>HighPrecisionNumber x1, x2;
SV.>ResolveSqEq(aT, bT, cT, ref x1, ref x2);

SV.>var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
SV.>    "вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
SV.>    "с небывалой точностью (100 знаков). Он равен: {0)", x1.ToString());

SV.>db3000.SaveIeee666(x2.ToArray());
SV.>

void ResolveSqEq<typename T>(T a, T b, T c,
                 ref T x1, ref T x2)
{
    var D = b * b - new T(4) * a * c;
    var minusB = -b;
    var a2 = 2 * a;
    x1 = (minusB - Sqrt(D)) / a2;
    x2 = (minusB + Sqrt(D)) / a2;
}

var a = 10500L;
var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
    "578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
    "286583653786537568327856378256237238598978182371283e150";
var c = (byte[]) GetIeee666(d);

var aHpn = HighPrecisionNumber(a, 100);
var bHpn = HighPrecisionNumber(b, 100);
var cHpn = HighPrecisionNumber(c, 100);

HighPrecisionNumber x1, x2;
ResolveSqEq(aT, bT, cT, ref x1, ref x2);

var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
    "вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
    "с небывалой точностью (100 знаков). Он равен: {0)", HighPrecisionNumberToString(x1));

db3000.SaveIeee666(HighPrecisionNumberToIeee666(x2));

Это не C#, а скорее С++ (на котором я писать не рискнул, т.к. отвык от синтаксиса за годы). У шарпа очень объектно-ориентированный механизм биндинга для инфиксных операций. А в С++ этого нет.
Как видим, нам достаточно иметь набор функций, работающих с нашим high-precision number, как бы он ни был представлен.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
S>Гипотеза интересная, но смолток из коробки был построен на сверхпозднем связывании. Экономить они научились уже потом — хотспоттинг и спекулятивные оптимизации были придуманы ровно для него, и уже потом перетащены в джаву.
Я собственно про то как ООП из смолтока переползал на C/Pascal и т.п. Там-то походу и потерялась объектность сообщений.

S>>Отчасти поэтому мы и имеем кучу работы с сингатурами, сложными правилами совместимости и прочим, вплоть до несовместимости Func/Action в C#. В ФП с более накладным применением аргументов все как-то намного проще.
S>Я вижу пока что бурление языков; каждый автор имеет своё представление о том, что и кому нужно. Академики откатывают концепции, практики — прикручивают изолентой то, что может пригодиться. В итоге из паскаля мы имеем академический Оберон (явный научный успех и не менее явный провал в популярности) и практичный Delphi — с кучей посторонних вещей, включая (о, ужас!) динамическую типизацию, но категорически популярный.
Конечно, когда приходится выбирать между удобством работы с функциями и удобством создания приложений под винду, то альтернативы Delphi фактически не было.

SV.>Это называется "понятийное мышление". В норме человек к 5 годам им овладевает в степени, достаточной для повседневного применения.

Ну... императивным мышлением даже животные обладают: "чтобы хозяин меня покормил надо подойти к нему и помяукать". Или, "чтобы поймать мышку надо (1), (2), (3) ..."

А в случае объектов вопрос спорный, лично мне императивное мышление намного ближе и нативнее.

Здравствуйте, vdimas, Вы писали:

I>>Если бы ты читал внимательно, то заметил бы, что эта разница целиком и полностью из за очереди

V>Это личные твои домыслы, из-за чего получилась такая разница. Я ХЗ что и как ты смотрел.

Не мои, а твои

Я то код вижу, а ты — нет.

I>>при том что издержки на GC ничтожны.

V>Т.е., после того, как уже раз 10 я тебя поправил, ты опять говоришь об издержках на выделение памяти в GC?
V>А что мы сейчас вообще обсуждаем, не пояснишь?

Я говорю о времени которое тратит GC относительно издержек на очереди согласно твоей же модели. На тех цифрах что ты выдал издержками на GC можно пренебречь.

I>>Эта разница как раз и натолкнула меня на мысль о том, что твои данные отличаются от реальных минимум на порядок-другой.

V>Меня твоя разница пока натолкнула на две мысли:
V>1. Не понял, что надо в тестах замерять.
V>2. Не знаешь куда смотреть в результатах теста.

Ты выдал нечто вроде: "GC падает навзничь"
Сообщаю — на твоих цифрах все в шоколаде — издержки на GC ничтожны.

I>>Ничего, если я тебе твои слова покажу ?
I>>

I>>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
I>>Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.

V>Именно, а ты как хотел? Любые тесты вокруг ненулевого поколения в GC заведомо нетривиальны.

Конкретно этот тест тривиальный.

Здравствуйте, vdimas, Вы писали:

V>Именно, а ты как хотел? Любые тесты вокруг ненулевого поколения в GC заведомо нетривиальны.

Судя по твоим высказываниям, тривиальный получается из нетривиального путем введения задержек в 1us, так шта дерзай.

Здравствуйте, samius, Вы писали:

SV.>>Вот когда такой классец у вас написан, его как черный ящик можно дергать хоть откуда, особо ни о чем не заботясь.
S>А теперь представьте что потребовалось решить уравнение с комплексными коэффициентами.

Тогда вы наУчите свои числовые обертки не только точности, но и мнимости. Как это конкретно сделать — в смысле, с наследованием реализаций или нет, а если с наследованием, то чего от чего — я с ходу не соображу, поскольку соответствующую математику со второго курса не использовал. Если кто-то поможет, то заранее ему спасибо.

SV.>>Если мы не заворачиваем конвертации, хранение и расчеты в класс, то где мы их имеем? Во что превратится код без него? Напишите и выложим оба API на голосование. Вот и будет "точная наука".
S>Точная наука голосованием? До сих пор бы катались в тарелке на спине у слонов.

Вы видите, что "точная наука" взята в кавычки? Это саркастическая ссылка на "точную науку дизайна", в которую я не верю ни на грамм, из параллельной дискуссии в соседней подветке.

Здравствуйте, Sinclair, Вы писали:

S>Делов-то.

S>

S>void ResolveSqEq<typename T>(T a, T b, T c,
S>                 ref T x1, ref T x2)
S>{
S>    var D = b * b - new T(4) * a * c;
S>    var minusB = -b;
S>    var a2 = 2 * a;
S>    x1 = (minusB - Sqrt(D)) / a2;
S>    x2 = (minusB + Sqrt(D)) / a2;
S>}

Перевод ResolveSqEq в обобщенный вид я (с опозданием) поддерживаю. Это очень правильно. Надеюсь, MTD досюда не дочитает

S>var a = 10500L;
S>var b = "8.4534523450230523053258239859328534534583475834758734857348758934758349753489" +
S>    "578349758349752763423546325463546523465236453624562354623465236546523645623546235463563" +
S>    "286583653786537568327856378256237238598978182371283e150";
S>var c = (byte[]) GetIeee666(d);

S>var aHpn = HighPrecisionNumber(a, 100);
S>var bHpn = HighPrecisionNumber(b, 100);
S>var cHpn = HighPrecisionNumber(c, 100);

S>HighPrecisionNumber x1, x2;
S>ResolveSqEq(aT, bT, cT, ref x1, ref x2);

S>var s = string.Format("Наша группа за отчетный период успешно сосчитала " +
S>    "вакуумный коэффициент коня (это оказался первый корень конно-квадратного уравнения) " +
S>    "с небывалой точностью (100 знаков). Он равен: {0)", HighPrecisionNumberToString(x1));

S>db3000.SaveIeee666(HighPrecisionNumberToIeee666(x2));
S>

S>Это не C#, а скорее С++ (на котором я писать не рискнул, т.к. отвык от синтаксиса за годы). У шарпа очень объектно-ориентированный механизм биндинга для инфиксных операций. А в С++ этого нет.
S>Как видим, нам достаточно иметь набор функций, работающих с нашим high-precision number, как бы он ни был представлен.

А тут я снова ничего не понял. В вашем варианте HighPrecisionNumber — это что? Handle?

Здравствуйте, samius, Вы писали:

S>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

Для ООП нужен объект Вычислитель, который может работать с числами самой разной природы.

Здравствуйте, SV., Вы писали:

SV.>А тут я снова ничего не понял. В вашем варианте HighPrecisionNumber — это что? Handle?
А как раз это — неважно.
Пусть это будет, скажем, ASCIIZ-строка, в которой хранится нужное нам количество цифр.
Или структ из тридцати интов для хранения мантиссы и ещё одного — для экспоненты.
Прикладному коду это совершенно безразлично.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

I>Для ООП нужен объект Вычислитель, который может работать с числами самой разной природы.
Для самой разной природы чисел не нужен. Нужен лишь для той природы, в рамках которой выполняется решение. Для вычислений другой природы подсовывай другой вычислитель.

Здравствуйте, samius, Вы писали:

S>>>А теперь представьте что потребовалось решить уравнение с комплексными коэффициентами.

SV.>>Тогда вы наУчите свои числовые обертки не только точности, но и мнимости. Как это конкретно сделать — в смысле, с наследованием реализаций или нет, а если с наследованием, то чего от чего — я с ходу не соображу, поскольку соответствующую математику со второго курса не использовал. Если кто-то поможет, то заранее ему спасибо.
S>В том и фишка, что хочется работать с разными представлениями одним кодом, а не запихивать в один класс все возможные представления.
S>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

Смотрите. Функция-решатель у меня изначально была отдельной функцией, не входящей ни в какой класс. Просто в силу ее функциональной природы. Про комплексные числа я не подумал, но зато (наверное) подумал Sinclair, и сделал функцию обобщенной. Шучу. Достаточно захотеть иметь обобщенное решение для простых чисел и чисел с повышенной точностью. Ну, еще при имплементации иметь в виду, что унарные операции могут для типа не поддерживаться (я имел). Так вот, с необходимостью обобщить функцию я согласился. Это отвечает на вашу претензию?

Что интересно, для меня обобщение ничего не меняет. Мой класс — способ упаковать различные конвертации и хранение, не дать им расползтись по всему проекту.

SV.>>Вы видите, что "точная наука" взята в кавычки? Это саркастическая ссылка на "точную науку дизайна", в которую я не верю ни на грамм, из параллельной дискуссии в соседней подветке.
S>А в проблемы неудачного дизайна верите?

Если рассматривать проблемы у каких-то конкретных людей — почему нет?

Здравствуйте, Sinclair, Вы писали:

SV.>>А тут я снова ничего не понял. В вашем варианте HighPrecisionNumber — это что? Handle?
S>А как раз это — неважно.
S>Пусть это будет, скажем, ASCIIZ-строка, в которой хранится нужное нам количество цифр.
S>Или структ из тридцати интов для хранения мантиссы и ещё одного — для экспоненты.
S>Прикладному коду это совершенно безразлично.

1. Как узнать все доступные источники данных для преобразования в число высокой точности?
2. Как узнать все доступные форматы, в которые может быть преобразовано число высокой точности?
3. Как явно обозначить, что вы a) запрещаете b) разрешаете юзеру привязываться к текущему формату (чем бы он ни был)? То есть, заключить контракт.

Здравствуйте, SV., Вы писали:

SV.>Здравствуйте, samius, Вы писали:

S>>В том и фишка, что хочется работать с разными представлениями одним кодом, а не запихивать в один класс все возможные представления.
S>>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

SV.>Смотрите. Функция-решатель у меня изначально была отдельной функцией, не входящей ни в какой класс. Просто в силу ее функциональной природы. Про комплексные числа я не подумал, но зато (наверное) подумал Sinclair, и сделал функцию обобщенной. Шучу. Достаточно захотеть иметь обобщенное решение для простых чисел и чисел с повышенной точностью. Ну, еще при имплементации иметь в виду, что унарные операции могут для типа не поддерживаться (я имел). Так вот, с необходимостью обобщить функцию я согласился. Это отвечает на вашу претензию?
Да, вполне

SV.>Что интересно, для меня обобщение ничего не меняет. Мой класс — способ упаковать различные конвертации и хранение, не дать им расползтись по всему проекту.
Это очень непростое по исполнению решение, однако оно традиционно для ООП. Конечно, оно не из лучших традиций. Не говоря уж о том, что единый класс для хранения любых данных — это малопроизводительное решение, так еще и ослабление типизации со всеми вытекающими. А бывает что в рамках такого решения еще и комбинаторный взрыв реализаций опираций устраивают.

S>>А в проблемы неудачного дизайна верите?

SV.>Если рассматривать проблемы у каких-то конкретных людей — почему нет?
Конечно же у людей. Компьютеру до фонаря на дизайн.

Здравствуйте, samius, Вы писали:

S>>>По идее, обобщенный метод — это скорее ФП решение. А для ООП нужно городить INumber и учить его складываться, умножаться и т.п. с самим собой. Либо вводить INumberArithmetic, который будет оперировать INumber-ами.

I>>Для ООП нужен объект Вычислитель, который может работать с числами самой разной природы.
S>Для самой разной природы чисел не нужен. Нужен лишь для той природы, в рамках которой выполняется решение. Для вычислений другой природы подсовывай другой вычислитель.

Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Для ООП нужен объект Вычислитель, который может работать с числами самой разной природы.
S>>Для самой разной природы чисел не нужен. Нужен лишь для той природы, в рамках которой выполняется решение. Для вычислений другой природы подсовывай другой вычислитель.

I>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

Здравствуйте, SV., Вы писали:
SV.>1. Как узнать все доступные источники данных для преобразования в число высокой точности?
Нет такого понятия, как "закрытый список источников данных для преобразования в число высокой точности".
Есть набор несвязанных между собой функций, которые преобразуют всякие разные "числа" в числа высокой точности.
Если меня что-то не устраивает в "заводской" версии библиотеки, то я просто пишу свою функцию HighPrecisionNumberFromBase64String() и не парюсь.
SV.>2. Как узнать все доступные форматы, в которые может быть преобразовано число высокой точности?
Нет такого понятия, как "закрытый список доступных форматов, в которые может быть преобразовано число высокой точности".
Есть набор несвязанных между собой функций, которые преобразуют числа высокой точности во всякие разные полезные форматы.
Если меня что-то не устраивает в "заводской" версии библиотеки, то я просто пишу свою функцию HighPrecisionNumberToRomanNumerals() и не парюсь.
SV.>3. Как явно обозначить, что вы a) запрещаете b) разрешаете юзеру привязываться к текущему формату (чем бы он ни был)? То есть, заключить контракт.
Не очень понимаю, чего вы хотите "обозначить". У меня задача — решить квадратное уравнение. Решателю уравнений совершенно наплевать на формат. Всё, что ему нужно — несколько функций с известными сигнатурами. (конкретно — унарный минус; бинарный минус; умножение; умножение на целое; деление; извлечение квадратного корня).

Здравствуйте, SV., Вы писали:
SV.>Смотрите. Функция-решатель у меня изначально была отдельной функцией, не входящей ни в какой класс. Просто в силу ее функциональной природы.
Ага. То есть здесь нестерпимого желания запихать решение уравнений внутрь класса нет. Причём ни внутрь класса-"числа", ни внутрь класса-"решателя".

SV.>Про комплексные числа я не подумал, но зато (наверное) подумал Sinclair, и сделал функцию обобщенной.
Ага. А ещё я подумал про октонионы и квадратные матрицы. И вообще про все "числа", над которыми определены те операции, которые нужны мне для решения задачи.

SV.>Шучу. Достаточно захотеть иметь обобщенное решение для простых чисел и чисел с повышенной точностью. Ну, еще при имплементации иметь в виду, что унарные операции могут для типа не поддерживаться (я имел).
Ну, вот тут, кстати, уже начинаются интересные моменты. Я сходу не скажу, нужны ли здесь унарные операции, или их можно выразить через умножение на -1? Нужно ли эту -1 приводить к типу данных и использовать умножение (моёчисло, моёчисло), или нужно требовать умножения (целое, моёчисло)? Нужно ли требовать оператора вычитания, или достаточно опять-таки умножения на -1 и сложения?

Наверное, на все эти вопросы можно ответить по недолгому размышлению. А я туплю оттого, что я не теоретик математики, и, честно говоря, вывести решение квадратного уравнения не умею.

SV.>Что интересно, для меня обобщение ничего не меняет. Мой класс — способ упаковать различные конвертации и хранение, не дать им расползтись по всему проекту.
О, а вот здесь вы уже хотите упаковывать методы в класс.
Я подозреваю, что вы этого хотите исключительно с целью "снижения порога вхождения". Хотя с точки зрения изучения ваш класс фактически играет роль пространства имён. С точки зрения мейнстримных синтаксисов, совершенно неважно, во что именно резолвится HighPrecisionMath в цепочке Com::SV::Math::HighPrecisionMath — в класс или в namespace.

А я бы хотел этого (если бы хотел) с точки зрения контрактности. То есть мы можем понимать, что бывают "числа", подразумевающие только сложение, а бывают — ещё и умножение. Что у векторов умножения ажно два, и оба — коммутативные.

И вот тут у нас есть искушение ввести некую иерархию "умножателей и складывателей".
Впрочем, отложим пока арифметику. Сосредоточимся на том, как "упаковать различные конвертации и хранение".
Вот смотрите, допустим, у нас есть тип HighPrecisionNumber. Для него мы определелили набор методов-конвертеров. Скажем, для простоты, между HighPrecisionNumber и double.
Теперь встаёт вопрос: где разместить эти методы? В "экземпляре" HighPrecisionNumber, или во внешнем утилитном классе?
Размещение во внешнем классе позволяет нам делать интересные трюки с наследованием.
Например, мы хотим расширить чужую библиотеку по работе с этими числами, чтобы конвертер умел конвертировать число ещё и в Ieee666.
Если у нас методы расположены во внешнем классе HighPrecisionConversions, то мы можем от него отнаследоваться и добавить пару новых методов. Это позволит нам инстанцировать наш класс конверсий и передавать его везде, где требовался предок.
А если методы были расположены "внутри" HighPrecisionNumber, то мы огребём. Наследоваться от него нельзя — все функции по работе с HighPrecisionNumber возвращают HighPrecisionNumber, а вовсе не нашего потомка.
Так что даже если LSP соблюдён, то попытка скормить пару HighPrecisionNumberDerived в существующий operator + приведёт лишь к возврату HighPrecisionNumber — значения.
Именно поэтому в C# нам придётся перереализовать все операторы и методы для нового типа. Это многословно и неудобно.

Аналогичные проблемы возникают везде, где мы пытаемся "всунуть" внутрь классов "внешнее" поведение.

Здравствуйте, samius, Вы писали:

I>>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
S>Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

Этот "вычислитель" требует ООП, а не уравнения.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Нужен, и это будет проще чем городить INumber и тд. "другой вычислитель" — вычислитель может быть полиморфным, тебя это смущает ?
S>>Тебе может нужен, а для решения уравнения в обобщенном виде — нет.

I>Этот "вычислитель" требует ООП, а не уравнения.
И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

Здравствуйте, samius, Вы писали:

I>>Этот "вычислитель" требует ООП, а не уравнения.
S>И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

В реальном мире числа не умеют складываться, они вообще ничего не умеют

Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
Модель построена. Теперь надо перегнать её в код.
Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Этот "вычислитель" требует ООП, а не уравнения.
S>>И в каком же месте ООП требует единый вычислитель для работы с числами самой разной природы, особенно если задача его не требует?

I>В реальном мире числа не умеют складываться, они вообще ничего не умеют

I>Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
I>Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
I>Модель построена. Теперь надо перегнать её в код.
I>Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

Здравствуйте, samius, Вы писали:

I>>В реальном мире числа не умеют складываться, они вообще ничего не умеют

I>>Хочешь проверить — напиши на бумажке числа и пусть они суммируются, только ты никак им не помогай.
I>>Когда надоест ждать, сделай всё сам и запиши все свои действия которые тебе надо сделать что бы рядом с числами появилась сумма.
I>>Модель построена. Теперь надо перегнать её в код.
I>>Все эти действия на бумажке офрмляем в виде класса Сумматор, задаёшь интерфейс, контракт и дело в шляпе — модель переведена в код согласно ООП.

S>А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>А теперь ближе к сути вопроса. Каким местом ООП требует вычислитель для работы с числами самой разной природы, и почему недостаточно вычислителя для работы с числами совершенно конкретной приорды?

I>Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

Так откуда вытекает требование?

Здравствуйте, Sinclair, Вы писали:

S>Ну, вот тут, кстати, уже начинаются интересные моменты. Я сходу не скажу, нужны ли здесь унарные операции, или их можно выразить через умножение на -1? Нужно ли эту -1 приводить к типу данных и использовать умножение (моёчисло, моёчисло), или нужно требовать умножения (целое, моёчисло)? Нужно ли требовать оператора вычитания, или достаточно опять-таки умножения на -1 и сложения?
Смотря для чего вводить реализацию. Для полей — можно и умножать на -1, существование которой гарантировано. Если мы захотим ввести операции над кольцом, то там не факт что -1 является элементом этого кольца (например кольцо четных чисел), но обратный элемент относительно операции сложения обязан быть. Для вычитания достаточно будет сложения и взятия обратного относительно сложения.

S>Наверное, на все эти вопросы можно ответить по недолгому размышлению. А я туплю оттого, что я не теоретик математики, и, честно говоря, вывести решение квадратного уравнения не умею.
вот я тоже немного потупил и воспользовался википедией

M>Подумалось мне что-то... А ведь классическое «висит окно, принимает события» — это классический Erlang

Насколько это ФП — это уже ХЗ

Ну так Эрланг — это самое ООП и есть. Процессы — объекты, обменивающиеся сообщениями. Applications — компоненты. Releases — приложения/системы. Behaviours — (недо)интерфейсы. OTP-модули — (недо)классы. Но все эти -недо- с лихвой компенсируются рантаймом — он прекрасен

В итоге получаем ФП язык с приемлимыми средствами струкрурирования на макро-уровне и отличной VM.

Здравствуйте, Ikemefula, Вы писали:

V>>Если бы ты понимал, где свободные переменные, а где связанные, ты бы понимал, где когда и сколько вызовов надо произвести. Реально на каждое замыкание со свободными переменными по одному вызову. То бишь замыкание легко заменяется процедурой. Собсно, именно это от меня и требовалось.

I>Ты утверждаешь выше, что тебе на все случаи не нужно писать разные версии этой процедуры. А я утрвеждаю, что надо.

Тогда ты не читал или не понял моих примеров. Не желаешь их верифицировать на предмет семантики происходящего?
Я тебе специально оставляю своё цитирование — в нем ключ для понимания.

I>И это уже проблема, даже без того, что надо еще и структуры и связывание описывать.

Проблема может быть только от непонимания собственного кода. Ты привел некий код и даже не понимаешь как он работает. Вернее так — ты настаиваешь, что имеешь право не понимать, как работает твой код, потому что "пусть всё будет само". Стремный подход, как по мне.

V>>А замыкание без свободных переменных можно реализовывать как часть вышестоящих замыканий (процедур) без изменения семантики. То бишь, в реальном коде одной процедурой можно заменить сразу несколько замыканий.
I>Ну да и разбираться где в каком случае надо создавать новые экземляры, а где реюзать контекст.

Гы-гы 2 раза. Вот это жжешь...
Понимаешь... Вернее наоборот — если ты этих вещей не понимаешь (ну не приучен твой мозжечек читать код на автомате), то твои творения — претендент №1 на мильон фейерических нежданчиков, сопровождающих автоматический захват контекста по мутабельным переменным.

I>Я дал три примера, ты их скипнул. Попробуй предложить хотя бы похожий аналог...

Я тебе расписал уже два твоих примера. До тех пор, пока ты не буешь в состоянии полноценно верифиицировать первых два, двигаться дальше нет никакого смысла. Для тебя уж точно. А для меня — тем более, ведь я уже начинаю повторяться. Техника-то одна и та же.

Там, кстате, кое-какая семантика изменена в моих примерах. Ты и этого не увидел. Но она не относится к ФП/ПП, а сугубо по прикладной части, т.к. интерфейс для сортировок в дотнете безбожно кривой... За верту несет индусятиной.

V>>Гы, у меня-то как раз даже ф-ию сортировки протянуть не проблема через Fn, а у тебя надо всё раздезайнить заново.
I>Мне как раз все что надо это лямбду поправить. Правка лямбды это уже смена дизайна ? А ты не простой.

Поправка лямбды тебе поможет не всегда из-за ограничений сигнатуры показанного метода для сортировки.

I>Внимательнее читай.
I>>>

I>>>Order(x => operation.Apply(Mask(x)))
I>>>

Внимательней пиши. Тут не видно, что это экземплярный мембер.

I>>>Вот оно, бедствие — Mask это метод того же класса что и Order, а значит тебе надо еще накидать N-структур, то есть пары {SaltedModifier, SomeClass}.

Нет, мне надо связать всего одну доп. переменную — this. Все связаные переменные уйдут в контекст. Кол-во контекстов никак не зависит от кол-ва переменных.

V>>Беда только в голове. Поскольку кол-во замыканий сосвободными переменными у нас не изменилось, то кол-во элементов программы в моем примере не изменится. Изменится тело локальной ф-ии CompareUsingModifier точно так же, как изменился твой локальный код. Вместо sm->Apply(a) будет sm->Apply(Mask(a)).

I>Локальные функции есть во всех языках ? Это новость

Лакальные есть во всех процедурных языках, а что? Это ф-ии, видимые лишь из одной единицы компиляции. То бишь нигде более не объявляемые и никуда не экспортируемые.

I>Замыкания контекстов вдруг перекочевали в процедурное программирование. А ты, не простой.

Нет никаких замыканий в процедурном программировании. Я ручками расписываю то, что у тебя происходит "само". А "само" у тебя происходит исключительно раскладка граблей, бо ты смелО замыкаешь мутабельные данные/объекты, включая this.

I>Локальные функции я так поянял есть во всех процедурных языках ? Это новость

Дык, даже в отце всех процедурных языков — в Фортране.
И если это твой "последний аргумент", то я признаю себя заведомо победителем этого спора.

V>>Да, именно, я руками делаю то, что за тебя делает сахарок. Я это где-то отрицал?
I>Ты отрицаешь наличие преимуществ которые дает эта возможность и пытаешься назвать ООП и ФП процедурным программированием.

Решил приписать мне лишнее? Все посты на месте, можешь освежить.

V>>

V>>в дизайне видна только декомпозиция на составные ф-ии, которая практически полный аналог процедурной декомпозиции (напомню, что процедурный подход допускает декомпозицию на процедуры и ф-ии). Возвращаясь к декомпозиции по замкнутому контексту — этот вид декомпозиции присутствует в подробностях кода, то бишь на уровне дизайна им можно пренебречь.

I>Нет этого аналога, ты демонстрируешь ООП и ФП особенности.

Я демонстрирую то, что утверждал: что твои лямбда-штучки в дизайне не видны, а являются сугубо локальной механикой... Той самой, которую можно заменить на инфраструктуру из нескольких строчек и локальные, опять же, ф-ии.

V>>В общем, если единственно за что ты меня ругаешь, что где-то глубоко в подробностях кода у меня будет не так посахарено как у тебя, то большое спасибо, это означает полное и бесповоротное согласие с моей точкой зрения.

I>Ты демонстрируешь ООП и ФП а не процедурное программирование.

Мне виднее, я успел на ПП пописать несколько лет до полноценного переползания на ООП. Реально ООП и ФП используют практические наработки процедурного/структурного программирования, а вовсе не наоборот.

А вообще... Твои рассуждения забавны, надо сказать... В этом есть очередной фан... Думаю, увидев как-нить лампы-триоды и поняв (а вдруг?), как они работают, ты заявишь, что их под чистую слизали с транзисторов.

I>Нет в процедурном тех вещей которые ты использовал в своем коде.

Есть. Просто ты придумал себе несуществующее на свете процедурное программирование, вместо имеющегося в реальности.

V>>Гы-гы-гы... Мож хоть раз с тобой на что-то конкретное поспорить? Ты же даже функциональной декомпозицией не владеешь, пишешь и не понимаешь свой собственный код... Ты даже не понимаешь, что показал мне в скипнутых примерах сценарии использование всего двух (ДВУХ!) базовых комбинаторов.

I>А мы договаривались что я покажу тебе все комбинаторы ? Или ты просто решил намекнуть непойми на что ?

Ты можешь показать что угодно, но 3 базовых комбинатора существуют независимо от тебя. Остальные комбинаторы — производные. И уж мне хватит соображалки выразить любой из них через базовые. Это задача примерно 8-го класса.

I>Ты обещал что покажешь лямбды в процедурном программировании и пока что у тебя примеры ФП и ООП. то есть, тебе просто хочется сменить тему.

ОК, это уже какая-то жалость, а не чтиво. Хреновый из тебя боец. ))
Адью.

Здравствуйте, Ikemefula, Вы писали:

I>Чисто для интереса, это в С++0x или ты имеешь ввиду локальные классы вроде

I>

I>void f()
I>{
I>   int x;
I>   class XXX {
I>      int& x_;
I>   public:
I>      XXX(int& x) : x_(x) {}
I>      void operator()() { ... }
I>   } _xxx(x);

I>   ...
I>}
I>

Так тоже можно и не только в новом С++. Но под локальностью подразумевалось не это, а видимость процедуры/ф-ии из всего проекта.
В пред. посте ответил.

==========
Показанный вариант имеет кое-какие ограничения при использовании его как параметров шаблонов, поэтому в таком виде его не используют. Он подойдет только если объявить в нем статические методы — они и будут те самые локальные ф-ии, которые придется связывать с аргументами посредством заранее объявленного шаблонного ф-ого типа, например, через boost::bind.

Здравствуйте, samius, Вы писали:

I>>Потому что ООП годится для перевода в код моделей объектов из реального мира, с поведением, блекджеком и шлюхами. Кроме как для поведения ООП наверное ни на что не годится. Потому моделируем поведение. У кого оно есть ? У человека, устройства, механизма и тд. Когда модель готова, дальше дело за ООП — преобразовать модель в код.

S>Так откуда вытекает требование?

Это никакое не требование. ООП всего лишь инструмент для перевода модели в код. Эффективность меряешь сам. ООП здесь ничем не помогает. То есть неэффективная модель может быть переведена в неэффективный код и ООП здесь ни при чем.
Наилучший эффект получается только для моделей из реального мира, с поведением и тд.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>да, ну если так сложно со светом, давай представим мяч, который попал в тебя рикошетом от двери. Ты будешь думать что это дверь послала в тебя мяч? Не, я догадывался что у тебя проблемы с дверьми, но что настолько... Пожалуй мой учитель тут не виноват.

V>Конечно виноват, он не проверил у тебя раздел оптики и взаимодействия элементарных частиц.
V>1. Не существует способа узнать, был ли фотон отражен, или сгенерирован.
V>2. Более того, отраженный фотон не факт, что это тот же самый фотон, который падал на поверхность. Отражение фотона от электрона (а ты видишь 99.9999% отраженных фотонов именно от электронов) описывается как поглощение одного фотона и испускание другого.
Раз "не существует" и "описывается", то лесом твою оптику. В быту двери не испускают свет.

S>>Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

V>Да, я сканирую обстановку, я получаю "информацию". Каждый предмет шлет визуальную информацию непрерывно, до тех пор, пока мы подпитываем их энергией извне — освещаем. Но я получаю эту информацию только тогда, когда я ее запрашиваю — смотрю в нужную сторону. Считай, что объекты постоянно шлют события-фотоны, но я то подписываюсь на эти события, то отписываюсь от них. Цикл подписки на событие и получения информации о событии я уверен, можно рассматривать как "опрос". Собсно, это так по-определению в технике. Например в семантике "опрос датчиков". Датчики регистрируют некий параметр непрерывно, но существуют фазы игнорирования этой информации и фазы опроса. Точно так же состояние объекта можно считать непрерывным генерированием одного и того же события, но мы вправе опросить это состояние (вызвать для опроса некое св-во) только когда нам надо.
Даже с позиций ООП ты нагородил полный бред. Что бы послать сообщение, нужна идентичность. Подписка — это передача идентичности. Выходит что прежде чем предмет начнет высылать тебе информацию, ты должен передать ему свою идентичность. А как ты это сделаешь, если предмет тебе еще не посылал информацию о своем существовании. А широковещательные сообщения это уже не ООП.

V>>>Да, повторно переданная одна и та же информация не изменяет энтропию, увы. Поэтому ленивые программисты поступают с лишней информацией... впрочем, ты уже в курсе как.
S>>Ну вот я и утверждаю что модель далека. А ты решил поспорить.

V>А я утверждал, что в ООП крутить-вертеть любые подробности любых моделей — проще всего. Удобно и дешево.
Только не забывай о задаче. Надо-то было дверь открыть, а ты видишь уже до каких подробностей скатился... Но и там ООП что-то не выруливает пока и к решению тебя не приближает.

V>Совсем чистый язык совсем бесполезен как прикладной. Например, совсем чистые языки док-ва теорем нужны для того, чтобы компилятор сказал — компиллируется или нет программа. Это всё. Но для меня этого бесконечно мало.

Твои проблемы не являются аргументом в споре.

S>>Я уже задолбался писать, почему я спорю и за что. А про зачем столько пишешь — ну мне ведь интересно, куда ты дальше вильнешь.

V>Нет, ты таки не пояснил:
V>

V>Кэй писал что вдохновлялся атомами Лиспа. На самом деле от Лисп-атома до кортежа функций не так далеко.

V>Но ты спорил, когда я поправлял тебя, что бесконечно далеко. Вот мне и любопытно — это что за спор был такой?

Я тебе уже ответил по этому поводу. Отвечу еще раз. То была проходная гипотеза.
V>Скажем так, в последнее время мне хочется определиться, насколько всерьез тебя воспринимать. Сорри за офтоп, но последние примерно пару лет твои посты далеки от былой вдумчивости.
Ты свои посты почитай

У меня по поводу них вопрос о серьезности даже не стоит. Хаскель из СП, подписка на получение фотонов... Жги еще!

S>>Слушай, ну концепция-то одна на все — мешок указателей на функции. Только от мешка до ООП далеко еще.

V>Вооот. "Мешок". Т.е. "нечто", собраное воедино и относящееся к одному и тому же... )))
тупл
V>Понимаешь... Если обмен сообщениями рассматривать как обмен информацией (а оно именно так), то ничуть не далеко.
Дальше, чем до тайпклассов хаскеля, т.к. там даже понятие сообщения не нужно. А еще не нужна идентичность, поведение и т.п.

Здравствуйте, samius, Вы писали:

S>Я уже на этот бред отвечал что с дверьми не разговариваю.

http://www.rsdn.ru/forum/test/4843258.1.aspx

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Так откуда вытекает требование?

I>Это никакое не требование. ООП всего лишь инструмент для перевода модели в код. Эффективность меряешь сам. ООП здесь ничем не помогает. То есть неэффективная модель может быть переведена в неэффективный код и ООП здесь ни при чем.
http://www.rsdn.ru/forum/philosophy/4850451.1.aspx

Этот "вычислитель" требует ООП, а не уравнения.

Так значит это все-таки не требование?

I>Наилучший эффект получается только для моделей из реального мира, с поведением и тд.

Здравствуйте, samius, Вы писали:

V>>1. Не существует способа узнать, был ли фотон отражен, или сгенерирован.
V>>2. Более того, отраженный фотон не факт, что это тот же самый фотон, который падал на поверхность. Отражение фотона от электрона (а ты видишь 99.9999% отраженных фотонов именно от электронов) описывается как поглощение одного фотона и испускание другого.

S>Раз "не существует" и "описывается", то лесом твою оптику.

Она не моя. Законы оптики существует независимо от нас с тобой в частности и от человека в общем.

S>В быту двери не испускают свет.

У меня испускает. Лампочка на звонке прямо на двери.
Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.

Ты сам разве не видишь, как далеко ты уже пытаешься убежать от банальных, вообще-то, вещей?

S>>>Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

V>>Да, я сканирую обстановку, я получаю "информацию". Каждый предмет шлет визуальную информацию непрерывно, до тех пор, пока мы подпитываем их энергией извне — освещаем. Но я получаю эту информацию только тогда, когда я ее запрашиваю — смотрю в нужную сторону. Считай, что объекты постоянно шлют события-фотоны, но я то подписываюсь на эти события, то отписываюсь от них. Цикл подписки на событие и получения информации о событии я уверен, можно рассматривать как "опрос". Собсно, это так по-определению в технике. Например в семантике "опрос датчиков". Датчики регистрируют некий параметр непрерывно, но существуют фазы игнорирования этой информации и фазы опроса. Точно так же состояние объекта можно считать непрерывным генерированием одного и того же события, но мы вправе опросить это состояние (вызвать для опроса некое св-во) только когда нам надо.
S>Даже с позиций ООП ты нагородил полный бред.

Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов".

S>Что бы послать сообщение, нужна идентичность. Подписка — это передача идентичности. Выходит что прежде чем предмет начнет высылать тебе информацию, ты должен передать ему свою идентичность.

Опять нет.

S>А как ты это сделаешь, если предмет тебе еще не посылал информацию о своем существовании. А широковещательные сообщения это уже не ООП.

Это отличное ООП, см. мультикаст делегаты. Ведь "адрес" тоже может быть не конкретикой, а абстракцией. Для событий дотнета приемником события является на самом деле мультикаст делегат, то бишь некая "шина", имеющая собственный "адрес". Это полный аналог происходящего в электронике, в которой шина — лишь посредник м/у компонентами, эдакий элемент механики доставки информации. Активный элемент схемы понятия не имеет, кому конкретно он посылает сигналы, их получает любой, подключившийся к шине. В ООП этот паттерн называется mediator и этот паттерн ни разу не вступает в противоречие с ООП. Ровно наоборот — обеспечивает важное кач-во слабой связанности. Собсно, обычная косвенная адресация (переменная ссылочного типа) — это тоже разновидность паттерна mediator. Вот почему простая косвенная адресация имеет такую мощь с т.з. ОО-дизайна (в отличие от ФП) — это же целый нехилый ОО-паттерн.

Аналогично с т.з. оптики адресом фотонов является вектор их распространения. Проводящее свет пространство в таком случае выступает посредником-средой доставки информации.

V>>А я утверждал, что в ООП крутить-вертеть любые подробности любых моделей — проще всего. Удобно и дешево.
S>Только не забывай о задаче. Надо-то было дверь открыть, а ты видишь уже до каких подробностей скатился... Но и там ООП что-то не выруливает пока и к решению тебя не приближает.

А я предупреждал, что на ООП без проблем можно скатиться к любым подробностям. Причем, за счет абстракций ты этого даже можешь не увидеть в статичном публичном АПИ, хотя это вполне может отразиться в динамике происходящего. Необходимый тебе предел подробностей можно задать через ТЗ. Я лишь показываю, насколько у тебя развязаны руки, если брать ООП.

Любые навороты моделирования выходят крайне дешевы... в сравнении с попыткой натянуть на них, например, ФП.

V>>Совсем чистый язык совсем бесполезен как прикладной. Например, совсем чистые языки док-ва теорем нужны для того, чтобы компилятор сказал — компиллируется или нет программа. Это всё. Но для меня этого бесконечно мало.

S>Твои проблемы не являются аргументом в споре.

Являются. На абсолютно чистом языке невозможно написать полезную программу, ведь она не сможет ввод-вывод, то бишь ты никогда даже не узнаешь, запущена она или нет. Это будет фантом, а не программа. ))

V>>Скажем так, в последнее время мне хочется определиться, насколько всерьез тебя воспринимать. Сорри за офтоп, но последние примерно пару лет твои посты далеки от былой вдумчивости.
S>Ты свои посты почитай

У меня по поводу них вопрос о серьезности даже не стоит. Хаскель из СП, подписка на получение фотонов... Жги еще!

Это от непонимания происходящего, от цепляние за догмы как за соломинки. Зачем ты запрещаешь сам себе ставить мысленные эксперименты? )) Смысл?

Я уже говорил, что понимать как и что устроено и откуда растут ноги у тех или иных решений надо всегда. Я не приемлю этой вот манеры заведомо абстрагироваться от происходящего. Это же догматика в чистом виде. Более того, я тебе дал ссылку чуть выше на обсуждение, в том обсуждении показательно то, что умозрительно были выведены некоторые закономерности-ограничения относительно рассматриваемомго примера (параметрический полиморфизм). То бишь, тот факт, что в случае неизвестной на этапе компиляции длины списка тот пример мог быть реализован только в боксированном виде — это уже не просто факт, а некая выведенная закономерность. То бишь, понятие более сильное чем факт, на которое можно полагаться не только в текущей версии компилятора, но и в любой последующей (до тех пор, пока он будет поддерживать параметрический полиморфизм в таком точно виде). Что это дает? Любые такие закономерности позволяют тебе обогащать собственное представление о низлежащей модели, то бишь выходить за рамки изначального упрощенного понимания (догм). Причем, вполне надежно и оправданно — ведь необходимость боксированного представления в том обсуждении была доказана. То бишь, ты можешь располагать при проектировании более подробной моделью, пользуясь всеми её св-вами Вот и всё кино.

Насчет Хаскеля и СП — я ХЗ почему ты там так и не смог ответить аргументированно (и никто не смог), а здесь вспомнил опять.

В энергичной манере исполнения ветвление в ФП было бы полностью аналогично происходящему в СП... То бишь твои аргументы были исключительно о ленивости, которая... оп-па, заведомо не должна влиять на семантику. И этот аргумент ты так и не перепрыгнул... И не перепрыгнешь, ес-но.

V>>Вооот. "Мешок". Т.е. "нечто", собраное воедино и относящееся к одному и тому же... )))
S>тупл

Тупл вполне себе тип. А уж АлгТД — не просто тип, а натуральный абстрактный тип, на котором сидит весь хаскелевский рантайм-полиморфизм.

V>>Понимаешь... Если обмен сообщениями рассматривать как обмен информацией (а оно именно так), то ничуть не далеко.
S>Дальше, чем до тайпклассов хаскеля, т.к. там даже понятие сообщения не нужно. А еще не нужна идентичность, поведение и т.п.

Кому не нужна? Насколько я вижу программы на хаскеле — экземпляр какой-нить монады (не только IO) вполне себе обеспечивает "рамки" некоего вычислительного процесса. А идентичность — это и есть способ отличить одно от другого, расставить те самые "рамки".

Просто здесь (на этом форуме) постоянно идет какая-то путаница, крепко присыпанная догмами. Если нужна идентичность + измененяемое состояние — непременно считается, что это возможно только через мутабельность. Дык, это же в текущей регистровой памяти, где идентичность (грубо) подменяется адресом регистра. Вспомни, ты же сам всегда стараешься уйти от подробностей.

А здесь-то почему убежать не можешь? В координатах, например, ассоциативной памяти, полноценное ООП будет работать поверх иммутабельной низлежащей вычислительной модели. В этом случае мутабельность должна будет эмулироваться примерно так же, как эта мутабельность эмулируется в Хаскеле на State или других трюках. Это именно то, почему создатель Хаскеля признал, что если мы можем эмулировать мутабельность и все связанные с ней эффекты, то нахрена фсё? ))) На самом деле, прикол в том, что в случае Хаскеля у нас получился "двойной слоёный пирог", и более ни в чем.

Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Раз "не существует" и "описывается", то лесом твою оптику.

V>Она не моя. Законы оптики существует независимо от нас с тобой в частности и от человека в общем.
В том числе поэтому давай ты не будешь вписывать в законы идентичность получателя фотона

S>>В быту двери не испускают свет.

V>У меня испускает. Лампочка на звонке прямо на двери.
Ты добрался в тонкостях до фотонов и тут же перестаешь отличать дверь от лампочки. Толсто.

V>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.

V>Ты сам разве не видишь, как далеко ты уже пытаешься убежать от банальных, вообще-то, вещей?

Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

S>>>>Слушай, а ты машину водишь? И вообще, когда смотришь, фокусируешься на всем подряд и спрашиваешь каждую вещь, видишь ли ты ее?

S>>Даже с позиций ООП ты нагородил полный бред.

V>Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов".

Необоснован твой абзац с подпиской на фотоны. По поводу концепции "непрерывного генерирования сигналов", то если ты говоришь о фотонах, а не о волне, то ничего непрерывного в той концепции нет.

S>>Что бы послать сообщение, нужна идентичность. Подписка — это передача идентичности. Выходит что прежде чем предмет начнет высылать тебе информацию, ты должен передать ему свою идентичность.

V>Опять нет.
Что нет? Не натягивается?

S>>А как ты это сделаешь, если предмет тебе еще не посылал информацию о своем существовании. А широковещательные сообщения это уже не ООП.

V>Это отличное ООП, см. мультикаст делегаты. Ведь "адрес" тоже может быть не конкретикой, а абстракцией. Для событий дотнета приемником события является на самом деле мультикаст делегат, то бишь некая "шина", имеющая собственный "адрес".
Мультикаст делегат является собственно объектом с конкретной идентичностью, и посылает он сообщения объектам с конкретной идентичностью. Разве что не только объектам. И ничего широковещательного аки в эфире в мултикаст делегате нет. Медиатор тоже не в тему, т.к. имеет конкретный адрес.

V>Аналогично с т.з. оптики адресом фотонов является вектор их распространения. Проводящее свет пространство в таком случае выступает посредником-средой доставки информации.
Расскажи теперь как твой глаз подписывается на сообщения от всевозможных векторов, входящих в него.

V>А я предупреждал, что на ООП без проблем можно скатиться к любым подробностям. Причем, за счет абстракций ты этого даже можешь не увидеть в статичном публичном АПИ, хотя это вполне может отразиться в динамике происходящего. Необходимый тебе предел подробностей можно задать через ТЗ. Я лишь показываю, насколько у тебя развязаны руки, если брать ООП.

Любые навороты моделирования выходят крайне дешевы... в сравнении с попыткой натянуть на них, например, ФП.
Я знаю что развязаны, я выступаю против того что ООП естественным образом отражает мир.

S>>Твои проблемы не являются аргументом в споре.

V>Являются. На абсолютно чистом языке невозможно написать полезную программу, ведь она не сможет ввод-вывод, то бишь ты никогда даже не узнаешь, запущена она или нет. Это будет фантом, а не программа. ))
Ты от исходного тезиса отклонился уже на 120 градусов. И напомню, хаскель все еще считается чистым языком общего назначения.

S>>Ты свои посты почитай

У меня по поводу них вопрос о серьезности даже не стоит. Хаскель из СП, подписка на получение фотонов... Жги еще!

V>Это от непонимания происходящего, от цепляние за догмы как за соломинки. Зачем ты запрещаешь сам себе ставить мысленные эксперименты? )) Смысл?
Разве же запрещаю? Я просто не делаю из них очень резкие выводы, как у тебя.

V>Я уже говорил, что понимать как и что устроено и откуда растут ноги у тех или иных решений надо всегда. Я не приемлю этой вот манеры заведомо абстрагироваться от происходящего. Это же догматика в чистом виде. Более того, я тебе дал ссылку чуть выше на обсуждение, в том обсуждении показательно то, что умозрительно были выведены некоторые закономерности-ограничения относительно рассматриваемомго примера (параметрический полиморфизм). То бишь, тот факт, что в случае неизвестной на этапе компиляции длины списка тот пример мог быть реализован только в боксированном виде — это уже не просто факт, а некая выведенная закономерность. То бишь, понятие более сильное чем факт, на которое можно полагаться не только в текущей версии компилятора, но и в любой последующей (до тех пор, пока он будет поддерживать параметрический полиморфизм в таком точно виде). Что это дает? Любые такие закономерности позволяют тебе обогащать собственное представление о низлежащей модели, то бишь выходить за рамки изначального упрощенного понимания (догм). Причем, вполне надежно и оправданно — ведь необходимость боксированного представления в том обсуждении была доказана. То бишь, ты можешь располагать при проектировании более подробной моделью, пользуясь всеми её св-вами Вот и всё кино.
А теперь о связи между боксированным представлением и вытеканием хаскеля из СП. Просим.

V>Насчет Хаскеля и СП — я ХЗ почему ты там так и не смог ответить аргументированно (и никто не смог), а здесь вспомнил опять.

Это ты не смог ничего аргументированного. Точнее все твои аргументы про побочные эффекты разнесли на молекулы. Напомню, что тезис твой, и доказывать его тебе. То что на твой взгляд у оппонентов возникли проблемы с контраргументацией не делает твой тезис истинным.

V>В энергичной манере исполнения ветвление в ФП было бы полностью аналогично происходящему в СП... То бишь твои аргументы были исключительно о ленивости, которая... оп-па, заведомо не должна влиять на семантику. И этот аргумент ты так и не перепрыгнул... И не перепрыгнешь, ес-но.
Я уже отвечал на это, что дело не только в ленивости, а еще и в отсутствии побочных эффектов. Ленивость здесь лишь снимает необходимость особой формы.

V>>>Вооот. "Мешок". Т.е. "нечто", собраное воедино и относящееся к одному и тому же... )))
S>>тупл
V>Тупл вполне себе тип. А уж АлгТД — не просто тип, а натуральный абстрактный тип, на котором сидит весь хаскелевский рантайм-полиморфизм.
А что, типы и в частности туплы это теперь прерогатива ООП?

V>>>Понимаешь... Если обмен сообщениями рассматривать как обмен информацией (а оно именно так), то ничуть не далеко.
S>>Дальше, чем до тайпклассов хаскеля, т.к. там даже понятие сообщения не нужно. А еще не нужна идентичность, поведение и т.п.

V>Кому не нужна? Насколько я вижу программы на хаскеле — экземпляр какой-нить монады (не только IO) вполне себе обеспечивает "рамки" некоего вычислительного процесса. А идентичность — это и есть способ отличить одно от другого, расставить те самые "рамки".
Что за "экземпляр" монады?

V>Просто здесь (на этом форуме) постоянно идет какая-то путаница, крепко присыпанная догмами. Если нужна идентичность + измененяемое состояние — непременно считается, что это возможно только через мутабельность. Дык, это же в текущей регистровой памяти, где идентичность (грубо) подменяется адресом регистра. Вспомни, ты же сам всегда стараешься уйти от подробностей.

А здесь-то почему убежать не можешь? В координатах, например, ассоциативной памяти, полноценное ООП будет работать поверх иммутабельной низлежащей вычислительной модели. В этом случае мутабельность должна будет эмулироваться примерно так же, как эта мутабельность эмулируется в Хаскеле на State или других трюках. Это именно то, почему создатель Хаскеля признал, что если мы можем эмулировать мутабельность и все связанные с ней эффекты, то нахрена фсё? ))) На самом деле, прикол в том, что в случае Хаскеля у нас получился "двойной слоёный пирог", и более ни в чем.
Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать. Так что я не понимаю твоих проблем. Ну это как все равно что писать на эмуляции паскаля через макросы под С++ компилятор.

V>Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира.

во-первых, отличия на поверхности. Код эмуляции будет чистым.
Во-вторых, в возможности эмуляции одного на другом нет ничего нового со времен тезиса Черча-Тьюринга. Если ты хочешь использовать это как аргумент в пользу происхождения хаскеля от СП, то так же можно будет использовать этот же аргумент в пользу происхождения Паскаля от лямбда счисления.

Здравствуйте, -VaS-, Вы писали:

I>>"Не мешает" это не значит, что помогает. Просто порог входа в ООП гораздо ниже в силу того, что ООП можно хорошо изучать на легкодоступных примерах. Даже без книг этот порог берется на раз, если прилагать хоть какие то усилия.

VS>Ты много видел вживую хорошего настоящего ОО кода?

Много.

Здравствуйте, vdimas, Вы писали:

S>>В быту двери не испускают свет.

V>У меня испускает. Лампочка на звонке прямо на двери.

Так дверь испускает свет или лампочка что на двери испускает свет ?

Здравствуйте, vdimas, Вы писали:

V>О чудо, ты наконец попал!

V>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя.

А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно. Говорить о замыканиях в паскале можно лишь с поздних версий. И то это будет уже не паскаль, а делфи.

Здравствуйте, samius, Вы писали:

S>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно. Говорить о замыканиях в паскале можно лишь с поздних версий. И то это будет уже не паскаль, а делфи.

Турбопаскаль уже считать дельфи или еще нет ?

Здравствуйте, samius, Вы писали:

S>>>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно. Говорить о замыканиях в паскале можно лишь с поздних версий. И то это будет уже не паскаль, а делфи.

I>>Турбопаскаль уже считать дельфи или еще нет ?
S>Вообще-то нет. Да и в делфи замыкания появились лишь в 2009-м. Так что без разницы, чем ты будешь считать турбопаскаль.

Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет

program test;
uses crt;
     procedure X(s:string);
               procedure X1;
               begin;
                     WriteLn('X1');
                     WriteLn(s);
               end;
     begin;
           WriteLn('X(s:string)');
           X1;
     end;
begin
ClrScr;
X('test');
end.

вывод

  X(s:string)
  X1
  test

И это, кстати, далеко не всё. наприме в этом турбопаскале можно сделать так


var p:procedure(s:string);

и использовать

p(''); {разработчики посчитали что это too big gun, потому инициализация делается с помощью InLine, по простому p := @X написать не получится.}

Вобщем как ты видишь, Pascal поддерживает замыкания а если на уровне библиотеки то и вовсе ФП

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Турбопаскаль уже считать дельфи или еще нет ?
S>>Вообще-то нет. Да и в делфи замыкания появились лишь в 2009-м. Так что без разницы, чем ты будешь считать турбопаскаль.

I>Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет
Это не замыкание, это вложенная процедура.

I>Вобщем как ты видишь, Pascal поддерживает замыкания а если на уровне библиотеки то и вовсе ФП

Как я вижу, не поддерживает.

Здравствуйте, samius, Вы писали:

I>>Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет
S>Это не замыкание, это вложенная процедура.

Это именно замыкание, а то про что ты говорил в дельфях, это анонимные функции.

Здравствуйте, samius, Вы писали:

I>>>>Вот они, замыкания, в олдскульном турбопаскале которому до дельфи еще много лет
S>>>Это не замыкание, это вложенная процедура.

I>>Это именно замыкание, а то про что ты говорил в дельфях, это анонимные функции.
S>Ты ошибаешься

Покажи недостающую разницу между замыканиями и локальными функциями.

И вправду. Мало людей понимает.

Вот прямо в этой нити люди уже путают наследование интерфейсов с наследованием реализаций.

Читайте, читайте Design Patterns. Ибо если не прочтете — то будете обречены на самостоятельное интуитивное изобретение их же

с годами опыта, конечно

Мыслим мы не объектами (Липперт, конечно, умнейший человек, судя по его комментам в книге Хейлсберга с соавторами, но таки уточню его мысль). Мыслим мы — _паттернами_. И каждый паттерн _зачем-то нужен_, а не _для красоты_.

Взять тот же синглетон. Случаи абъюза этого паттерна просто "для красоты" встречаются постоянно. Хотя у тех же GoF четко написано, зачем он нужен.

И тем не менее самая главная задача архитектуры кода не решается ни ООП, ни метапрограммированием, вообще никакой методологией, кроме вкуса, интуиции и опыта девелопера.

Выглядит она (в упрощенном виде) так: есть 2 похожие задачи, ну, процентов на 90. Писать ли для них две версии кода через копи/паст или включать анализ конкретных (а иногда экзотических) случаев в один и тот же код? понятно, что через if это делать — чудовищно, лучше воткнуть туда Strategy, но когда и как имеет смысл делать такое (да еще и с учетом роадмапа развития продукта и возможном появлении требований на новые фичи вот прям в этом месте) — это, извините, только интуиция.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Мыслим мы не объектами (Липперт, конечно, умнейший человек, судя по его комментам в книге Хейлсберга с соавторами, но таки уточню его мысль). Мыслим мы — _паттернами_. И каждый паттерн _зачем-то нужен_, а не _для красоты_.

Что значит "мыслить паттернами" ?

Здравствуйте, Ikemefula, Вы писали:

S>>Т.е. имеется в виду т.н. "сетевой эффект", да?
I>Я не сильно понимаю этот термин.
Это в маркетинге — нелинейность спроса на товар, вызванная спросом на товар.
Типичный пример — скайп и ему подобные. Любой идиот может написать p2p чатилку; но интерес к ней напрямую зависит от количества уже вступивших туда участников.

Здравствуйте, Ikemefula, Вы писали:

I>Ты смешиваешь разные понятия — первоклассные функции и замыкания.
Чтобы разделить их, достаточно в турбопаскале вернуть из функции X указатель на вложенную в неё функцию X1. А потом попробовать вызвать это "замыкание".

Здравствуйте, samius, Вы писали:

I>>Очевидно, в языке который умеет ПФ , замыкания так же должны поддерживать все сценарии для ПФ.
S>Контрпример — ALGOL 68

Там тоже есть замыкания.

I>>Если язык не поддерживает ПФ, то нет никакой необходимости поддерживать эти сценарии в замыканиях.
S>Замыкание — это техника реализации определенного сценария. В паскале этот сценарий не был реализован до 2009-го года.
I>>В дельфи 2009 появились именно ПФ, ага. Отсюда очевидно, что замыкания обязаны поддерживать эти сценарии.
S>Нет, замыкания лишь способ. Обрати внимание на то что нет языков с замыканием но без возможности возврата функции в качестве результата.
S>http://en.wikipedia.org/wiki/First-class_function#Language_support

Ты шота стал википедией злоупотреблять

Если я отредактирую эту табличку, ты согласишься со мной ?

I>>http://c2.com/cgi/wiki?LexicalClosure

S>То что ты называешь лексическим замыканием в паскале, всего лишь http://en.wikipedia.org/wiki/Lexically_scoped#Lexical_scoping, который распространяется на вложенные функции. Замыкание же позволяет использовать переменные ИЗВНЕ их lexical scope (http://en.wikipedia.org/wiki/Closure_%28computer_science%29)

Это вообще не аргумент, см выше

S>A closure allows a function to access variables outside its immediate lexical scope.

S>Соответственно, раз нет возможности пользоваться переменными извне их lexical scope, то о чем говорить?

Как минимум если нет такой возможности то в принципе невозможно различить.

Вобщем твое мнение мне понятно и я считаю его ошибочным, можешь отдыхать.

Здравствуйте, Sinclair, Вы писали:

I>>Ты смешиваешь разные понятия — первоклассные функции и замыкания.
S>Чтобы разделить их, достаточно в турбопаскале вернуть из функции X указатель на вложенную в неё функцию X1. А потом попробовать вызвать это "замыкание".

В турбопаскале это делается только хаком. Там даже обычную не вложеную функцию нельзя просто так вызвать по указателю.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Очевидно, в языке который умеет ПФ , замыкания так же должны поддерживать все сценарии для ПФ.
S>>Контрпример — ALGOL 68

I>Там тоже есть замыкания.
Интересно, а авторы в курсе?

S>>http://en.wikipedia.org/wiki/First-class_function#Language_support

I>Ты шота стал википедией злоупотреблять

Если я отредактирую эту табличку, ты согласишься со мной ?
Нет, я смотрел и в других источниках тоже. А если поправишь табличку, там есть кому поправить обратно.

S>>То что ты называешь лексическим замыканием в паскале, всего лишь http://en.wikipedia.org/wiki/Lexically_scoped#Lexical_scoping, который распространяется на вложенные функции. Замыкание же позволяет использовать переменные ИЗВНЕ их lexical scope (http://en.wikipedia.org/wiki/Closure_%28computer_science%29)

I>Это вообще не аргумент, см выше

Конечно, а у тебя аргумент, притом что автор той странички не знает, кто добавил паскаль в список языков с замыканиями. Удивительной убедительности аргумент.

S>>Соответственно, раз нет возможности пользоваться переменными извне их lexical scope, то о чем говорить?

I>Как минимум если нет такой возможности то в принципе невозможно различить.

I>Вобщем твое мнение мне понятно и я считаю его ошибочным, можешь отдыхать.
Окей, то что ты мое мнение считаешь ошибочным для меня не проблема. Отдохну от тебя с удовольствием.

Здравствуйте, samius, Вы писали:

S>>>Контрпример — ALGOL 68

I>>Там тоже есть замыкания.
S>Интересно, а авторы в курсе?

Позвони да узнай.

I>>Ты шота стал википедией злоупотреблять

Если я отредактирую эту табличку, ты согласишься со мной ?
S>Нет, я смотрел и в других источниках тоже. А если поправишь табличку, там есть кому поправить обратно.

похоже, "другие источники" еще более ушлые чем википедия

I>>Это вообще не аргумент, см выше

S>Конечно, а у тебя аргумент, притом что автор той странички не знает, кто добавил паскаль в список языков с замыканиями. Удивительной убедительности аргумент.

Ну это ж не я ссылаюсь на википедию

I>>Как минимум если нет такой возможности то в принципе невозможно различить.

I>>Вобщем твое мнение мне понятно и я считаю его ошибочным, можешь отдыхать.
S>Окей, то что ты мое мнение считаешь ошибочным для меня не проблема. Отдохну от тебя с удовольствием.

Ну значит я за тебя спокоен.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Нет, я смотрел и в других источниках тоже. А если поправишь табличку, там есть кому поправить обратно.

I>похоже, "другие источники" еще более ушлые чем википедия

Похоже что кроме дискредитации источников, тебе нечем возразить.

S>>Конечно, а у тебя аргумент, притом что автор той странички не знает, кто добавил паскаль в список языков с замыканиями. Удивительной убедительности аргумент.

I>Ну это ж не я ссылаюсь на википедию

А на кого ты ссылаешься, можно узнать?

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, samius, Вы писали:

S>>>>Контрпример — ALGOL 68
I>>>Там тоже есть замыкания.
S>>Интересно, а авторы в курсе?

K>Насколько я знаю, стандарт не обязывает реализовывать замыкания. Т.е. решение upwards funarg problem не требуется. При том, что все что нужно для полноценных замыканий (включая GC) в Algol 68 есть. Видимо поэтому, в некоторых реализациях 70-х замыкания были, но не во всех. В той реализации (современной), которой я проверял этот код замыканий не было.

Я просто посмотрел в табличку на википедии (и не только, еще и на haskell.org, где-то еще). Ikemefula походу принимает за замыкание решение низходящего фунарга.

Здравствуйте, Ikemefula, Вы писали:

I>В турбопаскале это делается только хаком. Там даже обычную не вложеную функцию нельзя просто так вызвать по указателю.
Да? А в инструкциипишут что вроде можно.

Здравствуйте, samius, Вы писали:

I>>похоже, "другие источники" еще более ушлые чем википедия

S>Похоже что кроме дискредитации источников, тебе нечем возразить.

Кроме фразы "другие источники" и википедии у тебя ничего не было.

S>>>Конечно, а у тебя аргумент, притом что автор той странички не знает, кто добавил паскаль в список языков с замыканиями. Удивительной убедительности аргумент.

I>>Ну это ж не я ссылаюсь на википедию

S>А на кого ты ссылаешься, можно узнать?

Надо понимать, по моей ссылке ты не ходил или ходил но прочесть не смог или прочел но не понял ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Кроме фразы "другие источники" и википедии у тебя ничего не было.
Это свидетельствует о проблемах с вниманием у тебя.

S>>А на кого ты ссылаешься, можно узнать?

I>Надо понимать, по моей ссылке ты не ходил или ходил но прочесть не смог или прочел но не понял ?
Я даже процитировал что автор не знает откуда взялась информация. Но ты не отразил это трижды.

Здравствуйте, Sinclair, Вы писали:

I>>В турбопаскале это делается только хаком. Там даже обычную не вложеную функцию нельзя просто так вызвать по указателю.
S>Да? А в инструкциипишут что вроде можно.

Ожидаю от тебя пример вроде того что ниже, но только что бы он хотя бы компилился

     type
          pProc = procedure(s:string);
     function X(s:string):pProc;far;
          procedure X1;far;
          begin;
               WriteLn(s);
          end;
     begin;
          X := @X1;
     end;

Ну и мануал, там есть подсказка

@ and Procedures and Functions
When the @ address-of operator is placed before a procedure or function,
it returns the address of the procedure or function's entry point. This form
is used for passing a procedure or function location to an assembly language
routine, or to save a pointer to a procedure. For example, given

var
ProcPointer : Pointer;

function Sum(A, B: Integer) : Integer;
...
ProcPointer := @Sum;

assigns ProcPointer the address of function Sum.
Listing 3.4 illustrates the use of the @ symbol for passing a pointer to a
procedure as a procedure parameter. This example uses the TCollection
object-oriented library method ForEach, which takes as its only a parameter, a
pointer to a procedure. ForEach is defined as,

procedure ForEach (Action: Pointer);

ForEach calls the procedure parameter using code that resembles,

Listing 3.4. A sample procedure that uses the @ address-of operator on a
procedure.

procedure PrintPhoneBook;
procedure PrintEntry( OneEntry : PPersonInfo ); far;
begin
with OneEntry^ do
Writeln(Name,Address,City,State,Zip,Age);
end; { PrintEntry }

begin
PhoneBook^.ForEach( @PrintEntry );
end;

Здравствуйте, samius, Вы писали:

I>>Кроме фразы "другие источники" и википедии у тебя ничего не было.
S>Это свидетельствует о проблемах с вниманием у тебя.

Три-четыре ссылки на википедию это и есть "другие источники" ? И давно у тебя так ?

S>>>А на кого ты ссылаешься, можно узнать?

I>>Надо понимать, по моей ссылке ты не ходил или ходил но прочесть не смог или прочел но не понял ?
S>Я даже процитировал что автор не знает откуда взялась информация. Но ты не отразил это трижды.

Не собираюсь твою вольную трактовку вольного перевода с английского языка, ибо смысла это не имеет, судя по предыдущим беседам, нпример как ты трактовал определение идентити.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Кроме фразы "другие источники" и википедии у тебя ничего не было.
S>>Это свидетельствует о проблемах с вниманием у тебя.

I>Три-четыре ссылки на википедию это и есть "другие источники" ? И давно у тебя так ?
Ой как жопа завиляла... Чую подмену темы. Я не выдавал википедию за другие источники.

S>>>>А на кого ты ссылаешься, можно узнать?

I>>>Надо понимать, по моей ссылке ты не ходил или ходил но прочесть не смог или прочел но не понял ?
S>>Я даже процитировал что автор не знает откуда взялась информация. Но ты не отразил это трижды.

I>Не собираюсь твою вольную трактовку вольного перевода с английского языка, ибо смысла это не имеет, судя по предыдущим беседам, нпример как ты трактовал определение идентити.
Именно поэтому я твоему источнику должен верить больше чем википедии и "другим источникам", которые я не упоминал?
Рассчитываю на то, что если у тебя найдется другая причина, то ты ее предъявишь. Иначе обсуждать тут кто что не понял я больше не собираюсь.

Здравствуйте, samius, Вы писали:

I>>>>Кроме фразы "другие источники" и википедии у тебя ничего не было.
S>>>Это свидетельствует о проблемах с вниманием у тебя.

I>>Три-четыре ссылки на википедию это и есть "другие источники" ? И давно у тебя так ?
S>Ой как жопа завиляла... Чую подмену темы. Я не выдавал википедию за другие источники.

"Кроме фразы "другие источники" и википедии у тебя ничего не было" @
Попроси модераторов отредактировать твои сообщения и всунуть туда какую ссылку кроме как на википедию и будем считать это твоей победой

I>>Не собираюсь твою вольную трактовку вольного перевода с английского языка, ибо смысла это не имеет, судя по предыдущим беседам, нпример как ты трактовал определение идентити.
S>Именно поэтому я твоему источнику должен верить больше чем википедии и "другим источникам", которые я не упоминал?

То есть, не упоминал, значит с моим вниманием все в порядке ?

S>Рассчитываю на то, что если у тебя найдется другая причина, то ты ее предъявишь. Иначе обсуждать тут кто что не понял я больше не собираюсь.

Не беспокойся, я тебя пойму, если не станешь писать ответ.

Здравствуйте, samius, Вы писали:

S>Я просто посмотрел в табличку на википедии (и не только, еще и на haskell.org, где-то еще). Ikemefula походу принимает за замыкание решение низходящего фунарга.

Я походу объяснил, что в паскале как минимум нет возможности различить два случая пользуюясь легальными средствами языка. Одна и та же фича для поддержки языковых средств.

Объясни, для чего в языке, который не умеет первоклассные функции, реализовывать полноценные замыкания ? Рассматривай это как оптимизацию.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

S>>Я просто посмотрел в табличку на википедии (и не только, еще и на haskell.org, где-то еще). Ikemefula походу принимает за замыкание решение низходящего фунарга.

I>Я походу объяснил, что в паскале как минимум нет возможности различить два случая пользуюясь легальными средствами языка. Одна и та же фича для поддержки языковых средств.

I>Объясни, для чего в языке, который не умеет первоклассные функции, реализовывать полноценные замыкания ? Рассматривай это как оптимизацию.
Вот и википедия говорит что в паскале замыканий нет в том числе потому что нет первоклассных функций. В этом свете я не понимаю, что ты хочешь что бы я тебе объяснил.

Здравствуйте, samius, Вы писали:

I>>Я походу объяснил, что в паскале как минимум нет возможности различить два случая пользуюясь легальными средствами языка. Одна и та же фича для поддержки языковых средств.

I>>Объясни, для чего в языке, который не умеет первоклассные функции, реализовывать полноценные замыкания ? Рассматривай это как оптимизацию.
S>Вот и википедия говорит что в паскале замыканий нет в том числе потому что нет первоклассных функций. В этом свете я не понимаю, что ты хочешь что бы я тебе объяснил.

на вопрос "для чего" ответил "Вот и википедия...", вобщем до свидания

Здравствуйте, grosborn, Вы писали:

>> S>>То что ты называешь лексическим замыканием в паскале, всего лишь http://en.wikipedia.org/wiki/Lexically_scoped#Lexical_scoping, который распространяется на вложенные функции.

G>Кхм... вложенная функция это свой отдельный scope, если вообще про область видимости можно такое сказать. Который можно сказать включает scope вышестоящего уровня.
Верно, включает, в этом и отличие.

>> Замыкание же позволяет использовать переменные ИЗВНЕ их lexical scope (http://en.wikipedia.org/wiki/Closure_%28computer_science%29)

G>Так же и во вложенной функции позволительно использовать переменные вышестоящего scope.
Использовать переменные вышестоящего scope это не есть замыкание. Пресловутая википедия говорит:

In programming language theory, a non-local variable is a variable that is not defined in the local scope.

Раз переменные внешней функции определены для вложенной функции, значит они локальны для вложенной по этому определению. А по определению замыкания с той же википедии, замыканием считается функция, позволяющая работать с нелокальными переменными. Т.е. вложенная функция паскаля не является замыканием по определению с википедии (точнее по совокупности их).

G>Внешние отличия чисто косметические. Внутренняя реализация конечно другая. Хотя строго говоря вложенные функции это не замыкания (технически и формально), но называть их замыканиями вполне можно, хотя путать их тоже нельзя. Это просто другая реализация с тем же смыслом и теми же целями. Там называлась так, здесь называется по другому, но это одно и то же.
Замыкание — это в основном и есть способ реализации, который отличается от способа реализации через передачу указателя на фрейм стека. Именно потому и отличия в возможностях.
Способ реализации "замыкание" в полный рост может использоваться и для вызовов вложенных функций внутри вложенной (т.е. без передачи вложенной функции наверх). Но это лишь потому, что некоторым компиляторам лень разбираться, в каком контексте будет вызываться вложенная функция. Так, например C# не разбирается и использует замыкание(т.е. технику реализации) даже там где передавать вложенную функцию вовне не надо, а можно было бы обойтись указателем на фрейм стека. Просто использовать замыкание дешевле в плане необходимости модифицировать рантайм. Возможно отсюда и путаница, что раз паскаль позволяет делать то, что позволяют замыкания в C# (но лишь во внутреннюю сторону, неестественную для замыканий), то типа и паскаль значит поддерживает замыкания. Но нет, не поддерживает по определению замыкания и нелокальной переменной.

Здравствуйте, samius, Вы писали:

S>Раз переменные внешней функции определены для вложенной функции, значит они локальны для вложенной по этому определению. А по определению замыкания с той же википедии, замыканием считается функция, позволяющая работать с нелокальными переменными. Т.е. вложенная функция паскаля не является замыканием по определению с википедии (точнее по совокупности их).

Википедия, википедия, википедия... Кстати, там же "A closure allows a function to access variables outside its immediate lexical scope". Что такое immediate lexical scope ?

S>Способ реализации "замыкание" в полный рост может использоваться и для вызовов вложенных функций внутри вложенной (т.е. без передачи вложенной функции наверх). Но это лишь потому, что некоторым компиляторам лень разбираться, в каком контексте будет вызываться вложенная функция. Так, например C# не разбирается и использует замыкание(т.е. технику реализации) даже там где передавать вложенную функцию вовне не надо, а можно было бы обойтись указателем на фрейм стека. Просто использовать замыкание дешевле в плане необходимости модифицировать рантайм. Возможно отсюда и путаница, что раз паскаль позволяет делать то, что позволяют замыкания в C# (но лишь во внутреннюю сторону, неестественную для замыканий), то типа и паскаль значит поддерживает замыкания. Но нет, не поддерживает по определению замыкания и нелокальной переменной.

Способ реализации ? Сильный аргумент — эдак окажется что ни в одном языке нет замыканий.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Википедия, википедия, википедия... Кстати, там же "A closure allows a function to access variables outside its immediate lexical scope". Что такое immediate lexical scope ?

Что-то ты не можешь со мной распрощаться. Пока-пока!

Здравствуйте, grosborn, Вы писали:

>> G>Так же и во вложенной функции позволительно использовать переменные вышестоящего scope.
>> Использовать переменные вышестоящего scope это не есть замыкание.

G>Это ты сам только что придумал.

>> Пресловутая википедия говорит:
>>

>> In programming language theory, a non-local variable is a variable that is not defined in the local scope.

G>Ну так верь википедии, что же ты ересь-то несешь. Отлучат тебя от вики.
В таком русле разговор не сложится.

Ты хочешь сказать что в scope вложенной функции переменные внешней не определены? Если да, не определены, то можно не продолжать.

> Ты хочешь сказать что в scope вложенной функции переменные внешней не определены? Если да, не определены, то можно не продолжать.

В scope вообще переменные не определяются. Локальные переменные определяются в блоке, а scope это область видимости. Если мы в какой-то процедуре что-то видим, оно не становится локальным. Глобальные переменные не становятся локальными.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> Ты хочешь сказать что в scope вложенной функции переменные внешней не определены? Если да, не определены, то можно не продолжать.

G>В scope вообще переменные не определяются. Локальные переменные определяются в блоке, а scope это область видимости. Если мы в какой-то процедуре что-то видим, оно не становится локальным. Глобальные переменные не становятся локальными.

Давай сначала закроем тему с глобальными переменными, ведь мы говорим не о них.
Опять википедия

In computer programming, a global variable is a variable that is accessible in every scope (unless shadowed).

Далее посмотрим на определения локальных и нелокальных (еще раз)

In computer science, a local variable is a variable that is given local scope.
In programming language theory, a non-local variable is a variable that is not defined in the local scope.

И еще на всякий случай scope.

a scope is the context within a computer program in which a variable name or other identifier is valid and can be used, or within which a declaration has effect.

Так вот, глядя на эти определения и ничего не выдумывая, можешь ли ты ответить, как классифицируются переменные внешней функции относительно вложенной?
Если переменной дается local scope (т.е. не глобальный), и этот scope распространяется на вложенную функцию, то согласно этим определениям будет ли переменная внешней функции локальна для внутренней или нет?

S>Давай сначала закроем тему с глобальными переменными, ведь мы говорим не о них.

Чтобы дискуссия была продуктивной стоит выделить и отделить друг от друга следующие понятия:
а) видимость переменной
b) время жизни переменной
c) "время жизни" вызова функции

Сейчас при аргументации постоянно происходит подмена одного понятия на другое, и соответственно передергивание терминов глобальный, локальный и т.д.

> Сейчас при аргументации постоянно происходит подмена одного понятия на другое, и соответственно передергивание терминов глобальный, локальный и т.д.

Нет, спасибо, не надо тут подмены понятий пожалуйста. Я понимаю ты в этом силен, но тут очень простой вопрос и не стоит из него высасывать тред на сотню постов.

Posted via RSDN NNTP Server 2.1 beta

> G>В scope вообще переменные не определяются. Локальные переменные определяются в блоке, а scope это область видимости. Если мы в какой-то процедуре что-то видим, оно не становится локальным. Глобальные переменные не становятся локальными.
>
> Давай сначала закроем тему с глобальными переменными, ведь мы говорим не о них.

> Так вот, глядя на эти определения и ничего не выдумывая, можешь ли ты ответить, как классифицируются переменные внешней функции относительно вложенной?
> Если переменной дается local scope (т.е. не глобальный), и этот scope распространяется на вложенную функцию, то согласно этим определениям будет ли переменная внешней функции локальна для внутренней или нет?

Ошибочный тезис о том, что переменные из внешнего по отношению к исполняемому scope, внесенные каким-то механизмом в контекст исполнения становятся локальными, выдвинул ты. Я тебе его разрушил простым примером глобальных переменных. Кроме него есть и другие. Так что ты не крутись перебирая все ссылки википедии, а просто признай ошибочность тезиса.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:
I>Ожидаю от тебя пример вроде того что ниже, но только что бы он хотя бы компилился

I>     type
I>          pProc = procedure(s:string);
I>     function X(s:string):pProc;far;
I>          procedure X1;far;
I>          begin;
I>               WriteLn(s);
I>          end;
I>     begin;
I>          X := @X1;
I>     end;
I>

Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

I>Ну и мануал, там есть подсказка
Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

Здравствуйте, DarkGray, Вы писали:

S>>Давай сначала закроем тему с глобальными переменными, ведь мы говорим не о них.

DG>Чтобы дискуссия была продуктивной стоит выделить и отделить друг от друга следующие понятия:
DG>а) видимость переменной
DG>b) время жизни переменной
DG>c) "время жизни" вызова функции

DG>Сейчас при аргументации постоянно происходит подмена одного понятия на другое, и соответственно передергивание терминов глобальный, локальный и т.д.
Проблема дискуссии как раз в том что используются понятия и у каждого за конкретным термином понятие свое. И желания прийти к единой системе понятий я не наблюдаю. Без этого любая дискуссия имеет тенденцию превратиться в срач.
О чем можно дискутировать, если не договорились что называть локальной перменной? Какое уж тут ООП?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, grosborn, Вы писали:

>>> Раз переменные внешней функции определены для вложенной функции, значит они локальны для вложенной по этому определению.

G>>Ничего подобного. По определению переменные вышестоящей процедуры это не локальные для вложенной переменные. У вложенной процедуры/функции своя область видимости, для нее вышестоящая процедура/функция это не локальная, а внешняя, и обращается она к переменным вышестоящей процедуры/функции технически так же, как и замыкание, то есть через относительную ссылку.
S>Что такое "относительную ссылку"? Что такое "технически также"? Простите коллега, я вас совсем не понимаю.
А мне показалось что я понял...

G>>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
S>Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте.

Действительно. Как-то я это пропустил между ушей/глаз. Походу пора почистить stackoverflow.com от дотнета.

> G>Вложенные процедуры имеют пересекающиеся scop-ы.
> О как. Я правильно понимаю, что в C++ фигурные скобочки — это уже замыкание???

Бу-га-га-га

> G>Ну так верь ей. Значит процедуры паскаля — замыкания. По определению

> У вас странное (для меня) понимание локальности. Но это, наверное, оттого, что я слишком много читаю Липперта.

Еще и думать нужно.

> G>А это ты сам придумал.
> Профессионал должен уметь и размышлять, а не только цитировать авторитеты. Я с samius согласен.

Бу-га-га-га, самиус как раз цитирует авторитеты и никогда не размышляет, не относится к формулировкам критически, относится строго формально вопреки логике. А тут формулировки википедии противоречат его позиции, вот ведь какая незадача случилась, попал в собственную ловушку.

> G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
> Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте.
> Коллега, вы меня пугаете! Можно пруфлинк в студию?

Ты опять потроллить решил и перевираешь слова. В лес.

Posted via RSDN NNTP Server 2.1 beta

>>> Если переменной дается local scope (т.е. не глобальный), и этот scope распространяется на вложенную функцию, то согласно этим определениям будет ли переменная внешней функции локальна для внутренней или нет?
>
> G>Ошибочный тезис о том, что переменные из внешнего по отношению к исполняемому scope, внесенные каким-то механизмом в контекст исполнения становятся локальными, выдвинул ты. Я тебе его разрушил простым примером глобальных переменных. Кроме него есть и другие. Так что ты не крутись перебирая все ссылки википедии, а просто признай ошибочность тезиса.
> Ты разрушил не тезис, ты разрушил мое предположение о том что ты можешь работать с определениями. При том что мы будем пользоваться различными определениями/понятиями мы ни о чем не договоримся, а лишь потратим время.

Не увиливай. Как не крутись, а переменная определенная в вышестоящей процедуре, во вложенной не локальная. У них и область видимости, то есть scope разные, и время жизни. С внешней не дотянуться до внутренней. Ну никак. Так что давай, садись на жопкой на горячую сковородку и признавай поражение.

> Вобщем, если я в чем-то и ошибаюсь, то убедить меня в этом ты сможешь лишь вникнув в определения википедии, а не продавливая мнение что я ошибся, игнорируя что я пишу в ответ.

Своей головой еще думать нужно.

> Ну или пообсуждать определение замыкания можно в другой системе определений, но непременно со ссылками на определения используемых понятий. Тогда тебе придется как минимум привести такую систему прежде чем гнобить википедию.
> Если ты не готов, или не собираешься это делать, то тебе остается понять, что формально обсуждать образы в твоей голове контрпродуктивно.

Тра-ля-ля, финтифлюшник-крючкотвор.

Posted via RSDN NNTP Server 2.1 beta

> О чем можно дискутировать, если не договорились что называть локальной перменной? Какое уж тут ООП?

О чем можно дискутировать, если такие понятия вызывают трудность? Вообще бардак какой-то в голове у тебя, scope видите ли можно "назначать". Ты эта, давай с википедией завязывай и начинай читать учебники с ситематичным изложением материала. Потому что твой моск не выдержал шрапнели от комбинаторного взрыва, вызванного запоминанием большого количества статей википедии не объединенных в стройную систему пониманий.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Не увиливай. Как не крутись, а переменная определенная в вышестоящей процедуре, во вложенной не локальная.
Согласно определению — локальная. И ты пока не привел ничего, согласно чему можно было бы считать что она локальной не является.

G>У них и область видимости, то есть scope разные, и время жизни.
Действительно разные и я не утверждал обратного.

G>С внешней не дотянуться до внутренней. Ну никак. Так что давай, садись на жопкой на горячую сковородку и признавай поражение.
Поражение пока запишем за тобой, т.к. никакой аргументации твоим тезисам, кроме личной неприязни к википедии, ты не продемонстрировал.

>> Вобщем, если я в чем-то и ошибаюсь, то убедить меня в этом ты сможешь лишь вникнув в определения википедии, а не продавливая мнение что я ошибся, игнорируя что я пишу в ответ.

G>Своей головой еще думать нужно.
Твои слова да тебе в уши. Включай голову-то!

>> Если ты не готов, или не собираешься это делать, то тебе остается понять, что формально обсуждать образы в твоей голове контрпродуктивно.

G>Тра-ля-ля, финтифлюшник-крючкотвор.

Здравствуйте, grosborn, Вы писали:

>> О чем можно дискутировать, если не договорились что называть локальной перменной? Какое уж тут ООП?

G>О чем можно дискутировать, если такие понятия вызывают трудность? Вообще бардак какой-то в голове у тебя, scope видите ли можно "назначать". Ты эта, давай с википедией завязывай и начинай читать учебники с ситематичным изложением материала. Потому что твой моск не выдержал шрапнели от комбинаторного взрыва, вызванного запоминанием большого количества статей википедии не объединенных в стройную систему пониманий.

— Имя, сестра, имя!

> G>Не увиливай. Как не крутись, а переменная определенная в вышестоящей процедуре, во вложенной не локальная.
> Согласно определению — локальная. И ты пока не привел ничего, согласно чему можно было бы считать что она локальной не является.

Вот ты опять несешь антивикипедическую ересь. В википедии нет такого определения, какое ты тут придумал. Я вот доложу про тебя олигархату.

> G>У них и область видимости, то есть scope разные, и время жизни.
> Действительно разные и я не утверждал обратного.
>
> G>С внешней не дотянуться до внутренней. Ну никак. Так что давай, садись на жопкой на горячую сковородку и признавай поражение.
> Поражение пока запишем за тобой, т.к. никакой аргументации твоим тезисам, кроме личной неприязни к википедии, ты не продемонстрировал.

Стрелочник. Продолжаешь увиливать и пытаешь перевести стрелки на личность, приписываешь мне неприязнь к википедии. А я всего-лишь не абсолютизирую ее, отношусь взвешенно. В вики пишут разные люди, но славатехоспади находятся еще в вики редакторы, способные противостоять абсолютизму. И ты скорее всего писал туда свои алогичные формализмы и тебя скорее всего правили. И я нормально к этому отношусь. И меня правили, и я рад этому. Вики это не божественное творение, призванное заменить человеку моск.

>>> Вобщем, если я в чем-то и ошибаюсь, то убедить меня в этом ты сможешь лишь вникнув в определения википедии, а не продавливая мнение что я ошибся, игнорируя что я пишу в ответ.
>
> G>Своей головой еще думать нужно.
> Твои слова да тебе в уши. Включай голову-то!
>
>>> Если ты не готов, или не собираешься это делать, то тебе остается понять, что формально обсуждать образы в твоей голове контрпродуктивно.
>
> G>Тра-ля-ля, финтифлюшник-крючкотвор.
>

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> G>Не увиливай. Как не крутись, а переменная определенная в вышестоящей процедуре, во вложенной не локальная.
>> Согласно определению — локальная. И ты пока не привел ничего, согласно чему можно было бы считать что она локальной не является.

G>Вот ты опять несешь антивикипедическую ересь. В википедии нет такого определения, какое ты тут придумал. Я вот доложу про тебя олигархату.
Определение есть и я его приводил. Докладывай.

>> Поражение пока запишем за тобой, т.к. никакой аргументации твоим тезисам, кроме личной неприязни к википедии, ты не продемонстрировал.

G>Стрелочник. Продолжаешь увиливать и пытаешь перевести стрелки на личность, приписываешь мне неприязнь к википедии. А я всего-лишь не абсолютизирую ее, отношусь взвешенно. В вики пишут разные люди, но славатехоспади находятся еще в вики редакторы, способные противостоять абсолютизму. И ты скорее всего писал туда свои алогичные формализмы и тебя скорее всего правили. И я нормально к этому отношусь. И меня правили, и я рад этому. Вики это не божественное творение, призванное заменить человеку моск.
По порядку.
Пока ты не объяснил, чем конкретно тебя не устраивают конкретные определения с википедии, я буду склонен считать что у тебя пунктик относительно нее.
На википедии не все гладко, это верно. Люди разные, да. И ты тоже людь в этом смысле. Твои тезисы, а особенно ничем не подкрепленные, не являются абсолютной истиной и без посторонней редакции очень сомнительны. Я там не зарегистрирован. То что тебя там правили — я тоже этому рад, хотя и не сказать что сильно, т.к. ты проявляешь тенденцию к этому.

Мне не нравится обсуждать людей, составляющих википедию. Давай конкретнее. Чем тебе не нравятся те определения? Чем твои лучше? Где вообще те определения, которыми ты пользуешься? Если таки нравятся, то объясни, почему ты переменные внешней функции не считаешь локальными для вложенной.

Здравствуйте, Sinclair, Вы писали:

I>>

I>>     type
I>>          pProc = procedure(s:string);
I>>     function X(s:string):pProc;far;
I>>          procedure X1;far;
I>>          begin;
I>>               WriteLn(s);
I>>          end;
I>>     begin;
I>>          X := @X1;
I>>     end;
I>>

S>Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

Тип pProc можно использовать для параметра, но нельзя для возвращаемого значения, это можно обойти хаком.

I>>Ну и мануал, там есть подсказка
S>Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

> Ну, то есть пруфлинка про нестековость машины C# мы не увидим? Тогда, конечно, в лес.

А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

I>>Ты показал что функциональщина это функциональщина, а обещал показать что функциональщина это процедурное.

V>Я и показал, бо никаких функциональных вещей НЕ использовал. Вообще никаких. Ссылка на процедуру известна со времен ассемблера еще до появления ЯВУ и присутствует во всех сколь-нибудь важных для индустрии императивных языках. Даже там где нет аналога AdressOf (например, в Фортране), там аналогичная техника работает через Computed GOTO.

Ты использовал для аргумента локальные функции == без пяти минут лямбды, это и есть функциональщина.
Указатель на функцию — снова поддержка ФП.

V>Просто ты отрицаешь само наличие декомпозиции задачи в рамках процедурного подхода (или не понимаешь её, ХЗ). В процедурном подходе декомпозиция отталкивается от данных и алгоритмов их обработки.

Ага, а указатель на функцию это данные, да ?

>Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн.

В твоей трактовке это так потому что в процедурное ты записываешь фичи из ФП.

I>>Из твоих примеров это не следует.

V>Боюсь, в ответ на мои обоснования тебе придется привести свои. Простое "нет" не канает.

Все аргументы я привел, возможно ты их не понял, это другой разговор.

I>>Не важно. Мы говорим совсем на другую тему и количетсво комбинаторов в моих примерах не имеет значения

V>Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лмбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.

Нет, не имеет.

V>>>Локальные есть во всех процедурных языках, а что? Это ф-ии, видимые лишь из одной единицы компиляции. То бишь нигде более не объявляемые и никуда не экспортируемые.
I>>Нет.

V>Да.

Тогда покажи аналог моего кода на языке СИ. Том самом что ввели Ричи и Керниган. Ну, раз там есть локальные функции, стало быть количество кода у тебя не изменится, правильно ?

I>>Покажи мне локальные функции для языка Си. Спасибо.

V>Такая пойдет: void function_57C24FEC93AC4ED0867305FE733CF6E1() {}? )))

Нет, это не локальная функция. В Си вообще нет локальных фунций, этот язык не умеет захватывать свободные переменные. В итоге тебе нужно
1. описать структуру для захвата
2. описать функцию которая будет работать с этой структурой
3. выполнить захват, то есть создать экземпляр, инициализировать
4. освободить память (хрен знает когда)

Внезапно оказывается что qsort принимает указатель на обычные функции, а про твой захват ничего не знает, опаньки, для различных коллекций надо писать свою функцию сортировки.

Здравствуйте, samius, Вы писали:

V>>Увы, получить информацию можно только поглотив энергию. Поэтому идентичность никуда не денется. )))
V>>Ведь эту энергию поглотит "кто-то конкретный".
S>Она не то что никуда не девается, она ниоткуда не берется.

Двойка по физике.

S>Испускатель фотона не знает кто его получит.

Это аргумент за или против чего? я ХЗ чтоты имел ввиду, но его получит любой, вставший на пути следования фотона. И кто тебе мешает встать аналогично на "пути следования" любого события в WinForms?

V>>>>У меня испускает. Лампочка на звонке прямо на двери.
S>>>Ты добрался в тонкостях до фотонов и тут же перестаешь отличать дверь от лампочки. Толсто.

V>>В итернете ты можешь найти фото дверей, которые одна сплошная лампочка. Что было действительно толсто — так это сравнивать фотон с мячом. Спишем на кривые представления о происходящем...
S>Предлагаешь поразговаривать с дверью-лампочкой по фотографии в интернете?

Предлагаю перестать юлить. ТЫ уже очень далеко убегаешь, но так и не сказал — зачем? Ты игноришь все прямые вопросы и откровенно юлишь. Поэтому отвечать тебе лишний раз неохота — ты мастер по замыливанию обсуждаемого.

V>>>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
S>>>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.

V>>Наоборот, я показываю правомочность того, что дверь мне "отвечает" на вопрос. То бишь показываю физический смысл этого явления.
S>Покажи как вопрос от тебя доходит до двери

Я уже показывал более одного раза.

V>>Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале.
S>Вот я тебе и талдычу о том что аналога в мире нет.

Я опроверг все твои аргументы (все два) многократно. Ты мои — ни разу. Талдыч своей жене.

S>Вместо того что бы натягивать реальный мир на ООП, программисты поступают ровно наоборот, только это не всем очевидно.

Они никогда не поступают наоборот и адекватных примеров, увы, ты не приведешь. Даже здесь с дверью — никакого наоборот. Тебе в любом случае надо получать информацию от двери. А прямо или косвенно — вообще не важно, что в жизни, что в программе.

... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

S>Типа вот если бы дверь была бы как бы компьютером, и мы могли бы ей посылать сообщение, вот было бы круто.

Я же говорю, у тебя пробелы в теории информации. Для тебя сообщение — это непременно набор байт. И если ты этого набора байт в жизни не видишь, то оп-па! Твоя программа не является моделью рж!!! Я такого откровеннго детсада уже 100 лет не видел. )

S>Все, дальше выдумывать ничего не надо.

А я и не выдумываю, я сразу обозначил, что дверь нам может посылать информацию в нашей модели. А есть у ней компьютер или нет — вообще неважно. В общем, советую курить теорию информации. Ты уже десяток постов на весь интернет объясняешь, что у тебя в голове одно не страстается с другим исключительно из-за пробелов в островках знаний/эрудиции.

S>Читай Кея.

Читать Кея надо было не позже 3-го курса. А теперь всё, опоздал. Он тебе уже не поможет.

S>Только я вижу, что тебя таращит от твоей теории настолько, что ты не пытаешься понять, что тебе пишут в ответ.

Угу... Смотрю, ты готов юлить бесконечно... Дело твоё...

S>>>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

V>>Подтроллировать надо уметь. А у тебя в каждом втором посте — серьезные ошибки.
S>А у тебя-то!

Дык, ты не показал еще ни одной ошибки. Одно юление и манера отвечать вопросами на вопросы.

V>>>>Необоснованно по абзацу целиком. Но мне бы хотелось твою т.з. насчет концепции "непрерывного генерирования сигналов".

S>>>Необоснован твой абзац с подпиской на фотоны.

Обоснуй!
Ы?

V>>Дык, давай аргументы. Твоя необоснованность- она в отсутствии обоснования, если ты забыл смысл этого слова.
S>А не ты мне хотел показать, как близко ООП к рж,

Я и показал.

S>но потом написал что на самом деле аналога нет?

Не надо меня перефразировать. Я говорил сугубо о ролях в модели. Но сама модель — из жизни, увы. Ты опять попался!

Просто ты не видишь, где проходят границы абстракций и что такое вообще модель.

Смотри внимательней, что происходит: все многочисленные роли посредников, необходимых в рж для генерирования и доставки мне информации о двери, я объединил сначала в один посредник, а затем тот стал исопльзовать ВМЕСТО двери. Я это сделал не из-за кривизны моей умозрительной модели, а исключительно из-за её абтрактности. Напомню, абстракция — это упрощение. То бишь я всего-навсего выкинул кучу деталей, которые не являляются необходимыми для целевой программы. А если бы я так не сделал, что было бы? Напомню:

... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

Плюс еще сама дверь! Не понял?

Смотри раза внимательней: для целей моделирования происходящего, упомянутого "фиктивного объекта, который будет делать это ВМЕСТО двери" — будет более чем достаточно, это ж модель!. то бишь, сама дверь нам не нужна, ууупс! А что остается? Чем будет являться этот "фиктивный объект"? А может он и будет моделью двери, коль именно через него мы получаем о двери необходимую информацию и взаимодействуем с дверью через него?

Хочешь того или нет, но всё это время ты спорил о том, что модель не есть реальная жизнь. Детсад, сорри за повторение. Модель и не должна быть рж, на то она и модель. Но она, тем не менее, модель реально происходящего.

S>Давай так, твоя модель — ты и обосновывай ее близость к рж.

Я уже сделал это бесконечное кол-во раз и ты так и не привел контраргументов.

S>>>По поводу концепции "непрерывного генерирования сигналов", то если ты говоришь о фотонах, а не о волне, то ничего непрерывного в той концепции нет.
V>>Любая дискретность происходящего сглаживается физикой/химией колбочек глаза. Уже 100ГЦ человеческий глаз не различает.
S>А единичный фотон — различает, ага

Откуда ты вообще сейчас взял "единичный" фотон? Что за флуктуации мыслительной активности? По теме есть что сказать?

V>>В таком категоричном виде — нет ес-но. "События" в ООП в виде мультикаста — оно так прижилось фактически сразу. Объект шлет события и не знает кому.
S>знает кому. Делегату. А тот списку подписчиков. Никаких неизвестностей в ООП нет. См. observer.

Я уже сказал, куда тебе смотреть — на медиатор. Фотоны тоже не во всякой среде распространяются. И они таки имеют вполне конкретное направление, которое можно назвать адресом. Твой медиатор — это единственный адрес, о котором знает источник события.

V>>Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы.
S>Что за на пути адреса?

Именно, это проекция на первые две составляющих полярных координат в 3-хмерном пространстве.

S>Расскажи мне о том как у рецептора есть свой адрес и как рецептор подписывается на сообщение от вектора.

Я уже рассказывал — как. Если конспектом — без фокусировки никак.

V>>Я тебе уже сказал не раз, что есть дарес для фотонов. Хотя, ты и сам должен был знать. Чтобы доставлять фотоны по произвольному адресу, нужны волноводы соотв. радиодиапазона.
S>В ООП нет произвольного адреса, есть только конкретные.

Двойка тебе еще и по дизайну. Для того медиатор и нужен, чтобы источник информации ничего не знал о получателе.

V>>Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики?
S>На твое усмотрение

ОК, Геометрическая оптика

V>>Т.е. всё это время был лишь протест против словосочетания "естественным образом"?

S>Да. Жаль что до тебя это доходило так долго. Но боюсь, что еще не совсем дошло.

А до меня и сейчас твой упрямство не доходит. Я вообще не понимаю позицию из разряда "не знаю и знать не хочу".
Асбтракция — это естественное для человека понятие, т.к. сам человек склонен мыслить абстрактно, выкидывая ненужные детали.

V>>Когда такое говорят о технических моментах, то подразумевают, что некий технический момент для неких условий/ограничений/задачи наиболее удобен.
S>Походу ты пропустил начало темы. Речь шла о другом.

Ну побегай, побегай.

V>>Мало ли что "считается". Ты уже достаточно его знаешь, чтобы понимать как на самом деле. На Хаскеле МОЖНО писать чистые участки кода... это да....
S>Ты так и не привел ни одного нечистого куска без использования бэкдоров.

Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить?

V>>Я кроме "удобства" ещё ни одного вывода не сделал. Остальное — считай разминка для образного мышления и ничего более. Просто я ХЗ почему 10-й пост подряд должен объяснять тебе, что имею право раздавать роли объектам так, как мне, разработчику, удобно. Внося динамику в процесс, увы, удобнее всего наделить дверь "поведением", умением "отвечать" и т.д. Или нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

S>А я тебе 10-ый пост объясняю что я не оспариваю твоего права раздавать роли как угодно. Я оспариваю то утверждение, что как угодно разданные роли естественным образом соответствуют рж.

Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.

S>>>А теперь о связи между боксированным представлением и вытеканием хаскеля из СП. Просим.
V>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? )) Я так и думал.
S>Ну ты же высосал из пальца то что возражений нет. Есть возражения. Энергичные вычисления тоже могут быть чистыми.

Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.

S>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.

Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения?

Это уже какой-то полный П.

V>>А требование босксированого представления само по себе накладывает ограничения. То бишь для программы, генерирующей пользу во времени, ты должен понимать, что обработать такую "последовательность" с конца — неэффективно (в отличие от "последовательностей" на сравниваемом там же С/С++)... Хотя, казалось бы, одна строчка разницы в рекурсивном алгоритме... А всего-то добавилось понимание происходящего и ты уже более адекватен с т.з. инструмента.
S>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

Ну побегай, побегай...
А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. ))

V>>Дословно было сказанно так: "в некотором смысле побочный эфект". Никто на молекулы ничего не разнес. Пару коллег решили что это их зведный час и поделились пониманием побочного эффекта на уровне вики. )) Но это как раз фигня и детсад. А вот то, что ты и еще кто-то (уже не помню) с разбега пытались опротестовать ФАКТ упорядочивания вычислений, но быстро обломались, взяв за труд немного подумать — это уже было чуть интересней.
S>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.

Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому.

S>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.

if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.

V>>Ну а остальное уже подытоживал:
V>>

V>>чистая ф-ия -> порядок вычисления аргументов не важен, так?

S>Чистота функции в общем случае не кореллирует с порядком вычисления аргументов. Т.е. легко показать чистую функцию
S>

S>int add(int x, int y) { return x + y; }
S>

S>, для которой порядок вычисления аргументов будет играть роль.

Я не вижу, чтобы ты это показал для чистого ФП.

V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе. Только из-за этого счел возможным проводить параллели м/у таким ФП и СП, бо происходящее аналогично, как бы тебе не хотелось абстрагироваться от этого. Я тебе весьма удачную аналогию про поезд и стрелки приводил, но ты как вегда бегаешь от неудобных аргументов.

S>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.

Дык, я и так знаю, что придирание шло исключительно к словам... Просто кривое это придирание... или покажи у меня "побочным эффектом в общеизвестном смысле".
Я ж говорю: натуральный звездный час блеснуть эрудицией, не? В общем, кому как, а мне порция фана.

S>А то что ты используешь некоторые смыслы и тебя не могут понять, то это сугубо твои тараканы.

Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо.

V>>Контракт на методы типа? — ес-но! Это непосредственная вотчина современного ООП. Но ты непременно оспариваешь мой тезис, что парадигмы воруют друг у друга наработки. "Баба Яга против!" во всей красе. )
S>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.

Я и не собраюсь. Более того, я же и утверждал, что ООП оформило в одну парадигму некоторые уже реально устоявшиеся в процедурном подходе практики. Но понятие контракта на методы типа в современном его смысле выкристаллизовалось именно в ООП. Это медицинский факт.

S>>>Что за "экземпляр" монады?
V>>Это такой функциональный объект.
S>Что за функциональный объект?

Это пара { ф-ия, контекст }.

S>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.
V>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?
S>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.

Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
Мы и так эмулируем по той лишь причине, что мы пишем модель. Т.е. у нас каждая строчка кода заведомо эмуляция.

V>>>>Это я уже молчу о том, что регистровая память полностью эквивалентна ассоциативной, если за ключ ассоциации взять некий порядковый номер. Как тебе такая изоморфность мутабельной и иммутабельной низлежащей модели? Вот нарисуй на Хаскеле некий dictionary<адрес, объект> и смоделируй на этом dictionary память компьютера c операциями read/write (возвращающими новое состояние "памяти", ес-но). Потом попробуй найти отличия от императивного мира.

S>>>во-первых, отличия на поверхности. Код эмуляции будет чистым.

S>Если ты поставил себе цель воплотить все необходимые побочные эффекты в конечной программе, то на что ты жалуешься?

Опять, кто тебя спросит? Никто не задается целью воплотить специально, ес-но. Проблемы всегда из-за того, что там, где можно наплодить граблей специально, можно точно так же неспециально.

S>И видишь ли, меня интересует не только сама конечная программа.

Дык, это я же тебе и говорю, что тебя боле интересуют догмы. А меня интересует исключительно кач-во конечной программы. Поэтому я закоренелый циник. Мне все ср-ва хороши, если они работают.

V>>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя.
S>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления.

Да тут и школьнику было понятно, на что ты расчитывал. У тебя в каждом втором посте основной аргумент: "О нет! Неужели?!!" и далее в лицах расписывается трагизм происходящего. Имею полное морального право посшибать лулзов с такого абсолютно неадекватного на техническом форуме подхода к обсуждению.

S>Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать. Я лишь хотел сказать что возможность эмуляции не доказывает родство более близкое чем вычислительная эквивалентность ЛС и МТ.

Да понимаешь... В современных высокоуровневых программах такая эмуляция может происходить взаимно-многократно через многие слои либ... независимо от твоего желания. Именно поэтому в программах на Хаскеле программисты точно так же допускают кучу ошибок, которые приводят к ошибкам в том самом побочном эффекте, который целевой у всех программ. В общем, ты правильно говоришь насчет того, что "код эмулятора чист". Да, некий кусочек кода может быть чист. Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...

Здравствуйте, grosborn, Вы писали:

>> V>>Да и какая разница, в быту или нет, если наша программа всегда абстракция прямо по определению? Тебе вообще не должно быть важно, сама дверь испускает сигнал или отражает его так, что ты способен расмотреть эту дверь.
>> S>Мне неважно, но именно ты ведь пытаешься натянуть физику на ООП.
>>
>> Наоборот, я показываю правомочность того, что дверь мне "отвечает" на вопрос. То бишь показываю физический смысл этого явления. Хотя, я ни разу не обязан был этого делать для тебя, т.к. в умозрительной модели я имею право раздать роли обектам как мне удобно. Даже если такое распределение ролей не имеет физического аналога в реальном мире. Просто я ХЗ как тебе втолковать сей очевидный момент, вот и пришлось демонстрировать аналогичное происходящее в реале.

G>Ты эта, как у женщин извечный вопрос про моду, как бы так одеться, что бы раздеться?

G>Сам же признаешь, что смоделировать реальность невозможно,

Где ты увидел признание? Речь была о раздаче ролей в модели. Читай ближе к концу тут: http://www.rsdn.ru/forum/philosophy/4857930.1.aspx

G>ты ни разу не моделируешь реальность, а моделируешь свои мысленные абстракции

Дык, ни я ни ты я по-другому и не умеем. Мы моделируем наше представление о реальности. Как оно на самом деле всё-равно никто не знает.

G>да еще и раздавая роли как тебе удобно, то есть не основываясь на реальности.

Ты очень правильно подобрал слово "как удобно", хорошо, что не "как угодно". Удобство тут проявляется исключительно в избавлении от подробностей. Но ведь это и есть право модели, не? )))

G>Ну давайте все вместо не связанной с реалом абстракции bool Дверь.Открыта будем подписываться векторами на фотоны, что бы определить открыта ли она.

Давай, попрбуй фотонами. Боюсь, фотоны в программе у тебя тоже будут воможны лишь в виде их модели. Собственно, свойства get — это и есть модель возможности наблюдения при надобности неких характеристик/состояний объектов.

G>Представляю как ты там программируешь

Боюсь, пока не представляешь. Еще рано.

G>Попытка "моделировать реальный мир", это костыль для людей не знающих или не способных найти эффективное решение задачи.

Пустозвонство и бла-бла-бла. Проходили многократно... а стоит начать разбирать любой пример — и всё-равно сдуешься.

G>Если ты не можешь создать свою абстрактную модель направленную на решение задачи, конечно ты будешь пытаться что-то там в своем мозгу "моделировать". Если не знаешь чисел и математики, то считать ты вынужден моделируя реальный мир — загибая пальцы.

Ох уж эти мне интернетные умники, ловящиеся на собственных аналогиях... я тебе как бывший разработчик аппаратуры скажу, что двоичная железка при сложении именно "загибает пальцы" и "переносит в уме".

А если ты попытаешься в своей работе программиста подходить к числам в программе, как в математике... кароч, ты будешь первый претендент при сокращении рабочих мест, только и всего. Есть математика фундаментальная, а есть прикладная. Программист должен владеть разделами и той и той. Ты должен понимать, что есть дискретизация, что есть цифровое представление значение, что есть шумы округления и т.д. до бесконечности... Это если мы всё еще говорим о цифровой модели какой-нить математики. Все цифровые эффекты представления чисел, кстате, тоже математикой описываются, но уже прикладной.

Здравствуйте, Klapaucius, Вы писали:

V>>На Хаскеле МОЖНО писать чистые участки кода... это да....
K>Да, и весь код из таких участков и состоит.

А толку, если на них можно огрести точно такие же побочные эффекты? Какая разница на каком уровне абстракции мы эти побочные эффекты огребаем? У нас в программе слоёв абстракций — мильон.

V>>Т.е. против аналогичного происходящего в случае энергичных вычислений в ФП возражений нет? ))
K>Возражение простое, ваша посылка "все дело в ленивости" — неверная.

Это не моя посылка. Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений. Я им и показал, что именно они мне пытались объяснить, а чего сами не понимают.

K>ну и все ваши выводы из неверной посылки, следовательно, тоже ошибочны.

Уже второе подряд безосновательное утверждение. Давай или ближе к телу или никак — всё-таки глубоко ветка ушла.

V>>чистая ф-ия -> порядок вычисления аргументов не важен, так?
K>Нет, не так.
V>>Ну т.е. прикол-оксюморон и ничего больше...
K>Ну, неправильная посылка -> абсурдный вывод. Все как обычно.

Ясно. Аргументов не будет.

V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.
K>В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.

А мне это зачем ты пишешь? Пиши оппонентам. Я им это несколько постов пытался объяснисть и не уверен, что дошло.

V>> Только из-за этого счел возможным проводить параллели м/у таким ФП и СП, бо происходящее аналогично

K>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще.

Это самообман, причем в клинической стадии. Подозреваю — как обычно из-за фривольного перепутывания понятия "иммутабельности" и понятия "чистоты кода", как это было при обсуждении const рядом. Не надо мешать одно с другим.

K>Чем дальше вы проводите аналогию — тем серьезнее проблемы с пониманием.

Не надо проводить аналигии вместо меня и приписывать мне лишнее. Все сообщения на месте, можно освежить, что именно я пишу.

S>>>Что за "экземпляр" монады?
V>>Это такой функциональный объект.
K>Это не ответ на вопрос.

Это ответ. Курить что есть функциональынй объект.

V>>волнует конечная генерируемая программой польза, то бишь её побочные эффекты.
K>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат.

Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.

V>>и защиты от них НЕТ.
K>Наоборот — защита есть. Ради этого все и затевалось.

Это защита от нерадивого программиста уровня 0. Т.е. самообман. Если я могу без всяких бэкдоров в абсолютно чистом ФП-коде проэмулировать специально все случайные побочные эффекты, бывающие в императиве... то кто помешает произойти этому же в достаточно сложной программе случайно? Да и это необязательно до тех пор, пока программисты допускают на функциональных языках так же много ошибок, как и на любых других.

Просто GC и иммутабельность помогают от тех самых ошибок уровня 0. Ну ОК, отлично. Только оба упомянутых перпендикулярны как чистоте, так и ссылочной прозрачности, а лишь эти последние 2 характеристики являются целевыми.

Здравствуйте, Ikemefula, Вы писали:

I>Это зачатки функциональщины, а ты записываешь это в процедурное.

Вы как-нить договоритесь м/у собой. )))
А то оппонент обиделся и написал:

Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления. Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать.

Здравствуйте, samius, Вы писали:

S>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно.

Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

Здравствуйте, samius, Вы писали:

S>А замыкание продлевает время жизни связанного окружения до времени своего существования,

Так и есть.

S>которое не ограничено временем выполнения внешней функции.

Для Паскаля именно временем выполнения внешней ф-ии и было ограничено.

S>Таким образом, пока паскаль располагал локальные переменные на стеке, его вложенные функции не могли считаться замыканиями.

Замыканию вообще фиолетово, как переменные располагаются. Локальный контекст одних вычислений доступен в контексте других. Это всё.
Вот определение из вики:

Замыкание (англ. closure) в программировании — процедура или функция, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции и не в качестве её параметров (а в окружающем коде). Говоря другим языком, замыкание — это процедура или функция, которая ссылается на свободные переменные в своём лексическом контексте.

Паскалевские локальные процедуры/ф-ии в точности соответствуют.

Здравствуйте, samius, Вы писали:

S>Замыкание — это в основном и есть способ реализации, который отличается от способа реализации через передачу указателя на фрейм стека.

А какая разница, на фрейм переменных в стеке был передан указатель, или на память из кучи?

Ты посомтри, до чего ты уже дошел в расуждениях. Ты всерьез претендуешь на то, что именно такая твоя формулировка, относительно указателя на непременно фрейм из стека будет являться отличительной для "ненастоящих" замыканий? ))

S>Именно потому и отличия в возможностях.

Как раз в возможностях никаких отличий нет и не может быть. Есть полноценный доступ к переменным, объявленным во внешнем контексте.

S>Способ реализации "замыкание" в полный рост может использоваться и для вызовов вложенных функций внутри вложенной (т.е. без передачи вложенной функции наверх).

Вообще-то вниз. Но разве нас интересует механика? Ведь это можно сделать в ЛЮБОЙ механике. Например, при оптимизации локальных замыканий компиляторы функциональных языков могут поступать точно так же как Паскаль — то бишь не создавать фреймы переменных на куче для замыканий, если компилятор видит, что время жизни этих переменных ограничено временем жизни контекста, в котором они определены. То бишь, если лямбда вызывается непосредственно, а не передается куда-то и не возвращается как результат ф-ии.

S>Но это лишь потому, что некоторым компиляторам лень разбираться, в каком контексте будет вызываться вложенная функция. Так, например C# не разбирается и использует замыкание(т.е. технику реализации) даже там где передавать вложенную функцию вовне не надо, а можно было бы обойтись указателем на фрейм стека.

Потому что в CLI никак нельзя представить указатель на фрейм стека. То бишь, если делать хоть какую-то оптимизацию, то разве что ref-type анонимного объекта-замыкания переделать в value-type, экземпляр который передавать по ссылке... Но в C# с оптимизацией вообще непонятно что происходит. Выглядит так, что ничего.

S>Но нет, не поддерживает по определению замыкания и нелокальной переменной.

-1
Ну блин, понимать формулировки надо таки уметь. См. хотя бы вики.

Здравствуйте, Sinclair, Вы писали:

G>>Вложенные процедуры имеют пересекающиеся scop-ы.
S>О как. Я правильно понимаю, что в C++ фигурные скобочки — это уже замыкание???

А разве ты можешь для таких "скобочек" вводить переменные-параметры и вызывать многократно с различными значениями этих параметров? Если бы мог — были бы полноценные замыкания.

S>У вас странное (для меня) понимание локальности. Но это, наверное, оттого, что я слишком много читаю Липперта.

Это он придумал замыкания?

G>>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
S>Вот это новости! Куда делся стек? В прошлый раз, когда я читал ECMA-338, стек дотнета был на месте.
S>Коллега, вы меня пугаете! Можно пруфлинк в студию?

Ключевое выделено. Нет никакого требования размещать фреймы локальных переменных в том же стеке, что упоминается в ECMA-338.

Здравствуйте, Sinclair, Вы писали:

G>>А-ха-ха, заметил свою ошибку и пытаешься меня подловить, хамишь опять. Это была твоя мысль что у C# нет стека, это залет как сказал бы vdimas.
S>Если вы — второй аккаунт vdimas'а, то вас я тоже буду игнорировать.

Какие глупоcти, ты же видишь, что я пишу посты любой степени провокационности из собственного ника? Т.е. нафига мне дополнительные ники для того же самого, типа как у некоторых тимовцев?

S>А если нет, то мысль про отсутствие стека в C# я взял отсюда:
S>

S>J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.

S>Вы точно уверены, что это не вы писали?

Он прав, коль речь была о локальных переменных. Нет там требований или рекомендаций располагать фреймы локальных переменных на том стеке, который описан в инструкциях ВМ.

Сабж автору по теме http://www.infoq.com/presentations/Value-Values

З.Ы. В топике кроме Воронков Василий и Klapaucius походу никто не понимает, что такое ФП и чем оно отличается от ИП и ООП.

З.З.Ы. Невежество AndrewVK тяжело читать.

Здравствуйте, grosborn, Вы писали:
G>Крутись-вертись но свои измышления мне приписать не получится. Это ты придумал что у C# нет стека.
Ок, отлично. Вы попали в мой личный игнор-лист. Прощайте.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

I>>Это зачатки функциональщины, а ты записываешь это в процедурное.

V>Вы как-нить договоритесь м/у собой. )))
V>А то оппонент обиделся и написал:

Вообще то самиус писал это тебе а не мне.

V>

V>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления. Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать.

Ты сам то понял, что процитировал ? функционалное это и есть лямбда счисление. Ты головой то думай. в однмо месте ты с этим соглашаешься, а как доходит до локальных функций, то вдруг начинаешь это же самое отрицать. Естественно, старый паскаль это не функциональный язык, но в ем есть поддержка некоторых функциональных фич. Новый паскаль вполне себе функциональный — легко.

Здравствуйте, samius, Вы писали:

V>>Молодца, ты попался на тривиальный очевидный момент. Потому что поторопимшись. Давай ты напишешь пример, где предикат при if ОБЯЗАТЕЛЬНО вычисляется, но не будет вычислена возвращаемая if ветка.
S>Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался.

Ну дык, я же не виноват, что ты не поспеваешь за мной. )
Итого:
1. аргумент-предикат вычисляется тогда, когда надо будет вычислить одну из веток then-else.
2. аргумент-предикат обязательно вычисляется перед вычислением удачной выбранной ветки.

Уффффф... ))

V>>Ты увидишь кое-что важное, когда наконец сможешь этот пример породить. Что именно? А достаточно будет сравнить полученный вариант с вариантом работы некоего вычислителя на энергичной технике и попробовать найти отличия в семантике.
S>Ты уже задолбал делать выводы по вычислителю.

Дело не в выводах, а в том, что все рассуждения должны сойтись на всех моделях, соответствующих рассматриваемому (в данном случае — чистому ФП). ИМХО, полезно крутить в голове семантику собственного кода в случае его ленивого и не ленивого исполнения, верифицируя её идентичность — это как проверка уравнения после решения... поможет, в случае чего, найти ошибки в неверном решении.

V>>Так что ваш аргумент, по-сути, о том, что ф-ия if, как и все остальные ф-ии Хаскеля — ленивые. Это был, конечно, очень крутой и правильный аргумент. Только ни о чем, бо он сугубо о семантике низлежащего вычислителя. Т.е. ты имеешь полное право писать свои чистые ф-ии вовсе не заботясь о низлежащей семантике вычислителя. Где-то так...
S>Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто.

Это НЕ принципиально. В насквозь императивном языке вычисление ветки тоже может быть чисто, даже если будет мутабельность в каждой строчке кода. И прямо отсюда тебе надо искать еще аргументы в разнице происходящего.

S>>>По другим пунктам тоже можно поглядеть.
S>>>1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается.

V>>Я таки вижу, что именно само вычисление раскладывают на шаги: сначала задают промежуточные данные (let var=...), потом из них — конечные (in expr). Опять и снова, тот факт что вычисление производится в ленивой манере — ненужные подробности. Теперь найди отличия в описании шагов таких вычислений от описаний точно таких же шагов, записанных в императивном языке (порой с точностью до синтаксиса в compile-time и конечного кода в runtime). Другая модель? Хмм... арифметика, она и в Африке арифметика, как раз на арифметике можно абстрагироваться от любых низлежащих моделей вычислетелей.
S>отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись.

Неверно. Не каждый. А в языке D можно задать гарантии, что ф-ия будет pure, то бишь не будет производить побочных эффектов. При этом будет оставаться мутабельной.

S>>>А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.

V>>Ну, если подходить догматически, расставить рамки и т.д. то пролететь может что угодно. А если рассматривать лямда-исчисление только как входные описания для некоего вычислителя на машине Тьюринга (а оно так и есть) — то я имею право искать похожие механизмы. ИМХО, ветвление и разложение сложных вычислений на более простые шаги — это фундаментальные практики, и там и там.
S>Да, я вижу что сводимость вычислителей к МТ дает тебе право не только искать, но даже утверждать об императивности всего что шевелится вплоть до языков высокого уровня. Неясно только, почему Пролог оттуда выбился.

Потому что Пролог выполняет высокоуровневый дополнительный алгоритм, вносящий собственную семантику, а ФП и ИП — нет. ФП и императивные языки они описывают одни и те же вычисления ровно с одной и той же степенью подробности (при прочих остальных равных, например при наличии GC). Просто описывают в разном базисе. Из-за идентичной степени подробности мы получаем такой эффект, что если ветвление присутствует в императивном варианте, то оно будет и в ФП-варианте аналогичного кода. Именно такое взаимное обязательное отображения дает мне право назвать эту практику (ветвление) фундаментальной практикой, которая не только имеет аналогичную семантику для ФП и императива, но даже без всякого вреда для этой семантики может быть одинаково реализована что там что там, например когда ФП работает в энергичной манере. А теперь поднимись на пару абзацев выше, и посмотри, что я говорил про проверку семантик на различных моделях.

V>>Цикл — это повтор одного и того же кода. И ты тут пытаешься манипулировать, бо результат подпрограммы будет один и тот же только при одних и тех же входных данных. А если входные аргументы на каждом шаге цикла разные, то и результат будет разный. Почему-то комбинатор неподвижной точки так и называют — циклом или рекурсией, а вы тут упрямитесь? ))
S>Тебе уже намекали что у тела цикла нет результата, потому цикл без побочных эффектов способен лишь греть атмосферу.

Мне намекали неграмотные коллеги и я уже на это отвечал. Курите, для начала, определение чистоты функций. В абсолютно чистой ф-ии запросто может быть обычный императивный "мутабельный унутре" цикл.

Собсно, я начинаю понимать причины твоего спора со мной. )))
Это уже даже не догматика, а натуральное плавание в базовых понятиях...

V>>Да ради бога. Мне просто опять прикольно как ты скачешь с теории на сугубо подробности (ленивое выполнение в случае if) и потом обратно. Эдак даже не получается ровненько провести границы догм, приходится бегать подправлять?

S>А мне прикольно как ты опять влез на МТ

Я влез только для демонстрациия обязательного взаимного аналогичного отображения. А то некоторые порой забываются...

S>V>Ес-но, она Тьюринг-полна, потому что может быть исполнено на конечном вычислителе, который ВЫНУЖДЕН аргументы некоторых ф-ий считать в определенном порядке.
S>

S>Твоя аргументация убивает

Опять показываешь всю степень трагизма? )
А меня убивает твоя оторванность от понимания работы ФП, хотя ты выступаешь последнее время со стороны этого "лагеря".

В общем, рядом более грамотный в ФП-лагере товарищь мне вторит: http://www.rsdn.ru/forum/philosophy/4853976.1.aspx

V>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.
В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.

И далее почитай ветку, там более-менее по-делу.

И, хотя я несогласен с формулировкой о неявном упорядочиваниия в императивне (оно дается сверху как обязательно присутствующее в каждой строчке программы), но с явным упорядочиванием на if в ФП он не только не спорит, он даже показывает в след. по ветке посте, почему именно так. Показывает, ес-но, отталкиваясь от конечности вычислителя! Ну разве не фан мне тут с вами, горемычными? )))

V>>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.

S>Что-то много букав.

Блин, хорош прикалываться. А так и будем ни о чем.
Я думал, что очевидно было это: для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным. А все мои якобы "провокационные" заявления об идентичности происходящего что в ФП, что в императиве исходили из того, что в энергичной технике исполнения ФП будет ровно аналогичное (почему так — уже доказал), а семантика ленивого вычисления не должна отличаться от семантики энергичных. Всё!

S>Да, конкретно в хаскеле K/KI будет вычислено раньше.

Да в любом, хоть в чистом, хоть в глязном, хоть в ленивом, хоть в энергичном — везде будет раньше. Через это не перепрыгнуть.

S>понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).

Ээээ... а причем тут это и ветки if?
И вообще, насчет стетментов и "мира" — отдельная тема. Как раз, если мы рассматриваем не зачаточный императив, а именно знакомое нам СП, то во всех СП-языках обязательно присутствуют локальные переменные. То бишь стейтменты в СП-языках могут не оперировать глобальными переменными, то бишь в СП "изкаробки" заложена возможность писать чистые ф-ии, даже если код этих ф-ий мутабельный или содержит императивные циклы.

Здравствуйте, Klapaucius, Вы писали:

V>>А толку, если на них можно огрести точно такие же побочные эффекты?
K>Об этом можно было бы поговорить, если бы можно было "огрести". Но, раз уж "огрести" (без лупхолов всяких) нельзя — то и говорить тут не о чем.

Я уже рядом объяснял — как. Например, эмулируешь явно на ассоциативной памяти некую регистровую память — и отгребай сколько угодно. Т.е. достаточно, чтобы "объекты" дизайна ссылались друг на друга не прямо, а косвенно — через такую ассоциативную память (через некий ключ). То бишь, эмулируешь ту самую косвенную адресацию из-за которой всё и происходит в императиве, и получай сколько угодно точно такие же побочные эфекты, ноу проблема.

V>>Какая разница на каком уровне абстракции
K>Если нет разницы на каком уровне абстракции — то в чем вообще может быть разница?

Я и говорю, что в строгом смысле разницы вообще нет. Вся разница в том, что случайные побочные эффекты в случае ФП можно огрести не на уровне строчек исходника, а на уровне происходящего м/у оперируемыми абстракциями. Как тут рядом правильно хватались за соломинку: "но ведь код эмулятора чист!"
О да! Код эмулятора чист.

Дык, фан в том, что в императивном ПО тоже на уровне строчек исходника довольно редко случайные эффекты возникают (если уж совсем студентов не брать). Всё больше где-то при нагромождении абстракций.

V>>Это был ответ на детсад с попыткой попытку объяснить мне, как работает if в Хаскеле, т.е. оппоненты мне пытались объяснить как работает ленивость, но не опровергнуть фундаментальное требование упорядочивание вычислений.

K>Вы имеете в виду объяснение, что в ветках хаскельного if не производится действий, а возвращается то действие, которое будет произведено? Ленивость этому совершенно ортогональна. Тут обычные первоклассные функции. В строгом чистом языке будет происходить то же самое.

Думаю, ты ошибаешься. В строгом чистом языке вообще нет никакого требования, чтобы if возвращало действие. В энергичном ФП-языке if возвращает значение, а не ленивое тело одной из своих веток then-else. См. хотя бы язык Схема — покатит как пример чистого языка? Чтобы вернуть из ветки if ПФ в Схеме, это надо описать явно. Но ветка в любом случае вычисляется энергично, просто результатом вычисления ветки будет ПФ.

K>Да какие проблемы с аргументами? Если у нас язык строгий, то аргументы вычисляются перед тем, как они передаются в функцию.

Правильно.

K>Таким образом нет никакой связи между чистотой функции и порядком вычисления аргументов. Т.е. ваша посылка неверна.

Это не моя посылка, это мне там же и писали, что для чистого языка порядок вычисления аргументов не важен. Я лишь показываю, что для ветвления — важен. То бишь показываю, что if НЕ является обычной ф-ией. Поэтому, отдельные рассуждения относительно операции ветвления, вести можно. (Отдельные от семантики обычных ф-ий в ФП).

Даже если ты приведешь на Хаскеле ф-ию, которая будет работать как if... То она будет работать исключительно из-за ленивости Хаскеля. В энергичном языке ты никак не сможешь заменить if некоей равноправной остальным ф-ией.

K>Если язык ленивый, то порядок вычисления аргументов определяется кодом функции и он, разумеется, важен.

Елки, единственно здравомыслящий человек во всей ветке. )))
Собсно, повторяешь мои перефразированные слова.

K>-- Но в тьюринг-полном разница есть:

Вернее, в конечном вычислителе разница есть. Твой пример можно было сократить до 2-х строчек.

Если бы был вычислитель, выполняющий бесконечный цикл за секунду, работали бы оба твоих варианта, ес-но. ))
Ты опять, по-сути, повторяешь мои рассуждения.

Не желаешь попробовать верифицировать вот эти рассуждения насчет росписи if в базие I/K?
Исходное выражение на if: I(K/KI?(x,y))

...для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны.

для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным.

K>>>Происходящее в чистых ФЯ и императивных языках настолько неаналогично, что никакий пользы из проведения аналогий нельзя извлечь вообще.
V>>Это самообман, причем в клинической стадии.

K>Это реальность данная нам в ощущениях. Аналогия между декларативным ФП и императивным СП ложная — она не поможет понять ни того ни другого, а вот помешает — легко. Этот тред — очередное подтверждение.

Ладно, в эту сторону бодаться бесполезно, бо в этой стороне спорим об ощущениях.

Лично мне ничего не мешает понять ни то, ни другое. То бишь, запросто смог бы писать компиляторыы ФП-языков, как энергичных, так и ленивых. (Как там говориться — понять язык, это уметь написать его компилятор). Точно так же как я могу эмулировать работу ФВП на процедурных языках: http://www.rsdn.ru/forum/philosophy/4841569.1.aspx и ниже по ветке.

Но ощущения у меня другие, се ля ви. Я вижу такую фундаментальную вещь, что в императиве и ФП приходится описывать алгоритмы ровно с одной и той же степенью подробностей. (Именно поэтому я не люблю, когда ФП награждают эпитетом "деларативный"). А об однозначном отображении операции "ветвление" для обоих таких вариантов, описанных с однойи той же степенью подробностей, я уже высказывался: http://www.rsdn.ru/forum/philosophy/4859218.1.aspx

Я ведь всё-равно не поверю, что ты, или другие коллеги не видят этого однозначного отображения. Просто это какая-то специальная самоустановка относительно ФП — "забыть всё что знал и начать жизнь сначала". )))
Хрень полная, как по мне. Одно другому не мешает.

S>>>>>Что за "экземпляр" монады?
V>>>>Это такой функциональный объект.
K>>>Это не ответ на вопрос.
V>>Это ответ. Курить что есть функциональынй объект.
K>И это — не ответ.

Это пара { ф-ия, контекст }.
По последней ссылке более подробно.

K>>>Опять же — неверная посылка. "Генерируемая программой польза" — это не "побочный эффект", а эффект самый что ни на есть "прямой" — результат.
V>>Отлично, стоило тебе попытаться обосновать хоть одно своё "неверно" и ты сразу сел в лужу. Видишь ли... Наблюдать результат работы программы можно только через побочные эффекты. Без побочных эффектов ты даже не будешь знать, работает программа или нет.

K>Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов".

Это не ответ. (С)

K>2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.

По определению побочных эффектов, ввод-вывод — это тоже побочный эффект. Поэтому, программа без побочных эффектов — это фантом, а не программа.

V>>Если я могу без всяких бэкдоров в абсолютно чистом ФП-коде проэмулировать специально все случайные побочные эффекты, бывающие в императиве... то кто помешает произойти этому же в достаточно сложной программе случайно?
K>Никаких побочных эффектов вы без бекдоров не "проэмулируете". Все эффекты в чистом ФЯ прямые и явные — "побочных" без "бэкдоров" не бывает.

Ясно. Пример с эмуляцией косвенной адресации ср-вами ФП и протягивание состояний "мира" ты пока не понял. Ну ОК, подожду...

Здравствуйте, grosborn, Вы писали:

G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.

с каких пор паскаль стал стековой машиной?
(внимательно читаем определение)

G>J или C# это не стековая машина

курим msil до полного просветления.

> G>Лень тут совершенно не при чем. J или C# это не стековая машина, как паскаль, данные не на стеке, отсюда (ну и не только) и различия в реализации.
>
> с каких пор паскаль стал стековой машиной?
> (внимательно читаем определение)

Опаньки. Еще один вики-адепт. То есть для тебя то что в вики еще не упомянуто, того не существует? И скоро собачку нельзя назвать жучкой, патамучта "читаем определение". Вы уже достали со своей вики, совершенно неспособны думать головой. Вообще уже маразм.

> G>J или C# это не стековая машина
>
> курим msil до полного просветления.

Кури, я подожду.
И обрати внимание, vdimas понял. Он-то как раз курил паскаль и msil и просветлен. А вы с синклером чего-то недокурили.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Ikemefula, Вы писали:

I>То есть, ты только что удесятерил минимально необходимое количество кода.

Ты так и не показал удесятирение. А разговаривать ярлыками со мной бесполезно.

I>А это именно то о чем я говорил — ручное связывание.

Не вседа это связывание (пытаюсь опять обратить на этот ВАЖНЫЙ аспект твоё внимание). Зачастую выгодней или надежней создать копию значения для замыкания. Но тебе как об стенку горох. Да, в процедурном программировании способ передачи данных в процедуры — это часть дизацна и часть работы программиста.

Т.е. да, я ручками тебе показал то, что в лямбдах происходит автоматом. Я именно это и обещал показать.

I>Ты бил себя пяткой в грудь что это не надо.

Фантазии. Ветка на месте, можно освежить, коль забыл. Я изначально утверждал, что тонкости ФП они обычно не на уровне дизайна, а на уровне внутренних подробностей. Имнно потому ФП неплохо смотрится в методах ООП, что он неплохо выглядит в кач-ве помощника по оформлению кода вокруг вычислительных подробностей.

I>Пойми простую вещь, если язык умеет локальные функции — это ФП и тогда не ясно нахрен вообще все твои пример, ибо это ФП против ФП. А если не умеет, то работы в десять раз больше чем ты показал.

Прочитав это предложение я уже малость сомневаюсь, что же ты имел ввиду под "локальными ф-ями"? Я имел ввиду обычные ф-ии, которые имеют некую ограниченную область видимости, чтобы не засорять ими глобальную видимость из всего проекта.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>А вот если поковыряться в википедии, то выяснится что термин "замыкание" при упоминаниии вложенных процедур паскаля (с его рождения) ты употребил совершенно напрасно.

V>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

На бумажке в клеточку. Там же была документация по паскалю, срисованная с доски. Время на писюках предоставляли лишь с 3-го курса, и то его хватало лишь на вбить код и получить результат. Т.е. возможности для глумления над паскалем не было.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:

I>>>

I>>>     type
I>>>          pProc = procedure(s:string);
I>>>     function X(s:string):pProc;far;
I>>>          procedure X1;far;
I>>>          begin;
I>>>               WriteLn(s);
I>>>          end;
I>>>     begin;
I>>>          X := @X1;
I>>>     end;
I>>>

S>>Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

I>Тип pProc можно использовать для параметра, но нельзя для возвращаемого значения, это можно обойти хаком.

I>>>Ну и мануал, там есть подсказка
S>>Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

I>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.
По хорошему нужно писать X := X1; Тогда те компилер скажет, что возвращать ссылку на вложенную процедуру — очень плохо. как только ты взял указатель на процедуру — то с ним ты естественно волен делать что хочешь, указатель — это всего лишь указатель..

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, Sinclair, Вы писали:

I>>>>

I>>>>     type
I>>>>          pProc = procedure(s:string);
I>>>>     function X(s:string):pProc;far;
I>>>>          procedure X1;far;
I>>>>          begin;
I>>>>               WriteLn(s);
I>>>>          end;
I>>>>     begin;
I>>>>          X := @X1;
I>>>>     end;
I>>>>

S>>>Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

I>>Тип pProc можно использовать для параметра, но нельзя для возвращаемого значения, это можно обойти хаком.

I>>>>Ну и мануал, там есть подсказка
S>>>Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

I>>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

J>Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
J>Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.
J>По хорошему нужно писать X := X1; Тогда те компилер скажет, что возвращать ссылку на вложенную процедуру — очень плохо. как только ты взял указатель на процедуру — то с ним ты естественно волен делать что хочешь, указатель — это всего лишь указатель..
И при вызове функции по такому указателю начнуться проблемы. Конкретно в этом примере может всё и прокатит,
поскольку Х1 не использует глобальных переменны, но тогда в чём смысл делать эту функцию локальной?

А вся прелесть лямбд в том, чтобы передать указатель на лямбду в качестве параметра некоторого алгоритма,
который принимает указатель на функцию. Так вот в Паскале и в Дельфи брать указатели на вложеные функции НЕЛЬЗЯ.

Здравствуйте, vdimas, Вы писали:

V>Я уже рядом объяснял — как. Например, эмулируешь явно на ассоциативной памяти некую регистровую память — и отгребай сколько угодно. Т.е. достаточно, чтобы "объекты" дизайна ссылались друг на друга не прямо, а косвенно — через такую ассоциативную память (через некий ключ). То бишь, эмулируешь ту самую косвенную адресацию из-за которой всё и происходит в императиве, и получай сколько угодно точно такие же побочные эфекты, ноу проблема.

В императиве все "происходит" из-за того, что в императивной программе отсутствует информация о широком классе связей. Эти связи неявные, восстановить их статическим анализом в общем случае нельзя. В чистом коде эта информация присутствует в полном объеме. Стереть ее можно только с помощью лупхолов типа unsafePerformIO. Если моделировать в чистом языке "ассоциативную память" — информация никуда не денется, не сотерется — все связи по прежнему будут присутствовать в явном виде.

V>Я и говорю, что в строгом смысле разницы вообще нет.

В любом смыле разница есть. И в теории и на практике.

V>Вся разница в том, что случайные побочные эффекты в случае ФП можно огрести не на уровне строчек исходника, а на уровне происходящего м/у оперируемыми абстракциями.

Побочных эффектов в чистом ФЯ не бывает в принципе. "Случайные" эффекты без конкуррентности тоже не получить, а для этого есть свои инструменты.

V>Как тут рядом правильно хватались за соломинку: "но ведь код эмулятора чист!"
V>О да! Код эмулятора чист.

Ну да. Если вы будете эмулировать стейт поверх чистого кода — у вас остается денотационная семантика и прочие плюшки чистого кода. В этом и принципиальная разница. Это для вас сюрприз?

V>Думаю, ты ошибаешься. В строгом чистом языке вообще нет никакого требования, чтобы if возвращало действие.

Это требуется для того, чтоб язык был чистым.

V>См. хотя бы язык Схема — покатит как пример чистого языка?

Нет. Схема чистым языком не является.

V> Чтобы вернуть из ветки if ПФ в Схеме, это надо описать явно. Но ветка в любом случае вычисляется энергично, просто результатом вычисления ветки будет ПФ.

Ну а я о чем? Ленивость не релевантна в данном случае — if будет возвращать первоклассную функцию — действие и в строгом языке тоже.

K>>Да какие проблемы с аргументами? Если у нас язык строгий, то аргументы вычисляются перед тем, как они передаются в функцию.

V>Я лишь показываю, что для ветвления — важен. То бишь показываю, что if НЕ является обычной ф-ией.

В строгом языке if, разумеется, обычной функцией быть не может. А в ленивом — вполне может.

V>Даже если ты приведешь на Хаскеле ф-ию, которая будет работать как if... То она будет работать исключительно из-за ленивости Хаскеля. В энергичном языке ты никак не сможешь заменить if некоей равноправной остальным ф-ией.

Правильно. но при чем тут чистота?

V>Если бы был вычислитель, выполняющий бесконечный цикл за секунду, работали бы оба твоих варианта, ес-но. ))

Достаточно тайпчекера, который бесконечный цикл не пропустит.

V>То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения

Это описание ленивости как она есть.

Поэтому вот это вот:
V>будь он хоть ленивым, хоть энергичным.
вовсе не уместно.

V>Ладно, в эту сторону бодаться бесполезно, бо в этой стороне спорим об ощущениях.
V>Лично мне ничего не мешает понять ни то, ни другое. То бишь, запросто смог бы писать компиляторыы ФП-языков, как энергичных, так и ленивых.

Ну давайте ссылки на ваши реализации строгого и ленивого чистых ФЯ. А пока это разговор об ощущениях.

V>Я вижу такую фундаментальную вещь, что в императиве и ФП приходится описывать алгоритмы ровно с одной и той же степенью подробностей. (Именно поэтому я не люблю, когда ФП награждают эпитетом "деларативный").

Декларативность — это не про степень подробности, а про ссылочную прозрачность.

S>>>>>>Что за "экземпляр" монады?
V>Это пара { ф-ия, контекст }.

Ну ладно, допустим, что "экземпляр монады" — это замыкание (хотя это и не так), но где тут идентичность? Идентичности у замыкания нет. Для замыканий вообще эквивалентность не определена, даже структурная.

K>>Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов".
V>Это не ответ. (С)

Упрощенно говоря, результат программы это байт X по адресу Y — его можно пронаблюдать непосредственно. А производимый для этого эффект — это смена байта X' на байт X по адресу Y на такте N. В большинстве случаев мы эффект не наблюдаем, да и не нужно нам это — достаточно результата.

K>>2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.

V>По определению побочных эффектов, ввод-вывод — это тоже побочный эффект. Поэтому, программа без побочных эффектов — это фантом, а не программа.

-- ввод-вывод - побочный эффект:
writeLine :: String -> ()
readLine :: () -> String

-- ввод-вывод - прямой, а не побочный эффект:
writeLine :: (World, String) -> World
readLine :: World -> (World, String)

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Jack128, Вы писали:

I>>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

J>Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
J>Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.

Я ж не про дельфи

В турбопаскале нельзя объявить тип возвращаемого значения как процедуру или функцию.

Здравствуйте, SV., Вы писали:

SV.>Просто потому, что мы мыслим объектами.

Надо хорошо засрать мозги, чтобы начать "мыслить" объектами.

Это видел?

ООП скорее всего является попыткой разработать научную теорию программирования, но попыткой неудачной. Займет свое место на свалке истории.

Здравствуйте, igna, Вы писали:

I>Надо хорошо засрать мозги, чтобы начать "мыслить" объектами.

I>Это видел?

I>ООП скорее всего является попыткой разработать научную теорию программирования, но попыткой неудачной. Займет свое место на свалке истории.

ООП скорее всего является способом описывать кодом вполне определенные модели используя вполне конкретную научную теорию.

Здравствуйте, samius, Вы писали:

S>Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь.

Она позволит этого достичь только в связке с GC. Это там же было написано? Разве нет? ))

А может, потому что конкретный эффект, на который ты ссылаешься, действительно никак без GC не работает? А может, никто в зравом уме не захотел подставляться и приписывать такую хрень, что замыкания и GC неразрывно связаны?

ИМХО, там привели лишь один из возможных эффектов, который можно достигнуть в этой технике. Не надо делать из этого такие далекоидущие выводы.

S>Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

Странная у тебя манера ведения пора — половинчатая. Несогласие ты высказал, но я не увидел твоих альтернатив. Как же назвать технику, на которой работают вложенные ф-ии Паскаля?

Здравствуйте, samius, Вы писали:

V>>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

S>На бумажке в клеточку. Там же была документация по паскалю, срисованная с доски. Время на писюках предоставляли лишь с 3-го курса, и то его хватало лишь на вбить код и получить результат. Т.е. возможности для глумления над паскалем не было.

Т.е. специальность непрофильная...
Наверно, поэтому не хватает здравого цинизма во взгляде на вещи ))

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь.

V>Она позволит этого достичь только в связке с GC. Это там же было написано? Разве нет? ))

V>А может, потому что конкретный эффект, на который ты ссылаешься, действительно никак без GC не работает? А может, никто в зравом уме не захотел подставляться и приписывать такую хрень, что замыкания и GC неразрывно связаны?

Чушь, в делфи работает на подсчете ссылок

V>ИМХО, там привели лишь один из возможных эффектов, который можно достигнуть в этой технике. Не надо делать из этого такие далекоидущие выводы.

S>>Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

V>Странная у тебя манера ведения пора — половинчатая. Несогласие ты высказал, но я не увидел твоих альтернатив. Как же назвать технику, на которой работают вложенные ф-ии Паскаля?
Я ее называю "указатель на фрейм стека".

Здравствуйте, Klapaucius, Вы писали:

S>>>Я бы объяснил это проще, тем что ООП натягивали на процедурные языки во времена когда было популярно экономить на вызовах, куда уж говорить о создании объекта на каждый вызов.
S>>Гипотеза интересная, но смолток из коробки был построен на сверхпозднем связывании. Экономить они научились уже потом — хотспоттинг и спекулятивные оптимизации были придуманы ровно для него, и уже потом перетащены в джаву.

K>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.

Это важно, потому что смолток более современный. По крайней мере это ООП четко указывает, где его можно применять, а где нет и в результате это ООП дало практически все известные ООП-артефакты. В симуловском лепи какие хочешь классы и все дела.

K>Однако, вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали, а были адаптированы мейнстримом.
K>Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП,

То есть, старое неправильное это и есть симуловское ? Если так, то все в порядке. В смолтоковском появились практически все что нужно — философич, методология, паттерны, юниттесты, это и есть true ООП. Вопрос кто древнее не стоит, эдак Ньютоновская механика станет "правильнее" релятивистской .

Здравствуйте, Klapaucius, Вы писали:

K>Техника называется "static chain", изобрели ее около 1964-го года Рэндалл и Рассел, описана в Algol 60 Implementation — B.Randell & L.J.Russell, Academic Press, 1964.
K>А технику "замыкание" изобрел в том же году Ландин и реализовал впервые в SECD.

static chain всегда частный случай замыкания. То есть вложеные процедуры есть замыкания. Замыкания не обязательно вложеные процедуры. Можешь опровергнуть ?

Здравствуйте, Ikemefula, Вы писали:

I>Вот-вот. А отсутствие локальных функций означает количество кода примерно в 10 раз больше того, что ты показал.

Просто шедеврально!
Я ведь и написал пример в отсутствии локальных функций. Уууппссс??? ))

==============
Всё, закругляюсь. Ни ты, ни плюсующий тебе посетитель не в состоянии прочитать малюсенький отрывок кода из десятка строчек.

Здравствуйте, Ikemefula, Вы писали:

K>>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.
I>Это важно, потому что смолток более современный. По крайней мере это ООП четко указывает, где его можно применять, а где нет и в результате это ООП дало практически все известные ООП-артефакты. В симуловском лепи какие хочешь классы и все дела.

Как раз почти все известные ООП-артефакты произошли скорее от Симулы, зато вся ООП-идеология от Смолтока. Создатели Симулы никакого "ООП" не изобретали, они разработали необходимый им набор относительно низкоуровневых инструментов на основе которого они построили более высокоуровневые инструменты для дискретно-событийного моделирования. Никаких претензий на "парадигмы" и "философии" у них не было. Вот только современные мейнстримные ООЯ похожи на Симулу (типичный мейнстрим ООЯ отличается от симулы не больше, чем от другого типичного мейнстрим ООЯ), а не на Смолток.

Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.

K>>Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП,
I>То есть, старое неправильное это и есть симуловское ?

Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

I>Если так, то все в порядке. В смолтоковском появились практически все что нужно — философич, методология, паттерны, юниттесты, это и есть true ООП. Вопрос кто древнее не стоит

Имеет место быть адаптация, когда ритуал требует пальмовые ветви, но за неимением пальм используются ветви вербы, а наряжают елки.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>static chain всегда частный случай замыкания.

Не частный случай. Static chain позволяет реализовывать функции со свободными переменными, используя стек, UFP не решает, функции первоклассными не делает. Замыкание — это техника реализации первоклассных функций, подразумевает размещение данных в куче и требует управления временем жизни этого блока в куче.

Техники разные, преимущества и недостатки — разные, результат использования — разный. Не вижу никаких бенефитов от проведения аналогий — наоборот, будут только путаница и пустопорожние флеймы. Аналогия очевидно вредна: использование вложенных функций как замыканий приводит к UB, а именование их замыканиями в разговоре с другим программистом приводит к недопониманию и проблемам с коммуникацией.

I>То есть вложеные процедуры есть замыкания.

Замыкания — это либо пара из блока данных в куче и кода функции (техника), либо лямбда со свободными переменными (в противоположность комбинатору, у которого все переменные связаны), паскалевско-алголовские вложенные функции ни тем ни другим не являются.

I>Замыкания не обязательно вложеные процедуры.

И на что они "замыкаются", если никуда не вложены?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

K>>>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.
I>>Это важно, потому что смолток более современный. По крайней мере это ООП четко указывает, где его можно применять, а где нет и в результате это ООП дало практически все известные ООП-артефакты. В симуловском лепи какие хочешь классы и все дела.

K>Как раз почти все известные ООП-артефакты произошли скорее от Симулы, зато вся ООП-идеология от Смолтока. Создатели Симулы никакого "ООП" не изобретали, они разработали необходимый им набор относительно низкоуровневых инструментов на основе которого они построили более высокоуровневые инструменты для дискретно-событийного моделирования. Никаких претензий на "парадигмы" и "философии" у них не было. Вот только современные мейнстримные ООЯ похожи на Симулу (типичный мейнстрим ООЯ отличается от симулы не больше, чем от другого типичного мейнстрим ООЯ), а не на Смолток.

"вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали"

Мне кажется тут надо определиться.

JS, питон и руби это хоришие примеры мейнстримных языков ?

K>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.

Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

K>>>Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП,
I>>То есть, старое неправильное это и есть симуловское ?

K>Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

I>>Если так, то все в порядке. В смолтоковском появились практически все что нужно — философич, методология, паттерны, юниттесты, это и есть true ООП. Вопрос кто древнее не стоит

K>Имеет место быть адаптация, когда ритуал требует пальмовые ветви, но за неимением пальм используются ветви вербы, а наряжают елки.

Здравствуйте, Klapaucius, Вы писали:

K>Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным

Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков

Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

Здравствуйте, Klapaucius, Вы писали:

I>>static chain всегда частный случай замыкания.

K>Не частный случай. Static chain позволяет реализовывать функции со свободными переменными, используя стек, UFP не решает, функции первоклассными не делает. Замыкание — это техника реализации первоклассных функций, подразумевает размещение данных в куче и требует управления временем жизни этого блока в куче.

А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

K>Техники разные, преимущества и недостатки — разные, результат использования — разный. Не вижу никаких бенефитов от проведения аналогий — наоборот, будут только путаница и пустопорожние флеймы. Аналогия очевидно вредна: использование вложенных функций как замыканий приводит к UB, а именование их замыканиями в разговоре с другим программистом приводит к недопониманию и проблемам с коммуникацией.

UB это следствие хака, обход возможностей языка. Точно так же хаком можно повалить и замыкания. Проблемы с коммуникацией это сомнительный аргумент, как пример здесь три человека высказалось за тз отличную от твоей, а в поддержку высказалось тоже целых три человека

I>>То есть вложеные процедуры есть замыкания.

K>Замыкания — это либо пара из блока данных в куче и кода функции (техника), либо лямбда со свободными переменными (в противоположность комбинатору, у которого все переменные связаны), паскалевско-алголовские вложенные функции ни тем ни другим не являются.

Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

I>>Замыкания не обязательно вложеные процедуры.

K>И на что они "замыкаются", если никуда не вложены?

На пустой контекст.

Здравствуйте, Ikemefula, Вы писали:

I>А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками. Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.

I>UB это следствие хака, обход возможностей языка.

Ошибочная аналогия с замыканием — это и есть мотивация для хака. Из аналогии следует некоторая возможность, которую "хакер" и пытается реализовать.

I>Проблемы с коммуникацией это сомнительный аргумент, как пример здесь три человека высказалось за тз отличную от твоей, а в поддержку высказалось тоже целых три человека

Это и есть проблема с коммуникацией. Если бы одного мнения придерживался один человек, а другого — 100, то у сообщества не было бы проблемы с коммуникацией. Проблемы были бы только у этого одного.

K>>Замыкания — это либо пара из блока данных в куче и кода функции (техника), либо лямбда со свободными переменными (в противоположность комбинатору, у которого все переменные связаны), паскалевско-алголовские вложенные функции ни тем ни другим не являются.
I>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

Еще раз. Либо это конкретная техника — тогда проверяем наличие блоков данных в куче. Их нет — след. не замыкание.
Если имеется в виду лямбда со свободными переменными — проверяем, является ли вложенная функция "засахаренной" лямбдой. Передавать "наверх" нельзя — значит не является. Итого не является замыканием в обоих смыслах.

K>>И на что они "замыкаются", если никуда не вложены?
I>На пустой контекст.

Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>"вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали"

Мне кажется тут надо определиться.

Я же говорю — они были адаптированы под группу языков, которые большинством изобретателей вышеперечисленных и ООЯ-то не считаются.

I>JS, питон и руби это хоришие примеры мейнстримных языков ?

JS — мейнстрим и в каком-то смысле испытал влиание self. Питон и Руби не мейнстрим. В случае Руби влияние smalltalk есть, в случае питона я его в упор не вижу.

K>>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.
I>Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

Речь идет о направлении развития. Если бы философия и "естественность" было первичным — появилась бы сначала идея, а потом реализация. И были бы сложности с реализацией. Но первична была реализация — а идея подведена в качестве базы позднее. Мой пойнт в том, что нет вопроса об естественности, если по факту идея произошла из особенностей реализации фреймворка для дискретно-событийного моделирования. И именно это направление — причина успешного распространения симулалайк-ООП и главное его конкурентное преимущество.

I>Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным

Справедливости ради, неправильным его назвал Кей, а я не считаю, что одно из них правильнее другого.

I>Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков

Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

Смолток — тоже целая куча языков с кучей последователей. И objective c еще один язык действительно испытавший влияние смолтока. Только в случае "кучи смолтоков" мы не имеем "плотного кластера" — это языки, мягко говоря, друг на друга не похожие, варьирующиеся от обджектив-си, до эрланга. И в мейнстриме из них один два и все. В случае мейнстрим-ООП языки похожи, они практически "клоны" симулы, особенно по состоянию на конец 90-х и начала 2000-х, когда всякие ФП-фичи типа лямбд, параметрического полиморфизма и иммутабельных "объектов" не стало модно в такие языки добавлять.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

I>>А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

K>Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

И давно замыкания определяются через ПФ ? Если понимать замыкания как способ реализации языковых фич, то все понятно — есть ПФ, значит должен быть реализован общий случай. Нет ПФ — достаточно и частного, т.е. оптимизируем как угодно.

>Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.

не важно, это особенности реализации и оптимизации.

I>>UB это следствие хака, обход возможностей языка.

K>Ошибочная аналогия с замыканием — это и есть мотивация для хака. Из аналогии следует некоторая возможность, которую "хакер" и пытается реализовать.

Если человек не понимает что такое частный случай, а что общий, то у него кругом будут мотивации для хаков, не тольк здесь.

I>>Проблемы с коммуникацией это сомнительный аргумент, как пример здесь три человека высказалось за тз отличную от твоей, а в поддержку высказалось тоже целых три человека

K>Это и есть проблема с коммуникацией. Если бы одного мнения придерживался один человек, а другого — 100, то у сообщества не было бы проблемы с коммуникацией. Проблемы были бы только у этого одного.

То есть, если моего мнения будут придерживаться все, то проблемы в коммуникации будут. А если твоего — то нет. Так что ли ?

I>>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

K>Еще раз. Либо это конкретная техника — тогда проверяем наличие блоков данных в куче. Их нет — след. не замыкание.

Это детали реализации. Есть какая жОсткая спецификация, как должны реализовываться замыкания ?

K>Если имеется в виду лямбда со свободными переменными — проверяем, является ли вложенная функция "засахаренной" лямбдой. Передавать "наверх" нельзя — значит не является. Итого не является замыканием в обоих смыслах.

Передавать вверх == фича языка. У нас любой язык это минимальный набор фич (эффектов) которые нас интересуют. Нет фичи — нет и её поддержки. Это нормально.

K>>>И на что они "замыкаются", если никуда не вложены?
I>>На пустой контекст.

K>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?

"environment for the non-local variables" — т.е. количество variables == 0

Здравствуйте, Klapaucius, Вы писали:

I>>JS, питон и руби это хоришие примеры мейнстримных языков ?

K>JS — мейнстрим и в каком-то смысле испытал влиание self. Питон и Руби не мейнстрим. В случае Руби влияние smalltalk есть, в случае питона я его в упор не вижу.

Это почему питон и руби не мейнстрим ? В питоне ровно то же ООП что и в смалтоке, разная только реализация

K>>>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.
I>>Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

K>Речь идет о направлении развития. Если бы философия и "естественность" было первичным — появилась бы сначала идея, а потом реализация. И были бы сложности с реализацией. Но первична была реализация — а идея подведена в качестве базы позднее.

Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

>Мой пойнт в том, что нет вопроса об естественности, если по факту идея произошла из особенностей реализации фреймворка для дискретно-событийного моделирования. И именно это направление — причина успешного распространения симулалайк-ООП и главное его конкурентное преимущество.

Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП. А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало

I>>Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным

K>Справедливости ради, неправильным его назвал Кей, а я не считаю, что одно из них правильнее другого.

Одно ты назвал старым и неправильным, другое — его реформацией

То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ? Тогда выходит тебе не нравится ООП вообще, какое они ни было

I>>Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков

Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

K>Смолток — тоже целая куча языков с кучей последователей. И objective c еще один язык действительно испытавший влияние смолтока. Только в случае "кучи смолтоков" мы не имеем "плотного кластера" — это языки, мягко говоря, друг на друга не похожие, варьирующиеся от обджектив-си, до эрланга. И в мейнстриме из них один два и все.

А для чего тебе "плотный кластер", на что это влияет ?

>В случае мейнстрим-ООП языки похожи, они практически "клоны" симулы, особенно по состоянию на конец 90-х и начала 2000-х, когда всякие ФП-фичи типа лямбд, параметрического полиморфизма и иммутабельных "объектов" не стало модно в такие языки добавлять.

Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.

Здравствуйте, Ikemefula, Вы писали:

I>Если понимать замыкания как способ реализации языковых фич, то все понятно — есть ПФ, значит должен быть реализован общий случай. Нет ПФ — достаточно и частного, т.е. оптимизируем как угодно.

На колу мочало — начинай сказку сначала:

Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

>>Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.
I>не важно, это особенности реализации и оптимизации.

Оптимизация тут не при чем, а реализация важна, потому что она и обсуждается.

I>То есть, если моего мнения будут придерживаться все, то проблемы в коммуникации будут. А если твоего — то нет. Так что ли ?

Если определение общепринято — проблем с коммуникацией нет, в противном случае проблемы есть. От того какое именно определение общепринято это никак не зависит.

I>Это детали реализации.

Обсуждаемое значение слова "замыкание" — это название детали реализации.

I>Передавать вверх == фича языка. У нас любой язык это минимальный набор фич (эффектов) которые нас интересуют. Нет фичи — нет и её поддержки. Это нормально.

В реальном мире языки имеют не "набор фич (эффектов) которые нас интересуют", а некоторое его подмножество, из-за ограничений, накладываемых проблемами реализации. Другими словами, мы имеем не те фичи, которые нам нужны, а те из них, что можем себе позволить. Поэтому все наоборот: нет поддержки — нет и фичи. Вот это — нормально. А то что вы описали — это какой-то платоновский идеализм, в котором реализация — это тень фичи.

K>>>>И на что они "замыкаются", если никуда не вложены?
I>>>На пустой контекст.
K>>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?
I>"environment for the non-local variables" — т.е. количество variables == 0

Да, а каждый лысый — волосатый, просто с "пустой прической".

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

I>Это почему питон и руби не мейнстрим ?

По факту.

I>В питоне ровно то же ООП что и в смалтоке, разная только реализация

В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.

I>Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

В физике "и везде" бывает и наоборот — по подобранной модели предсказали эффект — обнаружили его, сопоставили свойства с предсказанными, не опровергли модель. Но аналогия с физикой ложная. Физика изучает реальный мир, а ООП — инженерная методика (это в лучшем случае), она ничего кроме себя самой не изучает.

I>Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП.

Эта "сильная ограниченность" и является конкурентным преимуществом.

I>А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало

А проблемы с дизайном прямое следствие идеологии, которая от смолтока идет.

I>Одно ты назвал старым и неправильным, другое — его реформацией

То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ?

Да. И я иронизирую над "правильным реформированным ООП" смолтокеров потому, что оно не решило проблем ООП, но создало новые проблемы как раз с тем, с чем у ООП первоначально было все хорошо — простотой реализации. Формально, конечно, реализовать смолток проще — наивная реализация чуть ли не на один экран поместится. Вот только практически полезная реализация — это настоящий рокет сайенс.

I>Тогда выходит тебе не нравится ООП вообще, какое они ни было

Мне вообще все не нравится, а ООП — побольше среднего прочего.

I>А для чего тебе "плотный кластер", на что это влияет ?

Это показатель жизнеспособности идеи, если можно и через 50 лет "продавать" то же самое, но с перламутровыми пуговицами.

I>Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.

До смолтока C#-у как до Луны. И это, кстати, не недостаток.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>На колу мочало — начинай сказку сначала:
K>

K>Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

Замыкания есть реализация ПФ, а неумение ПФ есть наблюдаемый эффект без замыканий. Очень познавательно, спасибо, это называется порочный круг и смысла не имеет, повторяй ты эхто сколько хочешь раз.

K>В реальном мире языки имеют не "набор фич (эффектов) которые нас интересуют", а некоторое его подмножество, из-за ограничений, накладываемых проблемами реализации. Другими словами, мы имеем не те фичи, которые нам нужны, а те из них, что можем себе позволить. Поэтому все наоборот: нет поддержки — нет и фичи. Вот это — нормально. А то что вы описали — это какой-то платоновский идеализм, в котором реализация — это тень фичи.

Ну вообще говоря язык проектируется под определенный набор фич,а точнее под определенные задачи, которые могут требовать, а могут и не требовать полноценные фичи.

I>>>>На пустой контекст.
K>>>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?
I>>"environment for the non-local variables" — т.е. количество variables == 0

K>Да, а каждый лысый — волосатый, просто с "пустой прической".

лысый это человек у котрого растительность на голове удовлетворяет определенному критерию. Ничего смешного, это математика.

Здравствуйте, Klapaucius, Вы писали:

I>>Это почему питон и руби не мейнстрим ?

K>По факту.

Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

I>>В питоне ровно то же ООП что и в смалтоке, разная только реализация

K>В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.

Если смотреть внутрь реализации, то окажется что все мы пишем на ассемблере.

I>>Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

K>В физике "и везде" бывает и наоборот — по подобранной модели предсказали эффект — обнаружили его, сопоставили свойства с предсказанными, не опровергли модель. Но аналогия с физикой ложная. Физика изучает реальный мир, а ООП — инженерная методика (это в лучшем случае), она ничего кроме себя самой не изучает.

Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.

I>>Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП.

K>Эта "сильная ограниченность" и является конкурентным преимуществом.

Ты почему то ничего не говоришь про задачи у тебя популярность растет сама по себе, как будто является свойством семейства языков.
ЯП появились как инструмент решения задач. раньше это в основном обработка данных, отсюда неудивительно что популярная парадигма будет data-centric, что вобщем то и есть симуловское ООП.
С ростом сложности софта, которая ка известно растет нелинейно, data-centric себя исчерпал. Появились сложные задачи не ориентированые на обработку данных. Отсюда понятно, что популярными будут языки ориентированые на новые задачи, например — взаимодействие, вычисления самой разной природы и тд и тд.

Смалтоковское ООП оно полностью завязано на поведение и взаимодействие. В data-centriс это тоже можно, но в смалтоковской парадигме это намного проще. При чем весь data-centric полностью укладывается в смалтоковскую парадигму.

I>>А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало

K>А проблемы с дизайном прямое следствие идеологии, которая от смолтока идет.

Это разница между парадигмами. Симуловское ООП ориентировано на обработку данных. Смалтоковское — на поведение и взаимодействие. Отсюда понятны причины косяков в дизайне — описывая взаимодействие в духе симуловского ООП неизбежно будут рождаться монстры.
В то время как смалтоковское позволяет вполне сносно обрабатывать данные, максимум — незначительно в ущерб перформансу.

I>>Одно ты назвал старым и неправильным, другое — его реформацией

То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ?

K>Да. И я иронизирую над "правильным реформированным ООП" смолтокеров потому, что оно не решило проблем ООП, но создало новые проблемы как раз с тем, с чем у ООП первоначально было все хорошо — простотой реализации.

Если бы привел задачи, то еще можно было бы понять. Но в отрыве от типичных задч как то странно слушать про "простоту реализации".

>Формально, конечно, реализовать смолток проще — наивная реализация чуть ли не на один экран поместится. Вот только практически полезная реализация — это настоящий рокет сайенс.

Формально языки были направлены на самые разные задачи. Обработка данных со сцены не девается, это объясняет популярность С++, более того, никуда и не денется, отсюда ясно, что С++ потеснит только более производительный аналог в симуловской концепции.

Сложность поведения и взаимодействия компонентов только растет, а это значт что смалтоковская концепция популярности тоже не теряет, что видно на примере JS, питона, руби.

Вычислительные задачи самой разной природы дают результат в виде популярности функциональных языков.

I>>Тогда выходит тебе не нравится ООП вообще, какое они ни было

K>Мне вообще все не нравится, а ООП — побольше среднего прочего.

Вероятно ты просто решаешь другие задачи, в которых ООП непригодно. Скажем начни ты в хаскеле поднимать xml, скорее всего умрёшь от натуги. А старый гнусный С++ рвёт здесь всех конкурентов, кроме специализированых под xml реализаций.

I>>А для чего тебе "плотный кластер", на что это влияет ?
K>Это показатель жизнеспособности идеи, если можно и через 50 лет "продавать" то же самое, но с перламутровыми пуговицами.

Чушь. Популярность не является свойством семейства, эта популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

I>>Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.
K>До смолтока C#-у как до Луны. И это, кстати, не недостаток.

Я и не говорил, что C# это смалток. Я говорю что в ём можно отлично реализовать концепцию смалтоковского ООП, естественно ,будет чуток многословно, побольше чем на питоне, но терпимо.

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.

SV.>Примеры. Допустим, некто спрашивает, зачем нужно наследование интерфейсов. Я привожу пример, когда оно нужно.

Думаю, что истинное понимание ООП приходит уже будучи ОО-проектировщиком. Хоть чисто в домашних условиях, например книга "Применение UML"-Лармана,
перевернуло мое представление о создании программ. У него описано, что истоки нужно искать в реальном мире, составляя так называемые use-case'ы. Реальные случаи использования системы.
А из них выделять существительные (классы) и глаголы (методы). Это само собой не все ООП, но суть такова.

Здравствуйте, Ikemefula, Вы писали:

I>Ну вообще говоря язык проектируется под определенный набор фич, а точнее под определенные задачи

И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?
Обсуждаемые вложенные функции получились просто: разработчики алгола хотели получить практически полезный язык и считали, что сборщик мусора они себе позволить не могут. Поэтому они изобрели стек, реализовали рекурсию (раньше рекурсию умели только с помощью хипа реализовывать) и постарались выжать из этого изобретения все что можно. И функции, которые можно передавать только "вниз" — один из результатов такого выжимания. Они такие не потому, что нужны именно такие, а потому, что другие их создатели себе позволить не могли.

Про проектирование языков под определенные задачи, которого в реальности не существует ответил развернуто здесь

K>>Да, а каждый лысый — волосатый, просто с "пустой прической".
I>лысый это человек у котрого растительность на голове удовлетворяет определенному критерию. Ничего смешного, это математика.

Это смешно, потому, что критерий смешной и обобщение бесполезно. Нет никакого применения для обобщения замыканий и не замыканий введением "пустого контекста". Ну, кроме как насмешить собеседника в форумном диспуте.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

I>>Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

K>А по-моему, можно игнорировать рассуждения о мейнстриме человека, который считает, что руби — это мейнстрим.

Мейнстрим это задачи, а не ЯП. ЯП это уже следствие.

I>>Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.
K>Это, скорее, в тему соседней ветки, где предсказывающий эффект по модели "замыкание" получает UB.

Так ты определись, можно ли модели предсказывать или нет

I>>популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

K>Я об этом ниразу не сказал, потому что считаю это неправильным.
K>1) Не наблюдается никакой связи между тем, для чего язык разрабатывался и тем, для чего он применяется.

Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

K>Это объяснимо, конечно, потому что большинство языков, не смотря на заявляемую когда-то авторами "принадлежность", не имеют никакой специализации и являются языками общего назначения. Даже когда язык действительно специализирован — эта спецуиализация по мере развития разбавляется совершенно посторонними фичами. В SQL добавляют императивные конструкции, регулярные выражения перестают быть регулярными и т.д.
K>Подавляющее большинство языков не заточены под какую-то нишу.

Это заблуждение. Проверяется очень легко — берешь одну и ту же задачу и пишешь на самых разных ЯП. В одних языка решения будут простые и работать будут очень эффективно, в других будет нагромождение кода и фатальное проседание производительности.

K>2) Выбор языка определяется, в основном, возможностью нанять программиста на этом языке. Разумеется, имеющаяся в таком подходе положительная обратная связь раздувает любую флуктуацию до космических масштабов и делает популярность языка случайной. Невозможно предсказать какой из языков станет популярным, а какой канет в забвение: A или A', который от A отличается оттенком перламутровых пуговиц.

Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

K>3) Если же язык выбирают по техническим причинам, то выбирают не языки, а реализации и инфраструктуру, причем набор неигрушечных реализаций для нужных платформ часто вообще отсутствует. Понятно, что и тут положительная обратная связь, выхватывающая из шума случайный кактус и заставляющая его есть десятилетиями.

Правильно, я и говорю — язык это следствие. А главное это задачи.

K>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.

Это непроверяемо и нефальсифицируемо, так шта...

K>Сдвиг парадигмы не происходит от изменения задач, а ппоисходит от развития техники, которая начиная с какого-то момента позволяет иметь новый уровень удобств. ООП стал популярен, когда его стало можно себе позволить. И ФП становится популярным в последнее время по этим же причинам. Смолток просто морально устарел раньше, чем его смогли себе позволить использовать значительное количество программистов — вот и все.

Предложи как это можно проверить и фальсифицировать, тогда можно и продолжить.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

I>>Ну вообще говоря язык проектируется под определенный набор фич, а точнее под определенные задачи

K>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?

Обработка данных.

K>Обсуждаемые вложенные функции получились просто: разработчики алгола хотели получить практически полезный язык и считали, что сборщик мусора они себе позволить не могут. Поэтому они изобрели стек, реализовали рекурсию (раньше рекурсию умели только с помощью хипа реализовывать) и постарались выжать из этого изобретения все что можно.

Стек был изобретен задолго до алгола.

>И функции, которые можно передавать только "вниз" — один из результатов такого выжимания. Они такие не потому, что нужны именно такие, а потому, что другие их создатели себе позволить не могли.

Это неважно.

K>Это смешно, потому, что критерий смешной и обобщение бесполезно. Нет никакого применения для обобщения замыканий и не замыканий введением "пустого контекста". Ну, кроме как насмешить собеседника в форумном диспуте.

Это уменьшает количество понятий.

Здравствуйте, Ikemefula, Вы писали:

I>Мейнстрим это задачи, а не ЯП.

Не согласен. Задачи у мейнстрима как раз меняются, а характерные свойства инструментария и культуры производства остаются.

I>ЯП это уже следствие.

ЯП из задачи никак не следует.

I>Так ты определись, можно ли модели предсказывать или нет

По адекватной модели — можно конечно.

I>Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

Т.е. создатели языка не в состоянии определить его "пригодность" к чему-то на этапе дизайна? Ну это и не возражение вовсе. Если бы существовала реальная, а не воображаемая связь между свойствами языка и классом задач, для решение которых нужны как раз такие свойства — можно было бы "вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка. Это сделао бы вашу теорию проверяемой. Но это все фантастика, а значит связь эта — ничем не подтвержденные измышления.

K>>Подавляющее большинство языков не заточены под какую-то нишу.
I>Это заблуждение. Проверяется очень легко — берешь одну и ту же задачу и пишешь на самых разных ЯП.

То, что одни языки позволяют решать данную задачу меньшим объемом кода, чем другие я как раз не отрицаю. Вот только язык, на котором можно решить короче и понятнее задачу A, чем на сравниваемом языке, обгонит этот язык и на подавляющем большинстве других задач.
Это утверждение вполне проверяемо.
То что действительно заточено под задачу — это библиотека. И сравнивать по "заточенности" под определенную задачу имеет смысл наборы библиотек, а не языки. А у языков общего назначения одна задача — разработка библиотек. В одних языках разработка библиотек легче, в других — сложнее. Разумеется, "плохой" по этому критерию, но старый язык будет какое-то время иметь лучший набор библиотек, чем "хороший" и новый, пока (если) последний не догонит и не перегонит.
Также возможна специализация языка под решение. Конкретное решение на одном языке вполне может быть хуже другого.

I>В одних языка решения будут простые и работать будут очень эффективно, в других будет нагромождение кода и фатальное проседание производительности.

А вот это уж точно фантастика. В реальном мире обычно наоборот: код либо компактный и понятный, но тормозной — либо уродливый и многословный, но быстрый, либо и уродливый и тормозной. До красивого и быстрого кода индустрии еще далеко.

I>Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

А теперь перенесите C и PHP (ну, может питон еще) из второй кучи в первую и вторую кучу будет видно разве только в микроскоп.

I>Правильно, я и говорю — язык это следствие. А главное это задачи.

Если бы это было так, то существовал настоящий "зоопарк" сильно различающихся языков, каждый из которых живет в одной нише. В реальности мы наблюдаем небольшой набор очень похожих языков, использующихся для почти всего, при том что "почти" определяется качеством (и наличием) реализации под нужную платформу, а вовсе не свойствами языка. Или вы какую-то другую картину выводите из своей теории-специализации-под-задачу?

K>>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
I>Это непроверяемо и нефальсифицируемо, так шта...

Ну почему? Эта теория дает вполне проверяемые предсказания. Например, ФЯ, когда (и если) получат технически приемлимые реализации и инфраструктуру будут доминировать в большинстве областей вне зависимости от задачи, а на сохранившихся ООЯ будут эмулировать ФП, точно так же как ООЯ вытеснили СЯ, а на оставшихся эмулируют ООП сейчас. Если же упомянутые требования не выполнятся — никаких сдвигов парадигм не произойдет вне зависимости от смены "задач".
Скорость же сдвига будет определяться упомянутой мной кадровой инерцией, а не темпом изменения "задач".

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

K>>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?
I>Обработка данных.

Что за обработка данных? Или это опять "обобщенная задача" которая в себя вообще все включает?
Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?

I>Стек был изобретен задолго до алгола.

Да неужели?

>>И функции, которые можно передавать только "вниз" — один из результатов такого выжимания. Они такие не потому, что нужны именно такие, а потому, что другие их создатели себе позволить не могли.
I>Это неважно.

Если это не важно — что вообще важно? Я показываю на реальных примерах причины, по которым языки становятся такими, какими становятся.

I>Это уменьшает количество понятий.

Зачем? Какая от этого польза?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

I>>Мейнстрим это задачи, а не ЯП.

K>Не согласен. Задачи у мейнстрима как раз меняются, а характерные свойства инструментария и культуры производства остаются.

I>>ЯП это уже следствие.
K>ЯП из задачи никак не следует.

Как только в индустрии появляется некотороем множество сходных задач, то ответом становится популярность одного или нескольких языков которые позволяют решать такие задачи или даже создание нового языке нацеленого на это семейство задач.

I>>Так ты определись, можно ли модели предсказывать или нет

K>По адекватной модели — можно конечно.

Значит ООП дает адекватную модель

I>>Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

K>Т.е. создатели языка не в состоянии определить его "пригодность" к чему-то на этапе дизайна?

Создатели в состоянии определить пригодность для насущных задач. Для тех задач, про которые они еще не знают — нет, не могут.

>Ну это и не возражение вовсе. Если бы существовала реальная, а не воображаемая связь между свойствами языка и классом задач, для решение которых нужны как раз такие свойства — можно было бы "вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка. Это сделао бы вашу теорию проверяемой. Но это все фантастика, а значит связь эта — ничем не подтвержденные измышления.

Она уже давно есть, здесь не надо ничего придумывать.

K>То, что одни языки позволяют решать данную задачу меньшим объемом кода, чем другие я как раз не отрицаю. Вот только язык, на котором можно решить короче и понятнее задачу A, чем на сравниваемом языке, обгонит этот язык и на подавляющем большинстве других задач.
K>Это утверждение вполне проверяемо.

Конечно. Проверяем на SQL. В своих задачах он рвёт в хлам любые языки. Попробуй использовать его для обработки данных, рендеринга, вычислений, UI ... SQL cдох вместе с твоей теорией.

Берём Хаскель и делаем всякие вычисления — хаскель крут. грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI — хаскель сдох вместе с твоей теорией.

I>>В одних языка решения будут простые и работать будут очень эффективно, в других будет нагромождение кода и фатальное проседание производительности.

K>А вот это уж точно фантастика. В реальном мире обычно наоборот: код либо компактный и понятный, но тормозной — либо уродливый и многословный, но быстрый, либо и уродливый и тормозной. До красивого и быстрого кода индустрии еще далеко.

Красивый код это твой термин и ты сам его притянул. Для запросов к базе пока трудно найти замену SQL — здесь все компактно, понятно и быстро — порвать SQL по перформансу крайне сложно.
Низкоуровневые операции — на С++ это просто и компактно да еще и быстро. Порвать С++ здесь вряд ли получится.

I>>Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

K>А теперь перенесите C и PHP (ну, может питон еще) из второй кучи в первую и вторую кучу будет видно разве только в микроскоп.

А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

I>>Правильно, я и говорю — язык это следствие. А главное это задачи.

K>Если бы это было так, то существовал настоящий "зоопарк" сильно различающихся языков, каждый из которых живет в одной нише.

Этот зоопарк уже давно существует

K>>>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
I>>Это непроверяемо и нефальсифицируемо, так шта...

K>Ну почему? Эта теория дает вполне проверяемые предсказания. Например, ФЯ, когда (и если) получат технически приемлимые реализации и инфраструктуру будут доминировать в большинстве областей вне зависимости от задачи, а на сохранившихся ООЯ будут эмулировать ФП, точно так же как ООЯ вытеснили СЯ, а на оставшихся эмулируют ООП сейчас.

Вообще говоря у них уже есть эти самые приемлемые реализации и инфраструктура, кроме некоторых лабораторных языков вроде хаскеля.

>Если же упомянутые требования не выполнятся — никаких сдвигов парадигм не произойдет вне зависимости от смены "задач".
K>Скорость же сдвига будет определяться упомянутой мной кадровой инерцией, а не темпом изменения "задач".

Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

Здравствуйте, Ikemefula, Вы писали:

I>Она уже давно есть, здесь не надо ничего придумывать.

Если есть — предъявляйте упомянутый способ ""вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка."

I>Проверяем на SQL.

SQL я упомянул как один из немногих исключений. Это ДСЛ. Вы же говорили о "специализации" языков общего назначения.

I>Берём Хаскель и делаем всякие вычисления — хаскель крут.

Вычисления? Вы шутите?

I>грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI

А это, опять таки упомянутое, сравнение набора библиотек.

I>Низкоуровневые операции — на С++ это просто

Как бы не так. С чем сравнивали?

I>и компактно

Да уж, конечно. С чем сравнивали?

I>да еще и быстро. Порвать С++ здесь вряд ли получится.

Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.

I>А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

Попробуйте сначала найти ее без микроскопа, а потом можно решить — перекидывать или нет.

K>>Если бы это было так, то существовал настоящий "зоопарк" сильно различающихся языков, каждый из которых живет в одной нише.
I>Этот зоопарк уже давно существует

Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.

I>Вообще говоря у них уже есть эти самые приемлемые реализации и инфраструктура, кроме некоторых лабораторных языков вроде хаскеля.

Какие еще ФЯ, кроме "некоторых лабораторных"?

I>Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

Потому, что это DSL, которые специализированы по определению. Вы же утверждали, что языки общего назначения выбирают по задаче.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>>>И вас, конечно, не затруднит перечислить эти определенные задачи, которые требуют возможности передавать функцию "вниз", но не требуют передавать "вверх"?
I>>Обработка данных.

K>Что за обработка данных? Или это опять "обобщенная задача" которая в себя вообще все включает?

сбор, ввод, хранение, накопление, поиск, контроль, передача, представление.

K>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?

Потому что в большинстве этих задач ресурсы и вычисления нужно описывать и контролировать явно.

I>>Стек был изобретен задолго до алгола.

K>Да неужели?

В Алголе стек всего лишь получил специальную поддержку в процессоре:

Algol 60 would have been impossible to adequately process in a reasonable way without the concept of
stacks. Though we had stacks before, only in Algol 60 did stacks come to take a central place in the
design of processors.

K>Если это не важно — что вообще важно? Я показываю на реальных примерах причины, по которым языки становятся такими, какими становятся.

Потому что ты не рассматриваешь причины, по которым ЯП вообще появились и почему они востребованы до сих пор. То есть у тебя ЯП сами по себе, в вакууме, да еще с неотъемлимым свойством "популярность" которое меняеся само по себе.

I>>Это уменьшает количество понятий.

K>Зачем? Какая от этого польза?

Бритва Оккама утратила актуальность ? Не знал

Здравствуйте, Klapaucius, Вы писали:

I>>Она уже давно есть, здесь не надо ничего придумывать.

K>Если есть — предъявляйте упомянутый способ ""вычислять" язык из задачи или наоборот, "вычислять" задачу, для которой язык подходит лучше всего по свойствам данного языка."

I>>Проверяем на SQL.

K>SQL я упомянул как один из немногих исключений. Это ДСЛ. Вы же говорили о "специализации" языков общего назначения.

I>>Берём Хаскель и делаем всякие вычисления — хаскель крут.

K>Вычисления? Вы шутите?

Вычисления и прочие алгоритмические задачи.

I>>грузим XML, пишем вебсайт со всеми потрохами, мобильное, серверное с богатым UI

K>А это, опять таки упомянутое, сравнение набора библиотек.

Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

I>>Низкоуровневые операции — на С++ это просто

K>Как бы не так. С чем сравнивали?

С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

I>>и компактно

K>Да уж, конечно. С чем сравнивали?

см выше.

I>>да еще и быстро. Порвать С++ здесь вряд ли получится.

K>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!

Не правильно. См выше.

K>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.

Очень просто, С это всегда С++, С++ не всегда С.

I>>А еще лучше всю вторую кучку перекинуть в первую,это даст неоспоримое доказательство твоей теории.

K>Попробуйте сначала найти ее без микроскопа, а потом можно решить — перекидывать или нет.

I>>Этот зоопарк уже давно существует

K>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.

Если точнее, то такого никогда не было.

I>>Вообще говоря у них уже есть эти самые приемлемые реализации и инфраструктура, кроме некоторых лабораторных языков вроде хаскеля.

K>Какие еще ФЯ, кроме "некоторых лабораторных"?

Erlang, Ocaml

I>>Почему то эта кадровая инерция не мешала появлению шейдеров с возникновением видеокарт, не мешала появлению SQL c возникновением реляционных БД, не мешала распространению js+css с распростренением браузеров

K>Потому, что это DSL, которые специализированы по определению. Вы же утверждали, что языки общего назначения выбирают по задаче.

Конечно. Напиши драйвер на хаскеле, питоне, руби... Можешь даже на дельфи попробовать — реализуемо, но в своем уме никто этим не занимается.

Здравствуйте, icWasya, Вы писали:

I>>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

W>Язык (Object Pascal,Delphi) — вообще запрещает передавать вложеные процедуры куда бы то ни было

Почти. Вниз все работает:

program test;
uses crt;
type
  MegaProc = procedure(s:string);

  procedure Main;


    procedure Suxx(p:Pointer);
              var proc:MegaProc;
    begin
     proc := MegaProc(p);

     proc('hello world');
    end;

    procedure Print(s:string);far;
    begin
     WriteLn(s);
    end;


  begin


    Suxx(@Print); {вызываем вложеную и передем как параметр вложуную}
  end;

  begin
  Main;
end.

Здравствуйте, grosborn, Вы писали:

G>Кстати, есть хороший пример, как люди крупно облажались с ООП подходом "моделируя реальность".
G>WinForms — каждый раз при изменении размера визуального компонента каскадно вызываются множественные перерасчеты. Конечно до модели взаомодействия молекул в луже там далеко, но немного похоже. Модель крайне неэффективная и работает очень медленно. Ага, и им пришлось еще модельку ломать, что бы хоть как-то криво заработало, но результат-то все-равно печальный.
Да, для меня это пример грустного юмора.
Когда начинается поиск примеров задач, для которых ООП позволяет в полный рост "моделировать реальный мир", то как раз оконный UI выходит на первый план. Всё здорово — окна-объекты обмениваются сообщениями; идентичность и инкапсуляция в полный рост. Всё как Кей сказал.

А потом внезапно мы обнаруживаем, что гуй, построенный из большого количества "чёрных ящиков", работает медленно и плохо.
Гораздо эффективнее иметь полностью прозрачную модель, когда рендерер "видит" все элементы, и вместо каскадных перерасчётов делает всё в один проход. Вот такое вот внезапно.

Здравствуйте, licedey, Вы писали:

L>перевернуло мое представление о создании программ. У него описано, что истоки нужно искать в реальном мире, составляя так называемые use-case'ы. Реальные случаи использования системы.
L>А из них выделять существительные (классы) и глаголы (методы). Это само собой не все ООП, но суть такова.
Надо почитать. Пока что звучит страшно: очередная попытка пропихивания мисконцепций авторитетом.

Здравствуйте, Sinclair, Вы писали:

S>А потом внезапно мы обнаруживаем, что гуй, построенный из большого количества "чёрных ящиков", работает медленно и плохо.
S>Гораздо эффективнее иметь полностью прозрачную модель, когда рендерер "видит" все элементы, и вместо каскадных перерасчётов делает всё в один проход. Вот такое вот внезапно.

Это тоже нормально реализуется в ООП

Здравствуйте, Ikemefula, Вы писали:

I>Это тоже нормально реализуется в ООП

Но не в таком ООП, которое приходит в голову наивному проектировщику. Обработка WM_PAINT тысячами WindowProc — это худший способ добиться результата.

Здравствуйте, Ikemefula, Вы писали:

K>>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?
I>Потому что в большинстве этих задач ресурсы и вычисления нужно описывать и контролировать явно.

Ну, допустим, нужно. Почему требуется передача функций "вниз"? Почему не требуется "вверх"?

I>В Алголе стек всего лишь получил специальную поддержку в процессоре:

Так в Алголе или в процессоре? Да, аппаратная поддержка стека появилась после Алгола. Вы это хотели сказать? Ну и понятно почему. Это первый язык для которого она бы пригодилась.
Не понятно о каком "всего лишь" можно говорить, стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп).

I>Потому что ты не рассматриваешь причины, по которым ЯП вообще появились и почему они востребованы до сих пор.

Ну разумеется я рассматриваю эти причины.

I>То есть у тебя ЯП сами по себе, в вакууме, да еще с неотъемлимым свойством "популярность" которое меняеся само по себе.

Сами по себе они у вас. У меня они как раз рассматриваются без отрыва от реальности. ЯП нужны для написания библиотек. Это их единственная "специализация". Одни лучше для этого подходят — другие хуже. Почему хуже? Потому что на определенном этапе не было технической возможности сделать лучше. Есть тенденция переходить на языки, которые подходят для этого лучше, после того, как эти улучшения можно себе позволить. С поправкой на кадровую и инфраструктурную "инерции". Ответ на появление новых задач — это появление новых библиотек (и ДСЛ-ей, которые, если встроены — вообще мало чем от библиотек отличаются). Языки общего назначения в ответ на появление нового класса задач не появляются.

K>>Зачем? Какая от этого польза?
I>Бритва Оккама утратила актуальность ?

Разумеется не утратила. Поэтому я и спрашиваю: зачем? какая от этого польза? В ответ на введение бессмысленного объединения замыкания-и-не-замыкания-все-вместе со всякими "пустыми контекстами".

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

I>>Потому что ты не рассматриваешь причины, по которым ЯП вообще появились и почему они востребованы до сих пор.
K>Ну разумеется я рассматриваю эти причины.

Надо определиться имеют ли смысл ЯП в отрыве от задач. Если имеют, то так и пиши и здесь обсуждать нечего, я просто буду игнорировать все твои сообщения. Если не имеют, то не ясно, почему ты отказываешься рассматривать задачи.

Тут снова надо определиться. Не можешь или счиашешь, что ЯП имеет смысл в отрыве от задач — просто не пиши ничего.

K>>>Почему обработка данных требует передачу функций "вниз"? Почему не требует передачу "вверх"?
I>>Потому что в большинстве этих задач ресурсы и вычисления нужно описывать и контролировать явно.
K>Ну, допустим, нужно. Почему требуется передача функций "вниз"? Почему не требуется "вверх"?

Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

I>>В Алголе стек всего лишь получил специальную поддержку в процессоре:

K>Так в Алголе или в процессоре? Да, аппаратная поддержка стека появилась после Алгола. Вы это хотели сказать? Ну и понятно почему. Это первый язык для которого она бы пригодилась.
K>Не понятно о каком "всего лишь" можно говорить, стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп).

Я привел цитату, читай внимательно. Если ты не веришь разработчику алгола, то о чем можно спорить ? Внятно сказано — стек был и до алгола, с алголом он получил поддержку в процессоре. Всё.

I>>То есть у тебя ЯП сами по себе, в вакууме, да еще с неотъемлимым свойством "популярность" которое меняеся само по себе.

K>Сами по себе они у вас. У меня они как раз рассматриваются без отрыва от реальности.

Странно, но про задачи только я пишу, а ты в принципе отказываешь рассматривать то, благодаря чему ЯП актуальны.

>ЯП нужны для написания библиотек. Это их единственная "специализация". Одни лучше для этого подходят — другие хуже. Почему хуже? Потому что на определенном этапе не было технической возможности сделать лучше. Есть тенденция переходить на языки, которые подходят для этого лучше, после того, как эти улучшения можно себе позволить. С поправкой на кадровую и инфраструктурную "инерции". Ответ на появление новых задач — это появление новых библиотек (и ДСЛ-ей, которые, если встроены — вообще мало чем от библиотек отличаются). Языки общего назначения в ответ на появление нового класса задач не появляются.

Напиши хорошую библиотеку на хаскеле с помощью которой можно будет легко и эффективно обрабатывать что нибудь из видео, текст, графику, звук и тд.

K>>>Зачем? Какая от этого польза?
I>>Бритва Оккама утратила актуальность ?

K>Разумеется не утратила. Поэтому я и спрашиваю: зачем? какая от этого польза? В ответ на введение бессмысленного объединения замыкания-и-не-замыкания-все-вместе со всякими "пустыми контекстами".

Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.
Пустой контекст это просто конкретный случай а не новое понятие. Точно так же можно сказать пустой клас, пустая функция, пустая лямбда и тд и тд.

Здравствуйте, Klapaucius, Вы писали:

K>Все тот же случай "не можем себе позволить" и соревнующийся сам с собой C.

Вместо просты и понятных терминов "предназначен", "пригоден", "соответствует" ты несешь какую то ахинею "не можем себе позволить" и не можешь внятно даже пояснить, что заключается в этом термине, он у тебя вообще всё объясняет.
У каждого решения есть свойства — для тебя наверняка это новость. Потому вместо "можем себе позволить" нужно думать в направлении "соответствие", "свойства", "требования" а требования естественно, берутся из задачи.
Пока ты будешь повторять свою мантру "не можем себе позволить" смысла продолжать нет.

Полагаю, ты сделал для себя выбор — повторять мантру или нет.

K>Вы всерьез считаете, что хаскель в нынешнем состоянии "крут для вычислений"? А что вы подразумеваете под "неалгоритмическими" задачами? И почему хаскель, по-вашему, не крут для них?

Конечно. Позволяет вводить высокоуровневые оптимизации и здесь предела практически нет, в отличие от задач обработки данных. "неалгоритмические задачи" — в моем сообщении такого термина нет.

I>>Напиши на чистом хаскеле самый быстрый парсер XML и посмотри на результат.

K>Результат будет не хуже чем в среднем по компилируемым языкам, не считая небольшого числа языков в имплементации которых были вложены основные усилия вроде C++.

"В среднем" это неинтересно. Те же C# и Java порвут хаскель просто в хлам. Отсюда ясно, что C# и Джава более пригодны для этих задач, нежели хаскель.

I>>С самыми разными языками, на которых мне доводилось работать. Можешь меня опровергнуть — покажи хорошую массовую ОС писаную не на С/C++, достаточно одного примера.

K>Ну, для написания ОС нельзя (с незначительными в контексте дискуссии оговорками) ничего себе позволить кроме C++ и C. Значит и сравнивать можно только С++ с C. Т.е. пример это вырожденный — если бы были ОС с равной функциональностью на разных языках — можно было бы сравнивать код и определить какой язык лучше подходит. Но в условиях, когда выбор языка себе прозволить нельзя — и сравнивать нечего.

Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.

Давай не ОС, а обработку изображений, звука, видео, текст ? Что, и здесь плохо, опять С++ мешает ? Ну ладно, берем гигантски пакеты вроде Офиса. Тут вроде бы ничего не мешает. Как ты будешь описывать АПИ взаимодействия компонентов на хаскеле ? Наверное тебе нравится такой вариант "плагины для ХаскельОфис можно писать только на хаскеле"

I>>>>и компактно
I>>см выше.

K>Что это за язык такой, на котором код менее компактный, чем на C++? Брейнфак? Лисп? C? Java? Вот, пожалуй и все — на остальных будет компактнее.

Я уже говорил, берешь задачу и требования — функциональные, нефункциональные. Реализуешь, меряешь. Реализовал, результат удовлетворяет — язык пригоден. Не реализовал — не пригоден. Реализовал, результат неудовлетворяет — язык не пригоден.

K>>>Правильно. Есть быстрая реализация. Других подходящих реализаций нет, так что сравнивали C++ с C++-ом. Естественно он победил!
I>>Не правильно. См выше.

K>Да все правильно. Выше и сравнивается C++ с самим собой.

См выше, про мантру.

K>>>А как ваша теория объясняет то, что не то что на C++, а вовсе на C пишут не только "низкоуровневый" софт.
I>>Очень просто, С это всегда С++, С++ не всегда С.
K>Во-первых, С — это не всегда С++, ну да ладо. Вопрос то не в этом. Вопрос в том, что если ниша C++ — низкоуровневый код, то как объяснить то, что на нем пишут не только операционные системы (BeOS), но и, например, почтовые клиенты (Thunderbird), поисковые движки (Google), компиляторы (clang), софт для марсохода?

Пока пишут, и доля С++ в этих областях сокращается. Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.

> В ответ на какой вызов "появился" C++? Когда возникла задача "написание операционнх систем"? "Написание почтовых клиентов"? "Написание поисковых движков"? "Написание компиляторов"? "Программирование марсоходов"? Ведь по вашей теории все это просто не может быть написано на одном языке — иначе языки общего назначения действительно языки общего назначения, как утверждаю я, а не "нишевые", как утверждаете вы. Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?

Ты вероятно вообще не читаешь то о чем я пишу. С++ распространился в ответ на растущую сложность программ + сохранил все ниши что были за С.

K>Как ваша теория объясняет, например, написание интернет-магазина Гремом на лиспе, а потом его переписывание на C++?

Чисто экономические причины. Думаю вместо лиспа мог бы быть какой угодно язык, в т.ч. С++. Яха купил фактически пользовательскую базу, то есть бизнес, а сам язык никого не интересует, абы работало.

K>В рамках моей теории это все естественно. На C++ переходят, когда (считают что) могут себе это позволить. К примеру, разработчики gcc могут позволить с 14-го числа этого месяца. А когда могут себе позволить что-то более продвинутое — начнут использовать это что-то. Если же "продвинутое" позволить себе уже нельзя — откатываются вниз.

"могут позволить" это практически "теория всего".

K>>>Вы, как будто с другой планеты пишете. У нас, на Земле, одно время почти все задачи на C решали, потом почти все те же самые — на C++.
I>>Если точнее, то такого никогда не было.

K>На планете Земля вполне было. Не существует на нашей планете такой ниши, где бы C не отметился.

То есть, даже единичное использование означает что "задачи решали на С" ?

Я ж говорю — "теория всего"

K>Во-первых, я говорил про ФЯ, а не гибриды.

Тут можно и заканчивать, ибо нет ни одного языка не-гибрида, разве что xml какой или машинный код

Здравствуйте, Klapaucius, Вы писали:

I>>Надо определиться имеют ли смысл ЯП в отрыве от задач.

K>Никакой инструмент не имеет смысла в отрыве от задач. Проблема в том, что вы не понимаете для каких задач существуют обсуждаемые инструменты. Языки общего назначения — это инструменты для разработки инструментов: библиотек, ДСЛ, других языков общего назначения. Это и есть задача.

Задачи это конкретные действия необходимые человеку для достижения определенной цели. Цель у человека это не написание библиотеки, и даже не обработка данных. Написание библиотеки как задача имеет смысл только в контексте конкретной задачи, анпример обработки видео и тд и тд. Потому твои задачи это просто мусор в обсуждаемом контексте.

>Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.

Зайди в форум немерле

K>Выбор языка происходит не под задачу, а так:
K>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.

ну вот, "можем себе позволить" ты определил через "можем себе позволить"

I>>Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.

K>Конечно ухудшает. Как и сам стек. Но, разумеется, не так сильно, как управляемая куча. Озвученным требованиям полностью отвечает только статическое распределение памяти. Как в раннем фортране.
K>Короче говоря, вы даже не попытались обосновать нужность (которую я и просил обосновывать) передачи функции вниз. Вы только попытались обосновать ее безвредность. Но и это не удалось. При этом вы сами обосновывали это не в своей парадигме "языка под задачу" а в моей "берем лучшее из того, что можем себе позволить на данном этапе".

Передача вниз нужна для упрощения связывания

Передача вверх нужна для этого же

Разница между ними в том передача вниз безвредна для управления ресурсами и вычислениями и это вобщем то свойство этой самой передачи как способа использования а не замыканий.

I>>Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

K>Можно не бороться со свойствами замыканий, а бороться с замыканиями. Про лямбда-лифтинг слышали? Вот только это требует качественной и более затратной при разработке реализации, а не наивной, в которой все замыкания в куче.

Зеваю — лямбда-лифтинг в общем случае не поможет.

I>>Внятно сказано — стек был и до алгола
K>Где?

Мне не интересно, я показал тебе слова автора алгола, а ты думай сам.

I>>Напиши хорошую библиотеку на хаскеле с помощью которой можно будет легко и эффективно обрабатывать что нибудь из видео, текст, графику, звук и тд.

K>"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.

То есть, хаскель непригоден для решения таких задач, ЧТД.

I>>Просто потому что бритва оккама еще не утратила актуальность. У меня никаких новых понятий не вводится. У меня есть замыкания и контекст, всё. У тебя есть вложеные функций, замыкания и тот же самый контекст.

K>Разделение на замыкание и static chain вполне имеет смысл. Это вы сами обосновали выше, сравнивая их. Это необходимые сущности, их введение обосновано.

Я вобщем то и написал что это одно и то же. А то что свойства различные если по разному использовать — так это и ежу понятно, то есть разница в свойствах операций а не самих замыканий. Операции — передача ввехр или вниз.

I>>Пустой контекст это просто конкретный случай а не новое понятие.

K>Новое понятие, которое вы вводите, для объединения замыкания с "не замыканием" — действие не только бесполезное, но и вредное, согласно вашему же обоснованию.

Выделеное прочесть не алё ? Эдак у тебя каждое натуральное число станет новым понятием. С таким подходом математику не освоить

Здравствуйте, Klapaucius, Вы писали:

I>>Вместо просты и понятных терминов "предназначен", "пригоден", "соответствует" ты несешь какую то ахинею "не можем себе позволить" и не можешь внятно даже пояснить, что заключается в этом термине

K>Объяснил уже три раза — последний раз здесь. Зато у вас вечно получаются какие-то задачи вроде "алгоритмических" и "обработки данных" под которые подвести можно все что угодно, при наличи достаточного числа "пустых контекстов".

По ссылке у тебя определение "что можем себе позволить" через "что можем себе позволить"

Если ничего другого у тебя нет, можно и закругляться.

I>>в отличие от задач обработки данных

K>Не понятно, в чем отличие.

Для этой области важны нефункциональные требования + инструмент для работы с гигантскими приложениями, потому как старые требования что характерно никуда не бывают. С вычислительными задачами можно спокойно выбросить бОльшую часть кода если найдено хорошее решение которое закрывает общий случае. Здесь все операции растут из эвристик "давайте здесь прибавим, а здесь отнимем, а тут сделаем как там".

K>Насчет "в хлам" — это сомнительно, но думаю, что C# на CLR порвет, а C# на Mono — наоборот, глотнет пыли на обочине. Идея ясна?

Нет, не ясно зачем ты смешиваешь в кучу все подряд. Берешь самую лучшую реализацию платформы и сравниваешь. А в твоем случае получится результат "хорошее лучше плохого".

I>>Когда речь про ОС, ты почему то понимаешь пригодность языка для определенных задач. А как чуть что другое — так все языки резко одинаковы.

K>Пригодность реализации. До сравнения языков дело вообще не доходит.

Сравнение языков во все времена было сравнением текущих на момент сравнения реализаций. Я вообще думал это очевидно. Сами языки в чистом виде сравнивать нет смысла в принципе.
Приведи хороший пример как можно сравнить языки в отрыве от задач, т.е. язык против языка.
Компактность реализации как аргумент использовать нельзя ибо "черз 1000 лет вот н там будет убер-ФП за счет убер-адского мега-супер-ГЦ".
Валяй, пример сравнения в студию.

I>>Пока пишут, и доля С++ в этих областях сокращается.

K>Как же так? Ведь в вашей теории:
K>1) Один язык не может занимать несколько областей. Одна область — один идеально подходящий для нее язык.

Нету этого в моей теории. Более того, из примеров что я привел ясно следует несколько областей.

K>2) Доля в области не может сократится. Язык — это ответ на появление новой области и пока существует область ее будет занимать один и тот же язык.

И этого в моей теории нет. Более того, я говорил и объяснял на примере того же С++.

K>Вы эти следствия своей теории понимаете? В реальности их наблюдаете?

В итоге ты сам с собой чего то споришь.

I>>Софт для марсохода это обработка данных + управление железом — в чистом виде именно то подо что заточен С++.

K>Я знал! Я знал!
K>

K>Или вы очередным "вводом пустого контекста" сейчас объясните, что все эти ниши — на самом деле одна ниша?

А чего тут спорить ? марсоход нужен для сбора данных и больше ни для чего. Посмотри по ветку выше, где я упомянул "сбор данных".

I>>С++ распространился в ответ на растущую сложность программ + сохранил все ниши что были за С.

K>Сохранил не все, но это не существенно. Существенно то, что более продвинутый язык распространяющийся в ответ на растущую сложность — это почти моя теория, но наоборот.

"почти моя теория, но наоборот" — это сильно. Как это понять ?

>На самом деле это сложность может вырасти, когда появляется язык, который с этой сложностью справится.

Если у человека есть цели для которых нужны задачи такой сложности и язык пригоден для этих задач, то естественно появятся решения задач такой сложности.

K>В вашей теории язык появляется в ответ на задачу, для которой он иделаьно подходит. О каком распространении идет речь?

Ты похоже не можешь запомнить простые вещи. Вместо того, что бы переспросить ты начинаешь строить предположения основаные на твоих трактовках

>Есть задача — есть распространение. нет задачи — нет распространения.

Правильно, нет задачи нет и распространения. У С++ все в порядке. только у меня язык не обязательно должен появляться в ответ на задау. Это местные немерлисты хотят видеть по дсл на каждую задачу.

I>>Чисто экономические причины. Думаю вместо лиспа мог бы быть какой угодно язык, в т.ч. С++. Яха купил фактически пользовательскую базу, то есть бизнес, а сам язык никого не интересует, абы работало.

K>Если бы язык не интересовал — все бы оставили как есть. Но ведь переписали — потому, что язык интересовал. Только Грема один, а Яху — другой.

Потому что у яхи есть несколько тысяч инженеров + свои наработки в этой области + инфраструктура. Подумали да и забили на лисп.

I>>То есть, даже единичное использование означает что "задачи решали на С" ?

K>Куда больше, чем просто единичное. Куда деваться-то если "других языков у меня для вас нет"? Единичное использование для практически всех ниш — такое почти для каждого языка можно найти.

Нужно рассматривать ниши в которых язык является доминирующим. Будь такое с языкаом Си то и спора не было.

K>>>Во-первых, я говорил про ФЯ, а не гибриды.
I>>Тут можно и заканчивать, ибо нет ни одного языка не-гибрида

K>Ладно, под "гибридом" я имею в виду то, что обычно тут имеют в виду — императивный язык с несколькими функциональными финтифлюшками. Когда я говорил ФЯ в этой ветке я подразумевал полноценную поддержку ФП.

Я честно говоря не знаю, какие ФЯ ты считаешь имеющими полноценную поддержку ФП

Здравствуйте, icWasya, Вы писали:

W>Ну ваша процедура Print не использует накаких переменных, которые локальны для Main и глобальны для Print.
W>С таким же успехом она могла быть описана и вне Main.

О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор

Что это значит ?

> I>>Это тоже нормально реализуется в ООП

> S>Но не в таком ООП, которое приходит в голову наивному проектировщику. Обработка WM_PAINT тысячами WindowProc — это худший способ добиться результата.
>
> Проектирование глобального рендерера это задача мягко говоря не простая. В WPF микрософт отказались той моджели что WinForms и во многих сценариях перформанс стал ещё хуже.

Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

G>Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка.

Рендеринг работает быстро только теоретически и никаких "два порядка" там нет и близко, ибо GDI+ рендеринг во многих сценариях тупо даёт лучший эффект.

> G>Пример? В каких сценариях? Если ты имеешь в виду его общую тормознутость, то это не относится к его объектной модели, это архитектура. А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро. По моим сведениям, переход от моделирования к божественному рендерингу дает прирост в скорости на два порядка.
>
> Рендеринг работает быстро только теоретически и никаких "два порядка" там нет и близко, ибо GDI+ рендеринг во многих сценариях тупо даёт лучший эффект.

Понятно. А ты оказывается читать не умеешь. Досвидания.

Posted via RSDN NNTP Server 2.1 beta

G> А рендеринг у него сделан по Модели Бога, в отличие от Модели Тысячи Чертей в WinForms, и работает быстро.

При этом перерасчет layout-а (а также перерасчет и других наборов связанных переменных) сделано не по "модели бога" и тормозит.

Здравствуйте, Ikemefula, Вы писали:
...
I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор

Что это значит ?

А это примерно как разница между свободной функцией и методом.
У метода есть неявный параметр, в качестве которого передаётся указатель на объект.
Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь.

Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.

Здравствуйте, icWasya, Вы писали:

W>А это примерно как разница между свободной функцией и методом.
W>У метода есть неявный параметр, в качестве которого передаётся указатель на объект.
W>Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь.

W>Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
W>И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.

То есть, компилер паскаля умеет захват в самом православном виде ?

> I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор

Что это значит ?
>
> А это примерно как разница между свободной функцией и методом.
> У метода есть неявный параметр, в качестве которого передаётся указатель на объект.
> Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь.

> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.

Давай пруфлинк на контекст и указатель на контекст. не помню я там такого.
В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, grosborn, Вы писали:

>> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
>> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.

G>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого.
G>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.

Запусти программу из моего примера и объясни эффект.

Здравствуйте, grosborn, Вы писали:

>> I>О, сильно ! Захват есть, локальные в Main доступны, а параметры функции заменяются на мусор

Что это значит ?
>>
>> А это примерно как разница между свободной функцией и методом.
>> У метода есть неявный параметр, в качестве которого передаётся указатель на объект.
>> Поэтому приводить указатель на метод к указателю на свободную функцию можно только, если хорошо знаешь что делаешь.

>> Так и в случае вложеных функций появляется неявный параметр, в который передаётся указатель на контекст.
>> И как следствие — для компилятора сигнатура локальной функции не совпадает с сигнатурой свободной функции.

G>Давай пруфлинк на контекст и указатель на контекст. не помню я там такого.
G>В паскале контекст, это выделяемый при вызове процедуры участок стека, адресация локальным переменным и к части переменных скопа идет относительно указателя стека. Неявных параметров нет никаких. Соответственно пока не вызвана процедура/функция локального контекста просто не существует.

По примеру — в точке вызова Sucxx локального контекста для Print и Succ действительно не существует.
Но функция Main уже вызвана и для неё стек уже выделен.
Если функция Print должна использовать какие-то локальные переменные функции Main,
то для Print эти переменные не локальные(которые адресуются через SP:ebp+offset) и не глобальные (DS:offset)
И что бы Print могла до них добраться, ей нужно как-то передать адрес фрейма стека функции Main.

Здравствуйте, Klapaucius, Вы писали:

K>Никто не изобретает языки, например, для разработки компиляторов,
Я изобретаю. Ибо это гораздо эффективнее чем:
K>но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

Здравствуйте, grosborn, Вы писали:

G>В твоем представлении что-нибудь кроме моделей существует? Или в твоем представлении мы все созерцательные кони в вакууме? Что, никак-никаких-совсем никаких средств воздействия на окружающий мир? Совсем никаких новых сущностей, только отражение "реального мира"?

Необязательно реального. Придумай модель нереального. Все-равно, ты должен будешь для начала придумать ту самую Модель для целей разработки ПО, а потом реализовать ее. Процесс разработки ПО наоборот я даже не могу представить. ))

Просто, коль речь шла о прикладном ПО, то я считаю, что всегда речь идет о моделях реального Мира (с точностью до абстракции) или о нашем представлении о Мире (что одно и то же).

>> G>И не является частью модели.
>> Модель всегда работает по неким законам.

G>Ну по крайней мере я умею разделять модели и понятия,

"Понятия" — это алфавит модели. ОК, ты умеешь отделять алфавит от слов. А как же насчет грамматики? )))

Я тебя поправил в том плане, что речь была о связи участников модели и законов, по которым участники модели взаимодействуют. ИМХО, это неразрывные вещи для любой динамической системы: участники + правила игры.

G>отделяю инструментальные средства от объектов их применения. А ты этого не можешь.

В этом отделении нет никакого смысла. Например, какой толк от закона всемирного тяготения без понятия массы тел и самих тел?

Ес-но я отделяю такую цещь как "закон тяготения" от понятия "массы" и от понятия "тел", обладающих "массой". Но в моём понимании Мира перечисленные вещи неразрывно связаны и не имеют смысла один без другого. То бишь, они составляют полноценную "модель" только сообща. Грубо говоря, описание упомянутой модели состоит из 3-х разделов. И какой же из этих 3-х разделов, по-твоему, "инструмент" для остальных двух?

>> По русски можно?
G>По русски тут будет три буквы.

Кто из нас не умеет считать:

G>В программировании инструментальных средств — внезапно! — большая часть.

)))

Зря ты искал подвох. Я понял о чем ты, но хотел твоей самоличной перефразировки на нормальный русский, дабы не быть обвиненным в додумывании за оппонента.

Здравствуйте, samius, Вы писали:

V>>Странная у тебя манера ведения пора — половинчатая. Несогласие ты высказал, но я не увидел твоих альтернатив. Как же назвать технику, на которой работают вложенные ф-ии Паскаля?
S>Я ее называю "указатель на фрейм стека".

А на самом деле это указатель на фрейм локальных переменных. Ууупс? )))

> Да, вся куча сверхсложных процессов по передаче информации в рж в нашей модели выглядит как элеметарная отсылка сообщения некоей неделимой сущности. Но ведь на то она и модель, чтобы сложные вещи выглядели просто, не?

Вот-вот-ага-ага, удаляем гланды через ж

Я немного в цепи рассуждений потерялся, это вы все еще проектируете проверку bool Дверь.Открыта() ?

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>Веселый у тебя пост получился. Ты решил сдуться сразу по половине вопросов и вместо аргументов ухватился за последнюю соломинку — за "идентичность"? ))
V>Ню-ню..
Да, ты меня уже читаешь как открытую книгу. Не спал ночами, маялся, советовался с мамой, учительницей по физике, и все вместе принимали решение — надо сдуться.

V>[скипнул 50 вопросов "а где идентичность?"]
Правильно что скипнул. Они предназначались не для того что бы ты на них отвечал, а что бы ты перестал пороть про подписку колбочек на получение фотонов. С 50-го раза походу тебя все-таки проняло, с чем и поздравляю.

S>>Двойку оставь себе. Получателем сообщения отправителя будет медиатор, и медиатор будет отправлять сообщения другим получателям с помощью их идентичностей.

V>Да двойка опять, се ля ви. Идентичность — это тоже элемент модели, то бишь тоже результат абстрагирования.
Ну надо же, вот и озарение наконец-то.

V>Кароч, ликбез: тела в рж могут состоять из разнородных элементов — частиц, те в свою очередь из более мелких и т.д... и даже на сегодня науке ХЗ из чего состоят кварки. Набор тел, в свою очередь, может образовывать некую макросистему. Задача "идентити" в модели — представить экземпляр некоей логической сущности как неделимое понятие, асбтрагировавшись от её устройства. Всё!
Ну вот видишь, какая хрень получается... В рж макросистемы частиц, а в модели неделимое понятие с идентичностью. И после этого ты мне будешь говорить как ООП модель близка к рж? Походу ты забил гол в свои ворота.

V>Идентити объекта-наблюдателя из нашей модели может соответствовать экземпляр человека или экземпляр датчика положения двери. Посылка сообщения такому экземпляру — это абстракция над всеми процессами, связанными с передачей и получением информации в рж. Ключевое выделил. Да, вся куча сверхсложных процессов по передаче информации в рж в нашей модели выглядит как элеметарная отсылка сообщения некоей неделимой сущности. Но ведь на то она и модель, чтобы сложные вещи выглядели просто, не?
Вот именно что. Ты фактически берешь куринное яйцо и говоришь "представьте что это звезда класса желтый карлик". Модель? Безусловно. Близка ли она к рж? Вобщем я тя умоляю, кончай ты эту тягомотину уже.

V>>>ОК, Геометрическая оптика
S>>Причем тут идентичность, казалось бы?

V>При том, что ты уже давно так не юлил. Ты просил про механику происходящего в рж? Получи... Но фигли теперь сувать вопрос про "идентичность" во все абзацы, вопреки собственным же предыдущим рассуждениям?

Это уже 80-й лвл по замыливанию темы.
НЕНЕНЕ, ты меня неверно понял. Я просил не механику происходящего в рж, а то как ты этой механикой оправдываешь близость ООП модели и рж.

V>>>Асбтракция — это естественное для человека понятие, т.к. сам человек склонен мыслить абстрактно, выкидывая ненужные детали.
S>>Ну т.е. уже переметнулся в мой лагерь и пытаешься меня из него выбить, будто так все и было...

V>Нет уж, это не твой лагерь. Ты же не понимаешь как модель в технике ООП отображается на рж, дык я тебе терпеливо объясняю. Асбтракция — это ключевой прием любого моделирования. В любой технике, не только в ООП.
Значит ты щас продолжишь объяснять про подписку колбочек на фотоны двери? Избавь меня от этого. Абстракция бывает разная. Если мы возьмем и промоделируем каждую частицу системы (или каждую тысячную), даже если мы промоделируем эти частицы ООП объектами, то такая модель будет неизмеримо ближе к рж, чем то что обычно используется в ООП. Или давай представим фотонтрейсер (по аналогии с рейтрейсером). Это тоже будет модель и она будет ближе к рж, хоть и совершенно излишней в решении задачи открывания двери. А вот именно такой уровень абстракции, когда ты макросистему представляешь одним объектом, и все процессы взаимодействия подменяешь чем-то таким, чью аналогию ты не в силах мне объяснить, вот именно это делает ООП модель далекой от рж. Я не настаиваю на том что она слишком далека для решения задачи. Просто ООП модель дальше от практически любой другой в отношении качества абстракций и моделируемых процессов.

S>>Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?

V>Ес-но юлишь только ты, я готов подробно и терпеливо отвечать на что угодно.
Не вижу ответа на просьбу грязного кода
V>Конкретно здесь я тебе на это уже неоднократно возражал: если мы можем повторить все побочные эффекты без бэкдоров, то какая разница, что некий отдельный кусочек твоего кода чист? А вот ты, увы, на это ответить не смог ни разу. Ты лишь способен цепляться за тот факт, кто некая выделенная ф-ия в Хаскеле чиста. И, выждав паузу после очередного неотвеченного возражения, приводишь этот факт опять. Детсад... потому что дальше этого полный ступор в рассуждениях. Разве не видишь перехода от комбинации чистых ф-ий к точно таким же побочным эффектам, как в императиве? Это же простейший переход через трюк ассоциативности. Что здесь сложного?

Этот трюк в наверняка используется в любой более-менее большой программе многократно.
Так код будет? Способен я или нет, потом обсудим.
Только и у тебя тут ясли намечаются. У чистого кода есть определение. В этом определении нет ничего о том, моделируется ли с помощью чистого кода грязный эффект или нет. Потому, даже моделирование грязных эффектов с помощью чистого кода формально будет чисто. Только в ФП моделирование грязи — это не единственный способ писать программы.

V>>>Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.

S>>Опять подмена тезиса

V>Да нет подмены. Я вижу непонимание, что такое есть модель. Вот попробуй дать своими словами определение "модели"
Подмена, подмена. Право я не оспаривал. Я оспаривал степень соответствия.
V>Потому как пока что ты изо всех сил пытался на понятие "модель" наложить кучу высосанных из пальца ограничений.
Ссылку в студию

V>>>Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.
S>>Я не пытался это опровергнуть. Хорош спорить с голосами.

V>Ес-но пытался, но был пойман.
Не пытался и пойман не был. Хорош выдумывать.

V>>>Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения?

Это уже какой-то полный П.
S>>Походу ты не знаешь что такое особая форма, раз ты уже спалился с тем что в хаскеле if функцией не записать.

V>Ты читать не умеешь? Как это в Хаскеле не записать if, если я же тебе и сказал, что в Хаскеле if представима в виде обычной ф-ии из-за ленивости?

Смотри что ты написал

Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный.

даже "НЕ" выделил.

V>И конечно, я могу не знать, что есть "особая форма", бо в лямбда-исчислении такого понятия нет. А термины из некоторых конкретных экспериментальных ЯП меня мало волнуют, сорри.
Не волнуют ну и ладно. Только кончай беситься от того что меня тоже что-то мало волнует.

S>>>>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

V>>>Ну побегай, побегай...
V>>>А я буду писать эффективные программы. Даже если это будет стоит мне поменять пару строчек местами. ))
S>>Ты пиши, пиши, только смотри чем и что аргументируешь.

V>Здесь я лишь показывал пример, почему стоит знать как всё работает. Меня уже порядком утомляет твой крен в сторону того, чтобы специально стараться быть как можно более нубом, не имеющим понятия об устройстве и принципах работы используемых инструментов. Плох тот программист, для которого эффективность не аргумент, особенно если речь о том, что эта эффективность не стоит трудозатрат в процессе разработки, а лишь требует минимального понимания механики работы конечного сгенеренного инструментом кода.
Хорош тот программист, который аргументирует происхождение ФП от СП (что уже смешно) соображениями эффективности

S>>Ты опять что-то придумал за меня. Я не говорил что порядок вычислений не важен. Я утверждаю что он в отношении побочных эффектов не интересен, в отличии от нечистых вычислений.

V>Т.е. ты опять решил убежать? Но я тебе освежу. Я утверждал, что на if происходит та же механика в ФП, что в процедурном подходе (по фундаметальным причинам). Ты сначала пытался возразить, что не та же (как обычно, все возражение я в духе "неужели???" и смайлов

). А когда не смог доказать, то дважды повторил, что тебе это, оказывается, не интересно. Слабовато это как-то выглядит.
Это не интересно не мне, а вообще не интересно никому. Ну или попробуй убедить меня в обратном и покажи насколько полезна чистая функция в качестве стейтмента ветки if в СП.

V>На самом деле прикольно получилось, потому как я вначале рассуждал с т.з. программиста, рассматривая процесс мысленной трассировки работы программы на if, и уж мысленно вообще одно и то же выходит, что в ФП, что в ПП. Но еще и в рантайм, получается ровно то же самое. Прямо сейчас можно подниматься далеко наверх и попытаться искать новые аргменты, что ФП далеко убежало от структурного программирования.

Твои мысленные трассировки не аргумент, увы.

V>>>if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.
S>>Нет, не десятое. Чистый statement в СП никому не нужен, ибо единственный эффект от него — счета за электричество.

V>Ну опять тебе двойка. Курить определение чистоты до просветления.
Сам кури, у тебя с ним проблемы.
V>Вот тебе пример мутабельной ф-ии на С++, которая абсолютно чиста:
V>

V>int sum(int a, int b, int c) {
V>  a += b;
V>  a += c;
V>  return a;
V>}
V>

Я не спорю что она чиста. Теперь покажи мне насколько эта чистая функция полезна внутри ветки if-а в качестве стейтмента. Покажи, как ты используешь ее результат.

V>Я уже где-то рядом ловил тебя на том, что ты не понимаешь, что есть чистота вычислений. Собственно, о чем ты тогда спорил?
Ты ловишь голоса в твоей голове. А то что я пишу — ты понимаешь от силы процентов 40... Возможно меньше, т.к. доходит раза с 50-го, как с идентичностью. И то уверенности нет что ты меня понял.

S>>Я показал ложность твоего утверждения.

V>Еще раз, приведи такой пример, который, по твоим же словам:
V>

V>легко показать чистую функцию для которой порядок вычисления аргументов будет играть роль.

V>Вот давай самую обычную ф-ию без всяких особых форм. Увидишь, как глубоки твои заблуждения относительно св-в чистоты вычислений.
Уже давал. Вернись выше.

S>>Это не новость для меня, почему-то многие для блеска эрудиции и фана употребляют общеизвестные термины в каком-то скрытом и одним им известном смысле. Странный фан, как по мне. В итоге стало ясно что ты употребляешь термины невпопад.

V>Акцент был на том, что это упорядочивание вычислений ОБЯЗАТЕЛЬНО, невзирая на всю чистоту. Поэтому и говорилось, что происходящее при ветвлении в ПП и ФП фактически не отличается (ньюансы мы уже обсуждали, в т.ч. ньюансы во время ленивости). Ты прекрасно вначале уловил акцент и оспаривал именно его в течении нескольких постов, пока не понял свою ошибку. Но теперь пытаешься вернуться к самому началу и пытаться начать цепляться к словам. Поздно, все ходы записаны. Я обещал показать аналогичное происходящее в ФП и ПП? — я показал. Будешь опять здесь юлить — попрошу "помощь зала" рассудить, делов-то. Увидишь во всей красе новую тему со всеми твоими цитатами в хронологическом порядке...

Помощь зала — ну что же, я не возражаю. Но раз ты заговорил о зале, погляди сначала сколько минусов ты наковырял в этой теме. Да, и перечитай мои сообщения внимательно раз по 50. Возможно поймешь о чем я, но не факт.

S>>Я не отрицал упорядоченность.

V>Кто-то вскрыл твой аккаунт и писал от твоего имени?
ссылку

V>>>Я и не собраюсь. Более того, я же и утверждал, что ООП оформило в одну парадигму некоторые уже реально устоявшиеся в процедурном подходе практики. Но понятие контракта на методы типа в современном его смысле выкристаллизовалось именно в ООП. Это медицинский факт.
S>>Наверное тебя не затруднит привести пруф медицинского факта.

V>Легко. Курить историю IDL-языков.
V>Кстате, для начала даже саму аббревиатуру. ))
пруф-то будет? Ты приведи пруф, а там я покурю что сочту нужным.

V>>>Это пара { ф-ия, контекст }.
S>>Выглядит как замыкание

V>Правильно. Но объект выглядит так же, ваш КО. И если ф-ии общие на всех, то контексту присуще понятие экземпляра. Как раз хаскелевские монады таким образом организуют вычисления, что передаваемое от вычисления к вычислению новое состояние контекста можно смело рассматривать как один и тот же экземпляр изменяемого контекста.
Да, вот так в твоей мысленной трассировке чистый код и становится грязным ))) рукалицо

V>>>Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
S>>Значит опять невпопад.

V>Значит проблема с восприятием информации.
Можешь это называть невосприимчивостью к бреду, или просто фильтром

S>>Лично для меня неспециально плодить грабли в грязном коде куда проще.

V>О! Таки перешел уже от утверждения абсолюта к обсужденю оттенков?
V>Молодец. Не прошло и сотни постов.

V>А я именно с этого начал.

О да, в особенности про происхождение ФП от СП. Перечитай, у тебя там голый абсолют.
V>Ну что, по новой с новым пониманием? Или ты и сам теперь можешь понять то, что я писал выше?
Понять я могу, а вот ~~простить~~ согласиться — нет.

S>>Работают практически все средства. Но не все одинаково хороши. Во всяком случае для меня.

V>Про компроммисы в ФП я уже устал писать. Пока что в реально существующем ФП всё скорее плохо, чем хорошо. Не знаю, что там для себя ты увидел... Как велосипед для ума — ну ОК, одобряю. Как практически применимую вещь — только в виде инструмента написания некоммерческих утилит. И то не всех, бо даже утилиты разные бывают. В общем, только для кода, к которому нефункциональные требования отсутствуют как класс.
Спасибо за мнение, но твоя система оценок скомпрометирована.

S>>Это не цинизм, это банальности. Извини, но мысли вроде "все равно ошибки будут" и "все программы грязны" немногого стоят.

V>Не надо меня упрощать. Я претендовал на то, что у меня есть некая статистика по ошибкам из очень многих проектов. Так вот, доля ошибок по причине приписываемых императиву ужасов настолько ничтожна в общей массе вылавливаемых ошибок, что их обсуждение попахивает откровенным нубством на проф-форуме. А как усиление комичности ситуации выступает тот высмеиваемый мною факт, что ФП некоторыми преподносится как панацея. А какая это может быть панацея от логических ошибок, совершаемых программистом? Да никакая. Когда-то я тщательно спорил с thesz именно вокруг этой темы, а он, скажем прямо, намного более сильный функциональщик, чем многие из моих нынешних оппонентов из ФП лагеря на рсдн. И этим "оппонентам" я уже устал повторять, что не надо вестись как дети на фразы, что мол "чистый код декларативен". Это условности, это недоступные разработчику плюшки, а лишь сугубо св-во досутпных компилятору преобразований... бо реально в современном ФП необходимо описывать ту же степень подробности решения, что и в императиве (ООП). И как раз из-за равенства уровней описания обе техники провоцируют равное кол-во ошибок в реальных проектах с точностью до несущественных погрешностей. Вот и всё кино. Остальное — не более чем религия и дань моде.
Тот факт что ты спорил с thesz говорит лишь о том, что thesz был с тобой не согласен и только. И никак не доказывает твою правоту в чем-либо. Скорее наоборот.

V>Рядом я обсуждал, что именно было бы неплохо добавить в императивный ЯП, чтобы делать меньше тех самых ошибок. Я предлагал для С++ аналог pure из D. И заметь, что ФП в данном случае вообще никаким боком, бо функция/метод может быть чистым, он даже может изменять внешние (поданные по ссылке) данные, но при этом быть абсолютно pure. То бишь, легким движением руки я показывал, как можно преодолевать все "ужасы" императива, не плятя при этом высокую цену в виде ограничений, присущих "чистому ФП".
Одной рукой ты говоришь что в чистом языке ошибки те же самые, а другой тут же говоришь что при помощи аналога pure для императивного ЯП ты собираешься преодолевать ужасы императива. И это в одном и том же сообщении в соседних абзацах!!!
Ну и как к этому еще относиться? Извини, но тут у меня лишь ирония.

Здравствуйте, WolfHound, Вы писали:

K>>Никто не изобретает языки, например, для разработки компиляторов,
WH>Я изобретаю.

Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет. Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.

WH>Ибо это гораздо эффективнее чем:
K>>но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.

Стоп. Вы пишете ДСЛ на языке общего назначения. Чем это эффективнее написания ДСЛ на языке общего назначения?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>Если человек художник или повар — то цель у него, конечно, не написание библиотеки. Даже если человек программист, то цель у него, скорее всего не написание библиотек и даже не программирование как таковое. Но чтоб добится всех этих целей, программисту нужны, например, деньги, которые он зарабатывает. Как? Программированием! А программирование — это написание библиотек и/или "склеивание" их между собой. не обработка видео. Да, возможность хорошо "склеивать" библиотеки — это даже еще более важное свойство языка (есть же скрипты, которые для написания библиотек подходят плохо, а заточены исключительно на склеивание).

Цель у программиста как специалиста — это решение конкретных задач бизнеса. Человеческие цели не нужно рассматривать, а бизнес не ставит задачу "написать библиотеку".

I>>Написание библиотеки как задача имеет смысл только в контексте конкретной задачи, анпример обработки видео и тд и тд. Потому твои задачи это просто мусор в обсуждаемом контексте.

K>Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).

Это совершенно не важно.

>>>Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
I>>Зайди в форум немерле

K>Чтоб увидеть, как "для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего"?

Что бы увидеть как люди изобретают языки для разработки компиляторов.

K>>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>>ну вот, "можем себе позволить" ты определил через "можем себе позволить"

K>Какие проблемы с пониманием смысла "что может себе позволить"?

Есть понятные любому инженеру термины. Вот их и хочется видеть, а не продираться через твои "рекурсивные" понятия.

I>>Разница между ними в том передача вниз безвредна для управления ресурсами и вычислениями и это вобщем то свойство этой самой передачи как способа использования а не замыканий.

K>Передача-то безвредна. Зато стек, который для этого нужен вреден. Про его переполнение слыхали? Ну так и замыкания по такой логике не вредны — вредна куча.

Куча тоже безвредна. Вредны конкретные способы использования этой кучи.

I>>Зеваю — лямбда-лифтинг в общем случае не поможет.

K>А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.

Это все общие слова, неинтересно.

K>У алгола больше авторов чем в "словах автора алгола" слов. Закавыченные слова без ссылки не интересны, реальный контрпример — наоборот — может изменить ход дискуссии.

Ну так найди его, этот контрпример. Или ты хочешь что бы я сам искал и примеры и контрпримеры ?

I>>То есть, хаскель непригоден для решения таких задач, ЧТД.

K>Не подходит его имплементация. Вот авторы имплементаций C++ отлично понимали в чем тут разница, поэтому сейчас его имплементации для этих задач вполне подходят.

Текущая реализация хаскеля не пригодна для решения многих насущных задач. Ждать идеальной реализации в своем уме никто не станет — и через сто лет у хаскеля будут особенности реализации и соответсвующие свойства.

I>>Я вобщем то и написал что это одно и то же. А то что свойства различные если по разному использовать — так это и ежу понятно, то есть разница в свойствах операций а не самих замыканий. Операции — передача ввехр или вниз.

K>Вы тут противоречия не видите? Например, между "одно и то же" и "есть разница"?

"свойства различные если по разному использовать" — то есть разница в способах использования а не в сущностях.
Вот пример для тебя — берем две идентичные вилки, одной будем есть котлету, а другой прочищать канализацию. В одном случае руки грязные, в другом чистые. Следовательно идетичные вилки совершенно не идентичны

K>В выделенном весь и юмор. Вы вводите новое понятие...
>(замыкание-и-не-замыкание-одновременно, толи-лысый-толи-с-волосами и т.д.) для того, чтоб сделать что-то частным случаем.

Я показываю, что одно из понятий в твоей системе лишнее и ничего не меняется, если его выбросить оттуда. Я не ввожу понятие нуля, оно введено задолго до меня. Я его всего лишь использую.

Здравствуйте, Ikemefula, Вы писали:

I>Цель у программиста как специалиста — это решение конкретных задач бизнеса. Человеческие цели не нужно рассматривать, а бизнес не ставит задачу "написать библиотеку".

А примеры "конкретных задач бизнеса", которые решает программист можно? Потому что программист вообще-то решает конкретные задачи программирования — а конкретные задачи бизнеса решают другие люди, в том числе и ставя программистам конкретные программистские задачи и организуя их решение.

K>>Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).
I>Это совершенно не важно.

Тогда о чем мы вообще спорим?

I>Что бы увидеть как люди изобретают языки для разработки компиляторов.
Они изобретают дсл-и, встроенные в язык общего назначения и библиотеки к нему.

K>>>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>Есть понятные любому инженеру термины. Вот их и хочется видеть, а не продираться через твои "рекурсивные" понятия.

Ну, допустим, что вот это "любому инженеру" не понятно:

Отсекаем все языки, для которых вы не найдете программистов.

Потому, что работников не инженеры ищут.
Но тут-то какие вопросы:

Отсекаем все языки, для которых нет устраивающих вас реализаций.
Отсекаем все языки, не имеющие набора библиотек, которые нужны для решения ваших задач.

Вот то, что остается после этих отсечений мы и можем себе позволить. А что не остается — не можем. Что тут непонятного?

I>Куча тоже безвредна. Вредны конкретные способы использования этой кучи.

И? Что вы выводите из этого?

I>>>Зеваю — лямбда-лифтинг в общем случае не поможет.
K>>А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.
I>Это все общие слова, неинтересно.

ну так не сводите сами обсуждение конкретных средств к общим словам.

K>>У алгола больше авторов чем в "словах автора алгола" слов. Закавыченные слова без ссылки не интересны, реальный контрпример — наоборот — может изменить ход дискуссии.
I>Ну так найди его, этот контрпример. Или ты хочешь что бы я сам искал и примеры и контрпримеры ?

Это шутка? Я утверждал буквально следующее:

Поэтому они (авторы алгола) изобрели стек, реализовали рекурсию (раньше рекурсию умели только с помощью хипа реализовывать) и постарались выжать из этого изобретения все что можно.

И какой тут должен быть контрпример от меня? Вы даже не стали спорить с этим, а стали утверждать, что "стек был изобретен задолго до алгола". Дальше я сделал более сильное утверждение

стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп)

Какой контрпример тут может от меня требоваться — тоже непонятно. Вот вы, как оппонент можете привести контрпример — другой язык (не алгол, а если спорите с моим первоначальным утверждением — и не от авторов алгола) в котором это действительно было инновацией — раньше алгола. Я, кстати, не удивлюсь, если такой язык есть, но он наверняка малоизвестен и серьезного влияния на развитие ЯП не оказал.

I>Текущая реализация хаскеля не пригодна для решения многих насущных задач. Ждать идеальной реализации в своем уме никто не станет

Идеальных реализаций не бывает. А пригодных для решения конкретной насущной задачи будут в том смысле, что пока задачу имеющаяся реализация решать не позволяет — ее и использовать не будут. Если решатели насущной задачи, конечно, "в своем уме".

I>"свойства различные если по разному использовать" — то есть разница в способах использования а не в сущностях.

Ага. Теперь вы уже разделяете технику (которую мы обсуждаем) на "сущность" и технику-штрих. Т.е. сравниваем поедание и прочищение. Добавляем пустой контекст — вилку. Получаем прочищение вилкой и поедание вилкой. Раз "пустой контекст" или там "сущность" в обоих случаях одно и то же — вилка — вы делаете вывод, что поедание и прочищение или там замыкание и отсутствие замыкания — это одно и то же. Теперь ошибка в рассуждениях понятна?

K>>В выделенном весь и юмор. Вы вводите новое понятие...
>>(замыкание-и-не-замыкание-одновременно, толи-лысый-толи-с-волосами и т.д.) для того, чтоб сделать что-то частным случаем.
I>Я показываю, что одно из понятий в твоей системе лишнее и ничего не меняется, если его выбросить оттуда.

Ну так где вы показываете, что одно из них лишнее? Вы пока что доказывали (вполне обоснованно, кстати) только, что между замыканием и его отсутствием есть значимая на практике разница. А то, что это одно и то же — вы просто декларируете, рассуждая о каких-то "пустых контекстах", противореча самому же себе.

I>Я не ввожу понятие нуля, оно введено задолго до меня. Я его всего лишь использую.

Ага. Используете умножение на ноль для доказательства того, что 42 = 24.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>А примеры "конкретных задач бизнеса", которые решает программист можно?

Например Saas

>Потому что программист вообще-то решает конкретные задачи программирования — а конкретные задачи бизнеса решают другие люди, в том числе и ставя программистам конкретные программистские задачи и организуя их решение.

Разумеется, задачи это программирование. ТОлько цель и задача это разные вещи, ты их путаешь.

I>>Это совершенно не важно.

K>Тогда о чем мы вообще спорим?

I>>Что бы увидеть как люди изобретают языки для разработки компиляторов.
K>Они изобретают дсл-и, встроенные в язык общего назначения и библиотеки к нему.

Вообще то тебе WH внятно ответил

K>Ну, допустим, что вот это "любому инженеру" не понятно:
K>

K>Отсекаем все языки, для которых вы не найдете программистов.

K>Потому, что работников не инженеры ищут.
K>Но тут-то какие вопросы:
K>

K>Отсекаем все языки, для которых нет устраивающих вас реализаций.
K>Отсекаем все языки, не имеющие набора библиотек, которые нужны для решения ваших задач.

K>Вот то, что остается после этих отсечений мы и можем себе позволить. А что не остается — не можем. Что тут непонятного?

Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

I>>Куча тоже безвредна. Вредны конкретные способы использования этой кучи.
K>И? Что вы выводите из этого?

Нужно учитывать свойстваи конкретных явлений и способов их использования.

I>>Это все общие слова, неинтересно.
K>ну так не сводите сами обсуждение конкретных средств к общим словам.

ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

K>Это шутка? Я утверждал буквально следующее:
K>

K>Поэтому они (авторы алгола) изобрели стек, реализовали рекурсию (раньше рекурсию умели только с помощью хипа реализовывать) и постарались выжать из этого изобретения все что можно.

K>И какой тут должен быть контрпример от меня?

Я показал слова одного из авторов Алгола, который утверждает что стек они всего то использовали а не изобретали.

>Вы даже не стали спорить с этим, а стали утверждать, что "стек был изобретен задолго до алгола".

Все ровно наоборот.

Дальше я сделал более сильное утверждение
K>

K>стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп)

Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

K>Какой контрпример тут может от меня требоваться — тоже непонятно. Вот вы, как оппонент можете привести контрпример — другой язык (не алгол, а если спорите с моим первоначальным утверждением — и не от авторов алгола) в котором это действительно было инновацией — раньше алгола. Я, кстати, не удивлюсь, если такой язык есть, но он наверняка малоизвестен и серьезного влияния на развитие ЯП не оказал.

Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.

I>>Текущая реализация хаскеля не пригодна для решения многих насущных задач. Ждать идеальной реализации в своем уме никто не станет

K>Идеальных реализаций не бывает. А пригодных для решения конкретной насущной задачи будут в том смысле, что пока задачу имеющаяся реализация решать не позволяет — ее и использовать не будут. Если решатели насущной задачи, конечно, "в своем уме".

Вот-вот. Как только ушли от терминов "можем себе позволить", сразу стало все предельно понятно.

I>>"свойства различные если по разному использовать" — то есть разница в способах использования а не в сущностях.

K>Ага. Теперь вы уже разделяете технику (которую мы обсуждаем) на "сущность" и технику-штрих.

Нет, не правильно. Это у тебя понятия разделены. Я же говорю о том, что достаточно одного понятия + способы его использования. Передавать вверх, передавать вниз — это только способы. Ну да, могут быть оптимизации под конкретный способ, это нормально. Но это вилка все равно остаётся вилкой.

I>>Я показываю, что одно из понятий в твоей системе лишнее и ничего не меняется, если его выбросить оттуда.

K>Ну так где вы показываете, что одно из них лишнее? Вы пока что доказывали (вполне обоснованно, кстати) только, что между замыканием и его отсутствием есть значимая на практике разница. А то, что это одно и то же — вы просто декларируете, рассуждая о каких-то "пустых контекстах", противореча самому же себе.

Я говорю о том, что описание конкретного явления потребует меньше слов если выбросить одно из понятий, при чем без какого либо ущерба.

I>>Я не ввожу понятие нуля, оно введено задолго до меня. Я его всего лишь использую.

K>Ага. Используете умножение на ноль для доказательства того, что 42 = 24.

Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

Здравствуйте, SV., Вы писали:

SV.>Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

Вопрос — а нужно ли? Доля кода, описывающего предметную область в проекте, как правило, не очень велика. Реальные программы совсем не похожи на объектные модели предметной области. К тому же, для этого есть куда более удачное решение — DSL.
Основная масса кода в проекте, как правило, что-то делает, выполняет обработку данных. Для решения таких задач не нужны смешные средства моделирвоания предметной области, которые предоставляют языки вроде Java или C++. Для таких задач нужна возможность свободно комбинировать между собой простые вещи вроде итераторов или функций. Возьмем к примеру итераторы, в python или C#, не важно. Мы можем взять итератор по какой-нибудь коллекции, и сделать на его основе еще один итератор, который не просто ходит по коллекции, но еще и выполняет какую-то функцию. Мы можем скомбинировать несколько итераторов в один, функциями вроде zip или product. Мы можем получить итератор на блокирующую очередь, который будет блокировать вызывающий поток, если в очереди ничего нет. Как подобные примитивы связаны с предметной областью? Нужно ли тут что-то сложное моделировать или достаточно одной сущьности — итератор?
Можно привести в качестве примера что-нибудь еще, например асинхронные коллекции из Rx framework или futures/promises. Эти штуки тоже очень здорово умеют комбинироваться между собой, позволяя описывать очень сложные вещи, которые описываются в терминах ООП очень просто и.. бесполезно.
Мало того, ООП, оно про то, как имея набор примитивов — объектов, создать все множество необходимых поведений, правильно комбинируя эти примитивы между собой, а вовсе не про могучие таксономические иерархии, построенные на наследовании и что-то там описывающие в предметной области.

И вообще, идея того, что люди мыслят объектами и поэтому нужно все описывать в виде иерархий классов мне кажется в корне неверной. Людям очень сложно оперировать огромным количеством сущьностей, которые живут в любом, более или менее крупном фреймверке. Людям удобно оперировать объектами и классами, но только тогда, когда их мало и они ортогональны. Удобно оперировать списками, файлами, итераторами, словарями, функциями, и тд. Их удобно использовать в качестве стоительных блоков, комбинировать, трактовать что-нибудь как файл, либо скомбинировать несколько функций в одну. Очень неудобно оперировать сущьностями из какой-нибудь сложной иерархии объектов, где каждая сущьность реализует какой-либо набор интерфейсов и может быть использована в каком-то определенном контексте.

Здравствуйте, Klapaucius, Вы писали:

K>Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет.

Это еще почему ?

>Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.

Нет такого домена как С++

Здравствуйте, Ikemefula, Вы писали:

K>>А примеры "конкретных задач бизнеса", которые решает программист можно?
I>Например Saas

Ну и в этом случае программист тоже задачи бизнеса не решает.

I>Разумеется, задачи это программирование. ТОлько цель и задача это разные вещи, ты их путаешь.

Ну, теперь еще и цели какие-то появились.

K>>Тогда о чем мы вообще спорим?
I>

Ну вы же спорите, значит по факту это, по крайней мере достаточно важно, чтоб ради этого пост написать.

I>Вообще то тебе WH внятно ответил

Нет, не ответил.

I>Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.

I>Нужно учитывать свойстваи конкретных явлений и способов их использования.

Ну так с этим никто не спорит. Спорят с вами, когда вы в том же сообщении утверждаете, что при достаточном числе добавленных "пустых контекстов" разницы нет. Т.е. с одной стороны учитывать надо, вот только нечего, потому что ворон от конторки ничем не отличается. в этом и проблема с вашими рассуждениями.

I>ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

Это что, "общие слова" так выглядят?

K>>Это шутка? Я утверждал буквально следующее:
K>>

K>>Поэтому они (авторы алгола) изобрели стек, реализовали рекурсию (раньше рекурсию умели только с помощью хипа реализовывать) и постарались выжать из этого изобретения все что можно.

K>>И какой тут должен быть контрпример от меня?

I>Я показал слова одного из авторов Алгола, который утверждает что стек они всего то использовали а не изобретали.

Ну, понятно, что я не утверждаю, будто они стопку изобрели. Но именно стек вызовов — это алголовская инновация.

K>>

K>>стек — это главная алголовская инновация, определившая облик основных языков на полвека вперед. До этого либо память распределялась статически и не было никаких рекурсий (Фортран) — либо все было в куче (Лисп)

I>Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

Потому, что MIX-ассемблер изобретен позже чем алгол — что тут удивительного?

I>Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.

"Слова автора алгола" опровергаются делами авторов алгола. Есть реальность данная в ощущениях и есть заковыченные слова.

K>>Идеальных реализаций не бывает. А пригодных для решения конкретной насущной задачи будут в том смысле, что пока задачу имеющаяся реализация решать не позволяет — ее и использовать не будут. Если решатели насущной задачи, конечно, "в своем уме".
I>Вот-вот. Как только ушли от терминов "можем себе позволить", сразу стало все предельно понятно.

Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?

I>Нет, не правильно. Это у тебя понятия разделены. Я же говорю о том, что достаточно одного понятия + способы его использования. Передавать вверх, передавать вниз — это только способы. Ну да, могут быть оптимизации под конкретный способ, это нормально. Но это вилка все равно остаётся вилкой.

Еще раз: вред от того, что замыканием называются разные вещи вы и сами описали. а польза от этого обобщения какая? Вот и опять — "сущности" у них якобы одинаковые, вот только одна "сущность" позволяет ее использовать так, а другая якобы такая же — не позволяет. Так почему тогда это вилкой называть — если в одном случае грабли, а вдругом — астролябия?

I>Я говорю о том, что описание конкретного явления потребует меньше слов если выбросить одно из понятий, при чем без какого либо ущерба.

Не правда, с ущербом, который вы сами же и описали.

I>Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

Ага, а если человек ничего не украл — он все равно вор, просто потому что так проще.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:

K>>Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет.
I>Это еще почему ?

По определениям DSL и "язык общего назначения".

>>Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.
I>Нет такого домена как С++

"Домен C++" тут "домен языка C++". Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>>>А примеры "конкретных задач бизнеса", которые решает программист можно?
I>>Например Saas

K>Ну и в этом случае программист тоже задачи бизнеса не решает.

Ну да, балду гоняет, ага.

I>>Разумеется, задачи это программирование. ТОлько цель и задача это разные вещи, ты их путаешь.

K>Ну, теперь еще и цели какие-то появились.

Они всегда были

По крайней мере я их уже упоминал.

I>>Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

K>Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.

Снова теория заговора какая то выходит. Реально ЯП

I>>ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

K>Это что, "общие слова" так выглядят?

Ну ты просто брякнул про лямбда лифтинг без конкретики. Я тебе ответил в том же духе.

I>>Я показал слова одного из авторов Алгола, который утверждает что стек они всего то использовали а не изобретали.

K>Ну, понятно, что я не утверждаю, будто они стопку изобрели. Но именно стек вызовов — это алголовская инновация.

Господи, стек вызовов был и до них. Они его только в процессор упрятали.

I>>Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

K>Потому, что MIX-ассемблер изобретен позже чем алгол — что тут удивительного?

То есть, необходимое и достаточное условие это время изобретения ? А вот мне кажется, что для рекурсии это как то параллельно.

I>>Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.
K>"Слова автора алгола" опровергаются делами авторов алгола. Есть реальность данная в ощущениях и есть заковыченные слова.

Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола. Есть чего возразить ? Или может и рекурсию изобрели тоже а алголе ?

K>Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?

Нет. Язык по прежнему не имеет смысла в отрыве от задач.

K>Еще раз: вред от того, что замыканием называются разные вещи вы и сами описали. а польза от этого обобщения какая? Вот и опять — "сущности" у них якобы одинаковые, вот только одна "сущность" позволяет ее использовать так, а другая якобы такая же — не позволяет.

Если сущности одинаковые, то отсюда следует, что использовать можно одинаково. Покажи пример этой якобы такой же

I>>Я говорю о том, что описание конкретного явления потребует меньше слов если выбросить одно из понятий, при чем без какого либо ущерба.

K>Не правда, с ущербом, который вы сами же и описали.

Нет никакого ущерба.

I>>Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

K>Ага, а если человек ничего не украл — он все равно вор, просто потому что так проще.

Имущество по определению не может быть пустым местом, следовательно твоя аналогия неверна.

Здравствуйте, Klapaucius, Вы писали:

K>"Домен C++" тут "домен языка C++". Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?

Это __враньё__. Именно тебе я не раз и не два объяснял, что язык спокойно может быть пригоден для решения самых разных задач. Следоваетельно говорить о домене в таком случае мягко говоря не получится.

Здравствуйте, Ikemefula, Вы писали:

K>>Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?
I>Это __враньё__.

Это чистая правда.
Вот тут вы написали:

язык проектируется под определенный набор фич, а точнее под определенные задачи, которые могут требовать, а могут и не требовать полноценные фичи

Это и означает, что у языка есть домен, что он не общего назначения. Дальше в той подветке вы в ответ на мои возражения о том, что "язык спокойно может быть пригоден для решения самых разных задач" все дальше разрабатываете тему всеобщей дээсэльности и доходите до того, что приводите в пример SQL — т.е. для вас все языки — DSL.

I>Именно тебе я не раз и не два объяснял, что язык спокойно может быть пригоден для решения самых разных задач.

Вы не в первый раз сами себе противоречите, часто в одно посте. Но я, разумеется, спорю с теми утверждениями, которые не совпадают с моими.

I>Следоваетельно говорить о домене в таком случае мягко говоря не получится.

Это надо понимать так, что вы окончательно отказываетесь от своего первоначального утверждения о специализируемости языков и конструировании языка под конкретные задачи, но чтоб сохранить хорошую мину при плохой игре приписали свои заблуждения мне?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Ikemefula, Вы писали:
K>>Ну и в этом случае программист тоже задачи бизнеса не решает.
I>Ну да, балду гоняет, ага.

Бывает и так, но если правильно процессы выстроены — программирует. Я, конечно, не считаю невероятным существование компаний в которых программисты занимаются не своим делом — задачи бизнеса решают или даже полы моют — вот только это совершенно не нормально.

K>>Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.
I>Снова теория заговора какая то выходит. Реально ЯП

Где же тут теория заговора? Я вам продемонстрировал пару механизмов с положительной обратной связью, которые совершенно естественным путем создают такую конфигурацию с несколькими мегапопулярными языками, которые приходится для всего применять.

I>Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола. Есть чего возразить ? Или может и рекурсию изобрели тоже а алголе ?

Рекурсия появилась в лиспе, но там для ее организации нужна была куча и сборщик мусора. А стек, как техника автоматического управления памятью для организации рекрусии без кучи и ГЦ — да, именно в алголе и появился. Что я тут уже месяц и растолковываю.

K>>Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?
I>Нет. Язык по прежнему не имеет смысла в отрыве от задач.

Не имеет, но эта задача — написание библиотек и их "склеивание" — появилась давным давно и привела к возниконовению первых ЯП и их дальнейшему развитию. В ответ на задачу "покрасить забор" или "обработать музыку" появляются библиотеки/дсл, а не языки общего назначения.

I>Если сущности одинаковые, то отсюда следует, что использовать можно одинаково.

О чем я и говорю. А вы утверждаете что замыкание и не замыкание — это одно и то же — "замыкание". Хотя использовать их одинаково нельзя.

K>>Не правда, с ущербом, который вы сами же и описали.
I>Нет никакого ущерба.

Есть, по вашему же собственному утверждению:

Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

Т.е. детально расписано, почему различать замыкание и не замыкание полезно, а не различать — вредно.

I>Имущество по определению не может быть пустым местом, следовательно твоя аналогия неверна.
Замыкание тоже не может — следовательно аналогия адекватна.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Klapaucius, Вы писали:

K>Бывает и так, но если правильно процессы выстроены — программирует. Я, конечно, не считаю невероятным существование компаний в которых программисты занимаются не своим делом — задачи бизнеса решают или даже полы моют — вот только это совершенно не нормально.

Бизнес ставит задачи. Как ты их решишь, напишешь ли библиотеку или возьмешь имеющуюся или скажем сконфигуришь готовое решение — не важно. Главное что бы требования были выполнены.

K>>>Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.
I>>Снова теория заговора какая то выходит. Реально ЯП

K>Где же тут теория заговора? Я вам продемонстрировал пару механизмов с положительной обратной связью, которые совершенно естественным путем создают такую конфигурацию с несколькими мегапопулярными языками, которые приходится для всего применять.

I>>Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола. Есть чего возразить ? Или может и рекурсию изобрели тоже а алголе ?

K>Рекурсия появилась в лиспе, но там для ее организации нужна была куча и сборщик мусора. А стек, как техника автоматического управления памятью для организации рекрусии без кучи и ГЦ — да, именно в алголе и появился. Что я тут уже месяц и растолковываю.

Еще раз — один из авторов алгола с тобой не согласен, он утверждает что всего то заюзали стек и сделали поддержку в процессоре. Всё.
До этого стек и рекурсию организовывали ровно так же, как это делает Кнут в своем ассемблере.

I>>Нет. Язык по прежнему не имеет смысла в отрыве от задач.

K>Не имеет, но эта задача — написание библиотек и их "склеивание" — появилась давным давно и привела к возниконовению первых ЯП и их дальнейшему развитию. В ответ на задачу "покрасить забор" или "обработать музыку" появляются библиотеки/дсл, а не языки общего назначения.

На одну задачу конечно же никто язык обычно не пишет

I>>Если сущности одинаковые, то отсюда следует, что использовать можно одинаково.

K>О чем я и говорю. А вы утверждаете что замыкание и не замыкание — это одно и то же — "замыкание". Хотя использовать их одинаково нельзя.

Наоборот — можно. А если нельзя, то это не замыкание. Мне реально интересно, как ты ухитряешься выворачивать мои слова буквально наизнанку ?

K>Есть, по вашему же собственному утверждению:
K>

K>Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
K>Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
K>Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

K>Т.е. детально расписано, почему различать замыкание и не замыкание полезно, а не различать — вредно.

"Передача функий вверх", "Передача функий вниз" — тебе это о чем то говорит ? У меня и то и другое — замыкание. А у тебя — замыкание и незамыкание.
То есть, здесь сравнение поедания котлеты вилкой с прочисткой канализации той же вилкой.

I>>Имущество по определению не может быть пустым местом, следовательно твоя аналогия неверна.
K>Замыкание тоже не может — следовательно аналогия адекватна.

Для того, что бы вводить отдельное понятие нужны основания. Их нет. Потому проще помножить контекст на всем известный 0 и получить в результате пустой контекст.

От:	IT	linq2db.com
Дата:	28.07.12 17:23
Оценка:	+4

От:	Sinclair	https://github.com/evilguest/
Дата:	30.07.12 03:27
Оценка:	80 (8) +3

	От:	SV.
	Дата:	27.07.12 11:01
	Оценка:	14 (4) +5

От:	IT	linq2db.com
Дата:	27.07.12 19:23
Оценка:	+9

	От:	vdimas
	Дата:	31.07.12 16:43
	Оценка:	-5

От:	samius	http://sams-tricks.blogspot.com
Дата:	28.07.12 10:47
Оценка:	38 (1) +5

	От:	Klapaucius
	Дата:	10.08.12 08:22
	Оценка:	134 (6) -1

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	30.07.12 18:01
Оценка:	135 (4) +1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	02.08.12 15:11
Оценка:	85 (2) -1

	От:	Steamus
	Дата:	30.07.12 19:09
	Оценка:	1 (1) -1

От:	Mamut	http://dmitriid.com
Дата:	01.08.12 10:16
Оценка:	1 (1) +1 -1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	01.08.12 20:40
Оценка:	1 (1) +3

	От:	Воронков Василий
	Дата:	31.07.12 17:14
	Оценка:	+2 -1

	От:	grosborn
	Дата:	01.08.12 16:21
	Оценка:	15 (1) +1

От:	jazzer	Skype: enerjazzer
Дата:	30.07.12 05:30
Оценка:	14 (1) +1

От:	мыщъх	http://nezumi-lab.org
Дата:	28.07.12 04:13
Оценка:	+2

От:	KARPOLAN	http://karpolan.com
Дата:	15.08.12 07:49
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	29.07.12 04:03
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	01.08.12 18:38
Оценка:	+1

От:	-VaS-	vaskir.blogspot.com
Дата:	11.08.12 18:26
Оценка:	+1

От:	MTD	https://github.com/mtrempoltsev
Дата:	28.07.12 05:39
Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	28.07.12 10:14
Оценка:

От:	AlexCab	LinkedIn
Дата:	28.07.12 13:51
Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	09.08.12 07:33
Оценка:

	От:	Maxim S. Shatskih
	Дата:	14.08.12 14:23
	Оценка:

От:	Lazin	http://evgeny-lazin.blogspot.com
Дата:	24.09.12 11:02
Оценка: