14 ms·

Haskell for Web Developers

128 points by rwosync 13y ago

deleted 13y ago
[deleted]
Arnor 13y ago
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?
- pestaa 13y ago
  Well, I've been continously reassured that learning the theory is unneccessary if all you want is to use Haskell effectively.
  - freyrs3 13y ago
    Learning category theory is about as important to programming in Haskell as denotational semantics are to programming in C. Which is to say, not very important unless you're interested in deeper computer science.
    - Arnor 13y ago
      So lets assume I'm interested in deeper computer science :)
      - nightski 13y ago
        I'd still just start with learning Haskell. It will not be nearly as intimidating and you'll see how the ideas work out in practice in the programming world. Then move on to category theory. But hey if you are ambitious by all means dive right in.
      - awj 13y ago
        Well, then I think you should either learn category theory directly or learn Haskell without it first. Learning two brand new things at once usually produces an incomplete understanding of both.
        Arnor 13y ago
        Well said!
- asdasf 13y ago
  >I'm just getting started with Haskell and there will soon come a time where I need to jump in the deep end Your implication is that "jump in the deep end" means learn category theory. That is entirely unnecessary. If you are interested in category theory, by all means go for it. But don't think it is in any way a haskell requirement.
- jcurbo 13y ago
  We had a discussion on this when Stephen's last post showed up here: https://news.ycombinator.com/item?id=6041726 https://news.ycombinator.com/item?id=6041726 I've been looking into this myself and I have a similar background as you (elementary calculus and linear algebra; I also took number theory as part of a math minor). So far it looks like I should pick up a bit of abstract algebra/topology (rings, fields, groups, etc) then I should be able to start off on the shallow end of category theory and work from there. At the same time I need to improve my understanding of how monads, monad transformers, monoids, functors, etc work in Haskell from an operational standpoint; I have a basic understanding now but I'd like to dig deeper. The thread I linked above has a lot of links to books and stuff like Reddit's r/haskell and other places, that you can sort through to see what works for you. I have yet to make that determination for myself, but there's plenty to choose from. I actually picked up a copy of Benjamin Pierce's "Basic Category Theory for Computer Scientists" a few years ago based on someone's recommendation, way before I got into Haskell, and didn't make the connection until I picked up his book on type theory recently (while researching a paper on FP) and thought his name looked familiar. Ultimately I'm hoping to be able to get deep into type theory and go through that Homotopy Type Theory book that came out recently.
  - davidcuddeback 13y ago
    Thanks for the response. I was interested in the answer to this question as well. I read through the thread [1] that you linked to, and seems like the consensus is the same thing you said: it's best to learn abstract algebra and topology first. Does anyone know of some good sources for those topics? The other threads are understandably focused on category theory. As for category theory, after reading through that thread [1] and the Reddit thread [2] that it links to, I think Conceptual Mathematics: A First Introduction to Categories [3] will be my first read on category theory (but probably followed by the Rosetta Stone paper). That book receives some strong recommendations as a first book in the Reddit thread [2]. [1] https://news.ycombinator.com/item?id=6041726 https://news.ycombinator.com/item?id=6041726 [2] http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_category_theory_for_beginners/ http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_cat... [3] http://www.amazon.com/Conceptual-Mathematics-First-Introduction-Categories/dp/052171916X http://www.amazon.com/Conceptual-Mathematics-First-Introduct...
- jrokisky 13y ago
  I'm in a similar situation. My math background consists of the required courses for a BA in CS. I tried to start with Mac Lane's "Categories for the Working Mathematician", but it was too dense for me. I switched to Awodey's "Category Theory" and that has been easier to follow. Wikipedia, Youtube, and other online sources have been very helpful. It's been a very rewarding experience so far.
- ufo 13y ago
  In my experience, reading the Typeclassopedia[1] is probably more than enough for most people. Some people like thinking about category theory when they program but in the end its still just a bunch of (cleverly organized) abstract interfaces. [1] http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia
- polymatter 13y ago
  I will echo the choir here that states that Category theory is not Haskell. Category theory gave Haskell some neat tricks, but its not necessary to understand it to do anything practical. Category theory is so abstract and general that it is unlikely to come up with any grand solutions unless you are phd'ing. If you enjoy it anyway: I like (http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia) for how it discusses how the different type classes in Haskell relate. I found this a lot more practical coming from this direction but your taste may vary. I'd also highly recommend going through Types and Progrmaming Languages by Pierce (http://www.cis.upenn.edu/~bcpierce/tapl/ http://www.cis.upenn.edu/~bcpierce/tapl/) if you are interested in the area. This gives you a good background on type system stuff. There are tons more links to category theory stuff here (http://mathoverflow.net/questions/903/resources-for-learning-practical-category-theory http://mathoverflow.net/questions/903/resources-for-learning...)
- pasquinelli 13y ago
  i'm not sure what you need to learn category theory (but i'm working on it). so far it seems you need a to be able to write and read proofs, and not much else. of course, that doesn't have much to do with haskell, but if you have an interest in abstract algebra beyond its applicability in haskell, you're in luck, because it doesn't seem to require much background. all it needs is for your head asplode. caveat: i've tried to learn category theory, and found that i could barely follow a proof, let alone write one. so i picked up a book: http://www.pearsonhighered.com/educator/product/Mathematical-Proofs-A-Transition-to-Advanced-Mathematics-2E/9780321390530.page http://www.pearsonhighered.com/educator/product/Mathematical... and i'm working through it now. i could come back to category theory and find that i'm still lost, but i don't think so. i haven't really had much trouble writing haskell without a decent math background.
