Re: The Next Microsoft?

Re: The Next Microsoft?

[Ray Blaak]

> In article <E$OcUgAHHIE5Ewfl@quik.freeuk.net>,
>   GSV Three Minds in a Can <GSV@quik.fsnet.co.uk> wrote:
> > And Windows (at least NT) ain't so bad. You really need to have tried
> > some 'government designed' programming languages like Coral-66 and ADA, to
> > appreciate that 'government designed' is an oxymoron, right up there with
> > Military Intelligence.

Don't know about Coral-66, but Ada is very well designed. This myth about
comitte-designed languages being somehow inferior is resoundingly false in
Ada's case. It is precisely because many heads were looking at it that the
details of the language all hang together.

Ada's strength is its readability of source code, strong typing and run-time
checks for safety, and general name space mechanisms for programming in the
large. It does its job very well.

It is only recently that you have languages like C++ "catching up" to Ada.

If you really want to argue this, go to comp.lang.ada.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: The Next Microsoft?

[Mark Atwood]

Ray Blaak <blaak@infomatch.com> writes:
> 
> Don't know about Coral-66, but Ada is very well designed. This myth about
> comitte-designed languages being somehow inferior is resoundingly false in
> Ada's case. It is precisely because many heads were looking at it that the
> details of the language all hang together.

Ada (at least the first version) was designed by one man, and then
went thru several rounds of being critiqued by the user community and
revised by a small committee headed by the language designer.

That is the right way to do it. In a slightly more free-form manner,
it's very similar to how workhorses like Perl, Python and C (*not* C++)
have been evolving.

I like Ada. If I have to use a Wirth-style language, Ada is the
language of choice.

And if I ever end up writting software that would KILL someone if it
goes wrong, I would professionally refuse to use any other language.
Writing weapons control, avionics, nuke control, or medical device
control software in any other langage is malfeasense, IMO.

-- 
Mark Atwood   | It is the hardest thing for intellectuals to understand, that
mra@pobox.com | just because they haven't thought of something, somebody else
              | might. <http://www.friesian.com/rifkin.htm>
http://www.pobox.com/~mra

Re: The Next Microsoft?

[Hyman Rosen]

Mark Atwood <mra@pobox.com> writes:
> That is the right way to do it. In a slightly more free-form manner,
> it's very similar to how workhorses like Perl, Python and C (*not* C++)
> have been evolving.

Not C++? The initial form of the language is the work of a single person,
Bjarne Stroustroup, who developed it incrementally, giving out versions
to users and accepting feedback.

The enhancement of templates in C++ into their modern form was due to the
desire of the standardization committee to adopt the Standard Template
Library into the standard. This library was the work of Alexander Stepanov.

Re: The Next Microsoft?

[Mark Atwood]

Hyman Rosen <hymie@prolifics.com> writes:
> Mark Atwood <mra@pobox.com> writes:
> > That is the right way to do it. In a slightly more free-form manner,
> > it's very similar to how workhorses like Perl, Python and C (*not* C++)
> > have been evolving.
> 
> Not C++? The initial form of the language is the work of a single person,
> Bjarne Stroustroup, who developed it incrementally, giving out versions
> to users and accepting feedback.

Early C++, you are right. But once the committee started on it, they
could never say no to any seriously proposed feature, so now the language
is too big for the human brain.

Nobody uses C++, they only use either a preferred or a
in-house-mandated subset dialect.

> The enhancement of templates in C++ into their modern form was due to the
> desire of the standardization committee to adopt the Standard Template
> Library into the standard. This library was the work of Alexander Stepanov.

True, the STL model is nice and can fit in one competent brain. Pity
that it's realized in such a horrible language.

But all this is just a well pounded grease spot on the road, where
there used to be a dead horse.

-- 
Mark Atwood   | It is the hardest thing for intellectuals to understand, that
mra@pobox.com | just because they haven't thought of something, somebody else
              | might. <http://www.friesian.com/rifkin.htm>
http://www.pobox.com/~mra

Re: The Next Microsoft?

[Hyman Rosen]

Mark Atwood <mra@pobox.com> writes:
> Early C++, you are right. But once the committee started on it, they
> could never say no to any seriously proposed feature, so now the language
> is too big for the human brain.

What are these features that you are talking about? What features are
present in Standard C++ that were absent in Early C++? The only thing
that comes close that I can think of is the internationalization of
stream I/O, and it was absolutely necessary to do this or there would
have been no standard at all.

