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

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

I can sympathize with your desire to see some sort of common interface
between development tools. Sometimes we have it (like ASIS, elf, and other
sorts of "standards") and in other areas we don't.

I think one of the reasons that many people like the "closed" IDEs with
everything related to a particular language and compiler is just that it
comes down to "One Stop Shopping". They don't want to spend their time
creating the "perfect" development environment for their needs. They just
want to grab a shrink-wrap package, install it and have (almost) everything
they need to get their software product out the door quickly. If Micro$oft
offers them a kit that does this at a reasonable price, they go for it. Why
wouldn't they? If they could have a "better" environment by cobbling
together a polyglot of software, this might be interesting, but not
compelling. How does this get the job done faster/better/cheaper? Is more
time spent cobbling the environment together than it saves in developing the
real product?

If a software product - or set of them - wants to be successful, it/they
have to consider the business environment they're in and how best to work
with that. You can ignore "business needs" only at your own risk. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"hack" <hack@watson.ibm.com> wrote in message
news:a89vq3$haq$1@news.btv.ibm.com...
>
> My main point was *against* the closed nature of many IDEs, i.e. the view
> that "integration" means to have in one place (and style) everything
related
> to a particular language or compiler -- as opposed to my view of
"integration"
> as to ability to communicate equally well, in a single familiar
environment,
> with many separate working environments (compilers, e-mail, runtimes
etc.).
>