Show HN: Learn Functional Programming Using Haskell | Hacker News Reader

Show HN: Learn Functional Programming Using Haskell

lambdaschool.com

220 pointsxwowsersx90 comments

Haskell is such a distinct mix of features that make it great to use once you know them but somewhat difficult to learn from scratch.

One big fat clue that I wish I had been given when I was starting to try to figure it out on my own back in the 90's is that Haskell is kind of loaded up with syntactic sugar, beneath which is a relatively small core language that might be an easier point of entry into the language.

To be specific: infix operators, sections, multi-argument functions, partial application, 'where' clauses, multiple definitions of the same function with different patterns, implicit braces and semicolons inferred from layout, 'do' statements, if/then/else, [lists] -- all of these, and probably more, are great to use, but they all boil down to something like

  func = \arg -> let { ... } in case arg of { pat | guards -> f x y; ... }

and perhaps fully grokking these essential constructs before moving on to using them indirectly through all the layers of pretty syntax would have helped me understand all those features better.

ADDENDUM to forestall my inevitable hog-piling by pedants: yes, I know that 'let' isn't strictly essential, and I neglected to mention record fields, record updates, type classes, &c. Sorry. And I know that the Haskell standards have always defined higher-level constructs in terms of a core language. My point is that, at least for me, Haskell might have been easier had I been exposed to just that core language at first.

Interestingly, most educational resources start with a core language or concepts then build on them. So your gripe seems intuitively correct.

To do some reverse pedantry, actually that let is necessary but it's the one binding `func` that gets more use. It's a really interesting part of how ML-like languages do type inference that makes `let`s completely necessary.

Completely agree. This is one of the things I really like about the book Functional Programming in Scala, which builds from the ground up. I haven't found an equivalent book in Haskell.

The world might be a better place if we could exchange a few hundred of the existing monad tutorials for a post or two that just explained Haskell pattern matching really well.

I'd submit that our book builds from the ground up and covers dramatically more than FPiS, you can see our chapter listing here: http://haskellbook.com/progress.html

Also see my other comment here which mentions the process we used: https://news.ycombinator.com/item?id=12214430

The book covers so much because wanted it to work for people who

1. Weren't necessarily familiar with FP or at all, or in some cases, programming period.

2. Would be able to apply Haskell or learn more advanced concepts on their own after working through the book.

#2 required covering much more of the intermediate stuff than any of the existing books available.

I wrote the book because of the problems detailed in this blog post with the pre-existing materials: http://bitemyapp.com/posts/2014-12-31-functional-education.h...

Oh cool, I'll check it out. Thanks for writing it!

I've just finished my first pass through the book (kind of... have to go back through some stuff.) and I concur that its a great read. I do wish there was a companion that had some code examples of some of this stuff in the real world.

For instance, intuitively state traversals or using product monoids for folding lists seem to have tons of real world applications that I've been looking for something to solve, but I find it still takes lots of exploration.

When I was first learning Haskell, through Real World Haskell and LYAH, I was very frustrated that they never seemed to actually give definitions for anything, but instead just vaguely implied definitions by listing examples. What finally worked well for me was using the Haskell Report 2010 as a reference, and looking things up there every time I got frustrated by the lack of a solid, detailed definition.

