Scheme Death Knell?

As a subject of minor annoyance, Lambda the Ultimate has a bit suggesting that someone translate Hofstadter's Scientific American columns introducing Scheme to a general audience into Haskell. Yet more evidence that Scheme is losing its "cool" factor.

The thing is, I don't think there's any good reason for it. There is nothing wrong with Scheme. I think the only actual reason that people switch to Haskell and so on is just to jump a train. Scheme's been plugging along since 1975, and people therefore think it's time for something new.

Why Haskell? Here are the commonly-cited reasons:

• Haskell is Purely Functional - apparently, Haskell is a purely functional programming language. Scheme has some impurities floating around herer and there. Well, wonderful. But I don't see the big deal. I mean, can it be a bad thing to allow some (limited) flexibility in the paradigm? I really do think this is going to be the hallmark of the next 5-10 years of PL design - this insistence on pure versions of various paradigms. And I also think it's silly. It's one thing for a language to support a particular paradigm and encourage its use, but to choose one paradigm exclusively is to deliberately exclude classes of users. But OK, ya'll have fun making your loop objects in Ruby, or doing monadic I/O in Haskell. Don't let me spoil the fun!
  


• Monads - not that anyone actually knows what these are, but Monads are the shit, let me tell you. So this is the functional programmer's OOP. Monads are supposed to be some kind of huge foundational paradigm shift, but all they really are is a way to introduce sequencing and side-effects into the "purely functional" programming languages. Which of course just illustrates the point above: there is no sense in having a purely functional programming language!. Now, actually, I'm being too harsh. Monads may not be strictly necessary, but the fact that they had to be discovered to make Haskell work properly has led to more than one insight (demonstrating that seemingly unrelated computations in fact have related forms) in computation theory. So Monads are useful. It's just that it's a bit embarrassing to watch the Haskell people go all glowy over something that started out - let's be honest - as a workaround. They're scaffolding for people who like to pretend that programs are proofs - that programming is just math. But programming is more than that and we all know it.


• Call-by-need - I can never put my finger on just why, but I think this is largely hype too. For those not in the know - "call-by-need" is one broad category of functional semantics a programming language can exhibit. The main ones are call-by-value, call-by-reference, call-by-name and call-by-need. The overwhelming majority of PLs use call-by-value. This means two things - broadly: (1) when you pass a value to a function parameter, the function will not change the value passed. It may perform operations on it using private variables, but it will not actually change the caller's value unless you ask it to. This is distinct from call-by-reference, where variable names all refer, thoughout a program, to the associated memory register. In call-by-refernece, when you name a variable inside a function x, it's the same x as any variables by that name outside the function. Parameters passed to functions are the same as the variables associated with them. Run-time efficient, but computationally confusing. (2) Arguments are evaluated before being passed to the function. This is the disctinction with call-by-name. In call-by-name, arguments are passed as they are to functions. So - to use one of Friedman's examples - the difference can be seen in the return value of this function:
  
  
fun x = x + x

  
  Looks like a function that doubles its argument, right? And under call-by-value it is - becuase x gets evaluated before it's passed. But with call-by-need it isn't necessarily. If we said:
  
  
x(random 10)

  
  we might not get double anything - might get an odd number. And that's because in call-by-name what gets passed is (random 10) itself. So for each x in the body it is reevaluated. This seems silly, but it's actually very useful in some cases because it prevents code from being unnecessarily evaluated. In addition to sometimes being an efficiency gain (though not always), this has the huge advantage of minimizing chances of going into infinite loops.
  
  Well, call-by-need is supposed to be the best of both worlds. It has the lazy evaluation of call-by-name, but once an argument has been evaluated it also remembers that value so that the semantics come out right - i.e. our example function is a doubling function for all arguments again.
  
  I dunno - I can't prove it but I think there's something cheesy about this. It's another smug Haskell pretend solution - something just tells me so. On the documented side - it is true that evaluation order becomes a problem here. I won't give a motivating example because I think this is probably obvious from the example above. Now, evaluation order isn't always such a big deal in functional langages (especially, one presumes, in purely functional languages...), but it could still be annoying I think. But until I can come up with something better than "evaluation order problems," I think I'm going to have to admit that this feature of Haskell is indeed Very Cool. After all, evaluation order problems are less severe than the enhanced potential infinite loop problems that Scheme's call-by-value paradigm has.
  

So anyway - lots of the stuff that's supposedly cool about Haskell is...well, cool, but maybe not as cool as we're often led to believe. To all of the above I just want to say: I admit that call-by-need is probaby cool. Monads are cool too, but maybe not to the extent people wet their pants over them (and anyway they're supported in Scheme too). The purely functional stuff is crap and is actually an argument against Haskell, in my opinion. But then, I underestimate the extent to which some people are born with the functional programming gene.

In any case, I think Haskell is a fad, and one that has already peaked, at that. It's here to stay, don't get me wrong, but it definitely isn't the Next Big Thing - neither in the functional programming subculture nor in the real world of industry programming.

Which is why I get a little annoyed that so many Haskell hackers think Scheme should just step aside. This town's definitely big enough for both of us, thanks partner.