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

[nmm1@cus.cam.ac.uk (Nick Maclaren)]

In article <a7vfq8$pkq$1@news.btv.ibm.com>,
hack@watson.ibm.com (hack) writes:
|> 
|> 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.

Have you ever had a production application shipped to you that
wouldn't work outside its development environment?  And then had
the vendor tell you that they couldn't investigate bugs outside
it?  And then had them tell you that the bypass is that you should
run all your production code inside it?  Even when you couldn't
actually GET the development environment because it the vendor
had never ported it to your (wider) environment?

The answer, in my case, is "yes, and more than once".


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679