November 1st, 2018

# Zed Shaw is angry (abstraction and indirection)

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

In the tech world, a headline such as “Zed Shaw is angry” is the ultimate evergreen headline, since he is always angry, and it is easy to get tired of his ranting. But I think he has a good point here:

I hate using badly designed APIs. I hate it even more when someone beats me over the head with words they were handed in some rhetoric class masquerading as a computer science course. Words like “abstract”, “pattern”, and “object oriented” are used like a shield to protect the implementer from critical words like “crap”, “complicated”, “obtuse”, and “annoying”. It’s even worse when the implementer realizes that if he implements the most complicated piece of shit possible then he can go rogue consultant and make tons of mad cash helping poor unsuspecting companies implement his steaming pile of bullshit. Harsh words? You bet. But I’m fed up with people imposing their faulty definitions and ideas on me without any way for me to easily fight back with a reasonable explanation as to why their crap is steaming. I’ve decided to start fighting back by coming up with a set of essays about programming that highlight common design misconceptions. This essay is about my top pet peeve: an abstract interface and an indirect interface are entirely different things.

Source

Check out my book:

August 28, 2020 6:37 pm

"I am in RoR about 7 years, but I don't like it (I do it on my primary job). In free time (freelance) I work mo..."

July 14, 2020 8:53 am

"In my experience, yes. I have made it common to do a 3 day fast a few times a year. Anecdotally, I would say i..."

July 13, 2020 3:07 pm

"Thank you so much for sharing your story. I have recently been diagnosed with Lyme disease and want to treat i..."

May 31, 2020 9:03 am

"Dear Lawrence, I can agree with you partially, but not in the whole at all. I agree with you that even P..."

May 22, 2020 12:43 pm

"Good article. However I hate to see so called "SOLID Principles" conflated with OOD. SOLID is a form of cargo ..."

May 22, 2020 10:29 am

"The first time I looked closely at OOP I was astonished at the – idiocy, the absence of any usefulness, the ad..."

May 13, 2020 5:03 pm

"Closest match to the intensity of this is the movie "Twentieth Century" with John Barrymore and Carole Lombard..."

October 19, 2019 3:08 am

"I really enjoyed your article. But i can't understand the example with the interface. The example is reall..."

October 17, 2019 4:50 pm

"Can't speak for anyone else, but on my feed reader: 5K bookmarked feeds, 50K regex on the killfile to filter o..."

October 9, 2019 3:08 pm

October 4, 2019 8:44 pm

"Gorgi Kosev, I am working to clean up some of my Packer/Terraform code so I can release it on Github, and then..."

October 4, 2019 5:14 pm

"> Packer, sometimes with some Ansible. The combination of Packer and Terraform typically gives me what I ne..."

October 4, 2019 12:40 pm

"Gorgi Kosev, about this: "I would love if you could point out which VM based system makes it simpler and..."

October 4, 2019 7:31 am

"I won't list anything concrete that you missed, because that will just give you ammunition to build the next a..."

October 4, 2019 1:39 am

"Gorgi Kosev, also, I don't think you understand what a "straw man argument" is. This is a definition from Wiki..."

November 4, 2018
10:34 am

By Cat Mara

Normally, I’d agree with a lot of what Zed has to say but I think he misses the mark here. Most of what he says here seems to boil down to the “overloading” of certain words in OO languages like “abstract”. Abstract classes in most OO languages (at least the ones descending from C++ that I’m familiar with) are not necessarily abstract in a design sense; rather, they are partial implementations that must be subclassed before they are instantiable. Is this confusing? Sure. Just don’t get me started on the way these languages abuse the word “static”!

Regarding his points about the excessive ceremony of J(2)EE: I learned about JEE in its heyday when the XML Kool-Aid was at its height but never really used it in anger. To be fair to the guy who taught it to my colleagues and me, he went through how the whole thing tied together: the home and remote interfaces, using rmic to glue everything together, the JNDI to locate services, writing a service descriptor by hand instead of letting your IDE do it for you, all the gory details. It made sense when you understood that J2EE in its earliest incarnations was heavily influenced by CORBA and things like UDDI: this dream that one day we’d be able to locate remote services and drop them into our systems without a care for where exactly they were running. Of course, none of this ever paid off: sysadmins firewalling everything except port 80 killed CORBA RPC and forced a move to Web Services; universal service discovery remained a pipe-dream, and all the machinery built into JEE to one day support it looked more and more ridiculous as more lightweight ways of building distributed applications came along. TL;DR JEE was not merely “abstraction for abstraction’s sake” as Zed would paint it: there were definitely elements of “design by committee” to be sure but the main problem IMO was it was based on a model of distributed computing whose initial assumptions were rendered irrelevant by changes in the landscape brought about by the Web.

November 4, 2018
11:46 am

By lawrence

Cat Mara, I can agree with about half of what you say. It is true that Zed Shaw is criticizing some horrible old practices that existed only because of some really odd ideas about how to handle distributed computing (or at least, ideas that now seem odd).

But it’s worth thinking about why stuff like CORBA and JEE had such problems. Serializing objects is very difficult when objects have methods, or they contain references to other objects. But serializing an object is easy if the object is simply a container for data. And we’ve all gotten used to this over the last 15 years or so, having objects of data that we serialize and then pass along through our communication channel (which might be Kafka or Redis or HTTP or RabbitMQ or raw UDP).

But if we are building a communication system and we only want pass around data objects, or documents, then surely some of the weight of object oriented ceremony is causing us some unnecessary cost? It seems like a contradiction to argue that such ceremony is 100% necessary, but also we can freely forget about it whenever we pass around messages.

I’d go further than Zed does, I’d argue that Object Oriented Programming Is An Expensive Disaster Which Must End. Even after 4 years, this remains the most popular essay I’ve written:

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

I’ve been working with Clojure a lot in recent years, I find its functional approach very clean. It’s built on Java, so underneath, the data structures I hand around are really Java objects. But thinking of these structures as pure data structures, rather than “objects” in the complicated Java sense, has made it easier for me to think about how I want to handle the data in the systems I build.

November 4, 2018
2:59 pm

By Cat Mara

Laurence, it was your OO essay that brought me to your site and I’ve been reading your posts ever since. And I would agree with a lot of that essay. I especially agree that languages like Java that have mutable state while at the same time encouraging programmers to use threads has brought about a uniquely fragile way of doing software development. Have one or the other, but doing both together is fucking insanity. The Clojure or Erlang approaches make more sense to me. FWIW, I have tried dipping my toe into Clojure development (I have done some work in Lisp-like languages in the past) but nothing hard-core as of yet.

I’m finding it a bit difficult to articulate all my thoughts in a comment– I should probably take a shot at trying to write an essay of mine own one of these days!– but there were some ideas in the CORBA/OMG stuff that I would be loath to see thrown out with the bathwater, or at least dismissed as mere “ceremony”. Some of the problems they were trying to address were genuinely difficult problems, rather than just design-by-committee wankery– distributed transactions, for example, or guaranteed once-only delivery in messaging. I’m thinking of Fred Brooks’s distinction between “essential complexity” and “accidental complexity” in the Mythical Man Month here. The proof of this, IMO, was that when they decided that CORBA was too complex and dated and Web Services were the new hotness, the resulting WS-* specs were every bit as byzantine as what they were supposed to be replacing. It’s easy to declare “there’s too much ceremony” and start over only to find yourself at the same point a few years down the line having to deal with one of these “essentially complex” problems like trying to maintain consistency across system boundaries.

(There’s another perspective, of course: the reason these kinds of problems are hard isn’t because they’re really technical problems, it’s because they’re political problems. Distributed transactions are hard because people are trying to subtract human accountability from the system; they want it to Just Work™ and for the buck to stop anywhere in front of them if it doesn’t. But that’s a whole other rant and I’ve probably monopolised your comments as it is)

November 4, 2018
10:43 pm

By lawrence

Cat Mara, that is a good point about the way CORBA was deemed too complex but it was replaced by WS-* specs every bit as byzantine as previous attempts at object serialization and message passing. I have previously linked to some commentary on that subject here:

http://www.smashcompany.com/technology/a-complexity-that-is-frankly-breathtaking

I agree with you that some of the problem goes to the essence of the challenge — that is to say, this is an essential complexity. Certain problems, such as service discovery, are difficult when one is dealing with one’s own apps talking to one’s own apps, and that problem becomes extremely difficult when one wants to do service discovery of 3rd party services (or offer service discovery of one’s own services to 3rd parties).

I might have said this poorly, but my point is, I look at where the trend has been, over the last 20 years. It’s been away from all-in-one solutions. The problem has been broken down into parts. JSON emerged as the standard way documents are passed to 3rd party services, and it became common to serialize objects to JSON and then recreate them. But myself and many others continued to struggle with the problem, how should a 3rd party attempt to create the behavior of an object? So increasingly, the trend was to pass around documents, rather than whole objects.

Arguably, we were addressing the problem at the wrong level. Maybe it is best to think of network communications as an extension of inter-process communication. I believe that is one of the central ideas of RINA:

In that regard, I agree with you that “the main problem IMO was it was based on a model of distributed computing whose initial assumptions were rendered irrelevant by changes in the landscape brought about by the Web.”

Likewise, perhaps we might make further success if we challenge the assumptions the Web is based on, but that is a different conversation.

I never did anything serious with J2EE so I’m probably the wrong person to either praise it or damn it. I invite you to expand on what you were saying, if you felt there were some ideas there that should be rescued.

Regarding this:

“a few years down the line having to deal with one of these ‘essentially complex’ problems like trying to maintain consistency across system boundaries”

I agree with you that is a hard problem. I’m curious if you have a favored approach? Also, are there aspects of Object Oriented Programming that you think make this task easier?

November 5, 2018
3:03 pm

By Cat Mara

Lawrence-

Also, are there aspects of Object Oriented Programming that you think make this task easier?

No, not really. I’d really only be interested in mining this stuff to see if people had at least thought about some of the problems inherent in building big systems before charging off on another round of wheel-re-invention. As far as I’m concerned, I’m with you that the OO crowd has been big on talk for the past forty-odd years with very little to show for it beyond a lot of expensive failures and whiny self-justifications when called to account.

November 5, 2018
7:51 pm

By lawrence

Cat Mara, that is a very good point. Even if some of the previous attempts were badly done, if someone claims they have a new approach, we should ask how much they understand about the previous failures, otherwise their new idea probably is headed for the same kind of failures.

November 22, 2018
11:49 pm

By Free Speech Message Board

Americans used to think hippies were lazy fruits for dropping out during the Vietnam War, but maybe the hippies had the right idea after all.

If you can’t change a corrupt system, why be a part of it?