6 ms·

Haskell web programming (a simple tutorial)

207 points by yogsototh 15y ago

agumonkey 15y ago
Finally I know how to draw owls.
gtani 15y ago
You shouldn’t need to know Haskell. Don’t pay attention to all the syntax. If you are curious you can take a look at Applicative Functor. This is a nice, whirlwind tour, maybe the opening benchmarks and jab at node are superfluous. All haskell tutorials hit the speedbump of how to bootstrap haskell understanding, where to make forward references and when to say "Trust me" but code shown here: do blocks, ($), <- and return would be confusing if you didn't know any haskell
- yogsototh 15y ago
  Should I add a link to this article[^1] for people confused by the Haskell syntax? The opening is not really an attack. This is the way I myself started to be interested in Haskell web programming. [^1]: http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/
  - gtani 15y ago
    Yah, maybe just add links at bottom: LYAH, Applicative Functor wiki page. Or maybe mention one syntax feature, IO's and do-blocks, and say "return" and "<-" just kick things into and out of IO's, loosely speaking. Just don't say IO's are like burritos ;-} You could also say, for anybody that's looked at lisps, *ML, F#, scala, erlang, the syntax isn't too bad, and for anybody that knows rails, they'll recognize the same REST'y MVC layers/abstractions. I gather the target audience is folks using dynamically typed languages.
minhajuddin 15y ago
haven't finished reading the whole content, but the zoom in zoom out effects are very annoying.
- yogsototh 15y ago
  Are you talking about the zoom in when you click on some code block? I was thinking to remove them.
  - minhajuddin 15y ago
    the Ctrl + , or Ctrl mouse scroll up or mouse scroll down
    - yogsototh 15y ago
      For me, it takes only one to two second animation. After it stabilize. You can disable javascript and there won't be any CSS animation added.
      - Lewton 15y ago
        for me, in chrome, it takes 8-10 seconds to stabilize. and looks really wonky
        yogsototh 15y ago
        I disabled animation for chrome.
        tkahn6 15y ago
        Hey your site is really pretty. Would you mind licensing your CSS for personal use? I'd like to use for my blog (which I will start one of these days). Very nice blog post. After working on a Python stack during my part time job (check out Apache libcloud), I can safely say that using a statically typed language is a necessity for any non-trivial project. Without a type system you offload the entire framework onto the programmer. To actually grok the project you have to hold the complexity all in your head instead of using the types as a guide and that makes getting started incredibly challenging.
t-crayford 15y ago
Spelling corrections, noted as I read: "point of vue" -> point of view "shell command are executed" -> "shell commands are executed" "benchmark are here" -> "the benchmarks are here" Also, heroku works just fine with haskell, as long as you compile a static binary on an ubuntu machine. I compile mine on virtual box (via way of vagrant), and have 3 haskell apps (none of them really production ready though) running on heroku right now. Lastly, I don't really think haskell is the right language for a lot of web programming. In haskell, you really want your logic to be as purely functional as possible, but that gets pretty hard to do for web apps that rely on external apis.
- yogsototh 15y ago
  Thanks! Spell errors corrected! When I said there is no heroku for Haskell it because it is not official. Furthermore, do you have to use a 64bit architecture when compiling (just curious)? I might try it myself. And I even think that the argument against the number of Haskellers is in fact a force instead of a drawback. It filter passionate people. By external APIs, you mean that it would be difficult to write a simple "connect to twitter/facebook" application? Could you tell us about any bad experience you had?
  - t-crayford 15y ago
    Yeah, 64bit. I never said anything about number of people... External apis: nearly all the logic in my app leads to either talking to the db, or calling an http api (and haskell can't use https apis that well, you have to use its bindings to libcurl). In general, it feels extremely difficult to pull my logic out of IO (but maybe I'm just too dumb to). It's not that its particularly difficult, it's just that it's not a problem I think haskell is well suited to solve. I've used haskell to teach my self automated logic proofs (just resolution refutation), compression algorithms (huffman encoding and lz77), typechecking and breaking encryption (enigma). Every time university exams roll around, I learning them on paper. It's by far and away the best language I've used for stuff like that. It feels like web-apps with lots of IO aren't really a problem haskell is well suited to solve.
