Best Computer Science School in Utah

Levi Pearson levi at
Wed Sep 26 12:55:18 MDT 2007

Paul Seamons <paul at> writes:
> Hoisting theories to fact.  These are the problems I am talking about.  CS 
> proofs are one thing, but theories are another entirely.  History has many 
> examples in all fields where great advances because theories were ignored 
> (but more cases exist where failures were made because good theories were 
> ignored).

I think we're going in circles with the word 'theory'.  It's a
hot-button word these days, and it's getting pulled all over the place
by people with agendas.  Let me clarify:

By CS Theory, I mean the body of knowledge about computing, what is
computable, and how to compute things.  This is one half of the
theory/practice dichotomy, where theory is knowing and practice is
doing.  It is descriptive and analytical, being primarily based in
mathematics.  Think 'music theory', not 'theory of relativity'.

I most emphatically do not mean 'theory' as in a conjecture as to what
the answer to an unsolved question is.  Although we may 'theorize' in
this sense that P != NP, and it may be useful to do so to consider
what the implications would be, considering that it is most likely
true, that's not the sort of 'theory' I'm talking about.

> My fault in using too much hyperbole with words such as impossible.  My 
> argument is closer to saying that lack of training sometimes allows one to 
> focus on the problem rather than become mired in details (you may not cover 
> every edge case, but that's ok some of the time).

I don't think lack of training in CS gives any advantage in this case.
Being trained in CS theory may actually give you an advantage, since
you may be able to quantify just how okay it is to get non-optimal
solutions, and have some sort of idea what the tradeoffs are.

The only advantage I see would be that you hadn't spent a lot of time
learning CS theory, so although you would be flying somewhat blind,
you would be doing it earlier and might be lucky enough to hit on
something that works.

>> Despite your words, no one is going to successfully build a 
>> perpetual motion machine, because such things are impossible.
> And there is a proof to back it up (well in this case a law), not a theory.

The laws of thermodynamics are based on physics, which are based on
the fuzzier sense of theory that I said I wasn't using.  However,
they're very well-supported theories that have a whole lot of evidence
to back them up.  That's the best we can hope for in physics unless
God tells us the real axioms he used to design the universe.

There is still a very, very remote chance that they're wrong in some
very unlikely cases, but I wouldn't bet on it.  

<our argument about usefulness of learning CS clipped>
> Actually, I've always wished I'd double majored or at least minored
> in CS.  I guess an ounce of hindsight...

I'm afraid I have ascribed more anti-CS sentiment to you than you
actually hold.  I'm sorry.  I guess I misunderstood your response to
Hans's statement about the fundamental nature of CS theory.

> That wasn't my example.  My example wasn't about the procedure the surgeon was 

I know what your example was, but I didn't think it was a very good
analogy and I offered one that I thought fit better to the
relationship between a programmer and Computer Science.  Computer
Science doesn't provide scalpels, it's provides surgical techniques,
procedures, and knowledge about how the body works.  Electrical
Engineering provides the scalpels.  Computer Scientists don't
generally worry much about those, either, probably even less than
programmers in general

> Ding ding ding.  Yes.  My points exactly.  We have tools (higher level 
> languages) that have abstracted the science away that let us solve complex 
> problems.  Ah, we are finally on the same page.

I'm afraid I didn't see those points in what you were saying, but I'm
glad we're in agreement.

> In programming sometimes I find a tool lacking and I start looking
> for a solution.  In these cases I've wished a had more CS experience
> so I could better create my own tool.  But for the most part I use
> my database without working about database engine design, I use my
> webserver without worrying about tcp or protocol or network, I use
> my language of choice without worrying about compilers or assembly,
> I use my objects without worrying about object theory, and so on and
> so on.  Sometimes I have to worry about these things, but I'm glad
> that in my job as a programmer, most of the time I don't have to
> worry about my tools, I just have to know how to use them.

The guys who build your house don't know much about mechanical
engineering, either, but they're pretty good with nail guns and
circular saws.  Just don't ask them to make any major deviations from
the plan they were given, though, or you could end up with structural
problems.  Eliminating a load-bearing wall could be disasterous,
sooner-or-later, but you've either got to have a strict building code
or a knowledge of the structural properties of your building materials
in order to ensure you've built a safe house.

Software isn't well-understood enough yet to have well-defined
building codes.  It's way, way more complex than the structural
analysis of a house, and without the regularity that you get in
construction.  I'm not sure we'll ever have in software the sort of
design safety net that the Building Code provides to physical
construction work.  Meanwhile, builders of software need a far deeper
knowledge of what they're doing than the builders of homes if they
want to end up with a quality product.

> It is the MacGyverism thing all over again.

I have to admit I don't see how MacGuyver fits into this, either.
Surely he's got a pretty deep knowledge of physics, chemistry, and
mechanical engineering, or else he wouldn't know what bits of random
stuff to throw together to get his desired results.


More information about the PLUG mailing list