C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13

Hungarian notation: An artwork from hell. On the other hand, you are right, using this naming pattern, is kind of in the spirit of Hungarian notation, so I guess the hate-level has to be toned down a little, because it really is quite pretty. I don't quite like xs as much as s anymore because if you just say xs and you have to decompose it into locals in C#, then you need to save x and what's the rest of xs? xss? So in C# at least, without pattern matching it appears to be a little better with s decomposes to x and xs as in first of s and rest of s. I forget but seem to remember that you can pattern match a list in some languages using x:xs so here the parts are already decomposed into a pattern and you don't need the s to denote the whole, as the relevant parts have been named in the pattern. A reason for xs as name is also that it means you align well with the empty list case [].

The infix notation is not quite as nice as the prefix notation due to the quotes but in a proper editor, these could be removed from view and the infix operators could be specially formatted to reduce noise.

Object-oriented vs Function-oriented (aka Functional): Intellisense is nice but how about looking up locals based on what fits in the slots - if you pick product, then any local that fits into this will be shown. Well...

I love the short-code love and am reminded by sentence by Brian Beckman in a previous interview: "Shorter is almost always better." There Brian was talking about short as a more direct way to express simplicity; because shorter may be seen by some as more complex - the same is equally true for longer: imagine a short Haskell program compiled to X86 machine code, it too will be complex for many people, but as Brian says, everyone agrees on what short is.

I wasn't aware of the pervasiveness of transparently switching to "bignum" when necessary in these languages. That is quite beautiful. It adds another layer of transparency. You don't need to concern yourself with hardware limits of machine types.

One note on the presentation style: Erik you appear a little short of air at times, maybe thinking faster than you have air ready. (Well, and you kind of pronounce bloat as blood ;o) )

I wonder if ≤ and ≠ are legal function names in Haskell and defined in the Prelude. It would be nice - also, in this style discussion - because visually it makes the code more homogenous and aligned (≤ and > will take up the same space). And of course in C# we have to use if (..) else if (...) which completely messes up this homogeneity.

Excellent again!

OK, exercises. Defined it in C# after the first exercise but it's non-sensical for infinite lists - this is where non-termination (⊥) comes in handy

lastx xs = head (reverse xs)

... The |> looks like the solution to the problem of intellisense; when you write: [1,2,3] |> you are in a way making [1,2,3] the most important thing and |> becomes like the dot which fires off intellisense. And then ofcourse if you can use infix notation, Intellisense could help suggest functions as infixes given the first value (on the left) while the remaining values are unspecified.