> G>Тоже очень интересно про зависимость уборки мусора от количества типов и протухание кэша. Новые для меня концепции.
>
> Тогда это тебе не надо.
>
> Но если любопытно, то понаблюдать самому проще простого: попробуй на досуге автонагенерить несколько сотен каких-нить синтетических тестов, надо чтобы их код не бы в бинарнике взаимно повторно используемым (можно брать пару десятков синтетических тестов и раширить их на несовместимые типы: int, long, double, float, complex<float>, complex<double>, coordinate<xxx> и т.д., можно это наполовину автоматизировать на генериках + value type). Затем, тем же автогенеренным кодом надо прогнать сначала в цикле каждый из синтетических тестов в отдельности, чтобы длительность каждого была сотню миллисекунд минимум, запомнить медиану результатов и вывести общую стоимость прогона, если бы каждый тест прогнали по 1-му разу. Затем надо все вместе тесты гонять по 1-му разу в цикле с паузой 100ms, 10ms, 1ms, 100us, 50us, 20us (пауза м/у полными циклами переборов тестов). Над результатами медитировать.

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

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

Дальщше что?

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

Здравствуйте, DarkGray, Вы писали:
DG>и по какой модели построен, например, интерфейс gmail-а, интерфейс редактора Drawing из google docs, интерфейс Visual Studio, интерфейс инет-банка СберБанка?
DG>или это всё устаревшие примеры GUI? что тогда не устаревший GUI?
Интерфейс гмейла построен, в первую очередь, на search & navigation. Интерфейс VS — объектно-ориентированный, но это большая редкость. И целевая аудитория у студии, скажем так, нетипичная. Интерфейс Сбера я не видел, а вот интерфейс Собиндиректа — классический navigation (с поправкой на некомпетентность архитекторов, но она вообще типична для веб-приложений).

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

Здравствуйте, 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>Вот тебе еще одна косвенная оценка.

То есть, если некто ищет и читает про монады в эту статистике не попадёт, правильно ?