5 ms·

As one of the novices just trying to allocate my time, I'm constantly trying to understand whether, say, it's worth really understanding C++ at a deep level, or

As one of the novices just trying to allocate my time, I'm constantly trying to understand whether, say, it's worth really understanding C++ at a deep level, or whether I should just try to learn Rust. Think about languages as tools: focus on the tools you need to use. Your career will be long and there will be plenty of time to branch out, but you have very limited time for mastery, so you should master the tools you use often. All too often, I find this devolves into me scouring the internet for "C++ is ok but the ownership model is so primitive that I would never start a new project in it" and comparing it to "My problem with Rust is that it's still such a nascent language I can't trust it to have the libraries I need". Who are these people, and why are they saying these things? Are their gripes relevant to me? I have no way to know! Honestly, just pick one and run with it. Part of becoming an experienced programmer is developing your own heuristics for how to pick the right tool for the right job and how to read this type of discussion, and a big part of that is building up both wins and losses to train your intuition. When they say "OOP is now considered an anti-pattern, most companies are moving towards reactive FP", do they really mean "I work at snapchat and the ads group I work for is moving away from OOP. My friend at amazon said he's doing the same thing"? If it's an internet forum and you don't see references or citations, it's probably safe to assume it's the latter. They might still be right, but not verifiably so.

AnimalMuppet 6y ago
They're right, and they're wrong. OOP is considered an anti-pattern... by at least someone, somewhere. OOP is also considered The One Right Way, by someone, somewhere. Is there a consensus one way or the other? Not only no, but $PROFANITY no. The person who claims that there is... yeah, consider them a blowhard who is out of touch with reality.
exclusiv 6y ago
Seriously. From what I've seen, OOP haters either write shit code in general or they're working on something where FP makes sense and they don't actually mention that when they shit on OOP. Lot's of FP "fans" just writing procedural code with a terrible mess of functions and no architecture as well. Quite the mixed bag. But they're very passionate and believe in talking about FP as the one true way. I suppose most things go through a phase like that though. But if you've been around long enough, you don't get too jazzed about any one thing.
- JMTQp8lwXL 6y ago
  As someone who is more of an FP fan (though certainly not an OOP hater, just indifferent about OO)-- I would appreciate articles on what the tradeoffs of FP. It would better articulate what sorts of problems are conducive to one style vs another.
  - collyw 6y ago
    I am a mixed paradigm language person Python and previously Perl. I like OOP for higher level organization and functional for smaller details. I would find it difficult to know how to start a moderate sized project in a purely functional style.
    - tome 6y ago
      > I would find it difficult to know how to start a moderate sized project in a purely functional style. You don't start a moderate-sized project! You start a small project and then grow it to become moderate.
  - thu2111 6y ago
    FP isn't well defined so these sorts of debates sometimes turn into a no true scotsman fallacy. For example laziness is pretty much agreed now to be a bad idea even though it's at the core of Haskell, the flagbearer for FP languages. There are some other more subtle issues. This article goes in depth into some less well known ones related to data structure efficiency. https://jaxenter.com/disadvantages-of-purely-functional-programming-126776.html https://jaxenter.com/disadvantages-of-purely-functional-prog... The insistence on immutability comes from FP being closer to mathematics. But, computers aren't actually abstract equation solving machines. They are machines that spend much of their time copying data between mutable storage cells of various kinds. So, a lot of very important and common algorithms require mutability and don't have natural, efficient immutable equivalents. But FP requires you to be immutable, so, you can end up paying a heavy efficiency tax. Not many pure FP game engines out there! Even when there are problems that are theoretically pure functions, like a compiler, real world compilers like LLVM or Graal are not functional, because you give up too much performance by doing that. Functional problems still benefit from not gratuitously copying data all over the place, mutating graphs in place, etc. Cache locality is too powerful an optimisation to give up. OOP is fundamentally a paradigm about modelling a mutable world. It turns out that most software isn't implementing a pure function but rather a reduced model of reality, so, that makes it highly appropriate. Almost any database for example is a mutable model of reality (even if a fictional one like in a game). OOP languages have weak mutability controls, but fundamentally, a mutable variable is more "powerful" in some sense than an immutable one. FP languages are often rather poor on things that OOP emphasises heavily, like encapsulation. FP gives you data structures and functions. Namespaces, usually. Beyond that it gets ropey. The core insight of OOP is that you often want to bind code to data very strongly, because that lets you really control the scope of functions much more easily. This in turn makes it easier to scale up teams, as people can more easily own their little corner of the world. OOP languages like Java have a lot of visibility control features, and are still getting more even in recent years. Inheritance (subtyping) gets shit on a lot these days by the kids, but it's a very natural paradigm to model certain kinds of problems, for example it makes a lot of sense for GUI toolkits. Game engines also get a lot of good mileage out of it. Pure composition using layers is less effective, partly because it translates to worse machine code. Virtual method dispatch is highly optimised and thus a relatively efficient way to share and customise code. Interface dispatch is less efficient and proxying calls to composed inner objects, even less so again. FP languages often end up trying to bolt on features to the functional paradigm that are natural fits in imperative OOP-oriented languages. For example, FP languages handle errors with a Maybe type and monads. OOP languages can do this too, but they can also do exceptions which are often a more natural way to handle errors, with various benefits. Strictly this is an imperative vs FP thing not an OOP vs FP thing. There are some other issues that are less fundamental. FP languages are part of a family tree, and for whatever reason that family tree loves obscure syntax with lots of operator overloading. There are many OOP languages that are designed by industrial designers for usability in large teams, so they restrict how much of a mess you can make. FP languages are generally research languages that have little usage in industry, so FP code can often end up being very hard to read with a lot of bizarre custom operators. You could make a clear, easy to read and abuse-resistant FP language but nobody does.

