Language support for flexible handling of system-detected errors.

Language support for flexible handling of system-detected errors.

[Adam Tissa]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:

>I'd hazard to guess that you know nothing about Ada? 

Many of us studied it at university in the dim distant past.
( They now teach kids Haskell and Java )

Ada has gone the way of Jovial.

> Granted, the first implementations were crap, but the vendors
>seems to have improved on the quality lately.

Not too many vendors left.
ACT is the only one I can think of  and they have a free unsupported
version and a supported  version that they want six figures per seat
for. I guess that the DOD and a few companies stuck with legacy Ada
based DOD source code maintenance contracts are their only customers.

>The useof Ada is usualy obscure. It tends to be used in places where it does
>not show. It's devices like aeroplanes, nuclear reactors, trains, flight
>control systems, weapons systems etc.

Actually, many of these systems now use C or C++ because of:

1. Management reluctance to approve the use of a dying language.
( Heck, how many new projects are done in COBOL ? )
2. Difficulty finding and hiring Ada programmers.

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

[Jim Rogers]

Adam Tissa wrote:

> Actually, many of these systems now use C or C++ because of:
> 
> 1. Management reluctance to approve the use of a dying language.
> ( Heck, how many new projects are done in COBOL ? )
> 2. Difficulty finding and hiring Ada programmers.


Actually, management usually has no knowledge of Ada whatsoever.
They choose C or C++ because they have always used C or C++.

There seems to have been no difficulty for management to choose
Java, even when it was a new and unproven technology. At that time
they had difficulty finding and hiring knowledgeable Java
programmers, but that was not an issue.

IMHO the issue is not the difficulty of hiring talent. Good
programmers can be retrained to any language. The issue is
technology fads. When you consider dying languages you should
add C to that list. Clearly its usage as a percent of all new
development has dropped dramatically over the past 10 years.
It is not being taught in universities any more. In fact, C++
is seldom taught in universities any more. Both languages
must be dying, just like Ada.

Just ask the acknowledged software leaders such as Microsoft.
They will tell you that only C# and the .NET technologies have
any future. This is clearly a marketing position, yet many
managers will accept it as fact because they do not know
or care to know, the truth.

Jim Rogers

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

[Tissa Adam]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote:


>technology fads. When you consider dying languages you should
>add C to that list. Clearly its usage as a percent of all new
>development has dropped dramatically over the past 10 years.
>It is not being taught in universities any more. In fact, C++
>is seldom taught in universities any more. Both languages
>must be dying, just like Ada.

The are.
In 10 years time, C++ will be an old obscure language.
Already, the C newsgroups feel and sound like the Forth newsgroups.

>Just ask the acknowledged software leaders such as Microsoft.
>They will tell you that only C# and the .NET technologies have
>any future. 

I still hope for the advent of functional languages in the commercial
world.

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

[Simon Wright]

Adam Tissa <verb_precedes_adjective@yahoo.com> writes:

> ACT is the only one I can think of  and they have a free unsupported
> version and a supported  version that they want six figures per seat
> for.

It is not _that_ much.

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

[Marc A. Criley]

Adam Tissa wrote:
> 
> Not too many vendors left.
> ACT is the only one I can think of  and they have a free unsupported
> version and a supported  version that they want six figures per seat
> for.

I would strongly suggest you contact sales@gnat.com to get the actual
cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
almost to the point of libel.

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

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

[chris.danx]

"Adam Tissa" <verb_precedes_adjective@yahoo.com> wrote in message
news:an6q9uk8bdg8fmbpnhhhhvfqv3ffs043cc@4ax.com...
> "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
>
> >I'd hazard to guess that you know nothing about Ada?
>
> Many of us studied it at university in the dim distant past.
> ( They now teach kids Haskell and Java )
>
> Ada has gone the way of Jovial.

Maybe at your uni.  At ours they teach Ada along with Haskell, to newbies.
Our lecturers are quite fond of it, especially our software development
lecturers.  They seem to like it's separate compilation and the flexibility
of the types allowed in Ada (enumeration, ranges, subtypes, <forget the
name, unconstrained maybe?> arrays).  Sure they teach Java and C, but that's
only in the latter years of the course, and because they want us to be
familiar with as many languages as possible (no problem if your a language
freak, like me).

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

[Paul Repacholi]

Adam Tissa <verb_precedes_adjective@yahoo.com> writes:

> Actually, many of these systems now use C or C++ because of:
 
> 1. Management reluctance to approve the use of a dying language.
> ( Heck, how many new projects are done in COBOL ? )

Lots. One probably is looking after your money right now.

> 2. Difficulty finding and hiring Ada programmers.

Difficullty in finding GOOD programmers... in any language.

-- 
Paul Repacholi                               1 Crescent Rd.,
+61 (08) 9257-1001                           Kalamunda.
                                             West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

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

[Larry Kilgallen]

In article <3C9DBCEC.6820090E@earthlink.net>, "Marc A. Criley" <mcqada95@earthlink.net> writes:
> Adam Tissa wrote:
>> 
>> Not too many vendors left.
>> ACT is the only one I can think of  and they have a free unsupported
>> version and a supported  version that they want six figures per seat
>> for.
> 
> I would strongly suggest you contact sales@gnat.com to get the actual
> cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
> almost to the point of libel.

It depends on how many seats and how many platforms you want.
For a single user it is $12,000 per platform.  That is quite
a bit more than the "free" for unsupported use.

The comment about "Not too many vendors left" does seem to
be incorrect.  There are more vendors of C compilers, but
it is not clear to me that is a blessing.  Locally I can
find only about 4 brands of corn flakes breakfast cereal.

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

[Steve Doiel]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:$zjU3lVSbGVB@eisner.encompasserve.org...
> In article <3C9DBCEC.6820090E@earthlink.net>, "Marc A. Criley"
<mcqada95@earthlink.net> writes:
> > Adam Tissa wrote:
> >>
> >> Not too many vendors left.
> >> ACT is the only one I can think of  and they have a free unsupported
> >> version and a supported  version that they want six figures per seat
> >> for.
> >
> > I would strongly suggest you contact sales@gnat.com to get the actual
> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
> > almost to the point of libel.
>
> It depends on how many seats and how many platforms you want.
> For a single user it is $12,000 per platform.  That is quite
> a bit more than the "free" for unsupported use.
>
I think the price very much depends on the host/target combination.  A few
years ago I had a quote for $12,000 for 10 seats for one year.  This was the
minimum support level with NT as the host and target, and the minimum number
of seats was 10 (as I recall).

I go along with Marc's comment: contact sales@gnat.com to get the actual
cost of ACT support for GNAT.

> The comment about "Not too many vendors left" does seem to
> be incorrect.  There are more vendors of C compilers, but
> it is not clear to me that is a blessing.  Locally I can
> find only about 4 brands of corn flakes breakfast cereal.

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

[Rodrigo Cunha]

 > Tissa Adam wrote:
> Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote:
> 
> 
> 
>>technology fads. When you consider dying languages you should
>>add C to that list. Clearly its usage as a percent of all new
>>development has dropped dramatically over the past 10 years.
>>It is not being taught in universities any more. In fact, C++
>>is seldom taught in universities any more. Both languages
>>must be dying, just like Ada.
>>
> 
> The are.
> In 10 years time, C++ will be an old obscure language.
> Already, the C newsgroups feel and sound like the Forth newsgroups.

Most large open source project are implemented in C/C++, most "core" 
technologies are implemented in C/C++, including unix, windows, ios... 
also motif, kde, gnome, mozilla, IE, word, excel, most database engines, 
Apache, the Internet depends on C... and you say C is dead? Oh dear...



-- 
email (same address): rnbc@rnbc.pt.eu.org or rnbc@rnl.ist.utl.pt
homepage: http://rnbc.pt.eu.org/~rnbc
IRC: r0 (PT-Net and IRC-Net and sometimes UnderNet)

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

[Greg Bek]

"Adam Tissa" <verb_precedes_adjective@yahoo.com> wrote in message
news:an6q9uk8bdg8fmbpnhhhhvfqv3ffs043cc@4ax.com...
> "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
>
> ....
> Not too many vendors left.
> ACT is the only one I can think of  and they have a free unsupported
> version and a supported  version that they want six figures per seat
> for. I guess that the DOD and a few companies stuck with legacy Ada
> based DOD source code maintenance contracts are their only customers.
>

Gee, last time I was at an Ada Resource Association Meeting there were
attendees
from:
    ACT
    Aonix
    Averstar (Formerly Intermetrics)
    DDC-I
    Greenhills
    OC Systems
    Rational

Last time I checked the ARA website, www.adaic.com , there were vendors who
had recently certified compilers.

As a side note: every air traveller relies on Ada every time they fly.  The
aircraft they
are flying probably has Ada running in its' avionics or communications
system, the
Air Traffic Control sytem that directs their flight, the GPS Satellites and
associated
ground control stations all rely on Ada.

Greg Bek
-------------------------------------------
Greg Bek  mailto:gab@rational.com
Product Manager
Rational Software, Cupertino CA 95014
Ph: +1 408 863 4394   Fax: + 1 408 863 4180
-------------------------------------------

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

[Tim Shoppa]

Jim Rogers wrote:
> technology fads. When you consider dying languages you should
> add C to that list. Clearly its usage as a percent of all new
> development has dropped dramatically over the past 10 years.
> It is not being taught in universities any more. In fact, C++
> is seldom taught in universities any more. Both languages
> must be dying, just like Ada.

I think C/C++ is where Fortran was in the early 80's: Certainly very
passe' for a CS department to teach to CS majors, but not so
economically unviable that a CS department is unwilling hire out
faculty to teach it to the engineering or physics departments.

It will remain the "lingua franca" of lots of fields the same way
that Fortran is still used to illustrate algorithms in some fields.

There are two kinds of computers: obsolete, and obsolete-ready.

Tim.

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

[Tarjei T. Jensen]

Adam Tissa wrote 
> Ada has gone the way of Jovial.

Nope.

> 1. Management reluctance to approve the use of a dying language.
> ( Heck, how many new projects are done in COBOL ? )

Which shows that you know nothing about Cobol and Cobol use.

> 2. Difficulty finding and hiring Ada programmers.

Easier now than ever.

greetings,

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

[Georg Bauhaus]

In comp.lang.ada chris.danx <chris.danx@ntlworld.com> wrote:

: At ours they teach Ada along with Haskell, to newbies.

