Alvaro Videla

> But I’ve come to thinking that recommending a ton of theoretical papers is often precisely the wrong way to go about learning distributed systems theory (unless you are in a PhD program). Papers are usually deep, usually complex, and require both serious study, and usually significant experience to glean their important contributions and to place them in context. What good is requiring that level of expertise of engineers? Bingo! We need some "O'Reilly style" distributed systems material. Most of us are not going to be designing new algorithms, but plugging in various pieces. Having a generic understanding of those pieces and where they work well, and when to actually go to the research are kind of missing right now in that world. Some other links that people might find interesting: http://videlalvaro.github.io/2015/12/learning-about-distributed-system… http://book.mixu.net/distsys/single-page.html http://dancres.github.io/Pages/

I'm a relative newbie when it comes to Haskell; I've found it's best to just get stuck in - pick a project and just go for it. Especially if you're doing real-world stuff, because you'll just get sick to your back teeth of yet another fibonacci tutorial. Once you get stuck-in you'll find yourself on the Hackage docs site a lot, click on the Source link on the top right of every page, you'll find gold in there. A real world thing I did this week (which unfortunately is proprietary so I can't share), was a distributed configuration system for our cluster. It uses the RabbitMQ library[1][2] and Acid-state library[3] to have a per-node config-DB and uses RabbitMQ's guarantees for delivery of updates to the nodes. Messages are serialised using Aeson[4], the Haskell JSON library. I implemented a vector-clock versioning system on top of the Acid-state store to allow the clients to do conflict resolution. It really was a joy to write (around 350 lines of code). The C# client less so, 1000s of lines of boilerplate. I think there's something really impressive about haskell; I tend to have significantly more trust in the code I write because mostly I know the edge cases don't exist. 9 times out of 10 if your code compiles it will work. Although be prepared for the compiler to hate you when you first start. The beatings are worth it though. There's some basic code samples in the links: [1] https://github.com/hreinhardt/amqp [2]…

Anybody know whose handwritten note appears at the top? The URL includes "Knuth" and "Baker" and the initials at the top look like "CLB". (Also, we changed the URL from http://videlalvaro.github.io/2014/09/a-programmers-role.html to the original source, in keeping with the HN guidelines, which call for original sources. In this case the submitted article does add glosses, but not enough to be more substantive than the original. Historical material is particularly welcome on HN, especially when it hasn't appeared before, and this piece doesn't seem to have.)