hascall@cs.iastate.edu (John Hascall) (02/03/90)
[Note: this has nothing at all to do with #define OR || argh!!!]
**** Hopefully that horse has had enough, so I offer up my own. ***
Inside the front cover of "Principles of Programming Languages",
by Bruce J. MacLennan is the list:
ABSTRACTION: Avoid requiring something to be stated more than
once; factor out the recurring pattern.
AUTOMATION: Automate mechanical, tedious, or error-prone
activities.
DEFENSE IN DEPTH: Have a series of defenses so that if an error
isn't caught by one, it will probably be caught be another.
INFORMATION HIDING: The language should permit modules designed
so that (1) the user has all of the information needed to use
the module correctly, and nothing more; (2) the implementor
has all the information needed to implement the module correctly,
and nothing more.
LABELING: Avoid arbitrary sequences more than a few items long;
do not require the user to know the absolute position of an item
in a list. Instead, associate a meaningful label with each item
and allow the items to occur in any order.
LOCALIZED COST: Users should pay for what they use; avoid
distributed costs.
MANIFEST INTERFACE: All interfaces should be apparent (manifest)
in the syntax.
ORTHOGONALITY: Independent functions should be controlled by
independent mechanisms.
PORTABILITY: Avoid features or facilities that are dependent on a
particular machine or a small classs of machines.
PRESERVATION OF INFORMATION: The language should allow the
representation of information that the user might know and taht
the compiler might need.
REGULARITY: Regular rules, without exceptions are easier to learn,
use, describe, and implement.
SECURITY: No program that violates the definition of tha language,
or its own intended structure, should escape detection.
SIMPLICITY: A language should be as simple as possible. There
should be a minimum number of concepts with simple rules for
their combination.
STRUCTURE: The static structure of the program should correspond
in a simple way with the dynamic structure of the corresponding
computations.
SYNTACTIC CONSISTENCY: Similar things should look similar, different
things different.
ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and
infinity.
What I am curious about is:
How do you think C scores using this list as a measure?
Specific examples? Counter-examples?
What do you think of the list? What's missing? What's
extra? What's insightful? What's just plain wrong?
Everyone wants to be a language (re-)designer...hopefully with this list
we have the framework for a rational discussion.
John Hascall / ISU Comp Ctr / hascall@atanasoff.cs.iastate.edu
Ante mare et terras et quod tegit omnia caelum unus erat toto naturae
vultus in orbe, quem dixere chaos: rubis indigestaque moles... Oviddmocsny@uceng.UC.EDU (daniel mocsny) (02/03/90)
In article <490@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: [...] > SIMPLICITY: A language should be as simple as possible. There > should be a minimum number of concepts with simple rules for > their combination. [...] > What do you think of the list? What's missing? What's > extra? What's insightful? What's just plain wrong? I agree that a language should be as "simple" as possible, but how simple can a language be, and still be a useful tool for building the complex applications users demand? (Note: I include libraries in what I refer to as "language," since the programmer must assimilate their calling syntax just like the underlying language itself.) If the application is inherently complex, the complexity has to show up somewhere. If the complexity isn't in the "concepts" or the "rules for their combination," then it will be in the sheer number and detail of those combinations. TANSTAAFL and all that. I think "simple" languages and programs are useful primarily for complex (i.e., expert) users, people who are willing to spend 10x as much effort poring through manuals as actually running anything. The other 99% of humans have other responsibilities and interests besides keeping the computer happy. They require "bells and whistles", such as a program that takes care of its own errors, and can explain clearly at any time how the user may take advantage of it. Writing programs such as this forces the programmer to confront an enormous amount of detail. If the language does not embed this detail in its "simple" syntax, then it has to embed it in its libraries. So perhaps "simplicity" is not so much what we want, but grace in handling the complexity we can't avoid? In other words, striking a reasonable balance between capability and complexity. Dan Mocsny dmocsny@uceng.uc.edu
peter@ficc.uu.net (Peter da Silva) (02/04/90)
In article <3526@uceng.UC.EDU> dmocsny@uceng.UC.EDU (daniel mocsny) writes: > I agree that a language should be as "simple" as possible, but how > simple can a language be, and still be a useful tool for building the > complex applications users demand? Let me refer you to Forth. :-> -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) (02/09/90)
On 2 Feb 90 21:29:25 GMT, hascall@cs.iastate.edu (John Hascall) said: John> Inside the front cover of "Principles of Programming Languages", John> by Bruce J. MacLennan is the list: ... John> ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and John> infinity. On most of the points I agree. However, this restriction seems a bit bizarre. It may be inelegant, but I admit to liking the raw mathematical power that comes from being able to express the number "42", for example. :-) Could you provide a bit more context to this? I have a nagging feeling I must be missing something. -- Chuck Phillips -- chuckp%ncr-fc.FtCollins.NCR.COM uunet!ncrlnk!ncr-sd!chuckp%ncr-fc ccncsu.ColoState.EDU!chuckp%ncr-fc
henry@utzoo.uucp (Henry Spencer) (02/10/90)
In article <CHUCKP.90Feb8095934@halley.ncr-fc.FtCollins.NCR.com> chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) writes: >John> ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and >John> infinity. > >On most of the points I agree. However, this restriction seems a bit >bizarre... Could you provide a bit more context to this? ... The point of this rule, which goes back a long way, is that an arbitrary limit will usually get in the way eventually. If the system only allows you ten file descriptors, somebody will come up with a program that wants eleven and gets horribly contorted if it has to work within the limit. If your language limits arrays to a maximum of three dimensions, somebody will need four. And so on. The only good numbers are zero (don't do it at all), one (do it but don't let the issue of "how many" come up), and infinity (let the user decide how many he wants). -- SVR4: every feature you ever | Henry Spencer at U of Toronto Zoology wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mikes@rtech.UUCP (Mike Schilling) (02/11/90)
From article <1990Feb9.181942.24649@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): > In article <CHUCKP.90Feb8095934@halley.ncr-fc.FtCollins.NCR.com> chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) writes: >>John> ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and >>John> infinity. >> >>On most of the points I agree. However, this restriction seems a bit >>bizarre... Could you provide a bit more context to this? ... > > The point of this rule, which goes back a long way, is that an arbitrary > limit will usually get in the way eventually. > ... > The only good numbers are zero (don't do it > at all), one (do it but don't let the issue of "how many" come up), and > infinity (let the user decide how many he wants). I also remember a suggestion that languages force symbolic names to be used for constants other than zero and one, to make it harder to embed magic numbers in code. I think this was Glenford Myers's idea.
john@hcr.uucp (John R. MacMillan) (02/13/90)
In article <4721@rtech.rtech.com> mikes@rtech.UUCP (Mike Schilling) writes: |From article <1990Feb9.181942.24649@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): |> |> The point of this rule, which goes back a long way, is that an arbitrary |> limit will usually get in the way eventually. |> ... |> The only good numbers are zero (don't do it |> at all), one (do it but don't let the issue of "how many" come up), and |> infinity (let the user decide how many he wants). | |I also remember a suggestion that languages force symbolic names to be used |for constants other than zero and one, to make it harder to embed magic |numbers in code. I think this was Glenford Myers's idea. average = (a + b) / TWO I think I'll buy Henry's explanation, but the other one seems a bit silly. -- John R. MacMillan | For a long time I felt without style or grace HCR Corporation | Wearing shoes with no socks in cold weather {utzoo,utcsri}!hcr!john | -- Talking Heads
hascall@cs.iastate.edu (John Hascall) (02/13/90)
Mike Schilling writes: } Henry Spencer writes: }> Chuck Phillips writes: }>>John> I write: }>>John> ZERO-ONE-INFINITY: The only reasonable numbers are zero, one, and }>>John> infinity. }>>On most of the points I agree. However, this restriction seems a bit }>>bizarre... Could you provide a bit more context to this? ... }> The point of this rule, which goes back a long way, is that an arbitrary }> limit will usually get in the way eventually. Ok, let's talk C with regard to this. Off the top of my head I can think of the mystic number 509, are there others? }I also remember a suggestion that languages force symbolic names to be used }for constants other than zero and one, to make it harder to embed magic }numbers in code. I think this was Glenford Myers's idea. A good idea, although I do recall seeing an such an exhortation using PI as the example (in case the value of PI should change! :-) John Hascall / ISU Comp Ctr, Ames IA / hascall@atanasoff.cs.iastate.edu p.s. Is it my imagination or are attribution lines becoming like .signature lines (that is, overblown)? Do we really need: In article <180 bytes of crap> so-and-so "127 bytes of personal name" writes:
hascall@cs.iastate.edu (John Hascall) (02/17/90)
In article <1990Feb13.153513.2196@hcr.uucp> john@troch.UUCP (John R. MacMillan) writes: }In article <4721@rtech.rtech.com> mikes@rtech.UUCP (Mike Schilling) writes: }|From article <1990Feb9.181942.24649@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer): [Zero, one, infinity rule] }|I also remember a suggestion that languages force symbolic names to be used }|for constants other than zero and one, to make it harder to embed magic }|numbers in code. I think this was Glenford Myers's idea. }average = (a + b) / TWO (people who do: #define 2 TWO, #define 3 THREE, ... should be beaten) ;-) #define N_TERMS 2 ==> #define N_TERMS 3 average = (a + b) / N_TERMS; ==> average = (a + b + c) / N_TERMS; John Hascall / hascall@atanasoff.cs.iastate.edu
peter@ficc.uu.net (Peter da Silva) (02/19/90)
In article <645@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: > (people who do: #define 2 TWO, #define 3 THREE, ... should be beaten) ;-) > #define N_TERMS 2 ==> #define N_TERMS 3 > average = (a + b) / N_TERMS; ==> average = (a + b + c) / N_TERMS; #define AVERAGE(a,b) (((a)+(b))/2) Sometimes a number is the best thing to use. It's a judgement call. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
jharkins@sagpd1.UUCP (Jim Harkins) (02/20/90)
In article <645@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: > (people who do: #define 2 TWO, #define 3 THREE, ... should be beaten) ;-) often and for long periods of time... > > #define N_TERMS 2 ==> #define N_TERMS 3 > average = (a + b) / N_TERMS; ==> average = (a + b + c) / N_TERMS; I'm not sure what point your making here, but how about this_average = (a + b) / 2; that_average = (c + d + e) / 3; I think the point is that while using symbolic constants is usually a good idea, changing the word "usually" to "always" makes for a terrible rule. Lets consider this beaten horse dead. -- jim jharkins@sagpd1 "I've found by and large that when the flu gets you, the best thing to do (other than go to bed, which is boring) is to go conquer something." -Jerry Pournelle