Re: language design tradeoffs

bks@s27w007.pswfs.gov (Bradley K. Sherman)
Thu, 17 Sep 1992 22:42:37 GMT

          From comp.compilers
Related articles
[12 earlier articles]
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-17)
Re: language design tradeoffs jch@rdg.dec.com (1992-09-17)
Re: language design tradeoffs firth@sei.cmu.edu (1992-09-17)
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-17)
Re: language design tradeoffs norvell@csri.toronto.edu (1992-09-17)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-17)
Re: language design tradeoffs bks@s27w007.pswfs.gov (1992-09-17)
Re: language design tradeoffs raveling@Unify.com (1992-09-17)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-18)
Re: language design tradeoffs e86jh@efd.lth.se (1992-09-19)
Re: language design tradeoffs maniattb@cs.rpi.edu (1992-09-19)
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-20)
Re: language design tradeoffs eifrig@beanworld.cs.jhu.edu (1992-09-19)
[18 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers,comp.human-factors
From: bks@s27w007.pswfs.gov (Bradley K. Sherman)
Organization: Institute of Forest Genetics DataBase
Date: Thu, 17 Sep 1992 22:42:37 GMT
Keywords: parse, design
References: 92-09-048 92-09-102

As someone who has had to look at ugly code in several ugly languages and
make small (hah!) modifications here's my wish list:


        1) Just say NO to else!
                        if ( x) ...
                        if (not x) ...
              or
                        case (x) of
                        a | ...
                        b | ...
                        c | ...
            can remain. Nested and multiple elses are the devil's playground.


        2) Delimit the code, not the comments.
              I'm prepared for _every_ keystroke in a computer language to be
              exact. I'd like more freedom in constructing the commentary.


        3) No macros or overloading.
              Sorry, but x + y means add y to x. I do not want it to mean
              place object y on window x. Likewise I do not want func(x,y)
              to silently be replaced by func2( x + 1, func3(y - x)).


        4) No lines of over 79 columns allowed.
              Nothing is harder to read than code which disappears off the
              sides of the screen, or worse, slops over onto the next line
              completely ruining the advantages of careful composition.


        A former maintenance programmer,
        --Brad Sherman
--

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.