Re: Language support for flexible handling of system-detected errors.

[hack@watson.ibm.com (hack)]

In article <5ly9gcd9ao.fsf@rum.cs.yale.edu>,
Stefan Monnier  <foo@acm.com> wrote:
>>>>>> "Maynard" == Maynard Handley <name99@mac.com> writes:
>> Languages that don't provide what current programmers want and expect are
>> dead. You can whine all you like about how much I suck because I expect an
>> IDE, but I am simply telling you the way it is.
>
>That's a curious definition of "dead" which seems strangely close to the
>definition of "non-mainstream".
>
>
>	Stefan "being an Emacs hacker, I'm obviously biased"

I sure hope you are (biased)!  To me, something like emacs is an Integrated
Development Environment -- if only the compilers and linkers etc. would all
cooperate.  Traditional IDEs are the exact opposite -- they are a world unto
themselves.  I use an IDE in the emacs sense -- I integrate multiple envs
into one global environment where I can use *all* my tools, in the editor
that I'm familiar with, exploiting its features across all those environments
(programmability via powerful macros, generalised multiple-level UNDO, having
many files in simultaneous play, etc.)  The files may come from mainframes,
from Unix boxes, or from NT boxes -- it's all integrated.  I can click on a
function invocation and find myself looking at its definition -- such things
are possible if one has decent macro support:  I'm not bound by what somebody
else thinks is good for me -- I can shape the world the way I like it.

The cooperation of compilers and linkers is needed when I want to fully
exploit this paradigm.  For example, I can compile right out of the editor
(without having to save the source file to disk, e.g. because I don't yet
trust the changes I want to check).  My environment supports a universal macro
interface, which any command-line-oriented application can exploit.  This means
that I can write edit macros, linker macros, compiler preprocessor macros etc.
in the language of my choice, not the language imposed by the editor or
preprocessor.  (I tend to use modern Exec 2 for some things, Rexx for others,
and even have a couple of Lysp macros -- Lysp is a dialect of Lisp as might
be guessed.)  Btw, command-line interfaces lend themselves to programmability
and hence controllability and extendability better than GUIs.  One can always
put a GUI on top of the CLI to present a view that's more friendly to a new
user (by making a limited number of easy choices directly accessible) -- but
in a way that doesn't cramp the style of an experienced user.  By GUI I mean
the ability to click and point, pop up menus, etc. -- not necessarily fancy
graphics.  In a programming environment the latter are just decoration; when
images or graphics are the object of interest we have a different situation.
What *is* useful btw is multiple highlighting capabilities, e.g. to make
different syntactic entities stand out -- and there again the cooperation of
the compiler is desirable.

Michel.