Ada taught here, too, in the (rel. big) soldering department.

- georg

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

[Richard Riehle]

Greg Bek wrote:

> Gee, last time I was at an Ada Resource Association Meeting there were
> attendees
> from:
>     ACT
>     Aonix
>     Averstar (Formerly Intermetrics)
>     DDC-I
>     Greenhills
>     OC Systems
>     Rational
>
> Last time I checked the ARA website, www.adaic.com , there were vendors who
> had recently certified compilers.

Don't forget RR Software and the Janus Ada compiler.   They had a
representative
at the ARA meeting too.

Richard Riehle

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

[Wes Groleau]

> >I'd hazard to guess that you know nothing about Ada?
> 
> ....
> 
> Ada has gone the way of Jovial.

Maybe not nothing, but this statement shows
a significant misinformation problem.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Adam Tissa]

"Steve Doiel" <nospam_steved94@attbi.com> wrote:

>"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>> > I would strongly suggest you contact sales@gnat.com to get the actual
>> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
>> > almost to the point of libel.

Sorry,  I should have said that the minimum cost is six figures per
year.

For NT:
Minimum supported : 10 seats.
Cost per seat per year : 12,000 US $
Total cost per year : 120,000 US $

For someone who just needs a license for one or two programmers, the
effective cost is the cost for 10 seats.

I am sure that it makes sense in the context of ACT's business model.
( They seem to be thriving )

But I am not sure that it makes a lot of sense for a team of two or
three that are considering using Ada.

Hell, even Jovial is only 

Cost of Ada support

[Adam Tissa]

"Steve Doiel" <nospam_steved94@attbi.com> wrote:

>"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>> > I would strongly suggest you contact sales@gnat.com to get the actual
>> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
>> > almost to the point of libel.

Sorry,  I should have said that the minimum cost is six figures per
year.

For NT:
Minimum supported : 10 seats.
Cost per seat per year : 12,000 US $
Total cost per year : 120,000 US $

For someone who just needs a license for one or two programmers, the
effective cost is the cost for 10 seats.

I am sure that it makes sense in the context of ACT's business model.
( They seem to be thriving )

But I am not sure that it makes a lot of sense for a team of two or
three that are considering using Ada.

Hell, even Jovial is only 

Re: Cost of Ada support

[Mark Johnson]

Adam Tissa wrote:
> 
> "Steve Doiel" <nospam_steved94@attbi.com> wrote:
> 
> >"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> >> > I would strongly suggest you contact sales@gnat.com to get the actual
> >> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
> >> > almost to the point of libel.
> 
> Sorry,  I should have said that the minimum cost is six figures per
> year.
> [snip]
Not true. As Larry said before, I suggest you call ACT for pricing. I am
renewing annual support for well less that $100K US for support of
50-100 software developers. I would more likely believe the $12k figure
you quote is for all 10 developers (not per developer).

> For someone who just needs a license for one or two programmers, the
> effective cost is the cost for 10 seats.
Agreed. That is part of the pricing they chose to implement. They
explained the reasoning to me - perhaps you can ask to get the same
answer.... If you need the support and its worth say 8 weeks of labor to
pay for it, go ahead and do so. If not, ask questions on c.l.a or go to
another vendor.

  --Mark

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

[Kent Paul Dolan]

"Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote:

> Adam Tissa wrote:
 
> > Actually, many of these systems now use C or C++ because of:

> > 1. Management reluctance to approve the use of a dying language.
> > ( Heck, how many new projects are done in COBOL ? )
> > 2. Difficulty finding and hiring Ada programmers.

I don't think so, I'm surely not alone in applying for hundreds of Ada
openings to no avail.

> Actually, management usually has no knowledge of Ada whatsoever.
> They choose C or C++ because they have always used C or C++.

Well, no.

Just a few hours ago, I exchanged email with a recruiter trying to fill
a DoD programming slot for a C++ programmer for a C3I application.

I asked "why isn't that being done in Ada?" [Being confrontational about
lack of DoD Ada use is why I am no longer a contractor for the DoD.]

I got back the answer "my clients moved away from Ada to C++ quite some
time ago"; probably roughly the afternoon of the day the morning of
which DoD welched on its Ada mandate.

So lack of awareness of Ada (and how much better it is than C++ for
writing high reliability applications) is not really the answer, though
your further reference to software fads probably is closer to the mark.

xanthian [Does it give you a warm fuzzy feeling to know that your
security is being protected by a military deliberately using inferior
software because its leaders didn't have the guts to enforce a mandate
to use superior software?  Me either.]



-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Re: Cost of Ada support

[Marin David Condic]

It would also be important to consider the cost of support for similar
technology at a similar level. What is the cost of a garden variety C++
compiler for the same level of support? You could get MSVC++ at a price and
get quarterly updates for a price & probably not be able to get telephone
support at any price - or at least not a reasonable price. Is someone else
out there providing a similar level of support for a C++ compiler that ACT
does for GNAT? I'd bet the price is competitive. What does Cygnus charge for
gcc support and what do you get for that?

And then you also have to ask just how much support do you really need for a
smaller project? My experience with GNAT as a hobbyist and sometime internal
developer of small production systems is that for the most part I don't
really need a lot of hand holding or bug fixes. GNAT is pretty stable
technology for the most part. Its also well documented. And when in doubt,
there's usually free help to be had here on C.L.A. and other places. If I
encounter a bug, I can generally program around it and move on. In this
sense, I'm no worse off than if I were using MSVC++ at considerably more
cost than the "nothing" I pay for downloading GNAT.

I agree that it would be nice to get some level of support between "None"
and "Everything". It might be worth a few bucks to people to subscribe to
some kind of quarterly update service and get nothing else beyond that, but
with the basic stability of GNAT and the non-critical nature of most
projects, I've got to wonder if "Support" is that big an issue.

It might be fair to argue that some given Ada compiler doesn't have as many
critical tools and libraries as does some given C/C++/Java/(insert language
here) compiler and that this is important to project success. I just don't
see much of a case that can be made for bypassing Ada because a high level
of support from one particular vendor costs a lot of money. There are other
vendors - what are they offering for support and how much does it cost?

MDC

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


"Mark Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:3CA0FEDF.BF6F2C55@raytheon.com...
> Agreed. That is part of the pricing they chose to implement. They
> explained the reasoning to me - perhaps you can ask to get the same
> answer.... If you need the support and its worth say 8 weeks of labor to
> pay for it, go ahead and do so. If not, ask questions on c.l.a or go to
> another vendor.
>

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

[Simon Wright]

Adam Tissa <verb_precedes_adjective@yahoo.com> writes:

> "Steve Doiel" <nospam_steved94@attbi.com> wrote:
> 
> >"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> >> > I would strongly suggest you contact sales@gnat.com to get the actual
> >> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
> >> > almost to the point of libel.
> 
> Sorry,  I should have said that the minimum cost is six figures per
> year.
> 
> For NT:
> Minimum supported : 10 seats.
> Cost per seat per year : 12,000 US $
       ^^^^^^^^

This is the bug; the cost would have been 12,000 USD *for the 10 seats
altogether*. Which is still not cheap, but worth it (if you have a
support need, which if you have a real project you probably do).

> Total cost per year : 120,000 US $
> 
> For someone who just needs a license for one or two programmers, the
> effective cost is the cost for 10 seats.

Re: Cost of Ada support

[Pascal Obry]

Adam Tissa <verb_precedes_adjective@yahoo.com> writes:

> For NT:
> Minimum supported : 10 seats.
> Cost per seat per year : 12,000 US $
> Total cost per year : 120,000 US $

This is just plain wrong or it has changed recently. The $12,000 cover up to
10 programmers if my memory is ok.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Cost of Ada support

[Larry Kilgallen]

In article <3CA0FEDF.BF6F2C55@raytheon.com>, Mark Johnson <mark_h_johnson@raytheon.com> writes:
> Adam Tissa wrote:
>> 
>> "Steve Doiel" <nospam_steved94@attbi.com> wrote:
>> 
>> >"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
>> >> > I would strongly suggest you contact sales@gnat.com to get the actual
>> >> > cost of ACT support for GNAT.  "Six figures per seat" is inaccurate
>> >> > almost to the point of libel.
>> 
>> Sorry,  I should have said that the minimum cost is six figures per
>> year.
>> [snip]
> Not true. As Larry said before, I suggest you call ACT for pricing. I am
> renewing annual support for well less that $100K US for support of
> 50-100 software developers. I would more likely believe the $12k figure
> you quote is for all 10 developers (not per developer).
> 
>> For someone who just needs a license for one or two programmers, the
>> effective cost is the cost for 10 seats.
> Agreed. That is part of the pricing they chose to implement. They
> explained the reasoning to me - perhaps you can ask to get the same
> answer...

There was a quoting error above -- it was not I who said to call ACT.

I see nothing wrong with calling ACT, but for an explanation of that
reasoning no confidential phone discussion is required.  Answering a
question at a recent Boston lecture, Robert Dewar said their pricing
model is based on experience that supporting a single developer on
the average is more expensive than supporting ten developers, since
that single developer has nobody local from whom they can get advice.

> If you need the support and its worth say 8 weeks of labor to
> pay for it, go ahead and do so. If not, ask questions on c.l.a or go to
> another vendor.

I think even those of us who do not use their compiler feel it is a
priority for ACT to stay in business.

And Robert Dewar has pointed out that if someone else wants to get
into the business of lower-priced GNAT support for smaller numbers
of users it is perfectly legal for them to do so.

Re: Cost of Ada support

[Wes Groleau]

> support at any price - or at least not a reasonable price. Is someone else
> out there providing a similar level of support for a C++ compiler that ACT
> does for GNAT? I'd bet the price is competitive. What does Cygnus charge for

similar level of support meaning,  new version of compiler
as fast as possible after a bug report (usually within 24 hours)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Maynard Handley]

In article <3CA0A166.501E1D68@despammed.com>, wesgroleau@despammed.com wrote:

> > >I'd hazard to guess that you know nothing about Ada?
> > 
> > ....
> > 
> > Ada has gone the way of Jovial.
> 
> Maybe not nothing, but this statement shows
> a significant misinformation problem.
> 

No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
reasonable price (<$250)? Note I say IDE---I'm not interested in some
crappy suite of separate editor, compiler, linker, debugger all of which
are driven by command-line and are a total pain in the ass to use for any
program larger than a toy.

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.

Maynard

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

[Andrew W. Reynolds]

Maynard Handley wrote:
> In article <3CA0A166.501E1D68@despammed.com>, wesgroleau@despammed.com wrote:
> 
> 
>>>>I'd hazard to guess that you know nothing about Ada?
>>>
>>>....
>>>
>>>Ada has gone the way of Jovial.
>>
>>Maybe not nothing, but this statement shows
>>a significant misinformation problem.
>>
> 
> 
> No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> reasonable price (<$250)? Note I say IDE---I'm not interested in some
> crappy suite of separate editor, compiler, linker, debugger all of which
> are driven by command-line and are a total pain in the ass to use for any
> program larger than a toy.
> 
> 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.
> 
> Maynard

By IDE you mean:

Tools integrated to develop and application native to a supported OS?

This is then true for GNAT on MacOS X.  How is this so?

Currently Ada is being integrated into Apple's Project Builder for MacOS 
X.  An Ada-aware version of gdb is being updating to work with 
ProjectBuilder to complete the suite of tools.  A developer can use 
Interface Builder to develop their GUI.

A user can now build and run applications written in Ada using bindings 
to Apple's Carbon Framework.  These are fully MacOS X native 
applications using the Aqua graphics engine.

The cost?  *Free*.

To find out more about this:

http://adapower.net/macos

Drew

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

[Stefan Monnier <foo@acm.com>]

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

Re: Cost of Ada support

[Marin David Condic]

Thats a very high level of support and one would expect to pay a lot for it.
My question is: "Assuming a C/C++ vendor is providing the same level of
support, what do *they* charge for it?" Chances are, it would be similar in
price, so faulting ACT or Ada for a really steep price tag on this isn't
fair.

A good question is: "Can you find a lower level of support if you don't need
near instantanious bug fixes?" To answer that, you'd need to look at other
vendors of Ada compilers (there are a number out there...) to see what they
provide and at what price. Without knowing, I'd guess that it would again be
a similar price tag as compared to other languages. Ada isn't going to be
any more expensive to support than any other language.

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


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CA24461.76BF944E@despammed.com...
>
> similar level of support meaning,  new version of compiler
> as fast as possible after a bug report (usually within 24 hours)
>

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

[Marin David Condic]

This is a fair objection and one I have leveled myself from time to time. It
would be really nice to have a highly integrated IDE - as well as
significant libraries to speed development with leverage.

Here's a question that might help the Ada crowd out by getting a critic's
perspective: If you want a spiffy IDE (and possibly libraries) what would it
look like? (Its fair to point to some other language IDE and say "Something
like that...", but it might be more helpful to describe some specific
features.)

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


"Maynard Handley" <name99@mac.com> wrote in message
news:name99-2703021910440001@handma2.apple.com...
> In article <3CA0A166.501E1D68@despammed.com>, wesgroleau@despammed.com
wrote:
>
> No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> reasonable price (<$250)? Note I say IDE---I'm not interested in some
> crappy suite of separate editor, compiler, linker, debugger all of which
> are driven by command-line and are a total pain in the ass to use for any
> program larger than a toy.
>
> 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.
>
> Maynard

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

[Georg Bauhaus]

In comp.lang.ada Maynard Handley <name99@mac.com> wrote:
 
: No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
: reasonable price (<$250)?

What real-world IDE are you referring to?

- georg

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

[Nick Maclaren]

In article <5ly9gcd9ao.fsf@rum.cs.yale.edu>,
"Stefan Monnier <foo@acm.com>" <monnier+comp.arch/news/@flint.cs.yale.edu> writes:
|> >>>>> "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".

Yes.  In 1975, C was a dead language.  Discuss.  But preferably
not here :-)


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

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

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

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

[Wes Groleau]

> > > Ada has gone the way of Jovial.
> >
> > Maybe not nothing, but this statement shows
> > a significant misinformation problem.
> 
> No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> reasonable price (<$250)? Note I say IDE---I'm not interested in some

In other words, what you meant (instead of "Ada
has gone the way of Jovial") is

> > > Ada IDEs are just as bad as those for Jovial

Is that it?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[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

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

[Pascal Obry]

name99@mac.com (Maynard Handley) writes:

> No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> reasonable price (<$250)? Note I say IDE---I'm not interested in some
> crappy suite of separate editor, compiler, linker, debugger all of which
> are driven by command-line and are a total pain in the ass to use for any
> program larger than a toy.

This is quite strange. I would never use a compiler without being able to work
on the command line. I for sure do not build only "toy" programs :) Why you
ask ?  Just because for non "toy" programs you need to build automatically each
night for example ? Run a suite of tests ?...

How do you do that with "clickodrome"* IDE ?

> Languages that don't provide what current programmers want and expect are

We have a different view of programmers :)

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

The way you _think_ it is.

Thanks,
Pascal.

* I'm not sure how this translate in English, it means an
application full of buttons/menus where most of the time you need to click in
many places, all the time, just to have something done :)

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

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

[Simon Wright]

Pascal Obry <p.obry@wanadoo.fr> writes:

> How do you do that with "clickodrome"* IDE ?

> * I'm not sure how this translate in English, it means an
> application full of buttons/menus where most of the time you need to
> click in many places, all the time, just to have something done :)

I for one understood _exactly_ what you meant! ("click-o-rama" is
another possibility)

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

[Marin David Condic]

Its all well and good for some folks who are willing to take time to cobble
together their IDE out of separate tools and utilities & assume the
responsibility for making it all work together. However there are a large
number of developers in the world who need to spend their time working on
the end application and don't have time or desire to put together their own
toolkit. For those of us in that boat, a well integrated IDE that handles
everything seamlessly is a good thing.

Which group is in the majority? It probably doesn't matter. Which group
spends money on tools - and hence drives the kind of tools commercial
developers build? Obviously, the latter, since you don't see too many
off-the-shelf tools (such as a debugger) that the end user is supposed to
integrate with the rest of the tools (such as the compiler, editor, gui
builder, etc.)

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


"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:a7vjha$4us$1@pegasus.csx.cam.ac.uk...
>
> 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

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

[Randy Brukardt]

Maynard Handley wrote in message ...
>In article <3CA0A166.501E1D68@despammed.com>, wesgroleau@despammed.com
wrote:
>No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
>reasonable price (<$250)? Note I say IDE---I'm not interested in some
>crappy suite of separate editor, compiler, linker, debugger all of
which
>are driven by command-line and are a total pain in the ass to use for
any
>program larger than a toy.

Janus/Ada for Windows Personal Edition costs $195, and includes an IDE,
etc. (No debugger in that package, though.)

Even so, I prefer working from the command line, in part because I can
automate virtually anything I need to do. In an IDE, you're limited to
whatever the author thought you'd want to do, which rarely is exactly
what you need to do!

            Randy Brukardt
            R.R. Software, Inc.

Disclaimer: I work for the company that makes Janus/Ada...

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

[Ned Holbrook]

In article <u4rj0bo22.fsf@wanadoo.fr>, Pascal Obry <p.obry@wanadoo.fr> 
wrote:

> How do you do that with "clickodrome"* IDE ?

With a scripting language. As it turns out, a UI is just that. Most well 
designed systems also have interfaces for non-user-driven input.

Next question, please. 8-)

-- 
Ned Holbrook         http://web.dartmouth.edu/~holbrook/          ned@mac.com
* The Electric Mayhem World Tour '96 *** The Electric Mayhem World Tour '96 *

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

[Tony Finch]

Ned Holbrook  <ned@mac.com> wrote:
>Pascal Obry <p.obry@wanadoo.fr> wrote:
>
>> How do you do that with "clickodrome"* IDE ?
>
>With a scripting language. As it turns out, a UI is just that. Most well 
>designed systems also have interfaces for non-user-driven input.

IME most UIs are not built on top of a scripting language. I would
be interested to know about systems that are as easily scriptable as
the Unix tools; by easily I mean using well-known scripting languages.

Tony.
-- 
f.anthony.n.finch <dot@dotat.at>
MALIN HEBRIDES: SOUTHERLY 5 TO 7, OCCASSIONALLY GALE 8 AT FIRST IN HEBRIDES,
DECREASING 3 OR 4 LATER. OCCASIONAL RAIN. MODERATE OR GOOD.

Re: Cost of Ada support

[Wes Groleau]

> > similar level of support meaning,  new version of compiler
> > as fast as possible after a bug report (usually within 24 hours)
> 
> Thats a very high level of support and one would expect to pay a lot for it.
> My question is: "Assuming a C/C++ vendor is providing the same level of
> support, what do *they* charge for it?" Chances are, it would be similar in
> price, so faulting ACT or Ada for a really steep price tag on this isn't
> fair.

My point is that I doubt many--if any--C++ vendors offer that.
(If their product is written in C++, they probably are unable to)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Darren New]

Tony Finch wrote:
> be interested to know about systems that are as easily scriptable as
> the Unix tools; by easily I mean using well-known scripting languages.

Tcl and REXX both spring to mind.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
      Remember, drive defensively if you drink.

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

[Nick Maclaren]

In article <a7vokf$rnt$1@nh.pace.co.uk>,
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>Its all well and good for some folks who are willing to take time to cobble
>together their IDE out of separate tools and utilities & assume the
>responsibility for making it all work together. However there are a large
>number of developers in the world who need to spend their time working on
>the end application and don't have time or desire to put together their own
>toolkit. For those of us in that boat, a well integrated IDE that handles
>everything seamlessly is a good thing.

I think that you are missing the point.  Fewer than 1% of users do
any development, IDE or no.  I am referring to end-user applications
that don't work outside the IDE - things like databases, graphical
packages and so on!

One of the reasons that developers of real applications (i.e. not
happy hackers like the majority of users in the 1960s, and some of
us today) should NOT use IDEs is that they often fall into that
trap.  "We can't reproduce your problem in our IDE, so we can't
investigate it" :-(

>Which group is in the majority? It probably doesn't matter. Which group
>spends money on tools - and hence drives the kind of tools commercial
>developers build? Obviously, the latter, since you don't see too many
>off-the-shelf tools (such as a debugger) that the end user is supposed to
>integrate with the rest of the tools (such as the compiler, editor, gui
>builder, etc.)

The group that I am referring to is in the majority by 100:1 or
1,000:1.  Whether developers who use IDEs and those who don't are
in the majority is irrelevant.


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

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

[Wes Groleau]

