agocorona

https://github.com/transient-haskell/transient

transient-universe can run Browser nodes compiled from haskell to Javascript. they can display DOM widgets and are integrated with server nodes, using websockets communications. Just compile the program with the Haskelll to JS compiler and point the browser to http://server:port. The server nodes have a HTTP server that will send the compiled program to the browser.

Haxl uses a controlling thread that spawn worker threads and is single purpose. No distributed computing in the strong sense.

transient has no controlling thread. It run multiple threads and is general purpose.

The alternative operator <|> can spawn parallel threads/or parallel distributed computations that follow the flow of the monad. for example:

    r <-   runAt node1 foo <|>  runAt node2 bar
    lliftIO $ print r

(if we need a single thread, we can use `collect`)

note that `foo` and `bar` are distributed programs as well, so they can invoke other nodes and so on.

Taking away the initializations, this is the ping pong example in Erlang:

https://gist.github.com/torgeir/3978785

    ping(Receiver) ->
      { pong, Receiver } ! { ping, self() },
      receive
        pong -> io:format("Got pong!~n")
    end.

    pong() ->
      receive

        finished ->
          io:format("Pong finished~n");

        { ping, Sender } ->
          io:format("Got ping!~n"),
          Sender ! pong,
          pong()
      end.

    pingPong receiver=  
      wormhole receiver $ do
          teleport
          lliftIO $ print "ping"
          teleport
          lliftIO $ print "pong"

Just start the program in both nodes (initialization code is not shown)

This is a distributed program but I can compose this program with any other.

This other program stream integers from a remote node from 1 in increasing order:

    streamFrom node= 
       wormhole  node $ do
                  teleport
                  r <- threads 1 $ choose[1..]
                  threadDelay 1000000
                  teleport
                  return r

    composed node =  do
         r <-  (pingPong node >> return 0) <|>  streamFrom node
         lliftIO $ case r of
              0 -> putStrLn "pong was received"
              n -> print n

This backtracking is different since it permits different backtracking points. It is possible to implement a more "civilized" version of the STM semantics this way, with more respect for IO actions.

;)

ideographic writing is more complex and less composable than phonetic writing and yet can express the same ideas.

Subjectively, a chinese can understand Chinese ideograms while maybe he find written English difficult to understand. But a Chinese would learn phonetic writing in less time than ideographic writing and would be capable to express complex ideas using the most composable writing system in less time, no doubt.

This is just random thoughts and there is much more to say. Neither I pretend to tell that OOP is wrong. What I say in the article is that the deconstruction of the recipe that OOP naturally demand is very painful and has too many drawbacks, and can be avoided with the right tools.

In the case of events, it is because I later have to store different event types in a List

so I define the list as [Event] . That is the container that feed the monad with events.

If I define Event as you suggest, I would need a existential type anyway.

    data Event a = Event EvType a

    data ListEvents= forall a.[Event a]

    x :: IO a

    f :: a -> m b

Anyway this approach has some problems that I solved in the second part