My allegedly human brain can encompass Standard C++ enough so that I
can use it.  When I need precise detail, I refer to the Standard.

> Nobody uses C++, they only use either a preferred or a
> in-house-mandated subset dialect.

Ravenscar Profile. Nyah nyah! You are being ridiculous. Have you looked
at Microsoft's ATL class libraries, for example?

> True, the STL model is nice and can fit in one competent brain. Pity
> that it's realized in such a horrible language.

The STL model is a direct result of the desire to write high-level
algorithms on fancy containers using the exact style that C programmers
use to process arrays, namely with pointer arithmetic. Indeed, STL
algorithms apply directly to raw C arrays. STL and C/C++ make a perfect
fit.

Re: The Next Microsoft?

[Jon S Anthony]

Hyman Rosen wrote:
> 
> Mark Atwood <mra@pobox.com> writes:
> > Early C++, you are right. But once the committee started on it, they
> > could never say no to any seriously proposed feature, so now the language
> > is too big for the human brain.
> 
> What are these features that you are talking about? What features
> are present in Standard C++ that were absent in Early C++? The only
> thing that comes close that I can think of is the
> internationalization of stream I/O, and it was absolutely necessary
> to do this or there would have been no standard at all.

A few that come to mind (we are talking "early C++", say pre '90):

MI, Exceptions, Namespaces, and Templates.

I don't think the problem is that it is too big.  "Bigness" itself is
no bad thing in an industrial strength programming language and, if
properly executed, can even be a very good thing as it can make the
_writing_ of sophisticated programs _simpler_.  No, the major problems
with C++ revolve more around feature interactions and poorly thought
out binding time issues.  And this most likely comes from starting
with a very inappropriate substrate (good ol' C) for "accreting" new
constructs over it and nevertheless going ahead and making all those
accretions.


> > True, the STL model is nice and can fit in one competent brain. Pity
> > that it's realized in such a horrible language.
> 
> The STL model is a direct result of the desire to write high-level
> algorithms on fancy containers using the exact style that C
> programmers use to process arrays, namely with pointer arithmetic.

Stepenov's arguments for this have never made the least bit of sense.
The whole of STL (imo) is wrongheaded from top to bottom and the
template stuff in support shows an equal incompetence.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The Next Microsoft?

[Hyman Rosen]

Jon S Anthony <jsa@synquiry.com> writes:
> Stepenov's arguments for this have never made the least bit of sense.
> The whole of STL (imo) is wrongheaded from top to bottom and the
> template stuff in support shows an equal incompetence.

You are entitled to this opinion, but it is wrong. The design of STL is
supremely elegant. Not only does it give immense expressive power with
simple syntax, it allows the C++ compiler to generate higly efficient
code to implement this power. The C++ standardization committee found
this library to be so compellingly good that they adopted it into the
language and made certain that the language would support it properly.
Ada has nothing like it, since it is missing automatic instantiation
of generics.

Re: The Next Microsoft?

[Bill Greene]

Hyman Rosen wrote:
> 
> ...
> Ada has nothing like it [STL], since it is missing automatic instantiation
> of generics.

Ada must have something like it, since Stepanov ported STL from Ada to
C++.

-- 
William R. Greene                              1100 Perimeter Park Drive
Ganymede Software, Inc.                                        Suite 104
http://www.ganymede.com                       Morrisville, NC  27560 USA
Phone: (919) 469-0997, ext. 280                      Fax: (919) 469-5553

Re: The Next Microsoft?

[Ehud Lamm]

On Fri, 5 May 2000, Bill Greene wrote:

|Hyman Rosen wrote:
|> 
|> ...
|> Ada has nothing like it [STL], since it is missing automatic instantiation
|> of generics.
|
|Ada must have something like it, since Stepanov ported STL from Ada to
|C++.
|

That's not 100% correct. You can check out the Stepanov interviews linked
from my site for more on the STL history, and Stepanov views on Ada and
C++ generics.

You can also find some of the orignal paper on the Ada generic library.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Fri, 5 May 2000, Bill Greene wrote:
> Hyman Rosen wrote:
> > 
> > ...
> > Ada has nothing like it [STL], since it is missing automatic instantiation
> > of generics.
> 
> Ada must have something like it, since Stepanov ported STL from Ada to
> C++.

There are Ada versions of STL-like libraries, where "-like" means that
the libraries are based on active iterators defined over sequential 
containers with algorithms parameterized in terms of those iterators, and
hence independent of the particular type of container. It happens that
operations of C pointer arithmetic and random access map well to the 
traversal of sequential data structures and so you get a nice syntactic 
dovetailing in the C++ STL with this part of generic programming. Clearly  
non-sequential collections can't be handled this way. I don't think Ada's 
functional syntax for ++, --, etc is a fundamental problem.

I agree that the lack of automatic instantiation is a weakness of Ada
generics vis-a-vis C++ templates. There are other places where that 
facility would come in handy besides STL style generic programming. I 
don't think their absence is fundamental, but I suppose that is debatable. 

Ada has subprogram nesting and allows you to instantiate generics with 
local functions and overloading on return type. So generic programming is 
different in Ada, less powerful in some ways, due to the lack of automatic
instantiation, more powerful in others. 

I think that the STL is well designed, and has certainly influenced the 
design of C++ in a good way. If anything, I wish templates and the STL had 
been in the language earlier, and the OO part had come later. 

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Florian Weimer]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> > Ada must have something like it, since Stepanov ported STL from Ada to
> > C++.
> 
> There are Ada versions of STL-like libraries,

Is there any such library which doesn't duplicate the original STL
iterator semantics?  An STL iterator which denotes the end of a range
points to an element after the last element included in the range.
This differs from the Standard Ada approach for arrays, and I fear
that mixing both conventions results in code which is a bit irritating
at least.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Robert Dewar]

