4 ms·

People spend way too much time arguing about this.. If you're a good programmer u will be able to do excellent maintainable work in any language you're experien

People spend way too much time arguing about this.. If you're a good programmer u will be able to do excellent maintainable work in any language you're experienced with. If you're bad you will make a mess in any language. It'd be like carpenters saying "spruce is terrible if you make anything from spruce its fucked, you have to use oak." ; A good carpenter will be able to make something amazing from spruce. Like carpentry, metalworking etc. the quality of the product of programming is heavily based on the skill of the tradesman.

ttz 5y ago
Yeah pretty much this. If a paradigm (whether functional, OOP, or whatever label makes you feel better) isn't working for you when it has worked for many others, maybe it's not because the paradigm sucks... it's because you might just suck at the paradigm? Obviously there are cases where things were pigeonholed into the wrong paradigm for the job. Then it's a case of the person choosing the paradigm sucking at choosing the paradigm. Whatever happened to personal responsibility?
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- solraph 5y ago
  Absolutely. I really want to love FP style programming, but I just can't get it to gel in my head. I'm totally on board with the concepts of side effect free programming, minimising state, passing around functions as parameters, etc... But I struggle with reading it, and I struggle with writing it, and I struggle to build a conceptual framework of how FP style components fit together. I've been banging my head against the FP wall for _years_ now, and I still can't seem get a level of fluency that where I'm comfortable using it regularly. That doesn't mean FP sucks, it just means my brain isn't wired that way.
_fullpint 5y ago
Sure your first proposition is true. But many people realize you more than likely will not have a team of good to great programmers. OOP is a massive foot gun for many programmers who are okay at best. And that effect is exponential as the project and their team grows.
- marcos100 5y ago
  What isn't a footgun in the terms that you declared? I believe people dislike OOP because the vast majority of code is written using OOP. If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP.
  - _fullpint 5y ago
    >> What isn't a footgun in the terms that you declared? There are definite degrees to this. But something like FP that declares f(x: X) => Y, instead of something like OOP where given context: x: X, y: Y and f() => void (where there is an effect on y) those are massively different scopes of problems. It's not that you cannot do the previous in the latter, but that people -- especially those that are inexperienced and haven't dealt with the hell of a stateful programming -- routinely reach for as a solution to their problem. >> I believe people dislike OOP because the vast majority of code is written using OOP. Why do you believe that's the reason why? There's no implication here -- just a genuine curiosity as to how that was the conclusion. >> If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP. DOP especially given one with a static language forces you to move from one type to your next to solve your problem, and handle your edge cases. From experience DOP and FP can be intimidating, but usually end up being easier, and the development time, along with the time to stability are hugely reduced -- because it's inherently dumb.
    - marcos100 5y ago
      So, just to clarify before people think I'm an OOP advocate and it's perfect, I don't, but I think it has it's place. > There are definite degrees to this. Agree. The question is, does OOP leads to more buggy code? Maybe yes, so we ban OOP? Because that's the sentiment I get whenever someone is against it. In your example, is it ok allocating a new object every time? If you can't afford to do it, what do you do? > Why do you believe that's the reason why? I think in terms of proportions. For example, if you have 80% of all code written is OOP, chances that you'll find a bad OOP is greater than finding bad code in any other paradigm. What if people learn programming using FP or DOP? There would be less buggy code? I don't know, but I think in the end, OOP would become the popular choice because, in my opinion, it fits very well the way we think about our world and we would end having this same conversation.
wvenable 5y ago
Experience is not highly valued in articles about programming but often it comes down to that. I'm using tools with roughly the same level of expressiveness as I have for the last 20 years but I develop much better code now. I've been guilty of over-abstraction and I've been guilty of under-abstraction. There's a lot of blaming the tool for what amounts to lack of experience. Everyone has lacked that experience at some point in their career.
deltaonefour 5y ago
You don't understand. This is not what FP programmers are arguing about. What FP programmers are arguing about is that all code becomes shit if you do OOP. It doesn't matter how good you are. They argue that if you do FP your code is much less likely (note the word likely) to be shit. The analogy to carpentry or craftsmanship is bad. Programming is about managing complexity to a degree no one can fully hold in their head or understand. You can't just be a "master" craftsman and write an entire OS with zero technical debt. The argument here is that if you use FP over OOP your code will have magnitudes less technical debt.
- everyone 5y ago
  It sounds like you don't understand about various crafts. To me they are a quite analogous to programming. Also, code has barely changed at all since C. It's all just some variables, loops, flow control, some math operations and doing stuff with strings sometimes. One can write functionally in an OO language. No paradigm or design pattern or whatever will save you from making a mess. For me, the more experienced I've become, the less those things matter.
  - deltaonefour 5y ago
    > It sounds like you don't understand about various crafts. To me they are a quite analogous to programming. I understand every craft. They are analogous in the simple minded way you're thinking about it. However complexity in these crafts does not rise to the heights like the way it does in programming. That is the key difference. >No paradigm or design pattern or whatever will save you from making a mess This is fundamentally backwards. The FP style saves you from all errors related to mutation. This single statement already proves you wrong. You can't mutate a variable so that's one mess literally taken off the table. There are patterns that can provably prevent errors from happening and you can create languages that strictly enforce certain patterns. Elm for example, cannot have runtime errors. The language strictly prevents that "mess" from happening. Outside of strictly enforced patterns the FP pattern promotes better organization. You can still make a mess. But you are less likely to make a mess. Additionally for extremely large programs the proportion of technical debt will be significantly less for an FP styled program than an OOP styled program. See below for one instance of this. http://wiki.haskell.org/Why_Haskell_just_works http://wiki.haskell.org/Why_Haskell_just_works >For me, the more experienced I've become, the less those things matter. I've found that people who brag about experience doesn't make them smart or good programmers. You have limited intelligence and no matter your level of experience there are just design mistakes you make all the time in extremely large programs. Technical debt is an unsolved issue. Though the claim here is that FP programs tend to have less debt than non-FP programs. The keyword is "tend" as there are exceptions but the generality is mostly true.

ttz 5y ago

Yeah pretty much this. If a paradigm (whether functional, OOP, or whatever label makes you feel better) isn't working for you when it has worked for many others, maybe it's not because the paradigm sucks... it's because you might just suck at the paradigm? Obviously there are cases where things were pigeonholed into the wrong paradigm for the job. Then it's a case of the person choosing the paradigm sucking at choosing the paradigm. Whatever happened to personal responsibility?

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
solraph 5y ago
Absolutely. I really want to love FP style programming, but I just can't get it to gel in my head. I'm totally on board with the concepts of side effect free programming, minimising state, passing around functions as parameters, etc... But I struggle with reading it, and I struggle with writing it, and I struggle to build a conceptual framework of how FP style components fit together. I've been banging my head against the FP wall for _years_ now, and I still can't seem get a level of fluency that where I'm comfortable using it regularly. That doesn't mean FP sucks, it just means my brain isn't wired that way.

_fullpint 5y ago

Sure your first proposition is true. But many people realize you more than likely will not have a team of good to great programmers. OOP is a massive foot gun for many programmers who are okay at best. And that effect is exponential as the project and their team grows.

