6 ms·

Yes, real size and real world examples are what counts. And then, as much as numerous examples of real world and big size problem (Google, Wikipedia, etc.) have

by gbog 13y ago

Yes, real size and real world examples are what counts. And then, as much as numerous examples of real world and big size problem (Google, Wikipedia, etc.) have been tackled with a mix of OOP glue code (Java, C++, Python) and declarative style data retrieval (SQL), I have much harder a time finding examples of FP uses in the real world. I suppose some data analysis is done FP style somewhere, but is it comparable in complexity? (The data might be very complex, the algorithms too, but the code itself probably has much less branches, corner cases, ifs, and other PM-added mess). Oh, and yes, I am aware of a web app written in lisp by pg, but I wonder if this experiment is really reproductible. Is this Viaweb code still maintained and running? When the "world" from the point of a view of a program is an enormous drealocks-like hairball full of heterogeneity (which is the case for the code bases of most of the tools we use, Facebook, PowerPoint, etc.), I have hard time imagining that it can be modelled in a nice FP ether where well-behaved functions pass to each other all the data they need, and magically "reduce" it to a magically deterministic output.

rybosome 13y ago
The thing that bothers me about this attitude is that it discourages considering alternatives. I've had a blog post on this stewing for awhile, but the gist of my counter argument is that it is a common human condition to feel that the current level of technology is sufficient - people have made that argument countless times in the face of progress.
- jafaku 13y ago
  He didn't say it's sufficient, he said OOP can do the work (lots of examples) while FP can't (he asked for examples, since we don't have any).
- joe_the_user 13y ago
  Or perhaps it encourages think about alternative-alternatives. Functional programming has been presented as the alternative to OOP for a looong time now and the indications are that it just isn't to replace it ever. OOP is a paradigm that does work for gluing huge piles of flawed-but-useful code together. And OOP indeed has lurid flaws to it on multiple levels (the ambiguity concerning what "inheritance" is supposed to mean is one of many ridiculousnesses). Something that replaces OOP would need to have SOME winning combination of gluing hunks-of-together so you didn't have to start from scratch and being-so-powerful-but-understandable that medium skill-level programmers could replace the junk reasonably painlessly. If we acknowledge FP isn't going to be that paradigm, then we can start searching for a different one.
  - rybosome 13y ago
    Interesting; I am amenable to that idea, but don't have any experience with alternatives. I think a hybrid OOP/FP approach (i.e. Scala) can actually work really well, though I don't know if there is a perfect reference implementation.
samatman 13y ago
Especially from a Clojurian's perspective, the tool to watch in this realm is Datomic. It's a fundamentally different approach to databases, based on the functional paradigm, and should it succeed in massive scalable situations (which I suspect it will), it will be a triumphant validation of the particular functional/immutable paradigm Rich Hickey has been promoting.
stonemetal 13y ago
The data might be very complex, the algorithms too, but the code itself probably has much less branches, corner cases, ifs, and other PM-added mess). Being able to do complex stuff with less mess sounds like a big win to me. Current users of FP in industry tend to be in the financial sector(though a quick check of haskell in industry shows several CAD users too). Though I have to agree with you, I haven't seen a really convincing case study yet. For me at least it has wiggled its eyebrows and said look over there convincingly enough for me to take a look.
- jhaywood 13y ago
  I guess nobody ever thinks of Excel in these cases? I've heard it's used sometimes for calculations. It doesn't need to do destructive updates to intermediate values.
  - taeric 13y ago
    I think the argument would be that, though Excel is awesome for small data sets and so validates that it is indeed a great way to think about things at a level, it does not scale well. Indeed, one of the first things people suggest is to run away from large scale solutions that were done in a spreadsheet.
    - dragonwriter 13y ago
      Excel strengths come from the fact that the main mode of operation is generally declarative. Excel's weaknesses for use in large scale systems largely come from the fact that it isn't easily maintainable because, in the same main mode of operation, the actual code is hidden in cells that need to be accessed individually (in terms of usability for someone trying to maintain it, its almost like having one line of code per source file, since you have to open each cell to bring the code in it into the "editor".) The most common way to circumvent the problem posed by the second feature in Excel is to resort to coding in an imperative language, which negates the benefit of the first. FP languages share the first feature, but not the second.