In article
<Pine.BSF.4.21.0005071606250.9268-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> less powerful in some ways, due to the lack of automatic
> instantiation, more powerful in others.

I am not at all convinced that automatic instantiation is
a help to the reader and maintainer, on the contrary, it
seems very awkward to have uses of templates not be visible
from this point of view.

Sure it is a convenience for the writer, but I never consider
that a significant factor.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Mon, 8 May 2000, Robert Dewar wrote:
> In article
> <Pine.BSF.4.21.0005071606250.9268-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > less powerful in some ways, due to the lack of automatic
> > instantiation, more powerful in others.
> 
> I am not at all convinced that automatic instantiation is
> a help to the reader and maintainer, 

What would it take to convince you? That's not a rhetorical question. 

> on the contrary, it
> seems very awkward to have uses of templates not be visible
> from this point of view.

If automatic instantiation were optional, then the client of the generic 
abstraction could decide that if it were awkward, they could explicitly 
instantiate that abstraction. 

The question then shifts to whether it is ever the case that automatic 
instantiation is a benefit to the reader, and if it is worth the
implementation effort. 

> Sure it is a convenience for the writer, but I never consider
> that a significant factor.

I disagree. If it isn't damaging to readability and maintainability, or 
if one thinks the tradeoff there is favorable, I think considering 
convenience for the writer is reasonable.

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> I am not at all convinced that automatic instantiation is
> a help to the reader and maintainer, on the contrary, it
> seems very awkward to have uses of templates not be visible
> from this point of view.

I consider automatic instantiation of templates to be the compile-time
polymorphism equivalent of run-time dispatching on class-wide types.
When you make a dispatching call, you do not know what function you
are calling. Similarly, you should be able to call a generic function
without explicitly stating which one you are calling.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On 8 May 2000, Hyman Rosen wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > I am not at all convinced that automatic instantiation is
> > a help to the reader and maintainer, on the contrary, it
> > seems very awkward to have uses of templates not be visible
> > from this point of view.
> 
> I consider automatic instantiation of templates to be the compile-time
> polymorphism equivalent of run-time dispatching on class-wide types.

Correct, and type theorists refer to this as "parametric polymorphism". 
Ada doesn't really have parametric polymorphism, it's generics are really 
monomorphic. 

> When you make a dispatching call, you do not know what function you
> are calling. Similarly, you should be able to call a generic function
> without explicitly stating which one you are calling.

This is one good way to look at it, since dispatching is sometimes a 
negative with respect to readability and maintainability. It is also 
similar to overloading; if you have several overloaded functions in scope 
you don't explicitly say which you are calling in Ada or C++. In languages 
without overloading you have to use qualified names. 

As much as I like Ada, this is one thing I really prefer about the C++
design. This discussion might be more interesting with specific examples,
so I'll put some together in an Ada-like language with automatic
instantiation. Shen and Cormack's paper from Tri-Ada 91 is a good place to 
start for anyone interested.

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Richard D Riehle]

