Computer Science vs. Computer Practice
So you're an accomplished computer scientist are ya? We'll see about
that.
The difference between Computer Science and Computer Practice
What is a magician but a practicing theorist? -- Obi-Wan Kenobi
As we all know, there are a lot of ranty articles running around the
net about US IT jobs going overseas. Of course its a valid concern and
a lot of the posts are based heavily in frustration (which can
sometimes undermine facts). One point I see raised again and again is
the statement that programmers overseas produce "crap code" or "have
no idea how to design quality code". Or, the old fall back "don't
understand true computer science principles!"
Bummer.
Partly by force, hmm.. actually, completely by force, I'm still a
professional graduate student at Syracuse University. I don't live
there, but I travel there every few weeks. I meet with members of my
Ph.D committee whom, as you can imagine, are an interesting bunch of
smart professors. They see my dissertation (that I've worked on for
several years now), read it for the first time, and pull some obscure
embedded issue out of the depths of the idea. I'll never stop being
amazed at their ability to do that. Its like someone else telling you
your 10 year old kid has a 3rd arm - I never noticed that before!
Then again, that's their job. They are scientists - they can wrap
their head around new, complex concepts very quickly and immediately
assess the problem from many angles. Despite their brilliance, some of
them still don't use email. That's kind of the running joke isn't it?
The brilliant computer scientist that doesn't use email - or hardly
uses computers for that matter. The fact that this is a joke is a
clear misunderstanding of the line between computer science and
computer practice.
A lot of programmers seem to credit themselves pretty quickly with
understanding computer science. Surely some do. In some respects its
like the guy who has skiied all his life and then at middle-age takes
a skiing lesson. He does it to join a friend or just for fun. Often
enough he learns plenty. If nothing else, he learns other people's
viewpoints on things he figured out for himself. In fact, hopefully a
ski instructor is teaching from a source that has combined knowledge
from the world's best skiers over many years. Chances are you don't
figure out something on your own the same way that pooled knowledge
from hundreds of people before you figured out. You're bound to pick
something up.
The real truth is that knowing a lot about computer science isn't
seriously required for much today's programming needs. Personally, I
couldn't sleep if I knew an O(n^2) algorithm sat where a clean
O(nlogn) would fit - but thats my now inborn nature. Making a webpage
simply doesn't require much knowledge about complexity theory,
algorithms, or data structures. Now, before you go posting at the
bottom of this article that this is poop - I think you're forgetting
something. Surely there are implementations that would benefit from
running the best algorithms and the best quality code, but by far most
of those applications will run just fine with "good enough"
implementations too. That's the rub really.
Don Knuth (a pre-eminent computer scientist/mathematician for those
newbs) made a famous quote something to the effect of "I have proven
that this program is correct, but I haven't tested it". Sort of a
funny joke to prove something is correct but not be sure it will
actually work. If you've actually ever done any program proving
(probably in some computer science cirriculum), you know it can be a
tedious mathematical exercise. The only case I know of where
commercial software was actually proven correct was in the fly-by-wire
Boeing 757 aircraft (this is from memory, if anyone needs to correct
me please do so). That is, they didn't just write the code and test it
a bit to see if it works - they mathematically proved that the
software would work as prescribed. Sounds good to me since I'm on a
757 often enough.
There's a pretty interesting dividing line between science and
practice. Scientists prove, practitioners test. With all the hoopla in
our industry about "test-first" its pretty plainly a practical world.
Testing is fine, but its empirical and can miss details. Its rare that
you can test all possible input in an application. Maybe we all should
be more like computer scientists. Maybe we can abandon this
"test-first" mentality and adopt a "prove-last" one. I'd rather have
proven software than tested software. You can still test if you like
(as Knuth mentions). Then again, for a practical world its obvious
that despite the fact that empirical testing of software is almost
never perfect, clearly its "good enough".
Hopefully at this point, we can stop calling things like servlets and
web-services "computer science". I wear both hats, some days I'm a
groveling academic student and other days I'm a practicioner providing
solutions for a client. The most distinct element between science and
practice comes when I write academic versus business prose. As my
professor says about my dissertation, "you must be able to defend
every sentence". I've learned quickly (although sometimes I still make
mistakes when I context switch) about what and what-not to say in an
academic paper. Here's some examples:
* Never say anything is "optimal" unless you have concrete proofs.
We're not talking about amazing facts here, we're talking about
obvious stuff like "the shortest possible method is an empty method".
And darn it, your thingie better be optimal.
* Assume your reader is an accomplished computer scientist, but if you
use a word that isn't normal english, it better have a definition
first. Again, I'm not talking about "non-polynomial running time", I'm
talking about "parameter list".
* Empirical evidence is cute. But you better have a lot to make any
claims off it. Even then, you can only say what you have is of worth
"in practice". Unit tests won't get you anywhere with professors.
* For any algorithm that has any value in it - you best know whats
going to happen if that value were replaced by infinity.
Me: So the class has several methods and the algorithm examines each
one.
Professor: How long does that take? (he means algorithmically, not
wall time)
Me: Its linear - runs in O(n)
Professor: What if the class had BILLIONS AND BILLIONS of methods!???
HMM?
Me: Uh.. it can't. Java wouldn't support that. I think you can only
have like 256 methods or 32767 or something.
Professor: And what if it had an unbounded INFINITE number of methods?
What would happen THEN? hmm?
Me: It wouldn't because even if every Java programmer started typing
in methods in some grand coordinated method-creation effort and every
computer ran some method-creating program to help make more, we'd
still never get an infinite number of methods. Not to mention no
compiler or VM would accept such a class. Is this relevant?
Professor: And what if each of those methods had an INFIINTE number of
instructions and ran for an INFINITE amount of time? How long would
your little algorithm take THEN!?
Me: hrf.. um.. its linear.. runs in O(n). Which I suppose if
everything was INFINITE - it would be a really, really long fricken
time. But you and me and your dog too would be DEAD by then and we
wouldn't CARE anymore and my damn tombstone would say "DIED WAITING
FOR PHD DEFENSE" and yours would be like "DR. BOB PAINGIVER - I
SUCKED". Besides, most of the classes in question have only like 3
methods or so.
Professor: oh.
Unlike things like biochemisty, computers (and hence some computer
science) is actually fun to learn. Few people become accomplished
biochemists in their spare time. But plenty of folks gain useful
computer skills just by toying around. Its a pretty thin definition to
say that programmers with no formal computer science can't make good
computer programs. Of course they can. Languages like Java and C# have
built-in sandboxes to protect us from ourselves. Good algorithms are
buried away in collections libraries. How many programmers really know
how much faster a binary tree is over a hashtable for searching? Does
it really matter in commercial computer software? You might say yes,
but the truth is most software in existence today is written far from
algorithmically optimally. In other words, its "good enough". That may
stink, but its also the truth. It also may NOT stink - whats the
return on investment pristine computer science in business
applications?
The joke of the computer scientist not using email is not very
interesting to an actual computer scientist. Its like asking a
petroleum engineer if he knows how to drive an oil truck. Most
programmers today are practitioners because thats what businesses pay
for. If overseas programmers "suck" - don't worry, they'll get better.
And it probably won't mean anyone learns a whole lot more about
"computer science".
Printer Friendly Page
No comments:
Post a Comment