SJS wrote:
begin quoting Darren New as of Mon, Sep 29, 2008 at 05:48:36PM -0700:
[snip]
Loose coupling: "Tell someone to go do something. Check with them later
to see if they finished it."
That's not at ALL what I think of when I think of loose coupling.
No, because you're thinking of it in CS terms, and I'm being a little
sloppier than I ought to. The point is that it's not at all difficult to
describe intuitively what "loose coupling" is. There are examples all over.
Parallelism: "Tell several people to go do work. Tell them to come back
when they're done."
Better, but it's not the telling that's key.
No, it's the people doing the work in parallel. (OK, I should have said
"do different pieces of work.") Anyone who has been in school or at work
knows what loose coupling and parallel execution are.
Well, yes.
That's all I was saying. Parallelism and loose coupling are only hard in
the world of computer science, and only in detail.
Making one program run on parallel machines is hard, and making lots of
different programs run on parallel machines is so easy nobody even
considers it something unobvious. I run Word, you run Excel, both at the
same time. Wow, parallel execution! You have six truckloads of pumpkins
and three trucks. How do you most quickly move the pumpkins across country?
Loose coupling? Television stations and televisions. Cars and gasoline
companies. What makes this work? Well-defined interface. What is loose
coupling on a computer? Both Word and Excel will print to either my HP
printer or my Canon printer. End of lesson two.
Pretty intuitive.
Now, I'll grant you that designing those interfaces is non-trivial and
often unintuitive. But I'll also suggest that covering that before you
cover the basics of how *one* program works on *one* computer that
*does* work right isn't going to teach folks much. Just like I suspect
teaching someone how to calculate material delivery schedules to the Big
Dig isn't going to teach people much before they learn that concrete
needs rebar.
I'll tell you something else that's pretty intuitive: fault tolerance.
How do you get at least four truckloads of those pumpkins across the
country without spoiling if there are traffic jams? Did it take a lot of
time to figure out you can send different trucks on different routes?
Does anybody know why there's a thing called an "emergency brake" in
your car?
It's the details that kill you, and you're not going to be able to teach
the details of a distributed, fault-tolerant parallel system before you
know how one program works.
Heck, even Google gets it wrong. I read about the Map/Reduce stuff, and
how they'd run the map part on the same machine that's hosting the block
of data that it's mapping over, so it didn't have to go over the
network. And I thought "Wow, that's clever. I probably wouldn't have
thought of that at first." Then I read the history of the program, and
they were running it like six or nine months before they released the
version that did that, and I thought "Good, I'm not *too* stupid."
--
Darren New / San Diego, CA, USA (PST)
--
KPLUG-LPSG@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
