You might not need a deep understanding of category theory to write useful programs in Haskell, but the downsides of relying on those explicit monads to control state and interactions still show through in practical code.<p>Here’s an early example from the article:<p><pre><code> import Control.Monad.State
type Interact a = StateT Int IO a
repl :: Interact ()
repl = forever $ do
val <- liftIO readLn
state <- get
liftIO $ putStr "Total: "
liftIO $ print (val + state)
put val
main = runStateT repl 0
</code></pre>
Here’s something with similar behaviour written in Python, an imperative language with a reputation for being easy to read:<p><pre><code> total = 0
while True:
total += input()
print "Total:", total
</code></pre>
The difference is striking. The latter is obviously much more concise. Ironically, it also seems clearer about how the state is used, having the initialization, reading and writing of that state all kept together. It’s worth considering that the stateful logic is relatively kind here, too, because there’s only a single value that needs to be maintained via StateT in the Haskell version.<p>The Python code has the added advantage of actually being correct, assuming that the intended behaviour really is to add up the total of all entered numbers over time as the output suggests.<p>I think this example is instructive in terms of advancing industrial practice rather than the theoretical state of the art. Haskell demonstrates a lot of nice features that mainstream industrial languages lack today, but as soon as any sort of state or effects enter the picture, it becomes absurdly complicated to describe even simple systems. I would love to have future languages incorporate some of the safety that Haskell offers, but I think to catch on with working programmers they will have to hide away a lot of the state/effect details where they aren’t needed, just as tools like type inference have hidden away their own form of boilerplate. It’s not just about not needing to be an expert on category theory, it’s about not having to be aware of it at all.
I don't think you're going to convince existing web developers to adopt Haskell.<p>The second example from the article uses 8-lines of Haskell, a hand-waving explanation of a state transformer monad, composition, and a state transition diagram to demonstrate how easy it is to write trivial Haskell programs. The program in question takes a number from stdin, adds it to a counter, and prints the result.<p>"Web developers," being those who have experience building applications using web-based technologies, have a plethora of tools and languages at their disposal that don't require the up-front investment of learning Haskell.<p>Haskell has a lot to offer but I suspect the only people interested in using Haskell in their web application projects are Haskell developers or people who've been convinced that they will be smarter if they learn Haskell.
One thing I haven't seen mentioned here is that web development is often not a one-man endeavor. At its most basic, you commonly have separation between front- and back-end. So unless you plan on doing it all yourself, you will need to find a front-end developer who is either familiar with Clay, JMacro and Fay; or who is willing to learn; and frankly, I don't think that's a very likely scenario, given the scant usage of Haskell as a web development language.<p>Also, the example of the compiled JavaScript from Fay is horribly obfuscated:<p><pre><code> return Fay$$_(Fay$$_(
Fay$$cons)(i))(Fay$$_(
Prelude$enumFrom)(
Fay$$_(Fay$$_(
Fay$$add)(i))(1)
));
</code></pre>
Oh, God, my eyes. Any idea at all what that does? I can tell you one thing: I would not want to debug that on a Friday night. Or a Tuesday afternoon. Or ever, really.<p>Kind of have to agree with a few of the other commenters here who are saying things along the lines of "You can do anything with a hammer, if a hammer is what you have."<p>Also: this reminds me of a "LISP for Web Development" talk I went to a few years ago. The speaker was talking to a bunch of web devs about how LISP has an undeserved reputation for being domain specific (academia, astronomy, whatever). He then went on to explain how you could use it for calculating the results of some kind of physics experiment and output it as an HTML table. Uh-huh. My buddy and I walked out after about 25 minutes.<p>Am I being unfair?<p>>> As an example of we’ll use JMacro to implement a simple translator for the untyped typed lambda calculus.<p>Nope.
I'm just getting started with Haskell and there will soon come a time where I need to jump in the deep end. When I'm ready to learn Category theory, what background will I need? Is elementary calculus and a little linear algebra enough? Or am I going to need some more advanced math concepts? Once I've got the right background, where should I go to learn Category theory?
My long term bet is Haskell, but boy do the examples look ugly. And most of Haskell really is ugly. My mind just can't get around type names like "M a p f b c => (a -> p) -> b -> c -> a" just yet. I know it's not hard to understand, but it is hard to parse and build up context.<p>Looking forward to having 5+ years of experience in this brilliant language.
I really like Stephen's writing style: no frills, concise, but he still spends time explaining the hard things. Plus he usually writes about things I don't understand so I come away having learned something.
One of the most challenging things about Haskell tutorials is the difficulty in determining the etymology of very terse function names.<p>For example, what does the M in <i>forM_</i> stand for? Monad? Something else? What about <i>liftM</i>? Why is it called lifting? Is the M here the same as the M in <i>forM_</i>?<p>These are just a few examples from this tutorial, but I find that this is pretty much common everywhere in the Haskell world, making it hard to parse semantic meaning from function names if you aren't already immersed in the language and community and well versed in the lingo.<p>One of the best things I've learned to break out of this is to search for JavaScript implementations of many Haskell concepts when such a concept is doable in JavaScript. It usually leads me to enough understanding of what some function is trying to accomplish to proceed with whatever Haskell tutorial I happen to be reading.
If you like hammers you can make them do anything. Or is the analogy nails? I forget.<p>The real question is why use Haskell instead of something else that most people generally consider targeted at the web?
>Do I still need a graduate degree in category theory to write to a file?<p>No.<p>> Will I need a graduate degree in category theory to parse the next paragraph in this article?<p>Oh. Um wait, define web developer for me again?
I've been meaning to ask this for a while now: what's the appeal of Haskell? It doesn't come off as a pleasure to program in. Could someone who knows the language share their thoughts?
Set aside the small examples and theory about what's best, no argument beats a real world example.<p>Are there any large opensource haskell web apps that one could read to see how it really done ?
Reminds me of "Step 2: Draw the rest of the fucking owl." It does not follow that because Hello, World is easy, therefore IO in general is easy.
All of the examples of aeson I've seen have been for very simple, flat, json objects. What happens when you have json with nested objects. Do you have to create types for each intermediate json object or can you pull the values out into the top level type? If so how?