This is about Reflection
March 29, 2013 3:59 PM   Subscribe

 
The six elephants and the wise man1 always seems more appropriate when talking about these theoretical constructs that are going to make our lives easier.

Most code organization schemes are people trying to come up with technical solutions to people problems. A conscientious coder is going to turn out good code no matter what you saddle them with, and no matter how much structure you try to put around a sloppy coder the thing is going to turn out sloppy. But people keep trying.

All of these things seem to come from the idea that programming is some airy abstract construct that needs to be tied down. It's not. It's brick laying. People don't hold brick laying conferences where they talk about how important the overall structure of the way the bricks fit together is, although they may wax poetic down at the pub after a few beers. Sure coding has interesting complications, but if you're doing more than writing a blog entry about them you're taking the whole thing way way too seriously.


1Six blind elephants encounter a wise man, and each touches him in turn. Later when asked to describe the wise man they each said in turn: "Flat", "Flat", "Flat", "Flat", "Flat", and "Flat".
posted by Tell Me No Lies at 5:13 PM on March 29, 2013 [5 favorites]


I think every statement in that comment is wrong.

1) I've known lots of conscientious, but incompetent, coders. They turn out bad code unless you tell them specifically what to do.

2) If you motivate a sloppy coder s/he'll turn out good code. (That's me. I only write maintainable code because I know I'm the only person who will be maintaining it. It's overall less work for my lazy self to do it right the first time. And even then, I don't always do it.)

3) People do indeed hold brick-laying conferences on how to lay bricks, metaphorically speaking. Look at Machinery's Handbook and related publications sometime.
posted by DU at 5:37 PM on March 29, 2013 [1 favorite]


The first link locked up Firefox hard, twice.
posted by localroger at 5:55 PM on March 29, 2013


I'm watching Coplien's presentation at Øredev and I'm slowly beginning to understand why this might be needed. Particularly interesting is the idea of having dumb objects and coding smartness as contexts. The focus on business value and use cases is attractive.
posted by Foci for Analysis at 6:21 PM on March 29, 2013 [1 favorite]


Six blind wise men walk into a bar. The first blind wise man alerts the others: "There is an elephant in the room! I can feel its big leg!" The second blind wise man says "I agree! I can feel the soft hide of its head!" The third blind wise man says "It is indeed an elephant! I can smell the stink of its breath!" At this point, the fourth blind wise man says "I think it's a bar stool!" Then the fifth blind man says "No, I agree with the majority. It's probably an elephant."

The sixth one was both blind and mute.
posted by twoleftfeet at 7:40 PM on March 29, 2013 [2 favorites]


I think every statement in that comment is wrong.

Fair enough.

1) I've known lots of conscientious, but incompetent, coders. They turn out bad code unless you tell them specifically what to do.

Okay, I'll give you that one. There are indeed conscientious but incompetent programmers. In fact I'm writing my first big iOS project right now and while I've been mostly conscientious my incompetence is shining through. No amount of design patterns could correct my incompetence though, it's very specific to the environment.

2) If you motivate a sloppy coder s/he'll turn out good code. (That's me. I only write maintainable code because I know I'm the only person who will be maintaining it. It's overall less work for my lazy self to do it right the first time. And even then, I don't always do it.)

This trait is what I had in mind when I was talking about conscientious programmers. I've encountered very few people who naturally have the discipline to do it right the first time -- most of us have it beaten into us by years of experience.

In any case it's motivation, not coding design or structures or anything else, that is key here. It's a people problem that can not be solved be rearranging the object paradigm.

3) People do indeed hold brick-laying conferences on how to lay bricks, metaphorically speaking. Look at Machinery's Handbook and related publications sometime.

The distinction I'm making is that people literally hold conferences on object oriented design. And do their theses on it. I'll grant you that there are write-ups more comprehensive than blog entries on brick-laying, but very few people if any are making their academic career out of them.

What's interesting to me is that brick-laying is actually a much more varied art than computer programming. Worldwide there are an incredible number of different materials and mortars and bases and climates, with hundreds if not thousands of local "best practices". With programming we have a comparatively tiny number of dominant languages and a vanishingly small number of environments they run in.

But still people keep messing with "design patterns" as if they're going to hit the one true system that will eliminate bad code and/or lazy programmers.
posted by Tell Me No Lies at 8:20 PM on March 29, 2013


Maybe we'll stop having conferences about software design in a few hundred years, when it's a fraction as old as bricklaying...
posted by axiom at 9:15 PM on March 29, 2013 [1 favorite]


Maybe we'll stop having conferences about software design in a few hundred years, when it's a fraction as old as bricklaying...

Wow. Way to dis the International Union of Bricklayers & Allied Craftworkers Convention.
posted by twoleftfeet at 9:41 PM on March 29, 2013


I did not know about DCI - interesting post. I'm coding JavaScript these days so may play around with some of this.
posted by parki at 9:52 PM on March 29, 2013


The Software Engineers Union is a whole 'nother topic. An ugly, frightening, and very confusing topic :-)
posted by Tell Me No Lies at 11:31 PM on March 29, 2013


OK I was finally able to watch this, or at least skim it, after figuring out that something on the site triggers a very aggressive memory leak in FireFox which crashes the browser and, if I let it try long enough, Windows.

Here's a kick in the pants: Object oriented programming is a bad idea. It struck me as a bad idea when I first heard of it and nothing I've read since has disabused me of that notion. I undoubtedly just had to restart my computer because of some object-oriented bug.

The OP is half right in that the way OO is done is bad and leads to bugs. It's half wrong in that the notion of object orientation can ever work as well as procedural programming. The fact is the more independent you make "objects," the messier the interface between them is going to be.

Object orientation is a bad idea because the computer isn't made of objects. The computer, as a matter of physical reality, is the first diagram in his slide show. Everything in the presentation after that point represents a stupid attempt to make life easier for humans by pretending the computer is something other than what it is. But the further you get from the physical reality, the more your code is going to fuck up because you're not even going to know what you need to pay attention to.

Most code doesn't need to be written in assembly language, but everyone who writes code needs to know enough assembly language to spit out "hello world" on a microcontroller. I mean that passionately. Nobody should be allowed access to a floating point library unless they've been taught enough finite math to understand how much trouble they can get into. Floats are not real numbers, and data structures in a computer memory are not "objects" or "actors."

I favor Chuck Moore's approach of rewriting your routines for each new application; even though it seems like a waste you know where the holes are and you get better at leaving fewer of them with practice. You save the time you think you wasted writing yet another floating point lib when you don't have to go chasing down weird bugs because you don't know the undocumented limitations of the lib that you used.

Just about every overt goal of object oriented programming is moonshine. The plain fact is you write code with fewer errors by understanding every aspect of what the code is doing, at least in principle if not down to actual CPU registers. If you don't understand that you will ask the machine to do something that seems reasonable to you but either isn't implemented right or isn't even possible, and you won't even know why it doesn't work.
posted by localroger at 2:46 PM on March 30, 2013 [1 favorite]


« Older Walmart news of the week   |   Scenes from Renaldo and Somebody or Other Newer »


This thread has been archived and is closed to new comments