In article <t7og6gahgm.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>Robert Dewar <robert_dewar@my-deja.com> writes:
>> I am not at all convinced that automatic instantiation is
>> a help to the reader and maintainer, on the contrary, it
>> seems very awkward to have uses of templates not be visible
>> from this point of view.
>
>I consider automatic instantiation of templates to be the compile-time
>polymorphism equivalent of run-time dispatching on class-wide types.
>When you make a dispatching call, you do not know what function you
>are calling. Similarly, you should be able to call a generic function
>without explicitly stating which one you are calling.

I wonder if there is a trade-off here between convenience and type
safety.  Ada tends to lean heavily in the direction of safety,
and automatic instantiation seems not quite as focused on that issue.
For example, the model for generic formal package parameters in Ada
forces the designer to create a generic signature package corresponding to
the parameter.  This makes automatic instantiation quite difficult to
achieve, but has the benefit of pretty thorough compile-time evaluation
of all the elements of the signature.  

The goals of C++ are different from those of Ada.  If a programmer feels
more comfortable with C++ goals, then C++ is a good choice.  If someone
feels better with the goals of Ada, then Ada should be the choice.  Also,
those goals are intended to satisfy different levels of confidence in the
final product.  Would anyone who knows C++ well feel comfortable knowing the
software for the avionics on their aircraft was programmed in C++?  Most 
of those I ask, say, "No way."   Ada is targeted to exactly that kind of
application environment.  Scaling back a bit from that extreme, Ada still
inspires a greater sense of confidence in its goals than C++ when safety
is an issue.  Automatic instantiation does not inspire confidence, but that
may not matter if a software failure does not kill or maim anyone.  

Richard Riehle

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Tue, 9 May 2000, Richard D Riehle wrote:
> In article <t7og6gahgm.fsf@calumny.jyacc.com>,
> 	Hyman Rosen <hymie@prolifics.com> wrote:
> >Robert Dewar <robert_dewar@my-deja.com> writes:
> >> I am not at all convinced that automatic instantiation is
> >> a help to the reader and maintainer, on the contrary, it
> >> seems very awkward to have uses of templates not be visible
> >> from this point of view.
> >
> >I consider automatic instantiation of templates to be the compile-time
> >polymorphism equivalent of run-time dispatching on class-wide types.
> >When you make a dispatching call, you do not know what function you
> >are calling. Similarly, you should be able to call a generic function
> >without explicitly stating which one you are calling.
> 
> I wonder if there is a trade-off here between convenience and type
> safety.  Ada tends to lean heavily in the direction of safety,
> and automatic instantiation seems not quite as focused on that issue.

Overloading, runtime dispatching, and "use clauses" don't seem quite
as focused on safety either. The only way that automatic instantiation 
is troubling is that in the case of a language like C++ it is undecidable, 
I think in standard C++ they limit the depth of template expansion
(Hyman?) and I imagine a similar solution would be needed for Ada.  

> For example, the model for generic formal package parameters in Ada
> forces the designer to create a generic signature package corresponding to
> the parameter.  This makes automatic instantiation quite difficult to
> achieve, but has the benefit of pretty thorough compile-time evaluation
> of all the elements of the signature.  

Here are the rules for automatic instantiation proposed by Shen and
Cormack:

-- (1) Allow the name of a generic subprogram to appear wherever a
--     non-generic subprogram name is now allowed.
--
-- (2) Allow non-generic subprograms to overload generics
--
-- (3) Allow a subprogram component of a generic package to appear where
--     non-generic subprogram name is allowed.
--
-- (4) Allow generic package name to be specified in a "use" clause, thus
--     allowing subprogram components to be specified without
--     qualification according to rule (3)
--
-- (5) Allow some or all real parameters to be omitted in an explicit
--     instantiation

Packages in package parameters would not be inferred. 

> The goals of C++ are different from those of Ada.  If a programmer feels
> more comfortable with C++ goals, then C++ is a good choice.  If someone
> feels better with the goals of Ada, then Ada should be the choice.  

Programming languages don't have goals, people do. Languages are artifacts 
that can and should be discussed dispassionately. If a programmer believes
that a major feature of another language can be adapted to his preferred
language, why shouldn't he wish for change?

> Also,
> those goals are intended to satisfy different levels of confidence in the
> final product.  Would anyone who knows C++ well feel comfortable knowing the
> software for the avionics on their aircraft was programmed in C++?  
> Most of those I ask, say, "No way."   Ada is targeted to exactly that
> kind of application environment.  Scaling back a bit from that extreme,
> Ada still inspires a greater sense of confidence in its goals than C++
> when safety is an issue.  

