Long live Lisp
Dec. 6th, 2007 01:43 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
izardThis article requires some current technical background so the whole post goes under a ljcut. I'll try to post new photos of local fauna family life when I have some time to process those. Hopefully in a week or so (I've quickly grasped local slow notion of time).
It's all about concurrency. As an Application Engineer, I often spoke at Intel and partners (e.g. Microsoft) events and delivered trainings on how to design scalable software. After ~2 years dealing with s/w engineer who could not tell spin lock from mutex, I've finally convinced myself that this kind of education is an important task indeed, rather then just an excuse to meet new and interesting people.
During last 3 years I've collected enough evidences to become confident that the best way to deal with complexity of designing scalable and correct parallel code is using functional programming (not pure though). For example, there is an AMQP broker implementation that is perfectly scalable at least up to all Intel Caneland cores. It is written in just few thousands lines of Erlang/OTP code. Competitors that I will not name here, but you could use google had clearly spent some more interesting budgets for similar functionality and slightly worse scalability.
OpenMP, Intel TBB are only a palliative care, not the cure to the complexity problem. Ct is a niche solution. Transactional memory is better, but still not the answer. The answer is [impure] functional programming _and_ STM. I had been spreading this statement around my colleagues and customers who dared to listen, and mentioned in the blog once. The biggest obstacle is programmers mentality and education. Essentially it is easier than learning to use imperative synchronization in safe and scalable way, but it requires a different point of view. This problem even dwarfs legacy compatibility issues that come to the mind first.
So, for one of my toy projects, I was looking for a functional language that generates efficient code. (And I was not considering OCaml). By generating efficient code, I meant either good byte code for JVM or decent C. Thus I could choose from several lousy unsupported lisp dialects and Scala.
Recently I've discovered a Clojure. It was released few weeks ago, and it took several years of work of one smart guy. I like it despite it's alpha quality and lisp. Main reason is it has a very solid architecture of concurrency based on Java threads and java.concurrent built in. Also it allows meta programming (it's just a nice bonus for me, I am not a big fan being too dumb for utilizing such high order abstractions safely). Last but not least Clojure will always generate high performance code utilizing JIT optimizations engineered by people from Intel, Sun, IBM. (Hi, Chris, Yury and Sergey :) )
So it's great there is
To be continued...
It's all about concurrency. As an Application Engineer, I often spoke at Intel and partners (e.g. Microsoft) events and delivered trainings on how to design scalable software. After ~2 years dealing with s/w engineer who could not tell spin lock from mutex, I've finally convinced myself that this kind of education is an important task indeed, rather then just an excuse to meet new and interesting people.
During last 3 years I've collected enough evidences to become confident that the best way to deal with complexity of designing scalable and correct parallel code is using functional programming (not pure though). For example, there is an AMQP broker implementation that is perfectly scalable at least up to all Intel Caneland cores. It is written in just few thousands lines of Erlang/OTP code. Competitors that I will not name here, but you could use google had clearly spent some more interesting budgets for similar functionality and slightly worse scalability.
OpenMP, Intel TBB are only a palliative care, not the cure to the complexity problem. Ct is a niche solution. Transactional memory is better, but still not the answer. The answer is [impure] functional programming _and_ STM. I had been spreading this statement around my colleagues and customers who dared to listen, and mentioned in the blog once. The biggest obstacle is programmers mentality and education. Essentially it is easier than learning to use imperative synchronization in safe and scalable way, but it requires a different point of view. This problem even dwarfs legacy compatibility issues that come to the mind first.
So, for one of my toy projects, I was looking for a functional language that generates efficient code. (And I was not considering OCaml). By generating efficient code, I meant either good byte code for JVM or decent C. Thus I could choose from several lousy unsupported lisp dialects and Scala.
Recently I've discovered a Clojure. It was released few weeks ago, and it took several years of work of one smart guy. I like it despite it's alpha quality and lisp. Main reason is it has a very solid architecture of concurrency based on Java threads and java.concurrent built in. Also it allows meta programming (it's just a nice bonus for me, I am not a big fan being too dumb for utilizing such high order abstractions safely). Last but not least Clojure will always generate high performance code utilizing JIT optimizations engineered by people from Intel, Sun, IBM. (Hi, Chris, Yury and Sergey :) )
So it's great there is
To be continued...
