7 ms·

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 popular

by 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!
- wavegeek 12y ago
  > awful when you have to maintain low-quality legacy code When is it not awful to maintain low-quality legacy code?
- the_af 12y ago
  > I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) [...] Well, the unofficial motto of the Haskell community is "avoid success at all costs" after all :) [1] [1] https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p...
codygman 12y ago
> 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. Oh please, you just devalued your entire comment with that untrue and derisive comment. Haskell is used by people who highly value composability, purity, correctness, and who believe mutable state should have a big red flag around it and be limited as much as possible.
- frowaway001 12y ago
  I think you have just proven his comment about the attitude of Haskell users.
  - tel 12y ago
    Purity, composability, correctness, and avoidance of mutability are hardly category theoretic or exclusively praised by Haskellers. You could claim that Haskellers are particularly enthusiastic in their desire to optimize for those things, but now you have to describe why that's a bad thing. And it's still not related the gp's points of badmouthing other languages or being unmarketable.
    - frowaway001 12y ago
      Try reading again what I wrote. Nothing I said is about "Purity, composability, correctness, and avoidance of mutability" and "why that's a bad thing", and all about "badmouthing other languages or being unmarketable".
  - codygman 12y ago
    I didn't badmouth any other language in that comment.
evincarofautumn 12y ago
> …his impression is that there were plenty of Haskell people there that seemed to barely tolerate having any talk about Scala in the conference. It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions. > 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. You’re repeating the false meme that I/O in Haskell is difficult or theoretical, and furthermore implying that learning is a bad thing.
- dragonwriter 12y ago
  > It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions. If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming.
  - evincarofautumn 12y ago
    > If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming. If I had mentioned exclusion, yes. C++ is mentioned at OOP conferences like ECOOP and OOPSLA as often as Scala is mentioned at FP conferences like ICFP, CUFP, and Lambdahack. But I have little doubt that a strawman proponent of a pure-OOP language such as Smalltalk—or Self or Ruby or Java or whichever language embodies the definition of OOP you prefer—would be as miffed about the use of C++ in lieu of their preferred language as hibikir’s friend’s strawman Haskeller is about Scala. And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway.
    - pjmlp 12y ago
      > And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway. It is hard to get a good grasp of OO in C++, if you don't experience pure OO languages, at least for some time. Multi-paradigm languages like C++ are great, but that power can work against learning a specific paradigm properly. Good program design, regardless of the paradigm requires experience and the ability to use the tools that expose paradigm best practices.
scythe 12y ago
>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. If that was Haskell's problem, its effects would be unique to Haskell. Rather, Haskell, like Erlang, Lisp, Eiffel, Smalltalk, and, in its early days -- and it had to fight to overcome this -- Java: these all have or had the same problem, which is that they don't integrate well with the "outside world". As a result, a great deal of effort is expended in the developer communities surrounding these languages to reinvent the wheel, axle, spoke, tire, hubcap, and spinner, which prevents said developers from making things that are truly interesting. Languages which work with the "outside world" can be used to develop great software even if they are not popular, like Lua and CoffeeScript. Go, Swift, Scala and Rust learned this. The most obvious point of contrast, though, is how quickly Clojure became more popular than Scheme/Racket, despite being basically the same thing.
- Derbasti 12y ago
  In what way does Lua interact with the outside world? Are you referring to it being embeddable, or the FFI in luajit2? Also, in what way does Swift work with the outside world? It seems to be locked in pretty tightly in its own little world?
  - scythe 12y ago
    >In what way does Lua interact with the outside world? Lua's C API allows Lua programs to bind to any C library. It's probably better at this than anything else out there, and there have been some attempts at really ambitious things like automatically generated Qt bindings: https://github.com/mkottman/lqt https://github.com/mkottman/lqt >in what way does Swift work with the outside world? Swift uses the Objective-C runtime. It interoperates with Objective-C very well and is designed to do so; by definition this means it also interoperates with C quite well. See: http://en.wikipedia.org/wiki/Swift_(programming_language)#Libraries.2C_runtime_and_development http://en.wikipedia.org/wiki/Swift_(programming_language)#Li...