prof_hobart 15y ago
From the bit of Haskell I've managed to learn, it's a great language, and I can see how an awful lot of the errors that you can make in other languages will probably be avoided in Haskell, but I've never understood the (frequently repeated) claim that "If your program compile it will be very close to what the programmer intended". There's nothing I've seen in Haskell, or any other language, that will prevent you implementing the wrong algorithm, or the wrong business rules etc. If you're doing a phsyics simulator (to take an example I've played around with), Haskell is not going to stop you badly miscalculating the gravitational effect of multiple objects, or calculating the mass of an object incorrectly.
- jiggy2011 15y ago
  I think if someone made a language where it was categorically impossible to do something dumb they'd be very rich indeed. :)
  - Chirono 15y ago
    As long as it was also possible to do some non-dumb things, of course...
    - jiggy2011 15y ago
      true, otherwise you could just run your program by piping it into cat.
- Peaker 15y ago
  That's the difference between an "intentional bug" and an "unintentional bug". The former is when you want the program to do X, and X itself is wrong. Sure, defending against this is rarely possible. The latter is in my experience far more common. When you want the program to do X, but you actually told it to do Y. Haskell catches most of the latter cases. One of the main reasons is the functional purity. Because return values are the only result of a function, and these values are type-checked against a specification, it is much harder to do the wrong thing. For example, an imperative program will idiomatically have methods whose sole effect is mutating their arguments or the objects. Even with a type system -- if you just omit the effects, the compiler really has no way to know that you meant the effects to happen, and you will simply have a bug. A purely functional program will idiomatically use a different style. Instead of mutating arguments and objects, it will return a new value. If you forget to return a new value, the compiler will catch that. Additionally, the types in Haskell are generic by default. The more generic the type of a function, the more restricted is what that function can do. The restrictions narrow the space of wrong things you can do. Another interesting property of Haskell is where it chooses to be on the "restrictiveness+guarantess vs. powerful+unguaranteed" trade-off. It seems many don't even notice that the other side of the "power" coin is "guarantees". The more powerful a construct is -- the less you can say about what it will do. In Haskell, the purity and generic types of functions are two things that heavily restrict code. But there are many other mechanisms to restrict rather than empower code. In many contexts, restrictiveness is considered a bad thing, but in Haskell, this restrictiveness is very useful for reasoning about code. For example, the function of type: (forall a. a -> a) in Haskell can only be the identity function. It cannot print "hello world", and it cannot mutate variables. These restrictions are useful because we now can have useful laws. For example: id . f = f . id = f. And we can derive these useful laws from the type itself, without even looking at the code! By helping us find the most restrictive sub-language that can express the solution, we rule out even more bugs.
jiggy2011 15y ago
Is anyone here using haskell or a similar funtional language for any web app? Would be interested in known your experiences and opinion compared to something like django or rails. How difficult is it to build something with a complex domain model?
- SomeOtherGuy 15y ago
  >Is anyone here using haskell or a similar funtional language for any web app? Yes. >Would be interested in known your experiences and opinion compared to something like django or rails. Rails is an abomination, so pretty much anything would be better than that. We rolled our own framework in scala. Despite initial resistance from some dynamic language proponents here, it is now the only thing anyone here will use for web development. Even the python fan won't touch django now. >How difficult is it to build something with a complex domain model? Easier than in dynamic languages. The problem with complex models is that humans can't hold all that information in their heads. Static typing lets us offload a bunch of important information to the compiler and have it error check for us as we go. Our biggest issue has been that scala isn't strong enough, I'd much prefer to be using haskell.
  - jiggy2011 15y ago
    Right , I get that static typing can be an advantage but how is the functional paradigm an advantage in this case? Or is it more than you just want to use something statically typed that isn't Java?
    - SomeOtherGuy 15y ago
      Ah, yes we weren't looking for functional languages specifically, just languages with expressive type systems. As far as I know, the only languages with expressive type systems are also functional so we end up with a functional language as a consequence of that requirement, not due to actively seeking a functional language. We use scala in a pretty functional way, but most of the gains there come in the processing/displaying side rather than the model. Just because that portion lends itself to a functional style of applying chains of functions on data to transform it.
akg 15y ago
Is there performance benchmark comparing Haskell and Erlang? I hear Erlang is also quite performant when handling a large number of requests, but no hard numbers. Are there similar web frameworks for Erlang as Yesod for Haskell? Also, what about Clojure? That runs on the JVM but how does it fare on the "correctness" claim of Haskell, i.e., "If it compiles it's close to what the programmer intended". I'm learning Haskell right now and really loving it. I wonder if I should stick with it for more production projects or make a switch to Erlang/Clojure. I know Erlang has quite a few success stories behind it, CouchDB being one of them.
- apl 15y ago
  > Also, what about Clojure? That runs on the JVM but how > does it fare on the "correctness" claim of Haskell, i.e., > "If it compiles it's close to what the programmer > intended". Clojure's a dynamic language, so fairly different in character and strengths. Save for a couple of statically typed Lisp dialects, provability/correctness/etc. is not really what that language family is all about. If you want JVM and reasonably advanced type systems (given that Haskell's claim to correctness essentially boils down to this), try Scala.
