Здравствуйте, 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.>Нет, поскольку вы недопереписали вывод типов. Что вернут конвертеры?
Экземпляры какого-то абстрактного типа данных.

Здравствуйте, 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, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.

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

K>>>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
AVK>>Это не программисты уже в привычном понимании.

K>Привычном для кого ?

Для людей, присутствующих в софтверном бизнесе.

Здравствуйте, 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.>И, кстати, откуда у вас статичность взялась?
Как откуда? В приведённом коде метода нет никаких обращений к нестатическим мемберам. Так нахрена ему быть экземплярным?

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

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

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

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

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

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

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

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

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

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

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

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

I>>ООП работает там где в __решении__ задачи фигурируют физические объекты. Физический объект он с поведением и со свойствами.
S>Ничего подобного. Ну нету физического объекта "socket", который бы моделировался экземплярами класса CSocket. Это — математическая абстракция. У него нет физических свойств, таких как масса и линейные размеры.

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

I>>Вот здесь ООП работает. Собственно по этому во всех букварях по дизайну говорят, что надо моделировать объекты реального мира, но почему то этот совет понимается именно как генерация классов Лужа и Камень.
S>Ну, а какие объекты реального мира вы видите во взаимодействии лужи и камня?

Никакие, я не знаю как решить эту задачу, моей математики и физики для этого не хватает.

I>>Что касается симметричных операторов, то в ООП решением будет введение например сумматора — вполне себе физический объект. И точно так же с задачей про Account и перевод средств между оным естественным образом решение выливается в некоего вычислителя, и это будет TransferService.
S>Давайте мы слово "физический" не будем упоминать всуе, ок?

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

Здравствуйте, 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>И есть опасение, что даже если её удастся продемонстрировать, то она окажется многословной для программиста и неэффективной для исполнения.

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

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

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

> Любое ПО является лишь моделью мира.

2 + 4
— модель мира?

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

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

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