Haskell

[[deleted user]]

I have been investing a lot of time in learning Haskell in recent months. This is not a language that you pickup in a weekend. Although I am familiar with the functional paradigm form LISP and Mathematica (which is a big part of the learning curve), there are a lot of unusual concepts in Haskell (currying, monads, closure, lambda calculus). The super-strong static typing makes it very difficult to get something to compile, but once it does, it usually works perfectly!

I have not found great learning resources. My favorite so far is "Programming in Haskell" by Hutton. It offers concise focus on key concepts in digestible chunks, but lacks big-picture material. "Real World Haskell" helps with the big-picture, and is available online at http://book.realworldhaskell.org/read/

I am totally convinced that every software engineer needs to have some exposure to a functional language to develop an alternative way of viewing programming problems. Many predict that this paradigm will become more important in the future, because of the advantages for parallelism, concurrency, and security.

I am not convinced, however, on the general applicability of a language like Haskell to most problem domains. Maybe, I just need to learn more.

For me, it was very interesting to learn the "behind the scenes" information in this chapter.

[[deleted user]]

Here is quicksort in Haskell... elegant!

qsort [:] = [:]
qsort (x:xs) = qsort (filter (< x) xs) ++ [x:] ++ qsort (filter (>= x) xs)

Uggg... can't get rid of the straggling colons, so see this link for the real thing.

http://www.haskell.org/haskellwiki/In...

[[deleted user]]

Good site for the "Programming in Haskell" book, with EXCELLENT video tutorials (at the bottom of the page).

http://www.cs.nott.ac.uk/~gmh/book.html

[Erik]

I found the contrast of language ownership interesting between the previous chapter (Lua) and Haskell. Lua final decisions were made only by the authors (Luiz and Roberto). Haskell appears to have a pretty big committee of decision makers. I don’t see either process as bad, but I think a community language is less likely to die out or not evolve.

The video URL in the book was a good watch: http://channel9.msdn.com/posts/Charle...

I was a little surprised to see them describe LINQ and SQL as “more safe”. It was interesting to see the “little languages” come up again. Calling something like C# unsafe seems a little too extreme to me. I would chose useful and potentially unsafe over useless and safe in most cases. Opportunity versus risk is probably off topic though.

[[deleted user]]

I teach computer security, so I am pretty sensitive to language safety issues. I am not familiar enough with C# to comment, but I think that there is a ranking to language safety. And, that ranking is roughly the inverse of language "power". So, I think the trade-off you describe is a valid one (and on topic) that must be considered during the language selection phase for any project.

I would say that C is safer than assembler (i.e. type checking). Java is safer than C (i.e. no pointers, stronger type checking, and the VM to check for buffer overruns). Haskell is safer than Java (i.e. extreme type checking and very limited side effects).