- dons 15y ago
  I think it would be uncontroversial to say that optimized GHC Haskell (statically typed, compiled, optimized, native code) is always faster than current Erlang implementations (dynamically typed, interpreted, lightly optimized). For example, the fastest Erlang programs on the benchmarks game are all slower than all the GHC Haskell programs, * http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=erlang http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Median slowdown relative to GHC is 7x. GHC is aiming for the high performance computing world of late, as well. The Erlang language just doesn't have the facilities for raw number crunching that's needed.
  - fijal 15y ago
    It's always controversial to claim performance numbers without any actual evidence. Note that shootout numbers are by far not evidence about web-server performance.
ericmoritz 15y ago
Haskell web frameworks handle parallel tasks perfectly. For example even better than node.js of course, node.js has no parallelism
- pjscott 15y ago
  I think what was meant was concurrency. Haskell's lightweight user-space threading runtime is modeled after Erlang's.
mxavier 15y ago
I'm having a hard time understanding the intent behind "You shouldn't need to know Haskell". Do you mean in order to complete the tutorial and understand what Yesod does? That's probably true. Being someone who's been studying and using Haskell in personal projects for the past maybe 10 months or so, Haskell's syntax and fundamental design decisions (while spot on, in my book) are different enough from most programmers' skill sets that I don't think they'll make it very far writing a non-trivial Yesod app without knowing Haskell. I'm fairly proficient/enamored with Haskell now but I'm certain I would have crashed and burned if I got my start trying to learn Haskell from Yesod. My first dose of Haskell was attempting to write an XMonad config. That turned out to be a frustrating, several hour long ordeal for me that had me write off Haskell as undecipherable, alien hieroglyphics for quite some time after that. I'd urge anyone reading the tutorial who likes what they see to put in the hard time to get a handle on the language, understand what its good for and what it isn't and then return to web programming with it.
- yogsototh 15y ago
  I am sorry if I didn't made it clearer. Of course, you don't need to know Haskell to follow this tutorial in particular. But it is clear in my mind, you must know Haskell to do something useful with it. And in particular, make a web application, even if using a web framework. As you stated, Haskell is not a language you could learn in 3 hours like I learned the bases of Python. It takes a very long time to learn, particularly when you're not used to functional programming. But an intent of this tutorial was to promote Haskell. Clearly, if someone want to do something a bit more useful, he will very soon realize he must understand Haskell. I added a specific advice in my conclusion similar to yours and pointing some essential resources.
- deleted 15y ago
  [deleted]
- JoshTriplett 15y ago
  Many people saw Ruby for the first time when they looked at a Rails tutorial. Many people see Python for the first time when they look at a Django tutorial. In both cases, you'd still need to learn more about the language to do something useful. I think the disclaimer "You shouldn't need to know Haskell" just means that the same thing works for this tutorial: you don't need to have seen Haskell before going through the tutorial, because you'll learn enough to follow the tutorial, even though you'll need to learn more later.

