Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!uwvax!oddjob!nucsrl!morrison
From: morrison@nucsrl.UUCP (Vance Morrison)
Newsgroups: comp.lang.misc
Subject: Language tools for good code
Message-ID: <4000009@nucsrl.UUCP>
Date: 22 Jan 88 22:34:01 GMT
Organization: Northwestern U, Evanston IL, USA
Lines: 96



Hello,

	These are some of my recient thought on programming languages 
that I thought I would share with the net.

	I have been programming for many years now, and to the best of
my abilities I have tried to write what I term 'good code', and have found
that its has always been a struggle that I don't often win in traditional
programming languages (c, pascal etc).

	My pet project at the moment is to design a programming environment/
language that would make writing 'good code' very easy, in fact easier than
writing the equivalent bad code (if possible).  Now I realize that this is
no small project I undertake, and that many very smart people have tried to
solve this problem and had only limited success, so I actually don't expect
success, but I do hope to add my insight to theirs, and thus come that much
closer to the goal of a 'perfect language'.

	So lets attack this systematicaly, by first describing what I mean
by 'good code'.  I think THE property that seperates good code from bad
code is the ease in which it can be understood and CHANGED.   Anyone who
has done any real programming will tell you that any software worth writing
has to continually be upgraded and extended if it is to be a useful product.
Good code allow these changes to be done easily.

	The key tool we use to design good code is MODULARITY.  Everyone
knows (or should know) from their first programming courses how to break
up a problem into parts with procedures.  Unfortuately this is the extent
of the tools that many programming languages have for supporting modularity
and it simply just isn't enough.  

	What I mean by modularity is something much more broad than its
meaning when most people use the word.   When a program is designed, many
assumtions are made on the format and structure of the data being processed.
These assumtions does not make the code bad, in fact, ANY piece of code has
SOME assumtions about the format and structure of the data.  The KEY is 
to try to make these assumtions as independent as possible (that is any
assumtion can be changed with only minimal impact on any of the other 
assumtions).

	I could give many examples of how good code has this  'assumption'
independence and how bad code does not have this feature.  I also have
many rather radical ideas on how to design a language that makes doing
to a high degree this easy (or even possible!), but if I include them now
this letter will take forever to write, so instead I would like to stop
here and check on the responce of what I have written so far.

	First of all Does everyone with my definition of good code, that
is code that can be understood and changed easily?

	Second does everyone understand my concept of 'assumption 
independence', and agree that code that has this feature is 'good code'?
(now I do not believe total 'assumtion independence' is possible, but
we should try the best we can, that is we should make the most likely
features that could change in a program independent of one another so
that only small portions of the code need to be rewritten if a feature
need to be changed.)

	Third, does everyone agree that present languages do not provide
good tools for makeing design assumptions as independent as possible?
I will come up with some examples if necessary, but I am far from familiar
with many languages, so maybe someone knows of a language that provides
good tools.  

	Finally does anyone have any good ideas on what kind of tools
are needed?  I am particulary interested in the answer to this question,
since I have not yet answered it to my satisfaction, but I do have some
ideas.  I am also interested in common problems a good language should
solve cleanly (eg error handling, device independence etc), so let me
hear from you.

	I will write again on my ideas in trying to answer this last
question in latter postings if there is interest, but I will give you
certain hints now.  May I say that I do NOT like the idea with a language
with many features.  It makes the language impossible to learn and you
will undoubtedly find that you forgot something.  In some ways the
language must be 'programable' so that 'library implentors' can add
features to the language as needed for a particular set of problems.
This programmability has to be limited, however, otherwise every programmer
programs his own varient and no one can read anyone else's code.  

	Well that is enough of a brain teaser.  I hope that there is
interest in this question, because I think it is a VERY important and
practical one.  I also hope that I have given many intelegent people on
the net some food for thought.

	So lets hear from you.

					Vance Morrison
					Northwestern Univ

					morrison@northwestern.arpa
					morrison@accuvax.nwu.edu
					morrison@nuacc.bitnet