Re: simple vs complex languages

nmm1@cus.cam.ac.uk (Nick Maclaren)
29 May 2003 03:03:32 -0400

          From comp.compilers

Related articles
[22 earlier articles]
Re: simple vs complex languages alexc@std.com (Alex Colvin) (2003-05-16)
Re: simple vs complex languages eas-lab@absamail.co.za (2003-05-18)
Re: simple vs complex languages jcrens@earthlink.net (Jack Crenshaw) (2003-05-24)
Re: simple vs complex languages jcrens@earthlink.net (Jack Crenshaw) (2003-05-24)
Re: simple vs complex languages jcrens@earthlink.net (Jack Crenshaw) (2003-05-24)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-05-29)
Re: simple vs complex languages nmm1@cus.cam.ac.uk (2003-05-29)
Re: simple vs complex languages hat@se-46.wpa.wtb.tue.nl (Albert Hofkamp) (2003-05-29)
Re: simple vs complex languages zivca@netvision.net.il (2003-05-29)
Re: simple vs complex languages vbdis@aol.com (2003-06-03)
Re: simple vs complex languages vbdis@aol.com (2003-06-03)
Re: simple vs complex languages bear@sonic.net (2003-06-03)
Re: simple vs complex languages lars@bearnip.com (2003-06-03)
[10 later articles]
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 29 May 2003 03:03:32 -0400
Organization: University of Cambridge, England
References: 03-04-095 03-05-182
Keywords: design
Posted-Date: 29 May 2003 03:03:32 EDT

Jack Crenshaw <jcrens@earthlink.net> wrote:
>Steve_Lipscombe@amat.com wrote:
>> Robert wrote
>>
>> >The thing that bothers me about all this fancy parsing technology we
>> >have developed over the past few decades is that it is solving an
>> >artificial problem. If we didn't design our programming languages to
>> >have such doggone complicated syntax, then we would be happy to use
>> >hand-written recursive-descent parsers.
>>
>> And our moderator replied
>>
>> >[I don't see why it's artificial. Human languages have very complex
>> >grammars. That's how we're wired to work. Why shouldn't computers
>> >adapt to us for a change? -John]
>>
>> I'm with Robert on this one.
>
>Me, too. I understand the notion that I'd rather have the machine do
>the work than me. The logical extension of making the program easy
>for the machine would be to write it in absolute binary. Then all the
>machine has to do is turn 1's and 0's into bytes.


Grrk. I don't think that this is quite it. Most natural languages
have a very simple syntax, but what they don't have is either a
well-defined separation between syntax and semantics or a precise
definition of what is valid syntax. English is extreme in both cases.


The need for programming, as with mathematics and serious science, is
something that is precise and unambiguous.


>Even so, it strikes me that, given a certain construct (variable
>declarations, for example), why would you choose a syntax that's hard
>to parse, over one that's easy? Unless there's a compelling advantage
>to the programmer for the hard-to-parse construct, I'd go for the one
>that's easy. My experience has been that one can usually think of a
>construct that's both comfortable for the user _AND_ easy to parse.


Yes. The real argument against complexity is that it leads to human
errors and often hides ambiguity. If you can't parse it easily, then
how can you be sure what it means?


Regards,
Nick Maclaren.


Post a followup to this message

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