207 points by yogsototh 15y ago

Finally I know how to draw owls.

gtani 15y ago

You shouldn’t need to know Haskell. Don’t pay attention to all the syntax. If you are curious you can take a look at Applicative Functor. This is a nice, whirlwind tour, maybe the opening benchmarks and jab at node are superfluous. All haskell tutorials hit the speedbump of how to bootstrap haskell understanding, where to make forward references and when to say "Trust me" but code shown here: do blocks, ($), <- and return would be confusing if you didn't know any haskell

yogsototh 15y ago
Should I add a link to this article[^1] for people confused by the Haskell syntax? The opening is not really an attack. This is the way I myself started to be interested in Haskell web programming. [^1]: http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/
- gtani 15y ago
  Yah, maybe just add links at bottom: LYAH, Applicative Functor wiki page. Or maybe mention one syntax feature, IO's and do-blocks, and say "return" and "<-" just kick things into and out of IO's, loosely speaking. Just don't say IO's are like burritos ;-} You could also say, for anybody that's looked at lisps, *ML, F#, scala, erlang, the syntax isn't too bad, and for anybody that knows rails, they'll recognize the same REST'y MVC layers/abstractions. I gather the target audience is folks using dynamically typed languages.

minhajuddin 15y ago

haven't finished reading the whole content, but the zoom in zoom out effects are very annoying.

yogsototh 15y ago
Are you talking about the zoom in when you click on some code block? I was thinking to remove them.
- minhajuddin 15y ago
  the Ctrl + , or Ctrl mouse scroll up or mouse scroll down
  - yogsototh 15y ago
    For me, it takes only one to two second animation. After it stabilize. You can disable javascript and there won't be any CSS animation added.
    - Lewton 15y ago
      for me, in chrome, it takes 8-10 seconds to stabilize. and looks really wonky
      - yogsototh 15y ago
        I disabled animation for chrome.
        tkahn6 15y ago
        Hey your site is really pretty. Would you mind licensing your CSS for personal use? I'd like to use for my blog (which I will start one of these days). Very nice blog post. After working on a Python stack during my part time job (check out Apache libcloud), I can safely say that using a statically typed language is a necessity for any non-trivial project. Without a type system you offload the entire framework onto the programmer. To actually grok the project you have to hold the complexity all in your head instead of using the types as a guide and that makes getting started incredibly challenging.

t-crayford 15y ago

Spelling corrections, noted as I read: "point of vue" -> point of view "shell command are executed" -> "shell commands are executed" "benchmark are here" -> "the benchmarks are here" Also, heroku works just fine with haskell, as long as you compile a static binary on an ubuntu machine. I compile mine on virtual box (via way of vagrant), and have 3 haskell apps (none of them really production ready though) running on heroku right now. Lastly, I don't really think haskell is the right language for a lot of web programming. In haskell, you really want your logic to be as purely functional as possible, but that gets pretty hard to do for web apps that rely on external apis.

yogsototh 15y ago
Thanks! Spell errors corrected! When I said there is no heroku for Haskell it because it is not official. Furthermore, do you have to use a 64bit architecture when compiling (just curious)? I might try it myself. And I even think that the argument against the number of Haskellers is in fact a force instead of a drawback. It filter passionate people. By external APIs, you mean that it would be difficult to write a simple "connect to twitter/facebook" application? Could you tell us about any bad experience you had?
- t-crayford 15y ago
  Yeah, 64bit. I never said anything about number of people... External apis: nearly all the logic in my app leads to either talking to the db, or calling an http api (and haskell can't use https apis that well, you have to use its bindings to libcurl). In general, it feels extremely difficult to pull my logic out of IO (but maybe I'm just too dumb to). It's not that its particularly difficult, it's just that it's not a problem I think haskell is well suited to solve. I've used haskell to teach my self automated logic proofs (just resolution refutation), compression algorithms (huffman encoding and lz77), typechecking and breaking encryption (enigma). Every time university exams roll around, I learning them on paper. It's by far and away the best language I've used for stuff like that. It feels like web-apps with lots of IO aren't really a problem haskell is well suited to solve.

