Paul Graham on Spaghetti Code

http://www.kludgecode.com/index.php/paul-grahams-recipe-for-pasta/

by brudgers • 13 years ago

75 75 13 years ago

Ensorceled3• 13 years ago

    "The object-oriented model makes it easy to build up programs by accretion."

On a similar note that object-oriented model makes it easy to write code when you don't understand the problem yet. "I know I'll need a Patient and a Doctor and a Diagnosis ..." Soon you have all these pretty objects and interfaces and Patient and Doctor inherit from Person and ...

I've seen people with literally dozens of objects who still had no idea what they were building or why and couldn’t answer basic questions about the problem domain.

michaelochurch7• 13 years ago

Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable.

The SQL database (a brilliant, wonderful thing despite the hatred it gets) is an example. When you write a query, you don't tell it which indexes to hit and how to micromanage details. You send a declarative query to this "black box" that, most of the time, does the right thing.

I think Objects are a good thing, but they should be rare. Very rare. As with macros, only use them when the simpler tools (referentially transparent functions, immutable data) won't do. Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful.

The problem with "OOP" is that it's "programming as micromanaging, inept businessmen understand it". Instead of math, it's Factories and Visitors and other nonsensical "big picture" bullshit that doesn't map in any coherent, reliable way to the underlying substrate (mathematics, logic) of computation. I'm sorry, but programming is a game where if one doesn't understand the details, one doesn't understand the fucking big picture (which is made up of extremely important details).

_sh2• 13 years ago

Files are a case where the object metaphor makes sense-- there's a bunch of tightly-wound connected state, and I/O is inherently stateful.

And user interface widget libraries, which are all about I/O. Even Racket's widget toolkit leverages the superb racket/class encapsulation mechanism.

alipang• 13 years ago

That sounds very much to me like 'A SQL database is an abstraction', and very little like 'A SQL database is somehow related to OO'. In facts it's really unnatural to map objects to relations, which is why you need yet another ORM abstraction on top of it, just to satisfy the OO silver bullet.

Ensorceled3• 13 years ago

   "Alan Kay's idea of OOP-- encapsulate complexity behind a simple interface, and separate the two while preferring stability in the latter-- was utterly sound and right. He wasn't saying, "go off and write opaque, complicated objects". He was talking about what to do when complexity becomes inevitable."

I agree completely, I was only pointing out another problem with OOP (or, if you will, OOP done poorly) is that it leads to the trap I mention.

praptak2• 13 years ago

I know a company that used to ask in all seriousness "How would you model a car in an OO way?" during interviews, with the expected answer along the lines of Car, Engine, four instances of Wheel and so on. My friend totally stumped the interviewer asking him about the purpose of the modeling. You know, this revolutionary idea that a DMV might model a car slightly differently than a car mechanic.

Late nineties, good times, OO was the silver bullet back then :)

Ensorceled3• 13 years ago

Yeah, I was asked to model a graphics program in an interview and got into a argument about why circles should not be a subclass of ellipse. I explained that, yes, mathematically it's a degenerate case, but in a graphics package circles have different algorithms and different user interfaces. They actually have more in common with squares than ellipses.

After about 10 minutes of no progress, I suddenly realized I would be working with and for idiots so I excused myself from the rest of the process.

vsync• 13 years ago

I'm reminded of Pirsig's comments on the multiple ways you could break down a motorcycle, for example.

The tyranny of the dominant decomposition is no joke, especially when single inheritance and single dispatch are so popular.

michaelochurch7• 13 years ago

I wrote about this last summer: http://michaelochurch.wordpress.com/2012/08/15/what-is-spagh...

Inheritance (typically assumed to be part of OO, but not a requirement) is a big part of it. It gets nasty pretty quickly. Inheritance is the 21st-century goto, although it shares features with the even wonkier "comefrom" of INTERCAL.

Spaghetti code isn't just "bad code" but a specific kind of bad code where understanding a piece in isolation requires pinging about an ungodly number of places. There are a lot of causes of that, but usually it's poor software management and bad development practices.

rhizome2• 13 years ago

"Inheritance breaks encapsulation," the elders said, and as with all extremes, they each have their problems. Language is a lossy codec for math/logic/thoughts, computer languages no less so.

timr• 13 years ago

The "elders" never said that. They invented inheritance because there was a need for it.

Inheritance is a great way to maintain encapsulation in the face of a messy world. Unchecked composition quickly gets you to a world where everything has to be public anyway.

ank286• 13 years ago