wtetzner 13y ago
Jane Street Capital uses OCaml for their trading system. Yaron Minsky explained that one of the main benefits of it was that people could read and understand the code much better than the other languages they tried (including C#). Yaron's talk: https://www.youtube.com/watch?v=hKcOkWzj0_s https://www.youtube.com/watch?v=hKcOkWzj0_s

by gbog 13y ago

rybosome 13y ago

The thing that bothers me about this attitude is that it discourages considering alternatives. I've had a blog post on this stewing for awhile, but the gist of my counter argument is that it is a common human condition to feel that the current level of technology is sufficient - people have made that argument countless times in the face of progress.

jafaku 13y ago
He didn't say it's sufficient, he said OOP can do the work (lots of examples) while FP can't (he asked for examples, since we don't have any).
joe_the_user 13y ago
Or perhaps it encourages think about alternative-alternatives. Functional programming has been presented as the alternative to OOP for a looong time now and the indications are that it just isn't to replace it ever. OOP is a paradigm that does work for gluing huge piles of flawed-but-useful code together. And OOP indeed has lurid flaws to it on multiple levels (the ambiguity concerning what "inheritance" is supposed to mean is one of many ridiculousnesses). Something that replaces OOP would need to have SOME winning combination of gluing hunks-of-together so you didn't have to start from scratch and being-so-powerful-but-understandable that medium skill-level programmers could replace the junk reasonably painlessly. If we acknowledge FP isn't going to be that paradigm, then we can start searching for a different one.
- rybosome 13y ago
  Interesting; I am amenable to that idea, but don't have any experience with alternatives. I think a hybrid OOP/FP approach (i.e. Scala) can actually work really well, though I don't know if there is a perfect reference implementation.

samatman 13y ago

Especially from a Clojurian's perspective, the tool to watch in this realm is Datomic. It's a fundamentally different approach to databases, based on the functional paradigm, and should it succeed in massive scalable situations (which I suspect it will), it will be a triumphant validation of the particular functional/immutable paradigm Rich Hickey has been promoting.

stonemetal 13y ago

The data might be very complex, the algorithms too, but the code itself probably has much less branches, corner cases, ifs, and other PM-added mess). Being able to do complex stuff with less mess sounds like a big win to me. Current users of FP in industry tend to be in the financial sector(though a quick check of haskell in industry shows several CAD users too). Though I have to agree with you, I haven't seen a really convincing case study yet. For me at least it has wiggled its eyebrows and said look over there convincingly enough for me to take a look.

jhaywood 13y ago
I guess nobody ever thinks of Excel in these cases? I've heard it's used sometimes for calculations. It doesn't need to do destructive updates to intermediate values.
- taeric 13y ago
  I think the argument would be that, though Excel is awesome for small data sets and so validates that it is indeed a great way to think about things at a level, it does not scale well. Indeed, one of the first things people suggest is to run away from large scale solutions that were done in a spreadsheet.
  - dragonwriter 13y ago
    Excel strengths come from the fact that the main mode of operation is generally declarative. Excel's weaknesses for use in large scale systems largely come from the fact that it isn't easily maintainable because, in the same main mode of operation, the actual code is hidden in cells that need to be accessed individually (in terms of usability for someone trying to maintain it, its almost like having one line of code per source file, since you have to open each cell to bring the code in it into the "editor".) The most common way to circumvent the problem posed by the second feature in Excel is to resort to coding in an imperative language, which negates the benefit of the first. FP languages share the first feature, but not the second.

wtetzner 13y ago

Jane Street Capital uses OCaml for their trading system. Yaron Minsky explained that one of the main benefits of it was that people could read and understand the code much better than the other languages they tried (including C#). Yaron's talk: https://www.youtube.com/watch?v=hKcOkWzj0_s https://www.youtube.com/watch?v=hKcOkWzj0_s