See the entire conversation

Inspired by @mountain_ghosts, I've decided to re-read the classic software eng paper "Out of the Tar Pit." I last read it ~10 years ago.
58 replies and sub-replies as of Apr 13 2017

Found the PDF. Read the first 4 pages. Then printed it out on actual paper, because I have SO MANY comments to write in the margins.
In case you were wondering how it's going. 😅
+@mountain_ghosts I feel like there is a metaphor in you finishing "Out of the Tar Pit" and starting The Odyssey
Current status: page 5 of 66. Located 3 fundamental misunderstandings of how software is developed. Suspect more lurking in sections to come
Current status: page 12 of 66. Have lost count of issues. Reduced to underlining & writing NO in the margin. Pressing on in hopes of payoff
I look forward to the resulting thread!
most frustrating book report
I see a missed opportunity for using a red pen. :)
Are you going to post a scanned/reviewed copy? so curious
Current status: page 17 of 66. Java/Angular-style dependency inversion called "extreme"; surely would never _really_ happen. #lolsob #ifonly
Page 18 of 66. _Always_ make refactoring harder, or _sometimes_ have to look at other code? The former is deemed vastly preferable.
this paper is full of stuff that is theoretically/mathematically true, but we have p good coping mechanisms for
like yes *in theory* I cannot guarantee any random ruby method does not have effects, and yet I write workable software with it
or in some cases I write methods that exclusively have effects, *on purpose*, and it's fine
This lines up w how I feel about the static typing debate. "This value could be anything" yeah, but it won't be
If you replace every instance of "the object-oriented approach" with "how Java was done in the early 2000s", the paper starts to make sense.
Jbuilder #Borland that I used in 1994 wasn't #Event driven. DOS6.3 but we Compiled in 32-bit Exe's
That's the Rosetta Stone for this paper. In that context, their issues with testing, object equality, etc. do actually make sense. #woah
Ironically, by calling Java issues "inherent to the object-oriented approach," they have confused essential problems with accidental ones.
And distinguishing essence from accident is the _entire point_ of their paper.
OMG maybe this is an art piece and I just explained the joke for 25 tweets o_0
performance art piece à la The Family Fang 😂
So to recap our saga: 1. WTF WTF NO WTF 2. oh. OH. ok, I see 3. That's still wrong, but in a different way than I thought
I can't help but feel I've spoiled your afternoon
actually this has been pretty fun
This is also the saga of a developer attempting to understand someone else's (or their own old) code.
my favorite criticism: “The superficial flaws hide the fundamental mistakes.”
"Out of the Tar Pit" is still fundamentally wrong about how software is developed. Its advice should not be taken at all literally.
But given the limitations on their vision imposed by the Java of the early 2000s, I can understand why they thought that way.
There are a lot of projects still stuck in Java-of-the-2000s, and the paper is compelling in its description of those problems.
But the proposed solutions make zero sense in today's technology landscape.
I look forward to reading this as a blob post.
I agree, but the spirit of the proposed solutions do appear to me to resemble React apps and/or streaming event systems
Is this where I put an awful pun about how it's pretty far from SOLID? I want to make sure I obey the proper forms.
"everyone we assigned to the accidental complexity team quit within a month"
I think we see shadows of this model in "Object Oriented CSS" and other OO-like approach clones.
What to read about how modern software is developed? Any recommendations?
Actually that would be a lot of the essence of software architecture/engineering too, right?
"Object-oriented" has meant a ton of stuff. It barely makes sense to call *class* oriented languages like Java, "object" oriented at all IMO
Tells a lot about need for context. Many things are anti-patterns when applied to different tools (or even same tools, but years later).
Vocabulary changes over time and by writer. Backus advocates "functional programming," but not what it means today (we'd say "point-free").
I'm really enjoying your tweet stream on this. My colleagues pass around this paper as gospel. And the do the opposite. Which is also bad.
where should multiple-object constraints reside beyond doubt?
in other objects
I hope your notes turn into something we can all read. Or, you know, that you just post scan of marked up article. :)
This is a good use case for live streaming tbqh
If I ever re-read it I'd probably want to read your annotated version. Gonna publish?
Seems like a hard thing to publish. I printed it out to write on it with a pen because electronic annotations on a PDF are awkward >_<
oh well I guess an exegesis by blog would be cool too. In your copious free time. :)
Still on my list of things to read!