AnimalMuppet 6y ago

They're right, and they're wrong. OOP is considered an anti-pattern... by at least someone, somewhere. OOP is also considered The One Right Way, by someone, somewhere. Is there a consensus one way or the other? Not only no, but $PROFANITY no. The person who claims that there is... yeah, consider them a blowhard who is out of touch with reality.

exclusiv 6y ago

Seriously. From what I've seen, OOP haters either write shit code in general or they're working on something where FP makes sense and they don't actually mention that when they shit on OOP. Lot's of FP "fans" just writing procedural code with a terrible mess of functions and no architecture as well. Quite the mixed bag. But they're very passionate and believe in talking about FP as the one true way. I suppose most things go through a phase like that though. But if you've been around long enough, you don't get too jazzed about any one thing.

JMTQp8lwXL 6y ago
As someone who is more of an FP fan (though certainly not an OOP hater, just indifferent about OO)-- I would appreciate articles on what the tradeoffs of FP. It would better articulate what sorts of problems are conducive to one style vs another.
- collyw 6y ago
  I am a mixed paradigm language person Python and previously Perl. I like OOP for higher level organization and functional for smaller details. I would find it difficult to know how to start a moderate sized project in a purely functional style.
  - tome 6y ago
    > I would find it difficult to know how to start a moderate sized project in a purely functional style. You don't start a moderate-sized project! You start a small project and then grow it to become moderate.
- thu2111 6y ago
  FP isn't well defined so these sorts of debates sometimes turn into a no true scotsman fallacy. For example laziness is pretty much agreed now to be a bad idea even though it's at the core of Haskell, the flagbearer for FP languages. There are some other more subtle issues. This article goes in depth into some less well known ones related to data structure efficiency. https://jaxenter.com/disadvantages-of-purely-functional-programming-126776.html https://jaxenter.com/disadvantages-of-purely-functional-prog... The insistence on immutability comes from FP being closer to mathematics. But, computers aren't actually abstract equation solving machines. They are machines that spend much of their time copying data between mutable storage cells of various kinds. So, a lot of very important and common algorithms require mutability and don't have natural, efficient immutable equivalents. But FP requires you to be immutable, so, you can end up paying a heavy efficiency tax. Not many pure FP game engines out there! Even when there are problems that are theoretically pure functions, like a compiler, real world compilers like LLVM or Graal are not functional, because you give up too much performance by doing that. Functional problems still benefit from not gratuitously copying data all over the place, mutating graphs in place, etc. Cache locality is too powerful an optimisation to give up. OOP is fundamentally a paradigm about modelling a mutable world. It turns out that most software isn't implementing a pure function but rather a reduced model of reality, so, that makes it highly appropriate. Almost any database for example is a mutable model of reality (even if a fictional one like in a game). OOP languages have weak mutability controls, but fundamentally, a mutable variable is more "powerful" in some sense than an immutable one. FP languages are often rather poor on things that OOP emphasises heavily, like encapsulation. FP gives you data structures and functions. Namespaces, usually. Beyond that it gets ropey. The core insight of OOP is that you often want to bind code to data very strongly, because that lets you really control the scope of functions much more easily. This in turn makes it easier to scale up teams, as people can more easily own their little corner of the world. OOP languages like Java have a lot of visibility control features, and are still getting more even in recent years. Inheritance (subtyping) gets shit on a lot these days by the kids, but it's a very natural paradigm to model certain kinds of problems, for example it makes a lot of sense for GUI toolkits. Game engines also get a lot of good mileage out of it. Pure composition using layers is less effective, partly because it translates to worse machine code. Virtual method dispatch is highly optimised and thus a relatively efficient way to share and customise code. Interface dispatch is less efficient and proxying calls to composed inner objects, even less so again. FP languages often end up trying to bolt on features to the functional paradigm that are natural fits in imperative OOP-oriented languages. For example, FP languages handle errors with a Maybe type and monads. OOP languages can do this too, but they can also do exceptions which are often a more natural way to handle errors, with various benefits. Strictly this is an imperative vs FP thing not an OOP vs FP thing. There are some other issues that are less fundamental. FP languages are part of a family tree, and for whatever reason that family tree loves obscure syntax with lots of operator overloading. There are many OOP languages that are designed by industrial designers for usability in large teams, so they restrict how much of a mess you can make. FP languages are generally research languages that have little usage in industry, so FP code can often end up being very hard to read with a lot of bizarre custom operators. You could make a clear, easy to read and abuse-resistant FP language but nobody does.