Arbtirary thoughts on nearly everything from a modernist poet, structural mathematician and functional programmer.

Monday, November 24, 2008

Developing in "impractical" languages

So... functional languages, in the case of ones I know, Scheme and Haskell, are often called "impractical" for real applications. Due to the small libraries, this is mostly true of scheme, but it is only because scheme libraries are small... It is not true of CommonLisp, or Haskell, or OCaml, or ...

The most common argument is that they run slower. This falls flat for OCaml, which outpaces basically everything (that means you, imperative language) except C; also, CL is one of the faster languages around. But everywhere I look in relation to Haskell has some sort of argument about it being "slow and impractical".

Let's look at the cost ($$) of developing and running a piece of software written in C vs one in Haskell. Also let's assume that it is computationally expensive (uses a lot of CPU power).

Now, everywhere I've looked, suggests developing in functional languages is at least 2 times (actually closer to 3 or 4 times...) as fast as developing in their imperative counterparts. But! We'll give C the benefit of the doubt, and say that developing in Haskell takes 2/3t (e.g. if a C program takes 3 months to develop, it will take 2 months to develop it in Haskell).

Now, we'll continue with a conservative estimate of $40000 a year for a programmer. For a job which requires a BS in CS and "several years" of experience... this is a modest (and, quite frankly, bad) pay... but programmers love their jobs, right?

Now, a decent (but not huge) project is going to take, say, 9 months for 5 programmers to write in C. So 6 months in Haskell. This means the development cost of the C program is 5*40000*(3/4) = $150000. The Haskell program? 5*40000*(1/2) = $100000. Obviously, since we're looking at 2/3 the cost.
Now, we've just saved ourselves $50000. That's more than the salary for a programmer for a year!

But! We've got to take into account the extra amount of computation required by the Haskell program. Since the differences are constant (not asymptotic), and Haskell is ~3 times more "expensive" than C, we're looking at just getting a better computer here... We'll say one that's "twice as good" (whatever that means), which isn't quite enough, but we've been giving C the benefit of the doubt this whole time...

So, getting a computer that's "twice" as good is going to cost the average person less than $1000 extra-- $150 for RAM, $150 for a CPU and $200-$300 for video card: less than $600. Let's say $750.

So, in order for the imperatave program to be more efficient, all around, economically, there need to be roughly 50000/750 = 75 copies...
Hmm... that's not too much, now, is it?

Giving programmers more money (hurray!) increases this number some, but not all that much... However, there are a few things to note:

(1)In reality, every study/anecdote suggests about 2x speed with functional development. This means we have ourselves $100000, so 150 copies... still small...

(2)Giving programmers $50000 a year (on average... this includes project managers, etc) means an extra $25000 (given (1), above)

(3)The cost of hiring good programmers is not decreasing very fast... the cost of upgrading computers is. So in 5 years, this whole thing is going to be stupid.

(4)Most substantial programs take closer to 10-20 people 1 to 2 years (in C). Given (1) and (2), that's at least 400000 (taking 15 for 1.5 years, that's 1.125Mil). In Haskell? For 15 people it will take .75 years, so that's 562500. We've saved just under one million. So we can now sell almost 1000 copies... still not much.

(5)This is Haskell vs C. In reality, development is done in a combination of C and C++. OCaml performs only moderately slower than C (and faster than C++), and CL is only slightly slower than C++. So, working in OCaml will save about the same amount of time, and won't cost much (any) more to run; developing in Lisp will only cost a tiny bit more to run, and won't be much (if any) more than OCaml... especially with Macros, and CLOS.

(6)There are very, very few applications where performance matters that much... Rendering is just about the only common task. So the "It's too slow" argument is dumb anyway.

My point is: People see that Functional Languages are experimental (theoretical) hotbeds, and say "Oh, they must only be good for language theory"... This is not the case. They are, mostly, only a tiny bit slower to run, and are significantly faster to develop in...
Also, pugs, and darcs

Edit: So, I got my orders mixed up... (Actually, I was looking at an incomplete ranking when I said OCaml and Lisp are fast). The best way to look at things is: The Computer Language Shootout! Look at rankings... play around with what does what... etc.


Don Stewart said...

I think you could be a bit more concise :-)

Check the performance of functional languages on the multicore shootout,


And then check the numbers of libraries for Haskell,

on Hackage.

So we're neither short on speed, nor libraries. Making the equation more attractive than in the past.

Cory said...

Nice. Thanks. As far as libraries, I was actually talking about scheme in particular. I'm a rather young programmer, and am rather new to functional programming in particular, so scheme and Haskell are the only two for which I can justly argue. Haskell libraries are ridiculous... "Oh, you're implementing a turing machine simulation in the game of life? Isn't that on Hackage?"

As far as multi-core things: I forgot about this entirely. I really don't know what I'm talking about, but I assume functional languages can really take advantage of this...
If we have f (g h x y) = (g x) . (h y)
Then we can send (g x) and (h y) to different cores, and send their results back to f, right?

Anyway, the point of the post was to give C the benefit of the doubt at every point... And then come back through and point out the absurdity of the situation I described.


Brian said...

Sorry for the late comment.

1) I think you're way underestimating the cost of developers. Given all the ancillary cost- support staff, office space, insurance and benefits, etc., it's not unusual for a programmer to cost $50K or more above and beyond their take-home pay. So costs more in the $100-$150K a year to put a developer into a seat isn't unusual.

2) I also think you're underestimating the productivity enhancements of functional languages such as Haskell and Ocaml. Strong static typing is a huge win, as it catches bugs early and cheaply- 90-99.5% of bugs are caught by the type checker in my experience. Projects have to vague phases- writing the code, and debugging the code. When the Ocaml/Haskell programmer has finished writing the code, they're most of the way done with the project- but when the C/C++/Java programmer is done writing the code, they're less than half way done with the project.

3) While C/C++ are the fastest languages, most development is not done in them. Haskell's performance is quite comparable to Java or C#'s performance (Haskell is faster on some things, slower on others, but overall comparable), and it's pwns languages such as Ruby, Python, or PHP for performance (even if written in a "high level" fashion).

Note that all of the above just reinforces your point.


Cory said...

Oh, indeed! I hadn't considered overhead for keeping programmers on staff, and my "analysis" (if it is sufficiently thorough to deserve the title) is devoted entirely to C/C++, which Haskell is closer to in speed than I originally thought (I'm new at this!), Ruby/Python/Perl are far too slow for this-- but they are also labeled as "impractical toy languages", and are also the primary reason for the bias against non-C languages with higher level features: the critiques are mostly correct when applied to Ruby and Python. (But still miss the point that development is faster).

I hadn't considered debugging... a vast oversight.

This was mostly a thought experiment for my own benefit, and I figured others may take interest... I'm still surprised that it has actually raised any interest at all-- I get the feeling that Don prowls the blagosphere looking for posts about Haskell that he can comment on. :)

Thanks for the comment,

Creative Commons License Cory Knapp.