Schemeing in Haskell

Well, I guess this settles it. Anything Scheme can do, Haskell can do better. I think it's time to stop using a weenie language like Scheme and start programming like real men.

http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

Write Yourself a Scheme in 48 Hours

Most Haskell tutorials on the web seem to take a language-reference-manual approach to teaching. They show you the syntax of the language, a few language constructs, and then have you construct a few simple functions at the interactive prompt. The "hard stuff" of how to write a functioning, useful program is left to the end, or sometimes omitted entirely.

This tutorial takes a different tack. You'll start off with command-line arguments and parsing, and progress to writing a fully-functional Scheme interpreter that implements a good-sized subset of R5RS Scheme. Along the way, you'll learn Haskell's I/O, mutable state, dynamic typing, error handling, and parsing features. By the time you finish, you should be fairly fluent in both Haskell and Scheme.

There are two main audiences targeted by this tutorial:
People who already know Lisp or Scheme and want to learn Haskell
People who don't know any programming language, but have a strong quantitative background and are familiar with computers

>>35,36
Are you both retarded?

The statement was, "It is very hard to write slow code in plain C" -- this is bullshit, and I don't mean it any autistic sense, like that it's easy to write slow code if you want it. My point is that the language actively encourages both novice and experienced programmers to write abysmally ineffective code.

Contrast C to C++: you want to work with strings, the path of least resistance in C++ is to use std::string, problem solved. The path of least resistance in C is to use huge stack-allocated buffers and strcat (or worse, strlen-strlen-realloc-strcat, and yeah, I've seen that in the wild). It takes a lot of conscious effort to choose one of the efficient string-manipulation libraries (and God have mercy on your soul if someone else in your project chooses a different one), and it is still harder to use than the inefficient method. Same shit for, say dynamic arrays -- if you have std::vector you use std::vector, case closed, if you work in C you're more likely to thrash all your cache with your linked lists, either because you're thinking yourself very clever, or because even if you bothered to find a library implementing dynamic arrays, the plain list manipulation code still looks better. Same for linear searches vs using a dictionary.

Haskell sucks too in this respect somewhat, but at least at intermediate level nice-looking code is also reasonably fast code.