8 ms·

There is still no construction of a study that I would think would convince me of those figures. The number of confounders is invariably far too high. But ther

by tel 11y ago

There is still no construction of a study that I would think would convince me of those figures. The number of confounders is invariably far too high. But there are definitions of at least the latter two which are substantially justified via an FP take on the world. Really, though, I think FP does itself a disservice by claiming to be a "style" of computing much like OO. It's really just a back-to-the-basics take on what "is" computing and from it you can get a very well-behaved foundations of formal languages to build your CS (of whatever brand you like) atop. This has proven to be incredibly fruitful as a theory since, honestly, something like 1907.

l_dopa 11y ago
This is a really important point that I'm not sure I've seen before in a discussion about the adoption of FP. You're completely right, but I can't imagine FP language advocates would get very far by leading with the history of type theory.
erik14th 11y ago
IMO when it comes to productivity most of the time the platform, and by platform I mean documentation, build tools, package managers and such, are a big influence if not the biggest. From my experience with functional languages, they slack in that aspect. I like Lisp's simplicity and I like the elegance in Haskell but the only Lisp I know that have a workflow that kinda matches my taste is Clojure, which reeks of java. I tried Haskell several times and I liked the language but I can't stand cabal. That's why I believe in Go, the language isn't eye popping, but every aspect of the workflow makes me smile and think "that's how you do it". And by that I mean the no-versioning policy, web stuff built in to the language, and I just love the workspace structure[0]. It is transparent, no need to google to find out where external packages are installed if you want to fiddle with it's source, no worries about version hell, no worries about unicode. I've read good things about racket in that aspect but I'm yet to try it. [0]https://golang.org/doc/code.html https://golang.org/doc/code.html
- mbrock 11y ago
  Lots of people are and have been "productive" in Haskell, various Lisp dialects, O'Caml, and so on. I worked at a startup whose Haskell backend was quite pleasant to work with and served them very well. This site itself is written in Arc, as you probably know, and Paul Graham has written several essays about the "productivity" he and his team achieved using Common Lisp. People can work productively with software using all kinds of tools and languages. As you mention, a lot of it might come down to taste, likes and dislikes, habits, etc. Of course you're going to be more productive if you're familiar with your tools. So your experience with productivity isn't really an objective indicator for anyone else.
  - erik14th 11y ago
    I didn't mean you can't be productive in functional languages. What I'm criticizing are the platforms and I don't see that as too much of a subjective matter. For me as a user Haskell(the platform) is inferior to, say, Go, simply because I can manage external packages that much easier. Thus if I needed to get something done I'd rather use Go, not because I think it's a better language than Haskell, but because of the pain in dealing with package versions, building, etc. Basically what I'm saying is that you don't see that much adoption, and thus data to endorse the productivity claims because of the platforms and not because the languages per se are bad. Pg said people don't use lisp because it looked weird and it's not popular[0] and I think it applies to functional languages in general. I don't think you can/should solve the former, but by having friendlier/better platforms you could start solving the latter. http://www.paulgraham.com/iflisp.html[0] http://www.paulgraham.com/iflisp.html[0]
    - codygman 11y ago
      How do you personally do package management with versioning in Go? Last time I checked Haskell was better than Go here.
      - erik14th 11y ago
        Go packages have no versions, if you make breaking changes you should make a new package so you don't need to specify a version in some metafile to stop the build process from breaking.
cousin_it 11y ago
> back-to-the-basics take on what "is" computing... to build your CS (of whatever brand you like) atop I feel that we've given many years of attention to functional programming, and it's been disappointingly unfruitful in most areas of CS, such as computational complexity, cryptography, machine learning, or computer graphics. Most new ideas coming out of the FP camp are applicable only to FP itself, like monads. We've discussed that before: https://news.ycombinator.com/item?id=8563817 https://news.ycombinator.com/item?id=8563817 Part of the mismatch is that many interesting algorithms are impure and cannot be easily made pure. I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask? But the bigger problem is that FP treats functions as black boxes, and that's just not enough to prove interesting results in most areas of CS. A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away. I admit that's a very vague idea, but I'm not smart enough to make it concrete :-)
- tel 11y ago
  I think pure FP gives a better foundation for mutation, too. It's very straightforward to use something like a pure FP language to make very clear the choice of semantics involving mutable slots.
