1. 8

    The article seems like a trillion dollar disaster itself, wasting a good title. There’s quite lot of craptalk throughout. Also appeals to authorities spread across the post… Seriously think that Linus Torvalds doesn’t do any mistakes and him avoiding OOP would not be one such mistake? Research institutions favored over industry practices? What the heck dude? You still trust everybody after this mess?

    Then there’s the bull about functional programming as a remedy in the middle. When you bring it over to mean coding in Javascript, it becomes the same turd with the label in the can replaced by an another. Yeaah.. Sell it to us!

    Warning you ahead: There’s the classical “complexity is bad” -talk mixed in. Complexity down. Ohwait what is meant with complexity here? The guy/gal tells it’s shared mutable state and errorneous abstraction, low signal-to-noise. All those things common in OOP. Maybe the worse problem you have would be that nothing you ever wrote is actually correct? People find bugs in your stuff decades afterwards, and others add their own bugs in! Things have to get quite complex to actually do the things you want them to do and there’s nothing you can do about that. Terabytes of memory in your system. How would you expect that your software could even be simple in the same way it was when you had 32 kilobytes of available memory?

    And this dogma about mutable state.. Little they do know that latest theorem provers like Idris2 are ok with mutable state and handle it well because of progression into affine/linear logic, and you don’t have problems with reasoning over mutable state with that tool. Then there’s that thing “Separation logic” for reasoning about traditional programs. Mutability or parallellism in OOP aren’t the things that make it bad. They’re merely just things that OOP doesn’t do jack shit about. It’s completely ineffective in handling those things, just like the “FP” is, it’s just that with “FP” you aren’t even able to do anything with mutable state so the problem’s solved?

    All that incense over message passing is old stuff. It was there when I started coding. Too bad it doesn’t work because messages really provide very little in terms of what you can predict about program’s behavior, often things go over multiple steps before they accept the same message again, meanwhile everything can go wrong. Even Haskell doesn’t help because you still do typo or forget precedence rules somewhere such that it passes the type checker without being noticed and introduces a new case that isn’t catched by any of your seven test suites because it’s a new way to get it wrong.

    There’s lot of things you can argue spread around there. Encapsulation as global state? OOP modeling real world through its inheritance? All of those factories and MonaLisaProviders being complexity? Bit of intertextual references to classical texts (kingdom of nouns, that was fun to read years ago).

    Too bad(good?) to the author of that post. People are going to get back into dragging them to your level and arguing with you, just refuting what you say. Unit testing must be great because we test things in real world to make sure they qualify! It can’t be bad with coding?! That time surely isn’t wasted like you claim. Controlling your private parts is important so why not private/protected/public is important too. Surely packing things together must be an abstraction and that’s necessary to write software at all.

    Meanwhile, your whole industry is a fraud in the progress. You even already know it and feel something that your peers call “impostor syndrome”. Sigh.

    Nothing of OOP does anything because it attacks the false problem in the first place just like many other software solutions do. You blame yourself about missing targets but you aren’t even aiming at the target when you press fire. Things such as static or dynamic doesn’t mean anything at all. You should foremost care about what you know with certainty of program’s behavior before it runs.

    The history is indeed repeating itself, and this dude is repeating it. This time with FP.

    1. 1

      Nothing of OOP does anything because it attacks the false problem in the first place just like many other software solutions do. You blame yourself about missing targets but you aren’t even aiming at the target when you press fire.

      Indeed. A problem well-stated is half solved. We did not spend enough time on investigating what is the real problem, and what actually makes the problem hard, but spend far too much time on arguing arbitary solution. Here are some problems I find fascinating:

      • How to make developer perceive the global architecture when we only have a dark screen of 80 characters scrolling over thousands of files?
      • How to make developer perceive what is actually going on when we only have “console.log” as a tiny torch lighting up the cave?
      • If somewhat mutable state is inevitable, how to make “variable” or something with “identity” easier for human cognition? Is mutability the problem, or we are simply having too many states, especially too many ungrounded, local, transient states?
      • It is well-known attention is single threaded, and developer can only do informal reasoning with attention. How to make software source code read like “single threaded” but actually exploit parallesim in the runtime?
      • Why re-use is more successful in certain area, but not in other? Is it because there is a missing common ground to make the inter-changable parts economy flourish?

      I don’t know exactly when people invent OOP or FP, what kind of problem do they have in mind. It will be more constructive when we can start discussion from the problem.

    1. 2

      Would be nice to come up some concrete algorithm to calculate the “Code Cognitive Load”. It is already well-known, language and tool designer need to incorporate human-computer-interface knowledge to improve their design. There are couple of communities and conferences working on this front: