5 ms·

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haske

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world. I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have been adopted to good effect in more mainstream languages but commercial Haskell or OCaml apps are still conspicuously thin on the ground. I think at this point it's up to the FP advocates to back up their claims with results. I'm sure there are a lot of programmers that would happy to roll up their sleeves and learn something new if it truly would make them 3x more productive.

outworlder 12y ago
> and yet there still don't seem to be many non-trivial apps written in any of these languages Perhaps you are not looking hard enough? Sure, if your problem space is CRUD web apps, then you won't find many implementations. Try looking into more difficult problem spaces, such as high-frequency trading, and you'll suddenly find more FP examples. Also, there's Erlang, which was developed by Ericsson to solve a very specific, real-world problem. Look it up.
- bane 12y ago
  To be honest, I'd be happy with a 1 level interactive demo (with sound) of a Mario Brothers style platform game.
  - kasey_junk 12y ago
    That is sort of the worst case scenario for a FP program (though I'm sure you could write it in FP). It is almost entirely side-effects. I agree with the sentiment that for a paradigm that has been advocated for 60 years it is really odd how little non-academia code is written in it. In my experience you find functional code shines (and is therefore common) in places where prove-ability is of the utmost importance or where writing custom DSLs provide a lot of value. Things like nuclear systems, extremely high security applications (think custom OS level requirements) or financial modelling software. That said in most of the places I've found the FP program is a high value prototype or proof of concept, not the actual system. I don't know if that is just a resource allocation thing or not.
    - seanmcdirmid 12y ago
      There are plenty of side effect free ways of dealing with change...you can make the effects you know...explicit. Anyways, for a game like SMB, FRP should work relatively well. Just be careful with collections.
      - kasey_junk 12y ago
        But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects. Of course there are ways of abstracting those side effects and acting like they are the same as pure functions. Or conversely instead of hiding them, you could point them out and make them "exceptional", which is what I assume you mean by making them explicit. These machinations (of which FRP is a clear example) to deal with side effects have a price, and in a game like SMB it is entirely possible that the vast majority of the work would be this overhead. Again, of course you can do it, but it is a problem domain not particularly suited to FP in and of itself. I've written short running, fast starting, memory constrained applications in Java, but it was a fight to do it. If the fight is worth the other advantages, it can be worth it.
        dllthomas 12y ago
        "But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects." No, those are precisely effects. They can only be side effects once you've defined how you're distinguishing side effects from effects generally. A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're clearly effects not side effects, though this equally clearly isn't the usage in question. Another way - common in Haskell - is to label effects that do not appear in a function's type signature "side effects". By this definition, it clearly depends on the implementation and there are "side effect free ways of changing pixels on the screen". I don't think there is another useful definition to be had.
        seanmcdirmid 12y ago
  - interknot 12y ago
    There's Nikki and the Robots: http://joyridelabs.de/game/ http://joyridelabs.de/game/ There's also Super Monao Bros (which used to be called Super Nario): https://github.com/mokehehe/monao/tree/master https://github.com/mokehehe/monao/tree/master
  - Tyr42 12y ago
    Niki and the Robots[1] [1]: http://joyridelabs.de/game/trailer/ http://joyridelabs.de/game/trailer/
- asdf1234 12y ago
  High frequency trading is dominated by C++, Java and C#. There are a few places using F# and Ocaml but they're relatively small players. I know of only two places that seriously considered Haskell and they both decided against it in the end. I doubt any of these languages are significantly more popular in "more difficult problem spaces."
bane 12y ago
They exist, but it's super spotty. HN is written in an FP language for example. One of the airline reservation systems is written in some kind of FP. Reddit was written in a Lisp originally. But like many major FP projects, ended up being rewritten in a more common language. I used to work at a place that had hundreds of thousands of lines of CL code that was all rewritten in Perl and was on its way to getting rewritten into Java by the time I left there. I agree with the major thrust of your argument, FP seems to find itself mired in weird niches. I'm not sure if it's because FP advocates seem to not want to write mainstream end-user software or it just hasn't leaked out into the mainstream, but it's pretty tough to find lots of major FP success stories outside of a constant stream of anecdotal advocacy stories (none of which ever seem to be attached to some piece of software I can download and actually touch for day-to-day usage). I suspect the problem is that lots of the kind of software end users want is difficult/hard to write in an FP style, but an order of magnitude easier in an imperative language (even if it's less "right")...FP is just the wrong paradigm for general purpose programming, even if it works better than imperative languages in certain niches. I think this is an illuminating summary of all this [1]. However, here's an engine written in Haskell [2]. It seems that FP ideas will continue to end up in non-FP languages long before FP languages will become a major success. That might be a success by itself? To save us some time, here are some pretty woeful lists where this exact question is asked and answered. https://programmers.stackexchange.com/questions/22073/is-functional-programming-actually-used-to-create-applications https://programmers.stackexchange.com/questions/22073/is-fun... http://lambda-the-ultimate.org/node/2491 http://lambda-the-ultimate.org/node/2491 1 - http://prog21.dadgum.com/54.html http://prog21.dadgum.com/54.html 2 - http://www.hgamer3d.org/index.html http://www.hgamer3d.org/index.html
- zurn 12y ago
  > One of the airline reservation systems is written in some kind of FP. You are probably thinking of ITA and their Orbitz service, using Franz Common Lisp. That is not really a FP language, but a good feather in the hat for Lisp nonetheless.
  - bane 12y ago
    Yeah that's it. Well, strike that off the list then I guess.
mark_l_watson 12y ago
Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com. They wrote the back end in Haskell and the client side with Haskell compiled to JavaScript. Really impressive.
- doktrin 12y ago
  > Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com. Technical merits aside, I think this actually re-enforces the parents point. I mean, you're basically saying that one of the best examples of production-ready Haskell is a Haskell IDE, developed by a company a good >80% of HN readers may never even have heard of.
chiurox 12y ago
How about WhatsApp's backend being extremely scalable because it was written in Erlang from the start? Or even Twitter that rewrote much of their backend in Scala to deal with scaling issues (I'm not saying that Rails isn't scalable, I don't want to start a war over this issue; the important thing is they saw a problem and solved it) while contributing many many open sourced libraries for our use? Foursquare uses Scala extensively. LinkedIn is using Scala extensively for its new projects. The commercial and successful use cases for Scala are widespread at this point. For Haskell and OCaml it's going to take a while.
- pron 12y ago
  Well, when people say FP they mean different things. The Erlang/Clojure kind bears little resemblance to the Haskell/scalaz sort discussed in the article. Neither does most of the Scala code written at Twitter (which is mostly OO with a sprinkling of functional).
  - tel 12y ago
    That's hardly true. Erlang's event loops are based on a very similar kind of state encapsulation as Haskell's state monad. Really Erlang is littered with explicit monadic patterns but lacks a good system for abstracting over those patterns so you just call them "OTP" instead of a monad.
- virtualwhys 12y ago
  It says a lot about the scale of adoption the big language players have that despite the aforementioned inroads into the enterprise that Scala has made, it is still very much a niche language; Haskell at this point in time, even more so. Am curious to see how Scala 3/Dotty backed Scala works out. Enabling better tooling and faster build times via a generally less kitchen sink-y/more regular language should bring Scala adoption to new levels. Dotty is under active development, even saw a Github issue talking about the migration tool[1]. It's going to happen, just a matter of when. [1] https://github.com/lampepfl/dotty/issues/129 https://github.com/lampepfl/dotty/issues/129
deleted 12y ago
[deleted]
JackMorgan 12y ago
What have you contributed? Or are you just waiting for _someone else_ to put in the effort to prove it for you first? Multiply that by every developer in every company, and you start to see why it's not that common. I am currently trying to write something in F#, which is still OO, only the rest of my team won't let me because there is "no proof it's better". Well, no. And there won't be if everyone says that. And where is the proof C# was better than VB.NET? Oh, right, the proof is VB.NET doesn't look like Java! Curly braces, the only evidence we need! As long as the majority can hold back the minority that WILL learn something new just to see if it's better, everyone stays with the status quo. "Just don't make me learn anything new" <- the developer motto.
fancyketchup 12y ago
As others have mentioned, there is no universal definition of FP. But if you're willing to stretch your personal definition of FP to include LabVIEW, then there are a considerable number of real FP applications used every day in research and industry for real, productive things. It's just that LabVIEW tends to be considered outside the domain of "software engineers," so most people here probably haven't hear of it. Nevertheless, it is a real programming language, and you can do anything with it that you could do with any other language (albeit, much more tediously). I don't think I've ever heard of LabVIEW described as a functional language (and it's clearly not a "purely" functional language), but it programs like one. Programs are written by connecting VIs (functions in LabVIEW-speak) with wires in a data-flow diagram. VIs don't contain any state (usually, unless you explicitly use local or global variables--which all the documentation warns you never to do upon pain of something really awful). VIs mostly don't have side-effects (unless you're explicitly doing something with the filesystem, or data acquisition, or motion control, or... ). One of the difficulties of using FP for "real" things is that you give up something you got for free with imperative languages, namely control of timing. LabVIEW works around this with something called a sequence diagram, which forces VIs to be called in a deterministic order (because, being FP, you can't otherwise divine in what order VIs will be called). LabVIEW also encourages the use of a trick to enforce sequencing without using sequence structures (and this trick is absolutely mandatory if you don't want a write-only program): The abstract name of an instrument resource is passed to a VI, and then returned unchanged. Since the returned values of a function aren't determined until it is run, you can chain several functions together in this way so that they run in sequence (which, IMHO, is bad practice because this abstract resource thing being passed about is something which is needed by each function, and can be modified by each function, but SHOULDN'T be modified by any function). Annoyances aside, I've written a number of medium-sized programs in LabVIEW that implement entire data acquisition systems, including control of external instruments, positioning of mechanical parts, high voltage power supplies (no side effects, heh, sure thing), pulsed lasers (same), and a synchronous detector of my own design. I would also note that the data acquisition systems do not use any local or global variables (as LabVIEW uses those terms), so it could be argued that they are have a very high "functional purity," though that was not my intention when I wrote them. My personal opinion is that the productivity claims of the FP camp are largely inflated. Maybe FP is better suited to problem domains that exist entirely inside the computer.

outworlder 12y ago

> and yet there still don't seem to be many non-trivial apps written in any of these languages Perhaps you are not looking hard enough? Sure, if your problem space is CRUD web apps, then you won't find many implementations. Try looking into more difficult problem spaces, such as high-frequency trading, and you'll suddenly find more FP examples. Also, there's Erlang, which was developed by Ericsson to solve a very specific, real-world problem. Look it up.

bane 12y ago
To be honest, I'd be happy with a 1 level interactive demo (with sound) of a Mario Brothers style platform game.
- kasey_junk 12y ago
  That is sort of the worst case scenario for a FP program (though I'm sure you could write it in FP). It is almost entirely side-effects. I agree with the sentiment that for a paradigm that has been advocated for 60 years it is really odd how little non-academia code is written in it. In my experience you find functional code shines (and is therefore common) in places where prove-ability is of the utmost importance or where writing custom DSLs provide a lot of value. Things like nuclear systems, extremely high security applications (think custom OS level requirements) or financial modelling software. That said in most of the places I've found the FP program is a high value prototype or proof of concept, not the actual system. I don't know if that is just a resource allocation thing or not.
  - seanmcdirmid 12y ago
    There are plenty of side effect free ways of dealing with change...you can make the effects you know...explicit. Anyways, for a game like SMB, FRP should work relatively well. Just be careful with collections.
    - kasey_junk 12y ago
      But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects. Of course there are ways of abstracting those side effects and acting like they are the same as pure functions. Or conversely instead of hiding them, you could point them out and make them "exceptional", which is what I assume you mean by making them explicit. These machinations (of which FRP is a clear example) to deal with side effects have a price, and in a game like SMB it is entirely possible that the vast majority of the work would be this overhead. Again, of course you can do it, but it is a problem domain not particularly suited to FP in and of itself. I've written short running, fast starting, memory constrained applications in Java, but it was a fight to do it. If the fight is worth the other advantages, it can be worth it.
      - dllthomas 12y ago
        "But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects." No, those are precisely effects. They can only be side effects once you've defined how you're distinguishing side effects from effects generally. A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're clearly effects not side effects, though this equally clearly isn't the usage in question. Another way - common in Haskell - is to label effects that do not appear in a function's type signature "side effects". By this definition, it clearly depends on the implementation and there are "side effect free ways of changing pixels on the screen". I don't think there is another useful definition to be had.
        seanmcdirmid 12y ago
- interknot 12y ago
  There's Nikki and the Robots: http://joyridelabs.de/game/ http://joyridelabs.de/game/ There's also Super Monao Bros (which used to be called Super Nario): https://github.com/mokehehe/monao/tree/master https://github.com/mokehehe/monao/tree/master
- Tyr42 12y ago
  Niki and the Robots[1] [1]: http://joyridelabs.de/game/trailer/ http://joyridelabs.de/game/trailer/
asdf1234 12y ago
High frequency trading is dominated by C++, Java and C#. There are a few places using F# and Ocaml but they're relatively small players. I know of only two places that seriously considered Haskell and they both decided against it in the end. I doubt any of these languages are significantly more popular in "more difficult problem spaces."

bane 12y ago

They exist, but it's super spotty. HN is written in an FP language for example. One of the airline reservation systems is written in some kind of FP. Reddit was written in a Lisp originally. But like many major FP projects, ended up being rewritten in a more common language. I used to work at a place that had hundreds of thousands of lines of CL code that was all rewritten in Perl and was on its way to getting rewritten into Java by the time I left there. I agree with the major thrust of your argument, FP seems to find itself mired in weird niches. I'm not sure if it's because FP advocates seem to not want to write mainstream end-user software or it just hasn't leaked out into the mainstream, but it's pretty tough to find lots of major FP success stories outside of a constant stream of anecdotal advocacy stories (none of which ever seem to be attached to some piece of software I can download and actually touch for day-to-day usage). I suspect the problem is that lots of the kind of software end users want is difficult/hard to write in an FP style, but an order of magnitude easier in an imperative language (even if it's less "right")...FP is just the wrong paradigm for general purpose programming, even if it works better than imperative languages in certain niches. I think this is an illuminating summary of all this [1]. However, here's an engine written in Haskell [2]. It seems that FP ideas will continue to end up in non-FP languages long before FP languages will become a major success. That might be a success by itself? To save us some time, here are some pretty woeful lists where this exact question is asked and answered. https://programmers.stackexchange.com/questions/22073/is-functional-programming-actually-used-to-create-applications https://programmers.stackexchange.com/questions/22073/is-fun... http://lambda-the-ultimate.org/node/2491 http://lambda-the-ultimate.org/node/2491 1 - http://prog21.dadgum.com/54.html http://prog21.dadgum.com/54.html 2 - http://www.hgamer3d.org/index.html http://www.hgamer3d.org/index.html

zurn 12y ago
> One of the airline reservation systems is written in some kind of FP. You are probably thinking of ITA and their Orbitz service, using Franz Common Lisp. That is not really a FP language, but a good feather in the hat for Lisp nonetheless.
- bane 12y ago
  Yeah that's it. Well, strike that off the list then I guess.

mark_l_watson 12y ago

Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com. They wrote the back end in Haskell and the client side with Haskell compiled to JavaScript. Really impressive.

doktrin 12y ago
> Here is a good example of a complex Haskell app: the Haskell web based IDE at fpcomplete.com. Technical merits aside, I think this actually re-enforces the parents point. I mean, you're basically saying that one of the best examples of production-ready Haskell is a Haskell IDE, developed by a company a good >80% of HN readers may never even have heard of.

chiurox 12y ago

How about WhatsApp's backend being extremely scalable because it was written in Erlang from the start? Or even Twitter that rewrote much of their backend in Scala to deal with scaling issues (I'm not saying that Rails isn't scalable, I don't want to start a war over this issue; the important thing is they saw a problem and solved it) while contributing many many open sourced libraries for our use? Foursquare uses Scala extensively. LinkedIn is using Scala extensively for its new projects. The commercial and successful use cases for Scala are widespread at this point. For Haskell and OCaml it's going to take a while.

pron 12y ago
Well, when people say FP they mean different things. The Erlang/Clojure kind bears little resemblance to the Haskell/scalaz sort discussed in the article. Neither does most of the Scala code written at Twitter (which is mostly OO with a sprinkling of functional).
- tel 12y ago
  That's hardly true. Erlang's event loops are based on a very similar kind of state encapsulation as Haskell's state monad. Really Erlang is littered with explicit monadic patterns but lacks a good system for abstracting over those patterns so you just call them "OTP" instead of a monad.
virtualwhys 12y ago
It says a lot about the scale of adoption the big language players have that despite the aforementioned inroads into the enterprise that Scala has made, it is still very much a niche language; Haskell at this point in time, even more so. Am curious to see how Scala 3/Dotty backed Scala works out. Enabling better tooling and faster build times via a generally less kitchen sink-y/more regular language should bring Scala adoption to new levels. Dotty is under active development, even saw a Github issue talking about the migration tool[1]. It's going to happen, just a matter of when. [1] https://github.com/lampepfl/dotty/issues/129 https://github.com/lampepfl/dotty/issues/129

deleted 12y ago

[deleted]

JackMorgan 12y ago

What have you contributed? Or are you just waiting for _someone else_ to put in the effort to prove it for you first? Multiply that by every developer in every company, and you start to see why it's not that common. I am currently trying to write something in F#, which is still OO, only the rest of my team won't let me because there is "no proof it's better". Well, no. And there won't be if everyone says that. And where is the proof C# was better than VB.NET? Oh, right, the proof is VB.NET doesn't look like Java! Curly braces, the only evidence we need! As long as the majority can hold back the minority that WILL learn something new just to see if it's better, everyone stays with the status quo. "Just don't make me learn anything new" <- the developer motto.

fancyketchup 12y ago

As others have mentioned, there is no universal definition of FP. But if you're willing to stretch your personal definition of FP to include LabVIEW, then there are a considerable number of real FP applications used every day in research and industry for real, productive things. It's just that LabVIEW tends to be considered outside the domain of "software engineers," so most people here probably haven't hear of it. Nevertheless, it is a real programming language, and you can do anything with it that you could do with any other language (albeit, much more tediously). I don't think I've ever heard of LabVIEW described as a functional language (and it's clearly not a "purely" functional language), but it programs like one. Programs are written by connecting VIs (functions in LabVIEW-speak) with wires in a data-flow diagram. VIs don't contain any state (usually, unless you explicitly use local or global variables--which all the documentation warns you never to do upon pain of something really awful). VIs mostly don't have side-effects (unless you're explicitly doing something with the filesystem, or data acquisition, or motion control, or... ). One of the difficulties of using FP for "real" things is that you give up something you got for free with imperative languages, namely control of timing. LabVIEW works around this with something called a sequence diagram, which forces VIs to be called in a deterministic order (because, being FP, you can't otherwise divine in what order VIs will be called). LabVIEW also encourages the use of a trick to enforce sequencing without using sequence structures (and this trick is absolutely mandatory if you don't want a write-only program): The abstract name of an instrument resource is passed to a VI, and then returned unchanged. Since the returned values of a function aren't determined until it is run, you can chain several functions together in this way so that they run in sequence (which, IMHO, is bad practice because this abstract resource thing being passed about is something which is needed by each function, and can be modified by each function, but SHOULDN'T be modified by any function). Annoyances aside, I've written a number of medium-sized programs in LabVIEW that implement entire data acquisition systems, including control of external instruments, positioning of mechanical parts, high voltage power supplies (no side effects, heh, sure thing), pulsed lasers (same), and a synchronous detector of my own design. I would also note that the data acquisition systems do not use any local or global variables (as LabVIEW uses those terms), so it could be argued that they are have a very high "functional purity," though that was not my intention when I wrote them. My personal opinion is that the productivity claims of the FP camp are largely inflated. Maybe FP is better suited to problem domains that exist entirely inside the computer.