sznurek

Commenting on your second thought: I hoped that people behind DAO (and Ethereum?) will stick to the terms they themselves proposed but it seems they will push hard for forking the chain (see: Ethereum blog).

The 'Terms' section on DAO website states:

  The terms of The DAO Creation are set forth in the smart contract code existing on the Ethereum blockchain at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413. Nothing in this explanation of terms or in any other document or communication may modify or add any additional obligations or guarantees beyond those set forth in The DAO’s code.

Doesn't it state that, by definition, that DAO contract is bug-free, so it cannot be exploited? This is exactly what separates DAO case from flash-0-day-rootkit case.

I am not sure. I believe that in many cases similar activity would illegal or at least forbidden by Terms and Conditions.

I the DAO case I am not aware of any regulations or laws that the "attacker" has broken.

I have a (maybe naive) question: why is the person draining ETH from DAO called "attacker"?

I seems to me that the idea behind smart contracts was to have unambiguous description of what are participants agreeing to. The "attacker" is doing precisely this - I had not heard of any bug in Ethereum implementation that is used, only "bug" in DAO's smart contract. So he is allowed to do this, by contract definition.

Isn't the whole idea of that kind of contracts worthless if people are still rolling back effects of it when "it does not what it was meant to do"?

I would recommend "Purely Functional Data Structures" by Chris Okasaki. It's not only for functional programmers - there is also a bunch of structures useful in imperative languages.

I wrote 'monad-inspired' structure because of lack of syntactic sugar (do notation). So it basically looks like that:

  login_action = Write('PASS') >> \
                 Read('pass') >> \
                 Guard(lambda v: v['pass'] == 'mysecret') >> \
                 Write('WELCOME')
  
  register(socket, login_action, on_success=func1, on_error=func2)

Of course you can develop this idea futher:

  cat = Read('line') >> Write(lambda v: v['line'])
  cat.append_action(cat)

  register(socket, cat, on_error=handle_error_cb)

I was learning Haskell for last six months (part of my undergraduate studies).

It was (and is!) fun and challenging but I had hard time seeing any measurable profits from learning what are and how to use functors, monads etc.

Until recently when I was writing asynchronous communication framework in Python and I was searching for simple solution to sequence actions in this heavily callback-based environment.

Now everything looks so simple... (I am looking at you, monads!)

The bad part is that many people do not know what I am talking about when I try to describe them the design ;)

Agreed. My point was that uniformity will increase when content will be provided by one company (take Google Glass for example).

And you are right - it's partially happening right now. I highly doubt if website can gain popularity while being banned from Google search result.

The article missed one important scene from the video - the last one.

Maybe mind control stuff is too far reaching but consider another possibilities: for example censorship. If we would have only one news and data stream all the time in front of us, then you will be literally not able to see and hear censored things.

One can imagine that the contact lenses could remove some object from the vision in real time. Frightening.