
Paul Graham on Spaghetti Code - brudgers
http://www.kludgecode.com/index.php/paul-grahams-recipe-for-pasta/
======
nnq
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...

~~~
michaelochurch
_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
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.

~~~
michaelochurch
That's been my feeling about it, too. Headcount and control rather than actual
productivity. Also, I feel like middle managers have a terrible incentive
profile. If an underling really shines, then it reflects well on the
underling. If one underperforms or makes a mess, boss gets shat on for not
keeping them in line. It's easy to rip on middle managers, but they have a
shitty job and it's not their fault. It's just structured badly.

I think it's easier to understand why middle managers are the way they are
once one understands their incentive structure. They participate in an
employee's downside but not upside (she did it herself) so _of course_ they're
going to be the way they are.

I may be radical but I think open allocation is the only answer for software
development. All the nonsensical process that grows up around closed
allocation seems archaic and stifling. I think typical middle management is
useless. What you really need are HR-independent mentors. Aside from
mentoring, the other thing managers can do (firing) should be so rare in a
well-run company that you only need one per few hundred people.

~~~
gingerlime
I recommend reading about the Gervais principle![1]

[1][http://www.ribbonfarm.com/2009/10/07/the-gervais-
principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-
the-office-according-to-the-office/)

~~~
dpritchett
When Michael read about the Gervais principle it inspired about 100,000 words
of response:
[http://michaelochurch.wordpress.com/?s=gervais&submit=Se...](http://michaelochurch.wordpress.com/?s=gervais&submit=Search)

~~~
gingerlime
thanks for the link!

------
Ensorceled

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

~~~
michaelochurch
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).

~~~
_sh
_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.

~~~
tikhonj
For UI code, you should check out functional reactive programming (FRP). It
essentially provides first class time-varying values instead of implicitly
modelling time with mutable state.

This makes UI code more declarative and allows you to create things like neat
combinators. As an example, it's very easy to write a function like `when'
with FRP, which could be used like this (code roughly from a game of life app
I wrote):

    
    
        when (not <$> paused) (step <$ time)
    

Here `time' is just a stream of events every x milliseconds. So what this code
does is create a stream of step events which represent stepping the life
simulation forward at each time step, as long as the game isn't paused.
`paused' is a value based on a button, but it could easily have multiple
inputs.

So you get signals and event streams like `paused' and `time' from UI widgets
(or the system), and then combine them into new streams that you can plug
directly into UI widgets. This then lets the widgets themselves be much
simpler structures with not internal state. In essence, this replaces
arbitrary mutable state with an explicit dependence on time which leaves less
room for making mistakes while also making it easier to write high-level
functions like `when'.

There's a ton of other cool things you can do--this is just an example meant
to illustrate the sort of abstractions you can use; it is by no means
exhaustive!

I've found that FRP leads to much nicer UI code than callback-based OOP.

~~~
michaelochurch
FRP seems deeply awesome. Thanks for explaining it.

------
mcmire
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
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
Spoken like a true academic.

~~~
tikhonj
Or, you know, a software engineer. Good software engineers, after all, value
things like low coupling; composability is like a stronger version of low
coupling. (That is, composable things are not tightly coupled but decoupled
things are not necessarily composable.)

~~~
dchichkov
Good software engineers certainly value low couplings. Unless it is a coupling
with some code written in an obscure language with extreme (and masochistic)
approach and with no common sense.

~~~
kenbot
I'm not at all sure what your point is. There's nothing controversial about
the benefits of referential transparency and immutable state, for modularity,
composition and simplicity. What is obscure to you? It won't be to everyone.

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

------
btilly
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.

------
mynameishere
This has a specific name.

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

------
Osiris
* 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
When you 'had him write it' maybe you should have specified it more clearly.

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

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

------
michaelochurch
I wrote about this last summer:
[http://michaelochurch.wordpress.com/2012/08/15/what-is-
spagh...](http://michaelochurch.wordpress.com/2012/08/15/what-is-spaghetti-
code/)

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.

~~~
rhizome
"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
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.

~~~
rhizome
It's just a figure of speech.

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

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