The Haskell Reports, especially the 2010 edition, have been clear, readable, and straightforward documents whose contributors and editors should be commended. If only other language standards were so clear! (C'89 and Fortran are also really excellent documents.)

The thing I really took forever to grasp was how do-notation desugars (a la https://en.wikibooks.org/wiki/Haskell/do_notation ). For the longest time I understood logically/conceptually how to deal with monadic operations, but was confused on the syntax. For a while, do-notation and also applicative style were opaque mysteries until I managed to figure out what was going on under the hood.

>and perhaps fully grokking these essential constructs before moving on to using them indirectly through all the layers of pretty syntax would have helped me understand all those features better.

This is the approach we take in our book, Haskell Programming from First Principles. (http://haskellbook.com/) The book starts with a _brief_ introduction to lambda calculus and builds on what the reader knows incrementally. You can see in our chapter listing: http://haskellbook.com/progress.html what order we do things in. Importantly, it's not just show & tell. The book has _a lot_ of exercises and detailed explanation for the concepts covered.

I'd worked with and taught quite a few people before starting the book, in addition to maintaining a fairly popular guide (https://github.com/bitemyapp/learnhaskell) for learning Haskell and helping people working through the recommended materials. Further, my coauthor on the book was completely new to programming when she began working with me. What we cover and in how much detail is influenced by working with her, our ~10 deep-dive reviewers, and the over 1,300 emails of feedback/questions we've gotten from readers.

What I did in the book is based on that experience and data. If I could've written less and still solved the same problems, I would've. Maybe a future edition will be shorter after we refactor some things.

Awesome, thanks for sharing!

Here are some other resources to learn Haskell:

1. Learn You a Haskell for Great Good - http://learnyouahaskell.com/ - can read the text for free online

2. UVa Student Taught Haskell Course - http://shuklan.com/haskell/

3. Learning Haskell - http://learn.hfm.io/

4. Haskell Programming - http://haskellbook.com/

A question for the author - did you review the other learning materials (i.e. competition or maybe complement(s)) and find discrepancies that made you want to create a better learning resource or were you primarily motivated by how awesome of an experience you had learning Haskell and the desire to share that with others?

Haskell was the first language taught to us in my university course. Literally within the first week. Everybody was new to it. Our lecturer highly recommended Learn You A Haskell on the first day, and it's still one of the best docs/guides I've read in a while.

that's refreshing... what university was this?

They do it like that at Chalmers and Gothenburg University, at least.

University of Texas used to do this. They still might. Djikstra wrote a bit of a letter about it once.

Yeah, I’ve read/reviewed most of them. I could give long opinions on each, but overall I would say that I wanted an easy way to get into the language by building instead of endlessly going over all of the intricacies of the language. There is a time for that, but I’d argue it’s after you get in, get the basics, and start playing.

I almost called this a “crash course in Haskell” but I didn’t like what “crash” connotes. I just really want to get people into the practicalities of what’s important as quickly as possible.

While I really like the course from what I see, I also think that Haskell is not a good subject for a "crash course". In the Learn Haskell From First Principles book[1] it is given why a "crash course" Haskell is not working for many, and I second it.

Non the less, the more options the better. And of course I do not know how you do your course. Naturally I wish you best of luck: that your students may succeed in mastering the subject :)

[1] http://haskellbook.com

I agree, and that's why we didn't go with "crash course." There's a certain amount of stuff you simply have to work through and know in order to use Haskell, for sure. This course isn't mutually exclusive to something like Haskell Book. The intention is to provide a comprehensive overview so you can quickly get up to speed, have a sense for what real world programming in Haskell looks like and gain a familiarity with the basic concepts that are used over and over. If, after that, you're motivated to go through a 1000 page book, that will serve you well.

>the more options the better

Not true, with infinite options there are infinite bad options.

And also infinite good options.

so? Even the claim of unlimited options takes us more time to argue about then looking at the initially claimed option warrants.

Good luck.

That is not true at all.

> In the Learn Haskell From First Principles book[1] it is given why a "crash course" Haskell is not working for many, and I second it.

What's their reasoning? I didn't find this on the page you linked.

I don't think that it would be impossible to do a "crash course" in Haskell well, but it's certainly harder than doing the same in e.g. Python, simply because the language will flout so many expectations/assumptions that developers would be able to make in other languages.

How did you decide on pricing (price per course and then the Kickstarter?)? A top-noted resource "Learn You a Haskell" is free (online).

Has the course material been created? Are you the only instructor?

Is your intention to provide more resources on functional programming (in other languages perhaps) considering you've created the "Lambda School" instead of the "Haskell School"?

I don’t want to spend too much time discussing the concerns I have with other resources other than to say that I think the reason LYAH is popular is because it’s free, not so much because it’s the best resource ever created. There's some guess work in terms of pricing, but it reflects what I think we’ll need in order to justify the considerable time investment in putting something together that is really high quality

A lot of the material has been created, but it takes a long time and lot of synthesis - a lot of feedback-receiving and iterating from others who are learning Haskell. I am the only instructor who will be speaking/recording videos, but I’m working with several others to fine tune the course.

And our intention is to provide a lot more resources, not only on functional programming, but on many elements and aspects of what I consider “advanced computing,” or “ongoing developer education.”

Excellent, thanks for the clarity. Congratulations and good luck with this endeavor!

thanks a lot

call it a tutorial

A partial list of interesting talks on Haskell are available at https://github.com/0xmohit/talks

Worth noting, Université Paris Diderot will launch its second edition of ocaml programming mooc in september: https://www.fun-mooc.fr/courses/parisdiderot/56002S02/sessio....

I followed along its first edition last year and it was very good. Sure, the instructors had a really thick french accent and the videos had some outdated sound effects and animations, but the concept were well presented. That said, the selling point of this mooc was the high quality of the exercises, which were rather hard, but quite rewarding and very well thought out. By week 2 or 3 you had to implement complex algorithms and functions, eg. a database class or heap's algorithm. Highly recommended.

Coming from an SML background, one of the things that's always tripped me up about Haskell is that it doesn't have structures, signatures, and functors for grouping code. Instead it has modules, which are not much more than groups of exported functions.

For Haskellers coming to SML, there's "A Crash Course on ML Modules"[1] which does a nice job of explaining things in the opposite direction.

Are there any resources like this out there that discuss how best to break down and write modular Haskell programs?

[1]: http://jozefg.bitbucket.org/posts/2015-01-08-modules.html

(update: I realized the original article I linked to wasn't the one I thought it was!)

Thanks for the link. I'm actually under the impression that the situation in Haskell will be changing in the near future with the project called "Backpack"[1][2], which Simon Peyton Jones and Simon Marlow are both involved with.

[1] http://plv.mpi-sws.org/backpack/ [2] https://ghc.haskell.org/trac/ghc/wiki/Backpack

Oh cool! It looks like the first link is from 2014. Do they discuss their progress somewhere online? I'd love to see what they've done recently.

This is an interesting question. As much more of a Haskeller than an MLer I don't tend to feel the "need" to structure my programs explicitly modularly, and when I do I sort of instinctively use a combination of typeclasses and polymorphic higher-order functions to do so.

More basically, just think "everywhere I would open a module, instead I can take a parameterized record of functions" (and furthermore, if a datatype uniquely determines that record, I can associate a typeclass to that datatype). There are limitations to this, but in fewer circumstances than you'd think -- mainly about sort of cross-modularity (aka the expression problem).

There was a very nice discussion on lennart's blog about this in 2008, with a problem posed and some partial solutions (read bottom post to top):

http://augustss.blogspot.com/2008_12_01_archive.html

This is actually quite a far way towards what I was looking for! Thank you very much.

> We have basically packaged up the dictionary and unpack it ourselves to get access to the operations. It's not pleasant, but it works.

Would you say this method of using multi-parameter type classes and packaging/unpackaging related operations in a record is "idiomatic"? I admittedly haven't browsed all that much Haskell code, but I feel like I don't see it used that frequently.

once you end up with a typeclass and associate the methods the unpacking goes away and you're just working in a context parameterized by some typeclass. i expressed it via that route to help make the connection to modules more clear. (there are occasions when you don't take that last step too, which is why i also sort of pointed towards that route). lennart's post shows an example where this sort of falls down -- but the followup also shows a nice haskelly solution that works, mainly, except when we want to intermix. he also suggests explicit type arguments as a way to make things nicer -- those have now landed in GHC :-)

the other relevant work in a broader sense that I should mention is regarding effectful contexts where idiomatically you declare a subclass of monad with the relevant operations, then instantiate it via the mtl or some other means, so you can swap out the IO backed "real" one or various harnesses or add in logging layers, etc.

finally, i guess i should add that as a rule of thumb i've noticed that purity and laziness both help provide ways to give "modular separation of concerns" directly. in particular, the most obvious thing we can do is just have each function do one thing to a bit of data, and produce a different bit of data and that's innately modular. but when we're interleaving IO (for example with mutable datastructures) and concerned with _when_ computation happens (in a strict setting), then it feels we're paying for this too much because we get big intermediate structures. but if you get the knack of just using pure lazy structures directly, you can sort of "amortize out" the computation cost in a nice way and also the space cost (as conceptually some big data structures become produced "on demand"). of course if you get it wrong, blammo :-)

Anything you can do with ML modules you can do with Haskell typeclasses, and you can do most practical typeclass things (maybe all typeclass things?) with ML modules.

Some things are more or less convenient in one system or the other.

I wouldn't object to having both! I believe that's what the purpose of the Backpack project is.

You can't parametrize type classes over one another in the same way. In practice, this often makes ML style modules much more expressive: for example, I can have a Hashable type class with one implementation per type that is used by a HashSet data type or module, but with MLs there could be a number of modules for the same type implementing the hash function, which can be used to construct the set. This also means things like Monoids or Semigroups greatly benefit, since now you can easily have more than just (+) for ints, for example. You can even use this to derive operations like folds from your base module where you'd never have to apply the arguments to a folder; instead you could do Sum.fold or Product.fold based on the different base modules.

You can do this in Haskell as well, it's just clunkier since you usually end up needing some combo of MultiParamTypeClasses and plumbing around extra types.

The ML approach is better for this use case, but the Haskell approach can do the same with a bit more verbosity.

Of course, but at that point one could throw in OCaml extensions (modular implicits + HKTs) to provide the Haskell functionality to OCaml.

I really, really like video tutorials. I always have problems learning completely new languages because i can't motivate myself to complete the introductionary books. I want to start building things from day one, which is only possible when i am familiar with similar languages. With video-tutorials, i can watch them in the evening because the mental burden is not that great. I know i will miss things, but i watch them rather quick so i can start hacking after a few days (or 2 weeks max). I normally hit the limits of what i can do quickly, because i did not go through a whole book and completed exercise after exercise, but this is no problem, because i have a basic understanding of various parts and can revisit the appropriate videos or google a bit.

I am happy this looks like some decent videos will finally produced for haskell

I, on the other hand, cannot stand video tutorials. I can read a lot faster than I can watch, and I retain information approximately 1000x better that way. Video players that are difficult to pause precisely and progress frame-by-frame to catch points of interest don't make it any better, nor does the lack of indexing and search-ability for voice/video versus text.

But variety is good, different strokes for different folks.

I like videos, but if they don’t have good controls or a transcript I go insane. We’ll be including a transcript (modified so you could read it) with each video as well

Awesome. You know what would be really nice to have? Little markers at the beginning of points or concepts, like the numbers in the Bible. If I could bookmark those, and link to them from a digital notebook (are there any good Haskell notebooks?), that would make it very easy to come back to difficult concepts later, or to provide context with my own notes.

I agree. Optimized pacing and pausing happens naturally when we read, but people nearly always talk way too slowly for me to learn effectively from videos, and pauses are never optimized for my personal needs.

It isn't just a waste of time, I just can't learn effectively when the information is presented at the wrong pace.

Have you tried using VLC for the bookmarking and frame-by-frame hot keys? I exclusively use VLC for watching educational videos, so I can tweak the playback speed to my needs, and also jump backwards easily to have material repeated.

One day we may have video players that watch our faces and body language to intelligently guess the best pace of playback, and note the sections where we are confused for future study.

Yeah, I really like the video speed control for educational videos too. Curious, what speed do you normally use? 2x? more than 2x?

Did you know about this app for controlling speed of any HTML5 video element https://chrome.google.com/webstore/detail/video-speed-contro... ?

I've recently started experimenting with uploading videos (math tutorials) to youtube already at 1.5x speed. I think my lessons become much more interesting, but some people said they really hate the 1.5x speed, and prefer to watch me talk slowly, so I don't know if 1.5x should be the default...

Do you know other people who like to watch technical videos at 1.5x and 2x, or are we the exception?

I did not know about that HTML5 video speed controller, thank you for sharing that.

> Curious, what speed do you normally use? 2x? more than 2x?

It varies greatly depending on how fast the person talks normally, the difficulty/newness of the subject matter, and the way they phrase their sentences (useless filler words, or densely meaningful?)

There are some videos where the person talks fast enough (on a topic new to me, without filler words) for me to listen comfortably at 1.0.

At the other extreme if they talk exceptionally slowly, use lots of filler words, and the topic is easy or something I'm familiar with I may push it past 3.0. Also, if I'm reviewing videos I've already studied.

With foreign languages I may slow it down to 0.7 or so.

> Do you know other people who like to watch technical videos at 1.5x and 2x, or are we the exception?

I just assumed everyone does this at some point in time, unless it hadn't occurred to them.

I mean, we all skim books that we've already studied, don't we? Refreshing our memory and looking for things we need to revisit (at normal reading speed)? Wouldn't everyone also want to 'skim' the videos they've already watched instead of re-watching at normal speed?

I agree with you, its more efficient. For university i learn from the script and slides (and sometimes books).

But i also think its much more exhausting. I play the video tutorials when i am in bed before i sleep (or while sleeping :) ). They are way more relaxed, i don't have to pay that much attention. For me most of the time its a tradeoff between learning a bit and learning nothing. I also get excited from watching the videos and can start doing toy-projects. And while books are a good way to get a gasp of the language, it think the only way to really learn a language is to use it. Thats one similarity between programming languages and "real" foreign languages.

