Goodbye, Object Oriented Programming

Object Oriented Programming simulates the restrained reasoning capacity of the real world. This is done by weaving state into every conceivable unit of computation. The result is a universal and inescapable notion of identity. It's a state conspiracy! Sometimes you are actually interacting with the real world and this is an appropriate constraint. That is only because, in the real real world, these things are pervasively intertwined. Right down to the smallest phenomena we've been able to observe. We can't actually take them apart except for in our minds. To do so is a very old idea, pervasively apparent in western thought, called platonic realism. I internalized it as an unknown known at some point. I imagine that's just how people did it before someone as smart as Plato was able to articulate it. It's sort of the doorway to abstract thought. Most mathematically inclined people have ventured into the depths of the world it conceals. It's necessary in order to properly understand the concept of a "value". When these people first start to program they rely heavily on expressions and functions. They tend to atomize complex values with simple structs. They don't know they're doing it but they're writing "functional" programs. It might be more apparent if we just called them mathematical or algebraic programs. They demonstrate a preference for referential transparency without knowing what it is. Much of their code is outright stateless. They're hesitant to use a "var" as anything but a "let". Many seem to immediately grasp the simplicity and generality of recursion. They have to have it pried away from them like it's a dangerous recreational drug. That recursion is not "optimal" is simply presented as an engineering reality. Always intent on incremental improvement they diligently internalize these "optimal" representations utilizing loops and state. They're tricked into feeling they've acquired a worthwhile skill; They don't know they're doing what a compiler ought to. They learn to reserve the truly optimal representations for their minds eye. With the desire to utilize their new "skill" they move towards external representations that could only be considered "optimal" by an unconscious machine. All of this damage is done in the earliest stages of learning; Probably before they've even attempted any significant programmatic interaction with the real world. That's when everything gets worse. They start trying to coordinate too much state and they can't cope. They're told they need these object things. Everything seems to get easier: Sockets, Widgets and even the Lists that had been such a struggle to use before. They choke down the declaration syntax and hastily strap their newfangled constructor and destructor gadgets onto their toolbelts. These are excellent tools for arbitrating the abstract world and the real one. The ability to hook into their creation and destruction provides abstract objects with a canonical state-of-existence. This is necessary to fully simulate the identity possessed by real objects. For the purposes that they've learned them, objects are immediately and overwhelmingly useful. They come to appreciate the clarity of the method invocation syntax for manipulating state. They're right to do so. The functional languages themselves even sort of "do" it. Tragically with their most fundamental notions of computation already brutally violated by the state conspiracy, they're vulnerable to seeing objects as a universal paradigm. Everything is an object. Everything. They ascribe pet-hood to their little objects and feel driven by the satisfaction of teaching them their own special tricks. Each and every one of them is an excessively black box. Some go so far as to make social-networks called UML diagrams to protect them from inappropriate "friends". They have forgotten the elegant abstract world that was left for them by the intellectual giants of history. They descended from it in pursuit of mere performance and are in serious danger of never returning. To act like it's just another way of looking at things is a brutal misunderstanding. It's a discipline that resides entirely within a much larger one that it is not a suitable replacement for. Despite the confusing desperation of non-academics for it to be that. Even it's creators are disappointed by it's dominance.

Makes me feel like writing "Goodbye, Functional Programming" and making my case with a bunch of bad development practices.

A good programmer writes good programs.

The tools don't really come into it.

And Real Programmers(tm) can write Fortran in any language...

Future mad science project ... build an RNN to generate random buzzy bios.

>>Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation.

How much of the Haskell (a pure FP language) library code is formally proved? Just curious.

Also I wonder, if code like xmonad can be proved at all.