Re: simple vs complex languages

Basile STARYNKEVITCH <basile@starynkevitch.net> 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.




Regards,
Nick Maclaren.

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