Log in

No account? Create an account

Previous Entry | Next Entry

erlang and lawyers


I'm getting interested in erlang. It's a massively scalable actor model functional language which is agnostic as to where processes written in it run. Instead they can scale to an arbitary number of processors and pass messages to each other with minimal overhead. With concurrency built into the language from the start, you can put your application on ten times more cpus and have it run some large fraction of ten times faster.

It's also trivial to get more cpus because amazon will rent you them, and bill your credit card.


well, One thing about it is that programmers suck at writing concurrent systems at the moment... but I was thinking that lawyers (and legislators) already program concurrent systems. After all, everyone is always obeying (or breaking) the law at all times. So maybe an understanding of human law might be a useful thing in erlang programming.

Just wanted to hear your thoughts.

ETA: I'll accept what my friend aditya said and mention that good programmers who understand the hardware have been dealing with thread management and concurrency very well for ages. bad programmers are what makes the industry think concurrent systems are hard.


( 2 comments — Leave a comment )
Jun. 12th, 2009 09:36 am (UTC)
Concurrency *is* hard
Concurrency *is* hard, but it is true that one of the big advantages of agent- or actor-style concurrency is that it is reasonably straightforward to draw on the huge experience of dealing with concurrency in human organizations.

Good programmers have been dealing with concurrency for ages, true, but one of the ways concurrency experts deal with it is to limit the complexity and plan very carefully. As requirements on concurrent applications increase, this approach doesn't scale.

See e.g. Andre Pang's presentation on Erlang and concurrency:
where, among other things, he quotes a number of exceptionally bright people who claim concurrency is not only hard, but extremely so.
Aug. 16th, 2009 08:27 am (UTC)
I don't think concurrency is hard per se... I think synchronising a concurrent system is hard.

Message passing, which erlang relies on, doesn't give you any mechanism for synchronising multiple threads cheaply. If I need to send a message to a million threads in erlang I need to send a million messages. It's just one model of dealing with concurrency, and a fairly straight forward paradigm that unfortunately isn't anywhere near as efficient as shared memory concurrency in many situations.

I think for competent programmers who are going to write real performance critical software they need to understand all of the paradigms, and which to use when. I've been interested in erlang, but can't get past the fact that it ties your hands with regards to what model you can use for concurrency. Message queues are one of the simple textbook examples of how to write concurrent code, so every programmer really should be able to write that much in any language (although it is necessary to have some hardware support).

As for relations between real world analogies to concurrent problems you should read a Multi-Agent Systems Textbook.
( 2 comments — Leave a comment )

Latest Month

May 2019

Page Summary

Powered by LiveJournal.com
Designed by Naoto Kishi