Smash Company Splash Image

November 1st, 2018

In Technology

6 Comments

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

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:





RECENT COMMENTS

November 12, 2018 9:44 pm

From Roberto on Poland was shockingly liberal during the 1400s

"Also check out Laurentius Goslicius: https://en.wikipedia.org/wiki/Wawrzyniec_Grzymała_Goślicki Richard Cal..."

November 7, 2018 6:04 pm

From Henry Longmore on Why not use asserts in Python?

"Thanks for the article. I used to mock Eiffel for its "Design By Contract" as that seemed to be the only good ..."

November 5, 2018 7:51 pm

From lawrence on Zed Shaw is angry (abstraction and indirection)

"Cat Mara, that is a very good point. Even if some of the previous attempts were badly done, if someone claims ..."

November 5, 2018 3:03 pm

From Cat Mara on Zed Shaw is angry (abstraction and indirection)

"Lawrence- Also, are there aspects of Object Oriented Programming that you think make this tas..."

November 4, 2018 10:43 pm

From lawrence on Zed Shaw is angry (abstraction and indirection)

"Cat Mara, that is a good point about the way CORBA was deemed too complex but it was replaced by WS-* specs ev..."

November 4, 2018 2:59 pm

From Cat Mara on Zed Shaw is angry (abstraction and indirection)

"Laurence, it was your OO essay that brought me to your site and I've been reading your posts ever since. And I..."

November 4, 2018 1:44 pm

From lawrence on Object Oriented Programming is an expensive disaster which must end

"Marcel Kincaid, your comment is itself an example of the No True Scotsman fallacy. If you look at the discussi..."

November 4, 2018 11:46 am

From lawrence on Zed Shaw is angry (abstraction and indirection)

"Cat Mara, I can agree with about half of what you say. It is true that Zed Shaw is criticizing some horrible o..."

November 4, 2018 10:34 am

From Cat Mara on Zed Shaw is angry (abstraction and indirection)

"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 say..."

October 23, 2018 10:18 pm

From Marcel Kincaid on Object Oriented Programming is an expensive disaster which must end

"The worst part of this article is its misunderstanding and abuse of the No True Scotsman fallacy. It *only* ap..."

October 23, 2018 9:52 pm

From Marcel Kincaid on Object Oriented Programming is an expensive disaster which must end

"A silly polemic full of strawmen. Apparently the designers of Rust took it to heart, and as a result it's virt..."

October 18, 2018 7:15 pm

From Ahmed O Ali on The multiplicity of truth during the era of the Internet

"I think that the old attempts to unify the truth are the result of power, but today we are going to facts that..."

October 9, 2018 11:18 am

From Justin McGuire on Susan Kare invented the modern world

"I picked up her ICONS book a while back. It's an inspirational little art book, great for a geeky coffee table..."

September 20, 2018 5:23 pm

From Wayne on Have I been shadowbanned from Hacker News?

"Yep. I was also shadow banned from hacker news. Also, I saw a guy get banned from Hacker News for commenting t..."

August 27, 2018 1:04 pm

From Dave Paola on What's wrong with Hacker News

"I agree completely, although HN does support RSS feeds for user comments. I use this to follow people I respec..."

6 COMMENTS

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:

http://csr.bu.edu/rina/about.html

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>