Здравствуйте, 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>И это совершенно правильно и корректно. Вот только учебники ООП почему-то как правило при рассмотрении коровы и травы не предлагают моделировать машину Бэббиджа, зато предлагают моделировать корову и траву.
Я привел пример где моделируется именно корова и трава, только коровой был медведь, а травой — мертвечина. Чем тебя этот пример не устроил ?
>Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".
Ну так в учебниках синтетические задачи, это общая беда без малого всех учебников по программированию, при чем в ФП это вообще считается за норму. Просто авторы смешивают программирование и моделирование.
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>По указанной в пред посте ссылке, рядом с этим постом в обсуждении есть разбор механики тайпклассов для таких сценариев.
разбор механики ничего не говорит о заимствовании.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>В СП ветвление — оно об выполнении стейтментов. В хаскеле их нет.
V>А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо.
Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.
V>Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу.
Еще раз. Речь идет об ветвлении исполнения стейтментов, где стейтменты изменяют состояние программы. В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.
Здравствуйте, 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.
Здравствуйте, Sinclair, Вы писали:
I>>Линейка.ВзятьСумму(5,3) Причем это ровно тож самое, что и в анемиках TransferSevice.Transfer(acc1,acc2, amount) S>Попробуйте этот трюк с реальной линейкой. Посмотрим, возьмёт ли она сумму. S>Или всё-таки придётся самостоятельно выполнять действия с ней — руками, глазами, и мозгом.
Мы можем как угодно моделировать эту самостоятельность, ООП ничем не мешает.
I>>Внезапно, если вспомнить контекст, что вычислитель был нужен в примере про математические операции S>Ну, а вот в пятом классе, при решении квадратных уравнений, почему-то обходятся безо всяких вычислителей.
Ничего страшного, можно моделировать не всего ученика, а только отдельную его способность, которая нас интересует. И это снова будет Вычислитель.
S>А если у нас задача стоит чуть по-другому — например, начисление людям зарплаты, то внезапно окажется, что ни зарплата, ни люди объектами не являются. Хотя на основе учебников так и кажется, что класс Manager будет отнаследован от класса Employee.
Так это примеры в учебниках синтетически а не ООП плохое
>>>Вы посмотрите на классические примеры — что мы там видим? Компьютеры? Передачу пакетов? Нет блин, мы видим "жирафа", как потомка "млекопитающего", и "грузовой автомобиль", как потомка "транспортного средства".
I>>Ну так в учебниках синтетические задачи, это общая беда без малого всех учебников по программированию, при чем в ФП это вообще считается за норму. Просто авторы смешивают программирование и моделирование. S>Ну вот и не надо повторять ошибки этих учебников. Надо отказаться от желания моделировать реальный мир там, где задача не стоит в моделировании реального мира, и сразу ООП заиграет яркими красками.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Гарантия наличия реализации есть, но гарантии корректной реализации нет.
AVK>Нет, но это не страшно. Все таки программные проверки это не безопасность, рассчитывать надо прежде всего на случайные ошибки, а не на сознательное вредительство.
да, и что-то можно не реализовать случайно, особенно после генерации заглушки с исключением.
Я согласен, что для взаимодействия с C# и VB лучше было бы генерить визитора для вариантов, но это не основной сценарий, потому генерить его компилятором ФЯ для всех вариантов может быть накладно (можно было бы использовать атрибут для маркировки актуальных типов).
S>>Да, с вытекающим рантайм контролем, который нехило бы чекнуть тестами. Что, собственно, не вредно сделать и с рукописным визитором, т.к. компилятор корректность диспетчеризации не контроллирует.
AVK>Я категорически против отказа от статики ради решения каких то внутрипрограммных задач. Так что для меня это не вариант.
Хорошо, нечего возразить и добавить. Точка.
Здравствуйте, samius, Вы писали:
V>>А ветвление в логических рассуждениях человека оно о чем? ИМХО, рассуждения более чем чисты, а ветвление — налицо. S>Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.
Какое мне дело, что именно тебя не интересует?
V>>Кароч, отрицать ветвление в ФП не выйдет. Довод, что "ветвление другой системы" вообще ни о чем, в обсуждаемом вопросе система не интересует ни разу. S>Еще раз. Речь идет об ветвлении исполнения стейтментов,
Речь идёт о ветвлении как таковом. Остальное — твои личные фантазии и неуклюжие попытки ограничить меня уютными тебе рамками.
S>В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.
Я про возможность применения его в IO без каких-либо доработок вроде бы сказал сразу, не? Тебе это сколько еще повторять? Побочный эффект возникает ПОСЛЕ применения if, ес-но, как результат выполнения хвоста в цепочке IO-вычислений. Ес-но не в момент вычисления предиката при if, а в момент прохождения потока вычисления только по одной из двух веток, описанных в исходнике. Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Воронков Василий, Вы писали: ВВ>>>>Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет. I>>>А что ты видел в дизайне распределенных ? ВВ>>Анемики, сервисы и иже с ними.
I>Это все православное ООП
А каким образом 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>разбор механики ничего не говорит о заимствовании.
Согласен, на уровне механики заимствование не считается, это лишь подробности. Но на уровне концепции это есть контракт, который сам по себе концепция в ООП в таком точно виде. Т.е. в кач-ве концепции дизайна тайпклассы и контракты в ООП настолько близки, насколько это вообще возможно, т.к. и те и другие задают набор операций над одним и тем же элементом дизайна, в обоих случаях над типом.
Фаулер думает про ООП в симуловский концепции — данные + методы, так что его точка зрения вполне понятна. Зато анемик ничем не мешает ООП если посмотреть людей вроде Скотт Мейерс и Алан Кей.
ВВ>А каким образом SOA со своими политиками, stateless (в большинстве случаев) сервисами (а следовательно, и лишенными поведения) и совершенно другими принципами декомпозиции становится ООП да еще православным?
Если отталкиваться от симуловской концепции ОО, то да, это не ОО
Здравствуйте, Sinclair, Вы писали:
S>Омг, омг. У нас была предметная область (вы называете её реальным миром), состоящая из коровы и травы. S>Внезапно (ВНЕЗАПНО!) в этот реальный мир внедряется некое устройство, как идея вычислителя.
Эта идея была изначально. На этой идее построен сам процесс самоорганизации простой материи в сложные конструкции, в жизнь. Генерирование белков по шаблонным участкам ДНК — вполне себе АЛГОРИТМ. Безусловные реакции коровы на сигналы от желудка, трансформируемые в сложное поведение поиска и поедания травы — тоже АЛГОРИТМ, только чуть сложнее. Кароч, без вычислителя не было бы алгоритмов и не было бы способа сложной материи — жизни, которая являет нам своё многообразие как результат многообразия аналогичных описанным алгоритмов.
S>У пастуха, который пас корову, ни разу в жизни не возникло идеи про этот вычислитель.
Ну... центральный-то вычислитель пастуха всяко умнее вычислителя коровы будет.
А возникла идея вычислителя о самом себе или нет — это вопрос самосознания, который не принципиален тут ни разу. Мой рабочий десктоп никак себя не осознает, но это не мешает ему быть нехилым таким вычислителем.
Здравствуйте, Ikemefula, Вы писали:
ВВ>>Анемик — православное ООП? Фаулер бы поспорил с вами: http://martinfowler.com/bliki/AnemicDomainModel.html I>Фаулер думает про ООП в симуловский концепции — данные + методы, так что его точка зрения вполне понятна. Зато анемик ничем не мешает ООП если посмотреть людей вроде Скотт Мейерс и Алан Кей.
Кей — это объекты, поведения, сообщения. Никаким анемиком и не пахнет. Это ж это один из тех мужиков, которые смолток сделали. Он точно не по ошибке сюда попал?
ВВ>>А каким образом SOA со своими политиками, stateless (в большинстве случаев) сервисами (а следовательно, и лишенными поведения) и совершенно другими принципами декомпозиции становится ООП да еще православным? I>Если отталкиваться от симуловской концепции ОО, то да, это не ОО
Мне не знакома такая траковка ООП, которая бы вмещала в себя еще и все принципы SOA. Зачем ее сейчас выдумывать?
Принципы ООП были заложены в Симуле и оформились в Смолтоке. По сути ООП это и есть Кей и Смолток. А это значит "состояние", "поведение", "все есть объект" и проч. SOA тут как-то немножко мимо.
Здравствуйте, Ikemefula, Вы писали:
I>Ты описал модель, правильно ? ты не в состоянии повторить её или же она неадекватна ?
В модели графы объектов многих типов. Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов.
OK, поиграю на новом десктопе и на старом, бо разница на порядок — многовата.
V>>Не только. Проблемы от того, что мы храним сами сообщения. I>После упоминания интрузивных списков я еще больеш уверен, что никакой экономии твоя статика не даёт, разве что пустой список у тебя не весит в 100кб
Т.е. ты уже замерил эффективность интрузивной очереди vs стандартной очереди?
Не верю! (С)
>>Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.
I>И это еще больше усиливает уверенность, что экономия на пустом списке как мертвому припарка, дальше я скипнул.
Ты скипнул аргумент о лишнем ветвлении в алгоритмах. Похоже, ты не понимаешь, за какой порядок цифр идет борьба. Кол-во сообщений в сек уже дал. Вычти отсюда порядка 3us на сообщение, забираемое сетью, еще порядка 1us на межпотоковую передачу сообщений. Все, что осталось — твоё. Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.
Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.
Здравствуйте, AndrewVK, Вы писали:
K>>Начинаем с голословного утверждения о моей неадекватности.
AVK>Какая, нафик, неадекватность? Сочиняешь на ходу?
Ну да. И
Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.
тоже, наверное, я сам написал, залогинившись под вашим именем, ага?
AVK>считаешь что ФП безусловно лучше и перспективнее ООП.
Условно лучше и безусловно перспективнее. Ну так что? Как из этого утверждения можно вывести, что я считаю ФП — серебряной пулей? Или лучше ООП только "серебряная пуля" может быть?
AVK>Только там таких статей, что за, что против ООП
Статьи пишут не "за и против"
AVK>что можно найти любую заранее заданную точку зрения.
Я сомневаюсь, что вы найдете статью с простым формальным описанием нетривиального ООП.
AVK>Одна проблема — формальное описание интересно в основном только математикам и любителям CS.
Так вы же сами писали
Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
1) Создания абстракций с формальным описанием внешних свойств
А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?
AVK>А наследование, агрегация, композиция, это, по твоему, не комбинирование?
Повторяю: "агрегация" и "композиция" в ФП — это функции, агрегирующие и композирующие. А в ООП это слова — никакой реальный код им не соотвествует и на ООЯ не выражается. На ООЯ выражается только конечный результат композиции, произведенной программистом в уме, без всякой помощи компьютера.
Комбинаторы функций есть, комбинаторов классов — нет. Понятно теперь, о чем я?
AVK>Потому что без него объем писанины возрастает.
Все, без чего объем писанины вырастает — это подпорка? Т.е. "подпорка" никаких отрицательных коннотаций не имеет? А если вы таки говорили "подпорка" так, как будто это что-то плохое — объясните что же плохо в карринге?
K>>Туплы — это и есть АлгТД. AVK>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.
Нет? Это, конечно, заблуждение. Алгебраические типы — это типы-произведения (туплы, кортежи) и типы-суммы (размеченные объединения, варианты). Вторые, понятно, дискриминант имеют, а первым он без надобности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Причем это ровно тож самое, что и в анемиках TransferSevice.Transfer(acc1,acc2, amount)