> responsibility for making it all work together. However there are a large
> number of developers in the world who need to spend their time working on
> the end application and don't have time or desire to put together their own
> toolkit. For those of us in that boat, a well integrated IDE that handles
> everything seamlessly is a good thing.

Yes, such a thing would be really nice.  However, the original poster
(OP)
apparently believes that the lack of it means the language is already
dead.  It's arguable whether the lack will cause it to die, but it's
a fact that _currently_ there are still projects coding in Ada.

Many of these projects are big enough to afford Apex, which is (IMHO)
the kind of IDE that the OP was talking about (except for price).  And
yet, some of those feel that the GNAT IDE (our some other free one)
is adequate.

All of them realize that some factor of their project, size, or safety,
or reliability requirements, or ??? are such that using Ada is
mandatory,
IDE or not.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Cost of Ada support

[Marin David Condic]

Well, you sure can't get that kind of support for MSVC++. Most of the
shrink-wrap compilers I know of may have some limited support available that
may consist of quarterly updates and maybe e-mail responses to questions &
bug reporting. For lots of folks, that may constitute "Good Enough". For
those who need more - they may very well be out of luck if they are using
C++.

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


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CA3DFB2.EDBF3E87@despammed.com...
>
> My point is that I doubt many--if any--C++ vendors offer that.
> (If their product is written in C++, they probably are unable to)
>

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

[Marin David Condic]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a7vdf8$mjh$1@a1-hrz.uni-duisburg.de...
> In comp.lang.ada Maynard Handley <name99@mac.com> wrote:
>
> : No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> : reasonable price (<$250)?
>
> What real-world IDE are you referring to?
>
Good point. Last I checked MSVC++ was considerably more than $250 in its
least expensive form. It has a really nice IDE in many respects - very well
integrated editor, library manager, GUI builder & debugger - but it
certainly wasn't that low cost.

Is there something equivalent in any language that comes out at a price tag
under $250?

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

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

[Larry Kilgallen]

In article <a7vdae$mag$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> This is a fair objection and one I have leveled myself from time to time. It
> would be really nice to have a highly integrated IDE - as well as
> significant libraries to speed development with leverage.
> 
> Here's a question that might help the Ada crowd out by getting a critic's
> perspective: If you want a spiffy IDE (and possibly libraries) what would it
> look like? (Its fair to point to some other language IDE and say "Something
> like that...", but it might be more helpful to describe some specific
> features.)

Think Pascal (formerly Lightspeed Pascal ?). It features (featured?)

	incremental recompilation
	debugging

both right from the editor window.

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

[Marin David Condic]

Given that this started with talk about *compilers* having a CLI versus a
GUI based point-n-click interface, I'd like to know if there is a commercial
development compiler out there that *doesn't* provide a means of invoking it
from the command line. The ones I've seen usually have some means of running
the compiler from an MS_DOS window or a Unix command line. Given that much,
I'd think you could build a batch file to do compilations, right?

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

"Tony Finch" <dot@dotat.at> wrote in message
news:Bkf*qppkp@news.chiark.greenend.org.uk...
> Ned Holbrook  <ned@mac.com> wrote:
> >Pascal Obry <p.obry@wanadoo.fr> wrote:
> >
> >> How do you do that with "clickodrome"* IDE ?
> >
> >With a scripting language. As it turns out, a UI is just that. Most well
> >designed systems also have interfaces for non-user-driven input.
>
> IME most UIs are not built on top of a scripting language. I would
> be interested to know about systems that are as easily scriptable as
> the Unix tools; by easily I mean using well-known scripting languages.
>
> Tony.
> --
> f.anthony.n.finch <dot@dotat.at>
> MALIN HEBRIDES: SOUTHERLY 5 TO 7, OCCASSIONALLY GALE 8 AT FIRST IN
HEBRIDES,
> DECREASING 3 OR 4 LATER. OCCASIONAL RAIN. MODERATE OR GOOD.

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

[Marin David Condic]

You're right - Ada isn't dead and not likely to die anytime soon, given the
types of projects it already has & is likely to get. However, if it wants to
grow in popularity (something that is key to long-term survival) I think it
needs to cater a little more to what large numbers of developers like to see
come with a language. A well integrated, full featured IDE and a large
collection of class libraries (all at a price a garage developer can afford)
would help in that area.

Granted, there are lots of things at both the low end and the high end.
Certainly, GNAT with AdaGIDE and gdb at the price of a download is a really
good deal. (Its not really sophisticated and could be more smoothly
integrated, but at the everyday low price of "free" its really hard to
complain!) You can get more sophisticated environments from several
vendors - or roll your own from what you can download from the Internet and
cobble together. It would just be spiffy to be able to get something a notch
up from the bottom at a price point of - say - $500..$700?

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


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CA47835.EBEC352B@despammed.com...
>
> Yes, such a thing would be really nice.  However, the original poster
> (OP)
> apparently believes that the lack of it means the language is already
> dead.  It's arguable whether the lack will cause it to die, but it's
> a fact that _currently_ there are still projects coding in Ada.
>
> Many of these projects are big enough to afford Apex, which is (IMHO)
> the kind of IDE that the OP was talking about (except for price).  And
> yet, some of those feel that the GNAT IDE (our some other free one)
> is adequate.
>
> All of them realize that some factor of their project, size, or safety,
> or reliability requirements, or ??? are such that using Ada is
> mandatory,
> IDE or not.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

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

[Georg Bauhaus]

In comp.lang.ada Ned Holbrook <ned@mac.com> wrote:
: In article <u4rj0bo22.fsf@wanadoo.fr>, Pascal Obry <p.obry@wanadoo.fr> 
: wrote:
: 
: With a scripting language. As it turns out, a UI is just that. Most well 
: designed systems also have interfaces for non-user-driven input.
: 
: Next question, please. 8-)
: 
for <250$?

georg

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

[hack]

In article <bRcjQXT6c+XG@eisner.encompasserve.org>,
Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
>In article <a7vdae$mag$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
>> This is a fair objection and one I have leveled myself from time to time. It
>> would be really nice to have a highly integrated IDE - as well as
>> significant libraries to speed development with leverage.
>> 
>> Here's a question that might help the Ada crowd out by getting a critic's
>> perspective: If you want a spiffy IDE (and possibly libraries) what would it
>> look like? (Its fair to point to some other language IDE and say "Something
>> like that...", but it might be more helpful to describe some specific
>> features.)
>
>Think Pascal (formerly Lightspeed Pascal ?). It features (featured?)
>
>	incremental recompilation
>	debugging
>
>both right from the editor window.

If it allowed me to do this from *my* editor's window it would be just
wonderful.  All that's needed for that is a well-defined interface that
allows the compiler to read the editor's file buffer, and to report back
to the editor what areas to highlight and what messages to display.  Such
an interface can be defined generically, so whether I use emacs or some
other programmable editor wouldn't matter.

It would also mean that the compiler developer would not have to re-invent
what it takes to make a good program editor.  Not only would it be different
from other editors -- it would most likely have fewer general-purpose features
(non-trivial undo, non-trivial macro support), though it might have certain
nice language-specific features such as syntax-sensitive layout control.

Many years ago I saw a programming-language-specific editor whose internal
representation was the parse tree.  This permitted a nice integration with
language fatures, debugging and incremental recompilation.  It may have been
the one you mention (it was early 80s).  One significant problem with this
approach was that only syntactically complete program fragments could be cut
or pasted from other programs or files, so one had to have a second editor
to put the pieces together before one could import something!

A general-purpose editor has no problems with arbitrary program text updates.
The language-sensitive part of the environment, interfaced to the compiler,
could highlight complete and incomplete syntactic groupings, but would not
interfere with the incremental nature of composing a program.

Michel.

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

[hack]

In article <ned-124A97.16335828032002@news.apple.com>,
Ned Holbrook  <ned@mac.com> wrote:
>In article <u4rj0bo22.fsf@wanadoo.fr>, Pascal Obry <p.obry@wanadoo.fr> 
>wrote:
>
>> How do you do that with "clickodrome"* IDE ?
>
>With a scripting language. As it turns out, a UI is just that. Most well 
>designed systems also have interfaces for non-user-driven input.

Note the *well designed* in the above!  I am a very strong believer in
the concept of non-user-driven input, and am constantly frustrated by
applications which only offer a GUI -- or an overly complicated private
"scripting" interface.  The nice thing about a CLI is the universal nature
of the interface:  pass a command string, collect a reply string (or strings)
and a return code to distinguish success from failure.

I wish it were the case that "a UI is just that", because it would indeed
permit fairly universal control.  An example is the "smit" application in
AIX for system management: it is just a front end for traditional Unix CLI
configuration commands.  It has a "preview" feature that shows what commnds
would result from a given GUI button, making it clear that this is just an
improved UI to what would otherwise deserve the bad reputation ("inscrutable")
of the Unix CLI.

Michel.

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

[Preben Randhol]

On 29 Mar 2002 16:56:38 GMT, hack wrote:
> 
> If it allowed me to do this from *my* editor's window it would be just
> wonderful.  All that's needed for that is a well-defined interface that
> allows the compiler to read the editor's file buffer, and to report back
> to the editor what areas to highlight and what messages to display.  Such
> an interface can be defined generically, so whether I use emacs or some
> other programmable editor wouldn't matter.

I use vim as the editor and I have this. But there is absolutely no
need for the compiler to know anything about the editor used. It is much
better that the editor understands how to read the feedback from the
compiler(s)

-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

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

[Nick Maclaren]

In article <a8272v$ens$1@news.btv.ibm.com>, hack <hack@watson.ibm.com> wrote:
>
>Note the *well designed* in the above!  I am a very strong believer in
>the concept of non-user-driven input, and am constantly frustrated by
>applications which only offer a GUI -- or an overly complicated private
>"scripting" interface.  The nice thing about a CLI is the universal nature
>of the interface:  pass a command string, collect a reply string (or strings)
>and a return code to distinguish success from failure.

ONE nice thing - there are zillions of others.  For example, it is
possible to program it in non-trivial ways (though not in gruesome
and inferior CLIs like JCL, TSO or the MS-DOS one).  And it is
possible to collect evidence to report bugs to vendors in a way
that they might just understand.

>I wish it were the case that "a UI is just that", because it would indeed
>permit fairly universal control.  An example is the "smit" application in
>AIX for system management: it is just a front end for traditional Unix CLI
>configuration commands.  It has a "preview" feature that shows what commnds
>would result from a given GUI button, making it clear that this is just an
>improved UI to what would otherwise deserve the bad reputation ("inscrutable")
>of the Unix CLI.