- dllthomas 13y ago
  I'm currently working my way through "Basic Category Theory For Computer Scientists" with a local meetup group. I don't have enough to compare it to, to say whether I'd recommend it as a book. I've been enjoying it, though. If you're in the Bay Area, join the meetup group - we're only just starting chapter 2. As for background, I think some familiarity with set theory would be most useful, groups and rings and such a bonus. Calculus won't be of much help. Linear algebra might, depending.
MatthewPhillips 13y ago
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?
- jb55 13y ago
  As long as your nested types have implemented or derived the ToJSON typeclass, nested structures will serialize just fine
- nightski 13y ago
  Nested json objects are no different. You do not need to create an intermediate data type for each json object (that would be ridiculous). The docs are pretty clear on this, a quick hoogle of hackage would get you what you need.
- ocharles 13y ago
  When it comes to encoding JSON, you don't have to represent everything. For example, you can always do: object [ "foo" .= object [ "bar" .= [ "Yum", "Waffles!"] ] ] Which will give you {"foo": {"bar": ["Yum", "Waffles!"]}}. You can do traversals when decoding too: tasty :: JSON -> Parser [String] tasty json = json .: "foo" >>= (.: "bar") You can also do similar things with lens-aeson: tasty json = json & key "foo" . key "bar" . _Array Though I'm less familiar with that, and you won't be inside the Parser monad.
- awj 13y ago
  Aeson is built on the Show and Generic type classes. Anything that supports those also basically supports the FromJSON/ToJSON classes that Aeson needs. Lists already support it (for types that also support aeson), as do Map/HashMap for various text types mapping to something that supports aeson. So, complex nested structures are a matter of defining Show and Generic instances for any types that don't already have them. From there you can trivially make those types aeson-compatible. Since so many common types are already supported, adding support for your own nested types isn't too difficult. The example use automatic derivation of Generic instances, which may result in some performance problems but is the easiest way to get off the ground.
pestaa 13y ago
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. Looking forward to having 5+ years of experience in this brilliant language.
- ocharles 13y ago
  Rest assured it doesn't take 5 years to get there :)