- l_dopa 11y ago
  > I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask? http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis > A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away A lot of interesting research does exactly this, and a lot of it has found its way into ML-family languages. The starting point (or "foundation") in every case is a typed lambda calculus. Machine models, like turing machines, are just annoying to reason about and not extensible in any meaningful way.
  - cousin_it 11y ago
    Alas, the Church-Turing thesis doesn't say that every imperative algorithm can be translated to lambda calculus while keeping the same time and space complexity. The two main culprits are in-place mutation and O(1) array indexing.

by tel 11y ago

l_dopa 11y ago

This is a really important point that I'm not sure I've seen before in a discussion about the adoption of FP. You're completely right, but I can't imagine FP language advocates would get very far by leading with the history of type theory.

erik14th 11y ago

IMO when it comes to productivity most of the time the platform, and by platform I mean documentation, build tools, package managers and such, are a big influence if not the biggest. From my experience with functional languages, they slack in that aspect. I like Lisp's simplicity and I like the elegance in Haskell but the only Lisp I know that have a workflow that kinda matches my taste is Clojure, which reeks of java. I tried Haskell several times and I liked the language but I can't stand cabal. That's why I believe in Go, the language isn't eye popping, but every aspect of the workflow makes me smile and think "that's how you do it". And by that I mean the no-versioning policy, web stuff built in to the language, and I just love the workspace structure[0]. It is transparent, no need to google to find out where external packages are installed if you want to fiddle with it's source, no worries about version hell, no worries about unicode. I've read good things about racket in that aspect but I'm yet to try it. [0]https://golang.org/doc/code.html https://golang.org/doc/code.html

mbrock 11y ago
Lots of people are and have been "productive" in Haskell, various Lisp dialects, O'Caml, and so on. I worked at a startup whose Haskell backend was quite pleasant to work with and served them very well. This site itself is written in Arc, as you probably know, and Paul Graham has written several essays about the "productivity" he and his team achieved using Common Lisp. People can work productively with software using all kinds of tools and languages. As you mention, a lot of it might come down to taste, likes and dislikes, habits, etc. Of course you're going to be more productive if you're familiar with your tools. So your experience with productivity isn't really an objective indicator for anyone else.
- erik14th 11y ago
  I didn't mean you can't be productive in functional languages. What I'm criticizing are the platforms and I don't see that as too much of a subjective matter. For me as a user Haskell(the platform) is inferior to, say, Go, simply because I can manage external packages that much easier. Thus if I needed to get something done I'd rather use Go, not because I think it's a better language than Haskell, but because of the pain in dealing with package versions, building, etc. Basically what I'm saying is that you don't see that much adoption, and thus data to endorse the productivity claims because of the platforms and not because the languages per se are bad. Pg said people don't use lisp because it looked weird and it's not popular[0] and I think it applies to functional languages in general. I don't think you can/should solve the former, but by having friendlier/better platforms you could start solving the latter. http://www.paulgraham.com/iflisp.html[0] http://www.paulgraham.com/iflisp.html[0]
  - codygman 11y ago
    How do you personally do package management with versioning in Go? Last time I checked Haskell was better than Go here.
    - erik14th 11y ago
      Go packages have no versions, if you make breaking changes you should make a new package so you don't need to specify a version in some metafile to stop the build process from breaking.

cousin_it 11y ago

> back-to-the-basics take on what "is" computing... to build your CS (of whatever brand you like) atop I feel that we've given many years of attention to functional programming, and it's been disappointingly unfruitful in most areas of CS, such as computational complexity, cryptography, machine learning, or computer graphics. Most new ideas coming out of the FP camp are applicable only to FP itself, like monads. We've discussed that before: https://news.ycombinator.com/item?id=8563817 https://news.ycombinator.com/item?id=8563817 Part of the mismatch is that many interesting algorithms are impure and cannot be easily made pure. I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask? But the bigger problem is that FP treats functions as black boxes, and that's just not enough to prove interesting results in most areas of CS. A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away. I admit that's a very vague idea, but I'm not smart enough to make it concrete :-)

tel 11y ago
I think pure FP gives a better foundation for mutation, too. It's very straightforward to use something like a pure FP language to make very clear the choice of semantics involving mutable slots.
l_dopa 11y ago
> I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask? http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis > A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away A lot of interesting research does exactly this, and a lot of it has found its way into ML-family languages. The starting point (or "foundation") in every case is a typed lambda calculus. Machine models, like turing machines, are just annoying to reason about and not extensible in any meaningful way.
- cousin_it 11y ago
  Alas, the Church-Turing thesis doesn't say that every imperative algorithm can be translated to lambda calculus while keeping the same time and space complexity. The two main culprits are in-place mutation and O(1) array indexing.