prof_hobart 15y ago

From the bit of Haskell I've managed to learn, it's a great language, and I can see how an awful lot of the errors that you can make in other languages will probably be avoided in Haskell, but I've never understood the (frequently repeated) claim that "If your program compile it will be very close to what the programmer intended". There's nothing I've seen in Haskell, or any other language, that will prevent you implementing the wrong algorithm, or the wrong business rules etc. If you're doing a phsyics simulator (to take an example I've played around with), Haskell is not going to stop you badly miscalculating the gravitational effect of multiple objects, or calculating the mass of an object incorrectly.

jiggy2011 15y ago
I think if someone made a language where it was categorically impossible to do something dumb they'd be very rich indeed. :)
- Chirono 15y ago
  As long as it was also possible to do some non-dumb things, of course...
  - jiggy2011 15y ago
    true, otherwise you could just run your program by piping it into cat.
Peaker 15y ago
That's the difference between an "intentional bug" and an "unintentional bug". The former is when you want the program to do X, and X itself is wrong. Sure, defending against this is rarely possible. The latter is in my experience far more common. When you want the program to do X, but you actually told it to do Y. Haskell catches most of the latter cases. One of the main reasons is the functional purity. Because return values are the only result of a function, and these values are type-checked against a specification, it is much harder to do the wrong thing. For example, an imperative program will idiomatically have methods whose sole effect is mutating their arguments or the objects. Even with a type system -- if you just omit the effects, the compiler really has no way to know that you meant the effects to happen, and you will simply have a bug. A purely functional program will idiomatically use a different style. Instead of mutating arguments and objects, it will return a new value. If you forget to return a new value, the compiler will catch that. Additionally, the types in Haskell are generic by default. The more generic the type of a function, the more restricted is what that function can do. The restrictions narrow the space of wrong things you can do. Another interesting property of Haskell is where it chooses to be on the "restrictiveness+guarantess vs. powerful+unguaranteed" trade-off. It seems many don't even notice that the other side of the "power" coin is "guarantees". The more powerful a construct is -- the less you can say about what it will do. In Haskell, the purity and generic types of functions are two things that heavily restrict code. But there are many other mechanisms to restrict rather than empower code. In many contexts, restrictiveness is considered a bad thing, but in Haskell, this restrictiveness is very useful for reasoning about code. For example, the function of type: (forall a. a -> a) in Haskell can only be the identity function. It cannot print "hello world", and it cannot mutate variables. These restrictions are useful because we now can have useful laws. For example: id . f = f . id = f. And we can derive these useful laws from the type itself, without even looking at the code! By helping us find the most restrictive sub-language that can express the solution, we rule out even more bugs.

jiggy2011 15y ago

Is anyone here using haskell or a similar funtional language for any web app? Would be interested in known your experiences and opinion compared to something like django or rails. How difficult is it to build something with a complex domain model?

SomeOtherGuy 15y ago
>Is anyone here using haskell or a similar funtional language for any web app? Yes. >Would be interested in known your experiences and opinion compared to something like django or rails. Rails is an abomination, so pretty much anything would be better than that. We rolled our own framework in scala. Despite initial resistance from some dynamic language proponents here, it is now the only thing anyone here will use for web development. Even the python fan won't touch django now. >How difficult is it to build something with a complex domain model? Easier than in dynamic languages. The problem with complex models is that humans can't hold all that information in their heads. Static typing lets us offload a bunch of important information to the compiler and have it error check for us as we go. Our biggest issue has been that scala isn't strong enough, I'd much prefer to be using haskell.
- jiggy2011 15y ago
  Right , I get that static typing can be an advantage but how is the functional paradigm an advantage in this case? Or is it more than you just want to use something statically typed that isn't Java?
  - SomeOtherGuy 15y ago
    Ah, yes we weren't looking for functional languages specifically, just languages with expressive type systems. As far as I know, the only languages with expressive type systems are also functional so we end up with a functional language as a consequence of that requirement, not due to actively seeking a functional language. We use scala in a pretty functional way, but most of the gains there come in the processing/displaying side rather than the model. Just because that portion lends itself to a functional style of applying chains of functions on data to transform it.

akg 15y ago

Is there performance benchmark comparing Haskell and Erlang? I hear Erlang is also quite performant when handling a large number of requests, but no hard numbers. Are there similar web frameworks for Erlang as Yesod for Haskell? Also, what about Clojure? That runs on the JVM but how does it fare on the "correctness" claim of Haskell, i.e., "If it compiles it's close to what the programmer intended". I'm learning Haskell right now and really loving it. I wonder if I should stick with it for more production projects or make a switch to Erlang/Clojure. I know Erlang has quite a few success stories behind it, CouchDB being one of them.

apl 15y ago
> Also, what about Clojure? That runs on the JVM but how > does it fare on the "correctness" claim of Haskell, i.e., > "If it compiles it's close to what the programmer > intended". Clojure's a dynamic language, so fairly different in character and strengths. Save for a couple of statically typed Lisp dialects, provability/correctness/etc. is not really what that language family is all about. If you want JVM and reasonably advanced type systems (given that Haskell's claim to correctness essentially boils down to this), try Scala.
dons 15y ago
I think it would be uncontroversial to say that optimized GHC Haskell (statically typed, compiled, optimized, native code) is always faster than current Erlang implementations (dynamically typed, interpreted, lightly optimized). For example, the fastest Erlang programs on the benchmarks game are all slower than all the GHC Haskell programs, * http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=erlang http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Median slowdown relative to GHC is 7x. GHC is aiming for the high performance computing world of late, as well. The Erlang language just doesn't have the facilities for raw number crunching that's needed.
- fijal 15y ago
  It's always controversial to claim performance numbers without any actual evidence. Note that shootout numbers are by far not evidence about web-server performance.