- k_bx 13y ago
  Yeah, but type foo :: M a p f b c => (a -> p) -> b -> c -> a foo f b c = ... would look something like A foo<M<a>,p,f,b,c>(AP f, B b, C c) { ... in Java (I don't know Java, but I hope you gen an idea). I mean, this is a really complex example you've shown. And most of the times, you can (just like everywhere else) write simple type synonyms to express what you want.
- ExpiredLink 13y ago
  Why do you think a language that "really is ugly" and " is hard to parse" must be a "brilliant language"? Maybe the emperor has no clothes? Maybe Haskell is just what you see: suitable for academic discourse, unusable for real-wold programming.
  - asdasf 13y ago
    Lets throw reason and common sense to the wind and pretend the subjective "haskell is ugly" is objectively true. Given that, could you explain to me how you make the seemingly wild and random leap to "haskell is suitable for academic discourse, unsuitable for real-world programming"? Perl is widely considered to be ugly, is it also only suitable for academic discourse? What properties do you believe haskell possesses that makes it unsuitable for "real-world programming"? What do you even deem "real-world programming" to be? It seems rather bizarre to suggest haskell is unsuitable for real-world programming in a discussion about examples of using haskell for real-world programming.
egonschiele 13y ago
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.
gtani 13y ago
these "how to read _" posts are helpful mini- style guide/naming convention roadmaps http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_does_this_function_do.3F http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_...
themodelplumber 13y ago
>Do I still need a graduate degree in category theory to write to a file? No. > Will I need a graduate degree in category theory to parse the next paragraph in this article? Oh. Um wait, define web developer for me again?
gnuvince 13y ago
In the second example, shouldn't it be `mapM_` instead of `forM_` with this ordering of the arguments?
ionelm 13y ago
Set aside the small examples and theory about what's best, no argument beats a real world example. Are there any large opensource haskell web apps that one could read to see how it really done ?
- gtani 13y ago
  http://www.joachim-breitner.de/blog/archives/606-Real-World-Haskell-Applications.html http://www.joachim-breitner.de/blog/archives/606-Real-World-... https://www.fpcomplete.com/page/case-studies https://www.fpcomplete.com/page/case-studies
  - hbbio 13y ago
    So, the short answer is no. And there are many reasons to that. One of them: Haskell developers tend to love the technology and forget about the product.
    - asdasf 13y ago
      How do you come to that conclusion? I am all about the product, which is why it isn't open source.
      - dllthomas 13y ago
        Well, I think there's clearly such a contingent, and I think it's more visible because of Haskell's academic heritage; it may also be larger, but I am much less confident in that - there are people who love pushing the tech in most languages.
        asdasf 13y ago
        I think it isn't more visible, it is just more talked about. There is a perception, not a reality.
        dllthomas 13y ago
coldcode 13y ago
If you like hammers you can make them do anything. Or is the analogy nails? I forget. The real question is why use Haskell instead of something else that most people generally consider targeted at the web?
- asdasf 13y ago
  >The real question is why use Haskell instead of something else that most people generally consider targeted at the web? That applies to any language. Why use perl? Why use PHP? Why use ruby? Why use java? Web development isn't magical, it is just ordinary, general purpose programming. So people use ordinary, general purpose programming languages. Like perl, PHP, ruby, java, and haskell.
- dragonwriter 13y ago
  > The real question is why use Haskell instead of something else that most people generally consider targeted at the web? An equally "real" question is why people think "the web" is special in such a way that it requires a different programming language for back-end applications than other server applications use.
  - dllthomas 13y ago
    That seems like a far more real question.
  - SiVal 13y ago
    I would say that the difference is that the Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable. There are many programs that run on servers, grinding away on deep questions for extended periods with no more than the bare minimum of communication with the rest of the universe---maybe just a terse "42" at the end of a long run. But the Web is about talking to users thousands of times per second, sending it all in a hurricane of streams to a database, fetching data for each of them from various databases, streaming it out to a third-party credit card processor, sending the results back to the users.... Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams.
film42 13y ago
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?
- asdasf 13y ago
  The appeal for me is that it is an expressive, high level language with a useful type system and high performance. It is a pleasure to program in.
- egonschiele 13y ago
  I love programming in Haskell! Seriously, the reason it's on HN so much is that Haskellers love the language. Here are some reasons: * Types, types, types. You're probably sick of hearing about Haskell's type system, but it's amazing. Gives you almost all the flexibility of a language like Ruby, PLUS you can encode a lot of your assumptions in types...so if there's a bug you'll catch it at compile time. I like how I can just write a LOT of Haskell code without testing it, and then just compile my project and find all the issues I need to fix. It makes prototyping really easy and fast. * Awesome abstractions. Functors, monads, first class functions: you know how java is verbose and you end up writing the same boilerplate over and over? Haskell is the opposite. * Awesome syntax. I really love Haskell's syntax: super clean, and you can modify it however you like. I like writing very readable code (you read code way more often than you write it) and Haskell lets me write very readable code. * Neat libraries! All that stuff other languages are trying to work around? Like concurrency, or sandboxing? Part of the standard library already. I had written this post a while back (http://adit.io/posts/2012-03-10-building_a_concurrent_web_scraper_with_haskell.html http://adit.io/posts/2012-03-10-building_a_concurrent_web_sc...) that shows exactly how easy it is. Seriously, if you're curious about languages at all, give Haskell a try.
  - tel 13y ago
    I think something that's hard to appreciate before you learn Haskell is that while a lot of the abstractions used in the language are more complex and abstract than you're used to using, it's because the language/types/compiler help to lift an enormous mental burden you usually carry while reasoning about code in most languages. Purity is great not because you make fewer errors but because when writing pure code you can focus on what needs to happen instead of worrying about state/effects/control flow. While having to sprinkle `liftIO`s around your imperative code sounds dreadful, it's quickly appreciated as a statically checked marker for "code that you need to think harder about". So what you end up with is a fantastic playground to use mental tools unavailable in other languages due to the complexity overhead. You also have a suite of abstractions that "almost never break" due to their invariants being encoded into the type system and thus checked every single time you reload the file. People often compare this effect to having a large suite of automatically generated test specs run on every compile. It's like that, yeah, but humans can write tests this bulletproof and no suite runs this quickly. I get jitters writing Ruby sometimes now because I know I'm fallible and I have to store so much more in my mind in order to reason about it.
Chris_Newton 13y ago
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. Here’s an early example from the article: 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 Here’s something with similar behaviour written in Python, an imperative language with a reputation for being easy to read: total = 0 while True: total += input() print "Total:", total 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. 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. 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.
- sseveran 13y ago
  In real life (not contrived examples) haskell greatly simplifies dealing with state. Isolating IO makes it much simpler to reason about where exceptions can come from.
  - Chris_Newton 13y ago
    In real life (not contrived examples) haskell greatly simplifies dealing with state. That is the assumption I’m questioning. For example, let’s consider quicksort. Hopefully we can agree that this is a substantial and practically useful algorithm, and one that fundamentally relies on mutable state for its performance and scalability. I recently posted a link here to a discussion on haskell.org[1] about implementing a real quicksort. This was contrasted with the usual elegant but not-really-quicksort version that has propped up a million functional programming advocacy posts, and with the original C version[2]. Neither Haskell version seems particularly simple to me when compared to the C, and I see little extra safety in return for all the Haskell syntactic overhead that couldn’t have been had just as well with a couple of "const" annotations in numerous imperative languages. Obviously not every case is as self-contained as this algorithm and in other contexts Haskell’s approach would fare better. But a lot of real world code is stateful, and a lot of it uses this kind of local state, and so I contend that making everything explicit, Haskell-style, does not greatly simplify dealing with state in general. [1] http://www.haskell.org/haskellwiki/Introduction/Direct_Translation http://www.haskell.org/haskellwiki/Introduction/Direct_Trans... [2] http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_C http://www.haskell.org/haskellwiki/Introduction#Quicksort_in...
GeneralMayhem 13y ago
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.
- gnuvince 13y ago
  Can you explain what you feel is hard about IO in Haskell that isn't hard in other languages? Sure, you need to get used to the different way of working with IO (remembering to use <- instead let, calling return to wrap the result back into the IO type, etc.), but after some time, it's pretty much automatic.
ahawkins 13y ago
I really need to learn Haskell. Thanks for this.
Rickasaurus 13y ago
In this blog post about how easy and non-academic Haskell is I'm going to implement the lambda calculus as an example
agentultra 13y ago
I don't think you're going to convince existing web developers to adopt Haskell. 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. "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. 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.
- asdasf 13y ago
  I've had the opposite experience. Everyone I know who does web development is frustrated by the poor quality of work they produce, and how hard it is to maintain the projects they've done. Re-writing a project from scratch every ~5 years is essentially normal development practice. I learned haskell just for web development. I am not smarter as a result, I just have a better tool now that helps me produce better results. My wife then decided to learn haskell for web development too. Neither of us have a background in computer science, or even a degree at all. We learned haskell for purely practical reasons, and we keep using it for those purely practical reasons.
  - agentultra 13y ago
    ymmv; I hate web development but maintainability is the least of my concerns. I have frameworks for that.
    - asdasf 13y ago
      What framework, and what is it doing to help with maintenance? My experience has been that typical RoRish frameworks are so heavily concerned with trying to make the initial writing of the app easier that they actually hinder long term maintenance.
malandrew 13y ago
One of the most challenging things about Haskell tutorials is the difficulty in determining the etymology of very terse function names. For example, what does the M in forM_ stand for? Monad? Something else? What about liftM? Why is it called lifting? Is the M here the same as the M in forM_? 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. 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.
- dons 13y ago
  Yes, the M is for monad. Eg map vs mapM
- hiker 13y ago
  Let me hoogle those for you (sic) http://www.haskell.org/hoogle/?hoogle=liftM http://www.haskell.org/hoogle/?hoogle=liftM =-)
- dllthomas 13y ago
  It's called lifting because it's moving something between levels. In the case of liftM, it's moving a function that operates on type a and returns type b, to one that operates on a wrapped type a and returns a wrapped type b. Since a monad should be a functor, and the types are the same, I'm pretty confident that this is the same thing as fmap - though in principle there could be a monad with no functor instance defined where you would have to use liftM (for now: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal http://www.haskell.org/haskellwiki/Functor-Applicative-Monad...).
- ufo 13y ago
  The positive news is that while it might take a while to learn the conventions, usually the conventions are enforced all around. In your case, the conventions are documented in the docs for Control.Monad, the library those functions are from: The functions in this library use the following naming conventions: > A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example, filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] > A postfix '_' changes the result type from (m a) to (m ()). Thus, for example: sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m () > A prefix 'm' generalizes an existing function to a monadic form. Thus, for example: sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html http://www.haskell.org/ghc/docs/latest/html/libraries/base/C... Personally, the things that I found hard were idioms (like learning that $ is just avoiding parenthesis, "go" is for loops, etc) and how theres a lot of libraries that make the code shorter at the expense of forcing you to be aware of them (for example, applicatives <$> <*> look alien until you learn what they are and monad transformers add a lot of "magic" to the code as well as force you to use annoying lifts all over the place)
venutip 13y ago
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. Also, the example of the compiled JavaScript from Fay is horribly obfuscated: return Fay$$_(Fay$$_( Fay$$cons)(i))(Fay$$_( Prelude$enumFrom)( Fay$$_(Fay$$_( Fay$$add)(i))(1) )); 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. 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." 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. Am I being unfair? >> As an example of we’ll use JMacro to implement a simple translator for the untyped typed lambda calculus. Nope.
- asdasf 13y ago
  >Am I being unfair? I'm not sure I would call it unfair, but I wouldn't call it reasonable or logical. You don't have to use haskell for your front end development if you don't have someone to do it. You don't have to use haskell for your back end development if you don't have someone to do it. He just showed some of what is available if you do want to do it. Our front end developer knows haskell, and works on the backend as well writing haskell. She still doesn't use clay or fay though, she uses SASS and just plain old javascript. Also, Fay output isn't obfuscated, it is just accurately translating haskell to javascript, which means lazy evaluation.
- gnuvince 13y ago
  > 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. Do you often debug the assembler output of your compiler? Same thing; fix the Fay code, not the Javascript that the compiler generates.

128 points by rwosync 13y ago

deleted 13y ago

[deleted]

Arnor 13y ago

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?

pestaa 13y ago
Well, I've been continously reassured that learning the theory is unneccessary if all you want is to use Haskell effectively.
- freyrs3 13y ago
  Learning category theory is about as important to programming in Haskell as denotational semantics are to programming in C. Which is to say, not very important unless you're interested in deeper computer science.
  - Arnor 13y ago
    So lets assume I'm interested in deeper computer science :)
    - nightski 13y ago
      I'd still just start with learning Haskell. It will not be nearly as intimidating and you'll see how the ideas work out in practice in the programming world. Then move on to category theory. But hey if you are ambitious by all means dive right in.
    - awj 13y ago
      Well, then I think you should either learn category theory directly or learn Haskell without it first. Learning two brand new things at once usually produces an incomplete understanding of both.
      - Arnor 13y ago
        Well said!
asdasf 13y ago
>I'm just getting started with Haskell and there will soon come a time where I need to jump in the deep end Your implication is that "jump in the deep end" means learn category theory. That is entirely unnecessary. If you are interested in category theory, by all means go for it. But don't think it is in any way a haskell requirement.
jcurbo 13y ago
We had a discussion on this when Stephen's last post showed up here: https://news.ycombinator.com/item?id=6041726 https://news.ycombinator.com/item?id=6041726 I've been looking into this myself and I have a similar background as you (elementary calculus and linear algebra; I also took number theory as part of a math minor). So far it looks like I should pick up a bit of abstract algebra/topology (rings, fields, groups, etc) then I should be able to start off on the shallow end of category theory and work from there. At the same time I need to improve my understanding of how monads, monad transformers, monoids, functors, etc work in Haskell from an operational standpoint; I have a basic understanding now but I'd like to dig deeper. The thread I linked above has a lot of links to books and stuff like Reddit's r/haskell and other places, that you can sort through to see what works for you. I have yet to make that determination for myself, but there's plenty to choose from. I actually picked up a copy of Benjamin Pierce's "Basic Category Theory for Computer Scientists" a few years ago based on someone's recommendation, way before I got into Haskell, and didn't make the connection until I picked up his book on type theory recently (while researching a paper on FP) and thought his name looked familiar. Ultimately I'm hoping to be able to get deep into type theory and go through that Homotopy Type Theory book that came out recently.
- davidcuddeback 13y ago
  Thanks for the response. I was interested in the answer to this question as well. I read through the thread [1] that you linked to, and seems like the consensus is the same thing you said: it's best to learn abstract algebra and topology first. Does anyone know of some good sources for those topics? The other threads are understandably focused on category theory. As for category theory, after reading through that thread [1] and the Reddit thread [2] that it links to, I think Conceptual Mathematics: A First Introduction to Categories [3] will be my first read on category theory (but probably followed by the Rosetta Stone paper). That book receives some strong recommendations as a first book in the Reddit thread [2]. [1] https://news.ycombinator.com/item?id=6041726 https://news.ycombinator.com/item?id=6041726 [2] http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_category_theory_for_beginners/ http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_cat... [3] http://www.amazon.com/Conceptual-Mathematics-First-Introduction-Categories/dp/052171916X http://www.amazon.com/Conceptual-Mathematics-First-Introduct...
jrokisky 13y ago
I'm in a similar situation. My math background consists of the required courses for a BA in CS. I tried to start with Mac Lane's "Categories for the Working Mathematician", but it was too dense for me. I switched to Awodey's "Category Theory" and that has been easier to follow. Wikipedia, Youtube, and other online sources have been very helpful. It's been a very rewarding experience so far.
ufo 13y ago
In my experience, reading the Typeclassopedia[1] is probably more than enough for most people. Some people like thinking about category theory when they program but in the end its still just a bunch of (cleverly organized) abstract interfaces. [1] http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia
polymatter 13y ago
I will echo the choir here that states that Category theory is not Haskell. Category theory gave Haskell some neat tricks, but its not necessary to understand it to do anything practical. Category theory is so abstract and general that it is unlikely to come up with any grand solutions unless you are phd'ing. If you enjoy it anyway: I like (http://www.haskell.org/haskellwiki/Typeclassopedia http://www.haskell.org/haskellwiki/Typeclassopedia) for how it discusses how the different type classes in Haskell relate. I found this a lot more practical coming from this direction but your taste may vary. I'd also highly recommend going through Types and Progrmaming Languages by Pierce (http://www.cis.upenn.edu/~bcpierce/tapl/ http://www.cis.upenn.edu/~bcpierce/tapl/) if you are interested in the area. This gives you a good background on type system stuff. There are tons more links to category theory stuff here (http://mathoverflow.net/questions/903/resources-for-learning-practical-category-theory http://mathoverflow.net/questions/903/resources-for-learning...)
pasquinelli 13y ago
i'm not sure what you need to learn category theory (but i'm working on it). so far it seems you need a to be able to write and read proofs, and not much else. of course, that doesn't have much to do with haskell, but if you have an interest in abstract algebra beyond its applicability in haskell, you're in luck, because it doesn't seem to require much background. all it needs is for your head asplode. caveat: i've tried to learn category theory, and found that i could barely follow a proof, let alone write one. so i picked up a book: http://www.pearsonhighered.com/educator/product/Mathematical-Proofs-A-Transition-to-Advanced-Mathematics-2E/9780321390530.page http://www.pearsonhighered.com/educator/product/Mathematical... and i'm working through it now. i could come back to category theory and find that i'm still lost, but i don't think so. i haven't really had much trouble writing haskell without a decent math background.
dllthomas 13y ago
I'm currently working my way through "Basic Category Theory For Computer Scientists" with a local meetup group. I don't have enough to compare it to, to say whether I'd recommend it as a book. I've been enjoying it, though. If you're in the Bay Area, join the meetup group - we're only just starting chapter 2. As for background, I think some familiarity with set theory would be most useful, groups and rings and such a bonus. Calculus won't be of much help. Linear algebra might, depending.

MatthewPhillips 13y ago

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?

jb55 13y ago
As long as your nested types have implemented or derived the ToJSON typeclass, nested structures will serialize just fine
nightski 13y ago
Nested json objects are no different. You do not need to create an intermediate data type for each json object (that would be ridiculous). The docs are pretty clear on this, a quick hoogle of hackage would get you what you need.
ocharles 13y ago
When it comes to encoding JSON, you don't have to represent everything. For example, you can always do: object [ "foo" .= object [ "bar" .= [ "Yum", "Waffles!"] ] ] Which will give you {"foo": {"bar": ["Yum", "Waffles!"]}}. You can do traversals when decoding too: tasty :: JSON -> Parser [String] tasty json = json .: "foo" >>= (.: "bar") You can also do similar things with lens-aeson: tasty json = json & key "foo" . key "bar" . _Array Though I'm less familiar with that, and you won't be inside the Parser monad.
awj 13y ago
Aeson is built on the Show and Generic type classes. Anything that supports those also basically supports the FromJSON/ToJSON classes that Aeson needs. Lists already support it (for types that also support aeson), as do Map/HashMap for various text types mapping to something that supports aeson. So, complex nested structures are a matter of defining Show and Generic instances for any types that don't already have them. From there you can trivially make those types aeson-compatible. Since so many common types are already supported, adding support for your own nested types isn't too difficult. The example use automatic derivation of Generic instances, which may result in some performance problems but is the easiest way to get off the ground.

pestaa 13y ago

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. Looking forward to having 5+ years of experience in this brilliant language.

ocharles 13y ago
Rest assured it doesn't take 5 years to get there :)
k_bx 13y ago
Yeah, but type foo :: M a p f b c => (a -> p) -> b -> c -> a foo f b c = ... would look something like A foo<M<a>,p,f,b,c>(AP f, B b, C c) { ... in Java (I don't know Java, but I hope you gen an idea). I mean, this is a really complex example you've shown. And most of the times, you can (just like everywhere else) write simple type synonyms to express what you want.
ExpiredLink 13y ago
Why do you think a language that "really is ugly" and " is hard to parse" must be a "brilliant language"? Maybe the emperor has no clothes? Maybe Haskell is just what you see: suitable for academic discourse, unusable for real-wold programming.
- asdasf 13y ago
  Lets throw reason and common sense to the wind and pretend the subjective "haskell is ugly" is objectively true. Given that, could you explain to me how you make the seemingly wild and random leap to "haskell is suitable for academic discourse, unsuitable for real-world programming"? Perl is widely considered to be ugly, is it also only suitable for academic discourse? What properties do you believe haskell possesses that makes it unsuitable for "real-world programming"? What do you even deem "real-world programming" to be? It seems rather bizarre to suggest haskell is unsuitable for real-world programming in a discussion about examples of using haskell for real-world programming.

egonschiele 13y ago

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.

gtani 13y ago

these "how to read _" posts are helpful mini- style guide/naming convention roadmaps http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://blog.ezyang.com/2011/11/how-to-read-haskell/ http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_does_this_function_do.3F http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_...

themodelplumber 13y ago

>Do I still need a graduate degree in category theory to write to a file? No. > Will I need a graduate degree in category theory to parse the next paragraph in this article? Oh. Um wait, define web developer for me again?

gnuvince 13y ago

In the second example, shouldn't it be `mapM_` instead of `forM_` with this ordering of the arguments?

ionelm 13y ago

Set aside the small examples and theory about what's best, no argument beats a real world example. Are there any large opensource haskell web apps that one could read to see how it really done ?

gtani 13y ago
http://www.joachim-breitner.de/blog/archives/606-Real-World-Haskell-Applications.html http://www.joachim-breitner.de/blog/archives/606-Real-World-... https://www.fpcomplete.com/page/case-studies https://www.fpcomplete.com/page/case-studies
- hbbio 13y ago
  So, the short answer is no. And there are many reasons to that. One of them: Haskell developers tend to love the technology and forget about the product.
  - asdasf 13y ago
    How do you come to that conclusion? I am all about the product, which is why it isn't open source.
    - dllthomas 13y ago
      Well, I think there's clearly such a contingent, and I think it's more visible because of Haskell's academic heritage; it may also be larger, but I am much less confident in that - there are people who love pushing the tech in most languages.
      - asdasf 13y ago
        I think it isn't more visible, it is just more talked about. There is a perception, not a reality.
        dllthomas 13y ago

coldcode 13y ago

If you like hammers you can make them do anything. Or is the analogy nails? I forget. The real question is why use Haskell instead of something else that most people generally consider targeted at the web?

asdasf 13y ago
>The real question is why use Haskell instead of something else that most people generally consider targeted at the web? That applies to any language. Why use perl? Why use PHP? Why use ruby? Why use java? Web development isn't magical, it is just ordinary, general purpose programming. So people use ordinary, general purpose programming languages. Like perl, PHP, ruby, java, and haskell.
dragonwriter 13y ago
> The real question is why use Haskell instead of something else that most people generally consider targeted at the web? An equally "real" question is why people think "the web" is special in such a way that it requires a different programming language for back-end applications than other server applications use.
- dllthomas 13y ago
  That seems like a far more real question.
- SiVal 13y ago
  I would say that the difference is that the Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable. There are many programs that run on servers, grinding away on deep questions for extended periods with no more than the bare minimum of communication with the rest of the universe---maybe just a terse "42" at the end of a long run. But the Web is about talking to users thousands of times per second, sending it all in a hurricane of streams to a database, fetching data for each of them from various databases, streaming it out to a third-party credit card processor, sending the results back to the users.... Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams.

film42 13y ago

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?

asdasf 13y ago
The appeal for me is that it is an expressive, high level language with a useful type system and high performance. It is a pleasure to program in.
egonschiele 13y ago
I love programming in Haskell! Seriously, the reason it's on HN so much is that Haskellers love the language. Here are some reasons: * Types, types, types. You're probably sick of hearing about Haskell's type system, but it's amazing. Gives you almost all the flexibility of a language like Ruby, PLUS you can encode a lot of your assumptions in types...so if there's a bug you'll catch it at compile time. I like how I can just write a LOT of Haskell code without testing it, and then just compile my project and find all the issues I need to fix. It makes prototyping really easy and fast. * Awesome abstractions. Functors, monads, first class functions: you know how java is verbose and you end up writing the same boilerplate over and over? Haskell is the opposite. * Awesome syntax. I really love Haskell's syntax: super clean, and you can modify it however you like. I like writing very readable code (you read code way more often than you write it) and Haskell lets me write very readable code. * Neat libraries! All that stuff other languages are trying to work around? Like concurrency, or sandboxing? Part of the standard library already. I had written this post a while back (http://adit.io/posts/2012-03-10-building_a_concurrent_web_scraper_with_haskell.html http://adit.io/posts/2012-03-10-building_a_concurrent_web_sc...) that shows exactly how easy it is. Seriously, if you're curious about languages at all, give Haskell a try.
- tel 13y ago
  I think something that's hard to appreciate before you learn Haskell is that while a lot of the abstractions used in the language are more complex and abstract than you're used to using, it's because the language/types/compiler help to lift an enormous mental burden you usually carry while reasoning about code in most languages. Purity is great not because you make fewer errors but because when writing pure code you can focus on what needs to happen instead of worrying about state/effects/control flow. While having to sprinkle `liftIO`s around your imperative code sounds dreadful, it's quickly appreciated as a statically checked marker for "code that you need to think harder about". So what you end up with is a fantastic playground to use mental tools unavailable in other languages due to the complexity overhead. You also have a suite of abstractions that "almost never break" due to their invariants being encoded into the type system and thus checked every single time you reload the file. People often compare this effect to having a large suite of automatically generated test specs run on every compile. It's like that, yeah, but humans can write tests this bulletproof and no suite runs this quickly. I get jitters writing Ruby sometimes now because I know I'm fallible and I have to store so much more in my mind in order to reason about it.

Chris_Newton 13y ago

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. Here’s an early example from the article: 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 Here’s something with similar behaviour written in Python, an imperative language with a reputation for being easy to read: total = 0 while True: total += input() print "Total:", total 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. 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. 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.

sseveran 13y ago
In real life (not contrived examples) haskell greatly simplifies dealing with state. Isolating IO makes it much simpler to reason about where exceptions can come from.
- Chris_Newton 13y ago
  In real life (not contrived examples) haskell greatly simplifies dealing with state. That is the assumption I’m questioning. For example, let’s consider quicksort. Hopefully we can agree that this is a substantial and practically useful algorithm, and one that fundamentally relies on mutable state for its performance and scalability. I recently posted a link here to a discussion on haskell.org[1] about implementing a real quicksort. This was contrasted with the usual elegant but not-really-quicksort version that has propped up a million functional programming advocacy posts, and with the original C version[2]. Neither Haskell version seems particularly simple to me when compared to the C, and I see little extra safety in return for all the Haskell syntactic overhead that couldn’t have been had just as well with a couple of "const" annotations in numerous imperative languages. Obviously not every case is as self-contained as this algorithm and in other contexts Haskell’s approach would fare better. But a lot of real world code is stateful, and a lot of it uses this kind of local state, and so I contend that making everything explicit, Haskell-style, does not greatly simplify dealing with state in general. [1] http://www.haskell.org/haskellwiki/Introduction/Direct_Translation http://www.haskell.org/haskellwiki/Introduction/Direct_Trans... [2] http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_C http://www.haskell.org/haskellwiki/Introduction#Quicksort_in...

GeneralMayhem 13y ago

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.

gnuvince 13y ago
Can you explain what you feel is hard about IO in Haskell that isn't hard in other languages? Sure, you need to get used to the different way of working with IO (remembering to use <- instead let, calling return to wrap the result back into the IO type, etc.), but after some time, it's pretty much automatic.

ahawkins 13y ago

I really need to learn Haskell. Thanks for this.

Rickasaurus 13y ago

In this blog post about how easy and non-academic Haskell is I'm going to implement the lambda calculus as an example

agentultra 13y ago

I don't think you're going to convince existing web developers to adopt Haskell. 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. "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. 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.

asdasf 13y ago
I've had the opposite experience. Everyone I know who does web development is frustrated by the poor quality of work they produce, and how hard it is to maintain the projects they've done. Re-writing a project from scratch every ~5 years is essentially normal development practice. I learned haskell just for web development. I am not smarter as a result, I just have a better tool now that helps me produce better results. My wife then decided to learn haskell for web development too. Neither of us have a background in computer science, or even a degree at all. We learned haskell for purely practical reasons, and we keep using it for those purely practical reasons.
- agentultra 13y ago
  ymmv; I hate web development but maintainability is the least of my concerns. I have frameworks for that.
  - asdasf 13y ago
    What framework, and what is it doing to help with maintenance? My experience has been that typical RoRish frameworks are so heavily concerned with trying to make the initial writing of the app easier that they actually hinder long term maintenance.

malandrew 13y ago

One of the most challenging things about Haskell tutorials is the difficulty in determining the etymology of very terse function names. For example, what does the M in forM_ stand for? Monad? Something else? What about liftM? Why is it called lifting? Is the M here the same as the M in forM_? 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. 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.

dons 13y ago
Yes, the M is for monad. Eg map vs mapM
hiker 13y ago
Let me hoogle those for you (sic) http://www.haskell.org/hoogle/?hoogle=liftM http://www.haskell.org/hoogle/?hoogle=liftM =-)
dllthomas 13y ago
It's called lifting because it's moving something between levels. In the case of liftM, it's moving a function that operates on type a and returns type b, to one that operates on a wrapped type a and returns a wrapped type b. Since a monad should be a functor, and the types are the same, I'm pretty confident that this is the same thing as fmap - though in principle there could be a monad with no functor instance defined where you would have to use liftM (for now: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal http://www.haskell.org/haskellwiki/Functor-Applicative-Monad...).
ufo 13y ago
The positive news is that while it might take a while to learn the conventions, usually the conventions are enforced all around. In your case, the conventions are documented in the docs for Control.Monad, the library those functions are from: The functions in this library use the following naming conventions: > A postfix 'M' always stands for a function in the Kleisli category: The monad type constructor m is added to function results (modulo currying) and nowhere else. So, for example, filter :: (a -> Bool) -> [a] -> [a] filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] > A postfix '_' changes the result type from (m a) to (m ()). Thus, for example: sequence :: Monad m => [m a] -> m [a] sequence_ :: Monad m => [m a] -> m () > A prefix 'm' generalizes an existing function to a monadic form. Thus, for example: sum :: Num a => [a] -> a msum :: MonadPlus m => [m a] -> m a http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html http://www.haskell.org/ghc/docs/latest/html/libraries/base/C... Personally, the things that I found hard were idioms (like learning that $ is just avoiding parenthesis, "go" is for loops, etc) and how theres a lot of libraries that make the code shorter at the expense of forcing you to be aware of them (for example, applicatives <$> <*> look alien until you learn what they are and monad transformers add a lot of "magic" to the code as well as force you to use annoying lifts all over the place)

venutip 13y ago

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. Also, the example of the compiled JavaScript from Fay is horribly obfuscated: return Fay$$_(Fay$$_( Fay$$cons)(i))(Fay$$_( Prelude$enumFrom)( Fay$$_(Fay$$_( Fay$$add)(i))(1) )); 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. 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." 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. Am I being unfair? >> As an example of we’ll use JMacro to implement a simple translator for the untyped typed lambda calculus. Nope.

asdasf 13y ago
>Am I being unfair? I'm not sure I would call it unfair, but I wouldn't call it reasonable or logical. You don't have to use haskell for your front end development if you don't have someone to do it. You don't have to use haskell for your back end development if you don't have someone to do it. He just showed some of what is available if you do want to do it. Our front end developer knows haskell, and works on the backend as well writing haskell. She still doesn't use clay or fay though, she uses SASS and just plain old javascript. Also, Fay output isn't obfuscated, it is just accurately translating haskell to javascript, which means lazy evaluation.
gnuvince 13y ago
> 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. Do you often debug the assembler output of your compiler? Same thing; fix the Fay code, not the Javascript that the compiler generates.