[Edu-sig] RE: [Tutor] Off topic musings

Kevin Ollivier kevino@tulane.edu
Tue, 21 Aug 2001 00:48:15 -0400


I have to say I agree with Steve Morris here - I see programming and thus to
some extent software engineering as more of an art field than a science -
after all, you are simply expressing your ideas to a computer. The "science"
part is that you are given a solid, specific set of ways of expressing your
ideas, and that it resembles a mathematical language to some extent, but
that really hides the fact that you are still expressing ideas and can be as
creative as you want in devising a solution to a problem. As Steve said,
programming can be used to devise solutions to nearly any problem that comes
our way - they are now starting to teach computers to speak, etc.

Also, since a computer is a tool that we have created, we also control the
"laws" which govern the design, operation and use of this tool. As I see it,
laws are generally universal constants - a way to explain and predict the
behavior of natural forces. Laws mean nothing when you can change them at
will. We define the significance of bits and bytes, we create the
programming languages which we use to create software, etc. We can also
change those things, meaning they aren't held constant. The only 'laws' I
see as applicable to computer science are those that it uses in creating
these tools - i.e. electricity and conductivity.

I think I see what this discussion is trying to get at though - the
underlying abstract ideas which underscore software design. What is taught
in class for most computer science programs is a whole lot of math, a lot of
programming syntax, and all sorts of discussions of abstract programming
concepts like objects, recursion, etc. While that's all nice and good,
learning to code is not learning how to program. (Ever see a hacker write a
messy and buggy solution to a problem? I have. I've done it! ^_^) I think
what people are asking for are the "laws" of how to program - those few core
ideas which makes one master the 'art' of programming. Am I right on this?

Kevin

----- Original Message -----
From: "Morris, Steve" <smorris@cereva.com>
To: "Bruce Sass" <bsass@freenet.edmonton.ab.ca>
Cc: <edu-sig@python.org>
Sent: Monday, August 20, 2001 10:06 PM
Subject: RE: [Edu-sig] RE: [Tutor] Off topic musings


> > > Maybe. Really I'm just interested in what exactly a theoretical
>  > > basis for software engineering would look like. The papes I was
>  > > reading suggested that we may be reaching the point in CS
>  > > research where we cannot progress further without an underlying
>  > > theoretical base (like electrical theory underpins
>  > > electronics which
>  > > is in turn underpinned by atomic/molecular/ionic theory).
>
> I think you are comparing apples and oranges here. I think your vision of
> software engineering is too narrow. Electrical theory explains a finite
set
> of observed electrical properties. Software is a language that can express
> too much to be stated in a single theory. It is too expressive. You might
as
> well try to make a general theory of communication which covers all
possible
> communication, speech, evocation, persuasion, poetry, art and expression.
> Software engineering would then be a substantial subset of this general
> theory. In order to have a meaningful theoretical discussion you must
break
> down the subject into a finite set of rational observable components with
> observable relations between them. You then attempt theories to explain
what
> you observe. The problem with communication (of which software engineering
> is a subset) is that it is infinitely extensible. As long as there are new
> areas of software problems to solve we can't put a bound on it.
>
> It is not even clear what you mean when you ask what a "theoretical basis
of
> software engineering would look like." Engineering doesn't have theories.
> Science has theories; engineers apply these theories to solve specific
> problems. You would do better to think of a specific aspect of software
> engineering that you think needs explaination. Without specific questions
> you will never have useful theories. When you narrow your self to specific
> questions you will likely find plenty of literature that discuss them.
>
> Be careful or you will fall down the rabbit hole that has swallowed
literary
> criticism, chasing meaningless but pretty ideas that go nowhere, lost in
> endless reflections of ideas that seem like they must mean something but
> can't be nailed down. This is the curse of language, many more things can
be
> said than have meaning. You don't start with a theory, you start with
> specific questions and observations that need explaination. Theories
provide
> possible and hopefully testable explainations. The results suggested by
> these theories, once validated as useful and predictive, can be the basis
> for the next level of theories.
>
> Let me give a specific example. You don't ask for a theory of physics.
> Physics is too general a thing to have one theory. On the other hand we
have
> a set of theories which describe various fields; gravitation,
> electromagnetic, strong and weak forces. These theories are pretty mature
> and usefully and predidictively explain the specific fields. These field
> theories have a lot in common and now that they are well developed and
> tested it is worthwhile looking for a unified field theory in which the
> specific fields are merely special cases. Physicists have been hoping for
> this one for 80 years.  You try to build a general theory when the
specific
> theories are well understood. This does not describe the condition of
> software engineering or even of so called "computer science."
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>