Java Concurrency in Practice: Oh Shit.

Holy fucking shit. Reading Java: Concurrency in Practice has made me realize that probably every fucking program I’ve ever written is wrong, the world is constantly on fire, and you can’t have people writing reasonable applications with these barbaric and primitive tools.

Rich Hickey was a motherfucking genius. Functional programming languages and immutability almost everywhere are the only answers to any of this.  Motherfucking semaphores and locks and synchronized blocks: are you kidding me? We HAVE to evolve to Actors, Dataflows, Communicating Sequential Processes, and STM. Trying to use even a Java 7 ExecutorService with a ConcurrentHashMap sanely is like being a fucking surgeon in the 1800s trying to cure a patient’s “hysteria" and "bad humors” with fucking leeches and bone saws.  

This is too fucking hard! You cannot give a 22 year old kid who barely knows his elbow from a blow job access to an ExecutorService and a random Java class he wrote in school and say “Go to town, scrappy!” Kid’s gonna have no fucking clue about the Java Memory Model, properly using synchronized blocks for guarding invariant impacts by independent updates to immutable local state, or any of the dozens of abstruse and mundane nuances that go into managing the shared cross-product combinatorial explosion of state space involved in doing any seemingly simple, trivial operation in a concurrent environment!

I love this Brian Goetz, I really do. He’s like a cheery little droid while my spaceship’s on fire, hurtling towards a black hole, happily telling me that if I just design my classes this way and use special annotations and volatile variables that way and I am really careful every time I put some Object into a Map AND get some Object out of it AND that when I return it I publish some kind of contract that my method’s consumer is supposed to follow when accessing that Object’s state, THEN I can be effectively safe in a multi-threaded concurrent environment—without even understanding that all these preconditions mean GAME OVER, MAN! The jig is up! The whole thing is fucked!!! You can’t even do…while do is not try, if you catch my drift, because I forgot to call incrementAndGet() on some AtomicLong and now I’m deadlocked.

Good OOP == Good Dependency Management

Object-Oriented Programming is all about dependency management. Dependency management is crucial for building evolving systems that survive and adapt to contextual changes.

It's a paradigm that scales. Even the new "container" based virtualization technologies such as Docker are basically treat "Operating System" as an Object. Even Javascript's "Revealing Module Pattern" is just making a namespace of bound functions...at some point when you're passing the same 3 parameters to 5 functions you start thinking "wait. What if I just passed those parameters to 1 function that called those 5?" and you're on your way to OOP.

Good OOP is about seeing the relationships between things and figuring out how things actually come together. Your software is a jigsaw puzzle, a Lego set. The principles of good software construction all come down to good dependency management.

When you see the right relationships, you minimize the dependency between unrelated things, form logical partitions, and find traversals through the object graph that you completely replace at sub-graphs without any loss of generality.

When you don't, you create bloated, bureaucratic, hard to read and understand systems that don't work. Hopefully at least they fail in obvious ways. It's far more difficult to fix when failures aren't obvious.