Здравствуйте, eao197, Вы писали:
G>>"Многословность" — это симптом. Причиной является то, что ты назвал в дискуссии со мной "глобальная асинхронность".
E>Глобальная асинхронность и многословность в C++ -- это, имхо, две ортогональные друг другу вещи.
Я показал на конкретном примере, как связаны эти ортогональные друг другу вещи. Нет? "Многословность" не есть неотъемлемое свойство С++, это свойство именно твоего подхода.
G>>Не изменив подход к проблеме, ничего радикально исправить нельзя.
E>Я не вижу проблемы там, где ты говоришь.
Не замечать простые но неудобные тебе вещи, лежащие на поверхности — это твое полное право. Не видишь — и хорошо.
E>Если что-то делается слишком сложно с помощью SO, то просто не нужно делать это с помощью SO.
Так как самые простейшие вещи делаются слишком сложно с помощью SO, то класс того, что не нужно делать с его помощью, чрезвычайно широк. Я бы _ничего_ не стал делать с его помощью п освоей воле, ибо он не дает никаких преимуществ по сравнению с простой реализацией конечных автоматов паттерном ООП. Так же как и MFC не имеет никаких преимуществ по сравнению с нормально спроектированной гуевой библиотекой.
Здравствуйте, Gaperton, Вы писали:
E>>Глобальная асинхронность и многословность в C++ -- это, имхо, две ортогональные друг другу вещи.
G>Я показал на конкретном примере, как связаны эти ортогональные друг другу вещи. Нет?
Нет. Ты показал пример, в котором применение конечного автомата в твоих конкретных условиях было невыгодно. Во-первых, этот пример ни в коем случае отрицает существования обратных ситуаций, когда конечные автоматы будут более удобными. Во-вторых, он не показывает необходимости совмещения в одной библиотеки подхода на основе конечных автоматов и файберной магии.
G>"Многословность" не есть неотъемлемое свойство С++, это свойство именно твоего подхода.
В-третьих, многословность в моем подходе обуславливается поддержкой возможностей, которые мы сейчас вообще не рассматриваем. В частности, удаленного контроля за состоянием агентов. И поддержки распределенных приложений.
E>>Если что-то делается слишком сложно с помощью SO, то просто не нужно делать это с помощью SO.
G>Так как самые простейшие вещи делаются слишком сложно с помощью SO, то класс того, что не нужно делать с его помощью, чрезвычайно широк.
Да. Им еще и гвозди забивать нельзя. И кофе он не варит. Так что класс таких задач стремительно стремится к бесконечности.
G>Я бы _ничего_ не стал делать с его помощью п освоей воле, ибо он не дает никаких преимуществ по сравнению с простой реализацией конечных автоматов паттерном ООП.
И, заметь, тебе этого даже никто не предлагает.
G>Так же как и MFC не имеет никаких преимуществ по сравнению с нормально спроектированной гуевой библиотекой.
Тем не менее, это вовсе не мешает использовать MFC (и очень похожего на него wxWidgets) в огромном количестве разработок.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Эта увлекательная дискуссия закончилась еще в 70-х годах. Думаю, не надо напоминать, чем?
Напомни, если не сложно.
G>Это хорошо выглядит на картинке, и отвратительно — в коде.
Да нормальная последовательность для многошаговой установки связи. Перерисованная на state diagram она не поменяет своей сути.
V>> Как, кстати, обстоят дела с интеропом в Эрланге?
G>Есть байндинги в Java, C/C++, CORBA. Есть, в конце концов, сокеты .
Я имел ввиду, каковы собственные ощущения от доступности/простоты интеропа (насколько я понял, ты плотно с ним работал).
Просто писать все целиком на Эрланге — это весьма спорно, но в нашей системе есть несколько мест, где бы философия легковесных процессов была как нельзя кстати, вот и охота предварительно оценить затраты на внутренние эксперименты.
К>Не знаю, по-моему оно и на картинке выглядит извратно аля "кручу верчу — запутать хочу!"
Это потому что без надписей, а так — примерный алгоритм установки связи для H323, развернутый "линейно", с тем самым состоянием на стеке. В виде state-диаграммы весьма тривиален.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Курилка, Вы писали:
К>>Не знаю, по-моему оно и на картинке выглядит извратно аля "кручу верчу — запутать хочу!"
V>Это потому что без надписей, а так — примерный алгоритм установки связи для H323, развернутый "линейно", с тем самым состоянием на стеке. В виде state-диаграммы весьма тривиален.
Вроде как автоматы без goto вполне пишутся, или выбирать наиболее подходящую абстрацию уже не модно
Здравствуйте, Курилка, Вы писали:
V>>Это потому что без надписей, а так — примерный алгоритм установки связи для H323, развернутый "линейно", с тем самым состоянием на стеке. В виде state-диаграммы весьма тривиален.
К>Вроде как автоматы без goto вполне пишутся, или выбирать наиболее подходящую абстрацию уже не модно
Ха, именно, о том и речь, что явным образом моделируемые автоматы — вовсе не всегда зло, поднимись чуть выше на ветке.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Курилка, Вы писали:
V>>>Это потому что без надписей, а так — примерный алгоритм установки связи для H323, развернутый "линейно", с тем самым состоянием на стеке. В виде state-диаграммы весьма тривиален.
К>>Вроде как автоматы без goto вполне пишутся, или выбирать наиболее подходящую абстрацию уже не модно
V>Ха, именно, о том и речь, что явным образом моделируемые автоматы — вовсе не всегда зло, поднимись чуть выше на ветке.
Не знаю, но вот "фреймворк вынуждает программиста к разворачиванию всех сценариев взаимодействия агентов в явно записанные конечные автоматы" и то, что автоматы — всегда зло, по-моему 2 очень разных утверждения, или я не прав?
К>Не знаю, но вот "фреймворк вынуждает программиста к разворачиванию всех сценариев взаимодействия агентов в явно записанные конечные автоматы" и то, что автоматы — всегда зло, по-моему 2 очень разных утверждения, или я не прав?
Частично. Ведь если мы взяли такой фреймворк, значит задача соответвующая (хочется так думать). А иначе надо брать другой. И вообще, никто не запрещает в одном продукте объединять фреймворки и подходы, гдавное — чтобы удачно соответствовало конкретной задаче, остальное — разговоры в пользу бедных.
Здравствуйте, AndrewVK, Вы писали: AVK>В контексте этого топика важна именно возможность, а не отсутствие поддержки других стилей.
Ну, будем честными — так не стоит переопределять оператор is.
Вспомни C++ и голые указатели — мы же из своего управляемого мира хихикаем над их заявлениями про то, что "важна именно возможность xxx_ptr<T>, а не отсутствие поддержки void*".
Имхо, тут есть как бы три уровня "поддержки возможности":
0. Теоретически возможно, но ценой чрезмерного геморроя, поэтому никто не делает (если у вас себестоимость нефти $80 за баррель, то лучше добывать что-нибудь другое)
1. Возможно, достаточно нетрудно добиться и применять, но нельзя заставить пользоваться только этим.
2. Можно отключить "отсутствие поддержки" возможности и получить строгие доказательства полезных свойств программы.
Шарп по отношению к ФП медленно, но верно дрейфует от 0 к 1. При этом для хардкорных функциональщиков стакан всё еще "наполовину пуст", и посему интереса не представляет. Они хотят такую поддержку, на которую можно было бы положиться. (а не как const в С++, который "если нельзя, но очень хочется, то можно").
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>>Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все. G>Как в анекдоте: G>-синхронная запись лучше, чем асинхронная G>-чем лучше? G>-чем асинхронная!
Тут всё зависит от того, насколько жёсток протокол. Если приходящие сообщения более-менее независимые, а реакция на них более-менее сложна, то лучше подход с "явной асинхронностью".
Ну типа как мы пишем обработчики оконных сообщений: каждый обработчик выглядит независимым. Переписывание в "синхронном стиле" даст нам классический message loop с матёрым свитчем внутри.
А вот если протокол предусматривает небольшое количество вариантов в цепочках состояний, то наоборот — восстановление "смысла" работы сервера по отдельным фрагментам будет трудным и непонятным.
В частности, пример с копированием это наглядно подтверждает. Ручное распиливание даст нам четыре фрагмента, соответствующие переходам между состояниями; догадаться, что в сумме они дают копирование входа на выход — тяжкий труд.
G>>Данная "декларативность" его имхо затрудняет. G>Данная декларативность не влияет на наблюдаемое поведение.
Это, на самом деле, тяжкое наследие. В том смысле, что логически что синхронная, что асинхронная версии делают одно и то же.
Блокирующий вызов не приводит к остановке процессора — CPU переключает поток, и математически это ничем не отличается от файбера, или от IO Completion Port.
К сожалению, абстрактная математика здесь всё еще неприменима. Тупая машина не может догадаться, что мы имеем в виду, выполняя блокирующий вызов. В частности, ей непонятно, какой объём состояния потребуется нам для того, чтобы восстановиться с прерванной точки — и она на всякий случай откладывает в сторону целый стек, весом ажно в мегабайт.
Построение КА позволяет нам вручную указать то подмножество состояния, которое нам важно.
Это изменит "поведение", наблюдаемое в любом инструменте мониторинга в виде потребления ресурсов.
Рихтер предложил полуавтоматическое построение КА — то есть сам автомат строит Шарп, но нам нужно явно показывать, какие переходы нас интересуют.
Axum, очевидно, продолжает подход Рихтера в сторону автоматизации написания асинхронного итератора.
С точки зрения абстрактного смысла, вообще неясно, для чего нужны блокирующие вызовы при IO. Можно (было бы) тупо принудительно заменять вообще все Write на BeginWrite/yield/EndWrite. Заметить разницу прикладной код может только в том случае, если он явно пользуется какой-то тред-спецификой. По идее ему должно быть абсолютно наплевать на то, сменился ли Thread.Current.ID в процессе вызова Write или нет. Но, похоже, пока что об этом говорить рано.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Шарп по отношению к ФП медленно, но верно дрейфует от 0 к 1. При этом для хардкорных функциональщиков стакан всё еще "наполовину пуст", и посему интереса не представляет.
Ну так я о том же и писал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1226 on Windows Vista 6.1.7100.0>>
Здравствуйте, IT, Вы писали: IT>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression.
Ну, if-expression, к счастью, есть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
IT>>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression. S>Ну, if-expression, к счастью, есть.
К счастью есть, к несчастью сильно кастрированный.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Да сравнение с образцом.
Не мешало бы. Правда Немерле можно рассматривать как доведенный до ума C# в котором как раз сравнение с образцом поддерживается. Только радостных толп переходящих на него пока не замечено. Так что для масс это не проблема вовсе. Для них не существует все то что они не понимают.
T>Да функции высших порядков.
Уже давно есть.
T>Да неизменяемые данные (что и есть основа для сравнения с образцом).
Это ты чушь сказал. Неизменяемость для для сопоставление с образцом не требуется. Nemerle, F# и даже некоторые диалекты Лиспа поддерживают сопоставление с образцом для изменяемых структур данных.
Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан. Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
T>Erlang больше, чем сообщения и процессы.
Откровенно говоря не сильно то он больше если отбросить ПМ. Обычный скриптовый язык нечто вроде помеси лиспа с питоном.
T>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.
Таварищи занимаются исследованиями. Науку творят. За одно бабло зарабатывает (гранты от МС). Уверен, что им вся эта пенисометрия до лампочки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>>Да неизменяемые данные (что и есть основа для сравнения с образцом). VD>Это ты чушь сказал. Неизменяемость для для сопоставление с образцом не требуется. Nemerle, F# и даже некоторые диалекты Лиспа поддерживают сопоставление с образцом для изменяемых структур данных.
Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать.
Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя.
VD>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан.
Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов. Алгебраические типы данных здесь побоку, например, в теории типов Мартина Лёфа всё строится на зависимых парах. Хочешь — списки, а можно и натуральные числа, если, конечно, нет желания сделать деревья.
VD>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
Практически никакого. Контроля. Не будет.
T>>Erlang больше, чем сообщения и процессы. VD>Откровенно говоря не сильно то он больше если отбросить ПМ. Обычный скриптовый язык нечто вроде помеси лиспа с питоном.
Ещё библиотека времени выполнения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Да неизменяемые данные (что и есть основа для сравнения с образцом). VD>>Это ты чушь сказал. Неизменяемость для для сопоставление с образцом не требуется. Nemerle, F# и даже некоторые диалекты Лиспа поддерживают сопоставление с образцом для изменяемых структур данных.
T>Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать. T>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя.
Не так вс плохо в F#, там данные по умолчанию неизменяемы. С помощью модификатора mutable становятся изменяемыми.
VD>>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан. T>Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов. Алгебраические типы данных здесь побоку, например, в теории типов Мартина Лёфа всё строится на зависимых парах. Хочешь — списки, а можно и натуральные числа, если, конечно, нет желания сделать деревья.
Не знаю насчет классического ПМ, а в соременном F# такие функции-селекторы объявлять самому можно. В такую функцию изменяемые данные не подсунешь
Здравствуйте, thesz, Вы писали:
T>Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать.
У тебя мания величия. Можно подумать, что твоих рекомендаций кто-то ждет.
T>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом.
На практике это не проблема. Если человек сделал структуру данных изменяемой, значит он понимает что тварит. Обычно это оптимизация. Например, в AST немерла есть поле Location определяющее местоположение соответствующего кода в файле. Само поле ни на что не влияет, использовать в ПМ его практически бесполезно. Однако очень важно, чтоб было можно менять это поле не пересоздавая объекты. Например, при редактировании файла нужно обеспечить корректировку ветвей АСТ которые располагаются ниже области редактирования. Иначе прийдется каждый раз перепарсивать весь файл.
T>Преобразовать сравнение с образцом в вызов функции уже нельзя.
А оно надо? В прочем, думаю, что ты и тут ошибаешься. Это только в хаскеле функции не могут иметь замканий на изменяемые данные. А в гибридных языках — это нормальная практика. Так что преобразовывать можно. Вопрос только зачем.
VD>>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан.
T>Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов.
Блин, бессмертный .
Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
T>Алгебраические типы данных здесь побоку, например, в теории типов Мартина Лёфа всё строится на зависимых парах. Хочешь — списки, а можно и натуральные числа, если, конечно, нет желания сделать деревья.
Теорий много. Практика одна. И на практике четкого алгоритма ПМ для ОО-объектов (смешно звучит) не придумано. Потому в Скале и F#-е фактически предлагается создавать конверторы в АлгТД и обратно.
VD>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
T>Практически никакого. Контроля. Не будет.
Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
Кстати, в том же Эрланге ПМ тоже не контролируемый (как я понимаю). Но это не мешает его использовать.
T>>>Erlang больше, чем сообщения и процессы. VD>>Откровенно говоря не сильно то он больше если отбросить ПМ. Обычный скриптовый язык нечто вроде помеси лиспа с питоном.
T>Ещё библиотека времени выполнения.
Ну, библиотека есть библиотека. У того же дотната она куда больше и мощнее. Доделают что нужно, если что.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
VD>>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
T>>Практически никакого. Контроля. Не будет.
VD>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
VD>Кстати, в том же Эрланге ПМ тоже не контролируемый (как я понимаю). Но это не мешает его использовать.
Какой-то странный термин вы изобрели...
Если под ним подразумевается ПМ по неизменяемым данным (и дальнейшее соблюдение условий ПМ), то в Эрланге он контролируемый по самое "не балуйся", т.к. изменяемых данных там практически нет (если не брать словарь процесса и ввод/вывод, включая сообщения, но даже они не могут "поменять" имеющиеся переменные, single assignment)
.
Если нам не помогут, то мы тоже никого не пощадим.