One benefit of learning Haskell if you're a JS developer is that you'll understand how awesome Purescript is and will already know how to use it: http://www.purescript.org/

It was for me at least. As a front-end dev I'm not always able to use Haskell day-to-day but I've found ways to use Purescript.

How would you say Purescript compares to something like Elm?

As a very superficial comparison, PureScript is a lot more similar to Haskell than to Elm. All three are great languages, but of the three Elm is definitely the simplest and IMHO most beginner-friendly. It's also the least flexible and general.

In many ways, PureScript is actually a better version of Haskell (e.g., with extensible records). But it's currently very focused on front-end development, and it's missing amazing Haskell features like STM. So outside of front-end stuff it's not nearly as practical to use as Haskell.

The Elm wikipedia page has a good example of it's limitations compared to PureScript/Haskell:

> Unlike Haskell, Elm has no support for higher-kinded types, and thus cannot provide generic abstractions for many common operations.[20] For example, there is no generic map, apply, fold, or filter function. Instead, such names are used prefixed by their module, such as List.map and Dict.map. [1]

And from the above source link:

> You can't define higher-kinded things like Functor/Applicative/Monad/Foldable and do dictionary-passing style for ad-hoc polymorphism in Elm. [2]

But personally, I haven't tried Elm yet so I can't comment. I'm not sure I want to invest in learning a whole new language/framework just to do front-end work. By learning PureScript I can transfer the same knowledge/experience coding in that language to the backend when using Haskell. Much like Clojurescript and a lesser extent Node.js. While Elm is limited to front-end use.

