Re: simple vs complex languages (Nick Maclaren)
12 May 2003 01:30:33 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: simple vs complex languages (Basile STARYNKEVITCH) (2003-05-05)
Re: simple vs complex languages (2003-05-05)
Re: simple vs complex languages (Albert Hofkamp) (2003-05-06)
Re: simple vs complex languages (2003-05-06)
Re: simple vs complex languages (Scott Moore) (2003-05-06)
Re: simple vs complex languages (2003-05-06)
Re: simple vs complex languages (2003-05-12)
Re: simple vs complex languages (George Richard Russell) (2003-05-12)
Re: simple vs complex languages (2003-05-12)
Re: simple vs complex languages (David Spencer) (2003-05-12)
Re: simple vs complex languages (Thant Tessman) (2003-05-12)
Re: simple vs complex languages (2003-05-12)
Re: simple vs complex languages (2003-05-12)
[29 later articles]
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 12 May 2003 01:30:33 -0400
Organization: University of Cambridge, England
References: 03-04-095 03-04-112 03-05-006
Keywords: parse, design, visual
Posted-Date: 12 May 2003 01:30:33 EDT

Basile STARYNKEVITCH <> writes:
|> I agree with Ralph and the original poster, but there is one
|> additional point about computer languages: they are still, like in the
|> 1950's, plain textual files. Of course, every language has its syntax
|> and semantics, but we still are using editors, and more importantly,
|> the model of sources files, conceptually the same as punched card
|> decks!

Paper tape, please! Seriously.

|> I really think it is a pity that no language offers a fancier
|> interface than plain textual files, typed thru an editor. The syntax
|> directed editors of the late 1980's are gone.

Thank heavens! Having been inflicted with a little of that, I never
want to see it again.

|> It is a pity that no [major] programming language accept HTML pages
|> (or even .doc documents,...), or even provide its own fancy editor. In
|> particular, integrating some ideas from the literate programming
|> movement inside programming languages is not done. Comments are still
|> simple sequence of characters (perhaps with a specific markup like in
|> javadoc or ocamldoc). Our program sources are not hypertextual (even
|> if a few research papers mention this).

Well, let's ignore the minor (?) detail that those are even less
well specified and syntactically complex than a badly designed
programming language.

What do you do when you get a compiler or, worse, editor bug, deep
in the middle of 100,000 lines of a complicated, recursive document?
Please note "when" not "if".

|> I think that is is mostly a chicken & egg issue: no languages is
|> non-plain-textual because no editor is able to edit them, and vice
|> versa. (and also, major editors like emacs offer sufficient "modes"
|> for programming languages).

That is part of it. Another part is that it was tried out and found
to be a disaster.

Language sensitive editors are only borderline useful, at best, and
the same applies to Emacs modes. In particular, you DON'T think about
or write a complex piece of code sequentially, let alone in parsing
order - you 'paste' it together from basic concepts and then smooth
off the incompatibilities. Many such editors will not permit you to
create even a temporarily syntactically invalid construction.

That excludes the major factor that any programmer who deals with
multiple data formats doesn't want to learn a radically different
editor for every format.

|> Perhaps also researching on newer forms (hypertexts, fancy editors) of
|> source program is not fancy enough for academics (or for funding). I
|> still find it a pity.

It was done back in the 1970s, to some extent.

|> I'm dreaming of a major [opensource preferably] fancy (perhaps
|> functional) language with a better editing mode than Emacs. I'll
|> probably dream for a long while!

Try designing one and discover the problems even in that! It isn't
clear that it is a fundamentally impossible task to create a useful
such language/editor combination, but it is assuredly a fiendishly
difficult one.

Nick Maclaren.

Post a followup to this message

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