Join 3,559 readers in helping fund MetaFilter (Hide)


Every customer has a name, but custRec is a database record
October 16, 2013 6:37 AM   Subscribe

Introduction to Abject-Oriented Programming. (via /. embedded link)

Previously from Typical Programmer
posted by JoeXIII007 (38 comments total) 41 users marked this as a favorite

 
I made it to polymorphism before stabbing myself in the eye.
posted by odinsdream at 6:47 AM on October 16, 2013


It's funny because it's true.
posted by fatllama at 6:48 AM on October 16, 2013 [5 favorites]


I know some people I could forward this to, but I'm afraid they are going to take it seriously.
posted by Dr Dracator at 6:51 AM on October 16, 2013 [9 favorites]


Oh man, these are great. My favorite bit:

A module usually consists of:

- Copyright notice
- Legal disclaimers
- Three to five lines of asterisks
- Change history
- Description of what the module was originally supposed to do
- Three to five more lines of asterisks
- Big block of whitespace surrounded by asterisks or other character, including the name of each function or subroutine, the author’s name or initials, and the date originally written
- The code

posted by burnmp3s at 7:01 AM on October 16, 2013 [4 favorites]


I laughed because some of this stuff the author talks about is pretty insane to consider happening in a professional environment.

I also laughed because I am just as guilty of committing some of these errors.

*sigh* Deming and "continuous process improvement" FTW.
posted by JoeXIII007 at 7:05 AM on October 16, 2013 [1 favorite]


Ugh, I almost broke down and cried reading this. Then I wondered where they found the source code that I am now responsible for maintaining.
posted by indubitable at 7:13 AM on October 16, 2013 [5 favorites]


Needs moar:
 · passing a huge global hash from sub to sub so the arg list doesn't get huge.
 · deconstructing complex data structures with Data::Dumper instead of using public methods.
 · code tests which pass when the number of FIXME comments in the source == 0.
posted by scruss at 7:14 AM on October 16, 2013 [3 favorites]


It’s said that code should be written for people to read, so it follows that documentation is written for no one to read.

It hurts.
posted by jcreigh at 7:20 AM on October 16, 2013 [3 favorites]


The comments on the article are either terrifying or hilarious.
posted by justkevin at 7:20 AM on October 16, 2013 [2 favorites]


ProTip: Put your change comments in your commit message, not in the source code. I don't care if you fixed a typo in 2008.
posted by blue_beetle at 7:32 AM on October 16, 2013 [1 favorite]


Reading about objected oriented programming is always more jolly if you manage to convince yourself that cust is short for custard.
posted by Wolfdog at 7:33 AM on October 16, 2013 [2 favorites]


Pretty funny, but I wish he had talked about real inheritance: The programmer creates what are called base classes. These base classes' methods that have side effects. The base classes' methods are like secret challenges for other programmers that are using those base classes' subclasses' methods.

The programmer may think that method A does what it says. But they will soon find out that no, method A carries the weight of generations! It does what its parents' methods A did! And some of them call other methods, each carrying their own hidden ancestral baggage.

Fighting past all this makes the programmer – and the world – a better person.
posted by ignignokt at 7:37 AM on October 16, 2013 [10 favorites]


Scruss, re:
· passing a huge global hash from sub to sub so the arg list doesn't get huge.
Did you work at the same company I did for most of the '00s? :)

OK, it wasn't a global, but it was a huge Perl hash passed from sub to sub and modified by many of those subs, full of mysterious and magical keys and values that might be used several function-calls down from your current function so you'd better not touch them.

Thinking about it now still kinda gives me the heebie jeebies.
posted by edheil at 7:42 AM on October 16, 2013


Who's got time for anything other than grabbing black boxes of code from github?
posted by surplus at 7:57 AM on October 16, 2013 [2 favorites]


When I started my first real software job, I was horrified at the code base. I have since learned that most other code bases are much, much worse.
posted by scose at 7:58 AM on October 16, 2013 [6 favorites]


One programmer's technical debt is another programmer's job security.
posted by Foosnark at 8:03 AM on October 16, 2013 [10 favorites]


If the language supports first class functions, just put the function definitions in the big hash you're passing around and you're all set.
posted by wobh at 8:03 AM on October 16, 2013 [5 favorites]


Those who have not studied object oriented progamming are doomed to reinvent it, poorly.
posted by Dr Dracator at 8:06 AM on October 16, 2013 [1 favorite]


Version Control

sigh.
posted by mikelieman at 8:09 AM on October 16, 2013 [1 favorite]


It hurts just reading that.

I think it says something about the maturity of programming as a discipline that these kinds of errors are so commonplace. It's still a field trying to find its way.
posted by underflow at 8:17 AM on October 16, 2013 [1 favorite]


a huge Perl hash passed from sub to sub and modified by many of those subs

That's basically how global variables are implemented, though it's probably a little less efficient.
posted by frogmanjack at 8:43 AM on October 16, 2013


If someone ever writes a Devil's Dictionary for software development, this would be a decent start.
posted by Blazecock Pileon at 9:45 AM on October 16, 2013 [4 favorites]