As an AIX system administrator, I wish to dissent!  But that is
off-group :-)


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

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

[tmoran]

> If you want a spiffy IDE (and possibly libraries) what would it look
> like?  (Its fair to point to some other language IDE and say "Something
> like that...",
  Object Ada's IDE is like Visual C++.  (I dislike both. #.#)

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

[Marin David Condic]

Two things: 1) Nobody building a compiler can possibly guarantee you that it
will work with *your* editor since that could be just about anything. There
is no "standard" interface to every editor on the planet, so this would be a
hopeless goal. 2) A compiler like GNAT provides a good deal of programming
interface (such as ASIS) so that if you were so inclined, you could
integrate it to your favorite editor with your own glue code - presuming, of
course, that your editor of choice had the capabilities you need to invoke
some code & utilize the results.

I don't think its practical to ask of a language and IDE that it somehow
connect to any given other piece of software anywhere. I don't know of any
IDE that could achieve that goal.

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:a826c6$e72$1@news.btv.ibm.com...
>
> If it allowed me to do this from *my* editor's window it would be just
> wonderful.  All that's needed for that is a well-defined interface that
> allows the compiler to read the editor's file buffer, and to report back
> to the editor what areas to highlight and what messages to display.  Such
> an interface can be defined generically, so whether I use emacs or some
> other programmable editor wouldn't matter.
>

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

[Marin David Condic]

O.K. So what *would* you like? :-)

I've used both and while I can see negatives, they *do* provide some
interesting capabilities. You can't please everybody, but there's probably
some common body of features that most of us would consider desirable in an
IDE.

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


<tmoran@acm.org> wrote in message
news:K12p8.3033$jF3.2397254930@newssvr21.news.prodigy.com...
> > If you want a spiffy IDE (and possibly libraries) what would it look
> > like?  (Its fair to point to some other language IDE and say "Something
> > like that...",
>   Object Ada's IDE is like Visual C++.  (I dislike both. #.#)

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

[Larry Kilgallen]

In article <a81uvq$qnv$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Given that this started with talk about *compilers* having a CLI versus a
> GUI based point-n-click interface, I'd like to know if there is a commercial
> development compiler out there that *doesn't* provide a means of invoking it
> from the command line. The ones I've seen usually have some means of running
> the compiler from an MS_DOS window or a Unix command line. Given that much,
> I'd think you could build a batch file to do compilations, right?

Obviously Think Pascal cannot be invoked from the command line,
because there is no command line provided by the operating system.
The competing Macintosh Programmer's Workshop from Apple provided
a command line interface just for the purpose of running compilers :-)

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

[Larry Kilgallen]

In article <a82cgu$3he$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> O.K. So what *would* you like? :-)
> 
> I've used both and while I can see negatives, they *do* provide some
> interesting capabilities. You can't please everybody, but there's probably
> some common body of features that most of us would consider desirable in an
> IDE.

I would _like_ to think there was such a set to draw a constituency,
but I have no factual basis for believing such a set of features can
be listed.

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

[Peter da Silva]

In article <u4rj0bo22.fsf@wanadoo.fr>, Pascal Obry  <p.obry@wanadoo.fr> wrote:
> How do you do that with "clickodrome"* IDE ?

Last time I used the Microsoft IDE it had an option to generate Microsoft's
"makefile" [1] format from the project description, which could be used for
command line work.

But running automated tests of a GUI program is enough of a challenge that
the IDE is the least of your worries. :->

[1] It's more like a makefile-inspired script than a real makefile: it
    doesn't seem to support dependencies properly: it does run code
    conditionally based on file dates, but it's all run in sequential
    file order rather than from a dependency tree.

-- 
 `-_-'   In hoc signo hack, Peter da Silva.
  'U`    "A well-rounded geek should be able to geek about anything."
                                                       -- nicolai@esperi.org
         Disclaimer: WWFD?

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

[Erik Corry]

In comp.arch Peter da Silva <peter@abbnm.com> wrote:

> But running automated tests of a GUI program is enough of a challenge that
> the IDE is the least of your worries. :->

Actually, if you solve the GUI test problem, then it is likely
that the IDE problem is solved too, by the same mechanism.

-- 
Erik Corry erik@arbat.com
  Interviewer:  "Real programmers use cat as their editor."
  Bill Joy:     "That's right! There you go! It is too much trouble to say ed,
                 because cat's smaller and only needs two pages of memory."

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

[Wes Groleau]

> You're right - Ada isn't dead and not likely to die anytime soon, given the
> types of projects it already has & is likely to get. However, if it wants to
> grow in popularity (something that is key to long-term survival) I think it
> needs to cater a little more to what large numbers of developers like to see

This is true.  Why has it not happened?  Because up to now,
no Ada developers with the time and ability to create one
has felt enough need to want to do so.

If one existed, I'd grab it.  But--flame me if you want--
I do OK without it and can't see anything I can give up
to make room for that as a project.

I suspect I am not alone--else the tool would already exist.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Wes Groleau]

> Obviously Think Pascal cannot be invoked from the command line,
> because there is no command line provided by the operating system.

But AppleScript, in combination with other MacOS features,
does provided the requested batch capability.  Not in a
very convenient package, but .....

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Marin David Condic]

Hmmmmmmm....... Probably you're right. At least once the "requirements" got
specific enough to start suggesting how they should be implemented. For
example:

Requirement: I want to be able to easily navigate through the files,
packages, subprograms and other constructs of the Ada code that makes up
some system I'm working on.

We'd probably all agree that's A Good Thing. But everyone's concept of, for
example, "Easy", can be different. Does this mean it should have a
GUI-tree-like-thingie that I point&click on? Or does this mean I have a
command line thingie that uses grep-like expressions to search a directory
tree and open files?

Still, if someone were to be building an IDE, it would be wise to get
feedback from the potential customers as to what ought to be in it. Chances
are, you'd find a lot of commonality in the wants/needs area, if not in the
precise appearance of it.

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


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:YzYKvfFOJWul@eisner.encompasserve.org...
>
> I would _like_ to think there was such a set to draw a constituency,
> but I have no factual basis for believing such a set of features can
> be listed.

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

[Marin David Condic]

Another example of the brilliant marketing strategy that has propelled Apple
Computers to the very top of the personal computer business. ..... What? You
mean Apple is *NOT* the leading manufacturer of personal computers? I don't
believe you! The next thing you'll be telling me is that they don't let
other companies make compatible equipment for their computers..... :-)

I remember when the MAC first came out & I was looking at one in a showroom.
I asked the salesman how to get to the command line and he said "There isn't
one". "But then, how do you program it?" I asked naively. "You don't. You
buy software - or you can buy some add-on programming toolkit, yada, yada,
yada..." My response was "Boy, you guys really know how to attract software
developers, don't you...." I did not buy a Mac at that time....

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


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:DS4sPxqE7xSJ@eisner.encompasserve.org...
>
> Obviously Think Pascal cannot be invoked from the command line,
> because there is no command line provided by the operating system.
> The competing Macintosh Programmer's Workshop from Apple provided
> a command line interface just for the purpose of running compilers :-)

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

[hack]

In article <a82c8r$3ar$1@nh.pace.co.uk>,
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>Two things: 1) Nobody building a compiler can possibly guarantee you that it
>will work with *your* editor since that could be just about anything. There
>is no "standard" interface to every editor on the planet, so this would be a
>hopeless goal.

Agreed -- it's the lack of the *concept* even of a standard interface that
hurts.  It could just be a chicken-and-egg problem -- but I'm afraid it's
worse because there isn't even a general desire for this kind of thing, as
far as I can tell.  

> 2) A compiler like GNAT provides a good deal of programming
>interface (such as ASIS) so that if you were so inclined, you could
>integrate it to your favorite editor with your own glue code - presuming, of
>course, that your editor of choice had the capabilities you need to invoke
>some code & utilize the results.

Clearly only those editors willing to do their share of communicating in a
general (and flexible, programmable) way can be considered.  For the simple
purpose of writing and testing programs, one can indeed cobble up the needed
interfaces.  For example, in my environment, many compilers access services
through an emulated OS/360 interface, and I have hooks in that interface that
allow the compilers to read out of the editor (thinking they are reading a
plain old sequential file).  But much more is possible if the compiler offers
an interface to check-parse strings, to enquire about types and symbols, etc.

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

>I don't think its practical to ask of a language and IDE that it somehow
>connect to any given other piece of software anywhere. I don't know of any
>IDE that could achieve that goal.

Agreed -- it should only have to connect to one conceptual interface, which
other participating tools (such as editors, printers, e-mail systems etc.)
would also connect to -- without having to know about each other's particular
properties.

The Unix stdin/stdout pipe paradigm offers such a conceptual interface, but it
limited in that it is unidirectional.  (Pairs of pipes are possible, but lack
the needed synchronisation that *this* result belongs to *that* request.)

The CMS/YMS subcommand environment offers another, coroutine-like, conceptual
interface, where a program makes its services available via callback to other
programs invoked from it.  (This mechanism is very lightweight, so macros can
use it for high-performance automatic interaction involving tens of thousands
of requests per second.)

The mechanisms described above all assume communication via command strings
and result strings (plus return codes, if we're lucky).  THIS is what is
missing in a GUI-only tool.  There may be screen-scraping tools capable of
having a program "click" the 3rd button, read a button label or field content,
but the lack of layout consistency makes those tools awfully difficult to use.

Michel

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

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

[Marin David Condic]

Wes: Would I flame you? :-)

Think about it this way: You are already an Ada programmer and possibly
within your realm of endeavors, Ada is just fine. When I was doing embedded
systems in Ada, I was just fine with the available technology as well - O.K.
maybe I wished it was targeted at more processors, but basically I got stuff
with the compiler that was equivalent or better than what I got with some
other language.

But then there are a bunch of non-Ada programmers out there. What do they
want and what might Ada provide to get them inside the tent? I know a number
of programmers who are personally rather fond of Ada, but that won't use it
in developing their products because they get so much more leverage out of
some other environment. Saying to them: "Ada is better, but you don't have
as well -integrated an IDE, you don't have a bunch of class libraries, you
don't have a GUI, and you'll have to futz with the interface to the OS
because its not written in Ada, etc., etc., etc..." doesn't get you real
far. They'll rightly observe that the mission isn't to use Ada, but rather,
to get the job done. If another language with another set of tools gets them
there faster/better/cheaper, guess which way they go?