"C++ is deficient with respect to Ada in the safety critical realm"
"C++ has automatic instantiation"
"Therefore automatic instantiation is deficient ..."

> Automatic instantiation does not inspire confidence, but that
> may not matter if a software failure does not kill or maim anyone.  

Your emotional rhetoric is unconvincing. Any language with type inference
has a kind of automatic instantiation and "lack of safety" is not a 
reasonable negative claim to make.

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Tue, 9 May 2000, Brian Rogoff wrote:
> On Tue, 9 May 2000, Richard D Riehle wrote:
> > For example, the model for generic formal package parameters in Ada
> > forces the designer to create a generic signature package corresponding to
> > the parameter.  This makes automatic instantiation quite difficult to
> > achieve, but has the benefit of pretty thorough compile-time evaluation
> > of all the elements of the signature.  
> 
> Here are the rules for automatic instantiation proposed by Shen and
> Cormack:
... snip... 
> Packages in package parameters would not be inferred. 

Which is clearly unacceptable today, for reasons of consistency and
upward compatibilty,  Ada generic signature packages should be inferrable
too. I suspect that in a system with optional automatic instantiation
those would mostly still be explicitly instantiated, since they provide
important information to the reader, and would be particularly prone to
ambiguity. 

Sorry for writing that mistaken sentence.

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Hyman Rosen]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> Overloading, runtime dispatching, and "use clauses" don't seem quite
> as focused on safety either. The only way that automatic instantiation 
> is troubling is that in the case of a language like C++ it is undecidable, 
> I think in standard C++ they limit the depth of template expansion
> (Hyman?) and I imagine a similar solution would be needed for Ada.  

The C++ Standard requires support for a minimum of 17 levels of templates.
The GNU compiler has a command-line argument to specify what depth you want
if you need more.

Undecidability isn't really a problem, since failure to terminate simply
means that you don't get a compiled program, as opposed to getting an
incorrect one.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Robert A Duff]

Hyman Rosen <hymie@prolifics.com> writes:

> The C++ Standard requires support for a minimum of 17 levels of templates.
> The GNU compiler has a command-line argument to specify what depth you want
> if you need more.

Why?  I mean, why is there a need for a limit?  (And, less importantly,
why 17?)

- Bob

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Hyman Rosen]

Robert A Duff <bobduff@world.std.com> writes:
> Hyman Rosen <hymie@prolifics.com> writes:
> > The C++ Standard requires support for a minimum of 17 levels of templates.
> > The GNU compiler has a command-line argument to specify what depth you want
> > if you need more.
> 
> Why?  I mean, why is there a need for a limit?  (And, less importantly,
> why 17?)

The depth of template nesting is potentially unlimited, and erroneous
code can require infinite depth, so the standard sets a minimum depth
that must be supported, and strictly conforming code shouldn't require
anything deeper. Here's a trivial example -

template <int N>
struct factorial
{
	enum { v = N * factorial<N - 1>::v };
};

template <>
struct factorial<0>
{
	enum { v = 1 };
};

If I use factorial<5>::v, I'm fine. If I use factorial<20>::v,
I've gone over 17 levels, and a strictly conforming compiler
doesn't have to accept my code. If I use factorial<-1>::v, I'm
very happy that my compiler has some limit :-)

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Richard D Riehle]

In article <Pine.BSF.4.21.0005090756520.24683-100000@shell5.ba.best.com>,
	Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>On Tue, 9 May 2000, Richard D Riehle wrote:

>> I wonder if there is a trade-off here between convenience and type
>> safety.  Ada tends to lean heavily in the direction of safety,
>> and automatic instantiation seems not quite as focused on that issue.
>
>Overloading, runtime dispatching, and "use clauses" don't seem quite
>as focused on safety either. The only way that automatic instantiation 
>is troubling is that in the case of a language like C++ it is undecidable, 
>I think in standard C++ they limit the depth of template expansion
>(Hyman?) and I imagine a similar solution would be needed for Ada.  

Overloading is resolved at compile time.  It is a little safer than run-time
dispatching, according to some practitioners.  Use clauses certainly can
be problematic with regard to visibility, but they generally do not obviate 
type safety.  Of course, Geoff Mendal's paper on this subject illustrates 
some of the concerns for use clauses with predefined types.  The question
I was raising was whether we would expect the same level of confidence 
from automatic instantiation we already expect from Ada's model of generic
instantiation.  

