[rescue] Mainframe on eBay
phil.stracchino at speakeasy.net
Thu Sep 22 13:55:15 CDT 2005
Jonathan C. Patschke wrote:
> On Thu, 22 Sep 2005, Wes Will wrote:
>>(Other countries, I won't speculate about the skills of their grads,
>>but the U.S. CS grads that I know (several hundred) are spankin'-good
>>programmers, but computer-clueless.)
> I'd disagree with half that point. The current crop of CS graduates are
> good at abstraction, overall algorithm design, and the other abstract
> portions of computer science. However, when it comes to actually
> putting code on a running system, I'd be much more inclined to have to
> code written by someone with an engineering degree.
> The mantras of CS these days seem to be:
> "Performance doesn't matter"
Bullshit, pure and simple. If performance doesan't matter, why do
people continue buying faster and faster hardware in an effort to keep
up with the code bloat?
> "The user can always buy more hardware"
Yeah, and when the user buys faster hardware, lazy developers who think
the user can always buy hardware will write even more bloated code.
Code bloat expands until it runs into the hardware limits of the
> "Interpreted is better than compiled"
...For prototyping, maybe, and for very small, simple tasks, and in
certain specific environments. There's reasons for using interpreted
languages, and reasons for using compiled ones. Just try writing your
OS in an interpreted language, say, or the interpreter for the language.
> "Defer everything under runtime"
I don't follow this.
> "Programmer time is more expensive than user time"
Gah! While this is true on a per-programmer/per-user basis, there are
MANY more users than programmers and they'll spend a LOT more time using
it. If it sucks now on one development machine doing a few test/debug
runs a day, it's going to suck a whole lot more running 24/7 on twenty
servers each at five hundred different sites. This is the fallacy of
ignoring scale, pure and simple.
> I watched, aghast, as recent graduates have (at $job[-1]) twice taken
> the absolute fastest general-purpose microprocessors on the planet
> (POWER4+ and POWER5) and run them into the ground with abominably
> sucktastic code that happened to be associated with very elegant UML
> diagrams and ivory-tower abstractions from here to eternity. The
> application in question was essentially a community address book
> (statewide list of doctors and their credentials).
I had a classic ivory-tower math professor at EWU, big row of teaching
awards on his office wall, who taught the numerical analysis course
required for the CS curriculum. The curriculum described it as a
practical course on developing computer algorithms to implement
mathematical techniques. He taught it as a highly abstract course on
matrix operations and certain aspects of set theory. The math majors in
the class lapped it up; we CS majors were utterly lost. We didn't have
one clue what he was talking about. He assigned one programming
exercise in the entire quarter, gathered in the finished assignments,
piled them on his desk, said "Of course, you'd never use this algorithm
in practice because it propagates errors too badly," and as far as we
could tell, never looked at them again.
Well if that algorithm was totally useless in the real world, then WHY
THE FUCK did you just waste literally half the quarter on it in a class
that's supposedly about implementing mathematical methods on the
computer for real-world applications?!?
> But, hey, hand these same CS grads C++ and look what a mess they can
> make. Pick any large C++ application (OpenOffice, Mozilla, Microsoft
> Office); it's a nightmarishly over-complicated cesspool of bugs that
> requires more megabytes of memory than we had in disk space a few years
> back. So maybe the recent orgy of runtime-interpreted tools is only the
> tip of the iceberg.
The Microsoft Mantra: Adding features is more important than fixing
bugs, because people buy features, not bug fixes.
Phil Stracchino phil.stracchino at speakeasy.net
Renaissance Man, Unix generalist, Perl hacker
Mobile: 603-216-7037 Landline: 603-886-3518
More information about the rescue