Re: simple vs complex languages

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.

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