>> For example, the model for generic formal package parameters in Ada
>> forces the designer to create a generic signature package corresponding to
>> the parameter.  This makes automatic instantiation quite difficult to
>> achieve, but has the benefit of pretty thorough compile-time evaluation
>> of all the elements of the signature.  
>
>> The goals of C++ are different from those of Ada.    
>
>Programming languages don't have goals, people do. Languages are artifacts 
>that can and should be discussed dispassionately. 

Please excuse my inadvertant anthropomorphism of the languages.  Perhaps I 
should have said, "The goals of the C++ designers were different from those
of the Ada designers."  With that clarification, I doubt you would disagree
that there were some goals, at very minimum, a loose rationale, for the 
design of both languages under discussion.


>> Also,
>> those goals are intended to satisfy different levels of confidence in the
>> final product.  
>
>"C++ is deficient with respect to Ada in the safety critical realm"
>"C++ has automatic instantiation"
>"Therefore automatic instantiation is deficient ..."

Well, actually, I began my posting with a question.  I tried to phrase it
interrogatively, although I may have let myself slip into an assertion now
and then.  Let me try again.

Can we enjoy the same level of confidence in C++ automatic instantiation we
have come to expect from Ada genericity?   Having asked the question in that
way, I realize that some in the Ada community might point out that SPARK does
not support genericity because, for the designers of SPARK, even the conservative
approach of Ada to genericity does not carry sufficient guarantee of reliability.

>Your emotional rhetoric is unconvincing. Any language with type inference
>has a kind of automatic instantiation and "lack of safety" is not a 
>reasonable negative claim to make.

Yes, Brian.  I am well-known for my letting my passion override my dignity when
discussing technical concerns.  Sigh.  If I engage in future discussion on this
topic, I shall restrain myself from any comment without having first cleansed
myself of unruly emotions through the therapeutic agent of a cold shower.

Meanwhile, my question stands.

Richard Riehle
richard@adaworks.com
 

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Wed, 10 May 2000, Richard D Riehle wrote:
> In article <Pine.BSF.4.21.0005090756520.24683-100000@shell5.ba.best.com>,
> 	Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> 
> >On Tue, 9 May 2000, Richard D Riehle wrote:
> 
> >> I wonder if there is a trade-off here between convenience and type
> >> safety.  Ada tends to lean heavily in the direction of safety,
> >> and automatic instantiation seems not quite as focused on that issue.
> >
> >Overloading, runtime dispatching, and "use clauses" don't seem quite
> >as focused on safety either. The only way that automatic instantiation 
> >is troubling is that in the case of a language like C++ it is undecidable, 
> >I think in standard C++ they limit the depth of template expansion
> >(Hyman?) and I imagine a similar solution would be needed for Ada.  
> 
> Overloading is resolved at compile time.  

Automatic instantiation is still a "compile time" notion. It isn't the
same as a runtime method select, so it is even safer than OO style 
programming with tagged types. 

Programmers used to languages like ML, Haskell, and Clean use "automatic 
instantiation" all of the time, they just don't call it that. I find that 
it works OK from the point of view of safety and lack of run time errors, 
but that the error messages in OCaml are not as good as in GNAT and even 
worse in some other FPs. This is getting better though, and doesn't look 
like a fundamental problem.

I haven't seriously used C++ for a few years now, so it wouldn't be fair 
for me to comment on the error messages from heavy template programming.
Once again though, this is all having to do with "ease of writing",
duration of compilation, etc. 

> It is a little safer than run-time
> dispatching, according to some practitioners.  Use clauses certainly can
> be problematic with regard to visibility, but they generally do not obviate 
> type safety.  Of course, Geoff Mendal's paper on this subject illustrates 
> some of the concerns for use clauses with predefined types.  The question
> I was raising was whether we would expect the same level of confidence 
> from automatic instantiation we already expect from Ada's model of generic
> instantiation.  

How do you measure level of confidence? If you mean, do I trust that type 
checkers for languages with parametric polymorphism can be made to work, 
I do. I use a language with parametric polymorphism, and it works for the 
scale of project I use it in. It's hard to look at any feature
independently, but this one compresses code by eliminating cascading
instantiations. It allows higher level programming without requiring 
runtime overhead, at least in C++.

