Teenage Haskell

'All members of this [ALGOL] family are made from more or less the same material and for the same kind of programmers - those who love the machine more than the problem.'

Contrast with Lisp: 'a language that would help programmers solve problems without forcing them to think about the elements of a machine.'

So it really depends on one's interpretation of 'Computer Science', and the choice of what to prioritize from the subject: engineering or ideas.

Interesting question. My first language was (Common) Lisp. Not sure if it was a good or bad choice (wasn't a choice really, more of a coincidence), or if those terms even apply. Anyway, I'm fairly certain it took me much longer than necessary to get my first projects done (hint: some of them were never finished). I spent a lot of time trying to express my ideas in a functional style -- avoiding the loop macro, avoiding side-effects whenever possible etc. Slowly but surely drifting away from the actual problems I had set out to solve.

The feeling I got when I discovered Python is very accurately described in that xkcd comic which pops up in your browser when you type "import antigravity" in the interpreter. Then again, if Lisp was a detour on the path to becoming an "efficient and productive programmer", it was certainly a deeply interesting one which left me hungry for more -- I'm learning Haskell now (who isn't?) and am enjoying it immensely.

So, what made learning Haskell a good experience I think was mainly the strong type system. You could basically even early on use functions you barely knew what its name meant solely based on its type signature. It also made the progress of writing a program very nice, you write it and then it fails, you go back and try fix it, and when it compiles it usually worked.

There are some things to keep in mind though. Wild recursion is really the GOTO of functional languages, it's important to teach how to use the generalized folds and traversals early on. Secondly it is important to have simple analogies to concepts such as functors, monoids and monads etc. If you make sure to not care about these strange names then you can go pretty far by just trying to make the type signatures stick together, and it's not important for a beginner to grasp these directly either.

Python was quite smooth to learn coming from Haskell, the syntax is similar and it simply felt like programming in Haskell's do-blocks. It was very easy to get quickly going, I managed to write a little script talking to a JSON API almost directly after reading the official tutorial. I also digged a little bit into the realm of OOP, I wrote a simple game using Kivy. It felt quite nice actually, I could get some code re-use, although it was harder to get that (as newbie) than in Haskell.

EDIT: Something like typed Racket might been even better when I think about it, since Racket got a lot of resources for complete beginners. Then you get the benefit of easy to use syntax too, although syntax is probably not the biggest problem when starting out. For the record I usually recommend Python or Racket when people ask me where to start, because in the end I don't think it matter much what language you go with first, just make sure not to limit the paradigm of languages you learn afterwards.

"doesn't seem like you got it" ... "purposefully not getting it" ... "principles [..] undeniably the best".

No, you like those principles best, and that's about the most you can say. We don't even have solid criteria with which to make that call, never mind there being any type of consensus as to which is "best" (except within specific communities, but with each community having a different consensus and the most closed-minded of these communities usually the most sure of themselves).

Just to head off more ignorant comments: I aced those courses, as well as a few more including the elective "foundations of FP" and did my oral exam on Backus's FP calculus, which inspired me to come up with Higher Order Messaging: http://en.wikipedia.org/wiki/Higher_order_message

I also did some courses on algebraic specification and graph grammars (related to category theory), as well as formal specification with Z (yes, aced those as well). While useful in certain very constrained areas, these techniques trade making the smaller problem better (spec -> code) for making the larger problem ( actual problem -> spec ) infinitely worse.

Of course, functional techniques are a part of my toolbox, as they should be for any professional. However, if they were the only contents or even the majority of my toolbox, I couldn't do what I do and have been doing for the last quarter century.