Re: simple vs complex languages

Basile STARYNKEVITCH <basile@starynkevitch.net> writes:




> 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.


I agree wholeheartedly. The Smalltalk guys haven't completely
abandoned the idea, however: in Smalltalk, individual methods are
entered as text, but the higher-level structure like class definitions
and variable declarations are handled through tools. Furthermore,
Smalltalkers very rarely edit a text *file* that has source code in
it; they enter in the text into windows in the IDE, and the tools take
care of storing it off to the correct place (usually on a code server,
if it's a commercial project).


You would think Lisp guys do the same thing, but from the little I've
seen they tend to focus around files. Maybe I've had a limited view,
though; surely Lisp Machine users had nicer editors? It seems that
macroes complicate writing good tools, because they frequently
introduce new top-level organizational structures. It seems like a
good Lisp IDE would have to be extensible, so that users can tell the
tool how to browse new top-level forms as they are created.


> 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).


It's not *quite* as bad as you fear. Don't forget Emacs! For
example, in Emacs you can do "outline editing", where you can navigate
by structural elements instead of only by "line up", "line down", etc.
Also, outline editing lets you collapse and hide sections of the
program you are not looking at; eg this lets you look at the list of
top-level functions declared in a file and have them all fit on one
page.






Let me toss out one simple idea before leaving: Tool writers have
limited time. If the language's BNF fits on a page, then the
implementation is often quite simple and the tool writer can focus on
other things. If the tool writer uses an interpreter instead of a
compiler, at least initially, then again more time is saved and
furthermore the tools are easier to implement and can be more
powerful. And if the language designer starts thinking about static
typing systems, then they may spend the rest of their career on it.


I believe that tools make a *huge* difference in programming ability
-- even more than static checking tools and lint tools. Good
debuggers, good code navigation tools, and fast edit-run cycles all
seem to make a big difference in getting a program running and tested.
Checking tools are certainly nice, but I hate seeing languages where
the checking gets in the way of the tools. If you can forgive me for
whipping some flames a moment, please note that you cannot currently
have a Smalltalk-like environment if your language has a typical type
system: when you change the code, most of your live data becomes
stale; thus you cannot grow your data in parallel to the code.




-Lex

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