I love how it's titled "Simple Example". I don't think I'm ready to delve into Haskell, much less an abstraction embeeded within it. Maybe Clojure for another 6 months and then we'll see.
Reading Haskell is not that hard, but working with Clojure won't help you with it, unfortunately. Try OCaml or F# (or maybe Scala) for a more beginner friendly introduction to most of Haskell concepts.
Most of the complexity of needing Data.Dynamic has to do with the way we store the heterogeneous collection that is our observed data. There is a nicer way to do this which I hope lands in a future release.
A while ago I tried to port some of the Python code from the book Programming Collective Intelligence to Haskell, and I got stuck on the seemingly simple problem of reading and processing heterogenous collections (strings and numbers).
So I don't really consider myself a Haskell programmer, but the standard advice is to think about operation you are going to perform on those strings and numbers later, then think if there is a datatype you could create instead.
As an example, suppose I am trying to load a csv file with two fields being strings and one being Double. A list of lists representation isn't going to cut it. Instead I should make a Row datatype
Then you can parse the csv file into a [Row] representation.
As an aside, if the task did involve parsing csv I suggest the cassava library which I found out about through the amazing What I Wish I Knew When Learning Haskell (http://dev.stephendiehl.com/hask/)
data Datum = S String | D Double
lst :: [Datum]
lst = [S "a", D 3.14]
In Python we'd have to write the logic to handle both cases and fail with an exception or do an instanceof check. In Haskell we'd do this by pattern matching on the sum type.
case (lst !! 42) of
S n -> -- handle string
D n -> -- handle number
The things that make haskell and ocaml outwardly different are the pattern match syntax for function definitions, type signatures, the IO monad's slightly different syntax, all the category theory structures and their punctuation filled names, "<*>", and, you know, all that "theorems for free" and Curry-Howard stuff. But to get started, there's LYAH and (3)good tutorial books by Alejandro Mena, Simon Thompson and Graham Hutton, you can type expressions in to GHCi (the REPL) and see what types GHC infers, and you can, uh, encounter GHC error messages and warnings for the firs ttime.
Monads aren't really imperative, though the syntax sugar sometimes looks like it, but in any case that's too fine a point. You know what I meant. Pseudocode usually looks like this:
x := 1
while (x < 100)
stuff(x)
x := x + 1
etc, etc. Typical Haskell doesn't look like this. The example didn't look like this. Clojure won't look like this, either (in fact, it's likely to look even weirder than the Haskell example). That's neither good nor bad; I don't think programming languages should be judged by how much they resemble C/Pascal/Python/pseudocode.
Comments
I love how it's titled "Simple Example". I don't think I'm ready to delve into Haskell, much less an abstraction embeeded within it. Maybe Clojure for another 6 months and then we'll see.
Reading Haskell is not that hard, but working with Clojure won't help you with it, unfortunately. Try OCaml or F# (or maybe Scala) for a more beginner friendly introduction to most of Haskell concepts.
I recommend "Learn You a Haskell". Free online.
It really is a very simple language. The ML languages (and Haskell in particular) are just rather different and initially hard to read.
As someone who can Haskell, I can reassure you that the example is indeed simple. But I understand your concern.
It is indeed simple, though the use of ``Data.Dynamic`` raises a few eyebrows.
Most of the complexity of needing Data.Dynamic has to do with the way we store the heterogeneous collection that is our observed data. There is a nicer way to do this which I hope lands in a future release.
A while ago I tried to port some of the Python code from the book Programming Collective Intelligence to Haskell, and I got stuck on the seemingly simple problem of reading and processing heterogenous collections (strings and numbers).
What is the nicer way to do it?
So I don't really consider myself a Haskell programmer, but the standard advice is to think about operation you are going to perform on those strings and numbers later, then think if there is a datatype you could create instead.
As an example, suppose I am trying to load a csv file with two fields being strings and one being Double. A list of lists representation isn't going to cut it. Instead I should make a Row datatype
Then you can parse the csv file into a [Row] representation.As an aside, if the task did involve parsing csv I suggest the cassava library which I found out about through the amazing What I Wish I Knew When Learning Haskell (http://dev.stephendiehl.com/hask/)
Use a sum type:
In Python we'd have to write the logic to handle both cases and fail with an exception or do an instanceof check. In Haskell we'd do this by pattern matching on the sum type.this was written for getting an intuition about the syntax:
http://blog.ezyang.com/2011/11/how-to-read-haskell/
The things that make haskell and ocaml outwardly different are the pattern match syntax for function definitions, type signatures, the IO monad's slightly different syntax, all the category theory structures and their punctuation filled names, "<*>", and, you know, all that "theorems for free" and Curry-Howard stuff. But to get started, there's LYAH and (3)good tutorial books by Alejandro Mena, Simon Thompson and Graham Hutton, you can type expressions in to GHCi (the REPL) and see what types GHC infers, and you can, uh, encounter GHC error messages and warnings for the firs ttime.
Out of curiosity, which part of the example did you find difficult?
Haskell bears very little resemblance to traditional pseudo-code, compared to something like JavaScript.
True. Traditional pseudo-code tends to be imperative.
I think you'll face a similar problem with Clojure :)
Since the example used Monads, it was rather imperative.
Monads aren't really imperative, though the syntax sugar sometimes looks like it, but in any case that's too fine a point. You know what I meant. Pseudocode usually looks like this:
etc, etc. Typical Haskell doesn't look like this. The example didn't look like this. Clojure won't look like this, either (in fact, it's likely to look even weirder than the Haskell example). That's neither good nor bad; I don't think programming languages should be judged by how much they resemble C/Pascal/Python/pseudocode.