5 ms·

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD a

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms -- are your symbolic transformations what is desired? In practice, pure FP is the closest I've seen to stuff that "just works". While FP can be a huge pain in the ass mentally, it beats the heck out of the spaghetti dependency issues in OOP. [insert long discussion here about whether pure FP can actually scale in a large organization]

taeric 13y ago
Is it irony that the post right below this is complaining about Cabal and "dependency hell?"
- platz 13y ago
  I think the package system needs work, yes, but I'm not sure this is the fault of "Haskell the Language". Although I've read some blogs that complained that ML gets this right, and Haskell makes it harder with it's typeclasses
  - taeric 13y ago
    I think for a lot of folks, the differences between languages and the surrounding toolset is very diminished. That is, there seems little gain in making this distinction.
- nightski 13y ago
  No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).
  - taeric 13y ago
    Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modification. Whereas with many dynamic solutions, this is not the case.
    - deleted 13y ago
      [deleted]
    - nightski 13y ago
      It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.
      - taeric 13y ago
        I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
        tel 13y ago
eru 13y ago
> [insert long discussion here about whether pure FP can actually scale in a large organization] It scales for us at Standard Chartered.
splike 13y ago
But wait, don't we need to compare like with like here? Haskell is a break from imperative programming, not OOP. Could it be that functional programming just hasnt had enough industry time to develop an overhead concept that could be compared to what OOP did to imperative languages?
platz 13y ago
But is there also some selection bias at play here? Typically you don't see a lot of GUI programs or games written in pure FP; so far, I haven't been reading much that exols the virtues of FP in those domains. http://prog21.dadgum.com/138.html http://prog21.dadgum.com/138.html "If you want to be on the cutting edge of functional programming research, it's easy. Pick something that looks like a poor match for state-free code, like a video game, and start working on it." Will I have to write a FP "white paper" to make a game in FP?
- cgh 13y ago
  No, you can just watch this talk by John Carmack as he extols the virtues of Haskell for game programming: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-on-haskell/ http://functionaltalks.org/2013/08/26/john-carmack-thoughts-...
  - MedDev 13y ago
    The problem I have with this is Carmack is in the top 0.01% of developers so of course writing a game in Haskell is going to be within his grasp. For the rest of us it's a huge exercise in mental gymnastics. I've written a few visualizations for data using Gloss (http://gloss.ouroborus.net/ http://gloss.ouroborus.net/) with Haskell and although it does "just work" when it does compile understanding how to manage state in a pure environment is an uphill learning experience to say the least.
    - ademarre 13y ago
      Many medical techniques were probably pioneered by specialists and later adopted by general practitioners. The perceived difficulty of mastering pure functional programming for practical work might be a result of bias in the typical CS education experiences. That might shift as the value of pure functional programming gets more universally recognized.
    - chongli 13y ago
      For the rest of us it's a huge exercise in mental gymnastics. I've thought about this a lot and honestly, I think this is a good thing. Languages which are much less strict about types and mutation require huge mental gymnastics too, they just don't tell you about it. They let you happily continue on your merry way until some time at a later date you realize your program is a giant ball of mud and you have no idea how to change things without breaking it. Haskell forces you to deal with the hard problem of state up front in exchange for having a clear, maintainable program down the road.

taeric 13y ago

Is it irony that the post right below this is complaining about Cabal and "dependency hell?"

platz 13y ago
I think the package system needs work, yes, but I'm not sure this is the fault of "Haskell the Language". Although I've read some blogs that complained that ML gets this right, and Haskell makes it harder with it's typeclasses
- taeric 13y ago
  I think for a lot of folks, the differences between languages and the surrounding toolset is very diminished. That is, there seems little gain in making this distinction.
nightski 13y ago
No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).
- taeric 13y ago
  Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modification. Whereas with many dynamic solutions, this is not the case.
  - deleted 13y ago
    [deleted]
  - nightski 13y ago
    It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The problem is that GHC will not allow you to depend on two packages which themselves depend on different versions of the same package. Once this is fixed, along with sandboxing, will eliminate the vast majority of the cabal hell problem.
    - taeric 13y ago
      I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works. The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant. Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
      - tel 13y ago

eru 13y ago

> [insert long discussion here about whether pure FP can actually scale in a large organization] It scales for us at Standard Chartered.

splike 13y ago

But wait, don't we need to compare like with like here? Haskell is a break from imperative programming, not OOP. Could it be that functional programming just hasnt had enough industry time to develop an overhead concept that could be compared to what OOP did to imperative languages?

platz 13y ago

But is there also some selection bias at play here? Typically you don't see a lot of GUI programs or games written in pure FP; so far, I haven't been reading much that exols the virtues of FP in those domains. http://prog21.dadgum.com/138.html http://prog21.dadgum.com/138.html "If you want to be on the cutting edge of functional programming research, it's easy. Pick something that looks like a poor match for state-free code, like a video game, and start working on it." Will I have to write a FP "white paper" to make a game in FP?

cgh 13y ago
No, you can just watch this talk by John Carmack as he extols the virtues of Haskell for game programming: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-on-haskell/ http://functionaltalks.org/2013/08/26/john-carmack-thoughts-...
- MedDev 13y ago
  The problem I have with this is Carmack is in the top 0.01% of developers so of course writing a game in Haskell is going to be within his grasp. For the rest of us it's a huge exercise in mental gymnastics. I've written a few visualizations for data using Gloss (http://gloss.ouroborus.net/ http://gloss.ouroborus.net/) with Haskell and although it does "just work" when it does compile understanding how to manage state in a pure environment is an uphill learning experience to say the least.
  - ademarre 13y ago
    Many medical techniques were probably pioneered by specialists and later adopted by general practitioners. The perceived difficulty of mastering pure functional programming for practical work might be a result of bias in the typical CS education experiences. That might shift as the value of pure functional programming gets more universally recognized.
  - chongli 13y ago
    For the rest of us it's a huge exercise in mental gymnastics. I've thought about this a lot and honestly, I think this is a good thing. Languages which are much less strict about types and mutation require huge mental gymnastics too, they just don't tell you about it. They let you happily continue on your merry way until some time at a later date you realize your program is a giant ball of mud and you have no idea how to change things without breaking it. Haskell forces you to deal with the hard problem of state up front in exchange for having a clear, maintainable program down the road.