> >> For example, the model for generic formal package parameters in Ada
> >> forces the designer to create a generic signature package corresponding to
> >> the parameter.  This makes automatic instantiation quite difficult to
> >> achieve, but has the benefit of pretty thorough compile-time evaluation
> >> of all the elements of the signature.  
> >
> >> The goals of C++ are different from those of Ada.    
> >
> >Programming languages don't have goals, people do. Languages are artifacts 
> >that can and should be discussed dispassionately. 
> 
> Please excuse my inadvertant anthropomorphism of the languages.  Perhaps I 
> should have said, "The goals of the C++ designers were different from those
> of the Ada designers."  With that clarification, I doubt you would disagree
> that there were some goals, at very minimum, a loose rationale, for the 
> design of both languages under discussion.

Sure, I shouldn't be nitpicky, but C++ and Ada are both intended to be
capable of doing systems programming. Ada isn't purely about safety, and 
as you well know has many unsafe features. And new ones were added which
are also verboten in SPARK: tagged types, aliased/access all, etc. 

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]


Robert Dewar a �crit dans le message <8f50hc$hpo$1@nnrp1.deja.com>...
>Sure it is a convenience for the writer, but I never consider
>that a significant factor.


I second that. Another way to put it : I do not care for the health of
the writer fingers :)

What is important is readability and  maintenability (maintenance is where
70% of the sofware cost is spent).

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: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Brian Rogoff]

On Mon, 8 May 2000, Pascal Obry wrote:
> I second that. Another way to put it : I do not care for the health of
> the writer fingers :)
> 
> What is important is readability and  maintenability (maintenance is where
> 70% of the sofware cost is spent).

87% of all statistics are made up on the spot :-)

I've heard similar statistics before, but I wonder how the cost estimation
is done, and if it is biased towards certain kinds of software.

-- Brian

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Robert Dewar]

In article
<Pine.BSF.4.21.0005080941230.24665-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> I've heard similar statistics before, but I wonder how the
> cost estimation is done, and if it is biased towards certain
> kinds of software.

The figure obviously varies with the kind of software. 70% is
the lowest figure I have ever heard quoted, most measurements
are in the 80-90% range.

(I would think that Y2K remediation has pushed many fiscal
programs into the 95-99% range :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]


Robert Dewar a �crit dans le message <8f73p1$rgs$1@nnrp1.deja.com>...
>In article
><Pine.BSF.4.21.0005080941230.24665-100000@shell5.ba.best.com>,
>  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>> I've heard similar statistics before, but I wonder how the
>> cost estimation is done, and if it is biased towards certain
>> kinds of software.
>
>The figure obviously varies with the kind of software. 70% is


It is also the minimum that I have quoted, but this was not
explicitly stated in my previous message sorry :)

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: STL, Ada, C++

[Harry Erwin]

Robert Dewar <robert_dewar@my-deja.com> wrote:

> In article
> <Pine.BSF.4.21.0005080941230.24665-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > I've heard similar statistics before, but I wonder how the
> > cost estimation is done, and if it is biased towards certain
> > kinds of software.
> 
> The figure obviously varies with the kind of software. 70% is
> the lowest figure I have ever heard quoted, most measurements
> are in the 80-90% range.
> 
> (I would think that Y2K remediation has pushed many fiscal
> programs into the 95-99% range :-)
> 

Barry Boehm (in Chapter 30 of Software Engineering Economics) discusses
this. 10-year life-cycle costs ranging from 60% to 75% seem typical. 

-- 
Harry Erwin, PhD, <herwin@gmu.edu>, Bat Researcher, Senior SW Analyst 
and Security Engineer, and Adjunct Professor of Computer Science, 
George Mason University.

Re: STL, Ada, C++

[Robert A Duff]

herwin@gmu.edu (Harry Erwin) writes:

> Barry Boehm (in Chapter 30 of Software Engineering Economics) discusses
> this. 10-year life-cycle costs ranging from 60% to 75% seem typical. 

Fine, but we shouldn't forget that if a software project gets
cancelled before seeing the light of day, maintenance costs are zero.
But that doesn't necessarily say anything good about that project!
Or, if a project is successful (many people use the software for many
years) then maintenance costs will be high.

- Bob

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Marin D. Condic]

Brian Rogoff wrote:
> 
> On Mon, 8 May 2000, Pascal Obry wrote:
> > I second that. Another way to put it : I do not care for the health of
> > the writer fingers :)
> >
> > What is important is readability and  maintenability (maintenance is where
> > 70% of the sofware cost is spent).
> 
> 87% of all statistics are made up on the spot :-)
> 
> I've heard similar statistics before, but I wonder how the cost estimation
> is done, and if it is biased towards certain kinds of software.
> 
That number is going to vary dramatically depending on the problem
domain. Lots of software is never maintained at all. I've heard that
Micro$oft doesn't generally maintain many applications. They write them
once, put them on the shelf, then plan on rewriting them with a whole
bunch of new features. (Obviously, this varies depending on the
product.)

