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.

Sunday, November 2, 2008

Euler and Haskell

I just started learning Haskell, which is a fun, and slightly ridiculous language-- it seems to be what happens when you let mathematicians design a programming language without supervision: It's too clever and uses way too much graduate level theory. Any language which makes frequent use of monads, functors and has a wikibook describing its relation to category theory is the result of an evil genius (or several, to be precise).

Anyway, I'm using Project Euler to learn it, at Anne's polite not-actually-a- suggestion. Which is to say, she brought up Project Euler, and I said "Oh! I can learn Haskell!" It's working rather well, and I recommend it.
Creative Commons License Cory Knapp.