- wirrbel 12y ago
  I like to see Clojure definitely scheme-inspired, but it is a very different language. Scheme has this approach where you can build almost anything out of cons, car, cdr. After using Clojure for a while, all this cons, car, cdr stuff of Scheme feels like being stuck in implementation detail. With the scheme community insisting on (1) recursion as the primary means for looping (2) no general polymorphism in the language standard I see no future in Scheme. (1) - I have seen the light with Clojure's `for` macro. While it is not much more as a `map` (or a python/haskell list comprehension) its that kind of sugar that is really readable and is a good platform for beginners to reach up to map, fold, and other higher order functions. (2) - Lists have car, cdr, Lazy lists in Scheme have stream-car, stream-cdr. I.e. I cannot use an algorithm that works on lists on lazy lists, etc. Even some lightweight dispatch here would make scheme so much more powerful and useful. So: While clojure is not much more than Scheme, it demonstrates how a little more can actually make a huge difference in usability and adoption PS: I really like Scheme as a small, simple language that gives you a good idea how an interpreter might work under the hood.
lambdasquirrel 12y ago
I've had a lot of trouble here too. Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it. Most recently, I designed an algebraic query language, and some Haskellers were like... and it's written in Scala? I don't know about you, but I'd rather do real math (or at least take a stab at it) in Scala than write more routing web frameworks in Haskell. Ideally, I would be writing it in Haskell (or Idris ;)) but the lack of willingness to cross over to the other side and interact with "normal" programmers really hurts us, and I'm honestly a little fed up with the fundamentalism. There are really smart folks out there with a lot of domain experience that we alienate when we blow off stepping stone languages like Scala.
- fauigerzigerk 12y ago
  >Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it. If they didn't, you'd probably not call them "the languages crowd" and we'd never get any new inspirational theories and principles out of them.
- continuations 12y ago
  I'm not familiar with the community - why do Haskell folks look down on Scala?
  - trobertson 12y ago
    The common opinion is that Scala is a poor man's Haskell, with few of the strengths and more weaknesses. It's seen as, at best, a stepping stone from imperative languages to "real" functional languages.
    - continuations 12y ago
      I see. What are the perceived weaknesses and lack of strengths of Scala as compared to Haskell?
      - 12y ago

by hibikir 12y ago

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!
wavegeek 12y ago
> awful when you have to maintain low-quality legacy code When is it not awful to maintain low-quality legacy code?
the_af 12y ago
> I do think that the Haskell community has failed (but is it a failure or a deliberate choice not-to?) [...] Well, the unofficial motto of the Haskell community is "avoid success at all costs" after all :) [1] [1] https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p...

codygman 12y ago

> 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. Oh please, you just devalued your entire comment with that untrue and derisive comment. Haskell is used by people who highly value composability, purity, correctness, and who believe mutable state should have a big red flag around it and be limited as much as possible.

frowaway001 12y ago
I think you have just proven his comment about the attitude of Haskell users.
- tel 12y ago
  Purity, composability, correctness, and avoidance of mutability are hardly category theoretic or exclusively praised by Haskellers. You could claim that Haskellers are particularly enthusiastic in their desire to optimize for those things, but now you have to describe why that's a bad thing. And it's still not related the gp's points of badmouthing other languages or being unmarketable.
  - frowaway001 12y ago
    Try reading again what I wrote. Nothing I said is about "Purity, composability, correctness, and avoidance of mutability" and "why that's a bad thing", and all about "badmouthing other languages or being unmarketable".
- codygman 12y ago
  I didn't badmouth any other language in that comment.

evincarofautumn 12y ago

> …his impression is that there were plenty of Haskell people there that seemed to barely tolerate having any talk about Scala in the conference. It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions. > 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. You’re repeating the false meme that I/O in Haskell is difficult or theoretical, and furthermore implying that learning is a bad thing.

dragonwriter 12y ago
> It’s a conference about functional programming. If they believe that functional languages are better for software development than imperative languages, then they may see hybrid languages as making unnecessary and detrimental concessions. If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming.
- evincarofautumn 12y ago
  > If that kind of extremism was applied in discussion of other paradigms, we'd be excluding mention of "hybrid languages" like C++ from discussions of Object Oriented Programming. If I had mentioned exclusion, yes. C++ is mentioned at OOP conferences like ECOOP and OOPSLA as often as Scala is mentioned at FP conferences like ICFP, CUFP, and Lambdahack. But I have little doubt that a strawman proponent of a pure-OOP language such as Smalltalk—or Self or Ruby or Java or whichever language embodies the definition of OOP you prefer—would be as miffed about the use of C++ in lieu of their preferred language as hibikir’s friend’s strawman Haskeller is about Scala. And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway.
  - pjmlp 12y ago
    > And anecdotally, the top C++ developers I’ve worked with didn’t have anything good to say about object-oriented programming anyway. It is hard to get a good grasp of OO in C++, if you don't experience pure OO languages, at least for some time. Multi-paradigm languages like C++ are great, but that power can work against learning a specific paradigm properly. Good program design, regardless of the paradigm requires experience and the ability to use the tools that expose paradigm best practices.

