Re: Language Design Principles, was C++ intermediate representation.

Nick Maclaren wrote:
> Tom <rabbit@thehole.com> writes:
>
> |> I am reminded of Wirth's famous quote: "A language that is simple to
> |> parse for the compiler is also simple to parse for the human programmer,
> |> and that can only be an asset."
> |>
> |> [Wirth made many pithy comments, some of which have held up better in
> |> practice than others. It's often been noted that using a semicolon to
> |> separate statements as in Algol and Pascal is elegant but error prone,
> |> while using them to terminate statements as in PL/I and C is ugly but
> |> matches the way we think. Or, for a particularly egregious example,
> |> perl has its usability faults, but the difficulty of parsing it is
> |> down in the noise. -John]
>
> Correct. One of my mental designs includes some useful language
> features which are easily parsable by computers but a nightmare for
> humans. Consider a statement-based language, where the syntax is
> defined by a set of regular expressions and you can extend it by
> adding your own (subject to a few orthogonality and precedence rules).
> I don't mean SOME of the syntax - I mean ALL of the syntax. Yes, LISP
> was there first :-)
>
> 'Twouldn't be hard to do with a recursive descent parser and lexical
> analyser - integers with the digits backwards (but only in some
> contexts) and pseudo functions that deliver syntactic separators
> depending on the values of a (run-time) argument are merely two of the
> more obvious, er, uses. You can, of course, do something similar to
> the second with the C preprocessor.


I think I understand that you are rebutting Wirth's statement that
easy to compile is easy for humans, by counterexample. But what are
you arguing then? That easy to compile is irrelevant to
comprehension? Counterproductive to comprehension? Just an
interesting mental exercise?


As a formal proposition, Wirth's statement is clearly not universally
true. But it is inconceivable to me that easy to compile is not
highly correlated to human comprehension, looking at the real
programming languages we use and leaving out carefully constructed
counterexamples.


The correlation is also not that high if you are satisfied with
programmers' having only anecdotal understanding of their language,
i.e. they seldom venture outside a mental list of standard code
fragments of known meaning that they have seen before. Unfortunately,
my experience is that the majority of programmers, both students and
practitioners, have only such anecdotal understanding and have great
difficulty generalizing to new combinations of constructs. I
attribute this in no small part to languages whose "system" is highly
convoluted or unsystematic.


It also my experience that those who do have a complete understanding
of a confused language usually develop it only after extensive past
experience with a more simply-designed language.
[I dunno. My first language was Fortran, on punch cards, and it doesn't
seem to have damaged my comprehension too badly. -John]

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