[1] https://en.wikipedia.org/wiki/Elm_(programming_language)#Lim...

[2] https://github.com/elm-lang/elm-compiler/issues/396

> By learning PureScript I transfer the same skillset to the backend

do you mean "frontend" ?

No I mean the better I get at PureScript programming the better I will be at Haskell. As the syntax is very similar and the programming paradigm (purity, algebraic data types, etc).

Elm is a niche platform without applications outside of front-end (AFAIK).

A little feedback for the author - The curriculum link is not really a curriculum at all its a preview video. I would be far more inclined to pay $50 if I could see a syllabus, outline or at least the subjects of all the videos in the series.

Congrats on releasing your course though.

My biggest problem with pure FP languages is a lack of interesting projects - anyone have a good one that isn't a parser?

You can do any kind of project with Haskell; I suspect you aren't looking very hard.

Here are some interesting starting points:

https://wiki.haskell.org/Game_Development#Videos

Here are some:

https://github.com/facebook/Haxl - A Haskell library that simplifies access to remote data, such as databases or web-based services.

https://github.com/koalaman/shellcheck - ShellCheck, a static analysis tool for shell scripts

https://github.com/simonmichael/hledger - The hledger command-line and web-based accounting tool, a Haskell rewrite of ledger.

https://github.com/facebook/flow - Adds static typing to JavaScript to improve developer productivity and code quality.

