Concurrent Programming: Erlang, Haskell...and XSLT
Dave Thomas' announcement on ruby-talk that the Pragmatic Programmers are about to publish a book on Erlang sparked some interesting back-chatter on the O'Reilly editors' list. But first, Dave's announcement:
I love Ruby--I've done all my serious (and most of my not-so-serious) work in Ruby since 2000.But that doesn't mean that I think it's the only solution--the universal language. There are always going to be areas where other tools excel.
One of those areas is concurrent programming. As the world moves to multi-core processors, and as we start to write applications distributed across intra- and internets, we need to find better ways to exploit all this extra power. If you've ever tried to write concurrent programs in Java, or even Ruby, you know the challenges.
Erlang is designed from the ground up to help programmers create highly concurrently (read thousands or processes), highly reliable (read 99.99999% uptime) applications. It's a real world language--it is used to write telephone switches, banking applications, trading systems...you name it.
I like it for that reason. I also like it because it's different--very different. It makes me think about problems in a totally different way.
We were lucky to get Joe Armstrong, one of the inventors of Erlang, to write our latest beta book, Programming Erlang.
The book isn't being officially announced until next week, but I thought the Ruby community might appreciate an early look.
First off, I'm really glad the Prags are doing this. I totally agree with Dave about the future importance of concurrent programming. There was some debate over whether Erlang was going to be the language of choice for this kind of application. But whether it's something old, or something new, the fundamental paradigms of programming are going to be challenged as systems and processors scale up. (See Nat's recent post, Threads Considered Harmful.)
Alexaholic shows the increase of traffic to erlang.org and haskell.org over the past few years, with ruby-lang.org included for comparison:
Keith Fahlgren wrote:
I think the first publisher to get somebody both involved enough to know what the latest and greatest is but not writing for an academic audience should be able to capture this nascent (but, I'm sure growing) market.
What was also interesting was the way the conversation segued over to XSLT and XQuery, both of which our tools group uses heavily. Andrew Savikas wrote about the difficulty of getting used to the programming model of these languages:
And of course, XSLT and XQuery are both functional languages -- I suspect the former is in heavier use than Lisp, Scheme, and Haskell combined. I think one of the reasons XSLT gets a bad rap is because developers try to use it like a procedural language, and discover (surprise!) that lots of for-each and if/then choose statements are annoying and clunky and maddening to debug -- not to mention amounting to fighting the recursive descent parsing built into the language, which is what makes it so powerful to begin with. Surrendering to declarative xpath matches carries its own gotchas, but is sufficently rewarding (and with the right vim bindings, the verbosity argument is a non-starter -- many complete stylesheets I've written involve maybe 20-30 keystrokes.)But as Keith points out, most of the coverage of functional programming is way too academic to be useful. Without an undergrad Scheme class, I feel like I'm feeling my way through the dark trying to grok the functional way to do things in XSLT and XQuery. Case in point, there's a crazy (in a good way) chapter in XSLT Cookbook about using XSLT for "traditional" functional programming: I've read that chapter at least 5 different times in the past 2 years, and still have no idea how to apply that stuff.
tags:
| comments: 10
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://orm3.managed.sonic.net/mt/mt-tb.cgi/1831
Comments: 10
[03.04.07 05:05 PM]
Even better (if you're trying to be pro-Haskell) than Alexa: http://www.google.com/trends?q=haskell%2C+erlang
[03.04.07 05:50 PM]
Keith, if you look at the Haskell stories that are turning up in the rightmost column, you'll see that none of them refer to Haskell programming. So I don't think that Google Trends is useful in this context.
[03.05.07 01:15 AM]
Hello Tim,
I tried to elaborate on the trend you described in this post.
The result is on my blog:
http://www.process-one.net/en/blogs/article/web_20_shifting_from_get_fast_to_get_massive/
If you have any comments I would be happy to discuss this idea further.
[03.06.07 10:41 PM]
@Mickaël,
Interesting to see your comment as I was scrolling down to leave a comment regarding the best way to see the power of Erlang in action...
Install Wildfire on one machine, ejabberd on the other, then pressure cook them both with your load simulator of choice and watch your resource meter on both machines.
For that matter, you don't even need to pressure cook them to see the difference > ejabberd takes up all of about 5-7megs when idle, Wildfire upwards of 150megs.
As Peter Fisk (creator of Vista Smalltalk; a Smalltalk and Lisp interpreter for .NET, and now Flash) said a few months back in a private email thread: "Erlang is *THE* distributed network programming language." (which makes sense, given its roots in the telecom industry)
I agree: It most certainly is, without a doubt!
NOTE: For those unaware, Mickael's company, Process-one, is the company behind the development of ejabberd, which also develops Tsung (the load testing tool of the champions!) and e-jai (decentralized/distribute application integration server built on top of XMPP messaging), something I've fallen in love with as of late > http://nuxleus.com:6180/
Anyway, amazing work, those folks@Process-one are responsible for creating!
[03.07.07 05:12 PM]
And, for one of those "wow, were they really talking about this 2 years ago?" realizations, here's a Dr. Dobbs article from March 2005, "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software":
http://www.gotw.ca/publications/concurrency-ddj.htm
via (the quite current) Feb. 2007 CTWatch: "The Promise and Perils of the Coming Multicore Revolution and Its Impact": http://www.ctwatch.org/quarterly/archives/february-2007
[03.07.07 05:30 PM]
@Keith,
The "Free Lunch" post is fantastic! I actually read and blogged about it briefly in Dec. 2004 > http://www.xsltblog.com/archives/2004/12/concurrency_par.html
[03.07.07 05:33 PM]
Ugg! The last portion of my last comment got cut off by the < pointer. What it said was that "and have continued to find inspiration from it ever since. Hadn't seen the CTWatch link before now. Thanks for the link." or something quite close to this anyway. :)
[03.10.07 02:44 AM]
"Were they really talking about this two years ago?"
Well, multi-processor systems have been around before the advent of multi-core chips. They just weren't mainstream. Pekka Hedqvist wrote a Master's thesis on SMP Erlang already back in 1998 - had a working prototype too.
http://www.erlang.se/publications/xjobb/0089-hedqvist.pdf
One may also note, quite unscientifically, that searching for "parallel" in the erlang-questions mailing list yields 26,800 hits, while doing the same on ruby-forum.org gives some 6-700 hits.
One may also add to Peter Fisk's statement a similar one from Microsoft Senior Researcher Todd Proebsting: "[Concurrent Programming] Erlang... I'll propose it as THE answer" (MIT ll2 workshop 2002, http://web.mit.edu/webcast/ailab/mit-ll2-s2-09nov02-80k.ram, ca 33:30-37 minutes into the video)
[03.13.07 07:18 PM]
Tim,
Well on the one hand I am honored that you actually read one of my chapters five times, but on the other hand it is depressing that I was not clear enough to get through to some one like yourself!
Truth be told, I don't often use those techniques in XSLT but, as a general approach, functional programming has a lot to offer. Although you will often hear more about Haskell, ML, and Erlang, I find the Mathematica language one of the best functional languages I ever worked with because of the way it marries the functional style with a rich rule based style. In fact, the only bad thing I can say about Mathematica would be it price tag.
I think as we move into the brave new multi-core world the functional approach will receive more of the attention it deserves.
Post A Comment:
Radar RSS feed
chromatic [03.03.07 08:59 PM]
Is the top line in the graph traffic to ruby-lang.org?
I (almost) can't believe Alexaholic thought it was a good idea to use red and green as the colors of the second and third lines. I can nearly distinguish between them.