Hence, I think its important to discover what developers like about the
IDE's they have available to them & I think Ada ought to take that under
advisement... :-)

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


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CA86EA0.9BDF2EFD@despammed.com...
>
> This is true.  Why has it not happened?  Because up to now,
> no Ada developers with the time and ability to create one
> has felt enough need to want to do so.
>
> If one existed, I'd grab it.  But--flame me if you want--
> I do OK without it and can't see anything I can give up
> to make room for that as a project.
>
> I suspect I am not alone--else the tool would already exist.
>

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

[Marin David Condic]

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

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

[Stephen Leake]

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

> Two things: 1) Nobody building a compiler can possibly guarantee you that it
> will work with *your* editor since that could be just about anything. There
> is no "standard" interface to every editor on the planet, so this would be a
> hopeless goal. 

Not to every editor on the planet, but there have been some efforts in
this regard.

DEC defined a standard format for compiler diagnostics (I forget what
it was called), that LSE and other DEC tools could read. For non-DEC
tools (like Emacs), there was a text equivalent.

Gnu tools have a standard format for error messages, making them easy
to parse by simple scripts in editors.

Most programmer-oriented editors allow you to customize the command
line used to invoke compilers and similar tools. 

I don't think we need a real "standard" here, just a common paradigm
and a reasonably powerful scripting language in the editor.

-- 
-- Stephe

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

[Marin David Condic]

Well, yeah, sure. If you have some interfacing capability, great. I guess I
was arguing against the idea that there could be one single standard out
there for all development tool interfaces or that any one given tool could
be designed to connect to a multitude of TBD other tools. Some simple
editors might provide no programming interface and no scripting language. If
you want to integrate them you'll have to do a lot of your own glue-code and
still not get everything you might desire. Some editors might provide a
single buffer while others provide many buffers. The editor might expect to
invoke other tools via its own scripts or it may provide a set of callable
interfaces - expecting to be called by something else - or both. Given the
multiplicity of ways that an editor might communicate (or not) with the rest
of the world and throwing on top of it the multiplicity of ways that
compilers, linkers, debuggers, GUI builders, code generators, analyzers,
configuration managers, etc., might possibly communicate with the rest of
the world, I don't think it is reasonable to expect some kind of standard to
emerge.

Where you do have specific tools and they provide some ability to
communicate, integrating them into a development environment is possible.
(Did this once in a previous incarnation. It was a really big job.) But
since there are so many possible ways the various tools could choose to
work, I don't think it is practical to hope for some kind of standard
interoperability. DEC did it their way - GNU does it theirs. (Standards are
such a wonderful thing that everyone should have one of their own! :-) Too
much of *how* it is done is going to be determined by the design of the
tools, so I think standards would be difficult to achieve. It may even be
undesirable because it might inhibit design choices when building the tools.

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


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u8z871fga.fsf@gsfc.nasa.gov...
>
> Not to every editor on the planet, but there have been some efforts in
> this regard.
>
> DEC defined a standard format for compiler diagnostics (I forget what
> it was called), that LSE and other DEC tools could read. For non-DEC
> tools (like Emacs), there was a text equivalent.
>
> Gnu tools have a standard format for error messages, making them easy
> to parse by simple scripts in editors.
>
> Most programmer-oriented editors allow you to customize the command
> line used to invoke compilers and similar tools.
>
> I don't think we need a real "standard" here, just a common paradigm
> and a reasonably powerful scripting language in the editor.
>

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

[David Hoyt]

Marin David Condic wrote:
> "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:a7vdf8$mjh$1@a1-hrz.uni-duisburg.de...
> 
>>In comp.lang.ada Maynard Handley <name99@mac.com> wrote:
>>
>>: No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
>>: reasonable price (<$250)?
>>
>>What real-world IDE are you referring to?
>>
> 
> Good point. Last I checked MSVC++ was considerably more than $250 in its
> least expensive form. It has a really nice IDE in many respects - very well
> integrated editor, library manager, GUI builder & debugger - but it
> certainly wasn't that low cost.
> 
> Is there something equivalent in any language that comes out at a price tag
> under $250?
>

For Java - NetBeans
For Java (still in pre-release, other languages planned) Eclipse

Both are free, check out their .org sites...

david

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

[hack]

In article <a8a2v5$91j$1@nh.pace.co.uk>,
Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote:
>
>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". ...

For the many people who want or need just one such environment, this is
indeed very nice.  Even if they also use an e-mail system and common word
processor, the editing capabilities are probably not that different, and
cut&paste can probably handle 90% of cross-domain activity.  (What *really*
gets my dander is environments that don't support universal cross-domain
cut&paste, because they "know" what one might want to copy.  Note that I'm
just talking about text strings here, not about somebody preventing me from
copying a picture into an audio file.)

The situation is different for the (probably much smaller) number of people
who work on different projects, concurrently or sequentially.  The kinds of
things they do are of a similar nature, but now each "closed" IDE provides a
noticeably different environment, and the more sophisticated activities may
be conceptually similar, but will have to be carried out differently.  One
may be able to write private macros to encapsulate such activities (assuming
the IDE is programmable enough) but will not be able to reuse them in another
"closed" IDE -- and one will have difficulty combining them with generic
private tools (edit macros etc.) of one's main working environment.

What would be *ideal* is a set of IDEs organised around a couple of common
control and display paradigms (enabling interfacing to other environments),
together with a specifically tailored user interface that provides useful
defaults so that all the benefits of a "closed" IDE are also realised.  In
other words, a usable editor and scripting language would be included, but
could be replaced by those with a wider range of needs or desires.

I very much doubt that I'm the only one in this boat...

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

[Wes Groleau]

> Hence, I think its important to discover what developers like about the
> IDE's they have available to them & I think Ada ought to take that under
> advisement... :-)

I agree.  I'm just stating why I believe it hasn't been
done.  While you are stating why someone might want to do it.
And we're both right, as long as you leave in the "might"

(A new meaning for "might" makes right)  :-)

If I had a year's living expenses in the bank,
I'd consider taking a sabbatical and doing something
like that.  There's really no other way to create a
development environment with the marketing appeal
of something that created by a full-time staff and
marketed by another full-time staff.

Shall I open a trust fund for donations?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Wes Groleau]

> I remember when the MAC first came out & I was looking at one in a showroom.
> I asked the salesman how to get to the command line and he said "There isn't
> one". "But then, how do you program it?" I asked naively. "You don't. You

One of the reasons I bought an Amiga. 
Amiga, Ada, and now Macintosh--I just
keep on making stupid decisions.  :-)

By the way, some Mac fans would say something
that ought to sound quite familiar to this group:

"MAC is Media Access Control.  Mac is a computer."

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Marin David Condic]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CA9F849.C5B6DCBE@despammed.com...
>
> One of the reasons I bought an Amiga.
> Amiga, Ada, and now Macintosh--I just
> keep on making stupid decisions.  :-)
>
I had an Amiga 1000 and thought it was one of the coolest things since the
invention of shirt pockets. It did have some rather unstable software (the C
compiler was the best of the weak compilers available for it.) and I really
wasn't interested in the "Guru Meditation Numbers" I frequently saw, but it
was *way* more computer for the $$$ at the time and I wish it had lived long
enough to stop being a science fair project & gained some acceptance.


> By the way, some Mac fans would say something
> that ought to sound quite familiar to this group:
>
> "MAC is Media Access Control.  Mac is a computer."
>

My Bad. Sorry. I'll submit to a thousand lashes with a wet noodle. :-)

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

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

[Maynard Handley]

In article <a81ukm$qit$1@nh.pace.co.uk>, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

> "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
> news:a7vdf8$mjh$1@a1-hrz.uni-duisburg.de...
> > In comp.lang.ada Maynard Handley <name99@mac.com> wrote:
> >
> > : No it doesn't. Where do I get my Ada IDE for Mac or Windows at a
> > : reasonable price (<$250)?
> >
> > What real-world IDE are you referring to?
> >
> Good point. Last I checked MSVC++ was considerably more than $250 in its
> least expensive form. It has a really nice IDE in many respects - very well
> integrated editor, library manager, GUI builder & debugger - but it
> certainly wasn't that low cost.
> 
> Is there something equivalent in any language that comes out at a price tag
> under $250?
> 

(1) Anyone who thinks Dev Studio is a nice IDE clearly doesn't have very
high standards. Dev Studio is a piece of junk. To give some obvious
examples:
 --- no way to order the files in the file view by "conceptual order"
rather than alphabetically
 --- painful search and replace facilities
 --- no function or header popup menus
 --- stupid tiled-window UI that wastes huge amounts of space and does not
easily allow one to re-arrange windows to focus on what one is currently
doing
 --- very painful viewing of memory/stack/arrays/disassembly etc in the debugger

If you want to see what a GOOD IDE looks like, look at Metrowerks.

(2) I've no idea what CodeWarrior for Linux gives you, but it costs $149.
The blurb seems to indicate that it gives you the IDE parts (which is what
I am talking about), while using gcc, gdb and so on for the low-level
parts.
(CodeWarrior for Mac and Windows using its own compilers is $599 which I
imagine is the same sort of price as Dev Studio.)

(3) Apple's ProjectBuilder (which sucks compared to Metrowerks IMHO, but
is on the same sort of level as Dev Studio) is, as far as I know, free,
apart from the usual "sign up with Apple" nonsense.

Maynard

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

[Adam Tissa]

Wes Groleau <wesgroleau@despammed.com> wrote:

>
>> I remember when the MAC first came out & I was looking at one in a showroom.
>> I asked the salesman how to get to the command line and he said "There isn't
>> one". "But then, how do you program it?" I asked naively. "You don't. You
>
>One of the reasons I bought an Amiga. 
>Amiga, Ada, and now Macintosh--I just
>keep on making stupid decisions.  :-)

Quick go buy a SGI !

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

[Marin David Condic]