https://github.com/coq/coq - Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.

Coq is a theorem prover and library that is written in ML (OCaml), so it is definitely not Haskell.

It is interesting that most (interactive) proof systems (e.g. Isabelle and Coq) are written in ML, I think it is probably historical. AFAIK most theorem proving research is done in Europe and ML has always been more popular there (however it seems to change in recent years, and FP courses switch to Haskell - however my school e.g. switched from OCaml to Haskell to OCaml in their FP course).

OP said:

> My biggest problem with pure FP languages is a lack of interesting projects

The list included projected written in pure FP languages.

Not only COQ, Flow is also written in OCaml.

You are right my mistake. However it seems to me that the Haskell community lays more emphasis on purity and the OCaml community takes a more pragmatic approach - but this distinction may be superficial for practical concerns.

Any kind of project you would do in any other language :) My two favourite are either:

- an IRC bot (will get you into threading, network programming etc) or a;

- CMS starting with just basic blog functionality (i.e. authentication, talking to database to store posts etc)

The first can usually be done with just the standard libraries or at least some of the smaller ones, and the latter will get you into web programming and usually involve bigger frameworks, such as Yesod (what I'd go with), Snap, Servant etc.

Also, both of those types of projects are pretty well covered tutorial-wise.

The backend for https://circuithub.com/ is mostly Haskell. We are a YC startup.

I know a bunch of startups building in Haskell, it's just not that obvious from a google search.

Nice. For "No tracking" I also like Shariff (https://github.com/heiseonline/shariff) because it includes the share numbers without comprimising the user's privacy. It does so by crawling these number from the server instead of the user's browser.

The presentation is really impressive! I'd be interested to know how much time/resources went into this if Levi is on here?

I know it may not seem like much yet, but I've probably spent 15 hours or so preparing the intro. Previous iterations were much longer so I condensed it considerably to keep a good pace. I sent previous drafts to dozens of people and incorporated feedback from everyone.

I almost thought this was some sort of new series from Brian Will, another guy who makes programming video lessons. Your voice sounds quite similar to his: https://www.youtube.com/user/briantwill/videos

I wonder if topics learned would apply to Swift. Any ideas?

Only to a limited degree. Swift is not a functional language, though it has some things that are sorta functional. The Haskell paradigm does not translate to an eager, non-GC language like Swift easily.

How well would this transfer to something like Elixir?

Pretty well. DailyDrip already do Elixir tutorials: https://www.dailydrip.com/topics/elixir

If you're looking to learn Haskell on macOS you should really check out "Haskell for Mac" [0]. It's a great native Haskell programming environment not dissimilar to Swift Playgrounds (and there are great video tutorials too). The creator is a great teacher and member of the developer community to boot.

[0]: http://haskellformac.com/

I'm trying to find the video tutorials you mention, where are they?

http://learn.hfm.io/

Oh this is awesome. I'm surprised this hasn't gotten more attention. Thanks for sharing!

Wondering why this was downvoted? Is Haskell for Mac no good?

No clue. Haskell for Mac is pretty solid—although keep in mind that it's proprietary.

Why is this better than Learn You a Haskell for Great Good?

I'm not proposing that it's better, but it has a different focus. LYAH is, firstly, very long. Furthermore, it's difficult to get a sense for how real world programming a purely functional programming works from LYAH. You'll learn some of common FP constructs from LYAH, but you'll still be pretty far from being able to write real applications.

The goal of this course is to keep the content pretty restricted to the few, main concepts that are used over and over again and to gain experience with practice and real examples.

Hope that helps.

I still don't quite get it though... Is being impractical actually a virtue for a strictly typed functional language nowadays? Like "if it hurts more, you'll learn more" or something?

Why would you drive a beginner towards Haskell and make some many "Haskell for beginners tutorials" instead of OCaml or F# (even Scala fi you're into JVM...) which gives you the same features but slightly more practical (usable records, ability to be impure and imperative when you want etc., some kind of oop-style feature for when they really fit the way you want to model a problem, less "string madness", no "forced verbose" syntax with repeating names of things to type them etc.). Plus friendly new cool tools/skins for them: https://facebook.github.io/reason/ , https://github.com/bloomberg/bucklescript etc.

I agree it seems true, I did learn a lot while struggling to learn Haskell for a bit and hurting in the process, but... why?

Because the goal of the course is to teach PURELY functional programming (watch the first video for a full definition of that) and Haskell is the most practical language in which to do pure FP AFAIK.

ok, thanks. if this is your goal, then it seems like the right tool. monadic syntactic sugar helps too, so... ir fits.

> which gives you the same features

No they do not. Haskell's powerful typeclass system, advanced (kind) polymorphism, etc. are not available in those languages. Ocaml doesn't even support proper monads. Laughably, it doesn't even support HKTs! Not sure how Scala and F# fare in that regard.

>usable records,

A reasonable complaint about the core language, but essentially solved by lenses.

>ability to be impure and imperative when you want

Haskell has the ability to be pure and imperative when you want. You just can't lie about what you're doing.

> some kind of oop-style feature

Which features?

>string madness

I never understood this complaint. Three string types, plus lazy variants, is quite manageable. They are all very well-suited for a particular set of tasks, and I'm thankful the Haskell community doesn't shoehorn too much stuff into a single string type. Haskell cleanly solves the encoding problem, which many languages kind of sweep under the rug.

> no "forced verbose" syntax with repeating names of things to type them

No idea what in the world you are talking about. FWIW, Haskell is by far the least verbose language I have ever used. Every token has semantic significance. No waste.

+1 .. However OCaml does have a superb module system that is lacking in Haskell. Not sure about F#.

True! That is definitely a major + for OCaml.

"advanced (kind) polymorphism .."

I'm aware of the algebraic type system, can you elaborate on what you mean "by advanced (kind) polymorphism"?

Sure!

Edit: This formatted poorly on HN. See here: https://gist.github.com/anonymous/3925f5e58d8647e6d82a3b2084...

Reply on news.ycombinator.com