[PREV - COMP_SIGH] [TOP]
DIVISION
March 31, 2023
April 05, 2023
April 08, 2023
Some remarks by Brian Harvey, in
a lecture for an introductory CS 61A, Spring 2008, "The Structure
programming class at Berkeley and Interpretation of Computer Programs"
(paraphrased from memory):
"The thing about Computer Science is that it's not a Science,
and it's not about Computers. The discipline that's about
computers is called Electrical Engineering. And Computer
Science isn't a science, because for the most part we don't
do experiments to find out what reality is like. We invent
things, like engineers. So it's a funny name for the field
that we're in. And what we need to teach you is not how to
program computers. Programming computers is really really easy.
The world is full of 12 year old computer programmers.
And some of them sell them and make a lot of money with
them."
"So it's easy to do, as long as your project is small enough
that it can fit in your brain at the same time. When it gets
hard is when your project gets big enough so that when you're
working on this piece over here, you can't remember what you
did on that piece over there. And what we need to teach you ...
is how to cope with complexity in programming projects.
And the basic idea is that you invent a system in which you
can divide your projects into chunks ..."
So far so good. Divide-and-conquer is indeed almost
the only shot in our locker as programmers.
Then Brian Harvey remarks:
"... the way that you avoid
stepping on your own feet is
called a 'programming paradigm'"
Now... I know what he means here. One of the quirks of the CS
Where this course is going is he faith is that functional
wants to talk about "Functional programming is regarded with
Programming", then move from there tremendous respect, though it's
to "Objected-Oriented Programming". typically acknowledged you won't
usually want to do it that way.
These are indeed two different
organizational strategies-- I
would be inclined to call them
"doctrines" rather than
"paradigms", myself, where the Actually, the course description calls
word "doctrine" is intended to them "techniques of abstraction", which
make it clear that we have no hard again doesn't seem *quite* accurate.
data about which one is better, we Your divide-and-conquer strategy will
just have true believers. often involve abstraction, but what's
really needed is isolation-- components
Living in a world with multiple need to be understood independently,
doctrines, if you want to avoid written and tested on their own.
incessant religious wars, you Abstraction is useful to reduce the
tend to make moves like this: the number of components, but that's
"we must respect others personal typically less critical. (It also
choices" and so we avoid doesn't always save any work-- there's
declaring that one is better a phenomena of "over-engineering".)
than the other-- and here even
the suggestion that one might
some day be shown to be better
than the other is avoided.
Because then, you know, you might think that a A complaint I make
"Scientist" should try to contrive experiments every-other-day.
to prove which is better.
Calling them "paradigms" is a little
problematic, I would say, because the
Kuhn version of a paradigm is a way of
understanding the world that tends to
push out other ways of understanding. THE_PARADIGM_PARADIGM
In Kuhn's model, a human being has
trouble thinking in two different
paradigms-- here the CS student is
expected to be able to learn both It's also problematic to
approaches and hold both of them in insist that using a
their heads, enabling them to switch paradigm is *the* way
between them. of managing complexity.
So then, perhaps, the trained There are other ways:
Computer Scientist is expected Probably the most
to be able to choose an common one is to use
appropriate s paradigm for the existing software
task at hand? So then, there' components:
some sort of meta-doctrine, a
way of choosing which doctrine operating systems,
is appropriate... databases,
web servers,
interpreters/compilers
But if your programmer's know
multiple paradigms-- being
all CS trained and all-- Then there are other
wouldn't you expect them to ancilliary doctrines like
switch back and forth among test-oriented design
them on the fly? which are orthogonal
choices like functional
vs. oop.
Using a "multi-paradigm" language
like Raku, a programmer might, for (Us computer nerds like
example, favor object-oriented to use "orthogonal" to
design, but switch to functional mean "unrelated to".)
approaches inside the objects when
that seems appropriate. It could Then there are developer's
be there's a "multi-paradigm" tools which might be
style that's not confined to one regarded as part of a
or the other. "chunk management"
strategy: version control,
debuggers, IDEs...
--------
[NEXT - GOTO_ALAN_KAY]