Computer science research papers are funny things. On the one hand, there's all sorts of interesting stuff in them. And on the other it almost doesn't matter because the stuff just isn't accessible.
I found this out when I was doing research for Parrot, where a lot of the interesting things were done in Lisp, a language that, to a first approximation, nobody knows or cares about. I'm finding it again as I do research for Tornado where the interesting things are done in Haskell, again a language that, to a first approximation, nobody knows or cares about.
This, I think, is sad. Not that nobody cares about Lisp or Haskell (languages have to rise and fall on their own merits, and since it's all syntax I only have a limited interest in it) but rather because the relative obscurity of the languages being used makes it all that much more difficult to get some of these concepts in more wide-spread use.
As an example, take transactional memory. This is a really powerful concept that allows you to avoid a whole range of nasty problems when writing multithreaded code -- there's no worry about deadlocks or priority inversions, and in the common case where there's reading but not writing of global data it's much more performant. The problem is that most of the papers on STM express the code in Haskell with corresponding text that is written academically.
The problem is that if you don't read academic-speak (and most people don't) and don't read Haskell (which, again, most people don't) then you're just SOL. Granted, I'm not sure in practical terms it matters much for low-level constructs since most programmers aren't going to go implement things themselves, but still... for those of us who do want to implement this sort of thing it's a big pain.
More importantly, I think it makes it more difficult to recruit more people to write this sort of low-level code. Yes, it's tricky, but it's hardly rocket science. As we found with Parrot, most clever and willing programmers could do these low-level things but didn't because they were scared of them -- as an example, garbage collection terrified folks even though it just wasn't that tough. The problem was that all the literature was, bluntly, inaccessible.
So, I guess this is my complaint, or possibly my plea -- if you're writing papers about new things, by all means do your test implementation in whatever language you want, but when you write the paper? Use a language people actually know, dammit, even if you have to fake it.
Clever new things don't do anyone any good if nobody can understand the damn things. And when people don't understand them it's your failure as an author, not theirs as a reader, so... be understandable, even if you feel like you have to stoop. In the long run it'll be a lot more useful.
I sympathize, having often experienced the same thing, but you may be a little off the mark with your complaint about STM and Haskell. The original STM research wasn't in Haskell and it wasn't STM researchers who took up Haskell, it was Haskell researchers looking for a solution for their concurrency problems who took up STM. So you can hardly fault them for using Haskell.
Also, because Haskell has a much sharper line between side effects and purely functional code, it may be a better fit for STM than imperative or object-oriented languages.
Simon Peyton-Jones gave an interesting talk about STM at OSCON 2007, as well as an intro to Haskell. He's a very good speaker, so I recommend watching them--I generally prefer text over videos, but these were not a waste of my time.
http://blip (dot) tv/file/324976 Taste of Haskell, Part I
http://blip (dot) tv/file/325646 Taste of Haskell, Part II
http://blip (dot) tv/file/317758 Transactional Memory for Concurrent Programming
(long after-the-fact note, those bliptv links are bad so delinkified but left in for historical reasons and maybe if you want to look for them elsewhere with that link as a ref)
The differences between Haskell and other languages are not just syntactic. I haven't had a chance to use it, but it's very interesting.
To quite Wikipedia, the idea behind Haskell was to "consolidate the existing functional languages into a common one that would serve as a basis for future research in functional-language design".
If your work involves reading these kinds of research papers, you owe it to yourself to learn languages like Haskell and Lisp. :)
These *are* languages people know, people in the programming language research communities.
They are more effective communicating with the other experts in the field using less handicapped languages like Haskell, instead of mainstream languages. They prefer to write 5 lines of Haskell code, which often maps quite directly to the maths and thinking involved, instead of hiding the ideas in 50 lines of code in a mainstream language. Also, sometimes you need advanced features in order to build more advanced features, it's not always effective to build everything from scratch.
They are *not* automatically failures as (research paper) authors if interested "laymen" like you and me have trouble understanding their research papers.
Consider yourself very "lucky"/advanced if the only thing preventing you from fully understanding research papers is lack of Haskell/Lisp knowledge! :)
Try to read a state of the art paper in algebra or another branch of mathematics with a very long history, without having a Ph.D. on the subject first. :)
I do read Lisp and Haskell (though I admit to finding it fun to poke the Lisp guys occasionally -- they really have done almost everything you can think of decades ago but nobody knows) even if neither one of them is my language of choice for doing any work in. They seem to be the languages of choice for much of the research, which is mostly the reason for my getting grumpy about their use in papers. (Lisp in the past, Haskell more commonly these days)
You're right, though, that it wasn't really fair to poke at the Haskell folks over STM -- they found something that met their needs and they ran with it, putting out a bunch of papers on the subject. This was a nice thing for them, but I'll stand by my complaint that it doesn't do much to disseminate the experience that was gained by using them to implement the new functionality.
At the moment, so far as I can see, Computer Science really isn't. It's an engineering discipline, and doesn't really compare to things like mathematics. A far better comparison is Architecture, only our models are the end product rather than a pattern for construction.
Designing parallel garbage collecting systems and lock-free shared memory systems are important, but they're a long way away from tensor field theory. And yes, some of this is non-obvious, but like counterweights, arches, or flying buttresses, once someone has that Eureka moment most folks can get the concepts. (I'll grant here that I draw a distinction between things that are obvious in hindsight, which most engineering things tend to be, and things that still make your brain hurt in hindsight, where most math concepts lie)
That's not to say that illustrating the concepts with all the boilerplate you need to make them work in C or C++ is the right thing to do, far from it. Many of these papers require new semantics to be expressed, and for that language extensions (real or imaginary) are in order. My argument is that the concepts are better explained to a larger audience as imaginary extensions to common programming languages rather than real extensions to uncommon languages. In the case of STM, adding in an atomic keyword and maybe a transactional property for variables to a faux C program would be better illustrative than using Haskell to show the concepts.
Of course, it's always possible that there really is only an audience of 50 people on the planet who will, in practical terms, ever care about the new bits from the standpoint of implementers. That wouldn't surprise me too much either. I'm well aware that there really aren't many people who take these concepts and roll them into existing languages or design new languages for more widespread use, and is possible we're all just a bunch of cranky bastards that'll complain no matter what. (That actually seems more likely, thinking about it :)
Posted by: Dan at March 27, 2011 10:33 AMThe clojure guy touts STM strongly
Posted by: Alonzo at April 5, 2011 11:02 PM