ericmoritz 15y ago

Haskell web frameworks handle parallel tasks perfectly. For example even better than node.js of course, node.js has no parallelism

pjscott 15y ago
I think what was meant was concurrency. Haskell's lightweight user-space threading runtime is modeled after Erlang's.

mxavier 15y ago

I'm having a hard time understanding the intent behind "You shouldn't need to know Haskell". Do you mean in order to complete the tutorial and understand what Yesod does? That's probably true. Being someone who's been studying and using Haskell in personal projects for the past maybe 10 months or so, Haskell's syntax and fundamental design decisions (while spot on, in my book) are different enough from most programmers' skill sets that I don't think they'll make it very far writing a non-trivial Yesod app without knowing Haskell. I'm fairly proficient/enamored with Haskell now but I'm certain I would have crashed and burned if I got my start trying to learn Haskell from Yesod. My first dose of Haskell was attempting to write an XMonad config. That turned out to be a frustrating, several hour long ordeal for me that had me write off Haskell as undecipherable, alien hieroglyphics for quite some time after that. I'd urge anyone reading the tutorial who likes what they see to put in the hard time to get a handle on the language, understand what its good for and what it isn't and then return to web programming with it.

yogsototh 15y ago
I am sorry if I didn't made it clearer. Of course, you don't need to know Haskell to follow this tutorial in particular. But it is clear in my mind, you must know Haskell to do something useful with it. And in particular, make a web application, even if using a web framework. As you stated, Haskell is not a language you could learn in 3 hours like I learned the bases of Python. It takes a very long time to learn, particularly when you're not used to functional programming. But an intent of this tutorial was to promote Haskell. Clearly, if someone want to do something a bit more useful, he will very soon realize he must understand Haskell. I added a specific advice in my conclusion similar to yours and pointing some essential resources.
deleted 15y ago
[deleted]
JoshTriplett 15y ago
Many people saw Ruby for the first time when they looked at a Rails tutorial. Many people see Python for the first time when they look at a Django tutorial. In both cases, you'd still need to learn more about the language to do something useful. I think the disclaimer "You shouldn't need to know Haskell" just means that the same thing works for this tutorial: you don't need to have seen Haskell before going through the tutorial, because you'll learn enough to follow the tutorial, even though you'll need to learn more later.