A few things I would like to see in a new programming language.

"Eric Merritt" <cyberlync-/[email protected]> Sun, 03 Aug 2003 15:27:24 -0000
Newsgroups	gmane.comp.programming.pragmatic
Message-ID	<[email protected]>
Forwarded from pragprog.

--- Aaron Optimizer Digulla <[email protected]> wrote:
> Hello,
> 
> Just to give a short introduction for myself: I'm a
> senior software
> developer and in the last 15 years, I've used a host
> of different
> programming languages. I'm an experienced C and Java
> programmer,
> I use Python regularily as well as Perl and shell
> scripts.
> 
> Note that I don't think of myself as an experienced
> C++ programmer;
> I don't like C++ very much (as well as Perl). I
> don't think that I
> need to tell you why I don't like them; you probably
> already know :-)
> 
> From my experience, I would like to see this in a
> new
> programming language:
> 
> 1. It should allow for variable constraints.
> 
> Most of the time, I'm doing dull work, ie. things
> that rarely
> break, for example reading from a file that exists.
> I *know*
> that it exists.
> 
> Java forces me to handle exceptions that don't
> happen.
> 
> What I want is to be able to choose this mayself. I
> want to
> be able to modify the contraints under which my
> language
> operates and even add to them.
> 
> During development, I want to be able to say "this
> number should
> never be below 0 or above 10" or "I will never add
> Null-keys
> to that hashmap". I want the runtime to be able to
> check
> these things and warn me about them but I don't want
> it to
> *bother* me.
> 
> And I want to be able to turn these things off at
> any time when
> they start to bother me (performance, for example).
> 
> Think of this as a kind of embedded unit tests.
> 
> 
> 2. The language should have an extensible syntax. I
> want to be
> able to work with HTML as HTML and not as some kind
> of strange,
> mangled syntax to suit my compiler. At runtime, I
> want to be
> able to define:
> 
>     A is a HTML variable.
>     B is a HTML variable.
> 
>     A = <HTML><HEAD></HEAD><BODY></BODY><HTML>;
>     B = <TITLE>Some text</TITLE>
> 
>     A/HTML/HEAD += B;
> 
> and I want the compiler to abort on this with "Error
> in
> line 4: <HTML> must be terminated with </HTML>". And
> when I fix that, I want A to contain:
> 
>     <HTML><HEAD><TITLE>Some
> text</TITLE></HEAD><BODY></BODY><HTML>
> 
> and then:
> 
>     fh = open('index.html', 'w')
>     fh.write (A)
>     fh.close ()
> 
> to write that in some useful form into a file.
> 
> 
> 3. The syntax *must* be simple. Think of Python vs.
> Perl.
> Python code is (usually) easy to understand because
> it
> enforces some rules (you *must* indent properly, or
> the
> program won't run). Perl, on the other hand, likes
> to put
> as much into one statement as possible with a lot of
> possible
> shortcuts which save time for someone who is a Perl
> interpreter
> but makes it hard for everyone else to grasp.
> 
> So the language should be more simple to use when a
> simple syntax
> is used. It should not force people to use a simple
> syntax
> but encourage it. Eventually, people (lazy as they
> are) will
> use the simple syntax rather than making their lives
> more
> complicated than necessary.
> 
> To take the quicksort example from the Haskell
> introduction:
> 
>     qsort []     = []
>     qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort
> elts_greq_x
> 		     where
> 			elts_lt_x   = [y | y <- xs, y < x]
> 			elts_greq_x = [y | y <- xs, y >= x]
> 
> I would prefer:
> 
>     qsort []     = []
>     qsort (x:xs) = select y from xs where y < x
> 		    + [x]
> 		    + select y from xs where y >= x
> 
> or maybe:
> 
>     qsort []     = []
>     qsort (x:xs) = select (y, xs, y < x)
> 		    + [x]
> 		    + select (y, xs, y >= x)
> 
> Why? Well, the Haskell states that it is a purely
> functional
> language. Unfortunately, humans aren't functional.
> We tend to
> break things down until we can chew them and we
> think serially.
> 
> When you know the syntax of haskell, it's simple to
> understand
> that the "qsort (x:xs)..." line needs you to
> understand the next
> three lines to make sense of it. But our memory can
> only work
> with 3-7 items of information at the same time. So
> when things
> become more complex, we are easily lost (-> make
> more mistakes
> -> which are harder to find, etc).
> 
> Therefore, it should be possible to understand the
> program when
> reading it in a natural way. Lines at the top should
> not need
> to reference things which are below. When you are
> writing a book,
> you are warned to reference material which is
> explained further
> on. Why do language developers insist that their
> languages are
> "more simple" when they break this golden rule?
> 
> In the end, even a fool should be able to write
> working
> programs.
> 
> Because you are bound to have to work with one some
> way and
> you don't want to waste your time running behind his
> bugs.
> 
> Or, maybe even more importantly, a fool should be
> able to
> understand a program. Think manager here or someone
> who just started
> to learn programming. With some languages, I get the
> strong
> feeling that one of the major design concepts was
> "learning
> by frustration".
> 
> As a genius once said: It's simple to say something
> in a
> complex way but to say it simple, it takes a genius.
> 
> 
> KISS,
> 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Free shipping on all inkjet cartridge & refill kit orders to US & Canada. Low prices up to 80% off. We have your brand: HP, Epson, Lexmark & more.
http://www.c1tracking.com/l.asp?cid=5510
http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/