Здравствуйте, eao197, Вы писали:
E>В общем, да. Поскольку ты говорил, что замерял затраты на асинхронный и синхронный подходы, то было бы интересно взглянуть на результаты замеров.
E>Поскольку в своих задачах я просто видел возможность их решения с помощью асинхронных агентов (с приемлимыми трудозатратами и качеством). Но не видел такой возможности с синхронными подходами. А возможности тратить месяц на получение и внедрение одного решения, а затем еще месяц на разработку альтернативы с целью сравнения разных подходов -- такой роскоши не бывает.
Короче. Код по понятной причине показать не могу. Но могу описать ситуацию. Дело было так.
В CQG в сервере БД для обработки временных рядов есть подсистема "операторов" (преобразований над временными рядами), которые умеют преобразовывать временную шкалу для временного ряда. То есть, на вход идет последовательность котировок, а на выход — другой временной ряд, состоящий, скажем, из значений, соответствующих периодам монотонного возрастания и убывания значений во временном ряде. Один участок монотонности — одно значение. Этот "оператор" называется P&F.
Практически весь код в CQG написан в "асинхронном" стиле. Один поток, много коллбэков, блокировать надолго процесс нельзя. Проблема, из-за которой мне было поручено переписать P&F, состояла в том, что время вычисления одного значения временного ряда в случае P&F могло быть очень длинным, а архитектура не предполагала, что можно прерваться в середине расчета одного значения временного ряда. "Конечные автоматы" высокого уровня такого не предполагали, и поправить это было очень сложно.
То есть, помимо того, чтобы разработать способ решения предыдущей проблемы (что к делу не совсем относится), мне надо было развернуть достаточно простой последовательный алгоритм P&F, который уже был написан и работал, и занимал примерно экран кода, в конечный автомат.
Автомат простой, в нем три состояния. Период убывания, возрастания, или "разгон". "Сообщениями" конечного автомата являлись значения временного ряда котировок. "Переход" конечного автомата — генерация нового выходного значения. Примерно так. На самом деле, все было чуточку сложнее, так как по некоторой причине надо было еще и "развернуть" алгоритм, чтобы он работал при подаче входных значений в обратном времени, но это не важно.
Я затрахался это отлаживать (там была иерархия автоматов, алгоритм был внизу, по другому нельзя). Это оказалось удивительно долго — я сорвал сроки. Однако, я предполагал, что за P&F последуют задания на аналогичную переделку других "операторов" данной группы, и оформил это безобразие как маленький фреймворк, чтобы иметь меньше геморроя при последующих работах. Если ты помнишь рассказы про мой шедулер — я его тогда и написал, в том варианте он просто "честно" шедулил время между коллбэками, без всяких файберов.
И когда последовало аналогичное задание "а теперь сделай то же самое для оператора CVB", я понял, что ЭТОТ алгоритм разворачивать в конечный автомат я не хочу. И прикрутил к шедулеру файберы. В сроки, однако, заложил охрененные "буфера безопасности". Получилось однако, по оптимистичному прогнозу.
Потом, последовало еще два оператора. И я получил возможность оценить объем кода и сроки — у меня есть старый синхронный код, который писал не я, а также новый "асинхронный" и "синхронный" код. Разница оказалась примерно в два раза, при наличии корелляции с объемом кода. Что меня удивило. Ибо, по ощущениям и по количеству геморроя в P&F пошел месяц за два . Я ожидал разницы в четверо.
Сроки были порядка месяцев. Примерно две недели на оператор в синхронном варианте, без явных конечных автоматов, и месяц — на "асинхронный" вариант. Это чистая логика алгоритма. Учти, что я на тот момент очень хорошо умел писать асинхронный конечно-автоматный код. Количество строк кода — не помню. Помню вывод.
Потом, я многократно проверял этот вывод на практике, при случае, когда надо что-то порефакторить, заменяя старый асинхронно-коллбэчный код (которого в системе дофига) на новый "синхронный" код. Разница в читабельности и объеме поистине удивительная. Все та же, впрочем, в объеме — в среднем примерно в два раза.
E>>>Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.
G>>Я, вообще-то, этого не говорил.
E>Ну, поскольку мой подход ты называешь плохим, значит, по твоему мнению есть хотя бы один более хороший. С этим я не согласен. Плохость в одних задачах оборачивается хорошестью в других, и наоборот.
Да. У тебя "асинхронный" подход, которого я нахлебался по самые уши. Я тебе в другом посте объяснил.
Похоже, Microsoft кропеет над новым языком программирования для паралельных вычислений под названием Axum. Неизвестно еще, уйдет ли когда-либо в продакшн, но шансы вроде есть. На первый взгляд (disclaimer: я не сильный специалист в паралельном программировании) выглядит интересно, посмотрим, будет ли выхлоп.
Презентацию (требуется Silverlight) можно глянуть здесь, почитать немного здесь.
Краткое описание языка:
“It’s a language that builds upon the architecture of the web and the principles of isolation, agents, and message-passing to increase application safety, responsiveness, scalability and developer productivity. Other advanced concepts we are exploring are data flow networks, asynchronous methods, and type annotations for taming side-effects. We currently have a working prototype with basic Visual Studio integration and a few demonstrations of working code.”
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, VoidEx, Вы писали:
VE>Вот пока еррора нет, никакой функциональщины тоже нет. Она держится лишь на добром слове авторов соответствующих функций.
Здравствуйте, gandjustas, Вы писали:
E>>Более 100KLOC
G>На моей первой работе как раз был такой проект. Сейчас я знаю что тоже самое на .NET можно повторить с 10-кратным уменьшением объема. G>Так что размер — совсем необъективный поазатель.
Имелось в виду 100KLOC на Хаскеле. Для остальных можно смело умножать.
Здравствуйте, Gaperton, Вы писали:
G>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
... << RSDN@Home 1.2.0 alpha 4 rev. 1184 on Windows Vista 6.1.7000.0>>
Здравствуйте, eao197, Вы писали:
E>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?
А, кажется я понял. Ты не понимаешь, о чем идет речь, когда я говорю про синхронный и асинхронный стиль, и думаешь, что это имеет какое-то отношение к проблемам синхронизации .
Смотри. Вот это — асинхронный код. На "псевдокоде" пишу.
Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.
В твоем случае состояние переползет в явное состояние конечного автомата, и даже простые алгоритмы будут нашинкованы на явные состояния и переходы между ними. В таком коде без бутылки не разберешься, хоть как его "сахаром" разбавляй.
А разница между стилями ровно в одном. Как ты получаешь сообщение — синхронным блокирующим вызовом, или же ты вынужден вернуть управление наверх и получить коллбэк.
Это — самая существенная, фундаментальная разница, и Эрланг здесь собственно не причем. Хотя, его придумали люди, очень тонко и грубоко понимающие реальные проблемы построения больших систем, и он выглядит так, как выглядит, далеко не просто так. Скажем, подумай на досуге немного о том, почему и зачем в Эрланге сделан селективный receive на одном мэйлбоксе, а не по другому. Hint — это решение сильно упрощает код в реальных программах.
Здравствуйте, VoidEx, Вы писали:
VE>Не can avoid, а avoids.
Правильно, потому что для чисто функционального кода это не допустимо. Вообще, поражаюсь простой вещи — как что то по делу спрашиваешь, с кодом там, реакция вялая. Зато как терминологический спор — желающих хоть отбавляй.
В контексте этого топика важна именно возможность, а не отсутствие поддержки других стилей.
P.S. Я тут счас скажу кое кому, что язык на букву Н не функциональный, они вас буденовками закидают .
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
T>>Здесь у тебя ошибка. для set-cdr нужна переменная, вот ты и используешь x. в теле g переменная x недоступна, доступно только значение. MC>Ок MC>
MC>;(define (g x)
MC>; (set-cdr! x x)
MC>; "This is a scheme longcat: ")
MC>;
MC>В chicken scheme и plt (в режиме r5rs) этот код работает так же, как и мой предыдущий пример, т.е. cons-пара всегда передается по ссылке. Но вообще, я плохо помню нюансы модели памяти в scheme — надо будет полистать стандарт.
У меня guile/cygwin, я поправил свой вариант с твоими исправлениями.
Я в ужасе.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
G>Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.
"Проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи" с необходимостью писать программы с меньшим числом ошибок.
Сравнение с образцом здесь только инструмент.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать.
У тебя мания величия. Можно подумать, что твоих рекомендаций кто-то ждет.
T>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом.
На практике это не проблема. Если человек сделал структуру данных изменяемой, значит он понимает что тварит. Обычно это оптимизация. Например, в AST немерла есть поле Location определяющее местоположение соответствующего кода в файле. Само поле ни на что не влияет, использовать в ПМ его практически бесполезно. Однако очень важно, чтоб было можно менять это поле не пересоздавая объекты. Например, при редактировании файла нужно обеспечить корректировку ветвей АСТ которые располагаются ниже области редактирования. Иначе прийдется каждый раз перепарсивать весь файл.
T>Преобразовать сравнение с образцом в вызов функции уже нельзя.
А оно надо? В прочем, думаю, что ты и тут ошибаешься. Это только в хаскеле функции не могут иметь замканий на изменяемые данные. А в гибридных языках — это нормальная практика. Так что преобразовывать можно. Вопрос только зачем.
VD>>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан.
T>Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов.
Блин, бессмертный .
Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
T>Алгебраические типы данных здесь побоку, например, в теории типов Мартина Лёфа всё строится на зависимых парах. Хочешь — списки, а можно и натуральные числа, если, конечно, нет желания сделать деревья.
Теорий много. Практика одна. И на практике четкого алгоритма ПМ для ОО-объектов (смешно звучит) не придумано. Потому в Скале и F#-е фактически предлагается создавать конверторы в АлгТД и обратно.
VD>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
T>Практически никакого. Контроля. Не будет.
Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
Кстати, в том же Эрланге ПМ тоже не контролируемый (как я понимаю). Но это не мешает его использовать.
T>>>Erlang больше, чем сообщения и процессы. VD>>Откровенно говоря не сильно то он больше если отбросить ПМ. Обычный скриптовый язык нечто вроде помеси лиспа с питоном.
T>Ещё библиотека времени выполнения.
Ну, библиотека есть библиотека. У того же дотната она куда больше и мощнее. Доделают что нужно, если что.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, thesz, Вы писали:
E>>А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов).
T>А что надо делать?
Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал
Здравствуйте, Gaperton, Вы писали:
E>>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
G>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях.
Даже в области серверных приложений с требованиями 24x7 подход Erlang-а далеко не единственный. За десять лет до начала работ для Erlang-ом в лабораториях Ericsson компания Tandem разработала свой набор принципов обеспечения отказоустойчивости. Который и был успешно воплощен в Tandem-ах (ныне HP NonStop). Хотя в чем-то эти подходы совпадают, например, в следованию принципу fail fast.
G>High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно. И она достаточно уныла, чтобы не возникало такого желания.
Существует мнение, что с приходом массовых multicode машин под HPC будут попадать даже такие утилиты, как IrfanView и ACDSee. Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий. Какой толк от Erlang-а во внутренностях IrfanView (с горячей заменой кода, немутабельных данных, сопоставлении с образцом и принципом let it fail) я не представляю. В отличии от использования data-flow механизмов на агентах типа Axum-овских.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
G>>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
V>Тебе же недоступна вся та информация, которой располагает ОС, так? Например, сотни твоих потоков ждут чего-то от ввода-вывода, откуда ты знаешь, кому давать квант?
Я стараюсь устраивать так, чтобы ожидание ввода-вывода проходило в блокировке, о которой знает планировщик. А он в свою очередь, учитывает историю поведения тредов.
V>Разве что все вызовы АПИ оборачивать своими наворотами и плодить лишние примитивы синхронизации.
Если ты хочешь, чтобы у тебя в "легкие потоки" прерывались по вводу-выводу, то тебе было бы неплохо обернуть асинхронный ввод-вывод своим кодом.
Второй вариант — не оборачивать, а положится на избыточную мультитредность, рассчитывая количество потоков в пуле шедулера с учетом того, что они будут стоять в блокировках в синхронном вводе-выводе. В данном случае такой проблемы вообще стоять не будет, как и не будет никаких "лишних примитивов синхронизации", ибо с точки зрения шедулера поток просто займет больше времени (превысит квант), и все. Более правильно и просто делать способом (2). А уметь шедулить смесь задач на разных фактических квантах — не фокус. Уметь, правдо, надо, да, это не совсем в лоб решается.
Здравствуйте, vdimas, Вы писали:
E>>Вот, например, описание агента. Более-менее сложного.
V>Жень, тебе надо компилятор из некоего DSL в целевой С++ делать, а то как-то действительно "более-менее сложно" получается.
Я уже поднимал этот вопрос. И даже пытался представить, что может получиться при использовании Ruby в качестве host-языка для DSL. Вот, как тот же самый "более-менее" агент мог бы выглядеть в DSL.
Но самое удивительное для меня то, что многие заинтересованные в SObjectizer разработчики не хотят иметь внешних DSL. По разным причинам. Но категорически. Поэтому в конце-концов и возникла идея о том, как можно сделать все то же самое средствами C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>DSL тут не принципиален. Будет выглядеть чуть лучше, и только. Его фреймворк вынуждает программиста к разворачиванию всех сценариев взаимодействия агентов в явно записанные конечные автоматы, и в этом корень проблемы. Даже простые сценарии будут выглядеть очень сложно на ровном месте.
Если честно, я фиг его знает, что именно делают в прикладном коде эти агенты и какие конкретно там сценарии, за все сценарии не распишусь. Мне, например, и без агентов иногда код как автомат приходится делать, ибо природа задач бывает такова сама по себе, что разворот на C# через yield лишь усложняет или даже вынуждает использовать goto.
В общем, вот давняя картинка, попробуй здесь без goto:
Легко делается без goto на паттерне state или любой другой эмуляции автомата.
Надо вообще поспрашивать, какие задачи решают на его фреймворке. Как, кстати, обстоят дела с интеропом в Эрланге?
Здравствуйте, Gaperton, Вы писали:
G>С# уверенно движется в "функциональном" направлении, насколько я слышал.
Настолько, насколько это не встречает противодействия Хейлсберга.
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю.
API есть, реализации нету. Не забывай, что речь идет о C# 5, который бог знает когда будет.
G> А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом
Лишний повод перейти на х64. Инфраструктура готова, дело лишь за потребностями.
G>Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
Или технология навроде итераторов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1216 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход.
Насколько сейчас можно судить, Axum даже не маркетинговый ход. Это исследовательский проект в рамках MS. Ребята просто пытаются воплотить модель актеров в своем .NET-овском языке.
Собственно, о том, что это такое, можно ознакомиться в руководстве по Axum и в его спецификации.
А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Кошмар. Как много буков надо написать, и как много надо знать, просто для того, чтобы сообщения получить. Сложную логику за таким кодом будет не разобрать.
E>В статически-типизированных языках с анотацией типов так же приходится писать больше букв, чем в динамически-типизированных языках. Тем не менее, подобная аннотация позволяет разрабатывать большие, многолюдные, длительные проекты с меньшими трудозатратами, чем в случае динамической типизации. Как раз потому, что логику легче отслеживать благодоря лишним буквам.
Я довольно неплохо знаком на практике как со "статически типизированными языками", так и с многолюдными, длительными проектами. И с С++ тоже.
Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.
E>А уж если брать микропримеры, то Hello, World на C++ гораздо многословнее, чем на Ruby. Но на таком сравнении бессмыслено делать заключения о возможностях C++.
Я не говорю о микропримерах. Это в твоей статье кроме них ничего нет.
G>>Можешь пример прикладного кода привести для иллюстрации?
E>Вот, например, описание агента. Более-менее сложного.
Концы. И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.
Здравствуйте, Gaperton, Вы писали:
G>А, кажется я понял. Ты не понимаешь, о чем идет речь, когда я говорю про синхронный и асинхронный стиль, и думаешь, что это имеет какое-то отношение к проблемам синхронизации .
Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.
G>А вот это — соответствующий синхронный код.
G>
G>Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.
Этот сценарий идет лесом в ситуациях, когда во время ожидания результата request_something нужно обработать еще парочку-другую входящих запросов.
G>В твоем случае состояние переползет в явное состояние конечного автомата, и даже простые алгоритмы будут нашинкованы на явные состояния и переходы между ними.
Простые -- да, будут. Сложные, напротив, становятся более читабельными и наглядными.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandjustas, Вы писали:
E>>Мне кажется, что тотальная асинхронность все-таки лучше тотальной синхронности.
G>Лучше всего чтобы синхронность\асинхронность выражалась декларативно, а код был одинаковым в обоих случаях.
Ага, и все это на .NET-е
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
G>>>>Позаменяет синхронные вызовы, на аналогичные им асинхронные и треды блокироваться не будут. Кроме того с помощью констркции interleave можно несколько асинхронных возовов параллельно запустить при этом не париться с синхронизацией.
G>>>>Именно для таких выкрутасов и нужен язык, а не просто библиотека.
G>>>А вот тут рядом eao197 фьючерсы весьма по делу помянул. Чем это лучше работы с фьючерсами? G>>Декларативностью.
G>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
G>Если я в длинной функции объявил фьючерс, то я сообщаю читателю, что вот эта переменная, обращение с которой выглядит вполне гражданским образом, на самом деле скрывает под собой асинхронные вычисления. А остальные — нет. Человек видит такие места в коде.
G>Если я в начале длинной функции ставлю asynchronous, читатель должен ментальным сканированием догадываться о его поведении?
asynchronous не создает неявно отложенных вычислений (именно они вроде как фьючерами называются). Все что делает asynchronous — заменяет все блокирующие вывозы на асинхронные, которые не блокируют физический поток. В принципе такое поведение должно быть по-умолчанию в агентно-ориентированной среде (без явного управления потоками), а декларативно должно отменяться.
Здравствуйте, thesz, Вы писали:
T>>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества. G>>Ну давай посмотрим. В чем Erlang настолько больше?
T>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.
T>Горячая замена кода.
T>Let it fail.
T>Пожалуй, достаточно.
Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
G>>>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния. T>>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек. G>С чего бы? Только потому что pattern-matching нету?
Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля. В нём не будет разделения типов выражений с эффектом и без.
Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом.
T>>Строгая типизация страдает. G>Чем страдает?
Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе).
Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка.
G>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? T>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться. G>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.
Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом.
G>>>Ну давай посмотрим. В чем Erlang настолько больше? T>>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности. G>Неизменяемые данные есть и в Axum, там это называется схемами. Только схемы там сериализуемые должны быть, поэтому ФВП непердавать нельзя. G>Хотя не знаю насколько необходимо передавать ФВП, там ведь полностью поддерживается ООП.
Ты, вообще, HOF пользовался?
Оно понятно, что closures (HOF) are poor man objects, но они настолько удобней, что просто ах!
T>>Горячая замена кода. G>Горячая замена кода есть и в .NET, только больше приседаний для нее надо.
И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.
T>>>>(обнаружил себя в непривычной ситуации защиты Эрланга) G>>>(а я вроде как и не против Erlang был) T>>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду. G>Улыбнуло. Разве кто-то говорит что надо срочно бросить все и писать на axum?
Да вообще о нём забыть надо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Nope. В C# 3.0 ты можешь создать лямбду с побочным эффектом.
Ну и что? Лямбду без побочного эффекта на C# создать можно, а уж что там можно еще — дело десятое. Это называется — мультипарадигменный.
T>Тему про "достаточность функциональности" не я поднял.
А кто?
T> Мне, главное опровергнуть, чтобы она не послужила аргументом в споре.
Это не причина.
T>Мне достаточно, что ты это принял.
Я? Зачем?
T>>>Я считаю, что Axum — это PR .Net. AVK>>С верой спорить бесполезно.
T>Я здесь пытаюсь показать минимальность нового в Axum
Не, это исключительно твоя вера, потому что никаких фактов в поддержку этого ты не приводишь.
T>, из чего следует, что это PR
Из того что ты пытаешься следует? Отличная логика. И прекрасная демонстрация того, что это все таки вера.
T>. В ответ со мной соглашаются, но продолжают утверждать, что это хорошая штука.
Я с тобой никогда в этом не соглашался. Просто потому что у меня несколько больше информации о причинах внутренних течений в МС.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть. G>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Мимо. Задача не в том, чтобы нагрузить все ресурсы, а в том, чтобы получить максимальный эффект от распараллеливания (в идеале -- линейную масштабируемость). И здесь высокоуровневые механизмы (те же самые агенты) могут позволить разработчику достичь этой цели с меньшими трудозатратами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть. G>>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
E>Мимо. Задача не в том, чтобы нагрузить все ресурсы, а в том, чтобы получить максимальный эффект от распараллеливания (в идеале -- линейную масштабируемость). И здесь высокоуровневые механизмы (те же самые агенты) могут позволить разработчику достичь этой цели с меньшими трудозатратами.
Забыл добавить -- remark здесь несколько мегапостов написал на эту тему. Так что обращайстесь к первоисточнику
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>>>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях.
E>>Даже в области серверных приложений с требованиями 24x7 подход Erlang-а далеко не единственный.
G>Единственных подходов вообще не бывает. Их всегда пруд пруди. Я тебе сейчас не о подходе говорю, а о тех преимуществах, которые есть не подход, а свойства, и которые ты попытался отмести предыдущим постом.
Ты говоришь о любых серверных приложениях. Но пример Tandem-ов как раз показывает, что не для любых.
E>>Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий. Какой толк от Erlang-а во внутренностях IrfanView (с горячей заменой кода, немутабельных данных, сопоставлении с образцом и принципом let it fail) я не представляю. В отличии от использования data-flow механизмов на агентах типа Axum-овских.
G>Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.
Здесь есть два вопроса: "можно ли?" и "нужно ли?". И прежде чем обсуждать вопрос возможности переноса свойств Erlang-а в другие языки, имеет смысл дать ответ на вопрос "нужно ли?" Так вот, для многих предметных областей не требуется ни возможностей дробления задачи на сотни тысяч изолированных мелких процессов, ни горячая замена кода, ни даже обеспечение приципа let it fail. Поэтому в этом случае вообще бессмыслено обсуждать вопросы возможности переноса свойств Erlang-а куда-нибудь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Почему это? AVK>Потому что моя личность к теме топика не имеет никакого отношения, и переход на личности это грубый демагогический прием.
Упоминание об ангажированности не переход на личности. Ангажированность не свойство личности, это свойство позиции, занимаемой личностью.
T>> Ангажированность не свойство личности. Это может быть следствием заблуждений. AVK>Здесь не обсуждаются мои заблуждения.
Оба-на!
Да на всём RSDN только и делают, что обсуждают чьи-то заблуждения.
Здесь попались твои. Вот мы их и обсуждаем. В частности, заблуждения насчёт обсуждения заблуждений.
T>>>>Кстати, а ты знаешь, что творится-то в Parallel Haskell? AVK>>>Нет, это мне на данный момент не очень интересно. T>>Однако имеешь уверенность что-то утверждать насчёт "100 рублей". AVK>Потому что у меня есть кое какая информация, которой я здесь поделиться, к сожалению, не могу, NDA.
Ну, так и не делись. Лучше всего вообще.
А то только домыслы и слухи порождаешь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность? T>"Прозрачно" — это как?
Некоторые лёгкие процессы магически превращаются в реальные процессы, работающие на своём ядре.
Здравствуйте, thesz, Вы писали:
T>>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении. G>>И что? У лиспа пиписька длиннее стала? T>Он стал удобней в работе.
Чем?
T>>>Вопрос: какой порядок упрощения в функциональном подмножестве C#? G>>Встречный вопрос: что это меняет? T>Простоту рассуждений о программах.
Зачем рассуждать о программах?
T>>>>В нём не будет разделения типов выражений с эффектом и без. G>>>И зачем оно надо? T>>Для того, чтобы "иметь возможность писать императивный код там где надо и иметь возможность декларативно ограничивать запуск такого кода". G>Хм... я бы предпочел что-то типа модификатора pure на функции. (как const в C++)
Вопрос умолчаний.
С выводом типов это вообще не вопрос.
T>>На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#? G>generics?
Попробуй. Если я ещё и доказательства прикручу в виде типов классов, то никакие generics не спасут.
T>>Это же палка о двух концах. G>Не факт, в компиляторе можно много чего ограничить для получения адекватного результата, в отличие от DSEL.
Вопрос простоты. Большое количество проверок можно получить без компилятора, если система типов достаточно мощна.
G>Ведь хаскель тоже работат на вдоску имепративном CPU с состоянием.
А всё написано на ассемблере, да-да.
T>>>>>>Горячая замена кода. G>>>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо. T>>>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии. G>>>И что это меняет?
T>>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. G>"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET.
Она такая по построению.
G>По твоей логике можно haskell везде запихнуть, только я софта на хаскеле не видел вообще.
Во, куда скатились. Круто! А про императивный CPU так вообще отпад.
Это аргумент середины 70-х про языки высокого уровня.
T>>>>Да вообще о нём забыть надо. G>>>А то вдруг .NET задавит erlang и haskell. T>>Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы. G>Это же хорошо, люди деньги зарабатывают
Головой больше думать. Не делать ненужной работы. Не выбирать платформы и языки, где нужна ненужная работа.
T>>Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением. G>Странно. Как раз среда типа .NET, которая предлагает совершенно разные подходы к разработке, выраженные в разных языках и фреймворках, дает гораздо больше возможностей для развития, чем другие среды. Причем нету необходимости изучать что-то вне конкретного языка или платформы, так как база общая.
1) Очень низка скорость внесения этого чего-то нового.
2) Чего-то новое обычно оказывается C#, вид в профиль. Даже старое им оказывается.
G>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.
Уверяю тебя, ты всё равно ничего не знаешь про ФП, про скриптовые языки и про параллельное программирование.
Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке.
У тебя этого под рукой нет.
Ты не писал большой проект на скриптовом языке.
Ты знаешь о параллельном программировании только то, что в MS сочли нужным тебе показать.
Все эти знания приходится в тебя проталкивать, как вот в этом топике, и в других.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, AndrewVK, Вы писали:
IT>>Это выкривление одной кривизны с помощью другой. Короче говоря извратство.
AVK>Ну, не такое уж и извратство, хотя синтаксически несколько избыточно. Применять вполне можно.
"Не такое уж и извратство" и "Применять вполне можно" может характеризовать какую-нибудь второстепенную фичу какой-нибудь малоиспользуемой библиотеки, но никак не одну из основных конструкций языка.
Если нам не помогут, то мы тоже никого не пощадим.
, значит он функциональный. И все, ни о каких побочных эффектах речи не было.
Точнее, я писал, что считаю функциональным язык, в котором функции — FCO.
Просто, так уж получается, что идеи приходя в мэйнстрим деформируются и принимают странную форму, которая тех, кто был знаком с ними до этого, естественно, не устраивает.
Я полагаю, что C# 3.0 в такой же степени функциональный язык, в какой C++ — объектно ориентированный, хотя у православных хаскелиста (в первом случае) и у смолтокера (во втором) всегда найдется что возразить.
Но, если уж на то пошло, в Haskell можно обходить ограничение и создавать сайд-эффект в функциях с самым чистым, невинным типом. Просто это требуется из практических соображений.
Такое возможно, потому, что есть
unsafePerformIO :: IO a -> a
так что без доброго слова авторов и тут не обходится.
Другое дело, что контроль за побочными эффектами в Haskell все-таки лучше чем в C#, в котором его нет вовсе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'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
Здравствуйте, thesz, Вы писали:
T>>>MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах. E>>Тогда, надо полагать, PVM еще лучше MPI, поскольку существует еще дольше. А Java лучше .NET. А Oberon лучше Java...
T>Агенты ничем от MPI не отличаются, за исключением отсутствия стандарта.
Тогда на основании чего было сделано утверждение, что
Использовать агенты в HPC — немного совсем малоэффективное решение.
?
E>>И ни слова об автоматическом распараллеливании MPI. Что и не удивительно, т.к. автоматическое распараллеливание и MPI -- это, имхо, взаимоисключающие подходы.
T>"Let me see..." (C) The Incredibles T>
Therefore, we refer to our scheme as partial-replication. Data replication comes at the cost of limiting the data scalability of programs that is, programs will not be able to handle n-times larger data sets on n processors.
А ведь MPI как раз и рулит в области больших вычислений на сотнях и более узлов.
T> а для OpenMP автоматическое распараллеливание существует.
OpenMP изначально предназначалась для того, чтобы компилятор/runtime распараллеливал те куски, на которые указал программист. Но распараллеливал автоматически. Однако, речь сейчас не об OpenMP.
T>В принципе, товарищи из Майкрософт пытаются облегчить перенос последовательных программ на параллельные системы, это видно по приводимым здесь примерам кода.
T>С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот.
Ну конечно, пусть MS потратит еще десяток-другой лет на поиск хороших решений для автоматического распараллеливания кода. У них же денег много. А еще пусть Haskell вместо C# продвигает, ведь это более прогрессивный подход
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
E>>Но вот насколько эти проверки полные -- это вопрос.
FR>Если нужна совершенно чистая функциональщина, то в D это тоже есть в виде FR>Compile Time Function Execution
FR>http://www.digitalmars.com/d/2.0/function.html#interpretation
Да я как бы в курсе
Про полноту проверок я сказал потому, что где-то встречал описания ошибок в DMD, связанных с определением чистоты. Понятно, что это баги и их количество должно уменьшаться со временем. Но пока DMD не стабилизировался есть шанс, что компилятор воспримет как чистую функцию, которая таковой не является.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
К>Не знаю, но вот "фреймворк вынуждает программиста к разворачиванию всех сценариев взаимодействия агентов в явно записанные конечные автоматы" и то, что автоматы — всегда зло, по-моему 2 очень разных утверждения, или я не прав?
Частично. Ведь если мы взяли такой фреймворк, значит задача соответвующая (хочется так думать). А иначе надо брать другой. И вообще, никто не запрещает в одном продукте объединять фреймворки и подходы, гдавное — чтобы удачно соответствовало конкретной задаче, остальное — разговоры в пользу бедных.
Здравствуйте, AndrewVK, Вы писали: AVK>В контексте этого топика важна именно возможность, а не отсутствие поддержки других стилей.
Ну, будем честными — так не стоит переопределять оператор is.
Вспомни C++ и голые указатели — мы же из своего управляемого мира хихикаем над их заявлениями про то, что "важна именно возможность xxx_ptr<T>, а не отсутствие поддержки void*".
Имхо, тут есть как бы три уровня "поддержки возможности":
0. Теоретически возможно, но ценой чрезмерного геморроя, поэтому никто не делает (если у вас себестоимость нефти $80 за баррель, то лучше добывать что-нибудь другое)
1. Возможно, достаточно нетрудно добиться и применять, но нельзя заставить пользоваться только этим.
2. Можно отключить "отсутствие поддержки" возможности и получить строгие доказательства полезных свойств программы.
Шарп по отношению к ФП медленно, но верно дрейфует от 0 к 1. При этом для хардкорных функциональщиков стакан всё еще "наполовину пуст", и посему интереса не представляет. Они хотят такую поддержку, на которую можно было бы положиться. (а не как const в С++, который "если нельзя, но очень хочется, то можно").
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
IT>>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression. S>Ну, if-expression, к счастью, есть.
К счастью есть, к несчастью сильно кастрированный.
Если нам не помогут, то мы тоже никого не пощадим.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
Здравствуйте, AndrewVK, Вы писали:
G>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
Ну что ж, тем лучше для него. Приятнее [мне] было бы, правда, если бы оно влилось в F#.
G>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
Думаю, что тогда он Эрлангу не конкурент.
Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>>Очень мало информации. Вообще, выглядит очень интересно — похоже, эта штука прямой "конкурент" Эрлангу. Но все будет зависеть от деталей модели программирования, которую они выберут, и от практических свойств рантайма. F# получился весьма симпатичным. Отличный и очень практичный язык. Посмотрим, как выйдет на этот раз.
AVK>>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком.
T>Думаю, что тогда он Эрлангу не конкурент.
T>Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное.
С# уверенно движется в "функциональном" направлении, насколько я слышал.
Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю. А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом и обязано быть непрерывным. Так, что несколько тысяч файберов быстро сожрут адресное пространство. Известная проблема нативных "зеленых потоков".
Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
Здравствуйте, Gaperton, Вы писали:
G>Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое.
такое кол-во легких потоков нужно в эрланге т.к. там нет объектов, а в axure actor это скорее gen_server только пока(может сделают) без горячей замены и прочей радостей OTP.
Я бы тоже предпочел это увидеть в F#, а не в отдельном DSL, тем более F# пока CTP, и можно вводить новые фишки не оглядываясь назад.
AVK>>>Это MSR и результаты скорее вольются в C# 5, чем будут отдельным языком. T>>Думаю, что тогда он Эрлангу не конкурент. T>>Если разворачивать, то 1) сравнения с образцом не будет, 2) громоздкий синтаксис, 3) внутри будет ООП, а не что-нибудь функциональное. G>С# уверенно движется в "функциональном" направлении, насколько я слышал.
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю.
Да, забыл про потоки.
Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход. Тот самый fire, чтобы у других не было motion.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Проблема еще и в том, что легкие потоки с автоматическим вытеснением невозможны в рамках CLR, насколько я понимаю. А если их делать на основе файберов, то их на 32-х битной архитектуре много не создашь, ибо адресное пространство под стек резервируется с запасом и обязано быть непрерывным. Так, что несколько тысяч файберов быстро сожрут адресное пространство. Известная проблема нативных "зеленых потоков".
Либа CCR реализует подобие легких потоков через итераторы. Только многословно сильно получается.
Axum делает практически тоже самое, создает из линейного кода State Machine с состоянием в хипе.
T>>Тогда можно смело думать, что этот Axum не более, чем маркетинговый ход. AVK>Да при чем тут маркетинг? Это MSR, это просто исследования, что можно сделать.
Всё, что попадает во вне MSR через PR, становится маркетингом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Короче, чтоб все было приятно в плане количества потоков (сотня тысяч — штатная ситуация) — нужно либо 64 бита, либо серьезная модификация рантайма. А лучше и то и другое. C>такое кол-во легких потоков нужно в эрланге т.к. там нет объектов, а в axure actor это скорее gen_server только пока(может сделают) без горячей замены и прочей радостей OTP.
Такое количество легких потоков избавляет от необходимости их считать, и вообще думать о них как о чем-то особенном. Это хорошо и удобно вообще, вне контекста наличия или отсутствия объектов.
E>>>А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов). T>>А что надо делать? E>Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал
Я понял смысл твоего послания. (Глупость ты там написал, надо сказать.)
Опережение Axum-ом Эрланга будет только за счёт библиотек .Net. Предвижу, однако, сплошные нарушения инвариантов в их использовании в этом случае, поскольку они не изолированы рамками процессов.
Языкового опережения не получится.
Поэтому лично я, пожалуй, к Axum возвращаться не буду.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
E>>Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал
E>>>Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал
, касательно C++.
T>>Я понял смысл твоего послания. (Глупость ты там написал, надо сказать.)
E>Я там много чего написал. И что, все написанное глупость?
Большая часть.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
E>>>>А для того, чтобы конкурировать с Erlang-ом, не обязательно тупо копировать решения Erlang-а (поддержку сотен тысяч независимых процессов). T>>>А что надо делать? E>>Да практически так же, как и поступают разработчики Axum и не только его (можно, наверное, с десяток агентных фреймворков насчитать, в основном для JVM, но есть и для Python, Ruby, C++): оформлять агентов в виде объектов. Подробнее я на эту тему уже писал
, касательно C++.
T>Я понял смысл твоего послания. (Глупость ты там написал, надо сказать.)
T>Опережение Axum-ом Эрланга будет только за счёт библиотек .Net. Предвижу, однако, сплошные нарушения инвариантов в их использовании в этом случае, поскольку они не изолированы рамками процессов.
T>Языкового опережения не получится.
T>Поэтому лично я, пожалуй, к Axum возвращаться не буду.
T>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции.
Здравствуйте, thesz, Вы писали:
T>>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции.
T>http://en.wikipedia.org/wiki/Superposition
T>Ты играешься словами, не понимая их значения.
Здравствуйте, gandjustas, Вы писали:
T>>>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>>>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции.
T>>http://en.wikipedia.org/wiki/Superposition
T>>Ты играешься словами, не понимая их значения.
G>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
Странно, вроде как матан в универе два года преподается . То, что потом — как бы вроде не матан .
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
T>>>>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>>>>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции.
T>>>http://en.wikipedia.org/wiki/Superposition
T>>>Ты играешься словами, не понимая их значения.
G>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
G>Странно, вроде как матан в универе два года преподается . То, что потом — как бы вроде не матан .
T>>>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>>>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции. T>>http://en.wikipedia.org/wiki/Superposition T>>Ты играешься словами, не понимая их значения. G>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
Ух ты!
В чем отличие от Википедии?
T>>Это не тот пример, на который стоит обращать внимание. T>>Это всего лишь асинхронность, её даже на плюсах можно сделать. T>>Важно же само программирование — реакция со сложной логикой на разные события. T>>Это упустил из виду eao, это не рассматривают товарищи из Axum. G>А пример можно?
Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом).
Erlang больше, чем сообщения и процессы.
Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>Поэтому лично я, пожалуй, к Axum возвращаться не буду. G>>>>Не надо так скептически. В Axum уже есть супер-мега фича — dataflows, навороченный вариант функциональной суперпозиции. T>>>http://en.wikipedia.org/wiki/Superposition T>>>Ты играешься словами, не понимая их значения. G>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе.
T>Ух ты! T>В чем отличие от Википедии?
Во всем, по той ссылке что ты привел нету ничего похожего.
T>>>Это не тот пример, на который стоит обращать внимание. T>>>Это всего лишь асинхронность, её даже на плюсах можно сделать. T>>>Важно же само программирование — реакция со сложной логикой на разные события. T>>>Это упустил из виду eao, это не рассматривают товарищи из Axum. G>>А пример можно?
T>Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом). T>Erlang больше, чем сообщения и процессы. T>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.
Мда.. видно непонимание сути исследвательского проекта.
Здравствуйте, eao197, Вы писали:
T>>Важно же само программирование — реакция со сложной логикой на разные события.
E>Все это вполне решаемо даже в C++.
Кошмар. Как много буков надо написать, и как много надо знать, просто для того, чтобы сообщения получить. Сложную логику за таким кодом будет не разобрать.
Вопрос — ты когда эти ферймворки выдумываешь, какой-нибудь полезный код на них пробуешь писать? Можешь пример прикладного кода привести для иллюстрации?
G>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе. T>>Ух ты! T>>В чем отличие от Википедии? G>Во всем, по той ссылке что ты привел нету ничего похожего.
Ну, так выскажи своё понимание.
А то получается, что ты обладаешь неким секретным знанием, которое позволяет тебе видеть положительное в этих самых dataflows.
T>>>>Это не тот пример, на который стоит обращать внимание. T>>>>Это всего лишь асинхронность, её даже на плюсах можно сделать. T>>>>Важно же само программирование — реакция со сложной логикой на разные события. T>>>>Это упустил из виду eao, это не рассматривают товарищи из Axum. G>>>А пример можно? T>>Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом). T>>Erlang больше, чем сообщения и процессы. T>>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.
G>Мда.. видно непонимание сути исследвательского проекта.
Не спорю.
Так объясни непонимающему.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе. T>>>Ух ты! T>>>В чем отличие от Википедии? G>>Во всем, по той ссылке что ты привел нету ничего похожего. T>Ну, так выскажи своё понимание. http://ru.wikipedia.org/wiki/Композиция_функций
T>>>>>Это не тот пример, на который стоит обращать внимание. T>>>>>Это всего лишь асинхронность, её даже на плюсах можно сделать. T>>>>>Важно же само программирование — реакция со сложной логикой на разные события. T>>>>>Это упустил из виду eao, это не рассматривают товарищи из Axum. G>>>>А пример можно? T>>>Да сравнение с образцом. Да функции высших порядков. Да неизменяемые данные (что и есть основа для сравнения с образцом). T>>>Erlang больше, чем сообщения и процессы. T>>>Товарищи из Axum всё держатся за конец двадцатого века и никак не могут его отпустить.
G>>Мда.. видно непонимание сути исследвательского проекта.
T>Не спорю. T>Так объясни непонимающему.
Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#.
Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.
Здравствуйте, Gaperton, Вы писали:
G>Кошмар. Как много буков надо написать, и как много надо знать, просто для того, чтобы сообщения получить. Сложную логику за таким кодом будет не разобрать.
В статически-типизированных языках с анотацией типов так же приходится писать больше букв, чем в динамически-типизированных языках. Тем не менее, подобная аннотация позволяет разрабатывать большие, многолюдные, длительные проекты с меньшими трудозатратами, чем в случае динамической типизации. Как раз потому, что логику легче отслеживать благодоря лишним буквам.
А уж если брать микропримеры, то Hello, World на C++ гораздо многословнее, чем на Ruby. Но на таком сравнении бессмыслено делать заключения о возможностях C++.
G>Вопрос — ты когда эти ферймворки выдумываешь, какой-нибудь полезный код на них пробуешь писать?
Да.
G>Можешь пример прикладного кода привести для иллюстрации?
Здравствуйте, Gaperton, Вы писали:
G>Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.
Нравится, не нравится -- это все субъективные критерии. Мне, например, код на Erlang-е и ScalaActors не нравится. Поскольку, имхо, там очень важные вещи размазанны по коду. Тем не менее, кому-то именно такой стиль нравится больше.
Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.
G>И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.
Да, в этом и была цель в то время. Очень простое решение. Как в реализации, так и в освоении.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Твой код мне не нравится. Это далеко не лучший на мой взгляд подход к проблеме в случае С++. Слишком сложно, и на практике будет неудобно. Синхронный код гораздо компактнее и понятнее, чем асинхронный, разница примерно в два раза как по времени написания и отладки, так и по объему этого кода. И он, разумеется, читабельнее.
E>Нравится, не нравится -- это все субъективные критерии. Мне, например, код на Erlang-е и ScalaActors не нравится. Поскольку, имхо, там очень важные вещи размазанны по коду. Тем не менее, кому-то именно такой стиль нравится больше.
Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.
E>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.
Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и писать синхронно. А вот подход Эрланга позволяет обрабатывать сотни тысяч нитей простого синхронного кода. И все так же без каких-либо проблем синхронизации — это вообще свойство модели коммуникации параллельных процессов.
G>>И в результате, чтобы все более-менее прилично выглядело, тебе пришлось задействовать макросы. Здравствуй, старый добрый MFC-style.
E>Да, в этом и была цель в то время. Очень простое решение. Как в реализации, так и в освоении.
Ну, раз именно такой и была цель, то ты ее вне всяких сомнений достиг. Тока MFC-style сам по себе не лучшее решение. Он не полагается на возможности С++ "правильным" образом.
Здравствуйте, Gaperton, Вы писали:
G>Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и [позволяет] писать синхронно.
Здравствуйте, Gaperton, Вы писали:
G>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.
Это слова.
E>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.
G>Сотни нитей — это мощно . А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации, и писать в разы меньше кода, ибо он не вынуждает людей разворачивать код в явные автоматы, и писать синхронно. А вот подход Эрланга позволяет обрабатывать сотни тысяч нитей простого синхронного кода. И все так же без каких-либо проблем синхронизации — это вообще свойство модели коммуникации параллельных процессов.
Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.
E>Это слова.
Это у тебя — слова.
E>>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.
E>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?
О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?
Здравствуйте, Gaperton, Вы писали:
G>>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.
E>>Это слова.
G>Это у тебя — слова.
Ну конечно.
E>>>>Что до синхронности, то наш подход позволяет легко создавать приложения с сотнями нитей без намека на проблемы синхронизации где бы то ни было.
E>>Сейчас о чем речь идет? О том, что подход Erlang-а -- единственно верный? Или что право на существование имеет только твой самописный диспетчер файберов из CQG?
G>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?
То, что он тебе не нравится, это уже понятно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
G>>>>>Мои знания подобных вещей почерпнуты не из википедии, а из трех лет матана в универе. T>>>>Ух ты! T>>>>В чем отличие от Википедии? G>>>Во всем, по той ссылке что ты привел нету ничего похожего. T>>Ну, так выскажи своё понимание. G>http://ru.wikipedia.org/wiki/Композиция_функций
Я так и думал.
T>>Не спорю. T>>Так объясни непонимающему. G>Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#. G>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.
И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?
Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения.
А все подхватили.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
G>>>>Конечно. А вот то, что стиль с явными конечными автоматами, как у тебя, раздувает код минимум вдвое по сравнению с синхронным, и увеличивает трудозатраты как на разработку, так и на поддержку — это уже объективные критерии. Я замерял. Когда я говорю "не нравится" — я имею в виду именно это. Плохой это стиль.
E>>>Это слова.
G>>Это у тебя — слова.
E>Ну конечно.
Конечно.
G>>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?
E>То, что он тебе не нравится, это уже понятно.
Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.
Здравствуйте, Gaperton, Вы писали:
E>>>>Это слова.
G>>>Это у тебя — слова.
E>>Ну конечно.
G>Конечно.
Ну вот и состоялся обстоятельный обмен неоспоримыми доказательствами.
G>>>О том что твой подход плохой. Я донес эту мысль недостаточно ясно, это требует пояснений?
E>>То, что он тебе не нравится, это уже понятно.
G>Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.
Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>>>Это слова.
G>>>>Это у тебя — слова.
E>>>Ну конечно.
G>>Конечно.
E>Ну вот и состоялся обстоятельный обмен неоспоримыми доказательствами.
Ты ожидал чего-то другого на фразу "это слова"?
G>>Отлично. Это уже кое-что. Ну, если тебе что-то еще непонятно — например, "почему" — так ты спроси. Я объясню.
E>Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.
Здравствуйте, Gaperton, Вы писали:
E>>Ну вот и состоялся обстоятельный обмен неоспоримыми доказательствами.
G>Ты ожидал чего-то другого на фразу "это слова"?
В общем, да. Поскольку ты говорил, что замерял затраты на асинхронный и синхронный подходы, то было бы интересно взглянуть на результаты замеров.
Поскольку в своих задачах я просто видел возможность их решения с помощью асинхронных агентов (с приемлимыми трудозатратами и качеством). Но не видел такой возможности с синхронными подходами. А возможности тратить месяц на получение и внедрение одного решения, а затем еще месяц на разработку альтернативы с целью сравнения разных подходов -- такой роскоши не бывает.
E>>Спасибо, я и сам понимаю его достоинства и недостатки. Тем не менее, я не разделяю твоей уверенности в том, что есть какой-то единственный правильный подход к реализации агентов.
G>Я, вообще-то, этого не говорил.
Ну, поскольку мой подход ты называешь плохим, значит, по твоему мнению есть хотя бы один более хороший. С этим я не согласен. Плохость в одних задачах оборачивается хорошестью в других, и наоборот.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>А, кажется я понял. Ты не понимаешь, о чем идет речь, когда я говорю про синхронный и асинхронный стиль, и думаешь, что это имеет какое-то отношение к проблемам синхронизации .
E>Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.
Ну, это же thesz сказал. Пусть он за это и отдувается, так? Я конечно понимаю, что у нас на RSDN споры традиционно командные, и кровавое мочилово обычно идет стенка на стенку, но вроде бы, оно еще не началось, нет?
G>>А вот это — соответствующий синхронный код.
G>>
G>>Разница в том, что в синхронном RPC-style коде выполнение может прерываться, и контекст выполнения — переключаться. Неважно как — будь то тред, файбер, или continuation. Состояние в этом случае я могу хранить на стеке в локальных переменных, и алгоритм будет читабельным.
E>Этот сценарий идет лесом в ситуациях, когда во время ожидания результата request_something нужно обработать еще парочку-другую входящих запросов.
Да, это простейший сценарий, но именно он наиболее распространен в случае "протокольных" задач, например. Однако, давай действительно его оставим, и рассмотрим твой.
Когда возникает такая необходимость, у тебя есть два варианта.
1) Разбить одного агента на два (подставь нужное число), где все приведется к синхронному случаю.
2) Использовать стиль "wait_for_multiple_ojects". То есть, ты блокируешься в одном вызове, ожидая любого из перечисленных событий.
В предельном случае (2) разумеется сведется к явному конечному автомату. Однако, он все равно будет гораздо проще, потому, что простые случаи ты обработаешь синхронно. Плюс ко всему, даже в этом случае у тебя во многих ситуациях сохранится возможность записывать автомат неявно, с "состоянием" в локальных переменных.
G>>В твоем случае состояние переползет в явное состояние конечного автомата, и даже простые алгоритмы будут нашинкованы на явные состояния и переходы между ними.
E>Простые -- да, будут. Сложные, напротив, становятся более читабельными и наглядными.
Понимаешь, в чем дело. Во-первых, не хочется, чтобы простые случаи затуманивали на ровном месте код, вызывая у читателя шок и трепет. Раз они простые — почему бы им и не выглядеть просто.
А для сложного случая — что мне мешает сделать по месту и необходимости message loop и использовать твой стиль (кстати, во многих случаях я этого смогу избежать, расщепив агента на несколько)? Получается, что я могу комбинировать оба подхода, а ты привязан к одному из них. Хорошо ли это?
Здравствуйте, thesz, Вы писали:
T>>>Не спорю. T>>>Так объясни непонимающему. G>>Так уже объясняли. Цель у них не создать язык — конкурент Erlang или чего-то такого, а создать модель агентов на базе .NET и все, ничего больше не надо. Может быть по результатам резултаты исследований создадут новый язык, а может включат соовествующие средства в C# или F#. G>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows.
T>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке?
Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.
T>Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения.
Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
T>А все подхватили.
Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда.
Здравствуйте, Gaperton, Вы писали:
E>>Проблемы синхронизации здесь были упомянуты из-за того, что thesz выше по ветке упрекнул Axum в том, что в отсутствии изоляции процессов (как в Эрланг) будет происходить массовое нарушение инвариантов в объектах.
G>Ну, это же thesz сказал. Пусть он за это и отдувается, так?
Хорошо.
G>Когда возникает такая необходимость, у тебя есть два варианта. G>1) Разбить одного агента на два (подставь нужное число), где все приведется к синхронному случаю.
Это черевато ситуациями, где несколько агентов должны разделять один блок общих данных. Здесь всплывает проблема организации синхронизации доступа к этим данным.
G>2) Использовать стиль "wait_for_multiple_ojects". То есть, ты блокируешься в одном вызове, ожидая любого из перечисленных событий.
У меня этот стиль выбран в качестве основного. Только в нем сам фреймворк выполняет ожидание и диспетчеризацию полученных сообщений с учетом текущего состояния агента (под состоянием понимается не содержимое его атрибутов и локальных переменных).
G>Понимаешь, в чем дело. Во-первых, не хочется, чтобы простые случаи затуманивали на ровном месте код, вызывая у читателя шок и трепет. Раз они простые — почему бы им и не выглядеть просто.
Да, это было бы здорово -- для простых случаев простые подходы к решению, для сложных -- сложные. Но, если решать приходится сложные задачи, то и фреймворк затачивается под них. А читателю предлагается запастись терпением на начальной стадии обучения.
G>А для сложного случая — что мне мешает сделать по месту и необходимости message loop и использовать твой стиль (кстати, во многих случаях я этого смогу избежать, расщепив агента на несколько)?
Одной из целей было освобождение разработчика от необходимости взаимодействия с message loop вообще. И, как следствие, от избавления от спагети-кода, в который, как правило, превращается при сопровождении работа с message loop.
G>Получается, что я могу комбинировать оба подхода, а ты привязан к одному из них. Хорошо ли это?
Мне кажется, что тотальная асинхронность все-таки лучше тотальной синхронности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
E>>>Мне кажется, что тотальная асинхронность все-таки лучше тотальной синхронности.
G>>Лучше всего чтобы синхронность\асинхронность выражалась декларативно, а код был одинаковым в обоих случаях.
E>Ага, и все это на .NET-е
Угу, Axum так умеет.
Синхронное и асинхронное копирование данных из одного стрима в другой на Axum
Здравствуйте, Gaperton, Вы писали:
G>Короче. Код по понятной причине показать не могу. Но могу описать ситуацию. Дело было так.
Все это интересно, но ты судишь на основании, я бы сказал, достаточно частного опыта.
Кстати, судя по описанию задачи, я бы не рекомендовал сходу использовать для P&F мой подход, т.к. он гораздо лучше подходит для "тяжелых" сообщений-заданий или уведомлений. Преобразовывать последовательности временных рядов в сообщения sobjectizer-агентов невыгодно. В том числе и из-за слишком большого "синтаксического оверхеда" в коде sobjectizer-агентов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Когда возникает такая необходимость, у тебя есть два варианта. G>>1) Разбить одного агента на два (подставь нужное число), где все приведется к синхронному случаю.
E>Это черевато ситуациями, где несколько агентов должны разделять один блок общих данных. Здесь всплывает проблема организации синхронизации доступа к этим данным.
Есть такое дело. Это, в свою очередь, можно решить:
1) Явными синхронизациями на разделяемой памяти. Что, конечно, плохо, ибо непонятно, за что боролись, не так ли? Или же... удивительно, что есть какое-то "или", правда? А таки да, есть!
2) Апартментами. Апартментами, уважаемые коллеги! На чем и остановимся.
Короче, в COM есть прикольнейшая вешь, под названием single-threaded appartment. Это, вероятно, лучшая идея, которая есть в COM. И мы ее поюзаем, в несколько видоизмененном виде.
Агенты у тебя живут не абы где, а в "апартментах". Один апартмент — один тред. Один тред — много агентов, и, соответственно, много файберов, континуэйшнов, или на чем там они в данном случае построены. Один тред — и нет никаких проблем синхронизации при доступе к разделяемым ресурсам внутри апартмента.
Когда ты расщепляешь для простоты агента на несколько — они живут в одном апартменте. И все.
G>>2) Использовать стиль "wait_for_multiple_ojects". То есть, ты блокируешься в одном вызове, ожидая любого из перечисленных событий.
E>У меня этот стиль выбран в качестве основного. Только в нем сам фреймворк выполняет ожидание и диспетчеризацию полученных сообщений с учетом текущего состояния агента (под состоянием понимается не содержимое его атрибутов и локальных переменных).
Я это понял.
G>>Понимаешь, в чем дело. Во-первых, не хочется, чтобы простые случаи затуманивали на ровном месте код, вызывая у читателя шок и трепет. Раз они простые — почему бы им и не выглядеть просто.
E>Да, это было бы здорово -- для простых случаев простые подходы к решению, для сложных -- сложные. Но, если решать приходится сложные задачи, то и фреймворк затачивается под них. А читателю предлагается запастись терпением на начальной стадии обучения.
Дык дело в том, что в сложной задаче есть кроме сложных случаев куча простых. Это смесь. И когда ты имеешь возможность простые составляющие записывать "просто", чтобы они не отвлекали читателя от "сложных" — то это очень положительно сказывается на описании "сложного" решения.
G>>А для сложного случая — что мне мешает сделать по месту и необходимости message loop и использовать твой стиль (кстати, во многих случаях я этого смогу избежать, расщепив агента на несколько)?
E>Одной из целей было освобождение разработчика от необходимости взаимодействия с message loop вообще. И, как следствие, от избавления от спагети-кода, в который, как правило, превращается при сопровождении работа с message loop.
Мессадж луп можно записать очень просто, если об этом специально позаботится. Да хоть твоими же макросами, только не в определении класса, а в определении функции, вот и вся разница. Кстати, макросов при этом потребуется поменьше.
G>>Получается, что я могу комбинировать оба подхода, а ты привязан к одному из них. Хорошо ли это?
E>Мне кажется, что тотальная асинхронность все-таки лучше тотальной синхронности.
А я вижу очень большое преимущество в возможности комбинирования обоих подходов.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Короче. Код по понятной причине показать не могу. Но могу описать ситуацию. Дело было так.
E>Все это интересно, но ты судишь на основании, я бы сказал, достаточно частного опыта.
Все мы судим на основании частного опыта. Мой опыт основан на аппликухе размером в 2.5 миллиона строк кода, которая целиком написана в асинхронном стиле. То есть, я "накушался" именно такого подхода, о котором идет речь, в разных позах, по самые гланды. Там вообще не только P&F был, я там как-никак 6 лет проработал . Там были и "протокольные" задачи тоже, которые как раз неплохо в виде явного КА записывать. Во избежание.
E>Кстати, судя по описанию задачи, я бы не рекомендовал сходу использовать для P&F мой подход, т.к. он гораздо лучше подходит для "тяжелых" сообщений-заданий или уведомлений. Преобразовывать последовательности временных рядов в сообщения sobjectizer-агентов невыгодно. В том числе и из-за слишком большого "синтаксического оверхеда" в коде sobjectizer-агентов.
Я тоже не рекомендовал бы. Но куда программист денется, если ты другого подхода не даешь? Вот я и говорю, лучше комбинированный подход использовать. Когда у тебя состояние "агента" хранится на стеке, как например в Эрланге, это дает возможность выбирать подход по месту.
Здравствуйте, Gaperton, Вы писали:
G>Когда ты расщепляешь для простоты агента на несколько — они живут в одном апартменте. И все.
Когда они живут на одном контексте, то они не могут просто так "заснуть" на блокирующем синхронном вызове и при этом сохранять свое состояние на стеке. Потребуются системно-зависимые хаки для копирование стека заснувшего агента и передачи его контекста другому агенту.
Хотя я мог тебя неправильно понять.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Когда ты расщепляешь для простоты агента на несколько — они живут в одном апартменте. И все.
E>Когда они живут на одном контексте, то они не могут просто так "заснуть" на блокирующем синхронном вызове и при этом сохранять свое состояние на стеке. Потребуются системно-зависимые хаки для копирование стека заснувшего агента и передачи его контекста другому агенту.
В винде для C/C++ это делается без каких-либо хаков, через стандартный API, при задействовании Fibers.
В Linux/Unix для C/C++ это должно делаться также без каких-либо хаков, через так называемые user-level threads.
В языках, которые поддерживают continuations, это можно сделать через них. Опять же, без хаков. Continuations это достаточно распространенная штука — я слышал, например, что так можно делать в Smalltalk, LISP, и JavaScript.
А вот в .NET такого штатными средствами сделать нельзя . По крайней мере, я год назад пытался найти в сети отчет о применении такого способа — не нашел .
E>Хотя я мог тебя неправильно понять.
Ты правильно меня понял. Да, для этого фокуса требуется уметь сохранять и переключать локальный контекст.
Здравствуйте, Gaperton, Вы писали:
G>Все мы судим на основании частного опыта. Мой опыт основан на аппликухе размером в 2.5 миллиона строк кода, которая целиком написана в асинхронном стиле.
Я с 1997-го работаю со своим (точнее, он не мой, просто мной реализован) подходом. На различных проектах, от управления технологическими процессами до электронной коммерции.
G>Я тоже не рекомендовал бы. Но куда программист денется, если ты другого подхода не даешь?
Мой подход можно пременять только для "крупноблочного" строительства. А внутри каждого блока использовать то, что будет наилучшим выбором.
В библиотеке ACE реализован специальный паттерн (вроде там это называется streams framework). Когда каждая стадия обработки потока данных оформляется в виде специального модуля (наследника ACE_Service_Object, кажется), а все взаимодействие строится на основе ручного помещения и извлечения сообщений в очереди сообщений. Такой подход хорошо подходит для решения различных задач. А SObjectizer является альтернативой такому streams framework-у.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Я тоже не рекомендовал бы. Но куда программист денется, если ты другого подхода не даешь?
E>Мой подход можно пременять только для "крупноблочного" строительства. А внутри каждого блока использовать то, что будет наилучшим выбором.
Добавь в него файберы, как в свое время сделал я, будет прикольно, полезно, и удобно. Это можно сделать ничего не сломав. И сможешь сочетать оба подхода. Если, конечно, у тебя нет идиосинкразии у Эрлангу .
Здравствуйте, Gaperton, Вы писали:
E>>Мой подход можно пременять только для "крупноблочного" строительства. А внутри каждого блока использовать то, что будет наилучшим выбором.
G>Добавь в него файберы, как в свое время сделал я, будет прикольно, полезно, и удобно. Это можно сделать ничего не сломав. И сможешь сочетать оба подхода.
Поживем -- увидим.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G> Скажем, подумай на досуге немного о том, почему и зачем в Эрланге сделан селективный receive на одном мэйлбоксе, а не по другому. Hint — это решение сильно упрощает код в реальных программах.
Коль скоро у нас кровавого мочилова нет, то я сам отвечу на этот вопрос
Штука в том, что селективный receive позволяет не заботится о порядке, в котором приходят сообщения. Пример:
Допустим, к нам могут прийти два сообщения, A и B. Прийти они могут в любом порядке, однако, по логике обработки мы должны сначала дождаться A, а только потом — B.
В Эрланге мы в этом случае так и пишем:
receive { msg_A, Body } -> process( Body ) end,
receive { msg_B, Body } -> process( Body ) end,
То есть, мы не должны явно обрабатывать обе ситуации, когда сначала приходит A а потом B, и наоборот. Код одинаков и весьма прямолинеен. И нам все равно, в каком порядке на самом деле они придут. Если B придет раньше A, оно просто полежит в мэйлбоксе до тех пор, пока его не заберут.
Еще один пример. Нам надо дождаться, когда придут все сообщения от "агентов" из списка, и только потом продолжать. Что мы делаем — мы в их тупо получаем в цикле, перебирая агентов из списка.
MsgList = [ receive { From, Body } -> Body end || From <- WaitingAgentsList ]
И все. Вот таким элементарным образом мы поставили барьерную синхронизацию — мы дожидаемся сообщений в том порядке, в котором нам удобно, и все работает отлично.
Вот это на первый взгляд несущественное свойство selective receive вкупе с определенным устройством входного ящика весьма положительно и заметным образом сказывается на реальном коде обработчика приема сообщений. Мы обрабатываем только один случай, тот который нам нужен, синхронизация происходит автоматически.
Здравствуйте, Gaperton, Вы писали:
E>>Хотя я мог тебя неправильно понять.
G>Ты правильно меня понял. Да, для этого фокуса требуется уметь сохранять и переключать локальный контекст.
Я ошибся. Почему-то стал считать, что аппартментом может быть один фибер для нескольких агентов. Поскольку, если каждому из мелких агентов дать по своему файберу, то нужно будет следить за тем, чтобы они запускались только на контексте одной нити. Тогда как могли бы быть ситуации, когда выгодно было бы дать таким файберам работать параллельно на разных нитях. Но такой сценарий, при некотором размышлении, не выглядит слишком реалистичным.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>> Скажем, подумай на досуге немного о том, почему и зачем в Эрланге сделан селективный receive на одном мэйлбоксе, а не по другому. Hint — это решение сильно упрощает код в реальных программах.
G>Коль скоро у нас кровавого мочилова нет, то я сам отвечу на этот вопрос
Всю эту бодягу, AFAIK, сам Джо Армстронг уже расписывал. Может быть даже неоднократно
G>Хорошее свойство.
Сильно сомневаюсь, по крайней мере на основании своего опыта.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Хотя я мог тебя неправильно понять.
G>>Ты правильно меня понял. Да, для этого фокуса требуется уметь сохранять и переключать локальный контекст.
E>Я ошибся. Почему-то стал считать, что аппартментом может быть один фибер для нескольких агентов. Поскольку, если каждому из мелких агентов дать по своему файберу, то нужно будет следить за тем, чтобы они запускались только на контексте одной нити.
Да, вот теперь ты точно правильно меня понял. Именно так. Всегда один агент — один файбер, много агентов — один апартмент, и ни в коем случае не пускать больше одного треда одновременно в каждый апартмент. Ибо нефиг.
E>Тогда как могли бы быть ситуации, когда выгодно было бы дать таким файберам работать параллельно на разных нитях. Но такой сценарий, при некотором размышлении, не выглядит слишком реалистичным.
Совершенно верно. Реальный параллелизм в данном случае, ровно так же как и в COM, делается апартментами. Это не так страшно, ибо в серверных задачах тебе почти всегда хватит реального параллелизма на уровне клиентских сессий. Их всегда больше, чем процессоров.
Пример из телефонии. Один апартмент — один разговор. В апартменте живет один "главный" агент, и по одному "агенту на каждого участника разговора. Ответственность агентов-участников — они обрабатывают управляющий протокол точка-точка с IP-телефоном участника (это SIP-сессия), в то время как "главный" управляет всей конференцией-разговором, координируя агентов-участников, обеспечивая, например, добавление новых, и отключение текущих участников.
Скажем, при появлении нового участника конференции надо замогильным голосом всем объявить, что к нам присоединился новый участник. Эту процедуру инициирует "главный".
Смысл разделения на группу агентов в данном примере понятен — во первых, по своей семантике они независимы и параллельны, во вторых — мы таким шагом радикально упрощаем запись конечных автоматов.
Здравствуйте, Gaperton, Вы писали:
G>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
Если я правильно понимаю, то при вызове CopyStreamAsync сам ран-тайм произведет вызов на одной из рабочих нитей из пула. Т.е. вызывающей стороне всего лишь не придется вручную бабахаться с оформлением фьючерса.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>> Скажем, подумай на досуге немного о том, почему и зачем в Эрланге сделан селективный receive на одном мэйлбоксе, а не по другому. Hint — это решение сильно упрощает код в реальных программах.
G>>Коль скоро у нас кровавого мочилова нет, то я сам отвечу на этот вопрос
E>Всю эту бодягу, AFAIK, сам Джо Армстронг уже расписывал. Может быть даже неоднократно
Ну, в общем, да, кто-то из них объяснял. Я это читал когда-то в сообщениях Ульфа Вигерса в мэйллисте. Я же не знаю, знаком ты с этим тезисом или нет. Ментальным сканированием не владею. Опять же, может кому еще интересно будет.
G>>Хорошее свойство.
E>Сильно сомневаюсь, по крайней мере на основании своего опыта.
Знаешь, по крайней мере это не плохое свойство . Автоматическая неявная синхронизация, которую мы имеем без каких-либо умственных затрат в данном случае — чем плоха?
Здравствуйте, eao197, Вы писали:
G>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
E>Если я правильно понимаю, то при вызове CopyStreamAsync сам ран-тайм произведет вызов на одной из рабочих нитей из пула. Т.е. вызывающей стороне всего лишь не придется вручную бабахаться с оформлением фьючерса.
Какое-то получается весьма сомнительное преимущество. Которое скорее затруднит чтение кода, чем сделает его более понятным. Уж лучше тупо фьючерсы на уровне языка поддержать, чтоб не заставлять программиста сильно бабахаться с его оформлением, и не морочить людям голову.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Угу, Axum так умеет.
G>>Синхронное и асинхронное копирование данных из одного стрима в другой на Axum
G>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
Позаменяет синхронные вызовы, на аналогичные им асинхронные и треды блокироваться не будут. Кроме того с помощью констркции interleave можно несколько асинхронных возовов параллельно запустить при этом не париться с синхронизацией.
Именно для таких выкрутасов и нужен язык, а не просто библиотека.
Здравствуйте, gandjustas, Вы писали:
G>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
G>Позаменяет синхронные вызовы, на аналогичные им асинхронные и треды блокироваться не будут. Кроме того с помощью констркции interleave можно несколько асинхронных возовов параллельно запустить при этом не париться с синхронизацией.
G>Именно для таких выкрутасов и нужен язык, а не просто библиотека.
А вот тут рядом eao197 фьючерсы весьма по делу помянул. Чем это лучше работы с фьючерсами?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
G>>Позаменяет синхронные вызовы, на аналогичные им асинхронные и треды блокироваться не будут. Кроме того с помощью констркции interleave можно несколько асинхронных возовов параллельно запустить при этом не париться с синхронизацией.
G>>Именно для таких выкрутасов и нужен язык, а не просто библиотека.
G>А вот тут рядом eao197 фьючерсы весьма по делу помянул. Чем это лучше работы с фьючерсами?
Декларативностью.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
G>>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
E>>Если я правильно понимаю, то при вызове CopyStreamAsync сам ран-тайм произведет вызов на одной из рабочих нитей из пула. Т.е. вызывающей стороне всего лишь не придется вручную бабахаться с оформлением фьючерса.
G>Какое-то получается весьма сомнительное преимущество. Которое скорее затруднит чтение кода, чем сделает его более понятным.
да ну? Разница между синхронныи и асинхронным вариантом в одном декларативном объявлении затрудняет чтение кода?
G>Уж лучше тупо фьючерсы на уровне языка поддержать, чтоб не заставлять программиста сильно бабахаться с его оформлением, и не морочить людям голову.
Они вроде и так поддерживаются, правда я по фьючерсам не спец.
Здравствуйте, gandjustas, Вы писали:
G>>>>Занятно. И что именно он сделает с моим кодом, если я напишу asynchronous? Это поддается осмыслению?
G>>>Позаменяет синхронные вызовы, на аналогичные им асинхронные и треды блокироваться не будут. Кроме того с помощью констркции interleave можно несколько асинхронных возовов параллельно запустить при этом не париться с синхронизацией.
G>>>Именно для таких выкрутасов и нужен язык, а не просто библиотека.
G>>А вот тут рядом eao197 фьючерсы весьма по делу помянул. Чем это лучше работы с фьючерсами? G>Декларативностью.
"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
Если я в длинной функции объявил фьючерс, то я сообщаю читателю, что вот эта переменная, обращение с которой выглядит вполне гражданским образом, на самом деле скрывает под собой асинхронные вычисления. А остальные — нет. Человек видит такие места в коде.
Если я в начале длинной функции ставлю asynchronous, читатель должен ментальным сканированием догадываться о его поведении?
Здравствуйте, gandjustas, Вы писали:
G>>Какое-то получается весьма сомнительное преимущество. Которое скорее затруднит чтение кода, чем сделает его более понятным. G>да ну? Разница между синхронныи и асинхронным вариантом в одном декларативном объявлении затрудняет чтение кода?
Конечно. Точки взаимодействия не видны явно. А это читателю функции будет очень интересно знать.
Здравствуйте, Gaperton, Вы писали:
G>Короче, это хорошее, годное решение .
У нас аппартменты реализуются через привязку агентов к диспетчерам. Агент может быть либо пассивным (работать на одной нити вместе с другими пассивными), либо членом активной группы (каждая группа работает на своей нити, состав группы может динамически изменяться), либо активным объектом (один агент -- одна нить). За счет этого в наших приложениях могут быть сотни тысяч агентов (на тестах их число достигало 500K на машине с 2Gb RAM, в боевых системах -- до нескольких тысяч), которые работают на десятках/сотнях нитях.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
E>>Сильно сомневаюсь, по крайней мере на основании своего опыта.
G>Знаешь, по крайней мере это не плохое свойство . Автоматическая неявная синхронизация, которую мы имеем без каких-либо умственных затрат в данном случае — чем плоха?
Я не могу с ходу вспомнить ситуацию из своей практики, когда сообщение, которое нам не нужно на текущем шаге (в текущем состоянии), может потребоваться на следующем шаге (в новом состоянии). И как раз для того, чтобы не оставлять в mailbox-е сообщения, которые мы проигнорировали (и не путали карты впоследствии), у нас нет selective receive.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Смотри. Вот это — асинхронный код. На "псевдокоде" пишу.
А в раннем CQG десятилетней давности (которому тогда было всего-то десять лет возраста) ваще была жесть. Она тоже построена на агентском фреймворке, весьма неплохом, но! Там в ряде прикладных объектов-агентов не было события, соответствующего завершению запроса. Его иногда бывает удивительно трудно корректно добавить, вы не поверите, парни . Например, если речь идет о готовности сети активных объектов из сотен элементов, с нетривиальной топологией, и со сложным и потенциально разным поведением и состоянием, у которых локально оптимизировано прохождение асинхронных сообщений в рамках сети . В таких случаях, объект-сервис приходилось опрашивать по таймеру, дожидаясь, пока он не станет готов. Примерно так:
G>
Не проняло? Тогда представьте, что вам надо сделать серию запросов в цикле, чтобы потом обработать их результат, и некоторые запросы могут обломиться (как сразу, так и потом) — и тогда надо корректно обработать ошибку.
Вот он, асинхронный код во всей своей всеподавляющей мощи, ломающий психику пионеров легко, как ураган сносит карточный домик, и парализующий волю ветеранов, в сердца которых ледяным сквозняком закрадывается ужас и безысходность!
И ведь, типо, по другому нельзя. Не, понятно, что можно написать обертку вокруг этого безобразия, которая будет давать нормальный event. Но оно будет выглядеть только чуть-чуть лучше. Надо решать проблему радикально. Как?
Показываю особую, файберную магию, которая обеспечивается примерно пятью сотнями строк кода в системном фреймворке, и минимальными модификациями прикладного кода. Да, eao197, это опять мой "волшебный" шедулер .
G>
В современном CQG это можно делать двумя способами, как по старинке, так и способом, описанным выше, если вызовы идут из контекста файбера. Как хотите — работают оба способа. По моему, здоровый человек без мазохистских наклонностей предпочтет второй.
Разумеется, я пишу весьма условный код, демонстрирующий стиль работы, не раскрывая никакой коммерческой тайны. Просто я хочу, чтобы проняло, чтобы вы почувствовали, что все не так просто .
Здравствуйте, eao197, Вы писали:
E>У нас аппартменты реализуются через привязку агентов к диспетчерам. Агент может быть либо пассивным (работать на одной нити вместе с другими пассивными), либо членом активной группы (каждая группа работает на своей нити, состав группы может динамически изменяться), либо активным объектом (один агент -- одна нить). За счет этого в наших приложениях могут быть сотни тысяч агентов (на тестах их число достигало 500K на машине с 2Gb RAM, в боевых системах -- до нескольких тысяч), которые работают на десятках/сотнях нитях.
Ну вот, апартменты уже есть. Дело за небольшим — добавить "файберного агента", чтобы он мог использоваться наравне с коллбэчным, и проследить, чтобы они не сожрали все адресное пространство . Они, в принципе, на 32 битах такое могут. И станет у тебя комфортно, "как в Эрланге". Ну, почти.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
E>>>Сильно сомневаюсь, по крайней мере на основании своего опыта.
G>>Знаешь, по крайней мере это не плохое свойство . Автоматическая неявная синхронизация, которую мы имеем без каких-либо умственных затрат в данном случае — чем плоха?
E>Я не могу с ходу вспомнить ситуацию из своей практики, когда сообщение, которое нам не нужно на текущем шаге (в текущем состоянии), может потребоваться на следующем шаге (в новом состоянии). И как раз для того, чтобы не оставлять в mailbox-е сообщения, которые мы проигнорировали (и не путали карты впоследствии), у нас нет selective receive.
Избежать лика очень просто — добавляешь пустой паттерн в конец списка, и все. Это не проблема.
Если ты всегда разделяешь мэйлбоксы для разных типов сообщений, то в selective receive выраженной повседневной необходимости нет. Если тебе не важна последовательность прихода сообщений разных типов и от разных источников, конечно. Обычно она не важна.
А в решении Эрланга, в свою очередь, мэйлбоксы декларировать не нужно, они как бы "создаются" неявно и динамически. Это удобно и более гибко. В языке, где есть паттерн-матчинг, так работать удобнее. Если паттерн-матчинга в языке нет — чисто с точки зрения использования удобнее создавать много мэйлбоксов, а не пользоваться selective receive. Все просто.
Здравствуйте, Gaperton, Вы писали:
E>>У нас аппартменты реализуются через привязку агентов к диспетчерам. Агент может быть либо пассивным (работать на одной нити вместе с другими пассивными), либо членом активной группы (каждая группа работает на своей нити, состав группы может динамически изменяться), либо активным объектом (один агент -- одна нить). За счет этого в наших приложениях могут быть сотни тысяч агентов (на тестах их число достигало 500K на машине с 2Gb RAM, в боевых системах -- до нескольких тысяч), которые работают на десятках/сотнях нитях.
G>Ну вот, апартменты уже есть. Дело за небольшим — добавить "файберного агента", чтобы он мог использоваться наравне с коллбэчным, и проследить, чтобы они не сожрали все адресное пространство . Они, в принципе, на 32 битах такое могут. И станет у тебя комфортно, "как в Эрланге". Ну, почти.
Я в свое время именно так и сделал. Чтобы не лезть в работающий механизм, с одной стороны, и чтобы работа в "легаси" окружении стала более комфортной — с другой. Результатом очень доволен. И не только я. Получается более "гражданский" механизм, для использования которого не требуется высокого порога вхождения. Людям очень нравится.
G>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows. T>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке? G>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.
Вот уж совсем не проблема.
T>>Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения. G>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
T>>А все подхватили. G>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда.
Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества.
(обнаружил себя в непривычной ситуации защиты Эрланга)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Я не могу с ходу вспомнить ситуацию из своей практики, когда сообщение, которое нам не нужно на текущем шаге (в текущем состоянии), может потребоваться на следующем шаге (в новом состоянии). И как раз для того, чтобы не оставлять в mailbox-е сообщения, которые мы проигнорировали (и не путали карты впоследствии), у нас нет selective receive.
Вторая причина по которй Erlang поддерживает selective-receive — горячая замена кода.
Здравствуйте, thesz, Вы писали:
G>>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows. T>>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке? G>>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп.
T>Вот уж совсем не проблема.
С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.
T>>>Но ладно итог исследований. Сейчас-то чего? То, что я вижу, не тянет больше, чем на библиотеку. Это назвали языком в силу какого-то недоразумения. G>>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке. T>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
А зачем? С такой платформой как .NET отдельный язык может быть гораздо выгоднее, чем впихивать теже особенности в DSEL.
Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
T>>>А все подхватили. G>>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда. T>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества.
Ну давай посмотрим. В чем Erlang настолько больше?
T>(обнаружил себя в непривычной ситуации защиты Эрланга)
(а я вроде как и не против Erlang был)
Здравствуйте, gandjustas, Вы писали: G>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
Не знаю, насколько там все удачно, но вот: http://rsdn.ru/forum/message/3374655.1.aspx
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали: G>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? MC>Не знаю, насколько там все удачно, но вот: http://rsdn.ru/forum/message/3374655.1.aspx
Здравствуйте, thesz, Вы писали:
T>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке".
T>Увы, ты начал понимать только общее для Axum и Erlang.
Удивительные вы люди, все таки. Я уже практически прямо сказал — что это за проект и для чего он нужен. Это эксперимент на тему того, что будет C# 5 (точно так же как C omega был прототипоМ ряда фич C# 3), и от этого и надо плясать при оценке. Не верите?
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, Gaperton, Вы писали:
G>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
Но при этом ты доказываешь, что твои фокусы с файберами, которые магия куда как более хардкорная, это тоже хорошо
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
T>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке". T>>Увы, ты начал понимать только общее для Axum и Erlang. AVK>Удивительные вы люди, все таки. Я уже практически прямо сказал — что это за проект и для чего он нужен. Это эксперимент на тему того, что будет C# 5 (точно так же как C omega был прототипоМ ряда фич C# 3), и от этого и надо плясать при оценке. Не верите?
От этого моя оценка не меняется, поверь.
И то, что это тот самый fire, чтобы не было motion, и всего остального.
Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут.
Поэтому это очередная умеренно удобная фича, стоящая не более, чем очередная библиотека/DSeL на Haskell.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
G>>>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows. T>>>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке? G>>>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп. T>>Вот уж совсем не проблема. G>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.
Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
T>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке". G>А зачем? С такой платформой как .NET отдельный язык может быть гораздо выгоднее, чем впихивать теже особенности в DSEL.
Строгая типизация страдает.
G>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке?
Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
T>>>>А все подхватили. G>>>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда. T>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества. G>Ну давай посмотрим. В чем Erlang настолько больше?
Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.
Горячая замена кода.
Let it fail.
Пожалуй, достаточно.
T>>(обнаружил себя в непривычной ситуации защиты Эрланга) G>(а я вроде как и не против Erlang был)
Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>>>>>Для axum сейчас не нужно больше, чем сообщения, процессы и dataflows. T>>>>>И что получится в итоге? Беспроцессный монолитный императивный ужас, (сравнительно) непригодный к использованию в разработке? G>>>>Вроде как процессный, но очень императивный. Основное преимущество этого ужаса в том, что он он на .NET, поэтому хорошо делается интероп. T>>>Вот уж совсем не проблема. G>>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния.
T>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
С чего бы? Только потому что pattern-matching нету?
T>>>Это я в смысле "практически всё то же самое можно получить в виде DSEL на нормальном языке". G>>А зачем? С такой платформой как .NET отдельный язык может быть гораздо выгоднее, чем впихивать теже особенности в DSEL. T>Строгая типизация страдает.
Чем страдает?
G>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? T>Нет. Попробуй написать на Хаскеле, должно хорошо получиться.
Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.
T>>>>>А все подхватили. G>>>>Ну и хорошо, изучат новоые подходы в разработке. Я например после прочтения статей и примеров по Axum начал Erlang понимать, хотя его изучением и не занимался никогда. T>>>Увы, ты начал понимать только общее для Axum и Erlang. А Erlang в целом больше этого подмножества. G>>Ну давай посмотрим. В чем Erlang настолько больше?
T>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности.
Неизменяемые данные есть и в Axum, там это называется схемами. Только схемы там сериализуемые должны быть, поэтому ФВП непердавать нельзя.
Хотя не знаю насколько необходимо передавать ФВП, там ведь полностью поддерживается ООП.
T>Горячая замена кода.
Горячая замена кода есть и в .NET, только больше приседаний для нее надо.
T>>>(обнаружил себя в непривычной ситуации защиты Эрланга) G>>(а я вроде как и не против Erlang был)
T>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
Улыбнуло. Разве кто-то говорит что надо срочно бросить все и писать на axum?
Здравствуйте, AndrewVK, Вы писали:
IT>>Для полной уверенности нужно, чтобы if и switch перестали быть statement и превратились в expression.
AVK>Метод типа R If<R>(Func<bool> predicate, Func<R> @then, Func<R> @else) не спасет? Или это слишком тормозной вариант для твоих целей?
Это выкривление одной кривизны с помощью другой. Короче говоря извратство.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
Z>>Вторая причина по которй Erlang поддерживает selective-receive — горячая замена кода. E> А можно развернуть этот тезис?
Это не то, чтобы отдельная причина, скорее следствие того, что сообщение может быть в том числе и новым кодом для агента. А сообщение новому агенту может прийти до того, как будет установлен новый код.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gaperton, Вы писали:
G>>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
AVK>Но при этом ты доказываешь, что твои фокусы с файберами, которые магия куда как более хардкорная, это тоже хорошо
Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все.
Файберы — лишь иллюстрация того, как этого можно достичь в С++. Другие способы, кроме файберов, для достижения данного свойства в С++, мне не известны. Кроме того, эта хардкорная магия снаружи выглядит весьма просто, приятно и понятно. Ведет себя предсказуемо, дает программисту контроль на ситуацией, и облегчает чтение кода. Данная "декларативность" его имхо затрудняет.
Здравствуйте, eao197, Вы писали:
E>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях. High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно. И она достаточно уныла, чтобы не возникало такого желания.
T>>Пожалуй, достаточно. E>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
HPC не означает отсутствия устойчивости к сбоям.
Но в любом случае я точно буду использовать .Net только как одну из альтернатив.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>От этого моя оценка не меняется, поверь.
Дело не в твоей оценке, а в тех предпосылках и гаданиях на каофейной гуще, что я вижу в этом топике.
T>Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут.
Разумеется. Потому что цели сделать еще один Ерланг не стоит. Стоит цель улучшить поддержку асинхронного программирования в языке C#. И, сразу скажу, под асинхронным программированием в МС в данном конкретном случае понимают не решение коммуникационных задач и прочего ввода-вывода (это опять же к вопросу о ерланге), а для утилизации мультикоров с целью ускорения числомолотилок. Соотв., скажем, обсуждать библиотечку eao в приложении к Axim малоосмысленно.
T>Поэтому это очередная умеренно удобная фича, стоящая не более, чем очередная библиотека/DSeL на Haskell.
Именно. Но тут надо понимать, что ресеч еще только начинается, это даже близко не окончательный вариант.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек.
Он уже достаточно функционален, чтобы можно было использовать функциональный стиль. Бесскомпромиссным, навроде Clean или Haskell, он, разумеется, никогда не будет. Впрочем, это все вопрос терминологии.
T>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду.
Ну я знал, что этим все закончится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, Gaperton, Вы писали:
G>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях. High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно
Тем не менее, Евгений мыслит в абсолютно правильном направлении — в МС рассматривают прежде всего реюз мультикора для ускорения рассчетов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
T>>От этого моя оценка не меняется, поверь. AVK>Дело не в твоей оценке, а в тех предпосылках и гаданиях на каофейной гуще, что я вижу в этом топике.
Ну, у тебя тоже аргументы так себе.
T>>Ведь ясно же, что разделения процессов и сравнения с образцом из Эрланга через Axum в c# не внесут. AVK>Разумеется. Потому что цели сделать еще один Ерланг не стоит. Стоит цель улучшить поддержку асинхронного программирования в языке C#. И, сразу скажу, под асинхронным программированием в МС в данном конкретном случае понимают не решение коммуникационных задач и прочего ввода-вывода (это опять же к вопросу о ерланге), а для утилизации мультикоров с целью ускорения числомолотилок. Соотв., скажем, обсуждать библиотечку eao в приложении к Axim малоосмысленно.
1) Откуда ты знаешь, что понимают в MS?
2) Использовать агенты в HPC — немного совсем малоэффективное решение. Очень легко получить бутылочное горлышко, насколько я могу судить по своему опыту.
Твои аргументы очень слабые, с моей точки зрения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек. AVK>Он уже достаточно функционален, чтобы можно было использовать функциональный стиль. Бесскомпромиссным, навроде Clean или Haskell, он, разумеется, никогда не будет. Впрочем, это все вопрос терминологии.
Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.
Вопрос: какой порядок упрощения в функциональном подмножестве C#?
И другой: как скоро порядок упрощения в функциональном подмножестве C# дойдёт до алгоритма Common Lisp?
Пока же заявления о "достаточной функциональности" C# навевают на меня мысли либо об омониме слова "функциональный", либо о словосочетании "достаточно беременный", полностью бессмысленном и более точно выражающем мои ощущения.
T>>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду. AVK>Ну я знал, что этим все закончится.
Я с самого начала это сказал. С этого и начался мой путь в этом топике.
Я считаю, что Axum — это PR .Net.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Ну, у тебя тоже аргументы так себе.
Неправда. У меня их просто нет. В данном конкретном случае я просто делюсь доступной мне информацией, чтобы вы не плодили лишних домыслов. А спорьте вы уж сами, без меня.
T>1) Откуда ты знаешь, что понимают в MS?
Есть источники.
T>2) Использовать агенты в HPC — немного совсем малоэффективное решение. Очень легко получить бутылочное горлышко, насколько я могу судить по своему опыту.
Ну вот на то он и ресечь, чтобы доподлинно это понять. TPL использует fine grained таски, может в этом направлении что нибудь накопают.
T>Твои аргументы очень слабые, с моей точки зрения.
Еще раз повторяю — я вообще тут не спорю, нет никаких аргументов, исключительно факты (да, ссылками я их подтвердить не могу, но информация в том числе и из первых рук).
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Вопрос: какой порядок упрощения в функциональном подмножестве C#?
Терминологические споры бессмысленны и беспощадны. Но под большинство определений функционального языка, которые я видел, С# 3 подходит.
T>Пока же заявления о "достаточной функциональности" C# навевают на меня мысли либо об омониме слова "функциональный", либо о словосочетании "достаточно беременный", полностью бессмысленном и более точно выражающем мои ощущения.
Твои чувства и ощущения к делу не подошьешь. Ну высказал ты, какое дерьмо, в твоем понимании, C#. Ну и дальше что? Цель какая?
AVK>>Ну я знал, что этим все закончится.
T>Я считаю, что Axum — это PR .Net.
С верой спорить бесполезно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
T>>Ну, у тебя тоже аргументы так себе. AVK>Неправда. У меня их просто нет. В данном конкретном случае я просто делюсь доступной мне информацией, чтобы вы не плодили лишних домыслов. А спорьте вы уж сами, без меня.
Или наоборот, чтобы эти домыслы породить.
T>>1) Откуда ты знаешь, что понимают в MS? AVK>Есть источники.
Невероятно.
T>>2) Использовать агенты в HPC — немного совсем малоэффективное решение. Очень легко получить бутылочное горлышко, насколько я могу судить по своему опыту. AVK>Ну вот на то он и ресечь, чтобы доподлинно это понять. TPL использует fine grained таски, может в этом направлении что нибудь накопают.
Будет то же, что и в Parallel Haskell. Со всеми плюсами и минусами. Точнее, с меньшим количеством плюсов и большим минусов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, AndrewVK, Вы писали:
AVK>синтаксически несколько избыточно. Применять вполне можно.
Именно из-за этого нюанса применять-то можно, но никто не будет.
T>>Вопрос: какой порядок упрощения в функциональном подмножестве C#? AVK>Терминологические споры бессмысленны и беспощадны. Но под большинство определений функционального языка, которые я видел, С# 3 подходит.
Nope. В C# 3.0 ты можешь создать лямбду с побочным эффектом.
T>>Пока же заявления о "достаточной функциональности" C# навевают на меня мысли либо об омониме слова "функциональный", либо о словосочетании "достаточно беременный", полностью бессмысленном и более точно выражающем мои ощущения.
AVK>Твои чувства и ощущения к делу не подошьешь. Ну высказал ты, какое дерьмо, в твоем понимании, C#. Ну и дальше что? Цель какая?
Тему про "достаточность функциональности" не я поднял. Мне, главное опровергнуть, чтобы она не послужила аргументом в споре.
Мне достаточно, что ты это принял.
T>>Я считаю, что Axum — это PR .Net. AVK>С верой спорить бесполезно.
Я здесь пытаюсь показать минимальность нового в Axum, из чего следует, что это PR. В ответ со мной соглашаются, но продолжают утверждать, что это хорошая штука.
Вопрос: кто здесь пьёт Cool-Aid?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>2) Использовать агенты в HPC — немного совсем малоэффективное решение. E>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями.
А чем они от него отличаются-то?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
AVK>>>Я бы 100 рублей на это не поставил. T>>const могут распространить, конечно. Но это будет ой, как нескоро. AVK>Я бы 100 рублей на это не поставил. (С)
Точно до конца этого года неизменяемые значения не появятся в доступном рядовому пользователю C#. Ещё точнее, они не появятся до первого января 2010 года. На это могу поставить 10000 рублей.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Точно до конца этого года неизменяемые значения не появятся в доступном рядовому пользователю C#
Ну это уж 100%. Дизайн C# 4 уже финализован, а C# 5 раньше 2011 года ждать не стоит. Это очевидные вещи. Только здесь то обсуждается ресеч, нацеленный как раз на тот самый предполагаемый релиз Dev11.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали: T>При изменяемости значений нет смысла в сравнении с образцом. Рассуждения запутываются настолько, что смысл пропадает.
Согласен, что сопоставляемому значению лучше во время сопоставления не меняться. Другой вопрос — должен ли это контролировать программист или компилятор.
T>Все (практически, все) языки со сравнением с образцом имеют неизменяемые значения. На ум в качестве опровержения приходит только Refal.
Scheme, lua (с ней могу ошибаться).
Здравствуйте, Mr.Cat, Вы писали: T>>Все (практически, все) языки со сравнением с образцом имеют неизменяемые значения. На ум в качестве опровержения приходит только Refal. MC>Scheme, lua (с ней могу ошибаться).
Т.е. неизменяемые значения в scheme есть, но они ортогональны матчингу.
T>>Nope. В C# 3.0 ты можешь создать лямбду с побочным эффектом.
AVK>Ну и что? Лямбду без побочного эффекта на C# создать можно, а уж что там можно еще — дело десятое. Это называется — мультипарадигменный.
Таким образом он не подпадает под определение "функциональный". Ни под одно из имеющихся в сети (что по моей ссылке выше).
T>>Тему про "достаточность функциональности" не я поднял. AVK>А кто?
. Нет?
T>> Мне, главное опровергнуть, чтобы она не послужила аргументом в споре. AVK>Это не причина.
Здесь я узнаю почерк ВладаД2. Влад, это ты?
Это должен быть ты. Уж больно на твои non-sequitur-ы похоже.
T>>Мне достаточно, что ты это принял. AVK>Я? Зачем?
Принял ли ты, что C# недостаточно функционален?
Если нет, то почему. Хотя я понимаю, почему нет. Потому, что в твоей системе ценностей он уже "достаточно функционален", поэтому он не может быть "недостаточно функционален" вообще никогда.
T>>>>Я считаю, что Axum — это PR .Net. AVK>>>С верой спорить бесполезно. T>>Я здесь пытаюсь показать минимальность нового в Axum AVK>Не, это исключительно твоя вера, потому что никаких фактов в поддержку этого ты не приводишь.
Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
T>>, из чего следует, что это PR AVK>Из того что ты пытаешься следует? Отличная логика. И прекрасная демонстрация того, что это все таки вера.
"Что это PR" следует из минимальности нововведений в Axum.
T>>. В ответ со мной соглашаются, но продолжают утверждать, что это хорошая штука. AVK>Я с тобой никогда в этом не соглашался. Просто потому что у меня несколько больше информации о причинах внутренних течений в МС.
Ух ты.
Но ты не spokeperson и у тебя нет странички в MSR. Поэтому я не стану брать твои слова на веру.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>При изменяемости значений нет смысла в сравнении с образцом. Рассуждения запутываются настолько, что смысл пропадает. MC>Согласен, что сопоставляемому значению лучше во время сопоставления не меняться. Другой вопрос — должен ли это контролировать программист или компилятор.
Компилятор, конечно. Он железный, ему проще.
T>>Все (практически, все) языки со сравнением с образцом имеют неизменяемые значения. На ум в качестве опровержения приходит только Refal. MC>Scheme, lua (с ней могу ошибаться).
Уверен насчёт Scheme? Приведешь источник сведений?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Точно до конца этого года неизменяемые значения не появятся в доступном рядовому пользователю C# AVK>Ну это уж 100%. Дизайн C# 4 уже финализован, а C# 5 раньше 2011 года ждать не стоит. Это очевидные вещи. Только здесь то обсуждается ресеч, нацеленный как раз на тот самый предполагаемый релиз Dev11.
Каюсь, я тоже не сперва указал сроков действия моего утверждения. Mea culpa. Я неявно подразумевал, что для практических целей сроки появления неизменяемых значений в C# настолько велики, что их можно считать бесконечными.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>> Ты же ангажирован. AVK>Бессмысленный и необоснованный личный наезд.
Почему это? Ангажированность не свойство личности. Это может быть следствием заблуждений.
AVK>>>Я бы 100 рублей на это не поставил. (С) T>>Видимо, тебя задело. AVK>Нет. T>>Кстати, а ты знаешь, что творится-то в Parallel Haskell? AVK>Нет, это мне на данный момент не очень интересно.
Однако имеешь уверенность что-то утверждать насчёт "100 рублей".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Таким образом он не подпадает под определение "функциональный".
Таким образом он не попадает под определение "исключительно функциональный". Я об этом с самого начала говорил. А по тому, что по ссылке — попадает.
T>>>Тему про "достаточность функциональности" не я поднял. AVK>>А кто?
T>По-моему, ты
Нет. Это ты тут стал бросаться обвинениями, что шарп не функциональный, а посему декларативный подход к асинхронности ему не доступен.
Более того — доработка в направлении изоляции и контроля стейтов (state contraints) (в том числе та самая неизменяемость, но не только) — одна из главных целей в C# 5.
T>>> Мне, главное опровергнуть, чтобы она не послужила аргументом в споре. AVK>>Это не причина.
T>Здесь я узнаю почерк ВладаД2. Влад, это ты?
Нет, это не он. Я, собственно, не из под анонимного аккаунта пишу.
T>>>Мне достаточно, что ты это принял. AVK>>Я? Зачем?
T>Принял ли ты, что C# недостаточно функционален?
Глупость какая. Ты что, пастор, что хочешь меня в свою веру обратить? К чему этот бессмысленный спор? С# достаточно функционален уже, чтобы делать такие вещи как ParallelFX, и никто не мешает (точнее ничто) сделать его еще более функциональным, буде это понадобится для конкретных целей. Но откручивать от него ОО, императивщину или динамику, разумеется, никто не будет.
T>Если нет, то почему. Хотя я понимаю, почему нет. Потому, что в твоей системе ценностей он уже "достаточно функционален", поэтому он не может быть "недостаточно функционален" вообще никогда.
Заканчивай с обсуждением моей системы ценностей и прочих аспектов моей личности, бо это грубейшая и неумелая демагогия.
AVK>>Не, это исключительно твоя вера, потому что никаких фактов в поддержку этого ты не приводишь.
T>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
Сам понимаешь, где логическая ошибка?
T>"Что это PR" следует из минимальности нововведений в Axum.
Попробуй это доказать. Я пока логической цепочки не вижу. Вижу логическое нарушение — то, что ты не можешь придумать никакого другого объяснения, кроме того что это PR, никак не следует что это действительно PR.
Погляди от Re[6]: Axum: паралельное программирование
и вниз по ветке — исключительно бездоказательные утверждения. Именно поэтому я и назвал это верой.
T>Но ты не spokeperson и у тебя нет странички в MSR. Поэтому я не стану брать твои слова на веру.
Твое право.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Каюсь, я тоже не сперва указал сроков действия моего утверждения. Mea culpa. Я неявно подразумевал, что для практических целей сроки появления неизменяемых значений в C# настолько велики, что их можно считать бесконечными.
Тогда это утверждение малоценно и тривиально, потому что отсутствие изменений до C# 5 ни у кого сомнений не вызывает. Увы, неприятные особенности мейнстрима.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Потому что моя личность к теме топика не имеет никакого отношения, и переход на личности это грубый демагогический прием.
T> Ангажированность не свойство личности. Это может быть следствием заблуждений.
Здесь не обсуждаются мои заблуждения.
T>>>Кстати, а ты знаешь, что творится-то в Parallel Haskell? AVK>>Нет, это мне на данный момент не очень интересно.
T>Однако имеешь уверенность что-то утверждать насчёт "100 рублей".
Потому что у меня есть кое какая информация, которой я здесь поделиться, к сожалению, не могу, NDA.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали: T>Уверен насчёт Scheme?
В том, что для нее реализован матчинг? Было бы странно, если бы это было не так, ибо макросы рулят.
В plt scheme, например, оно вот так: http://docs.plt-scheme.org/reference/match.html.
Есть еще немного другой вариант — http://synthcode.com/scheme/match.scm — он подходит для разных имплементаций (ссылку проверить не могу, т.к. почему-то synthcode.com у меня дома не работает).
Здравствуйте, AndrewVK, Вы писали:
AVK>Таким образом он не попадает под определение "исключительно функциональный". Я об этом с самого начала говорил. А по тому, что по ссылке — попадает.
functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data
Не can avoid, а avoids. Можно ли написать на C# такую лямбду, чтобы она _гарантированно_ avoids state and mutable data? До тех пор, пока за это ответственнен автор лямбды и компилятор это не проверяет, функциональным языком будет и Паскаль, где никто не мешает мне написать function foo(x) result := x*x
Здравствуйте, thesz, Вы писали:
T>>>2) Использовать агенты в HPC — немного совсем малоэффективное решение. E>>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями.
T>А чем они от него отличаются-то?
Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами. Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VoidEx, Вы писали:
VE>>Не can avoid, а avoids.
AVK>Правильно, потому что для чисто функционального кода это не допустимо. Вообще, поражаюсь простой вещи — как что то по делу спрашиваешь, с кодом там, реакция вялая. Зато как терминологический спор — желающих хоть отбавляй. AVK>В контексте этого топика важна именно возможность, а не отсутствие поддержки других стилей.
А где я требую отсутствие поддержки других стилей? Ради бога, пусть можно создать лямбду с побочками. Но вот это должно быть обязательно:
void pureFoo(PureFunc<int, int> f) { Console.WriteLine(f(5)); }
void foo(Func<int, int> f) { Console.WriteLine(f(5)); }
pureFoo(x => { Console.WriteLine(x); return x; }); // error! lambda is not pure
foo(x => { Console.WriteLine(x); return x; }); // ok
pureFoo(x => x*x); // ok
foo(x => x*x); // ok
Вот пока еррора нет, никакой функциональщины тоже нет. Она держится лишь на добром слове авторов соответствующих функций.
Здравствуйте, thesz, Вы писали:
G>>>>С имеративностью я прогнал. В спеке по языку написано что axum поддерживать должен все функциональные фичи C# 3.0. Правда компилятор далек еще от этого состояния. T>>>Да ничего ты не прогнал. C# как был императивным, так и останется. Функциональным ему не быть вовек. G>>С чего бы? Только потому что pattern-matching нету?
T>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля.
Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода.
T>В нём не будет разделения типов выражений с эффектом и без.
И зачем оно надо?
T>Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом.
Неизменяемые значения есть. Более того в составе Axum есть компилятор C# с какими-то эксперементалтными фичами, связанными как раз с иммутабельностью.
T>>>Строгая типизация страдает. G>>Чем страдает?
T>Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе).
Ни разу не страдал от ухудшения проверок в .NET. Может пример адекватный приведешь?
T>Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка.
Дык в Axum проверки более сильные, чем в C#. Так что про DSEL мимо кассы.
G>>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? T>>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться. G>>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром.
T>Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом.
Угу, сомневаюсь что в исследовательском проекте это все необходимо.
А если уж необходимо то есть F#.
G>>>>Ну давай посмотрим. В чем Erlang настолько больше? T>>>Функции высших порядков, передаваемые по любому каналу. Неизменяемые данные. Глубокая инспекция данных, что обычно называют сравнением с образцом и что произрастает на их неизменности. G>>Неизменяемые данные есть и в Axum, там это называется схемами. Только схемы там сериализуемые должны быть, поэтому ФВП непердавать нельзя. G>>Хотя не знаю насколько необходимо передавать ФВП, там ведь полностью поддерживается ООП. T>Ты, вообще, HOF пользовался?
что есть HOF?
T>>>Горячая замена кода. G>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо. T>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии.
И что это меняет?
T>>>>>(обнаружил себя в непривычной ситуации защиты Эрланга) G>>>>(а я вроде как и не против Erlang был) T>>>Ты за этот Axum + .Net. То есть, поддерживаешь микрософтовскую пропаганду. G>>Улыбнуло. Разве кто-то говорит что надо срочно бросить все и писать на axum? T>Да вообще о нём забыть надо.
А то вдруг .NET задавит erlang и haskell.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, Gaperton, Вы писали:
G>>>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
AVK>>Но при этом ты доказываешь, что твои фокусы с файберами, которые магия куда как более хардкорная, это тоже хорошо
G>Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все.
Как в анекдоте:
-синхронная запись лучше, чем асинхронная
-чем лучше?
-чем асинхронная!
G>Данная "декларативность" его имхо затрудняет.
Данная декларативность не влияет на наблюдаемое поведение.
Здравствуйте, gandjustas, Вы писали:
T>>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля. G>Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода.
Обоснуешь? Тем, кто не писал, кажется, что это костыль для того, чтобы иметь возможность писать императивно, хотя бы через какие-то монады.
Я лично всё больше жалею, что такого способа нет в обычных языках.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Gaperton, Вы писали:
G>>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях. High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно
AVK>Тем не менее, Евгений мыслит в абсолютно правильном направлении — в МС рассматривают прежде всего реюз мультикора для ускорения рассчетов.
Не думаю что Axum поможет при ускорении расчетов. Для числомолотилки доожен быть прямолинейный код, который исполняется на всех доступных ядрах одновременно. Axum же дает возможность писать системы в которых взаимодействют множество разных потоков, при этом задействовать минимум ресурсов. При этом появляется небольщой оверхед, но сильно экономится на синхронизации.
Здравствуйте, VoidEx, Вы писали:
VE>Вот пока еррора нет, никакой функциональщины тоже нет. Она держится лишь на добром слове авторов соответствующих функций.
На всякий случай поясню мысль.
Сказать, что C# функциональный всё равно, что сказать, что Си (без const, да и наличие не помогает, вообще-то) достаточно поддерживает иммутабельность, никто же не мешает нам переменную не менять.
Однако это, очевидно, чушь.
Здравствуйте, thesz, Вы писали:
T>1) Откуда ты знаешь, что понимают в MS?
Все разработчики ведут блоги, есть записи на channel 9 обсуждений различных вещей.
Кроме того MS на начальном этапе развития новых идей создает community и прислушивается к его мнению.
Так что совсем не сложно узнать что понимают в MS.
Здравствуйте, thesz, Вы писали:
T>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.
И что? У лиспа пиписька длиннее стала?
T>Вопрос: какой порядок упрощения в функциональном подмножестве C#?
Встречный вопрос: что это меняет?
Хоть форум и называется философией, но абстрактно-теоретические рассуждения мало кому нужны.
Здравствуйте, gandjustas, Вы писали:
G>Не думаю что Axum поможет при ускорении расчетов.
То же предлагаешь обсудить свои ощущения?
G> Для числомолотилки доожен быть прямолинейный код, который исполняется на всех доступных ядрах одновременно.
Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, eao197, Вы писали:
E>Существует мнение, что с приходом массовых multicode машин под HPC будут попадать даже такие утилиты, как IrfanView и ACDSee. Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий.
Направление мысли правильное
E>В отличии от использования data-flow механизмов на агентах типа Axum-овских.
Вот вот.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, VoidEx, Вы писали:
VE>А где я требую отсутствие поддержки других стилей?
Ты? Без понятия. Но с предлагаемым подходом не только шарп не функциональный, но и F# с окамлом в ту же корзину, поскольку лямбду с побочными эффектами там, как два пальца об асфальт.
VE>Вот пока еррора нет, никакой функциональщины тоже нет.
Весьма спорно, но в контексте данного топика — непринципиально.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?
А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>>>, из чего следует, что это PR AVK>>Из того что ты пытаешься следует? Отличная логика. И прекрасная демонстрация того, что это все таки вера. T>"Что это PR" следует из минимальности нововведений в Axum.
Теперь осталось доказать "минимальности нововведений в Axum".
Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Не думаю что Axum поможет при ускорении расчетов. AVK>То же предлагаешь обсудить свои ощущения?
Тут видимо только этим и занимаются.
G>> Для числомолотилки доожен быть прямолинейный код, который исполняется на всех доступных ядрах одновременно.
AVK>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть.
Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Axum в этом не помощник, он как раз старается грузить минимум.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, AndrewVK, Вы писали:
AVK>>Таким образом он не попадает под определение "исключительно функциональный". Я об этом с самого начала говорил. А по тому, что по ссылке — попадает. VE>
VE>functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data
VE>Не can avoid, а avoids.
И сколько таких языков?
Какие из них были\есть mainstream?
Здравствуйте, gandjustas, Вы писали:
G>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Суть, к сожалению, все таки несколько меняется, и проблемы при HPC и работе с IO все таки несколько разные, особенно в плане акцентов. К примеру, грануляризация для IO почти по барабану, а для HPC — ключевой момент.
G>Axum в этом не помощник, он как раз старается грузить минимум.
Думаю, ты ошибаешься все же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, Gaperton, Вы писали:
G>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
Система была реал-тайм?
Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
Здравствуйте, eao197, Вы писали:
E>>>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
G>>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях.
E>Даже в области серверных приложений с требованиями 24x7 подход Erlang-а далеко не единственный.
Единственных подходов вообще не бывает. Их всегда пруд пруди. Я тебе сейчас не о подходе говорю, а о тех преимуществах, которые есть не подход, а свойства, и которые ты попытался отмести предыдущим постом.
А если говорить о твоем подходе в SObjectizer — он хуже по всем пунктам. Почему — я показал.
G>>High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно. И она достаточно уныла, чтобы не возникало такого желания.
E>Существует мнение, что с приходом массовых multicode машин под HPC будут попадать даже такие утилиты, как IrfanView и ACDSee.
Мнение можно иметь любое. Оно отличается тем, что его принципиально нельзя ни доказать, ни опровергнуть. Особенно если "мнение" относится к жонглированию терминами.
E>Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий. Какой толк от Erlang-а во внутренностях IrfanView (с горячей заменой кода, немутабельных данных, сопоставлении с образцом и принципом let it fail) я не представляю. В отличии от использования data-flow механизмов на агентах типа Axum-овских.
Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.
Здравствуйте, gandjustas, Вы писали:
G>>>>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
AVK>>>Но при этом ты доказываешь, что твои фокусы с файберами, которые магия куда как более хардкорная, это тоже хорошо
G>>Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все. G>Как в анекдоте: G>-синхронная запись лучше, чем асинхронная G>-чем лучше? G>-чем асинхронная!
Весьма глупый комментарий. Я это показал достаточно развернуто (рядом), с примерами кода, для тех, кто умеет читать, что написано. Умеешь — прочтешь.
G>>Данная "декларативность" его имхо затрудняет. G>Данная декларативность не влияет на наблюдаемое поведение.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
V>Система была реал-тайм?
soft-realtime.
V>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
V>Система была реал-тайм? V>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.
Здравствуйте, Gaperton, Вы писали:
V>>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев. G>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
Планировщик в современном Линуксе срабатывает за O(log N) времени — это даёт приятные фичи типа точного accounting'а и на практике работает как O(1), так как процессов не бывает особо много.
Здравствуйте, Gaperton, Вы писали:
G>Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.
Некоторые примтивы сложно перенести, типа неизменяемой кучи (для soft realtime GC). Ну и прерываемость тоже...
У меня есть персистентное желание сделать что-то типа Erlang'а, портировав Скалу под LLVM. Времени сейчас нет поглубже заняться только...
Здравствуйте, Gaperton, Вы писали:
G>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
Тебе же недоступна вся та информация, которой располагает ОС, так? Например, сотни твоих потоков ждут чего-то от ввода-вывода, откуда ты знаешь, кому давать квант? Разве что все вызовы АПИ оборачивать своими наворотами и плодить лишние примитивы синхронизации.
Здравствуйте, Gaperton, Вы писали:
G>А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.
В моей задаче насильно прерывать и не надо, но вот дать квант точно тому потоку, которому пришло сообщение — это я вижу лишь в ручной диспечеризации, которой доступна логика протокола.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
AVK>Суть, к сожалению, все таки несколько меняется, и проблемы при HPC и работе с IO все таки несколько разные, особенно в плане акцентов. К примеру, грануляризация для IO почти по барабану, а для HPC — ключевой момент.
Мы видимо о том же говорим разными словами.
G>>Axum в этом не помощник, он как раз старается грузить минимум. AVK>Думаю, ты ошибаешься все же.
Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически.
Здравствуйте, Gaperton, Вы писали:
G>>>Данная "декларативность" его имхо затрудняет. G>>Данная декларативность не влияет на наблюдаемое поведение.
G>Она влияет на поведение программы.
G>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке.
какая библиотека для создания агентов в net на данный момент есть?
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке. C>какая библиотека для создания агентов в net на данный момент есть?
CCR. http://www.microsoft.com/ccrdss/
G>Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически.
каким образом это достигается в PFX?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Библиотека для этого уже существует, а вот как раз поддржка агентов и изоляция на уровне языка только в разработке. C>>какая библиотека для создания агентов в net на данный момент есть?
вот на F# пример пинг-понга, вполне себе агентный:
#light
type Message = Finished | Msg of int * Message MailboxProcessor
let ping iters (outbox : Message MailboxProcessor) =
MailboxProcessor.Start(fun inbox ->
let rec loop n = async {
match n with
| 0 -> outbox.Post Finished
printfn "ping finished"
return ()
| _ -> outbox.Post <| Msg(n, inbox)
let! msg = inbox.Receive()
printfn "ping received pong"
return! loop(n-1)}
loop iters)
let pong() =
MailboxProcessor.Start(fun inbox ->
let rec loop () = async {
let! msg = inbox.Receive()
match msg with
| Finished ->
printfn "pong finished"
return ()
| Msg(n, outbox) ->
printfn "pong received ping"
outbox.Post <| Msg(n, inbox)
return! loop() }
loop())
ping 100 <| pong() |> ignore
System.Console.ReadLine() |> ignore
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Я вроде посмотрел все материалы по Axum, которые нашел. Не увидел способов задействовать все доступные ядра для вычислений. С PFX это жедается автоматически. C>каким образом это достигается в PFX?
В PFX парллелизм строится на задачах, выполнение которых раскидывается на все доступные ядра.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>CCR. http://www.microsoft.com/ccrdss/ C>агента покажешь на ней или отправишь к dss?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Ccr.Core;
namespace Agent
{
public class AdderAgent
{
DispatcherQueue _queue;
public Port<int> X { get; private set; }
public Port<int> Y { get; private set; }
public Port<int> Result { get; private set; }
public AdderAgent(DispatcherQueue queue)
{
_queue = queue;
X = new Port<int>();
Y = new Port<int>();
Result = new Port<int>();
Arbiter.Activate(_queue, Arbiter.JoinedReceive(true, X, Y, (x, y) => Result.Post(x + y)));
}
}
class Program
{
static void Main(string[] args)
{
using (Dispatcher dispatcher = new Dispatcher())
{
DispatcherQueue queue = new DispatcherQueue("queue", dispatcher);
var agent = new AdderAgent(queue);
agent.X.Post(1);
agent.Y.Post(2);
Arbiter.ExecuteToCompletion(queue, agent.Result.Receive(x => Console.WriteLine(x)));
Console.ReadLine();
}
}
}
}
Конечно для создания полноценной агентной системы нужно порты обернуть во что-нибудь чтобы контролировать направление порта.
Хотя не знаю насколько оправдано создание таких агентов без DSS.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>В PFX парллелизм строится на задачах, выполнение которых раскидывается на все доступные ядра. C>кто их раскидывает, в PFX свой шедулер?
Угу. В .NET 4.0 это будет встроенная возможность.
G>Конечно для создания полноценной агентной системы нужно порты обернуть во что-нибудь чтобы контролировать направление порта.
во-во, ну там в примерах еще и получше были
/// <summary>
/// Base type for all service messages. Defines a response PortSet used
/// by all message types.
/// </summary>public class ServiceOperation
{
public PortSet<string, Exception> ResponsePort = new PortSet<string, Exception>();
}
public class Stop : ServiceOperation
{
}
public class UpdateState : ServiceOperation
{
public string State;
}
public class GetState : ServiceOperation
{
}
/// <summary>
/// PortSet that defines which messages the services listens to
/// </summary>public class ServicePort : PortSet<Stop, UpdateState, GetState>
{
}
/// <summary>
/// Simple example of a CCR component that uses a PortSet to abstract
/// its API for message passing
/// </summary>public class SimpleService
{
ServicePort _mainPort;
DispatcherQueue _taskQueue;
string _state;
public static ServicePort Create(DispatcherQueue taskQueue)
{
var service = new SimpleService(taskQueue);
service.Initialize();
return service._mainPort;
}
private void Initialize()
{
// using the supplied taskQueue for scheduling, activate three
// persisted receivers, that will run concurrently to each other,
// one for each item type
Arbiter.Activate(_taskQueue,
Arbiter.Receive<UpdateState>(true, _mainPort, UpdateHandler),
Arbiter.Receive<GetState>(true, _mainPort, GetStateHandler)
);
}
private SimpleService(DispatcherQueue taskQueue)
{
// create PortSet instance used by external callers to post items
_mainPort = new ServicePort();
// cache dispatcher queue used to schedule tasks
_taskQueue = taskQueue;
}
void GetStateHandler(GetState get)
{
if (_state == null)
{
// To demonstrate a failure response,
// when state is null will post an exceptionget.ResponsePort.Post(new InvalidOperationException());
return;
}
// return the state as a message on the response portget.ResponsePort.Post(_state);
}
void UpdateHandler(UpdateState update)
{
// update state from field in the message
_state = update.State;
// as success result, post the state itself
update.ResponsePort.Post(_state);
}
}
G>Хотя не знаю насколько оправдано создание таких агентов без DSS.
+1 прада он за собой много чего тащит, и банально не удобен. Жду Dublin
Здравствуйте, eao197, Вы писали:
E>Я уже поднимал этот вопрос. И даже пытался представить, что может получиться при использовании Ruby в качестве host-языка для DSL. Вот, как тот же самый "более-менее" агент мог бы выглядеть в DSL.
E>Но самое удивительное для меня то, что многие заинтересованные в SObjectizer разработчики не хотят иметь внешних DSL. По разным причинам. Но категорически.
Странно, а как же народ пользуется IDL, всякими ASN.1, да и просто, не побоюсь этого слова, XML-based DSL? Декларативные вещи на декларативном DSL должны быть написаны, ИМХО.
Вообще, лично мне EDSL не по душе, т.к. не позволяют пользовать минимально достаточный синтаксис, навроде такого (практически от балды, не воспринимай всерьёз ):
Раза в 3 меньше писанины, если еще и префиксы для идентификаторов С++ напр. "msg_", "m_", "evt_" подать как аргумент командной строки генератора.
И сдается мне, что написать компилятор подобного "тупого" DSL на Ruby попроще будет, чем подготовить на нем же встроенный DSL. Даже если заказчики против, подобный тул сэкономит время на старте проекта, когда надо "накидать" кучу агентов. Еще поинт в том, что "сочные" описания — документация сама по себе.
И кстати, не факт, что заполнять таблицу по столбцам удобнее, повторяющиеся обработчики скорее будут для одного сообщения, поэтому может оказаться удобным после объявления сообщения тут же указать обработчиков (в духе описанного выше):
E>Поэтому в конце-концов и возникла идея о том, как можно сделать все то же самое средствами C++.
Тут есть неудобство в том, что внутренний класс не имеет доступа к приватным полям объемлющего. Например в C# такой доступ есть, и там эту идею реализовать было бы проще напрямую паттерном State, который несколько гибче навязанной табличной диспетчеризации. Просто в сильно разряженных столбцах (а таких полно у тебя) вычислить след. состояние куда проще, чем набивать пустышками таблицу.
T>>>>2) Использовать агенты в HPC — немного совсем малоэффективное решение. E>>>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями. T>>А чем они от него отличаются-то?
E>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами.
Проблемы уровня библиотеки в нормальном языке.
E>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.
T>>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля. G>Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода.
То, что ты описал, и есть монада IO. Вглядись.
T>>В нём не будет разделения типов выражений с эффектом и без. G>И зачем оно надо?
Для того, чтобы "иметь возможность писать императивный код там где надо и иметь возможность декларативно ограничивать запуск такого кода".
T>>Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом. G>Неизменяемые значения есть. Более того в составе Axum есть компилятор C# с какими-то эксперементалтными фичами, связанными как раз с иммутабельностью.
Ну, к 2012-му году, может быть, и дотянут.
Что для нормальных людей означает практическую невероятность. За три года можно добить до полностью рабочего состояния Agda2, тогда .Net окажется ненужным.
T>>>>Строгая типизация страдает. G>>>Чем страдает? T>>Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе). G>Ни разу не страдал от ухудшения проверок в .NET. Может пример адекватный приведешь?
Примем, что современный Хаскель и современный C# работают в улучшенной .Net, где ХАскель, всё-таки, работает.
А вот и пример: тип, параметризованный структурой данных.
Например, генератор XML деревьев, параметризованный схемой. data XMLTree xmlScheme where ...
На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#?
T>>Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка. G>Дык в Axum проверки более сильные, чем в C#. Так что про DSEL мимо кассы.
Значит, будет небезопасным использование C#/библиотек .Net в целом. Делов-то.
Это же палка о двух концах.
G>>>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? T>>>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться. G>>>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром. T>>Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом. G>Угу, сомневаюсь что в исследовательском проекте это все необходимо.
А могло оказаться совершенно бесплатно.
G>А если уж необходимо то есть F#.
Ты его использовал-то, хоть раз?
T>>Ты, вообще, HOF пользовался? G>что есть HOF?
Higher-order functions.
T>>>>Горячая замена кода. G>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо. T>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии. G>И что это меняет?
Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. Fault-tolerance у ней слабый и тп.
T>>Да вообще о нём забыть надо. G>А то вдруг .NET задавит erlang и haskell.
Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы.
Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением.
А я не люблю, когда людям не дают реализовать себя в полной мере.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении. G>И что? У лиспа пиписька длиннее стала?
Он стал удобней в работе.
T>>Вопрос: какой порядок упрощения в функциональном подмножестве C#? G>Встречный вопрос: что это меняет?
Простоту рассуждений о программах.
G>Хоть форум и называется философией, но абстрактно-теоретические рассуждения мало кому нужны.
Я прагматичен до мозга костей. Поэтому я идеалист.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше. G>Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?
Selective receive, если говорить только о параллельном программировании.
Но он помогает программированию в целом.
G>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
"Прозрачно" — это как?
T>>"Что это PR" следует из минимальности нововведений в Axum. G>Теперь осталось доказать "минимальности нововведений в Axum". G>Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.
А ты перечислил. Из совсем нового только dataflows. Всё остальное где-то уже было.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, vdimas, Вы писали:
V>Странно, а как же народ пользуется IDL, всякими ASN.1, да и просто, не побоюсь этого слова, XML-based DSL? Декларативные вещи на декларативном DSL должны быть написаны, ИМХО.
Ну вот, видимо исходя из такого опыта и не хотят.
V>И сдается мне, что написать компилятор подобного "тупого" DSL на Ruby попроще будет, чем подготовить на нем же встроенный DSL.
У меня получается наоборот. Встроенный DSL на Ruby делается гораздо быстрее. И если он не отдается широкой общественности, то так проще и дешевле.
<offtopic>
Вообще, после различных DSL я пришел к мнению, что для описаний лучше всего подходит Lisp/Curl/s-expression синтаксис. Поскольку при длительном использовании DSL его обязательно приходится расширять, да так, что заранее не предугадаешь. И оказывается, что ориентированный на теги синтаксис гораздо гибче в этом отношении, чем специально заточенный под предметную область синтаксис.
</offtopic>
V>Даже если заказчики против, подобный тул сэкономит время на старте проекта, когда надо "накидать" кучу агентов. Еще поинт в том, что "сочные" описания — документация сама по себе.
Вот поэтому мне и нравятся отдельные описания содержимого агентов -- тогда только по ним уже можно понять значительную часть логики его работы. А вот если приходится разбираться по разбросанным в коде секциям receive (как в примерах ScalaActors), то это уже менее удобно, имхо.
V>И кстати, не факт, что заполнять таблицу по столбцам удобнее, повторяющиеся обработчики скорее будут для одного сообщения, поэтому может оказаться удобным после объявления сообщения тут же указать обработчиков (в духе описанного выше): V>
Я с разными способами описания экспериментировал. Наиболее читабельная и, в тоже время, строгая форма получается именно в приведенном мной виде. Тогда при добавлении нового сообщения сразу легко определить, в каком состоянии его еще не обработали. Для этого даже никаких специализированных инструментов не нужно. А вот в предложенной тобой записи при изменении списка состояний/событий сложнее вносить правки в описания агентов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
G>>А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.
V>В моей задаче насильно прерывать и не надо, но вот дать квант точно тому потоку, которому пришло сообщение — это я вижу лишь в ручной диспечеризации, которой доступна логика протокола.
В чем проблема-то, я не пойму? Шедулер должен знать состояние всех очередей, и все.
Здравствуйте, thesz, Вы писали:
T>>>>>2) Использовать агенты в HPC — немного совсем малоэффективное решение. E>>>>Агенты в HPC вполне могут заменить старый добрый MPI более современными решениями. T>>>А чем они от него отличаются-то?
E>>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами.
T>Проблемы уровня библиотеки в нормальном языке.
Что-то мне подсказывает, что под нормальным языком для тебя является только Haskell.
Но мы несколько ушли в сторону. Мне интересно, считаешь ли ты, что MPI для HPC эффективное решение? И если да, то как по-твоему, если вместо MPI будут агенты, то почему агенты в HPC станут малоэффективным решением?
E>>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.
T>http://www.pgroup.com/products/workindex.htm
И что я по этой ссылке должен увидеть? То, что в природе существует "OpenMP and MPI parallel debugger/profiler"?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали: T>Каким образом в Схеме могут изменить значение, связанное с x в функции g? Не саму "переменную" x, а значение, которое мы передадим в h.
Через set! (set-car!, set-cdr! и т.п.).
(define (h x gx)
(display gx)(display x)(newline))
(define (f x)
(h x ((lambda (y) (set-cdr! x y) "This is a scheme longcat: ") x)))
(f '(cat))
Здравствуйте, thesz, Вы писали:
T>>>Потому, что в нём никогда (практически никогда) не будет чего-то типа монады IO Хаскеля. G>>Монада IO в хаскеле не от хорошей жизни. ИМХО язык должен давать возможность писать имеративный код там где надо и иметь возвожность декларативно ограничивать запуск такого кода. T>То, что ты описал, и есть монада IO. Вглядись.
T>>>В нём не будет разделения типов выражений с эффектом и без. G>>И зачем оно надо? T>Для того, чтобы "иметь возможность писать императивный код там где надо и иметь возможность декларативно ограничивать запуск такого кода".
Хм... я бы предпочел что-то типа модификатора pure на функции. (как const в C++)
Хотя о таком применении монад в хаскеле я и не догадывался.. Наверное потому что хаскель не знаю.
T>>>Да и неизменяемых значений тоже не будет. А без них не будет и сравнения с образцом. G>>Неизменяемые значения есть. Более того в составе Axum есть компилятор C# с какими-то эксперементалтными фичами, связанными как раз с иммутабельностью. T>Ну, к 2012-му году, может быть, и дотянут.
Может быть. Я бы на более раннее сроки и не рассчитвал.
Хотя возможно в 2010 году появится более-менее стабильная версия Axum, которая обрастет всеми необходимыми фичами.
T>>>>>Строгая типизация страдает. G>>>>Чем страдает? T>>>Ухудшением проверок. Неужто непонятно? У тебя часть на строготипизированном ЯП, другая на менее строготипизированном ЯП (вообще на скриптовом языке, как в пределе). G>>Ни разу не страдал от ухудшения проверок в .NET. Может пример адекватный приведешь?
T>Примем, что современный Хаскель и современный C# работают в улучшенной .Net, где ХАскель, всё-таки, работает. T>А вот и пример: тип, параметризованный структурой данных. T>Например, генератор XML деревьев, параметризованный схемой. data XMLTree xmlScheme where ... T>На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#?
generics?
T>>>Чем и хороши DSeL, что они пользуются всей мощью проверок типов базового языка. G>>Дык в Axum проверки более сильные, чем в C#. Так что про DSEL мимо кассы. T>Значит, будет небезопасным использование C#/библиотек .Net в целом. Делов-то.
Ты неправ, уже сейчас прога на Axum не скомпилится, елси использование .NET библиотек будет опасным. Правда я не знаю как оно там работает сейчас.
T>Это же палка о двух концах.
Не факт, в компиляторе можно много чего ограничить для получения адекватного результата, в отличие от DSEL.
Ведь хаскель тоже работат на вдоску имепративном CPU с состоянием.
G>>>>>>Кстати, есть примеры удачного создания агентной модели как DSEL в существующем языке? T>>>>>Нет. Попробуй написать на Хаскеле, должно хорошо получиться. G>>>>Зачем писать в хаскеле агентную систему, если она уже есть в axum, со всем необходимым сахаром. T>>>Но без удобных вещей типа синтаксиса, системы типов, чистого кода и сравнения с образцом. G>>Угу, сомневаюсь что в исследовательском проекте это все необходимо.
T>А могло оказаться совершенно бесплатно.
Каким образом?
G>>А если уж необходимо то есть F#. T>Ты его использовал-то, хоть раз?
Много раз.
T>>>Ты, вообще, HOF пользовался? G>>что есть HOF? T>Higher-order functions.
Я предпочитаю русское буквосочетание — ФВП.
T>>>>>Горячая замена кода. G>>>>Горячая замена кода есть и в .NET, только больше приседаний для нее надо. T>>>И стратегия замены только одна — поддерживаемая .Net. Сравни с Эрлангом, где только в тезисе Джо Армстронга описаны две стратегии. G>>И что это меняет?
T>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима.
"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET.
По твоей логике можно haskell везде запихнуть, только я софта на хаскеле не видел вообще.
T>Fault-tolerance у ней слабый и тп.
В чем это выражается? А то я вижну только одну цепочку рассуждений "нету средств как в Erlang -> Fault-tolerance слабый", почему нельзя сделать сильный Fault-tolerance другими средствами?
T>>>Да вообще о нём забыть надо. G>>А то вдруг .NET задавит erlang и haskell. T>Меня больше волнует количество работы у людей, с .Net связанных. Оно превышает разумные пределы.
Это же хорошо, люди деньги зарабатывают
Есть предложения как уменьшить количество работы?
T>Это мешает им заниматься самообразованием, хотя с помощью (само)образования можно увеличить свой уровень на 50%. Из среднего человека стать гением.
Странно. Как раз среда типа .NET, которая предлагает совершенно разные подходы к разработке, выраженные в разных языках и фреймворках, дает гораздо больше возможностей для развития, чем другие среды. Причем нету необходимости изучать что-то вне конкретного языка или платформы, так как база общая.
Кромем того можно изучение чего-то нового совмещать с основной работой.
Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.
T>А я не люблю, когда людям не дают реализовать себя в полной мере.
Аналогично.
Здравствуйте, thesz, Вы писали:
T>>>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше. G>>Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?
T>Selective receive, если говорить только о параллельном программировании.
В Axum подобная фича реализуется разными портами, если я вообще правильно понял о чем речь.
T>Но он помогает программированию в целом.
Не спорю. Вопрос в том насколько отсуствие ПМ критично для программирования в целом. Практика показывает что некритично.
G>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность? T>"Прозрачно" — это как?
Ну так что программисту не надо ничего писать чтобы несколько "проснувшихся" агентов одновременно работали на нескольких ядрах.
T>>>"Что это PR" следует из минимальности нововведений в Axum. G>>Теперь осталось доказать "минимальности нововведений в Axum". G>>Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.
T>А ты перечислил. Из совсем нового только dataflows. Всё остальное где-то уже было.
Ну там еще много много вчего попмио dataflows, явная изоляция с помощью domain. reader и writer агенты для синхронизации доступа к разделяемым данным.
И множесто боле мелких фишек.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, thesz, Вы писали:
G>>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность? T>>"Прозрачно" — это как? C>Некоторые лёгкие процессы магически превращаются в реальные процессы, работающие на своём ядре.
Не, такой хардкорной магии в Axum нету. Там просто тредпул по количеству доступных ядер, шедулер запускает все агенты в доступных потоках.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
G>>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность? T>>"Прозрачно" — это как? G>Ну так что программисту не надо ничего писать чтобы несколько "проснувшихся" агентов одновременно работали на нескольких ядрах.
ну дак SMP давно в эрланге есть, некоторые издержки на многоядерность, конечно, есть, но их всё меньше, да и где их нет?
Здравствуйте, gandjustas, Вы писали:
T>>Fault-tolerance у ней слабый и тп. G>В чем это выражается? А то я вижну только одну цепочку рассуждений "нету средств как в Erlang -> Fault-tolerance слабый", почему нельзя сделать сильный Fault-tolerance другими средствами?
Ой, ё. Какой наивный вопрос!
G>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.
E>>>Если речь об Axum, то там, насколько я могу судить, на уровне языка декларируются контракты между агентами. T>>Проблемы уровня библиотеки в нормальном языке. E>Что-то мне подсказывает, что под нормальным языком для тебя является только Haskell.
Что могло натолкнуть тебя на эту мысль? Где я прокололся?
E>Но мы несколько ушли в сторону. Мне интересно, считаешь ли ты, что MPI для HPC эффективное решение? И если да, то как по-твоему, если вместо MPI будут агенты, то почему агенты в HPC станут малоэффективным решением?
Ну, я считаю идеальным решением динамический поток данных, это такой ультимативный вариант посылки сообщений без состояния вообще.
MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах.
E>>>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.
T>>http://www.pgroup.com/products/workindex.htm
E>И что я по этой ссылке должен увидеть? То, что в природе существует "OpenMP and MPI parallel debugger/profiler"?
Автоматическое распараллеливание программ для MPI.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Начинать знакомство с параллельным программированием, имхо, лучше было с вот таких статей, а не с PFX, CCR и Axum: E>Introduction to Parallel Computing: Part 1 E>Introduction to Parallel Computing: Part 2 E>(ну и далее по ссылкам).
Это теория, а как оно делается на практике — совершенно другой вопрос.
T>>Каким образом в Схеме могут изменить значение, связанное с x в функции g? Не саму "переменную" x, а значение, которое мы передадим в h.
MC>Через set! (set-car!, set-cdr! и т.п.). MC>
MC>;(define (h x gx)
MC>; (display gx)(display x)(newline))
MC>;(define (f x)
MC>; (h x ((lambda (y) (set-cdr! x y) "This is a scheme longcat: ") x)))
MC>;
Здесь у тебя ошибка. для set-cdr нужна переменная, вот ты и используешь x. в теле g переменная x недоступна, доступно только значение.
MC>
MC>;(f '(cat))
MC>;
Вот мой вариант (бляха муха, я теперь ещё и Лисп теперь знаю лучше, чем мне бы хотелось):
(define (h x gx)
(display gx)(display x)(newline))
(define (g x)
set-cdr! x '(a b c))
(define (f1 x)
(h x (g x)))
(define (f2 x)
(h (g x) x))
(f1 '(cat dog))
(f2 '(cat dog))
Вывод:
(a b c)(cat dog)
(cat dog)(a b c)
То есть, значение x в f не изменилось.
Чтд.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении. G>>>И что? У лиспа пиписька длиннее стала? T>>Он стал удобней в работе. G>Чем?
Тем, что рассуждений для написания программы теперь требуется меньше.
T>>>>Вопрос: какой порядок упрощения в функциональном подмножестве C#? G>>>Встречный вопрос: что это меняет? T>>Простоту рассуждений о программах. G>Зачем рассуждать о программах?
Для их понимания. Для уменьшения количества ошибок.
Ты с какой луны свалился, что такие вопросы задаёшь в программерском форуме?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Selective receive, если говорить только о параллельном программировании. G>В Axum подобная фича реализуется разными портами, если я вообще правильно понял о чем речь.
Да, согласен.
Selective receive с обработкой всех сообщений в конце (сравнение с _ в конце всех сравнений) интересна тем, что не даёт возможности накапливаться сообщениям в очереди. С каналами такое возможно: мы можем "забыть" о чтении из одного из каналов.
T>>Но он помогает программированию в целом. G>Не спорю. Вопрос в том насколько отсуствие ПМ критично для программирования в целом. Практика показывает что некритично.
Моя практика говорит ровно об обратном.
G>>>А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность? T>>"Прозрачно" — это как? G>Ну так что программисту не надо ничего писать чтобы несколько "проснувшихся" агентов одновременно работали на нескольких ядрах.
Наверняка умеет. Вроде, мне про это защитники Эрланга говорили.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Вот мой вариант (бляха муха, я теперь ещё и Лисп теперь знаю лучше, чем мне бы хотелось): T>
T>;(define (h x gx)
T>; (display gx)(display x)(newline))
T>;(define (g x)
T>; set-cdr! x '(a b c))
T>;(define (f1 x)
T>; (h x (g x)))
T>;(define (f2 x)
T>; (h (g x) x))
T>;(f1 '(cat dog))
T>;(f2 '(cat dog))
T>;
См выделенное. Функцию set-cdr! стоит все-таки вызвать, иначе g всегда будет возвращать '(a b c), ничего при этом не делая. Если это опечатка при копипасте в пост, то что за имплементация scheme у тебя?
T>Здесь у тебя ошибка. для set-cdr нужна переменная, вот ты и используешь x. в теле g переменная x недоступна, доступно только значение.
Ок
(define (h x gx)
(display gx)(display x)(newline))
(define (g x)
(set-cdr! x x)
"This is a scheme longcat: ")
(define (f x)
(h x (g x)))
(f '(cat))
В chicken scheme и plt (в режиме r5rs) этот код работает так же, как и мой предыдущий пример, т.е. cons-пара всегда передается по ссылке. Но вообще, я плохо помню нюансы модели памяти в scheme — надо будет полистать стандарт.
Здравствуйте, thesz, Вы писали:
T>>>Проблемы уровня библиотеки в нормальном языке. E>>Что-то мне подсказывает, что под нормальным языком для тебя является только Haskell.
T>Что могло натолкнуть тебя на эту мысль? Где я прокололся?
Достаточно почитать (даже по диагонали) твои сообщения здесь и в livejournal
T>MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах.
Тогда, надо полагать, PVM еще лучше MPI, поскольку существует еще дольше. А Java лучше .NET. А Oberon лучше Java...
E>>>>Тогда как в MPI сборкой/разборкой сообщений программист занимается вручную. Соответственно, в MPI накосячить гораздо проще и косяки эти будут вылезать в run-time.
T>>>http://www.pgroup.com/products/workindex.htm
E>>И что я по этой ссылке должен увидеть? То, что в природе существует "OpenMP and MPI parallel debugger/profiler"?
T>Автоматическое распараллеливание программ для MPI.
Дай все-таки точную ссылку, поскольку я пока вижу:
PGF95™ native OpenMP and auto-parallel Fortran 90/95 compiler
PGF77® native OpenMP and auto-parallel FORTRAN 77 compiler
PGF95™ native OpenMP and auto-parallel Fortran 90/95 compiler
PGF77® native OpenMP and auto-parallel FORTRAN 77 compiler
Threads-based auto-parallelization using both PGF77 and PGF95
Threads-based auto-parallelization of FOR loops in PGCC and PGC++
Full native OpenMP parallelization directives in PGF77 and PGF95
Full native OpenMP parallelization pragmas in PGCC and PGC++
И ни слова об автоматическом распараллеливании MPI. Что и не удивительно, т.к. автоматическое распараллеливание и MPI -- это, имхо, взаимоисключающие подходы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
T>>>На современном Хаскеле я могу написать такое (ну, почти), как мне использовать это в современном C#? G>>generics? T>Попробуй. Если я ещё и доказательства прикручу в виде типов классов, то никакие generics не спасут.
Ну прям интересно, давай конкретно задачу, а то про генератор xml не понял.
T>>>Это же палка о двух концах. G>>Не факт, в компиляторе можно много чего ограничить для получения адекватного результата, в отличие от DSEL. T>Вопрос простоты. Большое количество проверок можно получить без компилятора, если система типов достаточно мощна.
Возможно. Может быть это будет даже иметь значение если бы я разрабатывал Axum. С позиции пользователя Axum мне как-то все равно.
T>>>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. G>>"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET. T>Она такая по построению.
Доказательства? "Не похоже на haskell" за доказательство не катит.
G>>По твоей логике можно haskell везде запихнуть, только я софта на хаскеле не видел вообще. T>Во, куда скатились. Круто! А про императивный CPU так вообще отпад. T>Это аргумент середины 70-х про языки высокого уровня.
Те агрументы, которые ты применяешь против .NET можно с таким же успеом применить против множества высокоуровневых языков, в том числе Erlang\Haskell\LanguageOfYourChoice.
G>>Есть предложения как уменьшить количество работы? T>Головой больше думать. Не делать ненужной работы.
Общие слова.
T>Не выбирать платформы и языки, где нужна ненужная работа.
Ненужная работа моет сильно зависеть от контекста. Кроме того изучение кардинально новых языко\платформ\подходов к разработке может само быть ненужной работой, а также может привести к ненужной работе в виде переписывания существующих решений на новом языке.
Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы?
G>>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях.
T>Уверяю тебя, ты всё равно ничего не знаешь про ФП, про скриптовые языки и про параллельное программирование.
Смелое утверждение.
T>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>У тебя этого под рукой нет.
Ты так говоришь как-будто нету других способов достигнуть такой же легкости.
T>Ты не писал большой проект на скриптовом языке.
Слава богу.
T>Ты знаешь о параллельном программировании только то, что в MS сочли нужным тебе показать.
Я не только MSDN читаю
Здравствуйте, thesz, Вы писали:
T>>>>>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении. G>>>>И что? У лиспа пиписька длиннее стала? T>>>Он стал удобней в работе. G>>Чем? T>Тем, что рассуждений для написания программы теперь требуется меньше.
Каких рассудений?
T>>>>>Вопрос: какой порядок упрощения в функциональном подмножестве C#? G>>>>Встречный вопрос: что это меняет? T>>>Простоту рассуждений о программах. G>>Зачем рассуждать о программах? T>Для их понимания. Для уменьшения количества ошибок.
Как порядок упрощения в функциональном подмножестве C# помоет пониманию и уменьшению количества ошибок?
T>Ты с какой луны свалился, что такие вопросы задаёшь в программерском форуме?
Че-то это пахнет сильно абстрактной теорией.
Здравствуйте, thesz, Вы писали:
T>>>Но он помогает программированию в целом. G>>Не спорю. Вопрос в том насколько отсуствие ПМ критично для программирования в целом. Практика показывает что некритично. T>Моя практика говорит ровно об обратном.
Ну это только твоя практика.
T>>MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах. E>Тогда, надо полагать, PVM еще лучше MPI, поскольку существует еще дольше. А Java лучше .NET. А Oberon лучше Java...
Агенты ничем от MPI не отличаются, за исключением отсутствия стандарта.
E>И ни слова об автоматическом распараллеливании MPI. Что и не удивительно, т.к. автоматическое распараллеливание и MPI -- это, имхо, взаимоисключающие подходы.
Это OpenMP -> MPI, а для OpenMP автоматическое распараллеливание существует.
В принципе, товарищи из Майкрософт пытаются облегчить перенос последовательных программ на параллельные системы, это видно по приводимым здесь примерам кода.
С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Упоминание об ангажированности не переход на личности.
Да нет, это именно он самый и есть.
T> Ангажированность не свойство личности, это свойство позиции, занимаемой личностью.
Вот вот, личностью.
T>>> Ангажированность не свойство личности. Это может быть следствием заблуждений. AVK>>Здесь не обсуждаются мои заблуждения.
T>Оба-на!
T>Да на всём RSDN только и делают, что обсуждают чьи-то заблуждения.
Это еще один демагогический прием.
AVK>>Потому что у меня есть кое какая информация, которой я здесь поделиться, к сожалению, не могу, NDA.
T>Ну, так и не делись. Лучше всего вообще.
А это уже не тебе указывать.
T>А то только домыслы и слухи порождаешь.
Ну, те кто меня знает, в курсе того с какой вероятностью мои источники выдают верную информацию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
T>>Попробуй. Если я ещё и доказательства прикручу в виде типов классов, то никакие generics не спасут. G>Ну прям интересно, давай конкретно задачу, а то про генератор xml не понял.
То, чем я на выходных занимался:
{-# LANGUAGE EmptyDataDecls, GADTs, PatternSignatures, ScopedTypeVariables #-}
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, FunctionalDependencies #-}
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
-------------------------------------------------------------------------------
-- Type-level arithmetic.class Nat a where
fromNat :: a -> Int
data Z
data S n
instance Nat Z where
fromNat _ = 0
instance Nat n => Nat (S n) where
fromNat sn = 1+fromNat n
where
nsn :: S n -> n
nsn = undefined
n = nsn sn
class (Nat a, Nat b, Nat r) => Plus a b r | a b -> r, a r -> b
instance Nat b => Plus Z b b
instance (Nat a, Nat b, Nat r, Plus a b r) => Plus (S a) b (S r)
natPlus :: (Nat a, Nat b, Nat r, Plus a b r) => a -> b -> r; natPlus = undefined
class GE a b -- | a -> b, b -> ainstance GE Z Z
instance GE (S a) Z
instance GE a b => GE (S a) (S b)
type ONE = S Z
type TWO = S (S Z)
type THREE = S TWO
type FOUR = S THREE
type EIGHT = S (S (S (S FOUR)))
-------------------------------------------------------------------------------
-- Buses and netlist elements.data Bus size = Bus Int
type BitBus = Bus ONE
busSize :: Bus size -> size; busSize = undefined
type Netlist = [NetlistElem]
data NetlistElem where
Join :: (Nat sa, Nat sb, Plus sa sb sr)
=> Bus sa -> Bus sb -> Bus sr -> NetlistElem
Split :: (Nat high, Nat low, Nat big, Plus high low hl, GE big hl)
=> Bus big -> Bus high -> Bus low -> NetlistElem
Есть операции над шинами в схемах-нетлистах: Join — из двух шин получить одну суммарного размера, — и Split — из большей шины получить две меньших. С проверкой размерности на этапе компиляции, то есть, я не смогу разбить Bus TWO на Bus THREE и Bus ONE.
Запиши это на generics.
T>>Вопрос простоты. Большое количество проверок можно получить без компилятора, если система типов достаточно мощна. G>Возможно. Может быть это будет даже иметь значение если бы я разрабатывал Axum. С позиции пользователя Axum мне как-то все равно.
До тех пор, пока не пришло время на нём писать.
T>>>>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. G>>>"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET. T>>Она такая по построению. G>Доказательства? "Не похоже на haskell" за доказательство не катит.
В сети мне не встречались ограничения на дизайн .Net. Не подкинешь ссылку? Я имею в виду именно саму .Net, а не написание программ под неё. Про Эрланг это описано в диссертации Джо Армстронга, про Haskell — в History of Haskell. А про .Net такого нет (пардон за каламбур).
Вот про .Net такое будет, там всё видно будет.
G>>>Есть предложения как уменьшить количество работы? T>>Головой больше думать. Не делать ненужной работы. G>Общие слова.
Именно.
Вот, например, тесты — когда это нужная работа?
T>>Не выбирать платформы и языки, где нужна ненужная работа. G>Ненужная работа моет сильно зависеть от контекста. Кроме того изучение кардинально новых языко\платформ\подходов к разработке может само быть ненужной работой, а также может привести к ненужной работе в виде переписывания существующих решений на новом языке.
Надо уметь изучать только то, что нужно.
G>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы?
Кардинально уменьшит количество тестов.
G>>>Я например в ФП разобрался благодаря C# и F#, хрен бы у меня время нашлось для изучения OCaml с нуля. Теперь скриптовые языки изучаю, причем у меня нету необходимости изучать немалые фреймворки python или ruby чтобы писать на них части своих программ. Посмотрев библиотеки PFX, CCR\DSS и Axum я теперь немного понимаю в параллельном программировании во всех его проявлениях. T>>Уверяю тебя, ты всё равно ничего не знаешь про ФП, про скриптовые языки и про параллельное программирование. G>Смелое утверждение.
Мне достаточно, что ты знаешь меньше меня в области применения ФП. А я знаю достаточно мало.
T>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>У тебя этого под рукой нет. G>Ты так говоришь как-будто нету других способов достигнуть такой же легкости.
Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review.
T>>Ты не писал большой проект на скриптовом языке. G>Слава богу.
Мой критерий уверенного знания языка: ты должен оптимизировать большую программу по скорости.
Без большого проекта это невозможно.
T>>Ты знаешь о параллельном программировании только то, что в MS сочли нужным тебе показать. G>Я не только MSDN читаю
Ещё и RSDN.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
С помощью троек Хоара можно конструировать программы и даже получать очень нетривиальные алгоритмы (правда, нужен опыт).
G>>>Зачем рассуждать о программах? T>>Для их понимания. Для уменьшения количества ошибок. G>Как порядок упрощения в функциональном подмножестве C# помоет пониманию и уменьшению количества ошибок?
Плотность ошибок в рассуждениях, я думаю, не сильно колеблется в зависимости от их числа. Косввенно это можно подтвердить, что плотность ошибок на строку коду (выражение программы) тоже величина достаточно постоянная, а на строку кода мы делаем примерно одинаковое число выводов.
Чем меньше рассуждений надо для реализации концепции, тем меньше ошибок мы внесём в эту самую реализацию.
T>>Ты с какой луны свалился, что такие вопросы задаёшь в программерском форуме? G>Че-то это пахнет сильно абстрактной теорией.
T>>>>Но он помогает программированию в целом. G>>>Не спорю. Вопрос в том насколько отсуствие ПМ критично для программирования в целом. Практика показывает что некритично. T>>Моя практика говорит ровно об обратном. G>Ну это только твоя практика.
"Тем же концом и вас" (С) народная мудрость
Мой вывод подтверждает не только моя практика.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
IT>"Не такое уж и извратство" и "Применять вполне можно" может характеризовать какую-нибудь второстепенную фичу какой-нибудь малоиспользуемой библиотеки, но никак не одну из основных конструкций языка.
Основную конструкцию ломать уже поздно. Тебе шашечки или ехать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>>>Попробуй. Если я ещё и доказательства прикручу в виде типов классов, то никакие generics не спасут. G>>Ну прям интересно, давай конкретно задачу, а то про генератор xml не понял.
T>То, чем я на выходных занимался: T>
T>--ушел изучать хаскел чтобы понять что там написано--
T>>>>>Многое. Сейчас считается, что .Net можно запихнуть всюду, а оказывается, что она мало, где применима. G>>>>"Можно" не означает "целесообразно". Мало где применима чаще всего означает низкий уровень пихальщиков .NET. T>>>Она такая по построению. G>>Доказательства? "Не похоже на haskell" за доказательство не катит.
T>В сети мне не встречались ограничения на дизайн .Net. Не подкинешь ссылку? Я имею в виду именно саму .Net, а не написание программ под неё. Про Эрланг это описано в диссертации Джо Армстронга, про Haskell — в History of Haskell. А про .Net такого нет (пардон за каламбур). T>Вот про .Net такое будет, там всё видно будет.
Дык твой тезис — тебе и доказывать.
T>Вот, например, тесты — когда это нужная работа?
Много от чего зависит. Например в TDD тесты — средство дизайна кода.
G>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>Кардинально уменьшит количество тестов.
Я использую TDD, от чего произойдет уменьшение количества тестов?
T>>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>>У тебя этого под рукой нет. G>>Ты так говоришь как-будто нету других способов достигнуть такой же легкости.
T>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review.
При условии хорошей автоматизации "других областей" это проблемой не является.
T>>>Ты не писал большой проект на скриптовом языке. G>>Слава богу. T>Мой критерий уверенного знания языка: ты должен оптимизировать большую программу по скорости. T>Без большого проекта это невозможно.
А теперь критерий большого проекта?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>А теперь критерий большого проекта?
E>Более 100KLOC
На моей первой работе как раз был такой проект. Сейчас я знаю что тоже самое на .NET можно повторить с 10-кратным уменьшением объема.
Так что размер — совсем необъективный поазатель.
T>>>>MPI лучше, чем агенты, поскольку дольше существует. Поэтому он лучше отработан на кластерах. E>>>Тогда, надо полагать, PVM еще лучше MPI, поскольку существует еще дольше. А Java лучше .NET. А Oberon лучше Java... T>>Агенты ничем от MPI не отличаются, за исключением отсутствия стандарта. E>Тогда на основании чего было сделано утверждение, что
Использовать агенты в HPC — немного совсем малоэффективное решение.
E>?
За счёт малой проработанности и отсутствия стандарта.
Вот придумал ты агентов, тебе они показались удобными, лучше, чем MPI. Ты уверен, что на них лягут любые HPC задачи?
Лично я уверен, что нет. Даже большинство не ляжет. А на MPI ляжет, поскольку за ней, пока, опыт.
E>>>И ни слова об автоматическом распараллеливании MPI. Что и не удивительно, т.к. автоматическое распараллеливание и MPI -- это, имхо, взаимоисключающие подходы.
T>>"Let me see..." (C) The Incredibles T>>
E>Therefore, we refer to our scheme as partial-replication. Data replication comes at the cost of limiting the data scalability of programs that is, programs will not be able to handle n-times larger data sets on n processors.
E>А ведь MPI как раз и рулит в области больших вычислений на сотнях и более узлов.
Ну, это преодолимо. Там всего ещё один этап анализа нужен.
T>> а для OpenMP автоматическое распараллеливание существует. E>OpenMP изначально предназначалась для того, чтобы компилятор/runtime распараллеливал те куски, на которые указал программист. Но распараллеливал автоматически. Однако, речь сейчас не об OpenMP.
OpenMP Только переходник. И ещё: есть алгоритмы автоматического вставления прагм OpenMP.
T>>В принципе, товарищи из Майкрософт пытаются облегчить перенос последовательных программ на параллельные системы, это видно по приводимым здесь примерам кода.
T>>С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот. E>Ну конечно, пусть MS потратит еще десяток-другой лет на поиск хороших решений для автоматического распараллеливания кода. У них же денег много. А еще пусть Haskell вместо C# продвигает, ведь это более прогрессивный подход
Ты серьёзно так думаешь? Очень удивительно слышать от тебя такие слова. Прямо бальзам на душу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>--ушел изучать хаскел чтобы понять что там написано--
G>
Вот ссылка по теме: http://okmij.org/ftp/Haskell/number-parameterized-types.html
T>>В сети мне не встречались ограничения на дизайн .Net. Не подкинешь ссылку? Я имею в виду именно саму .Net, а не написание программ под неё. Про Эрланг это описано в диссертации Джо Армстронга, про Haskell — в History of Haskell. А про .Net такого нет (пардон за каламбур). T>>Вот про .Net такое будет, там всё видно будет. G>Дык твой тезис — тебе и доказывать.
Да. Пожалуй, тут я оставлю позиции.
T>>Вот, например, тесты — когда это нужная работа? G>Много от чего зависит. Например в TDD тесты — средство дизайна кода.
Это хорошо?
http://grundik.livejournal.com/208883.html
G>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>Кардинально уменьшит количество тестов. G>Я использую TDD, от чего произойдет уменьшение количества тестов?
Уменьшение тестов произойдёт от увеличения проверок.
Типы Хаскеля закрыты (closed), поэтому ты можешь перечислить все интересные случаи на входе.
Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет.
Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна.
В общей сумме получится, что у тебя есть разработка функций и функциональные тесты программы в целом.
Функциональных тестов получится много меньше.
Надо, что ли, курс какой создать по этому поводу.
T>>>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>>>У тебя этого под рукой нет. G>>>Ты так говоришь как-будто нету других способов достигнуть такой же легкости. T>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>При условии хорошей автоматизации "других областей" это проблемой не является.
Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck).
T>>>>Ты не писал большой проект на скриптовом языке. G>>>Слава богу. T>>Мой критерий уверенного знания языка: ты должен оптимизировать большую программу по скорости. T>>Без большого проекта это невозможно. G>А теперь критерий большого проекта?
2+ разработчика, 6+ месяцев работы. Там получится достаточно чужого кода, проблемы с которым и придётся выяснять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>За счёт малой проработанности
Понятно.
T>и отсутствия стандарта.
Отсутствие стандарта сложно считать сколь-нибудь серьезным препятствием. Например, у C++ до сих пор нет компиляторов, которые бы на 100% поддерживали стандарт 1998-го года (уж не знаю, насколько всерьез можно воспринимать Comeau). Для Java/Python/Ruby вообще никогда не было стандарта. А вот стандарт ODMG-93 был, только мертворожденный.
T>Вот придумал ты агентов, тебе они показались удобными, лучше, чем MPI. Ты уверен, что на них лягут любые HPC задачи?
Те агенты, которыми пользуюсь я, вообще для HPC не предназначены. А вот что получится из Axum и что попадает потом в C# еще не известно.
T>>>С моей точки зрения, это не очень хорошо, поскольку разработчику даётся ещё одно средство прострелить себе ногу. Лучше бы они занялись автоматическим анализом и преобразованиями, чем вот так вот. E>>Ну конечно, пусть MS потратит еще десяток-другой лет на поиск хороших решений для автоматического распараллеливания кода. У них же денег много. А еще пусть Haskell вместо C# продвигает, ведь это более прогрессивный подход
T>Ты серьёзно так думаешь?
Нет, это сарказм.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
IT>>"Не такое уж и извратство" и "Применять вполне можно" может характеризовать какую-нибудь второстепенную фичу какой-нибудь малоиспользуемой библиотеки, но никак не одну из основных конструкций языка.
AVK>Основную конструкцию ломать уже поздно. Тебе шашечки или ехать?
Да там не конструкцию, там весь язык ломать нужно. Конструкция — это так, вершина айсберга.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>>При условии хорошей автоматизации "других областей" это проблемой не является.
T>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck).
Вот тут вопрос...
Эрланг же вроде как не совсем чтоб сильно чистый (процессы, ИО и т.п.), но QuickCheck вроде как интенсивно используют.
Правда тут хрен знает как рассуждать, т.к. QuviQ QuickCheck — вещь закрытая
VE>Не can avoid, а avoids. Можно ли написать на C# такую лямбду, чтобы она _гарантированно_ avoids state and mutable data? До тех пор, пока за это ответственнен автор лямбды и компилятор это не проверяет, функциональным языком будет и Паскаль, где никто не мешает мне написать function foo(x) result := x*x
Тогда OCaml не функциональный язык, а D функциональный
Здравствуйте, thesz, Вы писали:
T>>>Вот, например, тесты — когда это нужная работа? G>>Много от чего зависит. Например в TDD тесты — средство дизайна кода.
T>Это хорошо?
Это прекрасно.
T>http://grundik.livejournal.com/208883.html
У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная.
G>>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>>Кардинально уменьшит количество тестов. G>>Я использую TDD, от чего произойдет уменьшение количества тестов?
T>Уменьшение тестов произойдёт от увеличения проверок.
Если и проиойдет, то совсем незначительно. Unit-тесты тестируют функционал, функционала то меньше не станет и в разряд тривиального он не перейдет.
T>Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет.
И регрессионного тестирования нет. Это почти 100% проблемы при работе с чужим кодом.
T>Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна.
А проверкой того что композиция составлена правильно кто будет заниматься? Обычно эту роль играют интеграционные тесты.
T>Надо, что ли, курс какой создать по этому поводу.
Надо, я прям интересно за счет чего произойдет значительное уменьшение.
T>>>>>Ты, например, не знаешь о легкости соединения кода двух независимо работающих разработчиков, когда они пишут на чистом языке. T>>>>>У тебя этого под рукой нет. G>>>>Ты так говоришь как-будто нету других способов достигнуть такой же легкости. T>>>Для императивного программирования и для языков типа OCaml/F# эти "другие способы" переносят сложность в другую область. Например, на тесты. Или на документацию. Или на code review. G>>При условии хорошей автоматизации "других областей" это проблемой не является.
T>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). http://research.microsoft.com/en-us/projects/Pex/
Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
И проверка поведения на совести автора кода, я так понимаю?
Здравствуйте, Курилка, Вы писали:
К>Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
Исключения можно запретить.
Память могут и выделяют чистые функции на любом языке.
К>И проверка поведения на совести автора кода, я так понимаю?
Здравствуйте, Курилка, Вы писали:
FR>>В D есть http://www.digitalmars.com/d/2.0/function.html#pure-functions
К>Только вот как-то слова о том, что чистые функции могут аллоцировать память (ну это наверное не сильно важно) и бросать исключения как минимум смущают.
А с исключениями какие проблемы? Вот функция sqrt для вычисления квадратного корня. Она перестанет быть чистой, если будет выбрасывать исключение при получении отрицательного аргумента?
К>И проверка поведения на совести автора кода, я так понимаю?
В компиляторе D реализованы какие-то проверки чистоты функции. Об этом говорится даже в примере:
int x;
invariant int y;
const int* pz;
pure int foo(int i, // ok, implicitly convertible to invariantchar* p, // error, not invariantconst char* q, // error, not invariant
invariant int* s // ok, invariant
)
{
x = i; // error, modifying global state
i = x; // error, reading mutable global state
i = y; // ok, reading invariant global state
i = *pz; // error, reading const global statereturn i;
}
Но вот насколько эти проверки полные -- это вопрос.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). К>Вот тут вопрос... К>Эрланг же вроде как не совсем чтоб сильно чистый (процессы, ИО и т.п.), но QuickCheck вроде как интенсивно используют.
Опять же, из тезиса Джо Армстронга. Функции эрланговских процессов достаточно чисты. В принципе, их можно рассматривать, как state monad над состоянием процесса, включая и очередь сообщений, и посылку оных.
Получается функция вида InputMessage -> ProcessState -> -> FunctionState -> FunctionInput -> (OutputMessage,ProcessState,FunctionState).
Не такой уж и сложный тип.
К>Правда тут хрен знает как рассуждать, т.к. QuviQ QuickCheck — вещь закрытая
Я посмотрел. Довольно забавно. Видео у меня нет, я посмотрел на названия примеров и на флайер.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Вот, например, тесты — когда это нужная работа? G>>>Много от чего зависит. Например в TDD тесты — средство дизайна кода. T>>Это хорошо? G>Это прекрасно.
Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа.
Это не постановка вопроса, это жизнь.
G>>>>>Например мне нужно написать сайт, например интернет-магазин. Если я выберу haskell, то чем он мне поможет уменьшить количесто ненужной работы? T>>>>Кардинально уменьшит количество тестов. G>>>Я использую TDD, от чего произойдет уменьшение количества тестов? T>>Уменьшение тестов произойдёт от увеличения проверок. G>Если и проиойдет, то совсем незначительно. Unit-тесты тестируют функционал, функционала то меньше не станет и в разряд тривиального он не перейдет.
Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором.
Сравнение с образцом проверяется на полноту, типы проверяются строже. Вообще, проверок больше.
И их проще сделать самому.
T>>Тестирование правильности поведения заключается в вызове функции в REPL и входит в цикл разработки. Отдельного этапа создания тестов нет. G>И регрессионного тестирования нет. Это почти 100% проблемы при работе с чужим кодом. T>>Побочных эффектов нет, поэтому композиция правильных функций всегда тоже правильна. G>А проверкой того что композиция составлена правильно кто будет заниматься? Обычно эту роль играют интеграционные тесты.
У тебя есть типы. Интерфейсы должны по типам совпадать. Если совпали — переходи к функциональным тестам.
Интеграционные тесты требуются для проверки на правильность поддержания инвариантов.
T>>Надо, что ли, курс какой создать по этому поводу. G>Надо, я прям интересно за счет чего произойдет значительное уменьшение.
Да уж думаю.
T>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). G>http://research.microsoft.com/en-us/projects/Pex/
Сравни с QuickCheck, которая вообще библиотекой выполнена.
При желании можно разобраться и добавить функционала. С Pex у тебя такой возможности нет (в поставке нет исходного кода). И ещё: с Pex у тебя создаются юнит-тесты, которые ты должен сохранить и прогнать, в QuickCheck ты задаёшь свойства, прогонкой занимается QuickCheck.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>>>Вот, например, тесты — когда это нужная работа? G>>>>Много от чего зависит. Например в TDD тесты — средство дизайна кода. T>>>Это хорошо? G>>Это прекрасно.
T>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа.
Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей.
Как это одной строкой типа записать?
T>>>http://grundik.livejournal.com/208883.html G>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>Это не постановка вопроса, это жизнь.
Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage.
T>Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором.
На примере выше показать можно?
T>>>Видишь ли, автоматизацию тестов ты сделать не можешь. Точнее, можешь, но успешно её применять можно только в чистых языках (QuickCheck). G>>http://research.microsoft.com/en-us/projects/Pex/
T>Сравни с QuickCheck, которая вообще библиотекой выполнена.
Pex выполняет анализ кода, а не тестирование случаными данными.
Для тестирования случайными данными в .NET можно тоже просто библиотеку написать.
T>При желании можно разобраться и добавить функционала. С Pex у тебя такой возможности нет (в поставке нет исходного кода). И ещё: с Pex у тебя создаются юнит-тесты, которые ты должен сохранить и прогнать, в QuickCheck ты задаёшь свойства, прогонкой занимается QuickCheck.
В pex есть тоже самое. Свойства задаются контрактами (code contracts) и параметризованными тестами. Pex генерит тесты так как анализ выполняется достаточно долго, тесты фактически являются кешированными результатами анализа.
При этом тесты гораздо удобнее в использовании чем отдельные утилиты.
T>>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа. G>Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей. G>Как это одной строкой типа записать?
В Хаскеле к этому (см. раздел 5.1 Evidence is Ordering) только идут.
Хотя могу.
class Ordered order a where
mkOrder :: order -> a -> a -> (a,a)
data ByField1
instance Ordered ByField1 Obj
mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
data OrderedBy ordering a where
OrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
mkOrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
mkOrderedBy ordering x y = OrderedBy ordering low high
where
(low,high) = mkOrder ordering x y
fromOrderedBy (OrderedBy _ a b) = (a,b)
Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом.
Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
T>>>>http://grundik.livejournal.com/208883.html G>>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>>Это не постановка вопроса, это жизнь. G>Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage.
По-моему, он старался проверить возможные пути.
T>>Тебе потребуется меньше тестировать функционал, поскольку его правильность проверяется компилятором. G>На примере выше показать можно?
Ну, sized types мы уже рассмотрели. Упорядочение тоже.
Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns).
T>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>Pex выполняет анализ кода, а не тестирование случаными данными. G>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать.
И как ты проверишь все возможные пути изменения состояния?
G>При этом тесты гораздо удобнее в использовании чем отдельные утилиты.
Ну, я в подробных тестах не силен, поскольку не использую. Спорить не буду.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа. G>>Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей. G>>Как это одной строкой типа записать?
T>В Хаскеле к этому (см. раздел 5.1 Evidence is Ordering) только идут.
T>Хотя могу.
T>
T>class Ordered order a where
T> mkOrder :: order -> a -> a -> (a,a)
T>data ByField1
T>instance Ordered ByField1 Obj
T> mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
T>data OrderedBy ordering a where
T> OrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
T>mkOrderedBy :: Ordered ordering a => ordering -> a -> a -> OrderedBy ordering a
T>mkOrderedBy ordering x y = OrderedBy ordering low high
T> where
T> (low,high) = mkOrder ordering x y
T>fromOrderedBy (OrderedBy _ a b) = (a,b)
T>
T>Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом.
Да уж... одна строка типа...
T>Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
ИХМО приседаний многовато. Хотя надо на реальном проекте сравнить.
T>>>>>http://grundik.livejournal.com/208883.html G>>>>У человка видимо неправльные тесты. Даже сама постановка вопроса "надо поменять строчку и для этого понадобилось переписать кучу тестов" неправильная. T>>>Это не постановка вопроса, это жизнь. G>>Хреновая жизнь. Вероятнее всего вызванная тем, что человек гонялся за code coverage. T>По-моему, он старался проверить возможные пути.
Это и есть погоня за code coverage. Тесты должны не пути проверять, а функционал.
T>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns).
Вне контекста pattern-matching такое рассматривать смысла нет.
T>>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>>Pex выполняет анализ кода, а не тестирование случаными данными. G>>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать. T>И как ты проверишь все возможные пути изменения состояния?
Я — никак, а pex умеет.
T>>class Ordered order a where
T>> mkOrder :: order -> a -> a -> (a,a)
T>>data ByField1
T>>instance Ordered ByField1 Obj
T>> mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
T>>
T>>Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом. G>Да уж... одна строка типа...
А вот дальше — одна строка, практически:
sortByField1 :: Ordered ByField1 Obj => [obj] -> SortedList ByField1 Obj
sortByField1 list = sortByOrdering list
sortByField2Rev :: Ordered ByField2Rev Obj => [obj] -> SortedList ByField2Rev Obj
sortByField2Rev list = sortByOrdering list
Ошибиться вариантов минимум.
T>>Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана. G>ИХМО приседаний многовато. Хотя надо на реальном проекте сравнить.
Контракты получаются явные, видны невооружённым глазом, лежат рядом с реализацией.
В тех случаях, когда мне удавалось применить (я же только учусь) это очень помогало.
T>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns). G>Вне контекста pattern-matching такое рассматривать смысла нет.
Этого я не понял. Объясни, пожалуйста.
T>>>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>>>Pex выполняет анализ кода, а не тестирование случаными данными. G>>>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать. T>>И как ты проверишь все возможные пути изменения состояния? G>Я — никак, а pex умеет.
Ой ли? Всех объектов всех графов?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Не уверен. У тебя несколько строк кода тестов, у меня одна строка типа. G>>Хм... например тест проверяет что функция возвращает список объектов, упорядоченных по одному из полей. G>>Как это одной строкой типа записать?
T>Хотя могу.
T>
T>instance Ordered ByField1 Obj
T> mkOrder _ a b = if field1 a > field1 b then (a,b) else (b,a)
T>
T>Упорядоченную пару я создал, из неё можно сделать упорядоченный список похожим образом.
T>Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
А где проверка того, что упорядочение идет именно в том порядке, в котором это нужно для задачи? У тебя, насколько это можно понять, значения в парах сортируются в порядке убывания. А если нужно в порядке возрастания?
Unit-тест как раз проверил бы, не ошибся ли разработчик при записи field a <что-то> field b.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
T>>>И как ты проверишь все возможные пути изменения состояния? G>>Я — никак, а pex умеет.
FR>Комбинаторный взрыв не помешает?
Может и помешает.
Но нету необходимости проводить полный анализ. Можно кго сильно ограничит контрактами или вообще задать сценарии работы — параметризованные тесты.
Здравствуйте, thesz, Вы писали:
T>>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns). G>>Вне контекста pattern-matching такое рассматривать смысла нет.
T>Этого я не понял. Объясни, пожалуйста.
int func(int a)
{
if(a = 1) return 0;
return 1;
}
Если последний return не написать то даже компилироваться не будет.
Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.
T>>>>>Сравни с QuickCheck, которая вообще библиотекой выполнена. G>>>>Pex выполняет анализ кода, а не тестирование случаными данными. G>>>>Для тестирования случайными данными в .NET можно тоже просто библиотеку написать. T>>>И как ты проверишь все возможные пути изменения состояния? G>>Я — никак, а pex умеет.
T>Ой ли? Всех объектов всех графов?
Не знаю, я этого зверька пока только в ограниченных условиях гонял.
T>>Заметь, что упорядочение у меня протягивает и доказательство тоже. То есть, достаточно создать правильное создание упорядоченного списка (пары) и сделать несколько instance Ordered, и всё со всеми заработает. Правильность кода доказана.
E>А где проверка того, что упорядочение идет именно в том порядке, в котором это нужно для задачи? У тебя, насколько это можно понять, значения в парах сортируются в порядке убывания. А если нужно в порядке возрастания?
E>Unit-тест как раз проверил бы, не ошибся ли разработчик при записи field a <что-то> field b.
В полноценных зависимых типах индексом могут быть и функции.
В этом случае всё выглядело бы так:
data OrderedPair : (a : Set) -> {b : Set} ->
(map : a -> b) -> (less : b -> b -> Bool) where
OrderPair : {a b : Set} -> {map : a -> b} -> {less : b -> b -> Bool} ->
(x y : a) -> {less (map x) (map y) = True} -> OrderedPair a b map less
byField1 : {a : Set} -> a -> a -> OrderedPair a getField1 (_<_)
byField1 a b | getField1 a < getField1 b
byField1 a b True = OrderPair a b
byField1 a b False = OrderPair b a
byField1Rev : {a : Set} -> a -> a -> OrderedPair a getField1 (_>_)
byField1Rev ...
byField1 иначе не напишешь. Компилятор будет настаивать.
Это хорошее решение?
В Хаскеле же доступно вот то, что я показал выше. И общее движение в сторону полных зависимых типов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns). G>>>Вне контекста pattern-matching такое рассматривать смысла нет. T>>Этого я не понял. Объясни, пожалуйста. G>
G>Если последний return не написать то даже компилироваться не будет. G>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.
Что будет, если не int, а дерево и проверка посложней и вариантов побольше? Что будет, если структура дерева поменялась, и появился новый вариант?
Компилятор Хаскеля мне об этом скажет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, thesz, Вы писали:
T>>>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns). G>>>Вне контекста pattern-matching такое рассматривать смысла нет.
T>>Этого я не понял. Объясни, пожалуйста. G>
G>Если последний return не написать то даже компилироваться не будет. G>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.
Это не особенность записи функций хаскеля, это свойство паттерн-матчинга.
Ближайшим (правда ооочень фиговым) шарповским аналогом ПМ по-моему является switch, но вот что-то я не припомню проверки полноты его компилятором
Можно ещё и про "проваливающиеся" case вспомнить...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, eao197, Вы писали:
E>>Вот, например, описание агента. Более-менее сложного.
V>Жень, тебе надо компилятор из некоего DSL в целевой С++ делать, а то как-то действительно "более-менее сложно" получается.
DSL тут не принципиален. Будет выглядеть чуть лучше, и только. Его фреймворк вынуждает программиста к разворачиванию всех сценариев взаимодействия агентов в явно записанные конечные автоматы, и в этом корень проблемы. Даже простые сценарии будут выглядеть очень сложно на ровном месте.
Здравствуйте, thesz, Вы писали:
E>>А где проверка того, что упорядочение идет именно в том порядке, в котором это нужно для задачи? У тебя, насколько это можно понять, значения в парах сортируются в порядке убывания. А если нужно в порядке возрастания?
E>>Unit-тест как раз проверил бы, не ошибся ли разработчик при записи field a <что-то> field b.
T>В полноценных зависимых типах индексом могут быть и функции.
T>В этом случае всё выглядело бы так: T>
T>byField1 : {a : Set} -> a -> a -> OrderedPair a getField1 (_<_)
T>
T>byField1 иначе не напишешь. Компилятор будет настаивать.
T>Это хорошее решение?
Если я правильно понял, то теперь просто место потенциальной ошибки сместилось в запись "...getField1 (_<_)". Но что, если программист невнимательно прочитал спецификацию или же случайно написал (_<_) вместо (_>_). Кто это будет проверять?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandjustas, Вы писали:
G>>>>Данная "декларативность" его имхо затрудняет. G>>>Данная декларативность не влияет на наблюдаемое поведение.
G>>Она влияет на поведение программы.
G>Как?
Если оно не никак не влиет на поведение программы, то что может заставить программиста писать asynchronous? Я задал вопрос, чем это лучше явного употребления фьючерса. Если это на самом деле работает как фьючерс, то оно влияет на поведение программы, как фьючерс, вставленный в автоматическом режиме. Ты на вопрос не ответил ("декларативностью" — это не ответ). Если оно работает как-то по другому, и я неправильно понимаю — так объясни мне, как оно работает. Мне то ты зачем этот вопрос задаешь?
Непонятен вопрос — попроси пояснений. Не знаешь — скажи не знаю. Не хочешь отвечать — не отвечай, у нас свободная страна. Тока не надо задавать бессмысленные вопросы мне, уводя дискуссию в сторону. Мне совершенно не интересно пытаться тебя переспорить, есть дела поважнее.
Здравствуйте, eao197, Вы писали:
E>Если я правильно понял, то теперь просто место потенциальной ошибки сместилось в запись "...getField1 (_<_)". Но что, если программист невнимательно прочитал спецификацию или же случайно написал (_<_) вместо (_>_). Кто это будет проверять?
Место ошибки не сместилось, мест, где может быть ошибка, стало ровно одно. Написать (<) вместо (>) — это постараться надо. А написать неправильную сортировку — раз плюнуть.
Ты ещё скажи "а что, если юнит-тест написали неверно и он проверяет не то, и в документации опечатались".
Здравствуйте, gandjustas, Вы писали:
G>int func(int a) G>{ G> if(a = 1) return 0; G> return 1; G>} G>[/ccode] G>Если последний return не написать то даже компилироваться не будет.
Во-первых, в Си++ будет. Но, видимо, речь не о нём.
Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения.
Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
Здравствуйте, VoidEx, Вы писали:
E>>Если я правильно понял, то теперь просто место потенциальной ошибки сместилось в запись "...getField1 (_<_)". Но что, если программист невнимательно прочитал спецификацию или же случайно написал (_<_) вместо (_>_). Кто это будет проверять? VE>Место ошибки не сместилось, мест, где может быть ошибка, стало ровно одно. Написать (<) вместо (>) — это постараться надо.
Не знаю, как кто, а я вот, наверное, раз в две-три недели по недосмотру пишу < вместо <=, не говоря уже о +1/-1. Опечатки в исходниках никто не отменял.
VE>А написать неправильную сортировку — раз плюнуть.
Не будем доводить до маразма -- сейчас собственную сортировку пишут либо полные валенки/ламеры, либо люди, которые хорошо понимают, зачем и почему они это делают. А вот написать неправильный предикат сравнения -- это запросто.
VE>Ты ещё скажи "а что, если юнит-тест написали неверно и он проверяет не то, и в документации опечатались".
И кстати, когда такие вещи всплывают -- это очень и очень хорошо. Ошибки есть везде, и в спецификации, и в тестах. И юнит тесты как раз позволяют подобные вещи отлавливать. Поскольку они очень быстро лишают человека веры в то, что если компилятор проглотил программу, то она правильная. Она может быть, безошибочная. И неправильная. Просто делает не то, что нужно было.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>>>Unit-тест как раз проверил бы, не ошибся ли разработчик при записи field a <что-то> field b. T>>В полноценных зависимых типах индексом могут быть и функции. T>>В этом случае всё выглядело бы так: T>>
T>>byField1 : {a : Set} -> a -> a -> OrderedPair a getField1 (_<_)
T>>
T>>byField1 иначе не напишешь. Компилятор будет настаивать. T>>Это хорошее решение? E>Если я правильно понял, то теперь просто место потенциальной ошибки сместилось в запись "...getField1 (_<_)". Но что, если программист невнимательно прочитал спецификацию или же случайно написал (_<_) вместо (_>_). Кто это будет проверять?
Далее у нас идёт сортировка списка объектов. Она тоже будет вынуждена нести крест getField1 (_<_) из-за использования OrderedPair. И так до того уровня, на котором это доказательство пропадает.
Если раньше мы могли ошибиться в самом методе сравнения и в алгоритме сортировки, то теперь не можем.
Нам надо тестировать только то место, где доказательство пропадает.
Я считаю, исходя из моего практического опыта, что для этого достаточно функциональных тестов.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
EE>Не будем доводить до маразма
Действительно, не будем воспринимать пример буквально.
E>И кстати, когда такие вещи всплывают -- это очень и очень хорошо. Ошибки есть везде, и в спецификации, и в тестах. И юнит тесты как раз позволяют подобные вещи отлавливать. Поскольку они очень быстро лишают человека веры в то, что если компилятор проглотил программу, то она правильная. Она может быть, безошибочная. И неправильная. Просто делает не то, что нужно было.
Ну, можно, конечно, написать unit-test на функцию mkOrder
Здравствуйте, eao197, Вы писали:
E>Не знаю, как кто, а я вот, наверное, раз в две-три недели по недосмотру пишу < вместо <=, не говоря уже о +1/-1. Опечатки в исходниках никто не отменял.
От, этого, кстати, рекурсия хорошо помогает
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, thesz, Вы писали:
T>>>>>Мы можем возложить на компилятор проверки полноты рассмотрения нами всех вариантов входных данных (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html ищи -fwarn-incomplete-patterns). G>>>>Вне контекста pattern-matching такое рассматривать смысла нет.
T>>>Этого я не понял. Объясни, пожалуйста. G>>
G>>Если последний return не написать то даже компилироваться не будет. G>>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.
К>Это не особенность записи функций хаскеля, это свойство паттерн-матчинга.
Я вроде тоже самое сказал, но thesz не понял.
К>Ближайшим (правда ооочень фиговым) шарповским аналогом ПМ по-моему является switch, но вот что-то я не припомню проверки полноты его компилятором К>Можно ещё и про "проваливающиеся" case вспомнить...
А оно там и не надою switch не является выражением, поэтому там такая проверка не требуется.
Если далеко не ходить и взять F#, там тоже есть p-m, там код не компилится при неполных паттернах. Если функция должна падать при некоторых входных данных то жто надо явно указать.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>>>Данная "декларативность" его имхо затрудняет. G>>>>Данная декларативность не влияет на наблюдаемое поведение. G>>>Она влияет на поведение программы. G>>Как?
G>Если оно не никак не влиет на поведение программы, то что может заставить программиста писать asynchronous?
Вот и я не знаю, надо было asynchronous сделать дефолтным вариантом.
Спека по этому поводу вот что говорит
Using asynchronous methods is often over-kill and has a performance penalty for small methods and functions which do not do I/O or messaging. Therefore, the rule is that methods are synchronous and have to be explicitly identified as asynchronous. The only methods that are asynchronous by default are agent constructors.
G>Я задал вопрос, чем это лучше явного употребления фьючерса. Если это на самом деле работает как фьючерс, то оно влияет на поведение программы, как фьючерс, вставленный в автоматическом режиме. Ты на вопрос не ответил ("декларативностью" — это не ответ). Если оно работает как-то по другому, и я неправильно понимаю — так объясни мне, как оно работает.
Банально заменяет все блокирующие вызовы на неблокирующие (компилятор генерирует "автоматный" код, вместо линейного).
G>Мне то ты зачем этот вопрос задаешь?
Затем и задаю, что ты не разобравшись как оно работает стал выдумывать недостатки.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, gandjustas, Вы писали:
G>>int func(int a) G>>{ G>> if(a = 1) return 0; G>> return 1; G>>} G>>[/ccode] G>>Если последний return не написать то даже компилироваться не будет. VE>Во-первых, в Си++ будет. Но, видимо, речь не о нём.
неужели в С++ все так плохо?
VE>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения. VE>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции.
А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, gandjustas, Вы писали:
G>>>Это только особенность записи функций в хаскеле что можно забыть сопоставить выходные значения некоторому набору входных значений.
К>>Это не особенность записи функций хаскеля, это свойство паттерн-матчинга. G>Я вроде тоже самое сказал, но thesz не понял.
Я специально написал, что это не про запись, а ты меня не понял, чтож о Сергее-то говорить?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, VoidEx, Вы писали:
VE>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения. VE>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции. G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
Ты уже определись, то хорошо, что "если не написать, то даже компилироваться не будет", то пофиг, что код станет "код станет неправльным\неполным при добавлении новых значений енума". А то такое впечатление, что ты меняешь мнение в зависимости от выгодности в конкретный момент
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, VoidEx, Вы писали:
VE>>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения. VE>>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции. G>>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
К>Ты уже определись, то хорошо, что "если не написать, то даже компилироваться не будет", то пофиг, что код станет "код станет неправльным\неполным при добавлении новых значений енума". А то такое впечатление, что ты меняешь мнение в зависимости от выгодности в конкретный момент
Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.
Здравствуйте, gandjustas, Вы писали:
G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
Этого — никто не говорит.
А вот компилятор, который молча компилирует потенциально сделанный неверным код — говорит "а, добавление пару енумов точно ничего не сломает".
Не компилятору это решать, поэтому он обязан сообщить мне о местах, на которые мои изменения могли потенциально повлиять.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Ты уже определись, то хорошо, что "если не написать, то даже компилироваться не будет", то пофиг, что код станет "код станет неправльным\неполным при добавлении новых значений енума". А то такое впечатление, что ты меняешь мнение в зависимости от выгодности в конкретный момент
G>Я не говорю что чтото хорошо или плохо. Я говорю что проверки полноты рассмотрения нами всех вариантов входных данных нужны исключительно в связи паттерн-матчингом.
Т.е. ты просто до ПМ докопался (не проверямого на полноту по умолчанию в хаскеле), а на остальное пофигу?
Странно, а я думал, в этой ветке про возможную полезность проверок на уровне типов говорили, а оказывается я глубоко заблуждался
Чтот я большего конструктива ждал...
Здравствуйте, vdimas, Вы писали:
V>Если честно, я фиг его знает, что именно делают в прикладном коде эти агенты и какие конкретно там сценарии, за все сценарии не распишусь. Мне, например, и без агентов иногда код как автомат приходится делать, ибо природа задач бывает такова сама по себе, что разворот на C# через yield лишь усложняет или даже вынуждает использовать goto.
Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример: http://rsdn.ru/forum/message/3392818.1.aspx
Здравствуйте, Gaperton, Вы писали:
G>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример: G>http://rsdn.ru/forum/message/3392818.1.aspx
Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода. Твои задачи с помощью нашего подхода никогда не решались, поэтому я не могу сказать, был бы там геморрой или нет. Очевидно, что они решались бы сильно по другому. Но не факт, что сложнее файберной магии. Которая, вообще-то говоря, далеко не везде доступна.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример: G>>http://rsdn.ru/forum/message/3392818.1.aspx
E>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.
Это _не_ мой код. Это пример как будет выглядеть простая проблема в асинхронной записи. У тебя это будет выглядеть еще страшнее, кстати.
И я не вижу ни единой причины, почему мне не стоит приводить это в пример. У тебя асинхронная запись? Да. Все. Хочешь сказать, что я неправ — приведи решение данной проблемы "в своем фреймворке".
E> Твои задачи с помощью нашего подхода никогда не решались, поэтому я не могу сказать, был бы там геморрой или нет.
Твои агенты никогда не обращаются друг к другу с простейшими асинхронными запросами? Я тя умоляю. Непонятно, почему тебе вообще пришло в голову назвать это "агентским фреймворком" тогда.
E> Очевидно, что они решались бы сильно по другому. Но не факт, что сложнее файберной магии. Которая, вообще-то говоря, далеко не везде доступна.
Покажи — как по другому. Еще раз — я говорю о простейших сценариях. Под которые, как ты говоришь, фреймворк не заточен? Да нафига он вообще нужен тогда?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Ключевое слово "иногда", а не "всегда". Имея состояние на стеке, я имею выбор, как писать — явным автоматом, или линейным кодом. В его фреймворке я не имею этого выбора, и простейшие задачи превращаются в геморрой. См. пример: G>>http://rsdn.ru/forum/message/3392818.1.aspx
E>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.
Кстати, просим-просим — запиши этот геморрой на своем фреймворке, вот с этими самыми конечными автоматами, которые ты показывал выше, и приведи код в студию. Пусть люди увидят, на что это будет похоже. Паржом.
VE>>Возьми вместо int какой-нибудь enum. Теперь добавь в enum два новых значения. VE>>Вуаля! Никакого предупреждения о том, что обрабатывается не всё, потому что хоть в switch надо default вставить, хоть в конце функции. G>А кто сказал что код станет неправльным\неполным при добавлении новых значений енума?
Если это может случиться, то это случится.
Поэтому код станет неправильным/неверным при добавлении новых значений в enum.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
E>>Прикольно, что в качестве демонстрации геморроя с нашим фреймворком ты приводишь примеры своего кода.
G>Кстати, просим-просим — запиши этот геморрой на своем фреймворке, вот с этими самыми конечными автоматами, которые ты показывал выше, и приведи код в студию. Пусть люди увидят, на что это будет похоже. Паржом.
С Эрлангом мы конкурировать собрались, не имея в рукаве ничего кроме асинхронной автоматной записи, значить . Ведь все уже объяснил, разжевал, и в рот положил — и ведь все он понял, что самое интересное, но нет — все равно спорить полез.
Давай, момент истины — show me the code, хватит уже языками чесать. Убеди меня, что у тебя все не так — покажи красивый, правильный MFC-style код, пестрящий макросами, и вспухший на ровном месте. Вот спорим, ты мне сейчас под каким-либо предлогом не станешь приводить код?
Начнешь опять говорить, что "это не тот случай, под который разрабатывался фреймворк, задача мол слишком простая" — а вот давай будем честными, и покажем, во что превращается самая простая задача в твоем фреймворке. Это и есть его недостаток, понимаешь? Ну вот согласись, признай как оно есть — "да, недостаток". Не надо тебе ни в чем оправдываться, ты это в 97 году рисовал.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, vdimas, Вы писали:
V>>В общем, вот давняя картинка, попробуй здесь без goto:
V>>
G>Эта увлекательная дискуссия закончилась еще в 70-х годах. Думаю, не надо напоминать, чем?
G>Это хорошо выглядит на картинке, и отвратительно — в коде.
Не знаю, по-моему оно и на картинке выглядит извратно аля "кручу верчу — запутать хочу!"
Здравствуйте, Gaperton, Вы писали:
G>И я не вижу ни единой причины, почему мне не стоит приводить это в пример. У тебя асинхронная запись? Да. Все. Хочешь сказать, что я неправ — приведи решение данной проблемы "в своем фреймворке".
Что значит "асинхронная запись"?
Где описание проблемы, которую нужно решить? Пока были только общие слова про какую-то обработку каких-то рядов.
G>Покажи — как по другому. Еще раз — я говорю о простейших сценариях. Под которые, как ты говоришь, фреймворк не заточен? Да нафига он вообще нужен тогда?
Вот пример агента из задачи, которой я занимаюсь прямо сейчас. Этот агент является менеджером дочерних процессов (в каждом из которых сидят собственные агенты-исполнители). Его задачей является получение двух типов запросов (phase_c и phase_p), передача этих запросов в подходящие дочерние процессы, получение ответов от дочерних процессов (phase_c_result, phase_p_result), преобразование ответов в нужный формат, контроль за работоспособностью и наличию связи с дочерними процессами, поддержание актуальной оперативной мониторинговой информации о текущем состоянии. Информация о запросах/результатах, а также уведомления о проблемах с дочерними процессами приходит асинхронно, в произвольном порядке. Контроль состояния и обновление мониторинговой информации нужно делать по таймеру. В принципе, это простейший сценарий для тех задач, которыми я занимаюсь.
Суммарный объем кода одного этого агента -- 1500 физических строк (включая комментарии и пустые строки).
Суммарный объем кода нескольких классов, использующихся данным агентом -- более 2500 физических строк.
Объем кода, связанный с описанием агента для SO: 70 строк макросов + 50 строк подписки на разные сообщения. Т.е. на 4K строк, отвечающих за решение конкретной задачи, приходится 120 строк SO-оверхеда. Вот само описание агента для SO на макросах. Для знакомого с SO разработчика это описание уже раскрывает основную схему работы данного агента.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>С Эрлангом мы конкурировать собрались
E>Почему бы и нет?
Ну, наверное потому, что для того, чтобы всерьез конкурировать, одного желания недостаточно, надо иметь какие-то объективные преимущества. И кроме этого, иметь поменьше недостатков. Или просто — пробелов.
G>>Ну вот согласись, признай как оно есть — "да, недостаток".
E>О том, что многословность -- это недостаток SO4 было публично сказано еще в прошлом году.
"И повторять это я не собираюсь!!!" Так? "Многословность" — это симптом. Причиной является то, что ты назвал в дискуссии со мной "глобальная асинхронность". Не изменив подход к проблеме, ничего радикально исправить нельзя.
Это очень серьезный недостаток в сравнении с Эрлангом. Да и с любым фреймворком, в котором есть легкие потоки. На нем сравнение можно оставить. Все.
Здравствуйте, Gaperton, Вы писали:
G>"Многословность" — это симптом. Причиной является то, что ты назвал в дискуссии со мной "глобальная асинхронность".
Глобальная асинхронность и многословность в C++ -- это, имхо, две ортогональные друг другу вещи.
G>Не изменив подход к проблеме, ничего радикально исправить нельзя.
Я не вижу проблемы там, где ты говоришь. Если что-то делается слишком сложно с помощью SO, то просто не нужно делать это с помощью SO. Кому это нужно, пусть берет любой фреймворк с легкими потоками или пишет свой собственный. SO вовсе не обязан поддерживать разные формы взаимодействия сущностей в приложении. Пусть он делает хорошо то, для чего был предназначен.
G>Да и с любым фреймворком, в котором есть легкие потоки. На нем сравнение можно оставить. Все.
Аминь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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 очень разных утверждения, или я не прав?
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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# такие функции-селекторы объявлять самому можно. В такую функцию изменяемые данные не подсунешь
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
VD>>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше.
T>>Практически никакого. Контроля. Не будет.
VD>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
VD>Кстати, в том же Эрланге ПМ тоже не контролируемый (как я понимаю). Но это не мешает его использовать.
Какой-то странный термин вы изобрели...
Если под ним подразумевается ПМ по неизменяемым данным (и дальнейшее соблюдение условий ПМ), то в Эрланге он контролируемый по самое "не балуйся", т.к. изменяемых данных там практически нет (если не брать словарь процесса и ввод/вывод, включая сообщения, но даже они не могут "поменять" имеющиеся переменные, single assignment)
"Контролируемый" в том смысле, что компилятор может проконтролировать, что все варианты охвачены в операторе ПМ (или списке функций). Например, в Скале по умолчаню создаются открытые к расширению АлгТД, что ведет к тому, что компилятор не может контролировать полноту охвата ПМ. Но в Скале можно объявить АлгТД как запечатанные (не расширяемые), что приводит к тому, что компилятор может проконтролировать полноту охвата.
К>Если под ним подразумевается ПМ по неизменяемым данным
Нет. Изменяемость тут не причем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя.
В монгопоточных приложениях доступ к данным обычно осуществляется как один писатель, много читателей, или на обычных блокировках, не зависимо просто ли это чтение или сравнения с образцом.
Для однопоточных этого и не нужно.
и солнце б утром не вставало, когда бы не было меня
T>>Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать. VD>У тебя мания величия. Можно подумать, что твоих рекомендаций кто-то ждет.
Если кто-нибудь попросит, то не буду.
T>>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. VD>На практике это не проблема. Если человек сделал структуру данных изменяемой, значит он понимает что тварит. Обычно это оптимизация. Например, в AST немерла есть поле Location определяющее местоположение соответствующего кода в файле. Само поле ни на что не влияет, использовать в ПМ его практически бесполезно. Однако очень важно, чтоб было можно менять это поле не пересоздавая объекты. Например, при редактировании файла нужно обеспечить корректировку ветвей АСТ которые располагаются ниже области редактирования. Иначе прийдется каждый раз перепарсивать весь файл.
Не вижу, зачем снова разбирать оставшуюся часть файла заново и твою "оптимизацию" можно сделать и функционально.
T>>Преобразовать сравнение с образцом в вызов функции уже нельзя. VD>А оно надо? В прочем, думаю, что ты и тут ошибаешься. Это только в хаскеле функции не могут иметь замканий на изменяемые данные. А в гибридных языках — это нормальная практика. Так что преобразовывать можно. Вопрос только зачем.
Оно надо для рассуждения о программах.
VD>>>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан. T>>Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов. VD>Блин, бессмертный .
Почему, тоже смертный. Только знаю.
VD>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал.
Получилось не так и плохо.
VD>>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше. T>>Практически никакого. Контроля. Не будет. VD>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
Да, этого не отнять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя. S> В монгопоточных приложениях доступ к данным обычно осуществляется как один писатель, много читателей, или на обычных блокировках, не зависимо просто ли это чтение или сравнения с образцом.
S>Для однопоточных этого и не нужно.
f q xx@(x:xs) = g xx (q x)
f [] = что-то
p xs = f (изменяющее xs функция, как параметр q) xs
Мы не можем рассчитывать, что g получит не пустой список, если q x вычислится первым.
Функциональное программирование сильно меняет взгляд на вещи.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>Функциональное программирование сильно меняет взгляд на вещи.
E>Ну да, в почти случайной последовательности символов
f q xx@(x:xs) = g xx (q x)
вдруг обнаруживается какой-то смысл.
E>
Всё ж не Перл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Не вижу, зачем снова разбирать оставшуюся часть файла заново
Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
T>и твою "оптимизацию" можно сделать и функционально.
Языком все можно сделать. А на практике...
T>Оно надо для рассуждения о программах.
И часто ты о ней рассуждаешь?
VD>>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
T>Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал.
Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
T>Получилось не так и плохо.
Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
VD>>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
T>Да, этого не отнять.
Ну, дык речь то идет о добавлении ПМ в Шарп, а не о замене шарпа хаскелем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали: T>Функциональное программирование сильно меняет взгляд на вещи.
Менять меняет, но возьмем базы данных там тоже есть версионность (то есть чтение в разрезе транзакции, так и для откатов транзакций), но и экслюзивный доступ к данным.
Разные подходы нужны.
и солнце б утром не вставало, когда бы не было меня
T>>Не вижу, зачем снова разбирать оставшуюся часть файла заново VD>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
Я не вижу, зачем здесь изменяемые значения.
T>>и твою "оптимизацию" можно сделать и функционально. VD>Языком все можно сделать. А на практике...
Так я на практике так и делаю.
T>>Оно надо для рассуждения о программах. VD>И часто ты о ней рассуждаешь?
Практически над каждой строкой. Да не по одному разу.
Как и ты, впрочем.
VD>>>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно. T>>Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал. VD>Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
Это ты опять преждевременно оптимизируешь.
T>>Получилось не так и плохо. VD>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
Вычислительная часть и сравнение с образцом дружат редко. Хотя, символьная оптимизация на Хаскеле обычно получается работающей быстрее (во всех смыслах — и быстрее написать, и быстрее работает), чем на других языках.
Для моделирования я использую Джаву, поскольку JIT.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
VD>>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
T>Я не вижу, зачем здесь изменяемые значения.
Бывает. Но я тут тебе уже не помогу. Это к другим специалистам .
Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>>>и твою "оптимизацию" можно сделать и функционально. VD>>Языком все можно сделать. А на практике...
T>Так я на практике так и делаю.
Языком?
T>>>Оно надо для рассуждения о программах. VD>>И часто ты о ней рассуждаешь?
T>Практически над каждой строкой. Да не по одному разу.
И каждый раз в функции переводишь чтобы порассуждать?
T>Как и ты, впрочем.
Я код пишу и читаю. Мне его в функции переводить нужды нет.
VD>>Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
T>Это ты опять преждевременно оптимизируешь.
Опять? Сможешь привести хотя бы один пример?
Оптимизировать тут нечего. Просто язык на сегодня не гарантирует высокую производительность в нужных местах.
T>>>Получилось не так и плохо. VD>>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
T>Вычислительная часть и сравнение с образцом дружат редко.
Да, ну? Это очень сильно зависит от того как этот самый ПМ реализован. Если эффективно, то почему бы его не использовать и в вычислительных алгоритмах?
T>Для моделирования я использую Джаву, поскольку JIT.
Моделирования чего? Или в каком смысле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова. T>>Я не вижу, зачем здесь изменяемые значения. VD>Бывает. Но я тут тебе уже не помогу. Это к другим специалистам . VD>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
(осторожно) Ленивые вычисления?..
T>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>Языком все можно сделать. А на практике... T>>Так я на практике так и делаю. VD>Языком?
Программирования, ага.
T>>>>Оно надо для рассуждения о программах. VD>>>И часто ты о ней рассуждаешь? T>>Практически над каждой строкой. Да не по одному разу. VD>И каждый раз в функции переводишь чтобы порассуждать?
Возможностью перевода (прозрачностью по ссылкам или функциональной чистотой) — каждый раз.
T>>Как и ты, впрочем. VD>Я код пишу и читаю. Мне его в функции переводить нужды нет.
Ты рассуждаешь. А уж умеешь ли ты использовать перевод в функции, или не умеешь, это дело третье.
Если умеешь — ты сильнее, как программист.
T>>>>Получилось не так и плохо. VD>>>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы. T>>Вычислительная часть и сравнение с образцом дружат редко. VD>Да, ну? Это очень сильно зависит от того как этот самый ПМ реализован. Если эффективно, то почему бы его не использовать и в вычислительных алгоритмах?
Мало смысла.
Хотя кое-где очень полезно — например, k-d Или quad tree.
T>>Для моделирования я использую Джаву, поскольку JIT. VD>Моделирования чего? Или в каком смысле?
Аппаратуры. Моделирование аппаратуры и есть та самая вычислительная часть.
Это у Булата сжатие написано на C++.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
VD>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>(осторожно) Ленивые вычисления?..
И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
T>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>Языком все можно сделать. А на практике... T>>>Так я на практике так и делаю. VD>>Языком?
T>Программирования, ага.
А со стороны видно, что обычным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда. T>>(осторожно) Ленивые вычисления?.. VD>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
Как так "должны меняться"?
Они должны читаться новыми, но чтобы меняться...
T>>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>>Языком все можно сделать. А на практике... T>>>>Так я на практике так и делаю. VD>>>Языком? T>>Программирования, ага. VD>А со стороны видно, что обычным.
Одна твоя точка не даёт статистики.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>>(осторожно) Ленивые вычисления?..
VD>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
Толк, однако, с них есть. Релятивистские эффекты в программах возникают, и их можно полезно использовать.
Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример.
Потактовая модель процессора — это вполне императивная штука. Кадлая стадия конвейра имеет мутабельное состояние. Прикинь, именно ленивость позволяет компактно и прикольно его, процессор, описать. А именно — ленивые списки являются "проводами", которые связывают блоки — стадии конвейра, друг с другом.
Да, интересное наблюдение. Модели процов на Хаскеле дают более высокую производительность (такты в секунду), чем аналогичные модели на С++ (с применением библиотеки SystemC, что есть индустриальный стандарт). Это — наблюдавшийся на опыте в нашей работе (мы, если ты не знаешь, моделировали суперскалярный MIPS) парадокс, который сложно объяснить, но это — экспериментальный факт. Кстати — не только мы применяли Хаскель для моделирования аппаратуры. Еще это делает одна известная компания. ARM.
T>>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>>Языком все можно сделать. А на практике... T>>>>Так я на практике так и делаю. VD>>>Языком?
T>>Программирования, ага.
VD>А со стороны видно, что обычным.
Да ладно тебе. У Зефирова реально очень большая практика применения Хаскеля в продакшне. Сейчас он делает это уже на другой работе, разрабатывая САПР для микроэлектроники. И вполне успешно. Это, как минимум, интересно, согласись?
Здравствуйте, Gaperton, Вы писали:
VD>>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
G>Толк, однако, с них есть. Релятивистские эффекты в программах возникают, и их можно полезно использовать.
G>Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример...
Я ничего не имею против ленивости. Я хочу понять как она поможет мне избавиться от императивного изменения значений и при этом оставить код эффективным в конкретном случае.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>>Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример... VD>Я ничего не имею против ленивости. Я хочу понять как она поможет мне избавиться от императивного изменения значений и при этом оставить код эффективным в конкретном случае.
Ты ещё скажи, что ты не преждевременно оптимизируешь.
Но это я так, к слову.
Мы можем сделать промежуточную структуру, которая будет содержать в себе дерево и изменения позиции. ChangedTree PosDelta Tree.
При изменении позиции мы накапливаем её в ChangedTree. Когда нам надо получить изменённое дерево, мы применяем updateWithDelta posDelta к tree. Поскольку мы применяем лениво, то ничего лишнего не изменяется.
Это один из вариантов.
Второй вариант — ты разбираешь всё лениво. Тогда у тебя вообще ничего лишнего не запускается.
Такой вариант вполне подойдёт для указания места определения идентификатора, например. Для code completion также можно придумать какой-либо финт ушами.
В твоём энергичном случае ты работаешь с O(N) (N — число лексем или поддеревьев в файле) обновлений на каждый чих. В ленивом случае можно обойтись меньшим числом работы.
И на всякий случай — на stream processors сделать разбор в стиле Yi очень просто. Разбор на них строится таким образом, что текст подаётся в разборщик посимвольно и на каждый символ видимого текста ты можешь хранить своё продолжение работы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
. Я ожидал разницы в четверо. 
Если нам не помогут, то мы тоже никого не пощадим.
А можно развернуть этот тезис?
Декларативные вещи на декларативном DSL должны быть написаны, ИМХО. 
