I cannot overemphasise how much easier it is to understand Monads once you've groked Functors and Applicatives. It allows you to build an intuition for the _general_ structure and purpose of the typeclasses instead of trying to start with Monads by viewing them through the lens of IO or State.
Learn you a Haskell for Great Good is definitely an awesome book to get a handle on Haskell.
As the article says, it starts off from the basics and just quickly enough builds up from there to wherever you want to go. I stopped once I got distracted by writing useful-ish code :)
Also it's completely mindblowing, but irrelevant, that my high school classmate wrote that book.
LYAH is definitely a great starter but if you have an OK background in functional programming (Scheme/ML) you may find, like I did, that you probably want to bail a couple chapters in. Real World Haskell is probably your next step -- most of what you want to do can be found there.
As soon as you start developing a serious application in Haskell, though, I've found you eventually need to jump back to Hudak's Gentle Introduction to Haskell[1], the Haskell 98 Report[2] (I suppose the 2010 report works too, but I haven't used it as a resource nearly as much), and Hoogle/Hackage for the Haskell source of any library which you want to use seriously.
It's even more mindblowing that he's still my classmate ... sort of. Everyone flunks around so much at our faculty that it's hard to define what a classmate is.
I disagree with the order that this suggests learning stuff. The article recommends first playing around in the functional subset of the language in the REPL, then learn about theory of monads and finally put it into use with IO.
I feel it's better to jump straight in to IO after doing some basics and definitely before trying to learn deeper theory about monads. The second or third exercise you write should have a little I/O in it, do something like a guess the number or hangman game. I've found that it's also useful to first write it normally using "do" notation and then manually transform it into concrete syntax using ">>=", either mentally or actually writing it out compiling/running. This is a very simple (1 to 2 hour) exercise but should give a pretty good picture of what it's about.
This is a way to avoid the most common pitfall there is in learning Haskell, "not getting monads". There are lots of people who learn the basics of functional Haskell, but they are so afraid of the new concept of monads that they cannot get to writing a real application. I've seen people get stuck in this limbo for years.
Once you know enough I/O to open a file or run a simple loop, the horizons of your Haskell programming projects are vastly extended. If you can read and write files, you can get your hands on more and more interesting data to use for your apps.
Of course, people are different. If you're the kind of person who enjoys reading books about theory (and not the learning-by-doing type), just ignore everything what I just said and go enjoy a book or a wikipedia article about applicative functors, monoids or category theory.
(I don't know pretty much any theory about functors or monoids but it doesn't stop me from writing parsers, compilers and 3d graphics tools using Haskell. Just as not knowing theory about attribute grammars or LALR(1) parsers did not stop me from writing stuff in C.)
This is a bit of a tangent, but can anyone provide an opinion on which of the static-typing big 3 (Haskell, SML, OCaml) is most suited to scientific computing?
It's going to depend a lot on what you're trying to do and what your personality is like.
OCaml is probably the most pragmatic of the three, but the parallelism and concurrency story is pretty weak. There is a book, OCaml for Scientists, which is a tutorial intended for the scientific audience though. It's also heavily used in finance. It also compiles quite fast.
Haskell is the hardest of the three to learn and get up to speed with. If you have a heavy mathematical bend, it may make the most sense. Parallelism and concurrency are simple and easy, but I don't know if you can do MPI or OpenMP style supercomputing; it really seems optimized for desktop/server processors.
I love SML for its simplicity, clarity and power, but it is essentially a dead language at this point, with most of its userbase having migrated to Haskell or OCaml. I don't know if Concurrent ML supports true SMP, but that would leave you limited to certain implementations. MLton is fantastic, but it comes at a price of very slow compiles with no separate compilation.
If I were in your shoes, I'd look at some sample code in OCaml and Haskell and see which one looks more reasonable, and then write a small program in each and see which one you like the feel of more. You're probably going to run into a sticky spot at some point in your project whichever one you choose; the more you like the option you have, the more likely you are to stick it out.
That depends on the kind of scientific computing you want to do.
Haskell has the repa library [1] which is very nice for working with (multi-dimensional) arrays at a high level. Performance is decent (I don't know if they have a BLAS/LAPACK binding). Overall, the main advantage of Haskell is its runtime system and its great support for concurrency. The downside is, it does not have OpenMP and the MPI bindings don't look very nice to use (I don't know how OCaml or SML fare in this area). There are OpenCL bindings, but I've never used them. Data parallel Haskell is still under heavy development, so that's probably going to take a few years to become production-ready.
OCaml's advantage is that C-like algorithms are easier to transcribe and use (no monads). OCaml's main disadvantage is that its runtime doesn't support multicore well (or even at all?). If you want that you can use F#, though.
I don't know anything about the current state of SML implementations.
Answering a sub question of yours: Indeed the only way to use more than one core in OCaML is to use multiprocessing. If there is a lot of data that needs to be exchanged, it may not be very fast.
That said there is this patched up version (funded by a one off summer of code by Jane street, I think)
I am ok with OCaML not giving its users a threading API but a runtime that executes many of its higher-order functions in parallel would be really nice. Well, higher-order functions and the other parallelism exposed by the functional semantics, with some helpful directives from the user of course.
There's been a lot of projects, of which the ocamlnet/netmulticore and Jane St async's are (I think, but not very confidently) the only current. Others are:
There's also hmatrix for a pretty nice Haskell API over blas. The one current caveat is that because certain vector code currently uses GSL under the covers, the core hmatrix lib has to be GPL in turn (as GSL is GPL). That said, there's some work underway (by me and some others) to replace the offending pieces of code with some under bsd or other permissive license so that core hmatrix can be rereleased as a bsd licensed lib and thus see broader use.
Actually, I would probably bet that SML with MLton is the fastest (in some benchmarks) by a fairly large margin, but I can't find any up to date benchmarks.
Haskell is usually about 1-10x slower than C for the same task, while MLton has actually outperformed C in some benchmarks.
Edit: My information is out of date -- dons is almost certainly right on this one. I'd go with his estimation.
MLton has been mostly unmaintained for 5+ years - GHC has a performance consortium improving it ( llvm, new code gen, new register allocator, parallel GC)... I'd expect it to be a tie now for sequential code.
but have no idea how functional (aargh! no not that functional) it is. There seems to be some activity on the trunk in the last 7~8 months, but possibly maintenance edits. Just putting it out there if anyone wants to poke. It would be sad for MLton to bit rot.
there's always this (#include standard disclaimer that some languages' submissions have been heavily optimized, others have not, and none of them may work like your apps; languages with modern type systems do prety well: ATS, scala, GHC, clean, ocaml, even F# under mono
You could use Haskell for prototyping your idea and call a, hopefully faster, C implementation for portions of your code. Having said that, you should always use a profiler to determine what portions of your code can potentially benefit from going lower level.
If you do a lot of matrix computations, for example, you can always call a fast Fortran library like Blas or Lapack through a C layer.
I don't know Haskell well. That said
, this 'guide' is really blunt, succinct, and informative about Haskell. It's rather nice and gives me a feel for the language a lot quicker than "Learn You a Haskell" did.
And it's got a ton of references to existing resources in a ready to consume fashion. I would've liked this a lot when I kept getting stuck on Monads.
Quick question, since we have an author of RWH here for the moment -- most resources (including RWH) don't seem to mention Template Haskell or GHC type extensions.
Is this because they're nonstandard or do you disagree with their use cases? (For example, the section on Monad transformers in RWH is used similarly to the way implicit parameters might be used if enabled).
They come with GHC, but they're mostly not standardized. And there's more than 50 language extensions. They're not usually mentioned in texts, as they're usually necessary only for advanced user, or very small niches.
However, if you're are medium to advanced Haskell user, you should know about the common language extensions:
There was some fear expressed in the thread that development on MLton might have stopped, but going by this http://mlton.svn.sourceforge.net/viewvc/mlton?view=revision&... (codegen bugfix checked in 6 weeks ago) it seems MLton alive and well, I am definitely happier now that it is.
I read a thread about their plans to move their list to sourceforge. Maybe that has not happened yet, that might explain why the last available mail-archive is from Oct 2011.
Thanks for the pointer! My first language was Scheme and I always kind of joke around about eventually learning Haskell. I think I might actually start doing it though.
While that's an interesting read and fun mini-project, I wouldn't recommend it as a tutorial for Haskell beginners. You need to have a pretty decent handle on the language before a lot of it will make sense.
Learn You a Haskell for Great Good! is the ideal starting point, in my opinion.
You need to have a pretty decent handle on the language before a lot of it will make sense.
While that's true, I think a learner may need more to aspire to (whether to write it, or just understand it) than just the next line of 'Learn You a Haskell'.
And there's also the fill-in-the-blanks phenomenon: you see a bit of code and have no idea what it does, but later on when you start to learn the underlying idea behind that code it may help solidify your understanding.
This is also a good way to learn math: rather than a strict progression of incremental steps, it's good sometimes to beat your head against something that's way above your level. Even if it seems like you're doing nothing, you're actually creating a space in your head where this knowledge can go, if I can be forgiven that metaphor.
Agreed. LYAH is fantastic for forming a conceptual foundation, but if there's one thing it lacks, it's exercises, so it's definitely a good idea to supplement it with something more focused on writing actual code. Write Yourself a Scheme is good for that purpose, as is Real World Haskell.
I agree that it isn't a good first introduction. However, I think it's a pretty good choice for someone that's done a few basic tutorials and wants to move on to something large.
Does anyone here have experience with HDBC? I am very interested in using Haskell in a risk-rating system for cross-collateralized loans and bonds, but I absolutely need solid support for working with Sybase and SQL Server. We've used Clojure in our prototypes, and JDBC is top notch. However, Clojure lets you get away with a lot, while Haskell forces a level of discipline and gives a proper debugger. Also, I could really use Haskell's algebraic data types for performing operations on relational data and applying rules that have lots of exceptions. The system we're replacing is a mess of CASE WHENs and stored procedures operating on views built on views. I'd really like to use Haskell, but absolutely need solid database integration.
HDBC is fairly similar to JDBC. I consider it a fairly direct to the database affair. You can go lower level or higher with other APIs. If you want magic Haskell foo you probably need to look elsewhere, but if you like the database and like SQL it's quite reasonable.
Note that in practice, in OCaml, I found it easier to write my own Oracle bindings than use the "standard" one: http://gaiustech.github.com/ociml/
The mainstream community of both Haskell and OCaml, I get the feeling, doesn't really care too much about RDBMS access, as it's not something academics often need, so you will often find yourself on your own if you have a problem. The only mainstream functional language that does take RDBMSs seriously is F#, which it gets "for free" as C# needs it.
Thank you very much. I've never seen such beautiful database code before. I think it's here where the power of monads really shines; they keep all the statefullness of the database from cluttering up the rest of the code. I will stick with the JVM because of legacy integration. Although I must say, the more I use Haskell, the cleaner my code in other languages gets. Haskell is almost like poetry in this regard.
You might want to see if the code for the postgres-simple library can be ported to use those other databases c libs rather than the libpostgres one.
Reasons: in the context of Postgres, the above lib allows you to do full sql with proper escaping of parameters and also is extensible with respect to defining how to serialize values to and from the db side representation.
Full disclosure: I'm using that lib because it's the only one that lets me exploit postgres' geometry functionality while still using a rich query api thats type safe
For those going through LYAH, I highly recommend supplementing chapters 11-13 with this excellent resource.