This is a case of coherence vs coupling, which is lost by OO developers. Everything is so tightly coupled that more spaghetti code is written up to not break the coupling, making the code more incoherent overall.

brudgers2• 13 years ago

My understanding is that it originates with plugboards. See the third image in this recent article:

http://www.pcworld.com/article/249951/if_it_aint_broke_dont_...

tyang• 13 years ago

This is why almost all good investors pass on startups with weak or no technical cofounders.

absconditus• 13 years ago

What? Most of the business world runs on spaghetti code sold by successful software companies. Success has almost nothing to do with technical skill.

mynameishere• 13 years ago

This has a specific name.

http://c2.com/cgi/wiki?RavioliCode

Osiris• 13 years ago

* What this often means, in practice, is that it provides a structured way to write spaghetti code. *

I've had to refactor code that my co-workers have written several times because they end up throwing code in a class where it works but doesn't "belong".

For example, the REST API I'm building has thin controllers, thick domains, and thin data access layer with various supporting models. I had a co-worker write a Domain object that acted like a model (a single object that should be instantiated, properties set, and a calculation function run).

I had to refactor all his code out into a reusable model and then build helper functions in the domain for the controller to consume.

Whenever I see that I need to do the same type of operation in multiple places, it tells me that code should probably be consolidated into a structured class to make sure that any bugs in the code can be fixed in one place instead of a dozen.

So in a way the code was structured in a class but was still a mess. OOP isn't just about classes and inheritance but about structure, architecture, and how classes interact with each other.

lttlrck• 13 years ago

When you 'had him write it' maybe you should have specified it more clearly.

mcmire• 13 years ago

I've never understood these sorts of statements. You can write spaghetti code in a functional language too. Instead of objects floating around, you have functions. Instead of objects interacting with each other in various ways, you have functions interacting with each other in various ways. You can "build programs by accretion" in any language. Ultimately it all comes down to complexity. Simple code is simple, complex code is complex. You're not going to magically get around this by switching to a functional language. Right?

wtetzner• 13 years ago

Well, if you're really programming in a function way, then you're not using side effects (or at least, the side effects are constrained). That means things are local, and you can safely compose functions without causing the behavior of other parts of the program to change.

bdamm• 13 years ago

Spoken like a true academic.

ozataman2• 13 years ago

The biggest thing in this regard a language like Haskell has going for it is purity, and therefore the concept of "no global state" taken to an extreme. Add to that referential transparency (which is a highly related concept anyway) and you get pretty strong "equational reasoning" where it is quite easy to trace, accurately, what's happening in a chain of calls - it's all transformation of data structures passing through.

If by "functional language" you mean JavaScript, then that's a completely different matter... :-)

dchichkov7• 13 years ago

Whatever you do, don't let some baby with a hammer to take some abstract and high concepts to the extreme, ruin your project and learn from it. Not in your project.

In the production code, stay with the mainstream. And limit your extreme approaches to research grade code, with limited lifetime.

orokusaki• 13 years ago

This is Amazon affiliate spam... check the `tag=...` in the book link.

nnq2• 13 years ago

I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of the code" sounds like the opposite of what all people I know call sc. I thought that a necessary property of spaghetti code is that almost everything is connected in a way so you can't make a change by only changing something in one place because everything is connected in weird ways because of the lack of structure, so you need to keep the whole program in your head while working on it.

Isn't the whole point of well structured programs to be able to work on them while holding as little of the program in your head as possible, so you can work on part of it and be able to "make all these types of modifications without even looking at the rest of the code"? If you have a program that can "evolve" successfully without the need for anyone to "hold it in its head", then a large team can work on it and you can usually replace a 10x programmer with a swarm of 1x ones, basically a pointy haired boss's wet dream...

michaelochurch7• 13 years ago

If you have a program that can "evolve" successfully without the need for anyone to "hold it in its head", then a large team can work on it and you can usually replace a 10x programmer with a swarm of 1x ones, basically a pointy haired boss's wet dream...

Why is that the PHB's wet dream? I mean, by observation I agree with you. That is the case, so I am not challengingyou on that. But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive?

It seems like PHBs shoot themselves in the foot, repeatedly, without mercy.

gnaritas• 13 years ago

PHB's tend to measure themselves by how many people they're in charge of; better 10 guys than 1 that's productive as 10. PHB's aren't entrepreneur types, they're middle managers who require underlying to justify their existence, the more the better.

yen2232• 13 years ago

Risk management.

Assuming the PHB can hire 10 junior devs or 1 senior dev at the same cost:

If you have 10 junior devs and 1 decides to quit, the PHB can swap him out fairly easily - he just has to wait for graduation day.

