* Re: The Next Microsoft? [not found] ` <8eu0ob$7qv$1@nnrp1.deja.com> @ 2000-05-05 0:00 ` Ray Blaak 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Bobby D. Bryant 0 siblings, 2 replies; 35+ messages in thread From: Ray Blaak @ 2000-05-05 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` The Next Microsoft? Ray Blaak @ 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Ayende Rahien 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Bobby D. Bryant 1 sibling, 2 replies; 35+ messages in thread From: Mark Atwood @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Mark Atwood @ 2000-05-05 0:00 ` Ayende Rahien 2000-05-05 0:00 ` Hyman Rosen 1 sibling, 0 replies; 35+ messages in thread From: Ayende Rahien @ 2000-05-05 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Ayende Rahien @ 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Mark Atwood 1 sibling, 1 reply; 35+ messages in thread From: Hyman Rosen @ 2000-05-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Hyman Rosen @ 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Hyman Rosen 0 siblings, 1 reply; 35+ messages in thread From: Mark Atwood @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Mark Atwood @ 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Jon S Anthony 0 siblings, 1 reply; 35+ messages in thread From: Hyman Rosen @ 2000-05-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Hyman Rosen @ 2000-05-05 0:00 ` Jon S Anthony 2000-05-05 0:00 ` Hyman Rosen 0 siblings, 1 reply; 35+ messages in thread From: Jon S Anthony @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Jon S Anthony @ 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Bill Greene 2000-05-05 0:00 ` The Next Microsoft? Jon S Anthony 0 siblings, 2 replies; 35+ messages in thread From: Hyman Rosen @ 2000-05-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Hyman Rosen @ 2000-05-05 0:00 ` Bill Greene 2000-05-06 0:00 ` Ehud Lamm 2000-05-07 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Brian Rogoff 2000-05-05 0:00 ` The Next Microsoft? Jon S Anthony 1 sibling, 2 replies; 35+ messages in thread From: Bill Greene @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Bill Greene @ 2000-05-06 0:00 ` Ehud Lamm 2000-05-07 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Brian Rogoff 1 sibling, 0 replies; 35+ messages in thread From: Ehud Lamm @ 2000-05-06 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 35+ messages in thread
* STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-05 0:00 ` Bill Greene 2000-05-06 0:00 ` Ehud Lamm @ 2000-05-07 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Florian Weimer 1 sibling, 2 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-07 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Brian Rogoff @ 2000-05-08 0:00 ` Robert Dewar 2000-05-07 0:00 ` Brian Rogoff ` (2 more replies) 2000-05-08 0:00 ` Florian Weimer 1 sibling, 3 replies; 35+ messages in thread From: Robert Dewar @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Robert Dewar @ 2000-05-07 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Pascal Obry 2000-05-08 0:00 ` Hyman Rosen 2 siblings, 0 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Robert Dewar 2000-05-07 0:00 ` Brian Rogoff @ 2000-05-08 0:00 ` Pascal Obry 2000-05-08 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Hyman Rosen 2 siblings, 1 reply; 35+ messages in thread From: Pascal Obry @ 2000-05-08 0:00 UTC (permalink / raw) [-- 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" ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Pascal Obry @ 2000-05-08 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Robert Dewar 2000-05-09 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Marin D. Condic 0 siblings, 2 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Brian Rogoff @ 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Pascal Obry 2000-05-09 0:00 ` STL, Ada, C++ Harry Erwin 2000-05-09 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Marin D. Condic 1 sibling, 2 replies; 35+ messages in thread From: Robert Dewar @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Robert Dewar @ 2000-05-08 0:00 ` Pascal Obry 2000-05-09 0:00 ` STL, Ada, C++ Harry Erwin 1 sibling, 0 replies; 35+ messages in thread From: Pascal Obry @ 2000-05-08 0:00 UTC (permalink / raw) [-- 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" ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Pascal Obry @ 2000-05-09 0:00 ` Harry Erwin 2000-05-09 0:00 ` Robert A Duff 1 sibling, 1 reply; 35+ messages in thread From: Harry Erwin @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ 2000-05-09 0:00 ` STL, Ada, C++ Harry Erwin @ 2000-05-09 0:00 ` Robert A Duff 0 siblings, 0 replies; 35+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Marin D. Condic 2000-05-09 0:00 ` Robert Dewar 1 sibling, 1 reply; 35+ messages in thread From: Marin D. Condic @ 2000-05-09 0:00 UTC (permalink / raw) 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] ====================================================================== ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Marin D. Condic @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Marin D. Condic 0 siblings, 1 reply; 35+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Marin D. Condic 0 siblings, 0 replies; 35+ messages in thread From: Marin D. Condic @ 2000-05-09 0:00 UTC (permalink / raw) 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] ====================================================================== ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Robert Dewar 2000-05-07 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Pascal Obry @ 2000-05-08 0:00 ` Hyman Rosen 2000-05-08 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Richard D Riehle 2 siblings, 2 replies; 35+ messages in thread From: Hyman Rosen @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Hyman Rosen @ 2000-05-08 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Richard D Riehle 1 sibling, 0 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-08 0:00 ` Hyman Rosen 2000-05-08 0:00 ` Brian Rogoff @ 2000-05-09 0:00 ` Richard D Riehle 2000-05-09 0:00 ` Brian Rogoff 1 sibling, 1 reply; 35+ messages in thread From: Richard D Riehle @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Richard D Riehle @ 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Brian Rogoff ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Brian Rogoff @ 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Hyman Rosen 2000-05-10 0:00 ` Richard D Riehle 2 siblings, 0 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Brian Rogoff @ 2000-05-09 0:00 ` Hyman Rosen 2000-05-09 0:00 ` Robert A Duff 2000-05-10 0:00 ` Richard D Riehle 2 siblings, 1 reply; 35+ messages in thread From: Hyman Rosen @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Hyman Rosen @ 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Hyman Rosen 0 siblings, 1 reply; 35+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Robert A Duff @ 2000-05-09 0:00 ` Hyman Rosen 0 siblings, 0 replies; 35+ messages in thread From: Hyman Rosen @ 2000-05-09 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Hyman Rosen @ 2000-05-10 0:00 ` Richard D Riehle 2000-05-10 0:00 ` Brian Rogoff 2 siblings, 1 reply; 35+ messages in thread From: Richard D Riehle @ 2000-05-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-10 0:00 ` Richard D Riehle @ 2000-05-10 0:00 ` Brian Rogoff 0 siblings, 0 replies; 35+ messages in thread From: Brian Rogoff @ 2000-05-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: STL, Ada, C++ (Was Re: The Next Microsoft?) 2000-05-07 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Brian Rogoff 2000-05-08 0:00 ` Robert Dewar @ 2000-05-08 0:00 ` Florian Weimer 1 sibling, 0 replies; 35+ messages in thread From: Florian Weimer @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Bill Greene @ 2000-05-05 0:00 ` Jon S Anthony 1 sibling, 0 replies; 35+ messages in thread From: Jon S Anthony @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: The Next Microsoft? 2000-05-05 0:00 ` The Next Microsoft? Ray Blaak 2000-05-05 0:00 ` Mark Atwood @ 2000-05-05 0:00 ` Bobby D. Bryant 1 sibling, 0 replies; 35+ messages in thread From: Bobby D. Bryant @ 2000-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2000-05-10 0:00 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <8eg37k$15n$1@nnrp1.deja.com> [not found] ` <8epkoa$b8b$1@nnrp1.deja.com> [not found] ` <E$OcUgAHHIE5Ewfl@quik.freeuk.net> [not found] ` <8eu0ob$7qv$1@nnrp1.deja.com> 2000-05-05 0:00 ` The Next Microsoft? Ray Blaak 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Ayende Rahien 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Mark Atwood 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Jon S Anthony 2000-05-05 0:00 ` Hyman Rosen 2000-05-05 0:00 ` Bill Greene 2000-05-06 0:00 ` Ehud Lamm 2000-05-07 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Brian Rogoff 2000-05-08 0:00 ` Robert Dewar 2000-05-07 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Pascal Obry 2000-05-08 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Pascal Obry 2000-05-09 0:00 ` STL, Ada, C++ Harry Erwin 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` STL, Ada, C++ (Was Re: The Next Microsoft?) Marin D. Condic 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Marin D. Condic 2000-05-08 0:00 ` Hyman Rosen 2000-05-08 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Richard D Riehle 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Brian Rogoff 2000-05-09 0:00 ` Hyman Rosen 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Hyman Rosen 2000-05-10 0:00 ` Richard D Riehle 2000-05-10 0:00 ` Brian Rogoff 2000-05-08 0:00 ` Florian Weimer 2000-05-05 0:00 ` The Next Microsoft? Jon S Anthony 2000-05-05 0:00 ` Bobby D. Bryant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox