11 ms·

Why No One Uses Functional Languages (1998) [pdf]

85 points by tel 12y ago

jaytaylor 12y ago
It's interesting to see how 15+ years later, general attitudes among the masses haven't changed much in this regard (according to the most popularly used languages [0][1]). Feels bad, man. [0] http://beust.com/weblog/2014/05/03/language-popularity-on-github/ http://beust.com/weblog/2014/05/03/language-popularity-on-gi... [1] https://www.google.com/search?q=language+popularity https://www.google.com/search?q=language+popularity
- deleted 12y ago
  [deleted]
- clusterfoo 12y ago
  Would you say that the functional paradigm has started to gain more traction lately though? -- I don't know because I haven't been programming long enough, so maybe it just seems that way to me simply because now that I'm aware of its existence I'm seeing it everywhere. I read a quote once about The Velvet Underground that stuck with me. It said that, while not many people bought their albums, everyone who did started a band. Sometimes it seems like Haskell is The Velvet Underground of programming languages. While not many people are using it, everyone who is has started their own language/functional library -- Influencing other languages is, in a way, people using FP languages, just indirectly. I've not written a single serious Haskell program -- I don't think I would even know how to, tbh --, but I sure feel like just playing with it and learning about its theoretical motivations has made me a much better programmer in other languages.
  - mhogomchungu 12y ago
    >Would you say that the functional paradigm has started to gain more traction lately though? That is certainly true but I think more people will not shift to functional programming languages to do functional programming style programming but will stick with their favorite imperative language and do functional programming there as more and more imperative languages add features and facilities that allow functional programming style programming. Case in point, i have this Qt/C++[1] library that evaluates lambdas in a lazy fashion. You can have,for example, a function that returns what is called "a future",ie something that can be evaluated at a later time to produce a value "held" in the future or the future can be cancelled if the function caller decides they no longer need the result. Introductions of lambdas in C++11 allows for this kind of programming to happen in C++ and i suspect more and more C++ programmers will start coding to this style as more and more APIs will start getting released that will take lambdas as arguments or return them as results. It is an interesting new way of doing C++ and these ideas are mostly borrowed from functional programming world. [1] https://github.com/mhogomchungu/tasks https://github.com/mhogomchungu/tasks
  - dllthomas 12y ago
    "It said that, while not many people bought their albums, everyone who did started a band." And possibly a country. http://en.wikipedia.org/wiki/V%C3%A1clav_Havel http://en.wikipedia.org/wiki/V%C3%A1clav_Havel
  - pjmlp 12y ago
    > Would you say that the functional paradigm has started to gain more traction lately though? Surely. All major languages are going hybrid, mixing imperative (mostly OOP) with functional programming concepts. Until we get a complete new computer architecture, like quantum computers, the mainstream will be hybrid OOP + FP.
  - pedrow 12y ago
    > Would you say that the functional paradigm has started to gain more traction lately though? I would and I believe it started to happen when people started talking about Scala. I also think something similar happened with OOP in (maybe?) the early 1990s - i.e. we'd had Simula, Smalltalk and so on for years but it became mainstream. I'm thinking of things like Visual Basic 1.0 (1991), C++ v2.0 (1989)
- baddox 12y ago
  But many concepts from functional languages have become commonplace in popular multi-paradigm languages. That's probably the best we can realistically hope for in that time frame.
- mathattack 12y ago
  My impression is that it is making a difference amongst top programmers. When I learned Scheme way back when in college, there was no pretense of it being practical. My AI professor said, "AI is reduced to LISP hacking" and that was to denigrate AI, not raise LISP. Nowadays people see the value of recursive thinking, and hence the value of functional programming. The convergence of many technology trends seems to suggest that the idea of "The program can be the data, and the data can be the program" is no longer so far fetched.
tieTYT 12y ago
> Advocates of functional languages claim they produce an order of magnitude improvement in productivity. Experiments don't always verify that figure -- sometimes they show an improvement of only a factor of four. It's weird, the first time I read this I was excited to read the source of this quote. When I finished reading I scrolled up to the top and was disappointed to see a citation missing. Does anyone know what experiment he's referring to?
- Avshalom 12y ago
  I think probably http://haskell.cs.yale.edu/?post_type=publication&p=366 http://haskell.cs.yale.edu/?post_type=publication&p=366