marcos100 5y ago
What isn't a footgun in the terms that you declared? I believe people dislike OOP because the vast majority of code is written using OOP. If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP.
- _fullpint 5y ago
  >> What isn't a footgun in the terms that you declared? There are definite degrees to this. But something like FP that declares f(x: X) => Y, instead of something like OOP where given context: x: X, y: Y and f() => void (where there is an effect on y) those are massively different scopes of problems. It's not that you cannot do the previous in the latter, but that people -- especially those that are inexperienced and haven't dealt with the hell of a stateful programming -- routinely reach for as a solution to their problem. >> I believe people dislike OOP because the vast majority of code is written using OOP. Why do you believe that's the reason why? There's no implication here -- just a genuine curiosity as to how that was the conclusion. >> If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP. DOP especially given one with a static language forces you to move from one type to your next to solve your problem, and handle your edge cases. From experience DOP and FP can be intimidating, but usually end up being easier, and the development time, along with the time to stability are hugely reduced -- because it's inherently dumb.
  - marcos100 5y ago
    So, just to clarify before people think I'm an OOP advocate and it's perfect, I don't, but I think it has it's place. > There are definite degrees to this. Agree. The question is, does OOP leads to more buggy code? Maybe yes, so we ban OOP? Because that's the sentiment I get whenever someone is against it. In your example, is it ok allocating a new object every time? If you can't afford to do it, what do you do? > Why do you believe that's the reason why? I think in terms of proportions. For example, if you have 80% of all code written is OOP, chances that you'll find a bad OOP is greater than finding bad code in any other paradigm. What if people learn programming using FP or DOP? There would be less buggy code? I don't know, but I think in the end, OOP would become the popular choice because, in my opinion, it fits very well the way we think about our world and we would end having this same conversation.

wvenable 5y ago

Experience is not highly valued in articles about programming but often it comes down to that. I'm using tools with roughly the same level of expressiveness as I have for the last 20 years but I develop much better code now. I've been guilty of over-abstraction and I've been guilty of under-abstraction. There's a lot of blaming the tool for what amounts to lack of experience. Everyone has lacked that experience at some point in their career.

deltaonefour 5y ago

You don't understand. This is not what FP programmers are arguing about. What FP programmers are arguing about is that all code becomes shit if you do OOP. It doesn't matter how good you are. They argue that if you do FP your code is much less likely (note the word likely) to be shit. The analogy to carpentry or craftsmanship is bad. Programming is about managing complexity to a degree no one can fully hold in their head or understand. You can't just be a "master" craftsman and write an entire OS with zero technical debt. The argument here is that if you use FP over OOP your code will have magnitudes less technical debt.

everyone 5y ago
It sounds like you don't understand about various crafts. To me they are a quite analogous to programming. Also, code has barely changed at all since C. It's all just some variables, loops, flow control, some math operations and doing stuff with strings sometimes. One can write functionally in an OO language. No paradigm or design pattern or whatever will save you from making a mess. For me, the more experienced I've become, the less those things matter.
- deltaonefour 5y ago
  > It sounds like you don't understand about various crafts. To me they are a quite analogous to programming. I understand every craft. They are analogous in the simple minded way you're thinking about it. However complexity in these crafts does not rise to the heights like the way it does in programming. That is the key difference. >No paradigm or design pattern or whatever will save you from making a mess This is fundamentally backwards. The FP style saves you from all errors related to mutation. This single statement already proves you wrong. You can't mutate a variable so that's one mess literally taken off the table. There are patterns that can provably prevent errors from happening and you can create languages that strictly enforce certain patterns. Elm for example, cannot have runtime errors. The language strictly prevents that "mess" from happening. Outside of strictly enforced patterns the FP pattern promotes better organization. You can still make a mess. But you are less likely to make a mess. Additionally for extremely large programs the proportion of technical debt will be significantly less for an FP styled program than an OOP styled program. See below for one instance of this. http://wiki.haskell.org/Why_Haskell_just_works http://wiki.haskell.org/Why_Haskell_just_works >For me, the more experienced I've become, the less those things matter. I've found that people who brag about experience doesn't make them smart or good programmers. You have limited intelligence and no matter your level of experience there are just design mistakes you make all the time in extremely large programs. Technical debt is an unsolved issue. Though the claim here is that FP programs tend to have less debt than non-FP programs. The keyword is "tend" as there are exceptions but the generality is mostly true.