6 ms·

As far as I can tell from this, the authors worked really hard to implement in Haskell something that is trivial and well-understood in Python and other languag

by mrj 12y ago

As far as I can tell from this, the authors worked really hard to implement in Haskell something that is trivial and well-understood in Python and other languages. Maybe the article could talk more about their specific needs, but this looks like a crud app made very complicated by the choice of unusual software for the task. Maybe it did something awesome, but this doesn't tell us what that was. (They had to write their own ZeroMQ broker, after all. That was certainly costly.) I don't understand the claim in this article that concurrency in Python is hard. There are many reasonable ways to do it for the web, from multiprocessing using something like uwsgi or the excellent gevent. There are certain things that are hard, but for common patterns like web services, there are many awesome solutions to choose from. And I don't understand why memory footprint is seriously a factor here. Server runtimes may use all the memory available to go fast. As long as it fits, footprint seems a lot less important than other factors. The cost of buying an extra stick of ram is miniscule compared to the cost of having to implement libraries to support a language choice. The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant. Basically, this article is missing a lot of details to support the argument they have made. "The satisfaction we feel after a good day of Haskell is unparalleled, and at the end of the day, that's what it's really all about isn't it." Actually, since they appear to be working on a startup, I would think that a functioning business and time to market would be more important.

mbrock 12y ago
"The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant." Haskell has excellent I/O support. How do you mean that Haskell makes I/O difficult?
- peteretep 12y ago
  He means you have to climb the IO Monad learning curve.
  - mbrock 12y ago
    Learning is fun! And Haskell's IO functionality is pretty easy. They teach it in the very first programming course at Chalmers in Gothenburg. It's covered in any introductory Haskell book.
    - peteretep 12y ago
      Yes it's covered in any Haskell book - what use would a language book be without covering IO? How far back in the book it comes, relative to other languages, is the telling piece. LYAH has it as Chapter 9, after algebraic data types, higher order functions, functors, and recursion... I note that in the one week introduction I did for my MSc at the University of Oxford, they didn't cover it, considering it to be too much to fit in to the week. Having taken the rite of passage that is writing my own monad tutorial, I would agree, the concept is both easy and intuitive. Getting it in to your head, however, takes considerably more work than in any other language I've used.
      - deleted 12y ago
        [deleted]
        peteretep 12y ago
        I know there's some debate over it, but I think it's important to teach the general concept of a Monad first, before attempting to teach IO. Ask yourself: why does everyone write a Monad tutorial after they understand Monads? It's because they seem obvious in _retrospect_. The only tutorial I've seen that's anything like approaching a "works for everyone" tutorial is "You could have invented Monads". As to your specific explanation, I think it falls down with IO ().
kryptiskt 12y ago
> the authors worked really hard to implement in Haskell something that is trivial and well-understood in Python and other languages. So where do you get the idea that it was hard work in Haskell? "It was a breeze to rapidly prototype and test individual components before composing them into a whole." "Very surprisingly we got done really quickly." > The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. Haskell separates IO, it doesn't make it harder.
codygman 12y ago
> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant. Disclaimer: I haven't read this yet, but your comment above caught my eye and what I'm about to comment applies regardless. Maybe it makes IO slightly more difficult to begin with, but you can be sure that your all cases are handled after that. Plus once you know about fmap and >>= you can apply pure functions to monadic functions (functions of type IO are monadic because they implement the Monad typeclass (think of it as an interface for now)).
jeremyjh 12y ago
> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice Can you tell me what a program which does no I/O actually does? I can tell you what it does in Haskell: nothing. Without IO, there would be no reason for a computation to ever run in Haskell (or in any other language, but Haskell will actually NOT run it). Every Haskell program does I/O. I know when I first heard about functional programming and Haskell in particular, that ideas like purity, no side-effects and immutability seemed absurd. "But, but - the programs I write always do I/O and manage state!?" So do Haskell programs, they simply do it differently. If a program had no side effects it would have no purpose. Please do not assume that the tool used by an entire community is not well suited to building programs that have a purpose.
- seanmcdirmid 12y ago
  I remember a quote by SPJ but am unable to find a reference to it right now. It goes something like: "a program without I/O is merely heating space." Pure Haskell programs have no side effects, where "side effect" is defined as an effect that occurs implicitly outside of the function's signature. They can definitely have non-side effects; they just have to be explicit about it (the same with IO). For some reason, "side effect" have come to mean effects in general... Parent's observation probably relates to the fact that doing IO in Haskell is "harder" than say in Python. There is some truth to that.
  - phamilton 12y ago
    I think you are missing the parents point. Since everything is lazy in Haskell, a program without IO will literally do nothing. It will not evaluate a single line of code. To expound, Haskell pure functions do not run code. They produce code to be run at a future date. The infamous IO monad is essentially a wrapper around this code which contains information on when the runtime is supposed to actually execute the code. The execution is always dependent on IO. So, as the parent said, a Haskell program without IO is literally nothing.
    - seanmcdirmid 12y ago
rajoshighosh 12y ago
> implement in Haskell something that is trivial and well-understood in Python and other languages. Converting a custom AST (represented as a JSON query) into another AST that can be used to generate SQL is probably not simple with Python simply because there's no type safety while moving from one syntax tree to the other. In Haskell, the definition of the two syntax grammars (as types) itself solves a part of the problem, and then ensures the the programmer is writing functions that are taking the right input and generating the right output. So much more 'correct' code seems likely. > concurrency in Python is hard. There are many reasonable ways to do it for the web, from multiprocessing using something like uwsgi or the excellent gevent Multicore support? http://stackoverflow.com/questions/15617553/gevent-multicore-usage http://stackoverflow.com/questions/15617553/gevent-multicore... > And I don't understand why memory footprint is seriously a factor here. Server runtimes may use all the memory available to go fast. As long as it fits, footprint seems a lot less important than other factors. Using a server side programming language-runtime that would be able to use multiple cores and have a low memory footprint so that it would handle greater scale at lower hosting costs seems like a sensible move. Ofcourse, like you said, only if it is easy enough to do so. Which is what the author's point was I think.

by mrj 12y ago

mbrock 12y ago

"The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant." Haskell has excellent I/O support. How do you mean that Haskell makes I/O difficult?

peteretep 12y ago
He means you have to climb the IO Monad learning curve.
- mbrock 12y ago
  Learning is fun! And Haskell's IO functionality is pretty easy. They teach it in the very first programming course at Chalmers in Gothenburg. It's covered in any introductory Haskell book.
  - peteretep 12y ago
    Yes it's covered in any Haskell book - what use would a language book be without covering IO? How far back in the book it comes, relative to other languages, is the telling piece. LYAH has it as Chapter 9, after algebraic data types, higher order functions, functors, and recursion... I note that in the one week introduction I did for my MSc at the University of Oxford, they didn't cover it, considering it to be too much to fit in to the week. Having taken the rite of passage that is writing my own monad tutorial, I would agree, the concept is both easy and intuitive. Getting it in to your head, however, takes considerably more work than in any other language I've used.
    - deleted 12y ago
      [deleted]
      - peteretep 12y ago
        I know there's some debate over it, but I think it's important to teach the general concept of a Monad first, before attempting to teach IO. Ask yourself: why does everyone write a Monad tutorial after they understand Monads? It's because they seem obvious in _retrospect_. The only tutorial I've seen that's anything like approaching a "works for everyone" tutorial is "You could have invented Monads". As to your specific explanation, I think it falls down with IO ().

kryptiskt 12y ago

> the authors worked really hard to implement in Haskell something that is trivial and well-understood in Python and other languages. So where do you get the idea that it was hard work in Haskell? "It was a breeze to rapidly prototype and test individual components before composing them into a whole." "Very surprisingly we got done really quickly." > The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. Haskell separates IO, it doesn't make it harder.

codygman 12y ago

> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice given that Haskell makes side effects like IO more difficult than other languages. I'm curious to know how that affected the implementation. I'd like to use more functional languages, but since my job is primarily IO of some sort, watching people struggle with writing to sockets leaves me more than a little hesitant. Disclaimer: I haven't read this yet, but your comment above caught my eye and what I'm about to comment applies regardless. Maybe it makes IO slightly more difficult to begin with, but you can be sure that your all cases are handled after that. Plus once you know about fmap and >>= you can apply pure functions to monadic functions (functions of type IO are monadic because they implement the Monad typeclass (think of it as an interface for now)).

jeremyjh 12y ago

> The choice of a pure functional language like Haskell to do lots of IO seems like a strange choice Can you tell me what a program which does no I/O actually does? I can tell you what it does in Haskell: nothing. Without IO, there would be no reason for a computation to ever run in Haskell (or in any other language, but Haskell will actually NOT run it). Every Haskell program does I/O. I know when I first heard about functional programming and Haskell in particular, that ideas like purity, no side-effects and immutability seemed absurd. "But, but - the programs I write always do I/O and manage state!?" So do Haskell programs, they simply do it differently. If a program had no side effects it would have no purpose. Please do not assume that the tool used by an entire community is not well suited to building programs that have a purpose.

seanmcdirmid 12y ago
I remember a quote by SPJ but am unable to find a reference to it right now. It goes something like: "a program without I/O is merely heating space." Pure Haskell programs have no side effects, where "side effect" is defined as an effect that occurs implicitly outside of the function's signature. They can definitely have non-side effects; they just have to be explicit about it (the same with IO). For some reason, "side effect" have come to mean effects in general... Parent's observation probably relates to the fact that doing IO in Haskell is "harder" than say in Python. There is some truth to that.
- phamilton 12y ago
  I think you are missing the parents point. Since everything is lazy in Haskell, a program without IO will literally do nothing. It will not evaluate a single line of code. To expound, Haskell pure functions do not run code. They produce code to be run at a future date. The infamous IO monad is essentially a wrapper around this code which contains information on when the runtime is supposed to actually execute the code. The execution is always dependent on IO. So, as the parent said, a Haskell program without IO is literally nothing.
  - seanmcdirmid 12y ago

rajoshighosh 12y ago

> implement in Haskell something that is trivial and well-understood in Python and other languages. Converting a custom AST (represented as a JSON query) into another AST that can be used to generate SQL is probably not simple with Python simply because there's no type safety while moving from one syntax tree to the other. In Haskell, the definition of the two syntax grammars (as types) itself solves a part of the problem, and then ensures the the programmer is writing functions that are taking the right input and generating the right output. So much more 'correct' code seems likely. > concurrency in Python is hard. There are many reasonable ways to do it for the web, from multiprocessing using something like uwsgi or the excellent gevent Multicore support? http://stackoverflow.com/questions/15617553/gevent-multicore-usage http://stackoverflow.com/questions/15617553/gevent-multicore... > And I don't understand why memory footprint is seriously a factor here. Server runtimes may use all the memory available to go fast. As long as it fits, footprint seems a lot less important than other factors. Using a server side programming language-runtime that would be able to use multiple cores and have a low memory footprint so that it would handle greater scale at lower hosting costs seems like a sensible move. Ofcourse, like you said, only if it is easy enough to do so. Which is what the author's point was I think.