vajrabum 12y ago
That's really old so I actually looked at it (again). Here are the criteria that Wadler mentions that ho<eld back adoption. Things that Haskell used to be weak on but now has good support for: FFI - yes Libraries - Yes Portability - Yes Ease of installation - Yes Packagability - Yes Tools - yes Training - available Performance - yes (non)Reasons why it doesn't get adopted. Still apply. Popularity - No still not popular They don’t get it - Yes they still don't get it Killer App - none that I can see (darcs?)
- dllthomas 12y ago
  "Killer App - none that I can see (darcs?)" Maybe pandoc.
  - freyrs3 12y ago
    Historically I think Haskell will be very important as the substrate on which a lot of the next generation of dependently-typed languages (Idris, Agda) are bootstrapped on top of. It's a niche use admittedly, but it's hard to understate how great Haskell is for writing modern functional compilers.
    - dllthomas 12y ago
      Certainly possible. There's some great stuff going on there.
  - zhemao 12y ago
    Yeah, but both of those are command line tools. You don't have to know Haskell in order to use them. You don't even need to know that they are written in Haskell if your distro provides binary packages.
    - dllthomas 12y ago
      True, though pandoc exists as a library as well. Xmonad? Any of the web frameworks? That new rest framework? Shelly?
  - 12y ago
RollAHardSix 12y ago
It's not just popularity. I wouldn't trust anyone on my team (of 4) to 'get' a Functional Language. Maybe one out of four (Not counting myself in this scenario), and almost no-one that they would hire later on. That leads to a pretty low chance of it ever being adopted where I work.
- MichaelGG 12y ago
  What kind of work are you doing, and what kind of people are you hiring? I'd be very nervous of working with someone that wasn't actually capable of "getting" FP.
  - squidsoup 12y ago
    I suppose that depends on your definition of FP. If you're just talking about HOF or 'programming with functions' fair enough, but some individuals (erroneously imo) only consider languages with higher kinded types 'functional'. The term is really overloaded.
    - pjmlp 12y ago
      Which puts all Lisp inspired languages out of FP.
  - RollAHardSix 12y ago
    I don't hire anyone, just to get that out of the way. :) I don't want to go into to much detail but a .net financial management client and web application. Nothing fancy by any means. Let's also just say I don't have very many options where I live, and am geographically restricted because I don't believe in sacrificing watching my daughter grow up. I'm interested in remote work but that hasn't been very easy to look into. I'm in that mystical land between mid-level and senior and most remote jobs seem to want senior in both skills and time. I'd even consider getting away from .Net entirely and professionally pursing a new stack but those opportunities haven't been available at all when looking at remote positions (And I completely understand why).
  - collyw 12y ago
jkscm 12y ago
Switching to FP is a bit like switching to Dvorak: the cost of switching are still to high to justify the effort.
- quadrangle 12y ago
  The answer is obviously to teach Dvorak and FP from the beginning so you don't have to switch.
  - zak_mc_kracken 12y ago
    Except that Dvorak has been repeatedly proven as an inferior solution to qwerty, especially for programmers (and it's also pretty bad for carpal tunnel syndrome).
    - Curmudgel 12y ago
      Really? Do you know of any research that shows this?
    - jjoonathan 12y ago
      [citation needed]. I have a hard time believing that a layout which cuts the travel distance of your fingertips in half is worse for carpal tunnel. Number of characters in your post: 139 Number of characters on Dvorak home row: 83 Number of characters on QWERTY home row: 41 A solid 1/3d of those are 'a', the homerow letter they have in common. Also, my original motivation in learning Dvorak was to stop myself from touch-typing (I repeatedly tried and failed on QWERTY). It was quite a success in that regard. Incidentally, I do agree with the earlier post saying that it wasn't worth it. But I also strongly believe that it was an improvement (there's a reason why I don't switch back), just not an improvement large enough to justify the effort (which was much greater than expected).
      - zak_mc_kracken 12y ago
        Dvorak wasn't designed for programming, which includes a lot of non-alphabetical symbols. Wikipedia says: "The carefully controlled study failed to show any benefit to the Dvorak keyboard layout in typing or training speed" http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard Note that this is for English, which means Dvorak fails to deliver even for what it was designed for. As I mentioned above, Dvorak's performance and strain on your hand is even worse when you are doing something else than typing English (programming, typing another language, writing spreadsheets, etc...).
hibikir 12y ago
With most of those problems pretty much gone, functional programming is doing quite a bit better than it did 15 years ago. Hybrids languages are gaining popularity: You can find Scala in quite a few large companies out there. Major adoption of non-hybrid languages doesn't seem like something that will happen any time soon though, and it sure seems like the FP community actually wants it that way. We just sent one of our people to attend Lambdajam, and in his 5 minute version of what he learned, he was telling us how his impression is that there were plenty of Haskell people there that seemed to barely tolerate having any talk about Scala in the conference. Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations. So I suspect that the future of FP is to be influential, for most of the best bits to be copied by language makers that build communities that care about marketing, and Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.
- michaelochurch 12y ago
  Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations. Those hybrid languages (e.g. Python, F#, and Scala) are great for new development but awful when you have to maintain low-quality legacy code. That said... I think that observation applies far beyond functional programming. (It's rare, but certainly possible, for bad Haskell code to exist.) A common impetus behind language churn is the programmer's desire to justify green-field development (which is fun, even in C++) instead of career-damning legacy maintenance (which is unpleasant, even in good languages). Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory. This is an exaggeration of that prejudice. I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. Functor, monoid, and monad sound a lot scarier than they actually are.
  - rtpg 12y ago
    pedantic, but I really wouldn't call Python a hybrid language on the same level as F# and Scala. Python's functional programming capabilities are pretty poor (not to mention that things like TCO are missing). Not to say that Python is a bad language, but having continuously tried to program in a functional style I've found that more iterative-seeming code ends up being more idiomatic and maintainable. > do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. That is extremely true. Even in widely-used packages, you'll rarely find good official documentation (quickstarts or the like). Sure, for a lot of packages , types are good enough (if you have a package to read a CSV file, all you need to do is find the CSVConf -> Handle -> [[String]] function), but with the bigger, more framework-y packages, there are so many types internal to the system that you _have_ to read through everything to do even simple things. Too much time is spent trying to explain how the language (which ends up being simple) works and not enough time on practical guides on how to actually do things. This has become a bit of a rant, but in Math (the kind most people go through in middle school), you always learn specific cases before going into general theory. Unfortunately, a lot of Haskellers end up being mathematicians of the PhD style, where they're fine with just going into general theory. Examples are useful!
michaelochurch 12y ago
Plus le change, plus le meme chose. Functional programming has a couple of problems, when it comes to uptake. The first is that you only get 40% of the benefit if you go 90% of the way. (Static typing is the same way, which is why I prefer Clojure's typelessness over the mediocre static typing of Java or C++ or Go.) In that case, the "impure" 10% still causes, if not realized complexity, the potential for complexity that infuriates maintainers. If you go 90% of the way on FP and get 40% of the benefits, that still means you're writing code faster and generally producing less of it, and those are good things. However, there's a nasty duality in programming which is that saving time on the fun stuff means more time is spent on the un-fun stuff. (If you make writing of code 4 times faster and debugging of nasty interface issues 2 times faster, you spend a larger proportion of your time on the latter.) Unless you can eliminate whole classes of un-fun-ness (e.g. categories of bugs) it's often not worth it. Eliminating 90% of the un-fun-ness just means you're spending more time on that remaining 10%. For example, Python can be used as a mostly functional language and thereby go 90% of the way (conceptually) to FP, but it isn't. The community has judged it to be not worth it. Scala should be used for FP, but there are plenty of Java++ programmers who still use null instead of Option[T]. Sadly, it doesn't take much of this dysfunctional programming to emasculate FP and leave an unbiased person asking, "Why bother?" It might not even be the right way to go, for a maintenance project. Mixing two styles is going to make it more illegible than using the existing (if suboptimal) style for new changes and work. The career issues noted are also huge. The average Clojure or Haskell developer makes slightly than the average Java developer, but if you control for skill and compare at-level, the Java or C++ developer wins. A 1.8 Java developer (scale here: http://michaelochurch.wordpress.com/2013/04/22/gervais-macleod-23-the-shodan-programmer/ http://michaelochurch.wordpress.com/2013/04/22/gervais-macle...) makes $175,000 and turns down invitations into VP-level positions at major corporations on a regular basis, because 1.6+ Java developers are just so rare. A 1.8 C++ developer can make $500,000 per year at a hedge fund. The 1.8 Haskell or Clojure developer makes about $125,000 on average, which is not bad but hardly stratospheric. This tends toward a self-perpetuating exaggeration of historical discrepancies in language popularity. Even if the average Haskell job is better, Haskell jobs (at all) are much harder to get, and Haskell jobs that pay as well as even an upper-middle Java job are extremely rare. The market is just stronger for Java people, so that keeps people wanting to use it, which keeps the majority of companies preferring it over better languages because they fear maintenance risk more than low productivity. I'm less charitable than Wadler on the "they don't get it" angle. Certainly there are smart people who "get" functional programming and have good reasons not to use it. Still, I do think that a contributing factor to FP's lack of uptake is the anti-intellectualism of the programming world. It's not that anti-intellectuals have some natural inclination toward Java or C++. The anti-intellectuals have the general attitude that language doesn't matter. And then they pick Java for some risk-averse, enterprisey shitfuck reason like maintenance risk or lack of an available developer pool, both of which are just business stinginess ("we don't want to train people"). What makes them vile is not their tastes in languages (there is a lack of taste in the Java community but, even still, there are cases where Java is the absolute right language to use) but the fact that they don't take programmers' concerns (such as tooling choices) seriously at all, and prioritize manager-type concerns over the needs of the people actually doing the fucking work.
wyager 12y ago
I think the "they don't get it" thing is actually quite a valid reason. I've heard some really ignorant things said in opposition to functional programming. I don't think it applies to the majority of potential users, but certainly a non-negligible percentage. Examples: "Immutability is stupid, because if your program is immutable it can't do anything." "You just end up writing everything in an IO Monad anyway." "Functions are good for math, but not for coding."
- swift 12y ago
  I agree that this is the case for a lot of people. It's not a judgement of their abilities or anything like that; it's just that, as a practical matter, to really understand some things you have to commit and actually solve some real problems with them. The payoff isn't very apparent when you're starting out, but for me at least the insights I've gained from functional programming have been huge. FP isn't the only thing in this category - like many people on HN I learned OOP a long time ago, but I remember it being similarly earth shattering, and I went through a period of over-enthusiasm and evangelism for Java and GoF design patterns just like the one I went through when I first learned Haskell. The code-is-data realization that you have when you learn a Lisp is similarly powerful. I hope I experience more revelations like these! These moments where you learn a whole new way of thinking are the purest joy programming has given me.
galaxyLogic 12y ago
I think the Haskell, OCaml, F# people are promoting their language of choice the wrong way. The way to do it would be to show concrete examples of problems which are difficult to solve in say Java, and then show how that is a non-problem in Haskell etc. Of course if you know your language very well, it is much easier for YOU to be working with it. Just saying it has this or that feature is great, but does not really tell us why it would be costly to do similar things in other languages. What does FP really mean? The term is used frequently as a synonym for Haskell. Does it mean "type-inference"? But is that really a 'functional' feature? Does it mean 'immutability'? In Java you can declare your data to be immutable. Does it mean 'closures? Or being able to pass a function as an argument or result. You can do those in JavaScript.
- codygman 12y ago
  For me, purity, functional composition, and avoiding mutable state.
  - galaxyLogic 12y ago
    Makes sense, a function must always return the same value for the same argument. Therefore if there were mutable state you might have things that look like functions but are really not. But what is "purity"? Does it mean that you can NOT HAVE mutable state in any program written in a "purely functional" language? I still don't quite get it how a language could be "purely" functional if it has to do IO. Reading the user's input will return a different value most of the time. And what do you do in Haskel if you need to know the current TIME for any reason? It can't be returned by a "function" because its result will always be different. So there must be something ELSE besides functions in the language. But doesn't that then mean that it is no longer a "purely functional" lanaguage?
    - mhogomchungu 12y ago
      A "pure" functional programming language has the problem you have identified and that is why haskel for a very long time was considered an academic language since it couldnt do anything useful as anything useful requires side effects like IO. The above is how haskel was introduced when i took it in CS at Syracuse University. The practicalities of haskel as a useful and practical language are realized through monads[1]. Use of monads to deal with side effects and impure world automatically make haskel "none pure". With the existence of monads,the purity of the language is a matter of opinion or degrees since it largely based on "idiomatic" usage. To say haskel is an impure language because of monads will be akin to say C# is an unsafe language because it allows pointer managements through the usage of "unsafe" keyword. [1] http://en.wikipedia.org/wiki/Monad_%28functional_programming%29 http://en.wikipedia.org/wiki/Monad_%28functional_programming...
ExpiredLink 12y ago
> For a given task, the imperative solution may leap immediately to mind or be found in a handy textbook, while a comparable functional solution may require considerable effort to find FP means additional levels of indirection which makes it less efficient than imperative approaches. If FP really were more productive than imperative languages it would have been adopted by the industry long ago.
duncanawoods 12y ago
Here is my take as someone who could but chooses not to use fp. When I look at “good haskell” I see it dominated with comments written in procedural english describing what the code does e.g. http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/Text-PrettyPrint-HughesPJ.html http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/T... Haskell requires this because, lets be frank, its really hard to understand. I can hear the howls of anger but if you ask “man in the street”, will he do a better job explaining the above haskell sans comments or a similar pretty printer written in VB? I have CS background, studied FP and type theory, but I am more like the man in the street. What I want from a programming language is an executable description of what I want to achieve. I want that description to have all the good qualities sought in fp but more importantly I want it to flow into and out of my brain (and my colleague’s brains) like butter not like a sudoku puzzle trapped in a type theory proof and then Huffman encoded (because descriptive names are the preserve of all those "terrible java programmers"). In the real world, I need to write code that makes fast incremental changes to large interconnected data-structures e.g. graphs and trees with indexes and all sorts. I cannot begin to imagine how to solve half my problems with immutable data-structures. With what I know at the moment, it would be a massive obstacle to the real problems I need to solve.
- galaxyLogic 12y ago
  Yes, readability. It's only half the story if you can be more productive when writing programs. Readability is probably more important because SW needs maintenance. And readability is not only about how fast YOU can read and understand Haskel. It's more about how fast other programmers can. Imagine all scientific papers were written in Latin. I think you make a valid point. Many comparisons of Programming Languages productivity only try to measure how fast you can code a new application in them, but not how fast you can modify an existing application to do something else - ASSUMING you are not the author of the original version.

85 points by tel 12y ago

It's interesting to see how 15+ years later, general attitudes among the masses haven't changed much in this regard (according to the most popularly used languages [0][1]). Feels bad, man. [0] http://beust.com/weblog/2014/05/03/language-popularity-on-github/ http://beust.com/weblog/2014/05/03/language-popularity-on-gi... [1] https://www.google.com/search?q=language+popularity https://www.google.com/search?q=language+popularity

deleted 12y ago
[deleted]
clusterfoo 12y ago
Would you say that the functional paradigm has started to gain more traction lately though? -- I don't know because I haven't been programming long enough, so maybe it just seems that way to me simply because now that I'm aware of its existence I'm seeing it everywhere. I read a quote once about The Velvet Underground that stuck with me. It said that, while not many people bought their albums, everyone who did started a band. Sometimes it seems like Haskell is The Velvet Underground of programming languages. While not many people are using it, everyone who is has started their own language/functional library -- Influencing other languages is, in a way, people using FP languages, just indirectly. I've not written a single serious Haskell program -- I don't think I would even know how to, tbh --, but I sure feel like just playing with it and learning about its theoretical motivations has made me a much better programmer in other languages.
- mhogomchungu 12y ago
  >Would you say that the functional paradigm has started to gain more traction lately though? That is certainly true but I think more people will not shift to functional programming languages to do functional programming style programming but will stick with their favorite imperative language and do functional programming there as more and more imperative languages add features and facilities that allow functional programming style programming. Case in point, i have this Qt/C++[1] library that evaluates lambdas in a lazy fashion. You can have,for example, a function that returns what is called "a future",ie something that can be evaluated at a later time to produce a value "held" in the future or the future can be cancelled if the function caller decides they no longer need the result. Introductions of lambdas in C++11 allows for this kind of programming to happen in C++ and i suspect more and more C++ programmers will start coding to this style as more and more APIs will start getting released that will take lambdas as arguments or return them as results. It is an interesting new way of doing C++ and these ideas are mostly borrowed from functional programming world. [1] https://github.com/mhogomchungu/tasks https://github.com/mhogomchungu/tasks
- dllthomas 12y ago
  "It said that, while not many people bought their albums, everyone who did started a band." And possibly a country. http://en.wikipedia.org/wiki/V%C3%A1clav_Havel http://en.wikipedia.org/wiki/V%C3%A1clav_Havel
- pjmlp 12y ago
  > Would you say that the functional paradigm has started to gain more traction lately though? Surely. All major languages are going hybrid, mixing imperative (mostly OOP) with functional programming concepts. Until we get a complete new computer architecture, like quantum computers, the mainstream will be hybrid OOP + FP.
- pedrow 12y ago
  > Would you say that the functional paradigm has started to gain more traction lately though? I would and I believe it started to happen when people started talking about Scala. I also think something similar happened with OOP in (maybe?) the early 1990s - i.e. we'd had Simula, Smalltalk and so on for years but it became mainstream. I'm thinking of things like Visual Basic 1.0 (1991), C++ v2.0 (1989)
baddox 12y ago
But many concepts from functional languages have become commonplace in popular multi-paradigm languages. That's probably the best we can realistically hope for in that time frame.
mathattack 12y ago
My impression is that it is making a difference amongst top programmers. When I learned Scheme way back when in college, there was no pretense of it being practical. My AI professor said, "AI is reduced to LISP hacking" and that was to denigrate AI, not raise LISP. Nowadays people see the value of recursive thinking, and hence the value of functional programming. The convergence of many technology trends seems to suggest that the idea of "The program can be the data, and the data can be the program" is no longer so far fetched.

tieTYT 12y ago

> Advocates of functional languages claim they produce an order of magnitude improvement in productivity. Experiments don't always verify that figure -- sometimes they show an improvement of only a factor of four. It's weird, the first time I read this I was excited to read the source of this quote. When I finished reading I scrolled up to the top and was disappointed to see a citation missing. Does anyone know what experiment he's referring to?

Avshalom 12y ago
I think probably http://haskell.cs.yale.edu/?post_type=publication&p=366 http://haskell.cs.yale.edu/?post_type=publication&p=366

vajrabum 12y ago

That's really old so I actually looked at it (again). Here are the criteria that Wadler mentions that ho<eld back adoption. Things that Haskell used to be weak on but now has good support for: FFI - yes Libraries - Yes Portability - Yes Ease of installation - Yes Packagability - Yes Tools - yes Training - available Performance - yes (non)Reasons why it doesn't get adopted. Still apply. Popularity - No still not popular They don’t get it - Yes they still don't get it Killer App - none that I can see (darcs?)

dllthomas 12y ago
"Killer App - none that I can see (darcs?)" Maybe pandoc.
- freyrs3 12y ago
  Historically I think Haskell will be very important as the substrate on which a lot of the next generation of dependently-typed languages (Idris, Agda) are bootstrapped on top of. It's a niche use admittedly, but it's hard to understate how great Haskell is for writing modern functional compilers.
  - dllthomas 12y ago
    Certainly possible. There's some great stuff going on there.
- zhemao 12y ago
  Yeah, but both of those are command line tools. You don't have to know Haskell in order to use them. You don't even need to know that they are written in Haskell if your distro provides binary packages.
  - dllthomas 12y ago
    True, though pandoc exists as a library as well. Xmonad? Any of the web frameworks? That new rest framework? Shelly?
- 12y ago

RollAHardSix 12y ago

It's not just popularity. I wouldn't trust anyone on my team (of 4) to 'get' a Functional Language. Maybe one out of four (Not counting myself in this scenario), and almost no-one that they would hire later on. That leads to a pretty low chance of it ever being adopted where I work.

MichaelGG 12y ago
What kind of work are you doing, and what kind of people are you hiring? I'd be very nervous of working with someone that wasn't actually capable of "getting" FP.
- squidsoup 12y ago
  I suppose that depends on your definition of FP. If you're just talking about HOF or 'programming with functions' fair enough, but some individuals (erroneously imo) only consider languages with higher kinded types 'functional'. The term is really overloaded.
  - pjmlp 12y ago
    Which puts all Lisp inspired languages out of FP.
- RollAHardSix 12y ago
  I don't hire anyone, just to get that out of the way. :) I don't want to go into to much detail but a .net financial management client and web application. Nothing fancy by any means. Let's also just say I don't have very many options where I live, and am geographically restricted because I don't believe in sacrificing watching my daughter grow up. I'm interested in remote work but that hasn't been very easy to look into. I'm in that mystical land between mid-level and senior and most remote jobs seem to want senior in both skills and time. I'd even consider getting away from .Net entirely and professionally pursing a new stack but those opportunities haven't been available at all when looking at remote positions (And I completely understand why).
- collyw 12y ago

jkscm 12y ago

Switching to FP is a bit like switching to Dvorak: the cost of switching are still to high to justify the effort.

quadrangle 12y ago
The answer is obviously to teach Dvorak and FP from the beginning so you don't have to switch.
- zak_mc_kracken 12y ago
  Except that Dvorak has been repeatedly proven as an inferior solution to qwerty, especially for programmers (and it's also pretty bad for carpal tunnel syndrome).
  - Curmudgel 12y ago
    Really? Do you know of any research that shows this?
  - jjoonathan 12y ago
    [citation needed]. I have a hard time believing that a layout which cuts the travel distance of your fingertips in half is worse for carpal tunnel. Number of characters in your post: 139 Number of characters on Dvorak home row: 83 Number of characters on QWERTY home row: 41 A solid 1/3d of those are 'a', the homerow letter they have in common. Also, my original motivation in learning Dvorak was to stop myself from touch-typing (I repeatedly tried and failed on QWERTY). It was quite a success in that regard. Incidentally, I do agree with the earlier post saying that it wasn't worth it. But I also strongly believe that it was an improvement (there's a reason why I don't switch back), just not an improvement large enough to justify the effort (which was much greater than expected).
    - zak_mc_kracken 12y ago
      Dvorak wasn't designed for programming, which includes a lot of non-alphabetical symbols. Wikipedia says: "The carefully controlled study failed to show any benefit to the Dvorak keyboard layout in typing or training speed" http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard Note that this is for English, which means Dvorak fails to deliver even for what it was designed for. As I mentioned above, Dvorak's performance and strain on your hand is even worse when you are doing something else than typing English (programming, typing another language, writing spreadsheets, etc...).

hibikir 12y ago

With most of those problems pretty much gone, functional programming is doing quite a bit better than it did 15 years ago. Hybrids languages are gaining popularity: You can find Scala in quite a few large companies out there. Major adoption of non-hybrid languages doesn't seem like something that will happen any time soon though, and it sure seems like the FP community actually wants it that way. We just sent one of our people to attend Lambdajam, and in his 5 minute version of what he learned, he was telling us how his impression is that there were plenty of Haskell people there that seemed to barely tolerate having any talk about Scala in the conference. Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations. So I suspect that the future of FP is to be influential, for most of the best bits to be copied by language makers that build communities that care about marketing, and Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory.

michaelochurch 12y ago
Badmouthing of hybrid languages is the order of the day by extremely prominent members of the FP community, even if they end up using said languages in their presentations. Those hybrid languages (e.g. Python, F#, and Scala) are great for new development but awful when you have to maintain low-quality legacy code. That said... I think that observation applies far beyond functional programming. (It's rare, but certainly possible, for bad Haskell code to exist.) A common impetus behind language churn is the programmer's desire to justify green-field development (which is fun, even in C++) instead of career-damning legacy maintenance (which is unpleasant, even in good languages). Haskell and the like will remain used only by people that just think there's no way to write any useful program without first learning all about category theory. This is an exaggeration of that prejudice. I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. Functor, monoid, and monad sound a lot scarier than they actually are.
- rtpg 12y ago
  pedantic, but I really wouldn't call Python a hybrid language on the same level as F# and Scala. Python's functional programming capabilities are pretty poor (not to mention that things like TCO are missing). Not to say that Python is a bad language, but having continuously tried to program in a functional style I've found that more iterative-seeming code ends up being more idiomatic and maintainable. > do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) to package a not-that-hard language as something average programmers can understand. That is extremely true. Even in widely-used packages, you'll rarely find good official documentation (quickstarts or the like). Sure, for a lot of packages , types are good enough (if you have a package to read a CSV file, all you need to do is find the CSVConf -> Handle -> [[String]] function), but with the bigger, more framework-y packages, there are so many types internal to the system that you _have_ to read through everything to do even simple things. Too much time is spent trying to explain how the language (which ends up being simple) works and not enough time on practical guides on how to actually do things. This has become a bit of a rant, but in Math (the kind most people go through in middle school), you always learn specific cases before going into general theory. Unfortunately, a lot of Haskellers end up being mathematicians of the PhD style, where they're fine with just going into general theory. Examples are useful!

michaelochurch 12y ago

Plus le change, plus le meme chose. Functional programming has a couple of problems, when it comes to uptake. The first is that you only get 40% of the benefit if you go 90% of the way. (Static typing is the same way, which is why I prefer Clojure's typelessness over the mediocre static typing of Java or C++ or Go.) In that case, the "impure" 10% still causes, if not realized complexity, the potential for complexity that infuriates maintainers. If you go 90% of the way on FP and get 40% of the benefits, that still means you're writing code faster and generally producing less of it, and those are good things. However, there's a nasty duality in programming which is that saving time on the fun stuff means more time is spent on the un-fun stuff. (If you make writing of code 4 times faster and debugging of nasty interface issues 2 times faster, you spend a larger proportion of your time on the latter.) Unless you can eliminate whole classes of un-fun-ness (e.g. categories of bugs) it's often not worth it. Eliminating 90% of the un-fun-ness just means you're spending more time on that remaining 10%. For example, Python can be used as a mostly functional language and thereby go 90% of the way (conceptually) to FP, but it isn't. The community has judged it to be not worth it. Scala should be used for FP, but there are plenty of Java++ programmers who still use null instead of Option[T]. Sadly, it doesn't take much of this dysfunctional programming to emasculate FP and leave an unbiased person asking, "Why bother?" It might not even be the right way to go, for a maintenance project. Mixing two styles is going to make it more illegible than using the existing (if suboptimal) style for new changes and work. The career issues noted are also huge. The average Clojure or Haskell developer makes slightly than the average Java developer, but if you control for skill and compare at-level, the Java or C++ developer wins. A 1.8 Java developer (scale here: http://michaelochurch.wordpress.com/2013/04/22/gervais-macleod-23-the-shodan-programmer/ http://michaelochurch.wordpress.com/2013/04/22/gervais-macle...) makes $175,000 and turns down invitations into VP-level positions at major corporations on a regular basis, because 1.6+ Java developers are just so rare. A 1.8 C++ developer can make $500,000 per year at a hedge fund. The 1.8 Haskell or Clojure developer makes about $125,000 on average, which is not bad but hardly stratospheric. This tends toward a self-perpetuating exaggeration of historical discrepancies in language popularity. Even if the average Haskell job is better, Haskell jobs (at all) are much harder to get, and Haskell jobs that pay as well as even an upper-middle Java job are extremely rare. The market is just stronger for Java people, so that keeps people wanting to use it, which keeps the majority of companies preferring it over better languages because they fear maintenance risk more than low productivity. I'm less charitable than Wadler on the "they don't get it" angle. Certainly there are smart people who "get" functional programming and have good reasons not to use it. Still, I do think that a contributing factor to FP's lack of uptake is the anti-intellectualism of the programming world. It's not that anti-intellectuals have some natural inclination toward Java or C++. The anti-intellectuals have the general attitude that language doesn't matter. And then they pick Java for some risk-averse, enterprisey shitfuck reason like maintenance risk or lack of an available developer pool, both of which are just business stinginess ("we don't want to train people"). What makes them vile is not their tastes in languages (there is a lack of taste in the Java community but, even still, there are cases where Java is the absolute right language to use) but the fact that they don't take programmers' concerns (such as tooling choices) seriously at all, and prioritize manager-type concerns over the needs of the people actually doing the fucking work.

wyager 12y ago

I think the "they don't get it" thing is actually quite a valid reason. I've heard some really ignorant things said in opposition to functional programming. I don't think it applies to the majority of potential users, but certainly a non-negligible percentage. Examples: "Immutability is stupid, because if your program is immutable it can't do anything." "You just end up writing everything in an IO Monad anyway." "Functions are good for math, but not for coding."

swift 12y ago
I agree that this is the case for a lot of people. It's not a judgement of their abilities or anything like that; it's just that, as a practical matter, to really understand some things you have to commit and actually solve some real problems with them. The payoff isn't very apparent when you're starting out, but for me at least the insights I've gained from functional programming have been huge. FP isn't the only thing in this category - like many people on HN I learned OOP a long time ago, but I remember it being similarly earth shattering, and I went through a period of over-enthusiasm and evangelism for Java and GoF design patterns just like the one I went through when I first learned Haskell. The code-is-data realization that you have when you learn a Lisp is similarly powerful. I hope I experience more revelations like these! These moments where you learn a whole new way of thinking are the purest joy programming has given me.

galaxyLogic 12y ago

I think the Haskell, OCaml, F# people are promoting their language of choice the wrong way. The way to do it would be to show concrete examples of problems which are difficult to solve in say Java, and then show how that is a non-problem in Haskell etc. Of course if you know your language very well, it is much easier for YOU to be working with it. Just saying it has this or that feature is great, but does not really tell us why it would be costly to do similar things in other languages. What does FP really mean? The term is used frequently as a synonym for Haskell. Does it mean "type-inference"? But is that really a 'functional' feature? Does it mean 'immutability'? In Java you can declare your data to be immutable. Does it mean 'closures? Or being able to pass a function as an argument or result. You can do those in JavaScript.

codygman 12y ago
For me, purity, functional composition, and avoiding mutable state.
- galaxyLogic 12y ago
  Makes sense, a function must always return the same value for the same argument. Therefore if there were mutable state you might have things that look like functions but are really not. But what is "purity"? Does it mean that you can NOT HAVE mutable state in any program written in a "purely functional" language? I still don't quite get it how a language could be "purely" functional if it has to do IO. Reading the user's input will return a different value most of the time. And what do you do in Haskel if you need to know the current TIME for any reason? It can't be returned by a "function" because its result will always be different. So there must be something ELSE besides functions in the language. But doesn't that then mean that it is no longer a "purely functional" lanaguage?
  - mhogomchungu 12y ago
    A "pure" functional programming language has the problem you have identified and that is why haskel for a very long time was considered an academic language since it couldnt do anything useful as anything useful requires side effects like IO. The above is how haskel was introduced when i took it in CS at Syracuse University. The practicalities of haskel as a useful and practical language are realized through monads[1]. Use of monads to deal with side effects and impure world automatically make haskel "none pure". With the existence of monads,the purity of the language is a matter of opinion or degrees since it largely based on "idiomatic" usage. To say haskel is an impure language because of monads will be akin to say C# is an unsafe language because it allows pointer managements through the usage of "unsafe" keyword. [1] http://en.wikipedia.org/wiki/Monad_%28functional_programming%29 http://en.wikipedia.org/wiki/Monad_%28functional_programming...

ExpiredLink 12y ago

> For a given task, the imperative solution may leap immediately to mind or be found in a handy textbook, while a comparable functional solution may require considerable effort to find FP means additional levels of indirection which makes it less efficient than imperative approaches. If FP really were more productive than imperative languages it would have been adopted by the industry long ago.

duncanawoods 12y ago

Here is my take as someone who could but chooses not to use fp. When I look at “good haskell” I see it dominated with comments written in procedural english describing what the code does e.g. http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/Text-PrettyPrint-HughesPJ.html http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/T... Haskell requires this because, lets be frank, its really hard to understand. I can hear the howls of anger but if you ask “man in the street”, will he do a better job explaining the above haskell sans comments or a similar pretty printer written in VB? I have CS background, studied FP and type theory, but I am more like the man in the street. What I want from a programming language is an executable description of what I want to achieve. I want that description to have all the good qualities sought in fp but more importantly I want it to flow into and out of my brain (and my colleague’s brains) like butter not like a sudoku puzzle trapped in a type theory proof and then Huffman encoded (because descriptive names are the preserve of all those "terrible java programmers"). In the real world, I need to write code that makes fast incremental changes to large interconnected data-structures e.g. graphs and trees with indexes and all sorts. I cannot begin to imagine how to solve half my problems with immutable data-structures. With what I know at the moment, it would be a massive obstacle to the real problems I need to solve.

galaxyLogic 12y ago
Yes, readability. It's only half the story if you can be more productive when writing programs. Readability is probably more important because SW needs maintenance. And readability is not only about how fast YOU can read and understand Haskel. It's more about how fast other programmers can. Imagine all scientific papers were written in Latin. I think you make a valid point. Many comparisons of Programming Languages productivity only try to measure how fast you can code a new application in them, but not how fast you can modify an existing application to do something else - ASSUMING you are not the author of the original version.