Oh my, another tutorial. I've looked at many of them, trying to learn something from the Haskell way. And I think I get the fundamental advantages of the type systems, the lazy evaluation enabled by the languages purity, I think I can somehow make sense of the Monads even. I have the "learn you a haskell for good" on a pile of books where I have a glimpse from time to time.
Most tutorials and books are very enthusiastic in how they can detect that I try to zip two lists of different cardinality during compile time, or how they can lazily calculate the Fibbonacci sequence. And that's really nice and fine...
But nevertheless, I use C all of the time, and I learnt how to make use of a myriad of libraries, combine connections to a SQL database, embedd a webserver, talk to USB,... Must have been 20 years ago that I wrote code to calculate the Fibbonacci sequence.
So, where are tutorials that showcase all the wonderful "high-level" functionality that has already been written for Haskell, so that I, after reading through the text, will be thrilled how much work I can avoid, or how much security I can gain when switching over from my "almost bare-matel not-much-more-like-an-assembler C" to Haskell? Not in calculating the Fibunacci sequency, but in writing a backend for my web-app, or talk to a USB peripheral? Do 3D graphics?...
If all you've done is looked at tutorials and glimpsed at a book, I think it's very unlikely that you actually get the advantages or really understand any of the patterns like Monads. Write some code. The only way that you'll actually grok the language and get any of the benefits from learning it is if you actually write code in it.
I know your comment is more targeted at tutorials, but in case you don't know the book Real World Haskell explores, as the name implies, some real world problems: http://book.realworldhaskell.org/read/
Agreed compared to RWH, LYAH was next to useless for me. RWH could use a refresh though (published in 2008), hopefully a 2nd edition will be in the works at some point.
Oh cool, you can do everything, right up to something useful. At which point you should use this library for side effects, no wait, this new library, oh wait, have you tried this new feature that's only in the latest GHCi and w/ the right Data import? ... eh, maybe I'll pass.
There are helpful tutorials for all of the things you've mentioned. I think that part of the problem is that people don't go looking for these things. If you want to write a backend for a web-app, there are three frameworks that are all mature: Snap, Yesod, and Happstack. There are tutorials, books, and documentation for all of these frameworks. If you want to do 3D graphics, there are some pretty straightforward bindings to OpenGL, again with tutorials and documentation. If you want to talk to a USB peripheral, there's the usb-safe. For databases, there are a myriad of options and tutorials for those.
The tutorials are all out there, but one is going to have to have a pretty solid grasp on Haskell before one can understand them, just like with any other language.
Groundhog is pretty awesome[1]. Persistent also works, but it does some wonky stuff on SQL databases. Acid-state is really neat! Of course, there's stuff like postgresql-simple, but that's not very type safe.
Did not know about Groundhog, thanks. Looking into the docs Groundhog does not support joins (same deal with Persistent), which I'd say is a deal breaker for most (non-trivial) applications.
Acid-state is a different beast entirely, seems to be similar to Clojure's Datomic.
That leaves us with Esqueleto for real world type safe database access (with no SQL Server or Oracle support).
I want to jump ship from Scala to Haskell but there are some gaps to be filled yet before leaving the batteries included Java ecosystem.
Do you have any experience with Database Supported Haskell (DSH) [1]? I've just recently found it and it seems very nice. I didn't have the time to test it though.
Of course you don't have to believe me, but I'm genuinely puzzled why apparently most tutorials spend such an disproportionate amount on these more theoretical explanations.
One explanation of course might be that a lot of the crowd looking into this are coming from a computer-science background where they are more enthusiastic about the basics. And to them, the fact that (after a lot of coding chores, writing up libraries) it eventually will make sql-injection harder, or parallel handling of web-service faster will be seen just as a logical consequence not worth making a lot of fuzz about.
But for attracting a larger community one has to make the gains for the average programmer more visible.
@kissthblade: Your comment (dead) below is very sad. You've been hell-banned for more than a year and a half. It doesn't just seem like nobody is seeing your comments, it's true.
For those without showdead on:
"I posted about the same comment as the parent hours ago. I don't know if anybody even sees my posts, never gotten a response, and my "karma" or something has always been 15. And posting and reading the forum is very slow. What gives?"
Looking through your comments, I don't see an obvious reason you were hellbanned.
This happened to me, too. I spent about a year replying before finally seeing someone mention I was hell banned. I also wondered why the forum was so slow, but it's not particularly well coded so I just assumed its always been like that.
Is that something common at Hacker News? I find it worrisome that someone can be banned from a community and not even be aware of it. What's the point of punishing wrong behavior if the one making it isn't aware that it was wrong?
I'm trying to grasp how moderation and banning works around here, but it's difficult since neither the FAQ nor the posting guidelines have an explanation about it.
This makes for very good reading indeed. I started reading it and just now realised that I'd spent the last couple of hours on it. It's written well, approachable and very pragmatic. I spent a short while on Haskell a few years back and stopped after 3 or 4 chapters of Learn You A Haskell due to time constraints. I think I'm going to make this my evening reading and finally pick up the language.
This is great, and I've bookmarked it for reference while reading LYAH. Thanks for writing it.
For anyone who needs a refresher on DFA, Stanford's CS143 compilers class course materials are up on Coursera (https://www.coursera.org/course/compilers), and pretty helpful.
>What this means is that existing sort functions such as mergeSort and quickSort would need to be rewritten to sort values of the new type. In constrast, here is the type of mergeSort in Haskell mergeSort :: Ord a => [a] -> [a]
Er, you could define mergesort using templates in c++ and it would work pretty much the same.
The difference is entirely in the types. A sort function in Haskell has type:
Ord a => [a] -> [a]
You therefore know that the implementation of the function can only make use of functions provided by Ord, and manipulation of the list structure. The function cannot inspect the values in the list except via comparison. This is an incredibly powerful guarantee. It's also really useful when you go to implement the function because this level of parametricity guarantees that there are only so many valid implementations and only a couple of them are even close to correct.
All true. On the other hand, std::sort in C++ works on RandomAccessIterator, which means that it can sort vectors, C arrays, deques, strings, your custom container type, etc. The Haskell implementation can only sort lists. Furthermore, the Haskell type signature fails to express that the input and output have the same size. But std::sort necessarily preserves its size, because you pass it a range, and a range cannot access its underlying container to change its size (a limitation leading to bizarre APIs like std::unique).
You can define a mutable std::sort like function in Haskell:
mutableSort :: (MArray arr elem m, Ord elem, Ix ix) => arr ix elem -> m ()
This can work on mutable arrays in the IO, ST, or other mutable-array supporting monads. It also has a generalized index type (though newer array libraries threw that part away, so it's not considered a good idea anymore).
The existence of an operator< or the existence of a template specialization. Not as nice, and incapable of runtime polymorphism, but that's typically how it's done. Concepts would have been more explicit about it but they're also compile-time only.
Interfaces or pure virtual classes are not the same because they're closed.
Multiple inheritance from a purely virtual class. In Java, they're called interfaces; Comparable is the analogue to Ord.
The advantage that Haskell's typeclasses have over either Java or C++ is that the types aren't closed. I can define a new typeclass and tell the compiler that a type you defined is a member of that class at any point. In Java, if you don't define that your type is Comparable, there's nothing that I, as a consumer of your type, can do about it.
The advantage you mention is one of many (over OOP interfaces), I'll repeat it as (A).
(A) Ability to instantiate old types with new classes
(B) Conditional instantiation: "Maybe a" is an instance of "Show" iff "a" is an instance of "Show"
(C) Can do return-type polymorphism, or polymorphism on any part of the signature
(D) Objects do not need to pay for the interface vtable pointer. Large array of some type-class instance can be much smaller than an array of an OOP interface subclass.
(E) When comparing two Ord instance values, there is only one Ord dictionary, rather than 2 to choose from. No false dilemma.
E) you do get a dilemma if you add two elements in a sorted structure , lexically in two different files, where two different Ord instances arr in scope, respectively. this function-is-instance problem is dual to OO's -object-is-instance problem.
A homogenous list is guaranteed to only have one instance unless you enable incoherent instances (a known bad extension) or confuse the compiler with orphan instances (though I've never encountered this and think it should be detectable at link time anyway).
One type -> at most one instance for any class, in Haskell.
Yeah, though you will want to be the owner of either the type class or the type itself. Instances which are neither are called orphan instances and they are generally frowned upon. Luckily, it's trivial to create a newtype wrapper which gives you a whole new set of hooks for writing instances of a type.
That makes sense, but again, in Java you can't do it if you're just the owner of the typeclass, and in order to make a wrapper you'd have to make a subclass, which mucks with all kinds of other things.
Concepts will certainly be nice once they arrive in the standard, but it is already possible today with some trickery. Example checking whether an std::vector<T>'s type is comparable with `operator<`: http://coliru.stacked-crooked.com/a/2ea46e0afd894d3d
The error you get if you try to sort a vector with an unordered type is relatively easy to read:
main.cpp: In instantiation of 'void merge_sort(std::vector<_RealType>&) [with T = type]':
main.cpp:45:17: required from here
main.cpp:30:5: error: static assertion failed: Element type is not sortable
static_assert( concept::is_ord<T>(), "Element type is not sortable" );
^
Most tutorials and books are very enthusiastic in how they can detect that I try to zip two lists of different cardinality during compile time, or how they can lazily calculate the Fibbonacci sequence. And that's really nice and fine...
But nevertheless, I use C all of the time, and I learnt how to make use of a myriad of libraries, combine connections to a SQL database, embedd a webserver, talk to USB,... Must have been 20 years ago that I wrote code to calculate the Fibbonacci sequence.
So, where are tutorials that showcase all the wonderful "high-level" functionality that has already been written for Haskell, so that I, after reading through the text, will be thrilled how much work I can avoid, or how much security I can gain when switching over from my "almost bare-matel not-much-more-like-an-assembler C" to Haskell? Not in calculating the Fibunacci sequency, but in writing a backend for my web-app, or talk to a USB peripheral? Do 3D graphics?...