10:53 pm, 18 Aug 06
speed is not an excuse
What first got me down this wacky programming-languages path was getting curious about O'Caml and its reputation for speed. Then, as an O'Caml programmer who had heard about how all the cool kids were talking about Haskell, I had avoided it because it had to be slow (strings are linked lists!).
It turns out that in completely flawed microbenchmarks, Haskell ends up being in the general range of "decently fast" -- comparable to Java and often orders of magnitude faster than than "good enough" languages like Python or Perl. (Poor Ruby is almost reliably the slowest, often by a factor of a hundred.)
There are a few lessons here: the first, of course, is that microbenchmarks are not especially meaningful. Another is that you can uglify up Haskell code to make it fast if you want to.
But the important one is that the standard "premature optimization is the root of all evil" argument still applies, even when strings are implemented as linked lists. Ruby is obviously fast enough for plenty of projects. What ultimately matters more is what will get your job done the quickest.
It turns out that in completely flawed microbenchmarks, Haskell ends up being in the general range of "decently fast" -- comparable to Java and often orders of magnitude faster than than "good enough" languages like Python or Perl. (Poor Ruby is almost reliably the slowest, often by a factor of a hundred.)
There are a few lessons here: the first, of course, is that microbenchmarks are not especially meaningful. Another is that you can uglify up Haskell code to make it fast if you want to.
But the important one is that the standard "premature optimization is the root of all evil" argument still applies, even when strings are implemented as linked lists. Ruby is obviously fast enough for plenty of projects. What ultimately matters more is what will get your job done the quickest.
One thing that has got easier over the years -- and will hopefully get even better/easier in future -- is mixing environments so that you can make trade-offs with more granularity. (.NET, JNI, Parrot, etc) Moving forward, I'm hoping for cleaner interfaces between code written in different languages so that I can mix and match within the same application.
Of course, there's also the hurdle that developers (and their employers) are generally against mixed environments for non-technical reasons. The main one is that mixed envionments are inherently more scary because they require more knowledge. I guess this reduces the pool of potential workers on a project to those who know some superset of the involved platforms/languages, while a company that standardizes on doing everything in Java (for example) needs only to look for Java developers.