No need to get insulting. Just consider this point: MSVC++ has considerably
more features and integration than just about anything I've seen that comes
out of a box for Ada. While you can get many of the same capabilities out of
a polyglot of tools that you have to pull together from a variety of
sources, there isn't something of similar capability for Ada. You may not
like the way MSVC++ does a variety of things and you may have preferences
for other toolsets (of which I'm always happy to hear) but I don't think
that changes the fact that MSVC++ provides navigation, GUI building, class
libraries, debugging, building, etc., all together in one convenient package
and I don't see a similar shrink-wrap kit available for Ada. If Ada got *at
least* as far as MSVC++ it would have achieved something pretty cool.

Metrowerks and Code Warrior might make interesting models for deriving a set
of requirements for an Ada IDE. I'd have to look at them in more detail to
see what they do that would be A Good Thing. The idea should be to identify
a set of capabilities & features that folks tend to find useful in other
IDEs and adapt that to an Ada environment. It never hurts to add new
capabilities and features along the way so that an Ada IDE would have *more*
to offer than the other available tools.

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


"Maynard Handley" <name99@mac.com> wrote in message
news:name99-0204021351390001@handma2.apple.com...
>
> (1) Anyone who thinks Dev Studio is a nice IDE clearly doesn't have very
> high standards. Dev Studio is a piece of junk. To give some obvious
> examples:

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

[Darren New]

Adam Tissa wrote:
> >One of the reasons I bought an Amiga.
> Quick go buy a SGI !

I thought SGIs ran a UNIX variant?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
      Remember, drive defensively if you drink.

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

[Mark Bottomley]

I would be interested to know if you ever used Rational's Ada development
environments?

My experience is that even the earlier environments on their (admittedly
expensive) custom
hardware (the R1000's) provided syntax completion, change impact analysis,
full incremental
compilation, and fine grained integral revision control that I have yet to
see equalled. Using
one of these in a serious development environment where the customer (the
military) is more
concerned about tracability and all the nice things in doing rigorous
development made it a
pleasure to use.

This cadillac environment was still a fraction of a programmer's annual
salary, but it was
typically targetted to embedded systems, not desktops.

I still think the greatest thing about Ada is that a compiling program is
likely to run, where
a compiling C++ program is just starting out.

    Mark...

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a8f3tr$hu1$1@nh.pace.co.uk...
> No need to get insulting. Just consider this point: MSVC++ has
considerably
> more features and integration than just about anything I've seen that
comes
> out of a box for Ada. While you can get many of the same capabilities out
of
> a polyglot of tools that you have to pull together from a variety of
> sources, there isn't something of similar capability for Ada. You may not
> like the way MSVC++ does a variety of things and you may have preferences
> for other toolsets (of which I'm always happy to hear) but I don't think
> that changes the fact that MSVC++ provides navigation, GUI building, class
> libraries, debugging, building, etc., all together in one convenient
package
> and I don't see a similar shrink-wrap kit available for Ada. If Ada got
*at
> least* as far as MSVC++ it would have achieved something pretty cool.
>
> Metrowerks and Code Warrior might make interesting models for deriving a
set
> of requirements for an Ada IDE. I'd have to look at them in more detail to
> see what they do that would be A Good Thing. The idea should be to
identify
> a set of capabilities & features that folks tend to find useful in other
> IDEs and adapt that to an Ada environment. It never hurts to add new
> capabilities and features along the way so that an Ada IDE would have
*more*
> to offer than the other available tools.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
>
>
> "Maynard Handley" <name99@mac.com> wrote in message
> news:name99-0204021351390001@handma2.apple.com...
> >
> > (1) Anyone who thinks Dev Studio is a nice IDE clearly doesn't have very
> > high standards. Dev Studio is a piece of junk. To give some obvious
> > examples:
>
>
>

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

[Ketil Malde]

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

> that changes the fact that MSVC++ provides navigation, GUI building,
> class libraries, debugging, building, etc., all together in one
> convenient package

Now, if only it *worked*.

(I always hated the way it often failed to find function definitions,
how the class view took ages to scroll, how the pop-up boxes sometimes
worked, sometimes not, and sometimes were just annoyingly slow, how
Source Safe screwed up merges, etc etc)

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

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

[Ingo Marks]

Marin David Condic wrote:

> No need to get insulting. Just consider this point: MSVC++ has
> considerably more features and integration than just about anything I've
> seen that comes out of a box for Ada. While you can get many of the same
> capabilities out of a polyglot of tools that you have to pull together
> from a variety of sources, there isn't something of similar capability for
> Ada. You may not like the way MSVC++ does a variety of things and you may
> have preferences for other toolsets (of which I'm always happy to hear)
> but I don't think that changes the fact that MSVC++ provides navigation,
> GUI building, class libraries, debugging, building, etc., all together in
> one convenient package and I don't see a similar shrink-wrap kit available
> for Ada. If Ada got *at least* as far as MSVC++ it would have achieved
> something pretty cool.

The question is: Do you want to write comfortable software or do you want 
to write software comfortably?

Of course, MSVC++ is a comfortable environment for writing C++ 
applications. But are the applications you write comfortable for your 
customer?

I think it is better to write reliable software with Ada and "simple" tools 
like Xemacs editor and some Ada library than to use a pretty development 
environment which produces results of questionable quality.

I have developed for many years in many programming languages, but Ada is 
the first language which helped me to a) reduce my programming time (about 
half compared to C++) and b) to produce really realiable code. I don't like 
to use a compiler which I don't know to be error free or not. A computer 
science professor told me, that there is _no_ 100% error free C++ compiler 
in the world!

Besides: I use Xemacs with Ada mode. I have tried several Ada editors but 
nothing is more comfortable than Xemacs. Xemacs is a bit hard to learn but 
when you've got it you won't miss it.

> Metrowerks and Code Warrior might make interesting models for deriving a
> set of requirements for an Ada IDE. I'd have to look at them in more
> detail to see what they do that would be A Good Thing. The idea should be
> to identify a set of capabilities & features that folks tend to find
> useful in other IDEs and adapt that to an Ada environment. It never hurts
> to add new capabilities and features along the way so that an Ada IDE
> would have *more* to offer than the other available tools.

IMHO Anjuta is a good starting point for a very pretty Ada IDE. 
http://anjuta.sourceforge.net. SciTE (http://www.scintilla.org/) is 
interesting, too.

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

[pascal stenuit]

I don't know much about this, but wasn't this tried ( circa90s) with PCTE, the
so-called
software bus?

See for instance

http://www.ecma.ch/ecma1/STAND/Ecma-149.htm

Regards,
pascal stenuit


hack wrote:

>
> Agreed -- it's the lack of the *concept* even of a standard interface that
> hurts.  It could just be a chicken-and-egg problem -- but I'm afraid it's
> worse because there isn't even a general desire for this kind of thing, as
> far as I can tell.

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

[Marin David Condic]

"Mark Bottomley" <mark.bottomley@rogers.com> wrote in message
news:tRPq8.1821$2z1.252@news02.bloor.is.net.cable.rogers.com...
> I would be interested to know if you ever used Rational's Ada development
> environments?
>
I remember when Ada was first out there and Rational came out with their
compiler - that had to run on their own custom hardware. I remember getting
some information about it and hearing Grady Booch talk about it at a trade
show. I never used it. I didn't know anybody who could afford it. :-)


> My experience is that even the earlier environments on their (admittedly
> expensive) custom
> hardware (the R1000's) provided syntax completion, change impact analysis,
> full incremental
> compilation, and fine grained integral revision control that I have yet to
> see equalled. Using
> one of these in a serious development environment where the customer (the
> military) is more
> concerned about tracability and all the nice things in doing rigorous
> development made it a
> pleasure to use.
>
Yeah, I recall the R1000 had some very interesting and inovative features.
IIRC, it didn't store Ada programs as raw text - it went straight from the
editor into a parse tree and was kept that way. There might have been lots
of cool things about it, but there were just so many impracticalities about
it that even though I was in the Defense Industry in the days of cost-plus
contracts, I had no knowledge of or contact with any projects that were
using it. It was just *way* too expensive and/or didn't target whatever
environment was required.


> This cadillac environment was still a fraction of a programmer's annual
> salary, but it was
> typically targetted to embedded systems, not desktops.
>
A *fraction* of a programmer's salary? Unless you were *way* better paid
than I was back in those days, it was more like a *multiple* of a
programmer's salary. I don't remember the exact numbers for the various
options I had looked at back then, but I'm pretty sure that (say, circa late
80's) the base sticker price was somewhere in the six-figure range. It was
definitely beyond the consideration of any garage-startups and quite a bit
more spendy than any DoD contractors I knew wanted to go.

> I still think the greatest thing about Ada is that a compiling program is
> likely to run, where
> a compiling C++ program is just starting out.
>
Definitely a major advantage in my book. Its like having a spelling/grammar
checker for your word processor. It keeps you from making the most egregious
(and stupid/trivial) errors up front. And everyone knows that the earlier
you detect/correct an error in any production chain the less it costs to
fix.

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

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

[Marin David Condic]

"Ketil Malde" <ketil+@ii.uib.no> wrote in message
news:eg4risndq4.fsf@sefirot.ii.uib.no...
>
> Now, if only it *worked*.
>

I readily and wholeheartedly conceed that MSVC++ - like many things made by
Micro$oft - is buggy and unreliable. (It is, after all, written in C/C++ :-)
Like many things Micro$oft makes - if it worked reliably, you'd have
little/no reason to buy the next release.

But that doesn't mean that the many features it has are not in some sense
"desirable" and hence something from which lessons can be learned. I'd love
to see something similar to the class view in some Ada IDE. I'd love to see
a source-level debugger that let you change code on the fly and do the many
things MSVC++ does (at least attempts to do) in an Ada IDE. While much of
the MFC is either an interface to MS operating systems or a patch-up of
weaknesses in the C++ language, that doesn't mean that a similar class
library wouldn't be a real plus for an Ada IDE.

I'm suggesting that most of the Ada IDE's I've seen don't come close to
MSVC++ in terms of its highly integrated functionality. (Certainly not at
the price tag.) There are certainly other IDE's that might provide
more/better features in a variety of areas. But that's what Ada should be
learning from and offering similar capabilities.

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

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

[Marin David Condic]

"Ingo Marks" <adv@region-nord.de> wrote in message
news:a8h129$cr6$02$1@news.t-online.com...
>
> The question is: Do you want to write comfortable software or do you want
> to write software comfortably?
>
Any reason it can't be both?


> Of course, MSVC++ is a comfortable environment for writing C++
> applications. But are the applications you write comfortable for your
> customer?
>
Reliable, usable, functional and desirable programs can be written in any
language - including C++ using MSVC++. Its just more work getting them there
than it might be using Ada.


> I think it is better to write reliable software with Ada and "simple"
tools
> like Xemacs editor and some Ada library than to use a pretty development
> environment which produces results of questionable quality.
>
"Pretty development environment" does not of necessity equate to
"questionable quality" of the end product. Certainly many things can be
accomplished with a simple editor and a command line compiler. That doesn't
guarantee "high quality" any more so than a spiffy IDE and large class
library is going to mean "low quality". No environment can make you write
good code.


> I have developed for many years in many programming languages, but Ada is
> the first language which helped me to a) reduce my programming time (about
> half compared to C++) and b) to produce really realiable code. I don't
like
> to use a compiler which I don't know to be error free or not. A computer
> science professor told me, that there is _no_ 100% error free C++ compiler
> in the world!
>
I will readily agree that (all other things being equal) Ada programming
speeds development over C/C++ programming. I've seen enough data to convince
me of that. The problem is that some given C++ (or Java or other language)
development environment that provides you with a large library of code to
leverage can quickly eliminate any advantage Ada has if the Ada environment
doesn't have a similar library. All other things are seldom equal. :-)

What makes you think that there are any 100% error free Ada compilers out
there? :-) Its impossible to prove that there are no errors in a compiler or
any other sufficiently complex piece of software. And yes, I've encountered
errors in every Ada compiler I've ever used. It might be the case that Ada
compilers - having run through validation - at least fully implement the
language and do so in a consistent way. It might be the case that C++
compilers don't adhere to the definition of C++ because they have not run
through a similar validation process. But that's a different thing than not
having any errors.

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

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