If you have 1 senior dev and he decides to quit, the PHB's hands are severely tied, especially if the company is located in a place where talent is lacking.

This is also the reason why mainstream languages will likely remain popular forever in the enterprise world - no one wants to take a chance on a language that only 5% of devs know.

rizzom5000• 13 years ago

But what could be the underlying reason, seeing as 10x programmers are only 1.5-3.0x as expensive?

I'd venture that it's because something like less than x% of all programmers are elite; where x is some number between 5 and 10.

In this case, if you are PHB and have a budget of y for staff (where y <= average) and time variable of z (where z <= average) for a release date - it would appear that you are an incompetent PHB if you believe you can hire an elite programmer to solve your problem(s).

nnq2• 13 years ago

I think people are not as rational as they seem and it's basically a form of power hunger - PHBs feel more powerful when the distance between them and their employees is larger: one feels much more powerful having 10 people well below him than having 1 person a little below him, and 10x programmers that also have social skills in a company where IT matters will have a say in lots of things, even not IT related and even if not in a direct way, so they end up closer to the PHB on the power scale than each of the 10 1x ones, which is a bad feeling... Now if the 10x is totally lacking in social skills and introvert, that's ok for the PHB, but if lacking in social skills and more of an extrovert, it's bad again, because although he wouldn't have a say in things because he's "the smart asshole", he'll make everyone, including the PHB, feel and look stupid (and they probably will be 20 iq point below him and they'll know it and feel somewhat demoralized by him).

Basically the 10x guy is uncomfortable for all guys above him (not only in software but in any other field that has a 10x skill gradient) that lack self-control, self-knowledge and people skills (what's called "being wise"), and most PHBs are "very not wise".

yummyfajitas• 13 years ago

Why is that the PHB's wet dream?

Because it makes the business more failure tolerant. Finding even one 10x guy is tough - many teams will have only 1 or 2 of them, and a swarm of 1x guys.

If the 10x guy is on vacation, quits, or has something more important to do, you can throw one of the 1x guys at it.

You don't need nefarious "I hate the 10x cause I'm a psychopathic PHB" motives to explain this one.

laureny• 13 years ago

> I haven't read the book and dunno about PG's definition of spaghetti code, but "we can make all these types of modifications without even looking at the rest of the code" sounds like the opposite of what all people I know call sc.

That was exactly my thought as well, I had to reread the part twice to make sure. This is the definition of maintainable (or maybe even well-designed) code when all its parts are carefully isolated.

hmbg• 13 years ago

I think the point is that writing code on isolated parts without thinking about the overall purpose and architecture of the program leads to bloat, repeated functionality and diverging paradigms/conventions in the same codebase. I agree that's not the traditional definition of spaghetti code, but it's a problem in many large software projects.

Adding that together, well designed code is the foundation of really bad code. That could explain a lot.

brudgers2• 13 years ago

The quotation is nearly twenty years old. For context that's before Java [practically speaking] and before C++ was standardized - and when programmers of Graham's age had a background using PEEK and POKE and GOTO in BASIC or exposure to assembly and the older programmers had often seen plugboards in use.

I won't guess at Graham's definition today. He can speak for himself, anyway. But it resonated with me in the context of Rich Hickey's ideas - particularly "Are We There Yet?" http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

As I understand it, an issue with [some] object systems is that when objects are made by aggregation, rather than inheritance, they are of a different type than each of their components. And this requires the programmer to write some code [however minimal] for the new type in order to reimplement any desirable feature of the objects from which it is composed.

In other words, the behavior of an aggregate of objects is undefined. Hickey's comparison is to data. Which he claims aggregates into more data. When, I ask myself "what is data?" lisp-a-cadabra - it's code. Which is the [structuralist] way in which I read Graham's note.

flyinRyan3• 13 years ago

You're absolutely right. This is what is meant by spaghetti code; everything is connected and you can't tell what is connected to what until you start pulling things out.

I've only worked on one or two code bases that were truly spaghetti code and I replaced them both completely in short order.

unoti• 13 years ago

Where I come from, we derisively called this "Lasagna code." It's not tangled like spaghetti, but there are many, many layers.

btilly• 13 years ago

See http://www.paulgraham.com/noop.html for an essay from Paul Graham about a dozen years ago that expanded on the dislike that he had then for OO code.

I do not fully agree with his opinion there, but he certainly has some valid points.

olaf• 13 years ago

People who critisize OOP for its bad applications have mostly not understood it.

Paul Graham on Spaghetti Code

Related Stories