MDC

-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Robert Dewar]

In article <39182AB3.45A63919@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> Lots of software is never maintained at all. I've heard that
> Micro$oft doesn't generally maintain many applications. They
> write them once, put them on the shelf, then plan on rewriting
> them with a whole bunch of new features. (Obviously, this
> varies depending on the product.)

"I've heard" is remarkably weak authority even by the low
standards of usenet groups. Really I think that posting such
vague accusations is quite unhelpful without at least the
semblance of authority. I am certainly the last person to
accuse Microsoft of practicing state-of-the-art software
engineering techniques in their software quality assurance
and maintenance efforts, but I think a claim that they
"generally don't maintain many applications" is not at all
helpful.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: STL, Ada, C++ (Was Re: The Next Microsoft?)

[Marin D. Condic]

Robert Dewar wrote:
> "I've heard" is remarkably weak authority even by the low
> standards of usenet groups. Really I think that posting such
> vague accusations is quite unhelpful without at least the
> semblance of authority. I am certainly the last person to
> accuse Microsoft of practicing state-of-the-art software
> engineering techniques in their software quality assurance
> and maintenance efforts, but I think a claim that they
> "generally don't maintain many applications" is not at all
> helpful.
> 
Do you really believe that there *aren't* a large number of applications
that are never maintained? :-)

Actually, it makes a lot of business sense. Why fix bugs on something
that you have to throw away anyway because you need a next generation
product that looks totally different? There's no profit in fixing bugs.
There *is* profit in coming out with a V2.0 that has all kinds of spiffy
new features.

As to the logical proof or forensic evidence or smoking gun or Rodney
King Videotape to back up my "I've heard" statement: Lots of folks post
things every day that are essentially hearsay. Is it useful or helpful?
Maybe. My point was that rectally extracting a number for cost of
maintenance (70% ???) is not very helpful unless you state the kind of
software that you're talking about and the environment in which it is
built. Some software is maintained for decades. (We can also argue about
what constitutes "maintenance" while we're at it. One man's
"maintenance" is another man's "spiral development") Other software is
built, smoke tested and put out for public consumption, never to be
revisited again. Maintenance costs as a percentage of total project
costs will vary quite a bit.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: The Next Microsoft?

[Jon S Anthony]

Hyman Rosen wrote:
> 
> Jon S Anthony <jsa@synquiry.com> writes:
> > Stepenov's arguments for this have never made the least bit of sense.
> > The whole of STL (imo) is wrongheaded from top to bottom and the
> > template stuff in support shows an equal incompetence.
> 
> You are entitled to this opinion, but it is wrong. The design of STL is

Which, of course, is just your opinion.  There are many reasons why I
hold my opinion, but I am not going to go into them here.


> supremely elegant. Not only does it give immense expressive power with
> simple syntax,

Here we are in complete disagreement.  This is some of the ugliest and
convoluted stuff ever put forward.


> properly.  Ada has nothing like it, since it is missing automatic
> instantiation of generics.

So?  I am not in any sense arguing for Ada here.  If I was arguing for
something in this context, I would be pointing you at Common Lisp.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: The Next Microsoft?

[Ayende Rahien]

> I like Ada. If I have to use a Wirth-style language, Ada is the
> language of choice.
>
> And if I ever end up writting software that would KILL someone if it
> goes wrong, I would professionally refuse to use any other language.
> Writing weapons control, avionics, nuke control, or medical device
> control software in any other langage is malfeasense, IMO.
>

Why is that?
--
Ayende Rahien

Ayende@softhom.net

"Ave, Caesar Imperator! Morituri te salutant!"

"Lottery: A tax for those who are bad in math."



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The Next Microsoft?

[Bobby D. Bryant]

Ray Blaak wrote:

> This myth about
> comitte-designed languages being somehow inferior is resoundingly false in
> Ada's case.

Actually, it's a myth in any case. A product should be judged on its merits, not
on who designed it. "Designed by committee" is just a knee-jerk response for when
you don't like something but don't have any real justification for your dislikes.

Also, it might be worth pointing out that the last car you drove, airplane you
rode, large building you worked in, specification you designed for, etc., were
all almost certainly "designed by committee".  People use committeeware all the
time without complaining, except when they are clutching at straws to defend
their dislike of something.

Bobby Bryant
Austin, Texas