[Wes Groleau]

> I would be interested to know if you ever used Rational's Ada development
> environments?

They are great, but they are not under $250 per user
as was originally asked.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

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

[Warren W. Gay VE3WWG]

Ketil Malde wrote:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> 
>>that changes the fact that MSVC++ provides navigation, GUI building,
>>class libraries, debugging, building, etc., all together in one
>>convenient package
> 
> Now, if only it *worked*.
> 
> (I always hated the way it often failed to find function definitions,
> how the class view took ages to scroll, how the pop-up boxes sometimes
> worked, sometimes not, and sometimes were just annoyingly slow, how
> Source Safe screwed up merges, etc etc)
> 
> -kzm


Part of "that" problem is actually due to the underlying language

begin supported. Ada is easily supported by an IDE because there
are no _macros_ in the language to obscure what's behind them.

Visual Studio has to lean on specially formatted (and ugly!) comments
everywhere.  Add to that, the fact that MuckySoft has a fetish
for C macros. This leaves you with a recipe for a "can't win"
scenario in an IDE. But this is consistent with their "good enough"
philosophy.

I just don't agree that it is good enough.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

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

[Marin David Condic]

That's certainly an issue as well. Just the whole business of relying on C++
header files that work by lexical inclusion creates all kinds of ambiguities
and difficulties that make interpreting them within an IDE as having
specific meanings and intent a really difficult task.

I'd think it would be a lot easier to do this in Ada - especially with
something like ASIS working for you - because of the less ambiguous and more
consistent semantics of the package specification.

As for the comments? A lot of them have to do with trying to impose a very
specific structure on a program to utilize the GUI programming model that
MSVC++ defines. They're going "You have to write your program *this way* if
you want to integrate with the GUI builder and have all the code generation
we can do for you..." I'd suspect this might be easier to do in Ada, but you
might still have to come up with some kludges to get the source code to line
up with what the GUI builder is doing.

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


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3CAC8552.5060107@home.com...
>
> Part of "that" problem is actually due to the underlying language
>
> begin supported. Ada is easily supported by an IDE because there
> are no _macros_ in the language to obscure what's behind them.
>
> Visual Studio has to lean on specially formatted (and ugly!) comments
> everywhere.  Add to that, the fact that MuckySoft has a fetish
> for C macros. This leaves you with a recipe for a "can't win"
> scenario in an IDE. But this is consistent with their "good enough"
> philosophy.
>
> I just don't agree that it is good enough.

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> As for the comments? A lot of them have to do with trying to impose a very
> specific structure on a program to utilize the GUI programming model that
> MSVC++ defines. They're going "You have to write your program *this way* if
> you want to integrate with the GUI builder and have all the code generation
> we can do for you..." I'd suspect this might be easier to do in Ada, but you
> might still have to come up with some kludges to get the source code to line
> up with what the GUI builder is doing.
> 
> MDC

I'm not so sure that these kludges would be necessary for Ada,
for GUI or any other "wizard" IDE feature. With Ada's strong typing
features and ASIS "smarts", you should be able to locate the objects
or procedure calls that need tweaking by semantic analysis. If not
by type alone, then by type and pre-arranged name (within scoping
rules).

The only case that I can currently imagine a need for a place-holder
comment, might be when you need to mark the spot for the currently
"empty-set" of something.  But even there, if the package/object is
structured a certain way, even that should be deducible.

While I didn't pursue Borland's Delphi much, I was impressed by the
general lack of such muck. IIRC, Delphi never needed
any comments to locate objects of interest in the code.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

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

[Marin David Condic]

I have not programmed MSVC++ in quite some time, so my memory of all the
situations there has faded. (Time heals all wounds. :-) I have not spent any
time considering how one might go about getting similar effects into Ada
with or without comment markers. I suspect that mostly, you're right - you
could probably auto-generate a variety of packages that are auto-withed into
code the programmer has to develop & cover most of the territory. I'm just
suspicious that given the mission of duplicating the programming model and
all of its capabilities, there might be some burrs hanging off the edges
that you'd have a hard time finding a good way of doing without some kind of
kludge.

Of course, one might want to ask the question "why bother duplicating the
MSVC++ model at all?" I could imagine better ways of doing it might be
possible. If you start with a solid base, you can keep polishing and
polishing it for years. But if the base is no good, you're just polishing a
turd.

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


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3CADD77C.5010100@home.com...
>
> I'm not so sure that these kludges would be necessary for Ada,
> for GUI or any other "wizard" IDE feature. With Ada's strong typing
> features and ASIS "smarts", you should be able to locate the objects
> or procedure calls that need tweaking by semantic analysis. If not
> by type alone, then by type and pre-arranged name (within scoping
> rules).
>
> The only case that I can currently imagine a need for a place-holder
> comment, might be when you need to mark the spot for the currently
> "empty-set" of something.  But even there, if the package/object is
> structured a certain way, even that should be deducible.
>
> While I didn't pursue Borland's Delphi much, I was impressed by the
> general lack of such muck. IIRC, Delphi never needed
> any comments to locate objects of interest in the code.
> --
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

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

[Kevin Cline]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a8hqrv$r83$1@nh.pace.co.uk>...
> What makes you think that there are any 100% error free Ada compilers out
> there? :-) Its impossible to prove that there are no errors in a compiler or
> any other sufficiently complex piece of software. And yes, I've encountered
> errors in every Ada compiler I've ever used. It might be the case that Ada
> compilers - having run through validation - at least fully implement the
> language and do so in a consistent way. 

I wouldn't count on that either.  Validation suites may be incomplete,
particularly for a very large language like Ada.

I found bugs in two validated Ada-83 compilers within a month after
I started using them.

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

[Ingo Marks]

Kevin Cline wrote:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
> message news:<a8hqrv$r83$1@nh.pace.co.uk>...
>> What makes you think that there are any 100% error free Ada compilers out
>> there? :-) Its impossible to prove that there are no errors in a compiler
>> or any other sufficiently complex piece of software. And yes, I've
>> encountered errors in every Ada compiler I've ever used. It might be the
>> case that Ada compilers - having run through validation - at least fully
>> implement the language and do so in a consistent way.
> 
> I wouldn't count on that either.  Validation suites may be incomplete,
> particularly for a very large language like Ada.
> 
> I found bugs in two validated Ada-83 compilers within a month after
> I started using them.

Ok I agree with you. But isn't it better to use a "validated" Ada compiler 
(although it cannot be proved to be 100% error free - I know Turings proof 
;-) than to use C++ compilers which are proven not to be 100% error free?

The very existence of validation mechanisms extends my confidence in Ada.
They may be envitably incomplete but that's better than nothing.

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

[Nick Maclaren]

In article <ba162549.0204080917.7da8068b@posting.google.com>,
Kevin Cline <kcline17@hotmail.com> wrote:
>"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a8hqrv$r83$1@nh.pace.co.uk>...
>> What makes you think that there are any 100% error free Ada compilers out
>> there? :-) Its impossible to prove that there are no errors in a compiler or
>> any other sufficiently complex piece of software. And yes, I've encountered
>> errors in every Ada compiler I've ever used. It might be the case that Ada
>> compilers - having run through validation - at least fully implement the
>> language and do so in a consistent way. 
>
>I wouldn't count on that either.  Validation suites may be incomplete,
>particularly for a very large language like Ada.
>
>I found bugs in two validated Ada-83 compilers within a month after
>I started using them.

Validation suites are provably impossible to make bulletproof for
any language powerful enough to implement a Turing machine, which
includes any useful general-purpose language.


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

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

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> I have not programmed MSVC++ in quite some time, so my memory of all the
> situations there has faded. (Time heals all wounds. :-) I have not spent any
> time considering how one might go about getting similar effects into Ada
> with or without comment markers. I suspect that mostly, you're right - you
> could probably auto-generate a variety of packages that are auto-withed into
> code the programmer has to develop & cover most of the territory. I'm just
> suspicious that given the mission of duplicating the programming model and
> all of its capabilities, there might be some burrs hanging off the edges
> that you'd have a hard time finding a good way of doing without some kind of
> kludge.


I don't disagree that there would be challenges. I just believe that you
can probably dispense with the special comments with some careful planning.
You have considerable context to work with in Ada. Naming conventions, whether
they be for types and/or values will probably be enough. This doesn't work
well in C++ because the macros can mess up the "view" of the source code,
as we've already discussed.


> Of course, one might want to ask the question "why bother duplicating the
> MSVC++ model at all?" I could imagine better ways of doing it might be
> possible. If you start with a solid base, you can keep polishing and
> polishing it for years. But if the base is no good, you're just polishing a
> turd.
> 
> MDC

We definitely are not interested in "polishing turds" :-)  But MSVC++ has
been used as one comparison point for IDEs. I briefly used Borland's
Delphi for a while. While it's capabilities (IDE + library) is very good,
I didn't always find it very intuitive. But you could use it as another
comparison point.  Personally, I'd agree that something better could
be made available.  For me however, I'd have to insist on some flavour
of EMACS capability in the editor. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg