Я бесконечно далёк от этих ваших акторов, но мне показалось, что с помощью подобных алгоритмов можно намного более успешно программировать с помощью Finite State Machine. Я ошибаюсь?

А вы там, когда не рассуждаете об акторах, монадах и лямбдах, код пишете?
Ну хоть чуть-чуть, а?

P.S. Сначала хотел добавить что-то обидное вроде «Теоретики хреновы», но потом подумал, что теория тоже нужна.
Было бы здорово если бы вы свои измышления проверяли на практике, но иногда и так сойдёт...

Ты всё-таки добрался до SICP?

31 Довольно долго считалось, что хвостовая рекурсия — особый трюк в оптимизирующих компиляторах. Ясное семантическое основание хвостовой рекурсии было найдено Карлом Хьюиттом (Hewitt 1977), который выразил ее в терминах модели вычислений с помощью «передачи сообщений»

Врядле оно добралось до SICP, лучше же на ЛОРе срать.

Продолжайте наблюдения.

//Моно тонок.

Я пока только вникаю, если честно, экспертное мнение высказать не могу, но мне кажется, чисто субъективно, что нет. У меня стойкое ощущение складывается (нубскоке, да), что акторы - это правильный взгляд на вещи, а Finite State Machine - лишь частный случай модели акторов. Но это - всего лишь нубское мнение человека, который бегло прошелся по верхам. Nevermind:)

Да я не поклонник теорий, но как-то учиться надо, вот и заносит. А книжки, вроде «Освой Java за 2 недели», особо тоже не вдохновляют. А код я пишу исключительно for fun:)

Вообще, я читал SICP, но дошел только до банковских счетов, ЕМНИП, 4 главы. То, что я написал, сформировалось из беглого просмотра англоязычных сайтов. Я просто нашел, за что зацепиться, и додумал сам. Кстати, на русском на эту тему почему-то вообще очень мало инфы.

Но за наводку спасибо большое, я и не знал, что в SICP эта тема обсуждается.

можно намного более успешно программировать с помощью Finite State Machine

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

http://pchiusano.blogspot.ru/2010/01/actors-are-not-good-concurrency-model.html http://pchiusano.blogspot.ru/2013/09/actors-are-overly-nondeterminstic.html

Все мировые эксперты согласны, что акторы - говно и не нужно.

Я всегда с подозрением отношусь к людям, которые употребляют фразы вроде, «dinosaur era technology», все мы знаем, что такое эти ваши нано-эры — скатывание в энтерпрайз говно.

мировые эксперты

И, btw, я запарился читать, и в упор не увидел где там «мировые эксперты»?

s/акторы/актёры/g

/thread

Негодный фикс.

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

Угадал автора по заголовку

Особенно монады. Не подскажете где они применяются, если не пишешь на хаскеле?

Везде, где система типов вообще позволяет их выразить, например, в скале.

А разве монады связаны напрямую с типами? Что же тогда выражал Даглас Крокфорд на JS вот здесь:

http://www.youtube.com/watch?v=dkZFtimgAcM

?

Даглас Крокфорд - дебил, соответственно, он мог выражать что угодно. Монады не имеют смысла (другими словами, от наличия монад в языке нет никакого выигрыша для программиста), если нельзя писать код, параметризованный в конструкторе типа. А для этого нужно система типов с HKT

Не о том речь, это было ответом на это:

где система типов вообще позволяет их выразить

Здесь речь идет о том, что якобы выразить их можно только где-то там, где есть система типов. О том, что монады - кривой костыль, и в нормальном ЯП они не нужны, никто не спорил.

Ты не понял.

Чтобы выразить абстрактный (полиморфный) концепт монады - эндофунктор с двумя натуральными преобразованиями - нужна система типов с HKT

Частные случаи можно выразить хоть на бейсике, хоть на лиспе

Д

Основная идея монад в том, что писать код один раз. Например, в Хаскелле ты можешь написать

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

один раз и использовать этот mapM для любой имплементации класса Monad. В жаваскрипте ты изобретешь по mapM на каждую монаду - соответственно, смысла в абстракции никакого нет.

  a = foo(b);
  bar(a);

я использовал монаду, что мне делать!!!!!! аааааа!!!!!!!!

Вообще, я читал SICP, но дошел только до банковских счетов, ЕМНИП, 4 главы. То, что я написал, сформировалось из беглого просмотра англоязычных сайтов. Я просто нашел, за что зацепиться, и додумал сам. Кстати, на русском на эту тему почему-то вообще очень мало инфы.

блжад, всё это уже было в SICP. Читай дальше.

ssize_t read(int fd, void *buf, size_t buf_size).

грубо ssize_t и есть монада.

Основная идея монад в том, что писать код один раз. Например, в Хаскелле ты можешь написать

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

один раз и использовать этот mapM для любой имплементации класса Monad

а как это в C++?

В какой из этих строк ты ее использовал?;-)

в '\n': последовательность действий с передачей результата первой второй - это монада. Другое дело, что в хацкеле можно обобщить и установить правило передачи :)

http://bartoszmilewski.com/2011/07/11/monads-in-c/

foo(bar(x)) - это монада?

если оно гарантирует, что bar x был выполнен до передачи в foo то да, это частный случай монады.

Фигасе... оказывается я сплошь и рядом тоже юзаю монады!

А зачем тогда разводить вокруг этого такой туманище?

потому, что ты используешь частный случай, а в общем случае можно сделать много больше. Но вообще монады это очень простая штука

«There are so many things in computer science and programming that are far harder to understand than monads. Reading code written with dynamically typed languages, implementing balanced trees, debugging numerical methods that are subtly unstable, finding memory leaks in someone else's code, reasoning about concurrent code, and so on. Some of these things never ever become easy no matter how much time you spend on them. Monads are just a one time bump with a nice payoff when you're over.» Dan Piponi.

tl;dr

ну ничем не могу помочь.. я не знаю плюсов на том уровне, чтобы объяснить на пальцах. А Бартовца знаю, он дядька толковый и в плюсах и в хацкелях шарит, так что скорее всего по делу все расписал.

чё-то он много понаписал, ИМХО монады — сущность несложная.

PS:и я просил объяснить сишнику, что делает этот странный код.

применяет функцию, принимающую значение типа 'a' и возращающая значение типа 'b' в монадическом контексте, к списку значений типа a, и получает список типа b в монадическом контексте. Что конкретно это делает зависит от монадического контекста.

примеры:

1. Reader применение функции:

> let f = mapM (+) [1,2,3] -- создает штуку, которая в применении к числу выдаст список результатов:
λ> f 5
[6,7,8]

2. Maybe - значение которое может иметь или не иметь результата.

В этом случае если хотя бы одно действие не вернёт результат, то и будет отсутсвовать результат у всего выражения.

λ> let f = mapM (\x -> if x > 5 then Nothing else Just x)
λ> f [1,2,3]
Just [1,2,3]
λ> f [1,2,6]
Nothing

3. List - много вариантов значения, соотв при применении к списку будут перебраны все варианты

λ> let f = mapM (\x -> [x,x-1,x+1])
λ> f [3]
[[3],[2],[4]]
λ> f [0,10]
[[0,10],[0,9],[0,11],[-1,10],[-1,9],[-1,11],[1,10],[1,9],[1,11]]

а есть ещё много забавных и интересных и применимых вариантов :)

да, спасибо. Впрочем, в SICP это вроде есть.

Другое дело, что в хацкеле можно обобщить и установить правило передачи

А где это нельзя? По-моему, для этого достаточно лексической области видимости, не?

можно то можно, но сложность разная, в хацкелях это очень просто, для большинства императивщины считается не нужным. В общем-то можно попробовать взять язык и посмотреть, насколько сложно там определить Maybe, т.е. берём тип изоморфный Maybe и правила редукции:

  m b ; g ,  m b = Nothing
 -------------------------   M-Nothing
         Nothing


  m b ; g , m b \in Just
 -------------------------   M-Just
         g b

и пишем как это будет выглядеть в другом языке..

А вы не могли бы объяснить, что этот код реально делает, только без этих ваших изоморфов?

//Моно тонок.

Что опять наделал Василий?

изоморфов

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

Просто дико стыдно должно быть, что ты позиционируешь себя математиком и при этом ещё спрашиваешь такие вещи. Быдлодифуры решать - не математика, дорогой мой.

А зачем тогда разводить вокруг этого такой туманище?

Да ну нафиг, никому они не вперлись в программировании. Тот же Clean спокойно без них обходится

Выше же обьяснял, пусть у нас есть указатель, который указывает на null или данные. Хочется написать следующий код:

a * v = f();
if (v) {
   return g(*v);
} else return null;

Уровней вложений if может быть много. Т.е. семантика следующая, если у нас функция вернула null, то и все вычисление возвращает null, иначе возвращается результат.

Окай, с нетерпением жду дальнейших откровений продвинутых программистов.

Тот же Clean спокойно без них обходится

я бы не сказал, что uniqueness typing - это «свободно». это, в общем-то, куда жёстче, чем в Haskell

Много на Клине написал то?

Короче хуйня которая работает как && в норм языках, но еще и значение пробрасывать позволяет.