There is a positive case for passing a hash as an arg to each function - it ensures that the functionality of the lib is reentrant. Even a single global var referenced in the code can prevent more than one library in the same app from using the same lib.
posted by idiopath at 10:03 AM on October 16, 2013 [1 favorite]


Those who learn Object Oriented programming are doomed to use inheritance the wrong way.
posted by idiopath at 10:04 AM on October 16, 2013 [2 favorites]


here is a positive case for passing a hash as an arg to each function - it ensures that the functionality of the lib is reentrant.

Pure functional languages do this by design - all state must be explicitly passed everywhere. It's an interesting approach, though sadly functional languages are not even on the radar in large parts of the Real World.
posted by Dr Dracator at 10:14 AM on October 16, 2013


Now that functional programming is seeing wider acceptance from everyday programmers, I wonder what anti-patterns will establish themselves. For my part as a (fairly green) Clojure programmer I can't think of many that I see right now, except for the very broad case of people just writing imperative code with s-expressions, or possibly the pattern of the monolithic let block (The God Let?) which is frequently an instance of the aforementioned secretly imperative solution.
posted by invitapriore at 10:40 AM on October 16, 2013 [3 favorites]


All Perl is functional. I mean EVERY subroutine or function returns SOMETHING, amirite?
posted by mikelieman at 10:46 AM on October 16, 2013


wobh: "If the language supports first class functions, just put the function definitions in the big hash you're passing around and you're all set."

Owie. OW OW OW OW OW!
posted by symbioid at 10:50 AM on October 16, 2013 [2 favorites]


underflow: I think it says something about the maturity of programming as a discipline that these kinds of errors are so commonplace. It's still a field trying to find its way.
Once I might have felt the same way, but now I wonder if it's just the nature of the beast.

In software, it's possible for a beginner with terrible habits to cobble together something useful, something that mainly works. In most business environments, that's all that's wanted.

I actually suspect that a high percentage of users (including some of the managers who control programmers' schedules) actually can't tell the difference between good software and bad software. They'll tell you that business task A is slow and difficult and business task B is easy; if you tell them they're both the same task, and the software for task A just sucks, they'll boggle at you uncomprehendingly.

So there's no motivation for a development department to spend the time, money, and effort to improve its level of craft; to anyone outside the department (and to some inside it), that looks like waste.
posted by Western Infidels at 11:11 AM on October 16, 2013 [10 favorites]


In software, it's possible for a beginner with terrible habits to cobble together something useful, something that mainly works. In most business environments, that's all that's wanted.

I was going to say nearly the same thing, but you got there first.

End users care about user experience, not code quality, and the bad thing about programming is you can have one without the other.
posted by Foosnark at 11:23 AM on October 16, 2013 [5 favorites]


I still routinely respond to 'what's the best framework?' irc questions with Miasma.
posted by xiw at 12:27 PM on October 16, 2013 [5 favorites]


That Miasma post is one of the best bits of programmer humor I've ever seen. I can't be alone in reading it and wincing at some of the tendencies there that I shared as a beginner.
posted by invitapriore at 12:45 PM on October 16, 2013


> Did you work at the same company I did for most of the '00s? :)

Don't think so; this was at a pretty small Canadian financial services house c.2003. Apart from shunning core modules, the CEO had a method of programming (yes, we couldn't keep him away from the code base) involving a bottle of Ballantine's and adding/removing [] {} pairs until the syntax errors went away or he could no longer find the keyboard.
posted by scruss at 12:59 PM on October 16, 2013 [3 favorites]


here is a positive case for passing a hash as an arg to each function - it ensures that the functionality of the lib is reentrant.

I've been using a pattern whereby the first arg to the constructor of each new object is the old object in which the new one will be stored. That means I can reach up and out through the namespaces with dot notation, all the way to a single "This Is My App" class that doesn't do a whole lot. "Global" variables go there.

Does this not have the same advantages as passing a big damn hash table around?
posted by LogicalDash at 3:40 PM on October 16, 2013


That means I can reach up and out through the namespaces with dot notation ... Does this not have the same advantages as passing a big damn hash table around?

Well, it depends what you put in that hash table I guess. If you want it to be comprehensive enough to make sure that every property and method (they're all public of course) of all the objects in existence are accessible everywhere, you'd have to be able to go *down* through your tree of objects as well. That could get confusing. It's probably better to stick with one big polymorphic hash table if you can't make everything global, for maximum abjectivity.
posted by sfenders at 4:33 PM on October 16, 2013


Look at Chicolini. He sits there alone, an abject figure.
posted by charlie don't surf at 4:44 PM on October 16, 2013 [1 favorite]


I'm not alone!
posted by 23 at 7:44 PM on October 16, 2013


blue_beetle: “ProTip: Put your change comments in your commit message, not in the source code. I don't care if you fixed a typo in 2008.”
I have a client that has absolutely refused to implement source code control, despite my repeated exhortations and multiple changes in management, for the more than a decade I've been working with them. In fact, I'm the only one that even leaves a change message most of the time.
posted by ob1quixote at 8:48 AM on October 17, 2013


« Older It turns out that if you cut together a bunch of s...  |  io9 takes a look at why the nu... Newer »


This thread has been archived and is closed to new comments