scythe 12y ago

>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. If that was Haskell's problem, its effects would be unique to Haskell. Rather, Haskell, like Erlang, Lisp, Eiffel, Smalltalk, and, in its early days -- and it had to fight to overcome this -- Java: these all have or had the same problem, which is that they don't integrate well with the "outside world". As a result, a great deal of effort is expended in the developer communities surrounding these languages to reinvent the wheel, axle, spoke, tire, hubcap, and spinner, which prevents said developers from making things that are truly interesting. Languages which work with the "outside world" can be used to develop great software even if they are not popular, like Lua and CoffeeScript. Go, Swift, Scala and Rust learned this. The most obvious point of contrast, though, is how quickly Clojure became more popular than Scheme/Racket, despite being basically the same thing.

Derbasti 12y ago
In what way does Lua interact with the outside world? Are you referring to it being embeddable, or the FFI in luajit2? Also, in what way does Swift work with the outside world? It seems to be locked in pretty tightly in its own little world?
- scythe 12y ago
  >In what way does Lua interact with the outside world? Lua's C API allows Lua programs to bind to any C library. It's probably better at this than anything else out there, and there have been some attempts at really ambitious things like automatically generated Qt bindings: https://github.com/mkottman/lqt https://github.com/mkottman/lqt >in what way does Swift work with the outside world? Swift uses the Objective-C runtime. It interoperates with Objective-C very well and is designed to do so; by definition this means it also interoperates with C quite well. See: http://en.wikipedia.org/wiki/Swift_(programming_language)#Libraries.2C_runtime_and_development http://en.wikipedia.org/wiki/Swift_(programming_language)#Li...
wirrbel 12y ago
I like to see Clojure definitely scheme-inspired, but it is a very different language. Scheme has this approach where you can build almost anything out of cons, car, cdr. After using Clojure for a while, all this cons, car, cdr stuff of Scheme feels like being stuck in implementation detail. With the scheme community insisting on (1) recursion as the primary means for looping (2) no general polymorphism in the language standard I see no future in Scheme. (1) - I have seen the light with Clojure's `for` macro. While it is not much more as a `map` (or a python/haskell list comprehension) its that kind of sugar that is really readable and is a good platform for beginners to reach up to map, fold, and other higher order functions. (2) - Lists have car, cdr, Lazy lists in Scheme have stream-car, stream-cdr. I.e. I cannot use an algorithm that works on lists on lazy lists, etc. Even some lightweight dispatch here would make scheme so much more powerful and useful. So: While clojure is not much more than Scheme, it demonstrates how a little more can actually make a huge difference in usability and adoption PS: I really like Scheme as a small, simple language that gives you a good idea how an interpreter might work under the hood.

lambdasquirrel 12y ago

I've had a lot of trouble here too. Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it. Most recently, I designed an algebraic query language, and some Haskellers were like... and it's written in Scala? I don't know about you, but I'd rather do real math (or at least take a stab at it) in Scala than write more routing web frameworks in Haskell. Ideally, I would be writing it in Haskell (or Idris ;)) but the lack of willingness to cross over to the other side and interact with "normal" programmers really hurts us, and I'm honestly a little fed up with the fundamentalism. There are really smart folks out there with a lot of domain experience that we alienate when we blow off stepping stone languages like Scala.

fauigerzigerk 12y ago
>Too often, the languages crowd will care more about the language itself rather than the problems you are solving with it. If they didn't, you'd probably not call them "the languages crowd" and we'd never get any new inspirational theories and principles out of them.
continuations 12y ago
I'm not familiar with the community - why do Haskell folks look down on Scala?
- trobertson 12y ago
  The common opinion is that Scala is a poor man's Haskell, with few of the strengths and more weaknesses. It's seen as, at best, a stepping stone from imperative languages to "real" functional languages.
  - continuations 12y ago
    I see. What are the perceived weaknesses and lack of strengths of Scala as compared to Haskell?
    - 12y ago