* Development process in the Ada community @ 2002-04-10 16:33 Michael Erdmann 2002-04-10 23:28 ` Randy Brukardt ` (6 more replies) 0 siblings, 7 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-10 16:33 UTC (permalink / raw) Hallo all, i am wondering how standards are eveloving in the Ada community. In the Java Community there is a process called Java Community Process (JCP, http://www.jcp.org/) Is there something comparabel in the Ada communitiy? I gues if there would be something like this there would be more dynamic in the Ada 95 community. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann @ 2002-04-10 23:28 ` Randy Brukardt 2002-04-11 4:53 ` Michael Erdmann 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan ` (5 subsequent siblings) 6 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-10 23:28 UTC (permalink / raw) Michael Erdmann wrote in message <3CB46975.90408@snafu.de>... >Hallo all, > >i am wondering how standards are eveloving in the Ada community. >In the Java Community there is a process called Java Community >Process (JCP, http://www.jcp.org/) > >Is there something comparabel in the Ada communitiy? I gues >if there would be something like this there would be more >dynamic in the Ada 95 community. I'm not sure if this answers your question... The standard for the Ada Programming Language (and a variety of related standards) are managed by ISO/IEC JTC1 SC22 WG9 (http://wwwold.dkuug.dk/JTC1/SC22/WG9/). Because these are ISO standards, WG9 has to follow the procedures for creating ISO standards. Most of the actual work of fixing and improving the language standard occurs in a subcommittee of WG9 known as the ARG (Ada Rappetour Group). The ARG membership includes a wide variety of Ada vendors and users. Pretty much all that is required to informally monitor the process is to join the Ada-Comment mailing list (see http://www.adaic.org/standards/articles/comment.html.) You can look into the ARG's web site at http://www.ada-auth.org/ais.html (although that site is designed to be functional, not to impress people with our process). Randy Brukardt Editor, ISO/IEC JTC1 SC22 WG9 ARG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 23:28 ` Randy Brukardt @ 2002-04-11 4:53 ` Michael Erdmann 2002-04-11 7:34 ` Petter Fryklund ` (3 more replies) 0 siblings, 4 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 4:53 UTC (permalink / raw) Randy Brukardt wrote: > Michael Erdmann wrote in message <3CB46975.90408@snafu.de>... > >>Hallo all, >> >>i am wondering how standards are eveloving in the Ada community. >>In the Java Community there is a process called Java Community >>Process (JCP, http://www.jcp.org/) >> >>Is there something comparabel in the Ada communitiy? I gues >>if there would be something like this there would be more >>dynamic in the Ada 95 community. >> > > I'm not sure if this answers your question... > > The standard for the Ada Programming Language (and a variety of related > standards) are managed by ISO/IEC JTC1 SC22 WG9 > (http://wwwold.dkuug.dk/JTC1/SC22/WG9/). Because these are ISO > standards, WG9 has to follow the procedures for creating ISO standards. > Most of the actual work of fixing and improving the language standard > occurs in a subcommittee of WG9 known as the ARG (Ada Rappetour Group). > The ARG membership includes a wide variety of Ada vendors and users. > Pretty much all that is required to informally monitor the process is to > join the Ada-Comment mailing list (see > http://www.adaic.org/standards/articles/comment.html.) You can look into > the ARG's web site at http://www.ada-auth.org/ais.html (although that > site is designed to be functional, not to impress people with our > process). Thanks, yes this answers my question. I personally think this way of working is fairly outdated since it does not realy take the internet as a comminication media into accout. If you compare Ada 95 with Java, then the interesting points are not the languages it self, but the quick development of supporting components around it. If you take Ada 95 there is only a very limited set of predefined libraries standarized and thats it, nothing else. With JPC this is completly different! What i like to say it that not the language Ada is the illness, but the process around it which does not generate the dynamic as i would expect it from a language which is a live. Have there any attempts made to change the process towards a more dynmaic way of working? Regards M.Erdmann > > Randy Brukardt > Editor, ISO/IEC JTC1 SC22 WG9 ARG > > > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 4:53 ` Michael Erdmann @ 2002-04-11 7:34 ` Petter Fryklund 2002-04-11 16:39 ` Michael Erdmann 2002-04-11 8:37 ` Eric G. Miller ` (2 subsequent siblings) 3 siblings, 1 reply; 425+ messages in thread From: Petter Fryklund @ 2002-04-11 7:34 UTC (permalink / raw) would you really have that dynamic or would you like proven stability in the aircraft you're travelling with ;-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 7:34 ` Petter Fryklund @ 2002-04-11 16:39 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 16:39 UTC (permalink / raw) To: Petter Fryklund Petter Fryklund wrote: > would you really have that dynamic or would you like proven stability in the > aircraft you're travelling with ;-) > I am not talking about the language, but more about the development environment, e.g. POSIX Interface, Data Base Interfaces and other components. I feel all these things have been thought about along time ago, there are some standards (Mainly MIL ..ISO) out there, but they are old and outdated. This what i mean by mssing dynamic. A more public process might lead to more publicity, more up to date standards which are maintained not only by a advocatic community like ANSI, ITU or what so ever! There for i find the idea of the JCP quite interesting and something to think about in the Ada community. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 4:53 ` Michael Erdmann 2002-04-11 7:34 ` Petter Fryklund @ 2002-04-11 8:37 ` Eric G. Miller 2002-04-11 13:27 ` Marin David Condic 2002-04-11 17:26 ` Michael Erdmann 2002-04-11 10:41 ` Martin Dowie 2002-04-11 12:38 ` Jim Rogers 3 siblings, 2 replies; 425+ messages in thread From: Eric G. Miller @ 2002-04-11 8:37 UTC (permalink / raw) In <3CB516E1.9030008@snafu.de>, Michael Erdmann wrote: > I personally think this way of working is fairly outdated since > it does not realy take the internet as a comminication media into > accout. > If you compare Ada 95 with Java, then the interesting points are > not the languages it self, but the quick development of supporting > components around it. If you take Ada 95 there is only a very > limited set of predefined libraries standarized and thats it, > nothing else. With JPC this is completly different! How many changes in the Java language have occurred in the last ten years? How many are fully backwards compatible? Java aims to be a whole platform, but it's a moving target. What about developers who want their libraries and programs to be relevant for more than a couple years? IMHO, rapidly changing languages present a double edged sword. I think the goals of the two languages are somewhat orthogonal. I don't think there will ever be a "one size fits all" language. The safety and security features of Ada are very important to some folks, for instance. Oh, btw, this "outdated mode" of standardization is one thing that drew me to start using Ada vs. something like Java [tm], which is owned by Sun. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 8:37 ` Eric G. Miller @ 2002-04-11 13:27 ` Marin David Condic 2002-04-12 12:33 ` Larry Kilgallen 2002-04-12 23:59 ` Michael Erdmann 2002-04-11 17:26 ` Michael Erdmann 1 sibling, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-11 13:27 UTC (permalink / raw) I would agree that there needs to be stability around what might be called the "core" language. Certainly the 13 chapters of the ARM and possibly around the appendices as well. (Although I think it might be a benefit to be able to add to the appendices a little more easily to gain language extension without undue instability for the compiler writers.) But to look at Java and ask "what's good about what they are doing?" is important as well. Having a large library of support code that works to create a whole portable development environment might just be A Good Thing. Perhaps if the Ada standard process found a way of talking about "standard" libraries and incorporating them into the Ada language in some kind of semi-official way (with undue burdens or delays) it might help Ada find wider acceptance through the leverage it would offer to developers. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:pan.2002.04.11.01.38.30.887865.26212@jps-nospam.net... > > How many changes in the Java language have occurred in the last ten > years? How many are fully backwards compatible? Java aims to be > a whole platform, but it's a moving target. What about developers > who want their libraries and programs to be relevant for more than > a couple years? IMHO, rapidly changing languages present a double > edged sword. > > I think the goals of the two languages are somewhat orthogonal. I > don't think there will ever be a "one size fits all" language. > The safety and security features of Ada are very important to > some folks, for instance. > > Oh, btw, this "outdated mode" of standardization is one thing that > drew me to start using Ada vs. something like Java [tm], which is > owned by Sun. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 13:27 ` Marin David Condic @ 2002-04-12 12:33 ` Larry Kilgallen 2002-04-12 12:56 ` Marin David Condic 2002-04-12 23:59 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-12 12:33 UTC (permalink / raw) In article <a9430o$ee2$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > But to look at Java and ask "what's good about what they are doing?" is > important as well. Having a large library of support code that works to > create a whole portable development environment might just be A Good Thing. How many implementations of those standard libraries exist aside from the Java bytecode engine ? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-12 12:33 ` Larry Kilgallen @ 2002-04-12 12:56 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-12 12:56 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:Cszsj+N+tOUp@eisner.encompasserve.org... > In article <a9430o$ee2$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > > > But to look at Java and ask "what's good about what they are doing?" is > > important as well. Having a large library of support code that works to > > create a whole portable development environment might just be A Good Thing. > > How many implementations of those standard libraries exist aside > from the Java bytecode engine ? Isn't it more than what Ada has? Java may not be producing really good standards with lots of conformant implementations, but it does come with class libraries that do a lot of things for the programmer. Ada (as a standard) comes with some math and string stuff and some bindings to other things and what else? Specific vendors may supply more stuff (and then you start approaching copmpetitiveness with MFC - a vendor and platform specific library) but wouldn't it be better to have some kind of pseudo-standard collection of classes that go along with the language and do a bunch of work for the developer? All the arguments about Ada being "better" than one or more other languages fall below the noise floor if it can't offer the developmental leverage you get with some other language & its libraries. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 13:27 ` Marin David Condic 2002-04-12 12:33 ` Larry Kilgallen @ 2002-04-12 23:59 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-12 23:59 UTC (permalink / raw) Marin David Condic wrote: > I would agree that there needs to be stability around what might be called > the "core" language. Certainly the 13 chapters of the ARM and possibly > around the appendices as well. (Although I think it might be a benefit to be > able to add to the appendices a little more easily to gain language > extension without undue instability for the compiler writers.) I guess a public process imvoling the open source community as well would help to achieve this. > > But to look at Java and ask "what's good about what they are doing?" is > important as well. Having a large library of support code that works to > create a whole portable development environment might just be A Good Thing. > Perhaps if the Ada standard process found a way of talking about "standard" > libraries and incorporating them into the Ada language in some kind of > semi-official way (with undue burdens or delays) it might help Ada find > wider acceptance through the leverage it would offer to developers. Again i like to say i dont like what java is!!!!! The important point is that they have established a public process to improve there development environment, which i think is missing in the Ada community!!! Regards M.Erdmann > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > "Eric G. Miller" <egm2@jps-nospam.net> wrote in message > news:pan.2002.04.11.01.38.30.887865.26212@jps-nospam.net... > >>How many changes in the Java language have occurred in the last ten >>years? How many are fully backwards compatible? Java aims to be >>a whole platform, but it's a moving target. What about developers >>who want their libraries and programs to be relevant for more than >>a couple years? IMHO, rapidly changing languages present a double >>edged sword. >> >>I think the goals of the two languages are somewhat orthogonal. I >>don't think there will ever be a "one size fits all" language. >>The safety and security features of Ada are very important to >>some folks, for instance. >> >>Oh, btw, this "outdated mode" of standardization is one thing that >>drew me to start using Ada vs. something like Java [tm], which is >>owned by Sun. >> > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 8:37 ` Eric G. Miller 2002-04-11 13:27 ` Marin David Condic @ 2002-04-11 17:26 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 17:26 UTC (permalink / raw) Eric G. Miller wrote: > In <3CB516E1.9030008@snafu.de>, Michael Erdmann wrote: > > >>I personally think this way of working is fairly outdated since >>it does not realy take the internet as a comminication media into >>accout. >>If you compare Ada 95 with Java, then the interesting points are >>not the languages it self, but the quick development of supporting >>components around it. If you take Ada 95 there is only a very >>limited set of predefined libraries standarized and thats it, >>nothing else. With JPC this is completly different! >> > > How many changes in the Java language have occurred in the last ten > years? How many are fully backwards compatible? Java aims to be > a whole platform, but it's a moving target. What about developers > who want their libraries and programs to be relevant for more than > a couple years? IMHO, rapidly changing languages present a double > edged sword. > > I think the goals of the two languages are somewhat orthogonal. I > don't think there will ever be a "one size fits all" language. > The safety and security features of Ada are very important to > some folks, for instance. > > Oh, btw, this "outdated mode" of standardization is one thing that > drew me to start using Ada vs. something like Java [tm], which is > owned by Sun. > I am not saying that the old style of standarization make no sense any more. In the contrary, the core of a lagnuage should alwys be done like this (i guess), but the situation was as i remember that Ada development has been founded by gouvermental organizations, which has changed in the last years. My argument is not the language it self, but the environment around it, it should take the fact into account, that there is a strong open source movement which has to be chanelized some how by providing a public process which leads to open source standards. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 4:53 ` Michael Erdmann 2002-04-11 7:34 ` Petter Fryklund 2002-04-11 8:37 ` Eric G. Miller @ 2002-04-11 10:41 ` Martin Dowie 2002-04-11 16:50 ` Michael Erdmann 2002-04-11 20:26 ` Randy Brukardt 2002-04-11 12:38 ` Jim Rogers 3 siblings, 2 replies; 425+ messages in thread From: Martin Dowie @ 2002-04-11 10:41 UTC (permalink / raw) > I personally think this way of working is fairly outdated since > it does not realy take the internet as a comminication media into > accout. > If you compare Ada 95 with Java, then the interesting points are > not the languages it self, but the quick development of supporting > components around it. If you take Ada 95 there is only a very > limited set of predefined libraries standarized and thats it, > nothing else. With JPC this is completly different! > > What i like to say it that not the language Ada is the illness, > but the process around it which does not generate the dynamic > as i would expect it from a language which is a live. > > Have there any attempts made to change the process towards a more > dynmaic way of working? I work in avionics but not in any safety related work just now. In our developments such things as standard Directory & Socket packages (and a few others queues, lists etc) would be a great boon. Has any progress/agreement been made on the work to generate a 'standard' Directory package? Standard "Interfaces.Java" & "Interfaces.CPP" would be _very_ usefull too. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 10:41 ` Martin Dowie @ 2002-04-11 16:50 ` Michael Erdmann 2002-04-11 18:21 ` Marin David Condic 2002-04-11 20:26 ` Randy Brukardt 1 sibling, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 16:50 UTC (permalink / raw) To: Martin Dowie Martin Dowie wrote: >>I personally think this way of working is fairly outdated since >>it does not realy take the internet as a comminication media into >>accout. >>If you compare Ada 95 with Java, then the interesting points are >>not the languages it self, but the quick development of supporting >>components around it. If you take Ada 95 there is only a very >>limited set of predefined libraries standarized and thats it, >>nothing else. With JPC this is completly different! >> >>What i like to say it that not the language Ada is the illness, >>but the process around it which does not generate the dynamic >>as i would expect it from a language which is a live. >> >>Have there any attempts made to change the process towards a more >>dynmaic way of working? >> > > I work in avionics but not in any safety related work just now. In > our developments such things as standard Directory & Socket packages > (and a few others queues, lists etc) would be a great boon. There is a POSIX based package available (florist) and adasockets from S. Tardieu but they are not part of the Ada predefined packages. It is a pitty. > > Has any progress/agreement been made on the work to generate a 'standard' > Directory package? > > Standard "Interfaces.Java" & "Interfaces.CPP" would be _very_ usefull too. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 16:50 ` Michael Erdmann @ 2002-04-11 18:21 ` Marin David Condic 2002-04-12 4:43 ` tmoran ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-11 18:21 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CB5BED1.3090702@snafu.de... > There is a POSIX based package available (florist) and adasockets > from S. Tardieu but they are not part of the Ada predefined packages. > It is a pitty. > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It might even impose a layer on top that provided a whole Ada-ish look and feel to the endeavor, rather than being just a thin binding. A few things like this could go quite far in improving portable development life by getting an OS-independent view of common services. (With the usual stipulation that an implementation need not provide it at all, but if it does, it will have this interface.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:21 ` Marin David Condic @ 2002-04-12 4:43 ` tmoran 2002-04-12 11:13 ` Claw thick bindings to sockets (was: Development process in the Ada..) Larry Kilgallen 2002-04-12 23:19 ` Development process in the Ada community tony 2002-04-12 23:52 ` Michael Erdmann 2 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-12 4:43 UTC (permalink / raw) > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It > might even impose a layer on top that provided a whole Ada-ish look and feel > to the endeavor, rather than being just a thin binding. I will modestly propose the Claw Ada-ish thick binding to sockets. (A cut down, but still eminently usable, version is available for $0 at www.rrsoftware.com). A web server and a spider demonstrating it are available on www.adapower.com (Smplsrvr and Finder). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Claw thick bindings to sockets (was: Development process in the Ada..) 2002-04-12 4:43 ` tmoran @ 2002-04-12 11:13 ` Larry Kilgallen 2002-04-12 17:22 ` tmoran 0 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-12 11:13 UTC (permalink / raw) In article <DBtt8.902$Tm5.613040241@newssvr21.news.prodigy.com>, tmoran@acm.org writes: >> Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It >> might even impose a layer on top that provided a whole Ada-ish look and feel >> to the endeavor, rather than being just a thin binding. > I will modestly propose the Claw Ada-ish thick binding to sockets. > (A cut down, but still eminently usable, version is available for $0 at > www.rrsoftware.com). A web server and a spider demonstrating it are > available on www.adapower.com (Smplsrvr and Finder). That concept is interesting to me for a non-Microsoft operating system, but when I look at www.rrsoftware.com I realize I need guidance to find this. I see links for GUI bindings, but not anything for Unix-style IP sockets. Where should I be looking ? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Claw thick bindings to sockets (was: Development process in the Ada..) 2002-04-12 11:13 ` Claw thick bindings to sockets (was: Development process in the Ada..) Larry Kilgallen @ 2002-04-12 17:22 ` tmoran 2002-04-12 21:24 ` Larry Kilgallen 0 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-12 17:22 UTC (permalink / raw) > > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It > > > might even impose a layer on top that provided a whole Ada-ish look and feel > > > to the endeavor, rather than being just a thin binding. > > I will modestly propose the Claw Ada-ish thick binding to sockets. > > (A cut down, but still eminently usable, version is available for $0 at > > www.rrsoftware.com). A web server and a spider demonstrating it are > ... but when I look at www.rrsoftware.com I realize I need > guidance to find this. I see links for GUI bindings, but not > anything for Unix-style IP sockets. Where should I be looking ? Under "What's New" on the top right, click on "Claw Introductory Edition Available", then "Download Claw Now", or, directly www.rrsoftware.com/html/companyinf/news.html#clawintro Note that the spec is what I'm modestly proposing. The body at that web site runs on Windows. I don't know of anything in the spec that would make it less suitable for a Unix implementation. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Claw thick bindings to sockets (was: Development process in the Ada..) 2002-04-12 17:22 ` tmoran @ 2002-04-12 21:24 ` Larry Kilgallen 2002-04-12 23:18 ` tmoran 0 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-12 21:24 UTC (permalink / raw) In article <CJEt8.4033$p91.2051578013@newssvr14.news.prodigy.com>, tmoran@acm.org writes: >> > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It >> > > might even impose a layer on top that provided a whole Ada-ish look and feel >> > > to the endeavor, rather than being just a thin binding. > >> > I will modestly propose the Claw Ada-ish thick binding to sockets. >> > (A cut down, but still eminently usable, version is available for $0 at >> > www.rrsoftware.com). A web server and a spider demonstrating it are > >> ... but when I look at www.rrsoftware.com I realize I need >> guidance to find this. I see links for GUI bindings, but not >> anything for Unix-style IP sockets. Where should I be looking ? > Under "What's New" on the top right, click on "Claw Introductory Edition > Available", then "Download Claw Now", or, directly > www.rrsoftware.com/html/companyinf/news.html#clawintro Ok, that gives me prose, with some links to a page with choices based on Windows compilers. Is there any way to see just the specification ? > Note that the spec is what I'm modestly proposing. The body at that web Right now the licensing terms in the prose limit one to 30 days use. Are there plans to ease that license for the IP socket specification ? > site runs on Windows. I don't know of anything in the spec that would > make it less suitable for a Unix implementation. I guess when I wrote "Unix-style IP sockets" I should have said BSD-style IP sockets. My interest is not for Unix, but I think of that arcane interface used in C as being Unix-style. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Claw thick bindings to sockets (was: Development process in the Ada..) 2002-04-12 21:24 ` Larry Kilgallen @ 2002-04-12 23:18 ` tmoran 0 siblings, 0 replies; 425+ messages in thread From: tmoran @ 2002-04-12 23:18 UTC (permalink / raw) > on Windows compilers. Is there any way to see just the specification ? Just download and unzip from any one of the versions. The whole thing is under 500K, IIRC, so that's not too onerous these days. The file name for the socket spec will be either claw-sockets.ads or claw_soc.ads, depending on compiler and file naming convention. That version of Claw doesn't have the Help or HTML docs (about 10MB last I looked) so I'm afraid you'll have to look at the source code. > Right now the licensing terms in the prose limit one to 30 days use. For commercial use. Unlimited for personal use. > Are there plans to ease that license for the IP socket specification ? I certainly would have no problem and, given what he said here just the other day, I really doubt Randy Brukardt would have any problem with making it public domain or whatever. > I guess when I wrote "Unix-style IP sockets" I should have said > BSD-style IP sockets. My interest is not for Unix, but I think > of that arcane interface used in C as being Unix-style. Yes. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:21 ` Marin David Condic 2002-04-12 4:43 ` tmoran @ 2002-04-12 23:19 ` tony 2002-04-12 23:52 ` Michael Erdmann 2 siblings, 0 replies; 425+ messages in thread From: tony @ 2002-04-12 23:19 UTC (permalink / raw) Marin David Condic wrote: > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It > might even impose a layer on top that provided a whole Ada-ish look and feel > to the endeavor, rather than being just a thin binding. > There is the distributed annex which has been implemented in gnat-glade. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:21 ` Marin David Condic 2002-04-12 4:43 ` tmoran 2002-04-12 23:19 ` Development process in the Ada community tony @ 2002-04-12 23:52 ` Michael Erdmann 2002-04-15 14:35 ` Marin David Condic 2 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-12 23:52 UTC (permalink / raw) Marin David Condic wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message > news:3CB5BED1.3090702@snafu.de... > >>There is a POSIX based package available (florist) and adasockets >>from S. Tardieu but they are not part of the Ada predefined packages. >>It is a pitty. >> >> > > Maybe there needs to be an appendix to the ARM called Interfaces.Sockets? It > might even impose a layer on top that provided a whole Ada-ish look and feel > to the endeavor, rather than being just a thin binding. I guess a more sbatract concept for interprocess communication on basis of streams would be more apropriate. Personally i am always in favor of complext services provided to the developen rather than doing low level coding using a thin binding. > > A few things like this could go quite far in improving portable development > life by getting an OS-independent view of common services. (With the usual > stipulation that an implementation need not provide it at all, but if it > does, it will have this interface.) Maybe the basic ideas of Java can be resued here? Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-12 23:52 ` Michael Erdmann @ 2002-04-15 14:35 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-15 14:35 UTC (permalink / raw) Yeah, I like that idea, but I could still see some point in a lower level binding. On the one hand, it would be nice to have an interface that sent/received data to/from one or more partners that is based purely on streams & hides the underlying mechanisms. On the other hand, there are going to be lots of occasions where what you need is basically a one-to-one connection to Sockets that just looks Ada-ish instead of C-ish. (It could still use streams, obviously). Since the lower level binding is likely to be needed for producing any higher level communication abstraction, I'd say that it constituted A Good Start if it could become an Ada "convention". A higher level abstraction starts becoming problematic since there are so many possible ways of designing inter-process communication. Would it be one-to-one or one-to-many? Would it be some sort of message-registration and mailboxes? Or would you just have some general message queue that sees everything and the app discards what it doesn't want? See what I mean? It would be hard to come up with a model that would keep everyone happy. Better to get a lower level binding out there as a start and continue to think about a higher level abstraction for a later date. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CB77331.2030005@snafu.de... > > I guess a more sbatract concept for interprocess communication on basis > of streams would be more apropriate. Personally i am always in favor of > complext services provided to the developen rather than doing low > level coding using a thin binding. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 10:41 ` Martin Dowie 2002-04-11 16:50 ` Michael Erdmann @ 2002-04-11 20:26 ` Randy Brukardt 1 sibling, 0 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-11 20:26 UTC (permalink / raw) Martin Dowie wrote in message ... >Has any progress/agreement been made on the work to generate a 'standard' >Directory package? See AI-248 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT I keep hoping that the ARG will stop tinkering with it, but so far I've been disappointed. But I think it is pretty stable now. But we need to get compiler implementors to implement it... (Since it is a child of Ada, you can't do it yourself without some help from your compiler vendor -- compiling such a package is illegal by A.2(4).) Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 4:53 ` Michael Erdmann ` (2 preceding siblings ...) 2002-04-11 10:41 ` Martin Dowie @ 2002-04-11 12:38 ` Jim Rogers 2002-04-11 16:48 ` Michael Erdmann 2002-04-11 18:09 ` Ted Dennison 3 siblings, 2 replies; 425+ messages in thread From: Jim Rogers @ 2002-04-11 12:38 UTC (permalink / raw) Michael Erdmann wrote: > If you compare Ada 95 with Java, then the interesting points are > not the languages it self, but the quick development of supporting > components around it. If you take Ada 95 there is only a very > limited set of predefined libraries standarized and thats it, > nothing else. With JPC this is completly different! > > What i like to say it that not the language Ada is the illness, > but the process around it which does not generate the dynamic > as i would expect it from a language which is a live. Let's look at recent results of JPC efforts. j2sdk1.4.0 contains a new package java.nio. This package attempts to provide high performance I/O for Java. It provides direct access to a unix-like select command, as well as memory-mapped files, explicit buffers, and character translation. The "n" in "nio" stands for "new". This is a terrible name for a package. Beyond that quibble is the fact that this package seriously violates one of the foundation principles of the Java language. Java has always advertised the concept of "write once, run anywhere". One consequence of this goal is that Java could not support OS specific behavior, since that behavior could not be implemented anywhere. The java.nio package abandons that goal and implements I/O features not found on all OS platforms. It also provides an I/O model which is incompatible with the I/O defined in the java.io package. This is an example of rapid change without regard to its effect on the overall language principles. I do not want to see such rapid development results applied to Ada. Jim Rogers ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 12:38 ` Jim Rogers @ 2002-04-11 16:48 ` Michael Erdmann 2002-04-11 18:09 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 16:48 UTC (permalink / raw) To: Jim Rogers Jim Rogers wrote: > Michael Erdmann wrote: > >> If you compare Ada 95 with Java, then the interesting points are >> not the languages it self, but the quick development of supporting >> components around it. If you take Ada 95 there is only a very >> limited set of predefined libraries standarized and thats it, >> nothing else. With JPC this is completly different! >> >> What i like to say it that not the language Ada is the illness, >> but the process around it which does not generate the dynamic >> as i would expect it from a language which is a live. > > > > Let's look at recent results of JPC efforts. > > j2sdk1.4.0 contains a new package java.nio. This package > attempts to provide high performance I/O for Java. It provides > direct access to a unix-like select command, as well as > memory-mapped files, explicit buffers, and character > translation. The "n" in "nio" stands for "new". This is a > terrible name for a package. Beyond that quibble is the fact > that this package seriously violates one of the foundation > principles of the Java language. Java has always advertised the > concept of "write once, run anywhere". One consequence of this > goal is that Java could not support OS specific behavior, since > that behavior could not be implemented anywhere. The java.nio > package abandons that goal and implements I/O features not found > on all OS platforms. It also provides an I/O model which is > incompatible with the I/O defined in the java.io package. > > This is an example of rapid change without regard to its effect on > the overall language principles. I do not want to see such rapid > development results applied to Ada. > > Jim Rogers > I agree on this, may be they are a litle bit to fast, but i think Ada is i little bit to slow. Such things are happening in all kinds of instituations. But what i like to emphesze here the fact, that there IS A PROCESS (which might be missused as well) which is more public then ISO or ANSI. I think this is very important since the Ada communitiy does not consist only of developers doing brain surgery on atomic missiles but also on a lot of developers in smaller project which are using Ada 95 as well. To get these people in the process via the net would be a great achievement! Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 12:38 ` Jim Rogers 2002-04-11 16:48 ` Michael Erdmann @ 2002-04-11 18:09 ` Ted Dennison 2002-04-11 18:26 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-11 18:09 UTC (permalink / raw) Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3CB583D6.9000104@worldnet.att.net>... > principles of the Java language. Java has always advertised the > concept of "write once, run anywhere". One consequence of this > goal is that Java could not support OS specific behavior, since > that behavior could not be implemented anywhere. The java.nio > package abandons that goal and implements I/O features not found > on all OS platforms. It also provides an I/O model which is > incompatible with the I/O defined in the java.io package. > > This is an example of rapid change without regard to its effect on > the overall language principles. I do not want to see such rapid > development results applied to Ada. Java's Swing is another good example of this. AWT was found inadaquate as a GUI toolkit, so they just kept it and started over from scratch with Swing. But lots of old code uses AWT, so it can't go away. Instead you now have the new standard GUI and the old stardard GUI, left in as a trap for the unwary. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:09 ` Ted Dennison @ 2002-04-11 18:26 ` Michael Erdmann 2002-04-11 21:05 ` Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-11 18:26 UTC (permalink / raw) To: Ted Dennison Ted Dennison wrote: > Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<3CB583D6.9000104@worldnet.att.net>... > >>principles of the Java language. Java has always advertised the >>concept of "write once, run anywhere". One consequence of this >>goal is that Java could not support OS specific behavior, since >>that behavior could not be implemented anywhere. The java.nio >>package abandons that goal and implements I/O features not found >>on all OS platforms. It also provides an I/O model which is >>incompatible with the I/O defined in the java.io package. >> >>This is an example of rapid change without regard to its effect on >>the overall language principles. I do not want to see such rapid >>development results applied to Ada. >> > > Java's Swing is another good example of this. AWT was found inadaquate > as a GUI toolkit, so they just kept it and started over from scratch > with Swing. But lots of old code uses AWT, so it can't go away. > Instead you now have the new standard GUI and the old stardard GUI, > left in as a trap for the unwary. > > But is there any move in the Ada communitiy to standarize something in the GUI domain? Assume somebody would dare to try it, how could she/he achieve this? I never said that i like the stuff java is made of, but at least they are trying and consequently they are also failing! This is something i am missing in the Ada 95 comminuty. If you look at comp.lang.ada, you can break up the post in three categories: - Help Queries, how to do put_line , - My language is bettern then yours - Release note to the community But there only a small number of attempts made to establish some common understanding of a cetrain interface (which is a defacto standard) and afterwards setting up a project implementing it. You find the same behavior in the comp.lang.java groups,but at least they have something like the JCP, and not to forget SUN, to evelove (defacto) standards. From my perspective this is all missing in the Ada community. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:26 ` Michael Erdmann @ 2002-04-11 21:05 ` Randy Brukardt 2002-04-11 22:26 ` Ted Dennison 2002-04-12 8:35 ` Ingo Marks 2 siblings, 0 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-11 21:05 UTC (permalink / raw) Michael Erdmann wrote in message <3CB5D550.4000201@snafu.de>... >But is there any move in the Ada communitiy to standarize something in the GUI domain? >Assume somebody would dare to try it, how could she/he achieve this? That was the original idea behind Claw (in th 1996/7 timeframe). The idea was to create a de-facto standard, make a subset freely available, and eventually put the binding into the public domain to be a standard. However, it didn't work, because hardly anyone wanted to use it, preferring to roll their own. So we have a large number of such bindings. That is not necessarily a bad thing, but it does prevent any of them reaching a critical mass. Ada seems to have divided into a formally standardized part, and a completely informal part. But that's always been the case (look at all of the X bindings that were made for Ada 83 in the 1980s), and probably is part of the nature of things. > You find the same behavior in the comp.lang.java groups,but > at least they have something like the JCP, and not to forget > SUN, to evelove (defacto) standards. > From my perspective this is all missing in the Ada community. I can imagine an "ACP" would be useful, but the question is, who is going to pay for it? My experience as editor of the ARG is that getting the paper-pushing done by volunteers is like herding cats. When the budget allows, I often just do it myself. But writing standards is NOT fun, so I'm not surprised that people don't do it. In any case, an "ACP" would need someone to coordinate and enforce standards on the standards, and that pretty much requires paid personel. I'd like to be able to set up an internet process for secondary standards (the subject has been discussed in WG9), but it obviously would take an additional budget, and we're short on money (for work on the Amendment - "Ada 0y") as it is. Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:26 ` Michael Erdmann 2002-04-11 21:05 ` Randy Brukardt @ 2002-04-11 22:26 ` Ted Dennison 2002-04-12 13:13 ` Marin David Condic 2002-04-12 8:35 ` Ingo Marks 2 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-11 22:26 UTC (permalink / raw) Michael Erdmann wrote: > Ted Dennison wrote: > >> Java's Swing is another good example of this. AWT was found inadaquate >> as a GUI toolkit, so they just kept it and started over from scratch >> with Swing. But lots of old code uses AWT, so it can't go away. > But is there any move in the Ada communitiy to standarize something > in the GUI domain? Well..er..the Swing/AWT thing is actually *also* my archtypeal example of why its silly to even try to make a "standard" GUI. The argument surrounding it usually has to do with it being impossible to do everything everyone (or even a majority of everyone) wants to do with a GUI. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 22:26 ` Ted Dennison @ 2002-04-12 13:13 ` Marin David Condic 2002-04-15 14:28 ` Ted Dennison 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-12 13:13 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:3CB60E57.9090306@telepath.com... > > Well..er..the Swing/AWT thing is actually *also* my archtypeal example > of why its silly to even try to make a "standard" GUI. The argument > surrounding it usually has to do with it being impossible to do > everything everyone (or even a majority of everyone) wants to do with a GUI. > It always will be impossible so long as there exists two or more GUI platforms that look & feel different. But that doesn't mean that something couldn't be done anyway. It could go a couple of ways. One would be to say "Here's a minimal conforming set of classes that do GUI work in such a way as to be a least-common-denominator across some reasonably wide set of platforms. That part is 'Standard' and implementations are allowed to Embrace&Extend with the programmer being warned about portability." Another way to do it would be to just simply define an Ada-GUI that is its own thing. With a graphics engine and a markup language based on XML and the ability to interface to it, you're basically there.If the building blocks are in place, it just becomes its own environment (like Windows or Motif or whatever) and thats what you build your apps to. Not everyone will like it but then not everyone likes HTML-ish/Java-ish stuff they use via Netscape or IE. (Yet still, they use it!) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-12 13:13 ` Marin David Condic @ 2002-04-15 14:28 ` Ted Dennison 2002-04-15 17:53 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-15 14:28 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a96mhq$li6$1@nh.pace.co.uk>... > It always will be impossible so long as there exists two or more GUI > platforms that look & feel different. But that doesn't mean that something > couldn't be done anyway. Well of course *something* could be done. However, I don't believe anything particularly *useful* can be done. As far as anything useful can be done, the GtkAda folks have already done it. > It could go a couple of ways. One would be to say "Here's a minimal > conforming set of classes that do GUI work in such a way as to be a > least-common-denominator across some reasonably wide set of platforms. That That was the AWT approach. The result was that the Java community abandoned it and started over from scratch. As we don't have the resources they do, I propose that we cut out the middle-man. :-) > Another way to do it would be to just simply define an Ada-GUI that is its > own thing. With a graphics engine and a markup language based on XML and the Since that's essentially what Gtk is, what precisely would be the advantage of doing it ourselves rather than leveraging off of the Gtk work like the GtkAda folk have done? -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 14:28 ` Ted Dennison @ 2002-04-15 17:53 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-15 17:53 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0204150628.548b23e8@posting.google.com... > > Since that's essentially what Gtk is, what precisely would be the > advantage of doing it ourselves rather than leveraging off of the Gtk > work like the GtkAda folk have done? > I wouldn't be opposed to declaring GtkAda the annointed answer - with some eye toward extending its capabilities to be more useful while remaining portable. What are the odds we'd get the vendors to agree that this was The Moving Forward Plan? I think I had something else in mind - GtkAda does store the description of a GUI in XML, but ultimately it generates code that is compiled/linked for a given platform. What if there was an engine that interpreted an XML description of a GUI and you blipped XML text back and forth between the engine and the Ada program by some convention? Interpreting the XML at runtime has a lot of advantages and if the connection between the engine and your Ada program was over TCP/IP, your apps automatically work over the net. Its not as if you can't do this now by rolling-your-own & working with some existing things, but why couldn't there be a "conventional answer"? Something akin to this might make a better answer for a number of reasons. One of which is that an XML based solution would reduce to a relatively simple interface for the program that would mean a vendor could be "compliant" with it without having to do a lot of work. The other is that on the engine side of it, vendors can distinguish themselves with entirely different looks-and-feels if this seems desirable. In a sense, it would let the Ada developer develop as if there were a standard GUI, without actually needing there to *be* one. IIRC, Mozilla or someone out there was working on a "standard" XML markup for GUI descriptions. (Maybe someone can post a link? I seem to have lost track of it) Starting from here and defining a communication mechanism and a DOM and you're just about there. Then all you have is the hard part of generating the XML GUI engine that isn't a gross resource hog. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-11 18:26 ` Michael Erdmann 2002-04-11 21:05 ` Randy Brukardt 2002-04-11 22:26 ` Ted Dennison @ 2002-04-12 8:35 ` Ingo Marks 2002-04-12 14:37 ` Ted Dennison 2 siblings, 1 reply; 425+ messages in thread From: Ingo Marks @ 2002-04-12 8:35 UTC (permalink / raw) Michael Erdmann wrote: > But is there any move in the Ada communitiy to standarize something > in the GUI domain? What about GtkAda? http://libre.act-europe.fr/GtkAda/ http://www.gtk.org GTK is supported on many platforms (Unix, Win32, BeOS and even MacOSX, see http://www.apple.com/scitech/unixports). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-12 8:35 ` Ingo Marks @ 2002-04-12 14:37 ` Ted Dennison 2002-04-12 15:44 ` Georg Bauhaus 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-12 14:37 UTC (permalink / raw) Ingo Marks <adv@region-nord.de> wrote in message news:<a9666p$euv$06$1@news.t-online.com>... > Michael Erdmann wrote: > > > But is there any move in the Ada communitiy to standarize something > > in the GUI domain? > > What about GtkAda? > > http://libre.act-europe.fr/GtkAda/ > http://www.gtk.org > > GTK is supported on many platforms (Unix, Win32, BeOS and even MacOSX, see > http://www.apple.com/scitech/unixports). A very good point. I'd go so far as to say that GtkAda is the closest thing we have, and likely the closest thing we will ever have, to a standard Ada GUI. I use it for anything that isn't going to be OS-specific. But if you are OS-specific you are going to want to use the OS's standard GUI, so that everything looks and behaves the way the user expects. That's one of the main reasons why you really can't make one "standard" GUI for everyone. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-12 14:37 ` Ted Dennison @ 2002-04-12 15:44 ` Georg Bauhaus 0 siblings, 0 replies; 425+ messages in thread From: Georg Bauhaus @ 2002-04-12 15:44 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote: : I use it for anything that isn't going to be OS-specific. But if you : are OS-specific you are going to want to use the OS's standard GUI, so : that everything looks and behaves the way the user expects. That's one : of the main reasons why you really can't make one "standard" GUI for : everyone. And not even on one OS one grand unified GUI makes sense in all cases. Look at Photoshop's control windows, Framemaker has deviations that I don't want to miss, and so on. I think it is really a pity that supposedly standard "controls" are available at all, because this essentially stops UI developement towards applications that are really integrated into the OS. No need to build standard windows into your aplications, instead leave that to the OS! MS is doing a good job of slowly leading Windows GUI users (and developers!) towards what is already there, but rarely used: Ever noticed that you can use the container window that appears after "select Menu, chose File Open" much the same way you can use a very similar window outside applications, employing drag&drop, creating resources, deleting files, ...? Why on earth are there file open dialogs in a _G_UI? - georg ^ permalink raw reply [flat|nested] 425+ messages in thread
* Rant! (was) Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann 2002-04-10 23:28 ` Randy Brukardt @ 2002-04-11 21:14 ` Kent Paul Dolan 2002-04-11 23:20 ` tony ` (4 more replies) 2002-04-13 7:46 ` Michael Erdmann ` (4 subsequent siblings) 6 siblings, 5 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-11 21:14 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > i am wondering how standards are eveloving in the Ada community. > In the Java Community there is a process called Java Community > Process (JCP, http://www.jcp.org/) > Is there something comparable in the Ada communitiy? I guess > if there would be something like this there would be more > dynamic in the Ada 95 community. You have put your finger, probably, on the cause of the US Military's collapse on the issue of an Ada Mandate in the face of programmer intransigence to use Ada among the military community, in the answers you have received. The love of doing things one rigid way, with all decisions handed down from above, ran square into the software development community, which is used to speedy and flexible growth in its tools. Probably Ada was doomed to be the Horse Cavelry of programming languages the day its language standardization process was chosen, and I'm afraid you are going to find no cure for what is basically an incurable attitude problem of an entire, isolated programming community. Like Steven Jay Gould's "allopatric demes", Ada, brought back to cross fertilize with other programming languages and their newly invented mechanisms, might have provided hybrid vigor and a new, more competitive product. Instead you see what you see: "Why should we want a superior graphics interface to replace an inferior one, while maintaining the old one so as not to break old code?" "Why should the new developments become _part of the language_?" "Who needs a standard OS calling interface _in the language_?" "We don't need no stinking programming community inputs to the language!" "Procedure for change? We want stability, stability, stability!" [The Kaiser's army had stability; programming as a task by definition does not.] ad infinitum. No wonder the military programming community dragged heels until DoD caved. I was _really_ excited when Ada came out -- Pascal readability, but with power! I am no longer thrilled. Where are the parallel processing features _in the language_, the robust and powerful string parsing features _in the language_, the "programming by contract" features _in the language_, the standard higher level math libraries _in the language_, knowledge representation _in the langauge_, the SEI CMM model turned directly into a _standard_IDE _in the language_, the standard DoD and telecom community communication protocols, all _in the language_? When do the mind-bogglingly complex bogosities get ditched: _decimal_ specification of sizes for _binary_ data containers!!! Give me a break. "Progress, keeping up with community standards, is for other people!" Give me a break. Sigh. So much promise, so small a result. Given a complete community feedback loop and about a hundred times faster language change response time, Ada could be everyone's programming language of choice today. Java, alive for about 7 years, is due imminently for its fifth major release. That still doesn't guarantee its survival; Sun has an incurable attitude problem toward making Java truly freeware, but it does help. Ada doesn't even have a sponsor any more outside the compiler vendor community, and I don't even see any visible signs of public debate and motion toward a second much needed major overhaul and upgrade for twenty year old Ada, just a few well hidden notes on some standards committee web sites. That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole mindset problem. Unitary Usenet discussion groups are very characteristic of exactly one thing: _minor_ programming languages. xanthian. At least when I yelled at the Fortran standards folks back in 1987 or so, they responded, and arguably saved their language from the dust-bin as a result. Here, the outlook is not so rosy. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan @ 2002-04-11 23:20 ` tony 2002-04-12 0:55 ` Chad R. Meiners 2002-04-12 14:57 ` Ted Dennison 2002-04-12 10:10 ` Ingo Marks ` (3 subsequent siblings) 4 siblings, 2 replies; 425+ messages in thread From: tony @ 2002-04-11 23:20 UTC (permalink / raw) I was a student in 1987 when there was no ada open source. Ada in the military is a waste of Ada. A mix of a clearly understandable language with clearly understandable perverse human objectives. Open source with Ada however is a mixing of both write once and use around the world components. The amount of ada software now being produced open source amongst a community with no set objectives, no set one way of thinking, no hidden agenda, no management I think is astounding. Doomed to the horse calvalry is just a bad analogy I think because, Ada is doing very well in the open source community (against all odds) which is the true test. The true test of technology is in the open source community and not in the temporary distraction of the US military which appears to define the success of its technology in how many third world people you can murder or subjugate by pressing or not pressing a button. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 23:20 ` tony @ 2002-04-12 0:55 ` Chad R. Meiners 2002-04-12 1:21 ` Pat Rogers ` (2 more replies) 2002-04-12 14:57 ` Ted Dennison 1 sibling, 3 replies; 425+ messages in thread From: Chad R. Meiners @ 2002-04-12 0:55 UTC (permalink / raw) "tony" <tonygair@btinternet.com> wrote in message news:3CB61A78.271280C1@btinternet.com... > The true test of technology is in the open source community and not in > the temporary distraction of the US military which appears to define the > success of its technology in how many third world people you can murder > or subjugate by pressing or not pressing a button. Please refrain from supporting global ignorance by relying on rhetoric to persuade people. Just because you believe something doesn't make it true, and just because you say something over and over, also, doesn't make it true. If you care about the truth, you must carefully determine the truth with logically valid methods. In particular, please refrain from encouraging the irrational hatred of organizations such as the US military. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 0:55 ` Chad R. Meiners @ 2002-04-12 1:21 ` Pat Rogers 2002-04-12 15:57 ` Georg Bauhaus 2002-04-12 21:02 ` --off topic " tony 2 siblings, 0 replies; 425+ messages in thread From: Pat Rogers @ 2002-04-12 1:21 UTC (permalink / raw) "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:a95bdc$f67$1@msunews.cl.msu.edu... > > "tony" <tonygair@btinternet.com> wrote in message > news:3CB61A78.271280C1@btinternet.com... > > > The true test of technology is in the open source community and not in > > the temporary distraction of the US military which appears to define the > > success of its technology in how many third world people you can murder > > or subjugate by pressing or not pressing a button. > > Please refrain from supporting global ignorance by relying on rhetoric to > persuade people. Just because you believe something doesn't make it true, > and just because you say something over and over, also, doesn't make it > true. If you care about the truth, you must carefully determine the truth > with logically valid methods. In particular, please refrain from > encouraging the irrational hatred of organizations such as the US military. Well said. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 0:55 ` Chad R. Meiners 2002-04-12 1:21 ` Pat Rogers @ 2002-04-12 15:57 ` Georg Bauhaus 2002-04-12 22:20 ` Chad R. Meiners 2002-04-12 21:02 ` --off topic " tony 2 siblings, 1 reply; 425+ messages in thread From: Georg Bauhaus @ 2002-04-12 15:57 UTC (permalink / raw) Chad R. Meiners <crmeiners@hotmail.com> wrote: : If you care about the truth, you must carefully determine the truth : with logically valid methods. With consideration, o.K., but uhm, logically valid methods, leading to the truth... isn't that one of the beliefs of the years before a 1936 publication? And determining worldly facts is perhaps at least intractable, outside clerical reasoning. Still one might at least consider. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 15:57 ` Georg Bauhaus @ 2002-04-12 22:20 ` Chad R. Meiners 0 siblings, 0 replies; 425+ messages in thread From: Chad R. Meiners @ 2002-04-12 22:20 UTC (permalink / raw) With logically valid methods of reasoning, you must clearly distinguish that which you must assume (such as your reasoning axioms and your 'facts') from that which you prove. It is true that the power of logical reasoning is limited via Godel's proof, but this is never an excuse for allowing logical fallacies into any argument. Logic is still our best defense against the exploitation of ignorance and false conclusions. So even though we may not be able to enumerate all the truths of the universe, we can and should use logical reasoning; we simply must accept that there are some things that we cannot know. "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:a9704r$6ql$1@a1-hrz.uni-duisburg.de... > Chad R. Meiners <crmeiners@hotmail.com> wrote: > > : If you care about the truth, you must carefully determine the truth > : with logically valid methods. > > With consideration, o.K., but uhm, logically valid methods, leading to the > truth... isn't that one of the beliefs of the years before a 1936 > publication? And determining worldly facts is perhaps at least > intractable, outside clerical reasoning. Still one might at least consider. ^ permalink raw reply [flat|nested] 425+ messages in thread
* --off topic Re: Rant! (was) Development process in the Ada community 2002-04-12 0:55 ` Chad R. Meiners 2002-04-12 1:21 ` Pat Rogers 2002-04-12 15:57 ` Georg Bauhaus @ 2002-04-12 21:02 ` tony 2002-04-12 23:52 ` Chad R. Meiners 2 siblings, 1 reply; 425+ messages in thread From: tony @ 2002-04-12 21:02 UTC (permalink / raw) "Chad R. Meiners" wrote: > > Please refrain from supporting global ignorance by relying on rhetoric to > persuade people. In my bit to reduce global ignorance, I have looked up the following big words RELYING on the Oxford Dictionary, that you used. Rhetoric :- Art of presenting words impressively Thanks Chad. I didn't realise you were impressed. Repeated :- occurred more than once. I did not repeat myself. Ignorance :- lack of knowledge. For example not knowing the meaning of the words you write. >> Just because you believe something doesn't make it true, > and just because you say something over and over, also, doesn't make it > true. Gee thanks Grandma, can you tell me the truth now...... >> If you care about the truth, you must carefully determine the truth > with logically valid methods. In your post you implied that I was ignorant and now you imply I am lying. You are hereby strucken from my christmas card list. >> In particular, please refrain from > encouraging the irrational hatred of organizations such as the US military. Critiscism is not irrational hatred. What irrational Hatred am I encouraging? Does critiscism make me a Terrorist. The use and supply of weapons against civilians to further my ends in the world would be irrational hatred and terrorist. Bombing, strafing and the murder of unarmed civilian crowds in Somalia (The author of blackhawk down describes this in his book) is Irrational hatred and more. Opposing the design and production of satanic devices that make this possible is NOT irrational hatred, it is a logical valid method to oppose people who betray Humanity. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: --off topic Re: Rant! (was) Development process in the Ada community 2002-04-12 21:02 ` --off topic " tony @ 2002-04-12 23:52 ` Chad R. Meiners 2002-04-14 10:57 ` Georg Bauhaus 0 siblings, 1 reply; 425+ messages in thread From: Chad R. Meiners @ 2002-04-12 23:52 UTC (permalink / raw) Note that rhetoric does not deal with truth, but it does deal in impressing ideas upon people. Ergo, people that wish to persuade others without relying on the truth resort to rhetoric. As to repeating yourself, you accused the US military of both having perverse objectives, and of being murders. That is two attacks; the second attack would be the repeated attack. As to ignorance you are clearly ignorant of logical reasoning. As to your supposed 'criticism', in order for criticism to be valid it must be a well formed argument and be logically consistent. Otherwise your 'criticism' is likely to actually be defamation. So do you really care about truth or do you prefer to try to verbally force(impress) people into your point of view with your numerous personal attacks and abuses of the context and definition? If you care about truth, I would be more than happy to recommend some university courses on logic. That way you could have the tools to properly reason about truth. Otherwise, I suggest you look up one more word; this word is 'bigot'. Note that I am not calling you a bigot; I just think you should know what this word really means. As to your red herring about Somalia, you still cite no evidence; you only state your confidence in a book author's words. You also accuse the ENTIRE US military of crimes! Surely you cannot believe that everyone in the US military is guilty or responable for these crimes, but this is what you claim. Do you really want to accuse every person in the US military of murder? Please don't respond with any more personal attacks; they don't work on me. As long as you do not use logically valid means to present your arguments, I will not accept them since you do not have the tools to show that your arguments are valid. "tony" <tonygair@btinternet.com> wrote in message news:3CB74B83.D24F1835@btinternet.com... > "Chad R. Meiners" wrote: > > > > Please refrain from supporting global ignorance by relying on rhetoric to > > persuade people. > > In my bit to reduce global ignorance, I have looked up the following big > words RELYING on the Oxford Dictionary, that you used. > > Rhetoric :- Art of presenting words impressively > > Thanks Chad. I didn't realise you were impressed. > > Repeated :- occurred more than once. > > I did not repeat myself. > > Ignorance :- lack of knowledge. > > For example not knowing the meaning of the words you write. > > > > >> Just because you believe something doesn't make it true, > > and just because you say something over and over, also, doesn't make it > > true. > > Gee thanks Grandma, can you tell me the truth now...... > > >> If you care about the truth, you must carefully determine the truth > > with logically valid methods. > > In your post you implied that I was ignorant and now you imply I am > lying. You are hereby strucken from my christmas card list. > > >> In particular, please refrain from > > encouraging the irrational hatred of organizations such as the US military. > > Critiscism is not irrational hatred. What irrational Hatred am I > encouraging? Does critiscism make me a Terrorist. The use and supply of > weapons against civilians to further my ends in the world would be > irrational hatred and terrorist. > > Bombing, strafing and the murder of unarmed civilian crowds in Somalia > (The author of blackhawk down describes this in his book) is Irrational > hatred and more. Opposing the design and production of satanic devices > that make this possible is NOT irrational hatred, it is a logical valid > method to oppose people who betray Humanity. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: --off topic Re: Rant! (was) Development process in the Ada community 2002-04-12 23:52 ` Chad R. Meiners @ 2002-04-14 10:57 ` Georg Bauhaus 2002-04-14 22:17 ` Chad R. Meiners 0 siblings, 1 reply; 425+ messages in thread From: Georg Bauhaus @ 2002-04-14 10:57 UTC (permalink / raw) Chad R. Meiners <crmeiners@hotmail.com> wrote about tony's comments: : Note that rhetoric does not deal with truth, but it does deal in impressing : ideas upon people. That's a relatively recent (and narrowed) meaning of the word, afaik. Until few centuries ago, rhetoric counted as number two of the arts, close to logic, grammar, dialegein (not to be confused with the simple concept of yes/no/together again), and, in roman days, courts. Thus of course in those days it had to do with truth, in several ways. : As : to your supposed 'criticism', in order for criticism to be valid it must be : a well formed argument O.K. : and be logically consistent. That again is a modern axiom held by many scientists. By a mechanism known as group pressure it has become a dominant view in several scientific discussions, despite it's known difficulties. I'm not opposing that view entirely, but there are other views and they were described by scientists that were/are not actually nuts. (I'll try to find some interesting references next week, I hope.) : As to your red herring about Somalia, you still cite no evidence; you only : state your confidence in a book author's words. What will count as evidence? : "tony" <tonygair@btinternet.com> wrote in message :> Critiscism is not irrational hatred. (a claim, with an implicit all quantifier) :> Bombing, strafing and the murder of unarmed civilian crowds in Somalia :> (The author of blackhawk down describes this in his book) is Irrational :> hatred and more. Read as, "as described in the book", and given a truth universally aknowledged that there is hardly any war not somehow involving hatred as a motive of acts before/in wars, tony's sentence (this one) can, I think, indeed be read as a logically valid sentence, namely an impicit conclusion. (This doesn't say something about the validity of the premise (the book). However, if I say, "I'm confident that P /= NP, and based on that ..." this might be no evidence about P vs NP, but it certainly leeds to sound reasoning in current cirumstances, doesn't it. (P vs NP is not something I know a great deal about but if you allow me to use it for the sake of the argument...) :> Opposing the design and production of satanic devices :> that make this possible is NOT irrational hatred, it is a logical valid :> method to oppose people who betray Humanity. I see your point (I think), having read the article about a clever new weapon in IEEE Software, near Ada pride. However, within a scenario that involves satan, I can also see that these days people are not likely to agree that logic starts here. After all, famous betrayals with murderous consequence have been carried out with weapons not originally designed for murder, but for defence (...) and decoration, viz. daggers. As a final logical play, - measured by the number of guns etc. sold, shooting weapons are much more popular in the USA than in Europe. - timelessly popular devices reliably go with efforts to improve them, sell more - a programming language seen in connection with popular things will, by the principle of association (like in behaviourism), profit from the popularity of the things. ------------------- conclusion: ... :-) regards, Georg Bauhaus ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: --off topic Re: Rant! (was) Development process in the Ada community 2002-04-14 10:57 ` Georg Bauhaus @ 2002-04-14 22:17 ` Chad R. Meiners 0 siblings, 0 replies; 425+ messages in thread From: Chad R. Meiners @ 2002-04-14 22:17 UTC (permalink / raw) "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:a9bnbb$1bk$1@a1-hrz.uni-duisburg.de... > Chad R. Meiners <crmeiners@hotmail.com> > wrote about tony's comments: > : Note that rhetoric does not deal with truth, but it does deal in impressing > : ideas upon people. > > That's a relatively recent (and narrowed) meaning of the word, afaik. > Until few centuries ago, rhetoric counted as number two of the arts, > close to logic, grammar, dialegein (not to be confused with the > simple concept of yes/no/together again), and, in roman days, courts. > Thus of course in those days it had to do with truth, in several ways. I am aware of this. Of course since we are in the here and now and the modern definition works, I didn't try to use the old definition in this case. > > : As > : to your supposed 'criticism', in order for criticism to be valid it must be > : a well formed argument > > O.K. > > : and be logically consistent. > > That again is a modern axiom held by many scientists. By a > mechanism known as group pressure it has become a dominant > view in several scientific discussions, despite it's known > difficulties. I'm not opposing that view entirely, but there > are other views and they were described by scientists that > were/are not actually nuts. (I'll try to find some interesting > references next week, I hope.) I am sure your are well aware that you can prove anything from a logically inconsistent statement. E-mail me the references; I'll be glad to look at them. As I mention before, logic is our best defense against improper conclusions, not our only defense. > : As to your red herring about Somalia, you still cite no evidence; you only > : state your confidence in a book author's words. > > What will count as evidence? It depends, but paraphrasing a book is a little weak for the type of accusations. If I actually wanted to argue about what the US military did or did not do, I would be more than willing to reason with Tony's or was is and is not valid axioms and facts. I really just want to persuade people to argue better. > : "tony" <tonygair@btinternet.com> wrote in message > > :> Critiscism is not irrational hatred. > > (a claim, with an implicit all quantifier) > > :> Bombing, strafing and the murder of unarmed civilian crowds in Somalia > :> (The author of blackhawk down describes this in his book) is Irrational > :> hatred and more. > > Read as, "as described in the book", and given a truth universally > aknowledged that there is hardly any war not somehow involving > hatred as a motive of acts before/in wars, tony's sentence (this > one) can, I think, indeed be read as a logically valid sentence, > namely an impicit conclusion. (This doesn't say something about > the validity of the premise (the book). However, if I say, "I'm > confident that P /= NP, and based on that ..." this might be no > evidence about P vs NP, but it certainly leeds to sound reasoning > in current cirumstances, doesn't it. (P vs NP is not something > I know a great deal about but if you allow me to use it for the > sake of the argument...) I think you misunderstood to what I was referring. I have always been referring the Tony's original 'criticism' which was not a valid argument. When I was referring to the red herring I was trying to point out the overgeneralization as a example of what happens when you are not careful when you form your arguments. I really should just label red herring's and leave them be. Good example with the P /= NP. > :> Opposing the design and production of satanic devices > :> that make this possible is NOT irrational hatred, it is a logical valid > :> method to oppose people who betray Humanity. > > I see your point (I think), having read the article about a > clever new weapon in IEEE Software, near Ada pride. However, within > a scenario that involves satan, I can also see that these days > people are not likely to agree that logic starts here. > > After all, famous betrayals with murderous consequence have > been carried out with weapons not originally designed for > murder, but for defence (...) and decoration, viz. daggers. Of course most weapons were designed to hunt ;) (barring heavy weaponry) > As a final logical play, > - measured by the number of guns etc. sold, shooting weapons are much > more popular in the USA than in Europe. > - timelessly popular devices reliably go with efforts to improve them, > sell more > - a programming language seen in connection with popular things > will, by the principle of association (like in behaviourism), > profit from the popularity of the things. > ------------------- > conclusion: ... :-) Are you trying to imply that since a programming language associated with something cool becomes cool itself and that guns are cool in the USA, Ada's reputation should be cool in the USA since it is used to make reliable weapons? Of course you still need to show all the assumed implications are valid, but we really shouldn't need to go there. > regards, > Georg Bauhaus -CRM ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 23:20 ` tony 2002-04-12 0:55 ` Chad R. Meiners @ 2002-04-12 14:57 ` Ted Dennison 2002-04-12 23:12 ` tony 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-12 14:57 UTC (permalink / raw) tony <tonygair@btinternet.com> wrote in message news:<3CB61A78.271280C1@btinternet.com>... > I was a student in 1987 when there was no ada open source. > > Open source with Ada however is a mixing of both write once and use > around the world components. > > The amount of ada software now being produced open source amongst a > community with no set objectives, no set one way of thinking, no hidden > agenda, no management I think is astounding. > > Doomed to the horse calvalry is just a bad analogy I think because, > Ada is doing very well in the open source community (against all odds) > which is the true test. Hear, Hear! > The true test of technology is in the open source community and not in > the temporary distraction of the US military which appears to define the > success of its technology in how many third world people you can murder > or subjugate by pressing or not pressing a button. (sits back down) Errr...no. This argument is the moral equivalent of someone saying that all Palestinians are heartless murdering terrorists or all Jews are .... (on second though, I don't even want to go into this). I'm not saying that if you had toned this statement back a bit, you wouldn't have had half a point. But, there is way too much hatred, half-truths, and willful ignorance in the world already. If we truly care about peace, we need to be trying with all our might right now to fight it, not spread more of it. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 14:57 ` Ted Dennison @ 2002-04-12 23:12 ` tony 0 siblings, 0 replies; 425+ messages in thread From: tony @ 2002-04-12 23:12 UTC (permalink / raw) You're right Ted, but my blood goes all curdled and I transform into a troll when I hear Ada being bad mouthed, the rest (although heartfelt) just poured from that. I will have more tolerance in the future, and I will shut up about my politics. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan 2002-04-11 23:20 ` tony @ 2002-04-12 10:10 ` Ingo Marks 2002-04-12 11:11 ` Larry Kilgallen ` (2 more replies) 2002-04-12 21:17 ` Wes Groleau ` (2 subsequent siblings) 4 siblings, 3 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-12 10:10 UTC (permalink / raw) Kent Paul Dolan wrote: > Sigh. So much promise, so small a result. Given a complete community > feedback loop and about a hundred times faster language change response > time, Ada could be everyone's programming language of choice today. > ... > That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole > mindset problem. Unitary Usenet discussion groups are very > characteristic of exactly one thing: _minor_ programming languages. IMHO the major problems with Ada in the community are - Who continues Ada compiler support in the future? Now we have some kind companies who provide good Ada compilers (commercial and for free). But someday they could say: "There is no more demand for commercial Ada so we have decided to stop further Ada support." What then? It is not enough to have a good dynamic Ada standardization process. It is also important to have continuing Ada compiler support in the future! - Java and C# are much easier to learn. They are less expressive than Ada and suitable for small to medium projects. You can write software easier, shorter and faster - but more reliable? People have to know that Ada is pretty hard to learn (and you have to write more code) but makes your life easier afterwars (IMHO it's the same with Linux compared to Windows ;-). In bigger projects readibility of (self-commenting) code becomes a serious issue to consider. Studies show that development in Ada costs about half the time of development in C++. This is a quality of Ada that would make software developing companies curious surely if there would be a living Ada community and enough developers they could hire. I know that there _are_ companies out there who want to hire Ada developers but cannot find anyone. But they can get many Java developers so they decide to use Java in favor of Ada. - Ada was not popular because a) it has the image of a general-purpose-"military only"-language and b) most Ada compilers were way too be expensive to be affordable for the normal (hobby) programmer who wants to learn and play with Ada. Since there are free Ada compilers for everyone, the interest for Ada has raised and will continue to raise. Of course, addons like GNU Visual Debugger and AdaGIDE make Ada more attractive. Michael Erdmann and others are right when they say Ada needs a general purpose standardization process. Some people in comp.lang.ada are right when they say a very good incentive to make Ada attractive to newbies would be an IDE with the feeling and power of Visual Studio .NET. Could Ada have the same history as Unix? I remember earlier years when the press said that Unix would be on the way to die surely and it would merely be a matter of years when Unix will be replaced by Windows completely. Then Linux and the Open Source movement rised and suddenly Unix (its modern variants Linux, BSD, MacOSX) become more and more popular. One reason for this is that the hardware was getting better and better and suitable to have Unix for everyone. In "ancient" years we had Cobol, Fortran, C and C++. In earlier years Visual Basic, Perl and PHP were very popular languages, but now more and more people realize that these languages are not suitable for bigger projects. That's why Java became popular. It's a polished version of C and C++ and requires little learning for C++ converts. MS realized the success of Java and decided to copy the Java framework and make their own version, together with C#, a polished version of Java. So for the last years we can see a "downgrade" from pretty complex popular languages like C and C++ to lightweight languages like PHP, VB etc., recently followed by an "upgrade" trend to more powerful languages (Java and C#). Several people are still not happy with Java and C#. They try other languages (Python, Ruby, functional languages). Here I see a chance for Ada to become more popular. Software becomes more and more complex, and this raising complexity is the area where readibility becomes more important and which Ada fits well. Linux gained its success because of its good word-of-mouth recommendation. I think Ada needs the same. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 10:10 ` Ingo Marks @ 2002-04-12 11:11 ` Larry Kilgallen 2002-04-12 23:18 ` tmoran 2002-04-12 17:22 ` Florian Weimer 2002-04-13 3:30 ` Robert Dewar 2 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-12 11:11 UTC (permalink / raw) In article <a96bou$fb5$02$1@news.t-online.com>, Ingo Marks <adv@region-nord.de> writes: > - Who continues Ada compiler support in the future? Now we have some kind > companies who provide good Ada compilers (commercial and for free). But > someday they could say: "There is no more demand for commercial Ada so we > have decided to stop further Ada support." What then? It is not enough to > have a good dynamic Ada standardization process. It is also important to > have continuing Ada compiler support in the future! And Microsoft could say that .NET was the wave of the future, replacing COM, which had replaced DCOM, which had replaced something whose name I forget. Or Apple could drop support for AOCE when they thought it unpopular. Frankly I trust small companies much more than larger ones. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 11:11 ` Larry Kilgallen @ 2002-04-12 23:18 ` tmoran 0 siblings, 0 replies; 425+ messages in thread From: tmoran @ 2002-04-12 23:18 UTC (permalink / raw) > > - Who continues Ada compiler support in the future? Now we have some kind > > companies who provide good Ada compilers (commercial and for free). But > ... > Frankly I trust small companies much more than larger ones. Once upon a time a lot of companies bought RCA mainframes instead of IBM, sure in the knowledge that RCA wasn't going to go out of business. Similarly that well known large PC maker, Texas Instruments. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 10:10 ` Ingo Marks 2002-04-12 11:11 ` Larry Kilgallen @ 2002-04-12 17:22 ` Florian Weimer 2002-04-12 17:38 ` Mário Amado Alves 2002-04-12 18:29 ` Kent Paul Dolan 2002-04-13 3:30 ` Robert Dewar 2 siblings, 2 replies; 425+ messages in thread From: Florian Weimer @ 2002-04-12 17:22 UTC (permalink / raw) Ingo Marks <adv@region-nord.de> writes: > - Who continues Ada compiler support in the future? Now we have some kind > companies who provide good Ada compilers (commercial and for free). But > someday they could say: "There is no more demand for commercial Ada so we > have decided to stop further Ada support." If there is no commercial demand (and no demand in the Free Software community either), then you are not using Ada. What's the problem? > I remember earlier years when the press said that Unix would be on the way > to die surely and it would merely be a matter of years when Unix will be > replaced by Windows completely. A large problem in the UNIX community was (and still is) vendor fragmentation. There are at least three proprietary general-purpose UNIX implementations which are used widely. We have seen a lot of convergence, but there are still problems. I hope this is not the way ahead of Ada! > MS realized the success of Java What "success of Java" are you talking about? Hardly anybody is using Java in areas it was originally marketed for. > Here I see a chance for Ada to become more popular. Scripting languages like Perl and PHP encourage a development model which is mostly incompatible with Ada. I don't think many scripting language enthusiasts can be converted to Ada. ^ permalink raw reply [flat|nested] 425+ messages in thread
* RE: Rant! (was) Development process in the Ada community 2002-04-12 17:22 ` Florian Weimer @ 2002-04-12 17:38 ` Mário Amado Alves 2002-04-12 18:29 ` Kent Paul Dolan 1 sibling, 0 replies; 425+ messages in thread From: Mário Amado Alves @ 2002-04-12 17:38 UTC (permalink / raw) "Scripting languages like Perl and PHP encourage a development model which is mostly incompatible with Ada." (Florian) Do you mean the "write once never read" attribute of PERL (and likely of PHP as well) i.e. maintainability, short vs. long lived applications? How about when the requirements configure a short life span in the first place (as it is often the case today)? --MAA ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 17:22 ` Florian Weimer 2002-04-12 17:38 ` Mário Amado Alves @ 2002-04-12 18:29 ` Kent Paul Dolan 1 sibling, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-12 18:29 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote: > What "success of Java" are you talking about? Hardly anybody is using > Java in areas it was originally marketed for. Umm, which is why MS tried so hard to sabotage it and create a version locked to MS-Windows that it took a court order to break up their little game? I think your view of reality is flawed here. > Scripting languages like Perl and PHP encourage a development model > which is mostly incompatible with Ada. I don't think many scripting > language enthusiasts can be converted to Ada. You must not use them much, then. Scripting languages are "glue" languages, used to put software written in other languages into compatibly working clusters. In particular, Larry Wall created PERL to be a glue language. http://www.salon.com/21st/feature/1998/10/cov_13feature.html I cannot imagine the particular choice of programming language determining the development model. You can go SEI CMM level 5 in PERL, Ada, Logo, or any other programming language; the development model is pretty much an orthogonal issue to the choice of programming language. I will grant that one can _also_ use PERL to "hack out a quick solution", but then, that's what it's intended to be, a multi-pronged tool for getting to the needed result with low pain and high speed. I refused to learn PERL (line noise incarnate to the uninitiated) until long after I learned Ada. Then I finally used PERL, and regretted the six years I had pushed it aside. I'd just like to see Ada pick up some of the really nifty features of PERL, but then I'd like to see all of my programming languages (all nine or ten dozen, but I've forgotten most of them by now, luckily, or my poor head would have exploded) do the same. There isn't a programming language alive that couldn't use PERL's parsing power. Somewhere off this thread with a broken references pointer is a remark that PERL is a "write once, read never" language, or some such. Not so. Like C, like APL, PERL is a "takes time to learn" language. Once you get into it, its sheer beauty and economy of expression will amaze you; it was, after all, designed by a guy with his undergraduate training in linguistics. PERL, whether you buy the "Practical Extraction and Report-writing Language" which is the official version, or the creator's "Pathologically Eclectic Rubbish Lister", is a tool any professional programmer wants in his or her toolkit. Meanwhile, getting back on topic, it is exactly this concept that Ada has some sacred development model that seems to be paralyzing improvements in Ada as a programming language, and impoverishing Ada as a programming community. Development models are not programming languages, nor does improving a language damage a development model! xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-12 10:10 ` Ingo Marks 2002-04-12 11:11 ` Larry Kilgallen 2002-04-12 17:22 ` Florian Weimer @ 2002-04-13 3:30 ` Robert Dewar 2002-04-13 10:12 ` martin.m.dowie 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-13 3:30 UTC (permalink / raw) Ingo Marks <adv@region-nord.de> wrote in message news:<a96bou$fb5$02$1@news.t-online.com>... > Some people in comp.lang.ada are > right when they say a very good incentive to make Ada > attractive to newbies > would be an IDE with the feeling and power of Visual > Studio .NET. Stay tuned :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 3:30 ` Robert Dewar @ 2002-04-13 10:12 ` martin.m.dowie 2002-04-13 13:21 ` Larry Kilgallen 2002-04-13 14:20 ` Robert Dewar 0 siblings, 2 replies; 425+ messages in thread From: martin.m.dowie @ 2002-04-13 10:12 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204121930.64733eeb@posting.google.com... > Ingo Marks <adv@region-nord.de> wrote in message news:<a96bou$fb5$02$1@news.t-online.com>... > > > Some people in comp.lang.ada are > > right when they say a very good incentive to make Ada > > attractive to newbies > > would be an IDE with the feeling and power of Visual > > Studio .NET. > > Stay tuned :-) I nearly misread this as a hint of future support for ".NET" but a quick look at the www.gnat.com front page and I think it is more of a hint that there is a new post-GLIDE IDE coming (GPS). Shame - could have been the most significant announcement on this newsgroup for the last 5 years... ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 10:12 ` martin.m.dowie @ 2002-04-13 13:21 ` Larry Kilgallen 2002-04-13 13:39 ` martin.m.dowie 2002-04-13 14:20 ` Robert Dewar 1 sibling, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-13 13:21 UTC (permalink / raw) In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>, "martin.m.dowie" <martin.m.dowie@ntlworld.com> writes: > I nearly misread this as a hint of future support for ".NET" but a quick > look at the www.gnat.com front page and I think it is more of a hint that > there is a new post-GLIDE IDE coming (GPS). > > Shame - could have been the most significant announcement on this > newsgroup for the last 5 years... Or not. That certainly is a matter of opinion. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 13:21 ` Larry Kilgallen @ 2002-04-13 13:39 ` martin.m.dowie 2002-04-13 14:12 ` Gary Scott 0 siblings, 1 reply; 425+ messages in thread From: martin.m.dowie @ 2002-04-13 13:39 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:2imowKjzt7uP@eisner.encompasserve.org... > In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>, "martin.m.dowie" <martin.m.dowie@ntlworld.com> writes: > > > I nearly misread this as a hint of future support for ".NET" but a quick > > look at the www.gnat.com front page and I think it is more of a hint that > > there is a new post-GLIDE IDE coming (GPS). > > > > Shame - could have been the most significant announcement on this > > newsgroup for the last 5 years... > > Or not. That certainly is a matter of opinion. True - but IMHO any Ada.NET support would be hugely welcome! :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 13:39 ` martin.m.dowie @ 2002-04-13 14:12 ` Gary Scott 0 siblings, 0 replies; 425+ messages in thread From: Gary Scott @ 2002-04-13 14:12 UTC (permalink / raw) "martin.m.dowie" wrote: > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:2imowKjzt7uP@eisner.encompasserve.org... > > In article <5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com>, > "martin.m.dowie" <martin.m.dowie@ntlworld.com> writes: > > > > > I nearly misread this as a hint of future support for ".NET" but a quick > > > look at the www.gnat.com front page and I think it is more of a hint > that > > > there is a new post-GLIDE IDE coming (GPS). > > > > > > Shame - could have been the most significant announcement on this > > > newsgroup for the last 5 years... > > > > Or not. That certainly is a matter of opinion. > > True - but IMHO any Ada.NET support would be hugely welcome! :-) True and if a minor language like Fortran 95 has 4 or 5 .net commercial products in development... Heck, there's even COBOL.net for gosh sakes. No Ada.net would be a true embarrassment. (ok, I'm just joshin') -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 10:12 ` martin.m.dowie 2002-04-13 13:21 ` Larry Kilgallen @ 2002-04-13 14:20 ` Robert Dewar 2002-04-13 16:03 ` martin.m.dowie 2002-04-16 1:41 ` Rant! (was) Development process in the Ada community Richard Riehle 1 sibling, 2 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-13 14:20 UTC (permalink / raw) "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:<5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com > Shame - could have been the most significant announcement > on this newsgroup for the last 5 years... We have no plans to do anything with .NET and GNAT so far, since there has been absolutely zero significant interest in such a product (postings on CLA I am sorry to say do not register as significant interest). In fact the lack of interest is surprising, we have not even had enquiries on this topic. Needless to say, our assessment of significance is somewhat different from yours :-) It's all a bit reminiscent of two things in the past. Big chorus of people interested in GNAT for the Mac. But no significant interest emerged. Yes, there is a volunteer effort to keep GNAT alive on the Mac for the enthusiastic few :-) which is great, and one of the respects in which the Free Software approach is attractive. Big chorus (backed up by DoD money) of people interested in an Ada compiler generating code for the JVM. But only marginal interest emerged, so that port is now on terminal life support from us. Perhaps a significant volunteer effort will arise there too, but so far no sign of it. Now on the other hand interest in IDE's -- that's real indeed, and that is where we are putting a lot of effort these days. Perhaps .NET will emerge as significant, perhaps not. Hard to say. I think those who imagine that Ada for .NET will somehow spark new interest in Ada are indulging in wishful thinking. For me, the most interesting avenue for getting more people interested in Ada is to concentrate on things that will appeal to this generation of CS students who are working with Free Software extensively. Hint: anything to do with Microsoft does NOT appeal to students these days, who routinely refer to Microsoft as the "dark side", a phenomenon that I think MS should be paying far more attention too :-) Many of my students are shocked to see me using Windows XP these days. But of course there *is* significant interest in GNAT running under XP, so that's a different matter entirely :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 14:20 ` Robert Dewar @ 2002-04-13 16:03 ` martin.m.dowie 2002-04-15 15:03 ` Marin David Condic 2002-04-18 14:15 ` Ted Dennison 2002-04-16 1:41 ` Rant! (was) Development process in the Ada community Richard Riehle 1 sibling, 2 replies; 425+ messages in thread From: martin.m.dowie @ 2002-04-13 16:03 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204130620.114953ae@posting.google.com... > "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:<5wTt8.15598$C21.3515342@news6-win.server.ntlworld.com > > > Shame - could have been the most significant announcement > > on this newsgroup for the last 5 years... > > We have no plans to do anything with .NET and GNAT so far, since there > has been absolutely zero significant interest in such a product > (postings on CLA I am sorry to say do not > register as significant interest). In fact the lack of interest is > surprising, we have not even had enquiries on > this topic. > > Needless to say, our assessment of significance is somewhat different > from yours :-) [snip] I totally respect your decisions on what to target new development on - it is your business. I'm just sorry I can't bring the bucks to the table to make it worth while for you (or anyone else) to do this :-( It is a shame that COBOL has Fujitsu to develop COBOL.NET but that Ada has no such large corporate to perform this sort of work. Without such a sponsor it is hard to see how Ada gets out of the catch22 of: User: "Why use Ada when it doesn't support feature X?" Vendor: "Why support feature X when there is no user demand?" Perhaps there is some hope in the 'DotGNU' project. The item that interested me in the FAQ for this is: "1.17 Will C and C++ be supported in DotGNU? Code which is written in C or C++ can be used with DotGNU, *if* it is distributed with DotGNU or otherwise installed like you normally install software. However you cannot use C or C++ to implement webservice programs that are meant to run in the Secure Execution Environment (SEE), like it will be possible with e.g. Java, Ada, C# and Perl - at least not until someone solves the difficult issues of compiling C to some kind of portable intermediate representation in such a way that the Secure Execution Environment can efficiently verify that the program is not trying to do something malicious." ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 16:03 ` martin.m.dowie @ 2002-04-15 15:03 ` Marin David Condic 2002-04-16 8:30 ` Frank 2002-04-16 15:43 ` martin.m.dowie 2002-04-18 14:15 ` Ted Dennison 1 sibling, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-15 15:03 UTC (permalink / raw) "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net... > > It is a shame that COBOL has Fujitsu to develop COBOL.NET but > that Ada has no such large corporate to perform this sort of work. > Without such a sponsor it is hard to see how Ada gets out of the > catch22 of: > User: "Why use Ada when it doesn't support feature X?" > Vendor: "Why support feature X when there is no user demand?" > Maybe its worth looking for a big corporate sponsor? A corporation that is looking to distinguish itself as something "different" from the rest of the pack? The Ada vendors have the problem that they lack the resources to sink into tools/targets "on spec" that something will emerge. But for a large corporation that may have the need for such products (internally or externally), the development cost might look like a spit in the bucket. Maybe finding some "strategic partners" creates advantages for Ada as well as advantages for the parties involved. Of course there are always those sticky cliche's about "riding on the back of the tiger" or "getting into bed with an elephant" and such to serve as a reality check. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-15 15:03 ` Marin David Condic @ 2002-04-16 8:30 ` Frank 2002-04-21 11:35 ` Michal Nowak 2002-04-16 15:43 ` martin.m.dowie 1 sibling, 1 reply; 425+ messages in thread From: Frank @ 2002-04-16 8:30 UTC (permalink / raw) Hi! I have seen that Oracle's PLSQL is inspired by the Ada standard. I wonder if there are some historical material related to PLSQL vs Ada (?), but I don't know the history (born too late :-). To me it looks like Ada had a golden oportunitue to "ride on the back of a tiger" when the PLSQL were initiated. Were there some discussion related to this "once upon a time"?-) Oracle probably choose their own way due to market analyzis. Of course this is looking into the past. Frank ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 8:30 ` Frank @ 2002-04-21 11:35 ` Michal Nowak 0 siblings, 0 replies; 425+ messages in thread From: Michal Nowak @ 2002-04-21 11:35 UTC (permalink / raw) On 2002-04-16 at 10:30 Frank wrote: >Hi! > >I have seen that Oracle's PLSQL is inspired by the Ada standard. I wonder if >there are >some historical material related to PLSQL vs Ada (?), but I don't know the >history (born too late :-). >To me it looks like Ada had a golden oportunitue to "ride on the back of a >tiger" when the PLSQL >were initiated. Were there some discussion related to this "once upon a >time"?-) Oracle probably choose their own way due to market analyzis. That's nice that PLSQL was inspired by Ada, although no many people know it. Oracle had some tool for Ada, but now it is gone. There was Pro*Ada Precompiler, but it was in versions 7.*. I had no possibility to use (or try it), because I started with Oracle from 8.*. I seen somewhere on their web pages, that Pro*Ada will be no longer included (but there is ProC/C++, ProFortran and ProCOBOL). However, there is still SQL Module for Ada, but I don't know for how long it will exist. Documentation file for this product is dated for December 1997, while for other products - no earlier than 1999. A bit sad perspective... Mike ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-15 15:03 ` Marin David Condic 2002-04-16 8:30 ` Frank @ 2002-04-16 15:43 ` martin.m.dowie 2002-04-16 16:53 ` Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: martin.m.dowie @ 2002-04-16 15:43 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:a9eq3h$7e4$1@nh.pace.co.uk... > "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message > news:pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net... > > > > It is a shame that COBOL has Fujitsu to develop COBOL.NET but > > that Ada has no such large corporate to perform this sort of work. > > Without such a sponsor it is hard to see how Ada gets out of the > > catch22 of: > > User: "Why use Ada when it doesn't support feature X?" > > Vendor: "Why support feature X when there is no user demand?" > > > Maybe its worth looking for a big corporate sponsor? A corporation that is > looking to distinguish itself as something "different" from the rest of the > pack? The Ada vendors have the problem that they lack the resources to sink > into tools/targets "on spec" that something will emerge. But for a large > corporation that may have the need for such products (internally or > externally), the development cost might look like a spit in the bucket. > Maybe finding some "strategic partners" creates advantages for Ada as well > as advantages for the parties involved. > > Of course there are always those sticky cliche's about "riding on the back > of the tiger" or "getting into bed with an elephant" and such to serve as a > reality check. :-) Nice idea, but who? Boeing are an obvious candidate given their history of Ada use - but is that still true? And even it it was, it just reinforces the preconception that Ada is only any use in the avionics field (which I think we can all appriciate is not true). Reuters news agency I understand use it but not throughout. CANAL+ could be a better bet - are you out there Pascal? Anyone else any better ideas?.. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 15:43 ` martin.m.dowie @ 2002-04-16 16:53 ` Marin David Condic 2002-04-17 6:16 ` martin.m.dowie 2002-04-17 7:50 ` Ingo Marks 0 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-16 16:53 UTC (permalink / raw) "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:fFXu8.31411$tZ1.7228185@news2-win.server.ntlworld.com... > > Nice idea, but who? > Good question. Defer for a moment, but think along the lines of "Big Into Computers..." > Boeing are an obvious candidate given their history of Ada use - but is that > still true? And even it it was, it just reinforces the preconception that > Ada is > only any use in the avionics field (which I think we can all appriciate is > not > true). > From rumors I've heard Boeing is drifting away from Ada for a lot of the same reasons as other aerospace firms - the programmers want to work in something more marketable. Besides, Boeing is an airframer and not a computer company, so they have limited influence on what other computer companies would do. Unless maybe you just want to sell them on the idea of building a development environment for various systems and have them pay the freight of doing the development cost. But then they've got an ownership interest which they'd have to be stupid to ignore - and you're in bed with the elephant. > Reuters news agency I understand use it but not throughout. > Probably not big enough and certainly not in the "technology" business to want to finance some computer project. > CANAL+ could be a better bet - are you out there Pascal? > Maybe - but are they big enough and interested enough to finance some sort of Ada endeavor? > Anyone else any better ideas?.. > Some of this depends on what you think you want to do as far as "A Thing Financed By A Deep Pockets Contributor That Has A Side Effect Of Promoting Ada..." Say the objective is to build the world's spiffiest IDE for/with Ada. Ada's advantages are reliability and portability. Suppose you had someone like Compaq who thought it might be attractive to the market to provide OS-agnosticism: "Yeah, we'll give you a computer with Windows or Linux or Both!" (It would distinguish them from Sun, and other PC makers maybe?) But now they've got to encourage development that compliments their strategy. Suppose they could offer developers a kit that would let them use gcc-based compilers to target both OS's? We say: Sure! No sweat! We can build an IDE & some libraries and what have you that lets an app builder develop for one direction and recompile to go the other way. We can fix it so that any of the gcc based compilers could be your choice for development (language-agnostic) but we implemented in Ada, so it will just be more natural and easy to use Ada... Or suppose that IBM figures that its time to produce the next generation of personal computer and try to regain the market share it once had? We say: Sure! We can help! We'll go build you a new state-of-the-art OS programmed in Ada that will distinguish your product with higher reliability and security... Or much nearer and dearer to my heart: What about the Digital TV set-top box business? If we were proposing to build an OS/Development package that targeted this sort of device and offered higher reliability with faster time to market, etc. as a consequence of including Ada software, you've got access to a whole burgeoning market that is likely to attract lots of new developers. Where I'm going with this is somewhere along the lines of dreaming up a whole product that has Ada as a significant component and selling the idea to some big guy in that market. Get them thinking along the lines of incorporating Ada as a key piece of their product. You'd have to think of something that leaves them to some extent "language neutral" since they won't want to jump into Ada with both feet and not have alternatives. The strategy there is to dream something up that says "You can use any language you want - it will just be easier with Ada because that's where it all comes from..." (That's one of the reasons C got to be big, right?) Think about it...... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:53 ` Marin David Condic @ 2002-04-17 6:16 ` martin.m.dowie 2002-04-17 12:55 ` Marin David Condic 2002-04-17 7:50 ` Ingo Marks 1 sibling, 1 reply; 425+ messages in thread From: martin.m.dowie @ 2002-04-17 6:16 UTC (permalink / raw) > > CANAL+ could be a better bet - are you out there Pascal? > > > Maybe - but are they big enough and interested enough to finance some sort > of Ada endeavor? Big enough - I think so I think it is Universal Studios they own amongst others. They do (most of the?) set top boxes for terrestrial digital TV in Europe. Interest enough - probably not :-( ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 6:16 ` martin.m.dowie @ 2002-04-17 12:55 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-17 12:55 UTC (permalink / raw) "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:Ar8v8.41325$C21.7794767@news6-win.server.ntlworld.com... > > > CANAL+ could be a better bet - are you out there Pascal? > > > > > Maybe - but are they big enough and interested enough to finance some sort > > of Ada endeavor? > > Big enough - I think so I think it is Universal Studios they own amongst > others. > They do (most of the?) set top boxes for terrestrial digital TV in Europe. > > Interest enough - probably not :-( > Well since the Set-Top Box business doesn't (yet) have a dominant OS or resident application or a definitive set of third-party apps, it is still wide open for new technologies to emerge. Its not like the home PC market where basically its some version of Windows and Office apps that define the environment. Finding a way for Ada to play in that arena could be a big boost. I think to interest a company in some sort of funding of an Ada endeavor in this area is possible. It has to be dreampt up along the lines of creating some kind of competitive advantage for them and sold to them. Being in the set-top box business, I can see how hard it is driven by cost and time to market. Its really hard to get people in the company to focus on an R&D kind of thing when the rush is always on to hurry up and get the next thing out the door. But that doesn't mean that its totally impossible to get someone to listen to a good idea. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:53 ` Marin David Condic 2002-04-17 6:16 ` martin.m.dowie @ 2002-04-17 7:50 ` Ingo Marks 2002-04-17 12:01 ` Gary Scott ` (2 more replies) 1 sibling, 3 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-17 7:50 UTC (permalink / raw) Marin David Condic wrote: > From rumors I've heard Boeing is drifting away from Ada for a lot of the > same reasons as other aerospace firms - the programmers want to work in > something more marketable. What do they use instead of Ada? Regards, Ingo ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 7:50 ` Ingo Marks @ 2002-04-17 12:01 ` Gary Scott 2002-04-17 13:29 ` Robert Dewar 2002-04-17 13:29 ` Robert Dewar 2 siblings, 0 replies; 425+ messages in thread From: Gary Scott @ 2002-04-17 12:01 UTC (permalink / raw) Ingo Marks wrote: > > Marin David Condic wrote: > > > From rumors I've heard Boeing is drifting away from Ada for a lot of the > > same reasons as other aerospace firms - the programmers want to work in > > something more marketable. > > What do they use instead of Ada? C++, just like Lockheed Martin. > > Regards, > Ingo -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 7:50 ` Ingo Marks 2002-04-17 12:01 ` Gary Scott @ 2002-04-17 13:29 ` Robert Dewar 2002-04-17 18:40 ` Ted Dennison 2002-04-17 13:29 ` Robert Dewar 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-17 13:29 UTC (permalink / raw) > Marin David Condic wrote: > > > From rumors I've heard Boeing is drifting away from Ada for a lot of the > > same reasons as other aerospace firms - the programmers want to work in > > something more marketable. A common but highly irresponsible behavior on the web and usenet is to post rumours when you really don't know any facts. So often, these rumours quickly get taken as fact, and it is often the case that they have no grounding in fact at all. In fact the situation at Boeing is that some programs are using Ada and some are not. Some new developments are using Ada, some are not. I doubt anyone has meaningful overall figures that would support a conclusion of whether overall use is increasing at Boeing or not. Most certainly from ACT's point of view, we see an increase in use of Ada at Boeing, but that's only one point of view :-) The use of Ada is of course subject to competition. We will lose some and win some. When you lose, you try to learn, but it is singularly unhelpful to draw broad conclusions. I can certainly say that ACT is a company that is essentially 100% devoted to Ada based products, and we see our business expanding steadily. I can't speak for other Ada companies, but I can certainly be confident that neither Ada nor ACT are about to disappear in the forseeable future. I suggest people spend less time in uninformed discussions on the future of Ada use, and more time in contributing to the technical base :-) Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 13:29 ` Robert Dewar @ 2002-04-17 18:40 ` Ted Dennison 2002-04-18 15:02 ` Ted Dennison 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-17 18:40 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0204170529.beaf045@posting.google.com>... > I suggest people spend less time in uninformed discussions on the future of > Ada use, and more time in contributing to the technical base :-) Damn straight. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 18:40 ` Ted Dennison @ 2002-04-18 15:02 ` Ted Dennison 2002-04-18 15:28 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-18 15:02 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204171040.33abd3c3@posting.google.com>... > dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0204170529.beaf045@posting.google.com>... > > I suggest people spend less time in uninformed discussions on the future of > > Ada use, and more time in contributing to the technical base :-) > > Damn straight. (misc.misc trimmed) I felt I should do more than just a "me too" on this. I've been hanging out in c.l.a. for about 8 years now, and I got sick of the "Ada is dying" doom-and-gloom talk after about the 3rd Greg Ahnorian post I read. After 8 years of supposedly declining usage, there would be no one using it today but 3 kids and a monkey if those folks were all right. Instead it seems the Ada community is more healthy than ever before. No one is still being "forced" to use it and there's no DoD sugar-daddy around bankrolling projects any more, yet there are all sorts of wonderful new projects and initiatives comming out on what seems like a daily basis, from both companies and volunteers. Every language has its detractors that love to believe, no matter what the truth of the matter is, that it is just about to shrivel up and die. For whatever reason, Ada has always had more than its share of such people. I think that Ada's doom has been mindlessly predicted so much for so long that lots of otherwise sensible people have started to believe it. Its high time we quit listening. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 15:02 ` Ted Dennison @ 2002-04-18 15:28 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 15:28 UTC (permalink / raw) The "Is it dying or is it growning" debate can't really ever be settled anyway since there's no hard data on which most people would agree that would indicate anything meaningful about the direction. (I'd suggest that if it *really* grew in a large, substantial way, it would be so obvious nobody would ask the question.) So basically, anybody expressing an opinion on the subject either way is equally uninformed - there is no data so all you've got is opinions based on perceptions. I don't think its a waste of time though to discuss what would possibly make Ada more popular with the masses. That's the kind of "market research" that helps a product satisfy the needs of more people. For example, the discussion here about libraries seems to be identifying some common collections of desired utilities, from which maybe something emerges. The discussion about having some kind of standard GUI/tools seems to be clarifying a need and possibly seeing consensus getting built on which of several possibilities ought to be contenders. Any discussion of what people want out of a language can be helpful in setting future directions. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0204180702.3f703c23@posting.google.com... > dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204171040.33abd3c3@posting.google.com>... > > I felt I should do more than just a "me too" on this. I've been > hanging out in c.l.a. for about 8 years now, and I got sick of the > "Ada is dying" doom-and-gloom talk after about the 3rd Greg Ahnorian > post I read. After 8 years of supposedly declining usage, there would > be no one using it today but 3 kids and a monkey if those folks were > all right. Instead it seems the Ada community is more healthy than > ever before. No one is still being "forced" to use it and there's no > DoD sugar-daddy around bankrolling projects any more, yet there are > all sorts of wonderful new projects and initiatives comming out on > what seems like a daily basis, from both companies and volunteers. > > Every language has its detractors that love to believe, no matter what > the truth of the matter is, that it is just about to shrivel up and > die. For whatever reason, Ada has always had more than its share of > such people. I think that Ada's doom has been mindlessly predicted so > much for so long that lots of otherwise sensible people have started > to believe it. Its high time we quit listening. > > -- > T.E.D. > Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) > Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 7:50 ` Ingo Marks 2002-04-17 12:01 ` Gary Scott 2002-04-17 13:29 ` Robert Dewar @ 2002-04-17 13:29 ` Robert Dewar 2002-04-17 19:31 ` Chad R. Meiners 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-17 13:29 UTC (permalink / raw) > Marin David Condic wrote: > > > From rumors I've heard Boeing is drifting away from Ada for a lot of the > > same reasons as other aerospace firms - the programmers want to work in > > something more marketable. A common but highly irresponsible behavior on the web and usenet is to post rumours when you really don't know any facts. So often, these rumours quickly get taken as fact, and it is often the case that they have no grounding in fact at all. In fact the situation at Boeing is that some programs are using Ada and some are not. Some new developments are using Ada, some are not. I doubt anyone has meaningful overall figures that would support a conclusion of whether overall use is increasing at Boeing or not. Most certainly from ACT's point of view, we see an increase in use of Ada at Boeing, but that's only one point of view :-) The use of Ada is of course subject to competition. We will lose some and win some. When you lose, you try to learn, but it is singularly unhelpful to draw broad conclusions. I can certainly say that ACT is a company that is essentially 100% devoted to Ada based products, and we see our business expanding steadily. I can't speak for other Ada companies, but I can certainly be confident that neither Ada nor ACT are about to disappear in the forseeable future. I suggest people spend less time in uninformed discussions on the future of Ada use, and more time in contributing to the technical base :-) Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 13:29 ` Robert Dewar @ 2002-04-17 19:31 ` Chad R. Meiners 0 siblings, 0 replies; 425+ messages in thread From: Chad R. Meiners @ 2002-04-17 19:31 UTC (permalink / raw) Here are some interesting facts. Boeing out of St. Louis actively recruits Truman State University's students. Two of the reasons that they give to students on why they recruit at Truman are 1) Truman graduates are well educated and 2) Truman teaches Ada as a first language. If there are companies that worry about the supply of Ada programmers, you can also point them to Truman as a small but steady source of quality computer scientists that know (and in most cases appreciate) Ada. -CRM Truman Alumni ;) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204170529.6338a5f9@posting.google.com... > > Marin David Condic wrote: > > > > > From rumors I've heard Boeing is drifting away from Ada for a lot of the > > > same reasons as other aerospace firms - the programmers want to work in > > > something more marketable. > > A common but highly irresponsible behavior on the web and usenet is to > post rumours when you really don't know any facts. So often, these rumours > quickly get taken as fact, and it is often the case that they have no > grounding in fact at all. > > In fact the situation at Boeing is that some programs are using Ada and > some are not. Some new developments are using Ada, some are not. I doubt > anyone has meaningful overall figures that would support a conclusion > of whether overall use is increasing at Boeing or not. Most certainly from > ACT's point of view, we see an increase in use of Ada at Boeing, but that's > only one point of view :-) > > The use of Ada is of course subject to competition. We will lose some and > win some. When you lose, you try to learn, but it is singularly unhelpful > to draw broad conclusions. > > I can certainly say that ACT is a company that is essentially 100% devoted > to Ada based products, and we see our business expanding steadily. I can't > speak for other Ada companies, but I can certainly be confident that neither > Ada nor ACT are about to disappear in the forseeable future. > > I suggest people spend less time in uninformed discussions on the future of > Ada use, and more time in contributing to the technical base :-) > > Robert Dewar > Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 16:03 ` martin.m.dowie 2002-04-15 15:03 ` Marin David Condic @ 2002-04-18 14:15 ` Ted Dennison 2002-04-18 18:35 ` Paranoia about .NET (still): " Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-18 14:15 UTC (permalink / raw) "martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message news:<pHYt8.15029$sL6.2187840@news11-gui.server.ntli.net>... > I totally respect your decisions on what to target new development > on - it is your business. I'm just sorry I can't bring the bucks to the > table to make it worth while for you (or anyone else) to do this :-( > > It is a shame that COBOL has Fujitsu to develop COBOL.NET but > that Ada has no such large corporate to perform this sort of work. My understanding is that Microsoft is at least partially bankrolling a lot of those compiler ports. So the real issue is why Microsoft didn't think Ada worth worrying about, not why ACT doesn't find .NET worth worrying about. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-18 14:15 ` Ted Dennison @ 2002-04-18 18:35 ` Kent Paul Dolan 2002-04-18 21:43 ` Ted Dennison ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 18:35 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote: > My understanding is that Microsoft is at least partially bankrolling a > lot of those compiler ports. So the real issue is why Microsoft didn't > think Ada worth worrying about, not why ACT doesn't find .NET worth > worrying about. That, at least, is a no-brainer. What made Microsoft attack Java so strongly that it took a lawsuit to slap them down? Java is by design OS independent, contributing to breaking the stranglehold of MS-Windows on the market of "things needed to run applications". Microsoft as a corporate entity and an untrammeled monopoly feels very _threatened_ by the very _concept_ of OS independent programming languages; that's why there's a big compiler creating effort inside Microsoft. OS independent programming language _by design_. Can you think of some other language that meets that description, and so would meet with that reaction at Microsoft? xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-18 18:35 ` Paranoia about .NET (still): " Kent Paul Dolan @ 2002-04-18 21:43 ` Ted Dennison 2002-04-19 11:49 ` Robert Dewar 2002-04-19 23:14 ` rc211v 2 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 21:43 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<357f0f4aab2ac8ef39234c96f0ab6311.48257@mygate.mailgate.org>... > the market of "things needed to run applications". Microsoft as a > corporate entity and an untrammeled monopoly feels very _threatened_ by > the very _concept_ of OS independent programming languages; that's why > there's a big compiler creating effort inside Microsoft. ...unless they own that language-independant platform too. :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-18 18:35 ` Paranoia about .NET (still): " Kent Paul Dolan 2002-04-18 21:43 ` Ted Dennison @ 2002-04-19 11:49 ` Robert Dewar 2002-04-19 23:34 ` Kent Paul Dolan 2002-04-19 23:14 ` rc211v 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-19 11:49 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<357f0f4aab2ac8ef39234c96f0ab6311.48257@mygate.mailgate.org>... > "Ted Dennison" <dennison@telepath.com> wrote: > > > My understanding is that Microsoft is at least partially bankrolling a > > lot of those compiler ports. So the real issue is why Microsoft didn't > > think Ada worth worrying about, not why ACT doesn't find .NET worth > > worrying about. > > That, at least, is a no-brainer. What made Microsoft attack Java so > strongly that it took a lawsuit to slap them down? Java is by design OS > independent, contributing to breaking the stranglehold of MS-Windows on > the market of "things needed to run applications". Microsoft as a > corporate entity and an untrammeled monopoly feels very _threatened_ by > the very _concept_ of OS independent programming languages; that's why > there's a big compiler creating effort inside Microsoft. > > OS independent programming language _by design_. Can you think of some > other language that meets that description, and so would meet with that > reaction at Microsoft? > > xanthian. Well no doubt it satisfies some need to imagine that Microsoft is plotting and scheming against Ada, but I am afraid it is absurd. The reason that Microsoft is not paying attention to Ada is that they don't hear from any serious potential customer base requesting this capability. The reason that ACT is not paying attention to .NET is that they don't hear from any serious potential customer base requestion this capability. ACT tunes its activities to what people want. This is not simply a matter of corporate good sense (you can't succeed selling people what they don't want), but also of contributing most effectively to the Ada community -- much better to spend our limited resources on things that people want and need! Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-19 11:49 ` Robert Dewar @ 2002-04-19 23:34 ` Kent Paul Dolan 0 siblings, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-19 23:34 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote: > Well no doubt it satisfies some need to imagine that Microsoft is > plotting and scheming against Ada, but I am afraid it is absurd. I don't think that should be read as the intent of my remarks. Microsoft _is_ plotting and scheming against (at least some) anything(s) that make(s) application programming OS independent (and the court transcripts and judgements exist to prove that) and thereby free people to make an OS choice based on quality instead of market share. Whether Microsoft even knows Ada exists is sort of equally irrelevant as whether the steamroller operator knows the earthworm on the pavement ahead of him exists. If the goal is to flatten all obstacles to worldwide domination of a single dappy operating system, the incidental kills will probably be numerous, just as when the shrimp seine kills tenfold as many pounds of fish as it catches pounds of shrimp, and the dead fish are simply thrown back overboard. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-18 18:35 ` Paranoia about .NET (still): " Kent Paul Dolan 2002-04-18 21:43 ` Ted Dennison 2002-04-19 11:49 ` Robert Dewar @ 2002-04-19 23:14 ` rc211v 2002-04-20 3:00 ` Larry Kilgallen ` (3 more replies) 2 siblings, 4 replies; 425+ messages in thread From: rc211v @ 2002-04-19 23:14 UTC (permalink / raw) On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan" <xanthian@well.com> wrote: >Java is by design OS >independent, contributing to breaking the stranglehold of MS-Windows on >the market of "things needed to run applications". Java is _by_design_ a marketing product in search of a real problem to solve. I've recently discovered a very nice portable graphics library, FOX. The goal of it's designer is: "Write Once, Compile Anywhere" ... For those who want to take a look go to http://fox-toolkit.org . Just download the calculator demo. You will be impressed. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Paranoia about .NET (still): Rant! (was) Development process in the Ada community 2002-04-19 23:14 ` rc211v @ 2002-04-20 3:00 ` Larry Kilgallen 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG ` (2 subsequent siblings) 3 siblings, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-20 3:00 UTC (permalink / raw) In article <i661cuklbc689igifq22srkt101847die8@4ax.com>, rc211v <rc211v@attglobal.net> writes: > On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan" > <xanthian@well.com> wrote: > > >>Java is by design OS >>independent, contributing to breaking the stranglehold of MS-Windows on >>the market of "things needed to run applications". > > Java is _by_design_ a marketing product in search of a real problem to > solve. Java is _by_design_ a programming language intended to be safer than C. Two years ago Sun's Chief Technology Officer spoke at the RSA Conference and pointed out that the bytecode engine and web stuff was not the original reason Sun was interested in Java. The write-once, debug-everywhere approach stems only from that latter use of Java, having not much to do with native compiled Java. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Wish List : Ada95 to FOX 2002-04-19 23:14 ` rc211v 2002-04-20 3:00 ` Larry Kilgallen @ 2002-04-23 17:27 ` Warren W. Gay VE3WWG 2002-04-23 19:24 ` Stephen Leake ` (2 more replies) 2002-04-24 0:00 ` Jeffrey Carter [not found] ` <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com> 3 siblings, 3 replies; 425+ messages in thread From: Warren W. Gay VE3WWG @ 2002-04-23 17:27 UTC (permalink / raw) rc211v wrote: > On Thu, 18 Apr 2002 18:35:28 +0000 (UTC), "Kent Paul Dolan" > <xanthian@well.com> wrote: >>Java is by design OS >>independent, contributing to breaking the stranglehold of MS-Windows on >>the market of "things needed to run applications". > > Java is _by_design_ a marketing product in search of a real problem to > solve. > > I've recently discovered a very nice portable graphics library, FOX. > > The goal of it's designer is: "Write Once, Compile Anywhere" ... > > For those who want to take a look go to http://fox-toolkit.org . Just > download the calculator demo. You will be impressed. I like the fact that FOX does not use the precompiler MOC approach that Qt did. It would be reeeeaaal nice (hint) to have an Ada95 binding to this. I havn't looked at it in detail, so I don't know how practical this is (written in C++). One area that has traditionally been a sore point in Ada and GUIs is the client_data parameter in callbacks. Gtk kind of hacks around this, but I'd like to see a more perfect (Ada95) solution to this problem. I like the idea of requiring a base tagged type as the client data parameter (classwide?), which defaults to an dummy instance base type when none is provided. To actually provide user data, the user would derive from the base type, and pass that instead when establishing the callback. Within the callback, the user would re-cast the base_type to the type that the callback was actually expecting to get. This way, if the tagged type provided was not correct for the "cast", an exception would occur and type safety is maintained. I think FOX might permit this type of a binding to be accomplished. I also like the fact that FOX is designed to permit dynamic messaging between widgets. Qt and MFC for example, are fixed at compile time by MOC/macros AFAI know. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Wish List : Ada95 to FOX 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG @ 2002-04-23 19:24 ` Stephen Leake 2002-04-23 19:30 ` Randy Brukardt 2002-04-26 22:06 ` rc211v 2 siblings, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-23 19:24 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes: > One area that has traditionally been a sore point in Ada and GUIs is > the client_data parameter in callbacks. Gtk kind of hacks around this, > but I'd like to see a more perfect (Ada95) solution to this problem. Do you like the Windex solution to this? I use generics. Best example is in the Menus package. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Wish List : Ada95 to FOX 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG 2002-04-23 19:24 ` Stephen Leake @ 2002-04-23 19:30 ` Randy Brukardt 2002-04-26 22:06 ` rc211v 2 siblings, 0 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-23 19:30 UTC (permalink / raw) Warren W. Gay VE3WWG wrote in message <3CC5997E.4040904@home.com>... Warren Gay wrote: >I like the idea of requiring a base tagged type as the client data >parameter (classwide?), which defaults to an dummy instance base >type when none is provided. To actually provide user data, the >user would derive from the base type, and pass that instead >when establishing the callback. ... It's a good idea. So good, in fact, that we use it in Claw to handle the random globs of data that Windows sends along with notifications. Since early 1997... (Rule of thumb #1: someone else has already had any good idea that you have. :-) Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Wish List : Ada95 to FOX 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG 2002-04-23 19:24 ` Stephen Leake 2002-04-23 19:30 ` Randy Brukardt @ 2002-04-26 22:06 ` rc211v 2 siblings, 0 replies; 425+ messages in thread From: rc211v @ 2002-04-26 22:06 UTC (permalink / raw) On Tue, 23 Apr 2002 17:27:27 GMT, "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote: >that Qt did. It would be reeeeaaal nice (hint) to have an Ada95 >binding to this. I havn't looked at it in detail, so I don't know >how practical this is (written in C++). > >I think FOX might permit this type of a binding to be accomplished. > >I also like the fact that FOX is designed to permit dynamic >messaging between widgets. Qt and MFC for example, are fixed at >compile time by MOC/macros AFAI know. I'm glad that you looked at it. I'm not a real programmer nor an expert in the gui domain but i downloaded the library and some examples in source code form. Under MSVC++, everything compiled without a single problem in less than five minutes on my laptop (a thinkpad 600x running XP). The calculator demo is compiled in a few seconds. When you start the demo, it loads instantly, faster than a native Windows application! From what i've seen, the approach promoted by it's designer (Write Once, Compile Anywhere) seems valid and very efficient in terms of speed and hardware ressources. As a regular reader of this ng i posted this after someone talked about the strength of ADA in terms of portability. A binding with this library would just enhance this portability in the Gui area. Cordially ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Wish List : Ada95 to FOX 2002-04-19 23:14 ` rc211v 2002-04-20 3:00 ` Larry Kilgallen 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG @ 2002-04-24 0:00 ` Jeffrey Carter [not found] ` <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com> 3 siblings, 0 replies; 425+ messages in thread From: Jeffrey Carter @ 2002-04-24 0:00 UTC (permalink / raw) "Warren W. Gay VE3WWG" wrote: > > One area that has traditionally been a sore point in Ada and GUIs is > the client_data parameter in callbacks. Gtk kind of hacks around this, > but I'd like to see a more perfect (Ada95) solution to this problem. I consider callbacks themselves a sore point. Callbacks are a hack to handle the inherent concurrency of a windowing system in a sequential language such as C. The natural approach is to associate a concurrent blocking queue of events with each window; the application has a task per window obtaining events from this queue and deciding what to do with them. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com>]
* Re: Wish List : Ada95 to FOX [not found] ` <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com> @ 2002-04-24 8:47 ` Jean-Pierre Rosen 2002-04-24 15:15 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Jean-Pierre Rosen @ 2002-04-24 8:47 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1063 bytes --] "Jeffrey Carter" <jeffrey.carter@boeing.com> a �crit dans le message news: 3CC5F5B0.DBC6A6B8@boeing.com... > "Warren W. Gay VE3WWG" wrote: > > > > One area that has traditionally been a sore point in Ada and GUIs is > > the client_data parameter in callbacks. Gtk kind of hacks around this, > > but I'd like to see a more perfect (Ada95) solution to this problem. > > I consider callbacks themselves a sore point. Callbacks are a hack to > handle the inherent concurrency of a windowing system in a sequential > language such as C. The natural approach is to associate a concurrent > blocking queue of events with each window; the application has a task > per window obtaining events from this queue and deciding what to do with > them. > <PLUG> The issue of call-backs (and more generally of the listener paradigm) will be addressed in a paper that I present at the Ada-Europe/Vienna conference. </PLUG> -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Wish List : Ada95 to FOX [not found] ` <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com> 2002-04-24 8:47 ` Jean-Pierre Rosen @ 2002-04-24 15:15 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-24 15:15 UTC (permalink / raw) I consider callbacks a butt-ugly solution to anything. :-) I'd much rather see some kind of messaging or events or whatever rather than have subprograms lying around with no obvious clue as to what it is that is calling them or when. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message news:3CC5F5B0.DBC6A6B8@boeing.com... > > I consider callbacks themselves a sore point. Callbacks are a hack to > handle the inherent concurrency of a windowing system in a sequential > language such as C. The natural approach is to associate a concurrent > blocking queue of events with each window; the application has a task > per window obtaining events from this queue and deciding what to do with > them. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 14:20 ` Robert Dewar 2002-04-13 16:03 ` martin.m.dowie @ 2002-04-16 1:41 ` Richard Riehle 2002-04-16 19:40 ` [OT] MS vs Linux vs who in the student heart? (still mostly): " Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Richard Riehle @ 2002-04-16 1:41 UTC (permalink / raw) Robert Dewar wrote: > Hint: anything to do with Microsoft does NOT appeal to students these > days, who routinely refer to Microsoft as the "dark side", a > phenomenon that I think MS should be > paying far more attention too :-) I can confirm this. More and more of my students puchase laptops and immediately install Linux. They refuse to use the computers in the official lab because they all run Microsoft products. Microsoft, for these students, is characterized by is monopolistic path into the blue screen of death. Linux, right or wrong, represents freedom from unjust restraint. Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* [OT] MS vs Linux vs who in the student heart? (still mostly): Rant! (was) Development process in the Ada community 2002-04-16 1:41 ` Rant! (was) Development process in the Ada community Richard Riehle @ 2002-04-16 19:40 ` Kent Paul Dolan 2002-04-17 2:09 ` Adrian Hoe 0 siblings, 1 reply; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-16 19:40 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote: > Robert Dewar wrote: > > Hint: anything to do with Microsoft does NOT appeal to students these > > days, who routinely refer to Microsoft as the "dark side", a > > phenomenon that I think MS should be > > paying far more attention too :-) Yep, it's still a fact, in our virtual universe, that reputation is the only solid asset, and Microsoft seems to have spent theirs dry. > I can confirm this. More and more of my students puchase > laptops and immediately install Linux. They refuse to use > the computers in the official lab because they all run Microsoft > products. What pleasant news! By the time I am 80, this generation will be in charge of technology buying, and Microsoft products won't even be considered. Life is going to be much, much better. I wonder who the bad guys will be by then? > Microsoft, for these students, is characterized by is monopolistic > path into the blue screen of death. It's probably too late for Microsoft already, but about a dozen *free* OS upgrade releases with no new features, just bug-fixes, with all their software talent focused on wringing out bugs, would go a long way toward salvaging their ruined reputation. My experience ends with NT, but at least up to there, application programs can still crash the OS, not an acceptable situation, and part of the reason the 24x7 online community is so disgusted with NT. > Linux, right or wrong, > represents freedom from unjust restraint. We'll see; another evil empire of old bought into the Linux world big-time, and has, from my personal experience as an insider, still not learned from past rejection of monopolistic tactics any new ethics of corporate culture to prevent its trying to steamroll its way to success in the face of absolute resistance from the customer / user community to such tactics. I'm fearful Linux is going to end up wholly captive and ground under the same boot-heels. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: [OT] MS vs Linux vs who in the student heart? (still mostly): Rant! (was) Development process in the Ada community 2002-04-16 19:40 ` [OT] MS vs Linux vs who in the student heart? (still mostly): " Kent Paul Dolan @ 2002-04-17 2:09 ` Adrian Hoe 0 siblings, 0 replies; 425+ messages in thread From: Adrian Hoe @ 2002-04-17 2:09 UTC (permalink / raw) Kent Paul Dolan wrote: > > "Richard Riehle" <richard@adaworks.com> wrote: > > > Robert Dewar wrote: > > > > Hint: anything to do with Microsoft does NOT appeal to students these > > > days, who routinely refer to Microsoft as the "dark side", a > > > phenomenon that I think MS should be > > > paying far more attention too :-) > > Yep, it's still a fact, in our virtual universe, that reputation is the > only solid asset, and Microsoft seems to have spent theirs dry. > > > I can confirm this. More and more of my students puchase > > laptops and immediately install Linux. They refuse to use > > the computers in the official lab because they all run Microsoft > > products. > > What pleasant news! By the time I am 80, this generation will be in > charge of technology buying, and Microsoft products won't even be > considered. Life is going to be much, much better. I wonder who the > bad guys will be by then? > > > Microsoft, for these students, is characterized by is monopolistic > > path into the blue screen of death. > > It's probably too late for Microsoft already, but about a dozen *free* > OS upgrade releases with no new features, just bug-fixes, with all their > software talent focused on wringing out bugs, would go a long way toward > salvaging their ruined reputation. My experience ends with NT, but at > least up to there, application programs can still crash the OS, not an > acceptable situation, and part of the reason the 24x7 online community > is so disgusted with NT. > > > Linux, right or wrong, > > represents freedom from unjust restraint. > > We'll see; another evil empire of old bought into the Linux world > big-time, and has, from my personal experience as an insider, still not > learned from past rejection of monopolistic tactics any new ethics of > corporate culture to prevent its trying to steamroll its way to success > in the face of absolute resistance from the customer / user community to > such tactics. I'm fearful Linux is going to end up wholly captive and > ground under the same boot-heels. > > xanthian. > > -- > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG I broke Windows and breathed free air many years back. But I think the glass is still around at least it will stay for some time in Asia regions. The trend is very obvious. Hardware giant like Dell, Compaq and HP are reluctant to bundle Linux with their machines for Asian markets. Why? The people here have been stupefied by advertisement and TV tech programs. That's why the Windows still refrain the market in this region. Nevertheless, Linux is getting popular here, at least slowly. It is the same to Ada in this region. Only a few "rebels" who seek different direction make the shift. -- Remove *nospam* to email. -- Adrian Hoe -- http://adrianhoe.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan 2002-04-11 23:20 ` tony 2002-04-12 10:10 ` Ingo Marks @ 2002-04-12 21:17 ` Wes Groleau 2002-04-13 0:23 ` Michael Erdmann 2002-04-13 0:59 ` Robert Dewar 4 siblings, 0 replies; 425+ messages in thread From: Wes Groleau @ 2002-04-12 21:17 UTC (permalink / raw) > Where are the parallel processing features _in the language_, the robust > and powerful string parsing features _in the language_, the "programming > by contract" features _in the language_, the standard higher level math > libraries _in the language_, knowledge representation _in the langauge_, > the SEI CMM model turned directly into a _standard_IDE _in the > language_, the standard DoD and telecom community communication > protocols, all _in the language_? Many of your complaints have some merit. This one however, can be applied to any language today. How many languages have TWO of these features? Ada at least has one and it would have two if concurrency were added to the list. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan ` (2 preceding siblings ...) 2002-04-12 21:17 ` Wes Groleau @ 2002-04-13 0:23 ` Michael Erdmann 2002-04-13 22:07 ` Kent Paul Dolan 2002-04-13 0:59 ` Robert Dewar 4 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-13 0:23 UTC (permalink / raw) Kent Paul Dolan wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > > >>i am wondering how standards are eveloving in the Ada community. >>In the Java Community there is a process called Java Community >>Process (JCP, http://www.jcp.org/) >> > >>Is there something comparable in the Ada communitiy? I guess >>if there would be something like this there would be more >>dynamic in the Ada 95 community. >> > > You have put your finger, probably, on the cause of the US Military's > collapse on the issue of an Ada Mandate in the face of programmer > intransigence to use Ada among the military community, in the answers > you have received. > > The love of doing things one rigid way, with all decisions handed down > from above, ran square into the software development community, which is > used to speedy and flexible growth in its tools. This has nothing to do with the DoD. From my experiences this is a consequence of larege orgnaisations, because it is not possible in such organisations, that everybody is communicating with everybody else to reach a common understanding. > > Probably Ada was doomed to be the Horse Cavelry of programming languages > the day its language standardization process was chosen, and I'm afraid > you are going to find no cure for what is basically an incurable > attitude problem of an entire, isolated programming community. > > Like Steven Jay Gould's "allopatric demes", Ada, brought back to cross > fertilize with other programming languages and their newly invented > mechanisms, might have provided hybrid vigor and a new, more competitive > product. > > Instead you see what you see: > > "Why should we want a superior graphics interface to replace an inferior > one, while maintaining the old one so as not to break old code?" > > "Why should the new developments become _part of the language_?" > > "Who needs a standard OS calling interface _in the language_?" > > "We don't need no stinking programming community inputs to the > language!" > > "Procedure for change? We want stability, stability, stability!" > > [The Kaiser's army had stability; programming as a task by definition > does not.] > I agree on this partially, i read this during the whole thread very often. > ad infinitum. > > ..........................complex bogosities get ditched: > _decimal_ specification of sizes for _binary_ data containers!!! > > Give me a break. > > "Progress, keeping up with community standards, is for other people!" I dont like the attitude you are showing here. I have worked on standarisation of telecomminucation protocols and i can assure you that progress is possible with a defined development process, It depends largely on the good will of the audience but it works! > > Give me a break. > > Sigh. So much promise, so small a result. Given a complete community > feedback loop and about a hundred times faster language change response > time, Ada could be everyone's programming language of choice today. > > Java, alive for about 7 years, is due imminently for its fifth major > release. That still doesn't guarantee its survival; Sun has an > incurable attitude problem toward making Java truly freeware, but it > does help. Ada doesn't even have a sponsor any more outside the > compiler vendor community, and I don't even see any visible signs of > public debate and motion toward a second much needed major overhaul and > upgrade for twenty year old Ada, just a few well hidden notes on some > standards committee web sites. > > That comp.lang.ada isn't comp.lang.ada.* is a symptom of the whole > mindset problem. Unitary Usenet discussion groups are very > characteristic of exactly one thing: _minor_ programming languages. > > xanthian. > > At least when I yelled at the Fortran standards folks back in 1987 or > so, they responded, and arguably saved their language from the dust-bin > as a result. Here, the outlook is not so rosy. > > Any how i cant seeing your point what should be done with Ada? Thrown away because the DoD has has initiated it??!!!! Regards M.Erdmann > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 0:23 ` Michael Erdmann @ 2002-04-13 22:07 ` Kent Paul Dolan 2002-04-14 8:01 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-13 22:07 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > Kent Paul Dolan wrote: > > The love of doing things one rigid way, with all decisions handed down > > from above, ran square into the software development community, which is > > used to speedy and flexible growth in its tools. > This has nothing to do with the DoD. To the contrary, rigid, top down command structure with limited upwards feedback is quintessentially a military organization model. No business could long survive with a similarly rigid hierarchy. > > "Progress, keeping up with community standards, is for other people!" > I dont like the attitude you are showing here. I have worked > on standarisation of telecomminucation protocols and i can assure > you that progress is possible with a defined development process, > It depends largely on the good will of the audience but it works! How well I know; there are three ANSI X3H3 standards (GKS, CGM, VDI) containing my 4.5 years of contributions. I know what is possible, I don't see the Ada community following ANSI's most important guideline: standards shall incorporate current best practice. This isn't a standards process problem, this is explicitly an Ada community problem. > > At least when I yelled at the Fortran standards folks back in 1987 or > > so, they responded, and arguably saved their language from the dust-bin > > as a result. Here, the outlook is not so rosy. > Any how i cant seeing your point what should be done with Ada? It should follow the Fortran standards choice (for Fortran 90) of continuing to incorporate programming community best practice, rather than crawling off in a corner and becoming a programming language no new graduate wants to touch because none of the new stuff to make programming easier learned in school exists in the language. > Thrown away because the DoD has has initiated it??!!!! No, I sign my name "LCDR, Retired" when I care to bother; I don't have any particular bone to pick with the military. DoD has abandoned Ada, that is the problem. The head has been cut off, the body continues to twitch. Ada needs a new mandate, some sense of direction so it doesn't just continue to march in place, and I don't see it happening. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 22:07 ` Kent Paul Dolan @ 2002-04-14 8:01 ` Michael Erdmann 2002-04-14 10:24 ` Ingo Marks ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 8:01 UTC (permalink / raw) Kent Paul Dolan wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > >>Kent Paul Dolan wrote: >> > >>>The love of doing things one rigid way, with all decisions handed down >>>from above, ran square into the software development community, which is >>>used to speedy and flexible growth in its tools. >>> > >>This has nothing to do with the DoD. >> > > To the contrary, rigid, top down command structure with limited upwards > feedback is quintessentially a military organization model. No business > could long survive with a similarly rigid hierarchy. > I am not so mutch experienced with the DoD, but to me it sounds like what you can often encounter in large companies and they are still dominating the market without alwys beeing always the technical leader in there domain. >>>"Progress, keeping up with community standards, is for other people!" >>> > >>I dont like the attitude you are showing here. I have worked >>on standarisation of telecomminucation protocols and i can assure >>you that progress is possible with a defined development process, >>It depends largely on the good will of the audience but it works! >> > > How well I know; there are three ANSI X3H3 standards (GKS, CGM, VDI) > containing my 4.5 years of contributions. I know what is possible, I > don't see the Ada community following ANSI's most important guideline: > standards shall incorporate current best practice. This isn't a > standards process problem, this is explicitly an Ada community problem. > > >>>At least when I yelled at the Fortran standards folks back in 1987 or >>>so, they responded, and arguably saved their language from the dust-bin >>>as a result. Here, the outlook is not so rosy. >>> > >>Any how i cant seeing your point what should be done with Ada? >> > > It should follow the Fortran standards choice (for Fortran 90) of > continuing to incorporate programming community best practice, rather > than crawling off in a corner and becoming a programming language no new > graduate wants to touch because none of the new stuff to make > programming easier learned in school exists in the language. This is where i completly agree, specially the predefined packages have to updated dramatically. The langauge is still better then most of the currently commonly used languages. >>Thrown away because the DoD has has initiated it??!!!! >> > > No, I sign my name "LCDR, Retired" when I care to bother; I don't have > any particular bone to pick with the military. DoD has abandoned Ada, > that is the problem. The head has been cut off, the body continues to > twitch. Ada needs a new mandate, some sense of direction so it doesn't > just continue to march in place, and I don't see it happening. This is exaclty the impression i have my self. So i was wondering if Ada could take a new direction, when the open source communitiy is more directly involved by establishing a public process in order to enhance the predefined libraries, and may be later, to make an attempt to get these things into ISO etc.. I am realy wondering if good place to start would be the AIC? Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 8:01 ` Michael Erdmann @ 2002-04-14 10:24 ` Ingo Marks 2002-04-14 10:26 ` Ingo Marks ` (2 more replies) 2002-04-14 14:44 ` Gary Scott 2002-04-14 15:54 ` Larry Kilgallen 2 siblings, 3 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-14 10:24 UTC (permalink / raw) Michael Erdmann wrote: > Kent Paul Dolan wrote: >> >> No, I sign my name "LCDR, Retired" when I care to bother; I don't have >> any particular bone to pick with the military. DoD has abandoned Ada, >> that is the problem. The head has been cut off, the body continues to >> twitch. Ada needs a new mandate, some sense of direction so it doesn't >> just continue to march in place, and I don't see it happening. > > This is exaclty the impression i have my self. So i was wondering > if Ada could take a new direction, when the open source communitiy is > more directly involved by establishing a public process in order > to enhance the predefined libraries, and may be later, to make an > attempt to get these things into ISO etc.. Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have any more interest. A new standardization project needs a central place to start. CAD is a good starting point to discuss but the many messages are scattered all over the group and it becomes difficult for me to collect the essence of all ideas. You complained that the focus of this thread is already out of control. I would like to suggest to create a new website where you list all your intentions and considerations. People will read them and make comments there and/or here. People will make source code contributions and the whole thing will grow step by step. Do you want open source library standards for the current Ada 95 standard or do you want to have the language "polished up", too? Ada is impressive but my first impressions were that some (few) things are unnecessarily complicated which have a deterring effect to newbies. For example string handling. The distinction between fixed and unbounded strings confused me at first (and my compiler produced at lot of error messages ;-) Somewhere I read that the Ada 95 standard would support string handling with garbage collections already (but no compiler has implemented this yet). It would be fine if this could be done in an open source standardization project. Ingo ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 10:24 ` Ingo Marks @ 2002-04-14 10:26 ` Ingo Marks 2002-04-14 11:41 ` Michael Erdmann 2002-04-17 3:13 ` Richard Riehle 2 siblings, 0 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-14 10:26 UTC (permalink / raw) Ingo Marks wrote: > A new standardization project needs a central place to start. CAD is a sorry: I meant CLA (comp.lang.ada) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 10:24 ` Ingo Marks 2002-04-14 10:26 ` Ingo Marks @ 2002-04-14 11:41 ` Michael Erdmann 2002-04-14 12:48 ` Ingo Marks 2002-04-17 3:13 ` Richard Riehle 2 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 11:41 UTC (permalink / raw) Ingo Marks wrote: > Michael Erdmann wrote: > > >>Kent Paul Dolan wrote: >> >>>No, I sign my name "LCDR, Retired" when I care to bother; I don't have >>>any particular bone to pick with the military. DoD has abandoned Ada, >>>that is the problem. The head has been cut off, the body continues to >>>twitch. Ada needs a new mandate, some sense of direction so it doesn't >>>just continue to march in place, and I don't see it happening. >>> >>This is exaclty the impression i have my self. So i was wondering >>if Ada could take a new direction, when the open source communitiy is >>more directly involved by establishing a public process in order >>to enhance the predefined libraries, and may be later, to make an >>attempt to get these things into ISO etc.. >> > > Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have > any more interest. > > A new standardization project needs a central place to start. CAD is a good > starting point to discuss but the many messages are scattered all over the > group and it becomes difficult for me to collect the essence of all ideas. > You complained that the focus of this thread is already out of control. > > I would like to suggest to create a new website where you list all your > intentions and considerations. People will read them and make comments > there and/or here. People will make source code contributions and the whole > thing will grow step by step. May be www.adapower.com is a good place to start? > > Do you want open source library standards for the current Ada 95 standard > or do you want to have the language "polished up", too? Just the libraries. I would not dare to touch the language. > > Ada is impressive but my first impressions were that some (few) things are > unnecessarily complicated which have a deterring effect to newbies. For > example string handling. The distinction between fixed and unbounded > strings confused me at first (and my compiler produced at lot of error > messages ;-) Somewhere I read that the Ada 95 standard would support string > handling with garbage collections already (but no compiler has implemented > this yet). It would be fine if this could be done in an open source > standardization project. > Are there any examples for "..open source standardization projects..."? > Ingo > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 11:41 ` Michael Erdmann @ 2002-04-14 12:48 ` Ingo Marks 2002-04-14 13:42 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Ingo Marks @ 2002-04-14 12:48 UTC (permalink / raw) Michael Erdmann wrote: >> I would like to suggest to create a new website where you list all your >> intentions and considerations. People will read them and make comments >> there and/or here. People will make source code contributions and the >> whole thing will grow step by step. > > May be www.adapower.com is a good place to start? You should ask the maintainer (David Botton) not me. > Are there any examples for "..open source standardization projects..."? Your project. (Open source standardization project for Ada libraries ;-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 12:48 ` Ingo Marks @ 2002-04-14 13:42 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 13:42 UTC (permalink / raw) Ingo Marks wrote: > Michael Erdmann wrote: > > >>>I would like to suggest to create a new website where you list all your >>>intentions and considerations. People will read them and make comments >>>there and/or here. People will make source code contributions and the >>>whole thing will grow step by step. >>> >>May be www.adapower.com is a good place to start? >> > > You should ask the maintainer (David Botton) not me. I will do this. I think it would be a good idea to keep the people from http://www.ada-auth.org also in the loop. > >>Are there any examples for "..open source standardization projects..."? >> > > Your project. (Open source standardization project for Ada libraries ;-) > > Nice to know, but this is a chance! I guess there where a lot of attempts in the past, or at least what i have seen in comp.lang.ada. At least i will contact Mr. Button or at least setup a small page on my homepage regarding this issue! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 10:24 ` Ingo Marks 2002-04-14 10:26 ` Ingo Marks 2002-04-14 11:41 ` Michael Erdmann @ 2002-04-17 3:13 ` Richard Riehle 2002-04-17 13:19 ` Marin David Condic 2 siblings, 1 reply; 425+ messages in thread From: Richard Riehle @ 2002-04-17 3:13 UTC (permalink / raw) Ingo Marks wrote: > Who "owns" Ada? The DoD has decided to quit Ada so they don't seem to have > any more interest. OK, let's get this straight. The DoD has not decided to quit Ada. I still correspond with former Assistant Secretary of Defense Emmett Paige from time to time and I gather that one of his disappointments is the misinterpretation of his memo abrogating the Ada mandate. If I may take the liberty of defending his original intent, he expected Ada to be a language among others, still used, when appropriate for DoD software systems. His memo says a Software Engineering Review Process (SEPR) should be determining factor for choosing a programming language. Very few DoD contractors are paying attention to this order any more than they did the original Ada mandate. Ada is still being chosen for DoD software projects, even though it is not being chosen as often as it was before Secretary Paige's memo. Some developers, having evaluated C++ and discovered just how error-prone it is, have decided to stick with Ada. Others, unable to admit their monumental stupidity, have dug in and pushed ahead with C++. They will, of course, rue the day they decided to use C++ instead of Ada, but that will never become public knowledge. Already, many of them have decided to use Java instead of C++ instead of admitting they would have been better off with Ada. Those who have chosen to stick with Ada are doing well with it. As for the DoD deciding to abandon Ada. There are certainly program managers, employed by the Dod, who have misunderstood Secretary Paige's memo. There are program managers who have been hoodwinked into a misunderstanding by DoD software developers. However, there are still program managers who specify Ada as a first choice because they understand its merits. I have a little contact with some of these managers and have taken the time to educate those willing to listen regarding the advantages and disadvantages of competing choices among languages. Those who understand will continue to make the right choice. Those who don't will continue to be led into bad decisions by the media and the contractors. Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 3:13 ` Richard Riehle @ 2002-04-17 13:19 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-17 13:19 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3CBCE84E.811EA1C3@adaworks.com... > > OK, let's get this straight. The DoD has not decided to quit Ada. I still > correspond with former Assistant Secretary of Defense Emmett Paige > from time to time and I gather that one of his disappointments is the > misinterpretation of his memo abrogating the Ada mandate. If I may I think the problem was a huge misjudgement of how his memo would be interpreted. Maybe Secretary Paige didn't intend for the memo to be interpreted as the DoD abandoning Ada, but that sure was the net effect. Perhaps part of it was willfull misinterpretation on the part of some who hated Ada and The Mandate so they could use it as an excuse to rush off and do what they wanted to in the first place. Perhaps there was a kind of a logical inference on the part of others that this is what it meant: "You used to insist that Ada was the right answer and now you're saying 'go forth and select whatever makes sense' so I can reasonably guess that this amounts to 'Ada was a mistake'..." Sometimes perception *is* reality. Especially when we're dealing in a political & social realm. Once The Mandate was instituted, any attempt to back off from it was going to be perceived as weakness and lack of resolve. Once that chink showed up in the armor, the Ada Haters of America charged in to exploit it with gusto and the more ambivalent ones in the crowd stuck their fingers into the air to find which way the wind was blowing and decided it wasn't towards Ada. Maybe The Mandate was a mistake to begin with. Maybe it should have been abandoned. But if abandonment of The Mandate had to be done and there wasn't a desire to simultaneously abandon Ada, then perhaps the DoD could have done more to show it still thought Ada was a good idea and that it supported it. (DoD could have allocated significant money to build development tools, etc., that might have made Ada a more attractive choice, for example.) Instead, they effectively said "you're on your own - sink or swim..." which clearly added to the perception that DoD was "abandoning" Ada. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 8:01 ` Michael Erdmann 2002-04-14 10:24 ` Ingo Marks @ 2002-04-14 14:44 ` Gary Scott 2002-04-14 15:44 ` Michael Erdmann 2002-04-14 15:54 ` Larry Kilgallen 2 siblings, 1 reply; 425+ messages in thread From: Gary Scott @ 2002-04-14 14:44 UTC (permalink / raw) Michael Erdmann wrote: > > Kent Paul Dolan wrote: > > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > > > >>Kent Paul Dolan wrote: > >> > > > >>>The love of doing things one rigid way, with all decisions handed down > >>>from above, ran square into the software development community, which is > >>>used to speedy and flexible growth in its tools. > >>> > > > >>This has nothing to do with the DoD. > >> > > > > To the contrary, rigid, top down command structure with limited upwards > > feedback is quintessentially a military organization model. No business > > could long survive with a similarly rigid hierarchy. > > > I am not so mutch experienced with the DoD, but to me it sounds > like what you can often encounter in large companies and they are > still dominating the market without alwys beeing always the technical > leader in there domain. But leadership in the software world so often involves fads, reinvention of the wheel and calling it by another name, etc. It's hard to sort through sometimes as to what's truly a technical advance and what's merely a regurgitation of something that was available in the 1970's on an IBM mainframe (html-like text markup). -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 14:44 ` Gary Scott @ 2002-04-14 15:44 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 15:44 UTC (permalink / raw) Gary Scott wrote: > Michael Erdmann wrote: > >>Kent Paul Dolan wrote: >> >>>"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: >>> >>> >>>>Kent Paul Dolan wrote: >>>> >>>> >>>>>The love of doing things one rigid way, with all decisions handed down >>>>> >>>>>from above, ran square into the software development community, which is >>>> >>>>>used to speedy and flexible growth in its tools. >>>>> >>>>> >>>>This has nothing to do with the DoD. >>>> >>>> >>>To the contrary, rigid, top down command structure with limited upwards >>>feedback is quintessentially a military organization model. No business >>>could long survive with a similarly rigid hierarchy. >>> >>> >>I am not so mutch experienced with the DoD, but to me it sounds >>like what you can often encounter in large companies and they are >>still dominating the market without alwys beeing always the technical >>leader in there domain. >> > > But leadership in the software world so often involves fads, reinvention > of the wheel and calling it by another name, etc. It's hard to sort > through sometimes as to what's truly a technical advance and what's > merely a regurgitation of something that was available in the 1970's on > an IBM mainframe (html-like text markup). I agree completly on what you are saying, the same thing in the context of different technologies has completly different impact (sgml/xml is a good example is think) But Ada 95 should support some of the common practices (like networking, dynamic lists...) through it's standard, avoiding us from reinventing the same common things in the same technical context (in this case Ada 95) all over again. For example with Ada you dont have to think about communication between tasks any more because the language supports it, before this you had the burden of implementing of selecting a tasking system. Regards M.Erdmann > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 8:01 ` Michael Erdmann 2002-04-14 10:24 ` Ingo Marks 2002-04-14 14:44 ` Gary Scott @ 2002-04-14 15:54 ` Larry Kilgallen 2002-04-14 16:33 ` Michael Erdmann ` (2 more replies) 2 siblings, 3 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-14 15:54 UTC (permalink / raw) In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > This is exaclty the impression i have my self. So i was wondering > if Ada could take a new direction, when the open source communitiy is > more directly involved by establishing a public process in order > to enhance the predefined libraries, and may be later, to make an > attempt to get these things into ISO etc.. Don't worry about getting it into the ISO standards, just get people using a common set of packages and the rest will follow. There were recent efforts here in this newsgroup in the area of containers; you are free to choose a different venue. There is _nothing_ about the ISO process that is holding you back, and libraries/packages have little to do with core language changes. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 15:54 ` Larry Kilgallen @ 2002-04-14 16:33 ` Michael Erdmann 2002-04-14 21:46 ` Larry Kilgallen 2002-04-15 15:39 ` Marin David Condic 2002-04-15 15:11 ` Marin David Condic 2002-04-15 15:28 ` Marin David Condic 2 siblings, 2 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 16:33 UTC (permalink / raw) Larry Kilgallen wrote: > In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > > >>This is exaclty the impression i have my self. So i was wondering >>if Ada could take a new direction, when the open source communitiy is >>more directly involved by establishing a public process in order >>to enhance the predefined libraries, and may be later, to make an >>attempt to get these things into ISO etc.. >> > > Don't worry about getting it into the ISO standards, just get people > using a common set of packages and the rest will follow. There were > recent efforts here in this newsgroup in the area of containers; you > are free to choose a different venue. Did they manage to get this into an Appendix of the Ada 95 RM, or did they succeed with there container packages? > > There is _nothing_ about the ISO process that is holding you back, > and libraries/packages have little to do with core language changes. > The problem is now to find the correct platform (organisation) to develope the process. Is there already something in the community or has something new to be setup? My idea is to use the ISO ARC WG9 as a start platform. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 16:33 ` Michael Erdmann @ 2002-04-14 21:46 ` Larry Kilgallen 2002-04-15 15:39 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-14 21:46 UTC (permalink / raw) In article <3CB9AF3C.8030301@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > Larry Kilgallen wrote: >> In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: >> >> >>>This is exaclty the impression i have my self. So i was wondering >>>if Ada could take a new direction, when the open source communitiy is >>>more directly involved by establishing a public process in order >>>to enhance the predefined libraries, and may be later, to make an >>>attempt to get these things into ISO etc.. >>> >> >> Don't worry about getting it into the ISO standards, just get people >> using a common set of packages and the rest will follow. There were >> recent efforts here in this newsgroup in the area of containers; you >> are free to choose a different venue. > > Did they manage to get this into an Appendix of the Ada 95 RM, or > did they succeed with there container packages? To the best of my knowledge, they have not yet achieved consensus and multiple implementations among those who are most anxious to see such capability. That is the first step. Even for language core features, the GNAT implementation of Ada is ready-made for local experimentation prior to proposal for standardization. >> There is _nothing_ about the ISO process that is holding you back, >> and libraries/packages have little to do with core language changes. >> > The problem is now to find the correct platform (organisation) to > develope the process. Is there already something in the community > or has something new to be setup? The problem is to create a useful detailed proposal, with multiple worked examples. To the best of my knowledge, the ARG will consider such an example when presented. Check the Lists discussions on this newsgroup within the past few months for a good example. There was a lot of discussion about features that are needed, and nobody was worried about how to get it standardized. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 16:33 ` Michael Erdmann 2002-04-14 21:46 ` Larry Kilgallen @ 2002-04-15 15:39 ` Marin David Condic 2002-04-16 16:34 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-15 15:39 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CB9AF3C.8030301@snafu.de... > > Did they manage to get this into an Appendix of the Ada 95 RM, or > did they succeed with there container packages? > Getting any sufficiently complex library into an appendix of the ARM would be very difficult and problematic. You would need to formally specify the behavior and then come up with a formal validation process. Any package or set of packages that might have hundreds of interface details would become a major problem to incorporate into something as formal as the ARM. What needs to happen is to have some kind of second tier of "standard" that doesn't require all that formality. If a thing could be reasonably well described so that an understanding emerged as to what it should be/do and the vendors were willing to include it in an identical way (same interface specs, at least, or reference implementation) in all their implementations, then you've got your "standard" without needing a ***STANDARD*** :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-15 15:39 ` Marin David Condic @ 2002-04-16 16:34 ` Michael Erdmann 2002-04-16 17:28 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-16 16:34 UTC (permalink / raw) To: Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> Marin David Condic wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message > news:3CB9AF3C.8030301@snafu.de... > >>Did they manage to get this into an Appendix of the Ada 95 RM, or >>did they succeed with there container packages? >> >> > Getting any sufficiently complex library into an appendix of the ARM would > be very difficult and problematic. You would need to formally specify the > behavior and then come up with a formal validation process. Any package or > set of packages that might have hundreds of interface details would become a > major problem to incorporate into something as formal as the ARM. Interesing, i did not know this. Is there any information about this in the net? May be this formality is why most of the people in the community are not taking part in the standarization process. > > What needs to happen is to have some kind of second tier of "standard" that > doesn't require all that formality. If a thing could be reasonably well > described so that an understanding emerged as to what it should be/do and > the vendors were willing to include it in an identical way (same interface > specs, at least, or reference implementation) in all their implementations, > then you've got your "standard" without needing a ***STANDARD*** :-) This is what is normally called a defacto standard. Raising initial interest for a certain sloution and setting up alliences to enforce the solution normally creates such standards. But if these alliences breaking up, such standards start to dissolve and lot of derivates of the original solution are back on the market gain. I like to avoid this. But your second tier idea may be the right point! This second tier could become some kind of public entry process for the ISO WG which is in the first stage (input) less formal and at the output as formal as ISO requieres. Establishing such a second tier interface to the public would be an interesting project for the open source community, and may be some ideas of the JPC may be taken over for this purpose. I am realy wondering if there are comparable projects in the net exisiting?! Regards M.Erdmann > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:34 ` Michael Erdmann @ 2002-04-16 17:28 ` Marin David Condic 2002-04-17 17:02 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-16 17:28 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CBC5281.1040202@snafu.de... > > Interesing, i did not know this. Is there any information about this > in the net? May be this formality is why most of the people in the > community are not taking part in the standarization process. > Well think about some of the packages that are in the appendices right now. Things like Ada.Strings.Fixed. There is a quite detailed description of the behavior of each subprogram in there and I'd suspect you need some part of the validation suite aimed at testing compliance with that specification. Furthermore, all they provide is a spec and that means the vendors have to go out and build the bodies - which for a string package may not be that big a deal, but for something like - say - a GUI would be *waaayy* much bigger and would hence meet resistance from the vendors. (Do you really think they're just chomping at the bit to rush out and spend millions just to get themselves compliant with the next Ada standard? ;-) > > This is what is normally called a defacto standard. Raising initial > interest for a certain sloution and setting up alliences to enforce > the solution normally creates such standards. But if these alliences > breaking up, such standards start to dissolve and lot of derivates > of the original solution are back on the market gain. I like to > avoid this. > Trying to do anything real formal to avoid divergence is just going to get too costly and difficult. What might work better is some version of "Standardization By Inertia" If you got some committee of vendors and users to agree on some libraries as the de facto standard and there was a reference implementation the vendors all adopted, chances are it would just stay the way it is because nobody is going to want to spend their own money to change it without a compelling reason. Think, for example, if all the vendors agreed to just ship the Booch Compoinents with their compilers and make it the de facto standard. People w ould be using them based on what they knew of the reference implementation and they'd expect their vendor to give them a conforming copy. If extensions were desired, there'd be a strong incentive to get them into the reference copy so long as doing so wasn't unnecessarily difficult. (The users and the vendors don't want to go updating everything in the world if BC v2.0 comes out with differences from their divergent paths.) > But your second tier idea may be the right point! This second tier > could become some kind of public entry process for the ISO WG which > is in the first stage (input) less formal and at the output as formal > as ISO requieres. > Establishing such a second tier interface to the public would be > an interesting project for the open source community, and may > be some ideas of the JPC may be taken over for this purpose. > I really think that once you stick the initials "ISO" on it you're asking for a rigid, validatable, *sloooooow* process to be put in place. It would be better to form something up under some less formal structure. It might work better to do something under the auspices of SIGAda - that's how ASIS got done, IIRC. You need the input and guidance of the vendors because if they won't sign up to include/implement whatever you come up with, the whole game is over. If the vendors said "We'd be interested in libraries that cover the following subjects...." and your working group could come up with an answer they'd be willing to adopt, *and* you could come up with the necessary resources to build a reference implementation, you might see a fairly quick and agile process evolve that probably wouldn't see a lot of divergence from the "standard". I really doubt that lobbying for *anything* to happen under ISO is going to result in any sort of process that meets the objectives you seem to be supporting. The less formal it is, the more likely it will be to move quickly and be willing to listen to what you have to say. If you got something that was adopted as a de facto standard, it would likely be a lot easier to get it included into the ISO standard after that point - if that seems at all important if/when that happens. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 17:28 ` Marin David Condic @ 2002-04-17 17:02 ` Michael Erdmann 2002-04-17 21:09 ` Kent Paul Dolan 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-17 17:02 UTC (permalink / raw) Marin David Condic wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message > news:3CBC5281.1040202@snafu.de... > >>Interesing, i did not know this. Is there any information about this >>in the net? May be this formality is why most of the people in the >>community are not taking part in the standarization process. >> >> > Well think about some of the packages that are in the appendices right now. > Things like Ada.Strings.Fixed. There is a quite detailed description of the > behavior of each subprogram in there and I'd suspect you need some part of > the validation suite aimed at testing compliance with that specification. > Furthermore, all they provide is a spec and that means the vendors have to > go out and build the bodies - which for a string package may not be that big > a deal, Mean while started to contact them using the ada-comments mail list. The answer was that i should just send a proposal & rational. Maybe i will do this asap for a basic container. Just to see what happens. > but for something like - say - a GUI would be *waaayy* much bigger > and would hence meet resistance from the vendors. (Do you really think > they're just chomping at the bit to rush out and spend millions just to get > themselves compliant with the next Ada standard? ;-) I gues GUI's was not a good idea, only resonable small building blocks should be standarized. I think nobody would attempt to stndarize a complete car! >>This is what is normally called a defacto standard. Raising initial >>interest for a certain sloution and setting up alliences to enforce >>the solution normally creates such standards. But if these alliences >>breaking up, such standards start to dissolve and lot of derivates >>of the original solution are back on the market gain. I like to >>avoid this. >> >> > Trying to do anything real formal to avoid divergence is just going to get > too costly and difficult. What might work better is some version of > "Standardization By Inertia" If you got some committee of vendors and users > to agree on some libraries as the de facto standard and there was a > reference implementation the vendors all adopted, chances are it would just > stay the way it is because nobody is going to want to spend their own money > to change it without a compelling reason. I agree on this also. I think the way of establishing first a defacto standard will be the best process. This could be done in the following steps (i guess): - Raise interest - Setup a group producing some result for the community - Distribute the software as wide as possible - Run several itterations (event incompatebil ones) - After you reached stability either propose to ISO or seek alliences with vendors. - Propose to ISO to stabilize the package I think the first 4 steps are typlical for open source software which is developed in the net. The two steps following have to be established by some means.May be it is in the interest of the vendors to standarize packages of this process in order to avoid the some body is chaging them via the same process after they have reached stability (> step 4). So the trick is to develope in the net in a distributed manner software till end of step 4. > >>But your second tier idea may be the right point! This second tier >>could become some kind of public entry process for the ISO WG which >>is in the first stage (input) less formal and at the output as formal >>as ISO requieres. >>Establishing such a second tier interface to the public would be >>an interesting project for the open source community, and may >>be some ideas of the JPC may be taken over for this purpose. >> >> > I really think that once you stick the initials "ISO" on it you're asking > for a rigid, validatable, *sloooooow* process to be put in place. It would > be better to form something up under some less formal structure. It might > work better to do something under the auspices of SIGAda - that's how ASIS > got done, IIRC. You need the input and guidance of the vendors because if > they won't sign up to include/implement whatever you come up with, the whole > game is over. If the vendors said "We'd be interested in libraries that > cover the following subjects...." and your working group could come up with > an answer they'd be willing to adopt, *and* you could come up with the > necessary resources to build a reference implementation, you might see a > fairly quick and agile process evolve that probably wouldn't see a lot of > divergence from the "standard". > I will check out ACM! > I really doubt that lobbying for *anything* to happen under ISO is going to > result in any sort of process that meets the objectives you seem to be > supporting. The less formal it is, the more likely it will be to move > quickly and be willing to listen to what you have to say. If you got > something that was adopted as a de facto standard, it would likely be a lot > easier to get it included into the ISO standard after that point - if that > seems at all important if/when that happens. There i do agree completley, ISO will not be the driving part of development. ISO will be the finalization of the development. > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 17:02 ` Michael Erdmann @ 2002-04-17 21:09 ` Kent Paul Dolan 2002-04-17 21:25 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-17 21:09 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > Marin David Condic wrote: > > but for something like - say - a GUI would be *waaayy* much bigger > > and would hence meet resistance from the vendors. (Do you really think > > they're just chomping at the bit to rush out and spend millions just to get > > themselves compliant with the next Ada standard? ;-) > I gues GUI's was not a good idea, only resonable small building > blocks should be standarized. I think nobody would attempt to > stndarize a complete car! Ummm, but arguably Java's fairly instant success was exactly due to coming with the GUI built in, so that GUIed applets started popping up all over the Web, evangelizing Java without extra effort by Sun. I suspect that a standard GUI is high on the list of what is needed to make Ada more popular, and luckily, Ada to Java compilation provides that pretty much for free already. Is it being used? xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 21:09 ` Kent Paul Dolan @ 2002-04-17 21:25 ` Darren New 2002-04-17 23:14 ` Kent Paul Dolan 0 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-17 21:25 UTC (permalink / raw) Kent Paul Dolan wrote: > Ummm, but arguably Java's fairly instant success was exactly due to > coming with the GUI built in, so that GUIed applets started popping up > all over the Web, evangelizing Java without extra effort by Sun. Well, that and Sun getting it built into several popular web browsers by default. > I suspect that a standard GUI is high on the list of what is needed to > make Ada more popular, and luckily, Ada to Java compilation provides > that pretty much for free already. Is it being used? How about a binding to Tk (of Tcl fame)? I thought GNAT already supports that, yes? -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 21:25 ` Darren New @ 2002-04-17 23:14 ` Kent Paul Dolan 2002-04-17 23:24 ` Darren New 2002-04-18 17:12 ` Pascal Obry 0 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-17 23:14 UTC (permalink / raw) "Darren New" <dnew@san.rr.com> wrote:. > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports > that, yes? Reasonable, I presume you mean GtkAda, which I haven't seen (amazing how much of the universe of discourse you can't explore when your pillow is the pavement). Since there is already a Perl binding to Tk (which (PerlTk) I have used), the more languages that add in a Tk binding, the better chance you have of making it the de facto standard; I'm not enough of a theorist to compare it to either the Java GUI or to the various international standard graphics APIs for superiority, though. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 23:14 ` Kent Paul Dolan @ 2002-04-17 23:24 ` Darren New 2002-04-18 4:34 ` Eric G. Miller 2002-04-18 4:42 ` Kent Paul Dolan 2002-04-18 17:12 ` Pascal Obry 1 sibling, 2 replies; 425+ messages in thread From: Darren New @ 2002-04-17 23:24 UTC (permalink / raw) Kent Paul Dolan wrote: > > "Darren New" <dnew@san.rr.com> wrote:. > > > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports > > that, yes? > > Reasonable, I presume you mean GtkAda, I haven't looked at GtkAda. I would have assumed that had Ada used Tk, it would be called Ada/Tk, just like it's Perl/Tk, Python/Tk, and Tcl/Tk. If GtkAda is actually Ada with Tck's Tk, then cool, let's make that the standard. ;-) > Since there is already a Perl binding to Tk (which (PerlTk) I have > used), the more languages that add in a Tk binding, the better chance > you have of making it the de facto standard; That's what I thought, yah. And it's already portable amongst a wide variety of desktop systems. And capable of supporting a variety of programming interface styles. > I'm not enough of a > theorist to compare it to either the Java GUI or to the various > international standard graphics APIs for superiority, though. It's very simple to learn, too. Way easier than either Java GUI, and relatively high-level, but relatively limited due to being high-level and portable. You don't get 3D, or round windows, or dancing menus with talking paperclips.... wait a minute... that could be a benefit too! -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 23:24 ` Darren New @ 2002-04-18 4:34 ` Eric G. Miller 2002-04-18 14:08 ` Ted Dennison 2002-04-18 4:42 ` Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Eric G. Miller @ 2002-04-18 4:34 UTC (permalink / raw) In <3CBE0457.6E7B82A8@san.rr.com>, Darren New wrote: > Kent Paul Dolan wrote: >> >> "Darren New" <dnew@san.rr.com> wrote:. >> >> > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports >> > that, yes? >> >> Reasonable, I presume you mean GtkAda, > > I haven't looked at GtkAda. I would have assumed that had Ada used Tk, > it would be called Ada/Tk, just like it's Perl/Tk, Python/Tk, and > Tcl/Tk. If GtkAda is actually Ada with Tck's Tk, then cool, let's make > that the standard. ;-) There is no connection between Tk and Gtk, though both have similar goals (gui abstraction layer and toolkit). AFAIK, both are written in C. >> Since there is already a Perl binding to Tk (which (PerlTk) I have >> used), the more languages that add in a Tk binding, the better chance >> you have of making it the de facto standard; > > That's what I thought, yah. And it's already portable amongst a wide > variety of desktop systems. And capable of supporting a variety of > programming interface styles. That is one benefit of Tk. It's been around longer, and has been ported to more systems than Gtk. But my impression is that Gtk2 smokes Tk in widget functionality, and certainly the Gtk1.x look and "feel" is better than most Tk programs I've used. I suspect in a year or so, Tk's advantage in portability will be less than today. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 4:34 ` Eric G. Miller @ 2002-04-18 14:08 ` Ted Dennison 2002-04-18 18:34 ` Al Reynolds ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 14:08 UTC (permalink / raw) "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>... > There is no connection between Tk and Gtk, though both have similar > goals (gui abstraction layer and toolkit). AFAIK, both are written > in C. Just to be complete it should be mentioned that there are good Ada bindings available for both. > That is one benefit of Tk. It's been around longer, and has been > ported to more systems than Gtk. But my impression is that Gtk2 > smokes Tk in widget functionality, and certainly the Gtk1.x look and > "feel" is better than most Tk programs I've used. I suspect in a I switched from Tk to Gtk as my default Ada gui about 2 years ago for precisely that reason. The only sore spot with Gtk is that it isn't yet supported on Macs. I suspect that will change soon, at least for OSX. For those looking for a defacto Ada GUI standard, I would say that it is already here with GtkAda, as much as we will ever have a standard. Perhaps it would help everyone to realise its "standard" status if we distributed it with future Gnat builds? :-) -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:08 ` Ted Dennison @ 2002-04-18 18:34 ` Al Reynolds 2002-04-18 19:15 ` Marin David Condic 2002-04-18 20:03 ` Michael Erdmann 2002-04-18 20:45 ` Ingo Marks 2 siblings, 1 reply; 425+ messages in thread From: Al Reynolds @ 2002-04-18 18:34 UTC (permalink / raw) GtkAda has been ported to MacOS X. We needed to build GVD, which uses GtkAda, to provide a user-friendly interface to our Ada-aware version of GDB so that we can more readily debug our Ada binding to Apple's Carbon API :) Of course, by "ported" what I meant is we compiled it and the demo ran fine (thanks to Ada). I'm guessing that most of the effort went into porting Gtk+ (thanks to C) ;) I don't know if a GUI standard is required for Ada or for any other language. From my own experience it wasn't that C++ was standard (because it wasn't) but the STL (which also wasn't a standard) made it possible to hack at twice the speed which is what appealed to me. The same goes for Perl (also not a standard) which has mega-functionality attached to short character sequences and libraries that cover most application domains. Whenever I need to do something *just once* I can reach out and use the language or environment, standard or not, which provides the greatest support for the problem at hand. What appeals to me about Ada is that I have to be disciplined enough to get my code past the damn compiler! After that it's doing what I enjoy so much with the other languages: debugging :) <RANT> So, if we really want to make Ada popular what we have to do is make it possible to hack in Ada quickly. That's what GUI support is all about. That's what IDE's are all about. That's what libraries for containers, math, parsing, networking, etc, are all about. We want Ada to become a strongly-typed, scripting language. </RANT> Have fun, Al Ted Dennison wrote: > "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>... > >>There is no connection between Tk and Gtk, though both have similar >>goals (gui abstraction layer and toolkit). AFAIK, both are written >>in C. > > > Just to be complete it should be mentioned that there are good Ada > bindings available for both. > > >>That is one benefit of Tk. It's been around longer, and has been >>ported to more systems than Gtk. But my impression is that Gtk2 >>smokes Tk in widget functionality, and certainly the Gtk1.x look and >>"feel" is better than most Tk programs I've used. I suspect in a > > > I switched from Tk to Gtk as my default Ada gui about 2 years ago for > precisely that reason. The only sore spot with Gtk is that it isn't > yet supported on Macs. I suspect that will change soon, at least for > OSX. > > For those looking for a defacto Ada GUI standard, I would say that it > is already here with GtkAda, as much as we will ever have a standard. > Perhaps it would help everyone to realise its "standard" status if we > distributed it with future Gnat builds? :-) > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 18:34 ` Al Reynolds @ 2002-04-18 19:15 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 19:15 UTC (permalink / raw) I'd agree except for the "hack" part and "scripting language" part. I think the real issue is *almost* what you describe but with a subtle difference. It is "Time To Market" and "Leverage" rather than "hack in Ada quickly" or "scripting language" that is missing. If we had the things you describe (containers, math, parsing, networking, GUI, IDE, etc.) they would all work to create leverage and reduce time to market. You could still cater to Software Engineering, high reliability, life-cycle, etc., rather than cater to the script-kiddies and hackers, and still be successful being what Ada is at its roots. If an Ada environment could get you to market 50% faster than MSVC++ or some other popular development environment, it would be hard for business enterprises to argue against it. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Al Reynolds" <alan1@bellatlantic.net> wrote in message news:3CBF11BE.3090007@bellatlantic.net... > > <RANT> > So, if we really want to make Ada popular what we have to do is make it possible to hack in Ada quickly. That's what > GUI support is all about. That's what IDE's are all about. That's what libraries for containers, math, parsing, > networking, etc, are all about. We want Ada to become a strongly-typed, scripting language. > </RANT> > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:08 ` Ted Dennison 2002-04-18 18:34 ` Al Reynolds @ 2002-04-18 20:03 ` Michael Erdmann 2002-04-18 20:45 ` Ingo Marks 2 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-18 20:03 UTC (permalink / raw) Ted Dennison wrote: > "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:<pan.2002.04.17.21.35.54.963686.16266@jps-nospam.net>... > > For those looking for a defacto Ada GUI standard, I would say that it > is already here with GtkAda, as much as we will ever have a standard. > Perhaps it would help everyone to realise its "standard" status if we > distributed it with future Gnat builds? :-) Yes would guess so! > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:08 ` Ted Dennison 2002-04-18 18:34 ` Al Reynolds 2002-04-18 20:03 ` Michael Erdmann @ 2002-04-18 20:45 ` Ingo Marks 2 siblings, 0 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-18 20:45 UTC (permalink / raw) Ted Dennison wrote: > I switched from Tk to Gtk as my default Ada gui about 2 years ago for > precisely that reason. The only sore spot with Gtk is that it isn't > yet supported on Macs. I suspect that will change soon, at least for > OSX. At least Gtk is supported in OSX: http://www.apple.com/scitech/unixports/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 23:24 ` Darren New 2002-04-18 4:34 ` Eric G. Miller @ 2002-04-18 4:42 ` Kent Paul Dolan 2002-04-18 13:16 ` Marin David Condic 2002-04-18 13:54 ` Ted Dennison 1 sibling, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 4:42 UTC (permalink / raw) "Darren New" <dnew@san.rr.com> wrote: > It's very simple to learn, too. Way easier than either Java GUI, and > relatively high-level, but relatively limited due to being high-level > and portable. You don't get 3D, or round windows, or dancing menus with > talking paperclips.... wait a minute... that could be a benefit too! Ummm. Actually then, that could be a problem, since a fraction of Ada use (I have no idea how much) goes into stuff like flight simulators and combat theater simulators. I don't think limited functionality graphics would fly as a standard Ada GUI (though I'm talking way past my knowledge base at this point, so it is time for me to choose this leaf as a point at which to bow out of this bough of this discussion tree, I suspect). xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 4:42 ` Kent Paul Dolan @ 2002-04-18 13:16 ` Marin David Condic 2002-04-18 13:54 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 13:16 UTC (permalink / raw) GtkAda as a "standard" would be more than what we have now - which is pretty close to "nothing" last time I checked. Lack of sophisticated 3-D graphics for flight simulators wouldn't be a hindrence in my mind. If that's what you want to build you'll probably want some package that is specialized to the platform and problem domain anyway - which you could still do. Not to mention that should there be some sense of GtkAda being the "standard" then there would be incentives to build upon it & extend its capabilities. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Kent Paul Dolan" <xanthian@well.com> wrote in message news:75e7bccb730eda7db554601b66ba9814.48257@mygate.mailgate.org... > > Ummm. Actually then, that could be a problem, since a fraction of Ada > use (I have no idea how much) goes into stuff like flight simulators and > combat theater simulators. I don't think limited functionality graphics > would fly as a standard Ada GUI (though I'm talking way past my > knowledge base at this point, so it is time for me to choose this leaf > as a point at which to bow out of this bough of this discussion tree, I > suspect). > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 4:42 ` Kent Paul Dolan 2002-04-18 13:16 ` Marin David Condic @ 2002-04-18 13:54 ` Ted Dennison 2002-04-18 18:25 ` Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-18 13:54 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<75e7bccb730eda7db554601b66ba9814.48257@mygate.mailgate.org>... > "Darren New" <dnew@san.rr.com> wrote: > > > It's very simple to learn, too. Way easier than either Java GUI, and > > relatively high-level, but relatively limited due to being high-level > > and portable. You don't get 3D, or round windows, or dancing menus with > > talking paperclips.... wait a minute... that could be a benefit too! > > Ummm. Actually then, that could be a problem, since a fraction of Ada > use (I have no idea how much) goes into stuff like flight simulators and > combat theater simulators. I don't think limited functionality graphics > would fly as a standard Ada GUI (though I'm talking way past my > knowledge base at this point, so it is time for me to choose this leaf > as a point at which to bow out of this bough of this discussion tree, I > suspect). For the flight simulators I've worked on, generally you have several systems, including at a minimum a dedicated operator station for the instructors (which can be non-realtime and contains nice GUI's), a host machine (hard real time, no GUI), and an IG (Image Generator, a dedicated real-time 3D graphics generator). The host gets the most benifit from Ada. For the IOS, you really need to build everything with a GUI builder. If any Ada is there, it will only be glue code (or in some cases, generated by the GUI builder). The IG's we usually get off the shelf from an IG vendor (eg: Vitals from FlightSafety or Compu-Scenes from Lockheed Martin), and they are very expensive. I don't know if any of them use Ada, but I doubt it. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 13:54 ` Ted Dennison @ 2002-04-18 18:25 ` Kent Paul Dolan 2002-04-18 19:05 ` Marin David Condic 2002-04-18 21:41 ` Ted Dennison 0 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 18:25 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote: > "Kent Paul Dolan" <xanthian@well.com> wrote: > > (though I'm talking way past my > > knowledge base at this point, so it is time for me to choose this leaf > > as a point at which to bow out of this bough of this discussion tree, I > > suspect). Sigh. Or maybe not. > For the IOS, you really need to build everything > with a GUI builder. If any Ada is there, it will only be glue code (or > in some cases, generated by the GUI builder). Doesn't this become a self fulfilling prophesy? "Ada doesn't do graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is doing graphic in Ada (yet), so it isn't important for Ada to have strong graphics capabilities (ever)." xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 18:25 ` Kent Paul Dolan @ 2002-04-18 19:05 ` Marin David Condic 2002-04-18 21:41 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 19:05 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:5b41d17f3dcf632de26b5ef06daf0650.48257@mygate.mailgate.org... > > Doesn't this become a self fulfilling prophesy? "Ada doesn't do > graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is > doing graphic in Ada (yet), so it isn't important for Ada to have strong > graphics capabilities (ever)." > True, but its not as if there are lots of languages out there that have large-scale, standardized, built-in graphics capabilities of the sort that one might use to build flight simulators. C/C++ doesn't really have graphics as a "standard". They just get it because things like Windows and Motif are all written in C/C++, so it sort of gets viewed as just part of the environment. Lots of add-on, sophisticated graphics packages are similarly C/C++ so people tend to view it as spitting into the wind to use any other language. I'm definitely not against the proposition that Ada could/should include some kind of graphics support as some sort of convention/standard, but we have to admit that this is the kind of thing that is difficult to make portable across a wide number of platforms. As a result, we might just have to settle for some minimal level of support (a "graphics microkernel"?), and look to build on top of that. In time, the set of things that can be supported across a wide set of platforms might just expand and get more sophisticated, but if we want a language extension that isn't platform specific, that's probably the way it will have to be. The alternative is to define a whole execution environment for Ada programs (ala Java) with its own windowing/graphics scheme. That's not necessarily a bad idea, but its going to have its own set of problems and issues. I'd settle for a lesser solution that got the ball rolling. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 18:25 ` Kent Paul Dolan 2002-04-18 19:05 ` Marin David Condic @ 2002-04-18 21:41 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 21:41 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<5b41d17f3dcf632de26b5ef06daf0650.48257@mygate.mailgate.org>... > "Ted Dennison" <dennison@telepath.com> wrote: > > For the IOS, you really need to build everything > > with a GUI builder. If any Ada is there, it will only be glue code (or > > in some cases, generated by the GUI builder). > > Doesn't this become a self fulfilling prophesy? "Ada doesn't do > graphics well (yet) so we don't do the graphics in Ada (ever). Nobody is > doing graphic in Ada (yet), so it isn't important for Ada to have strong > graphics capabilities (ever)." The issue with IOS's has nothing to do with Ada or any other programming language. The issue is that IOS's are so complicated (often hundreds of different screens of controls), that you *have* to develop the graphics with a GUI builder. You need the instant visual feedback for what you are creating. Trying to draw controls and adjust stuff like button sizing and placement numericly with a compile in the middle of every viewing would just be insane. As for GUI's in general, I don't think we are in nearly as bad a situation as we used to be in. Ada's always been easy to integrate with UIL, which opens up the world of UIL (Motif) GUI builders for easy Ada use. GTKAda is quite complete, and can do about anything a GUI author needs as long as long as they can accept its look&feel. Better Win32 GUI support might be nice, but that wouldn't help non-Windows Ada users much. It might be nice in an abstract sense to have a standard Ada GUI that isn't quite as industrial-strength as GTK+. But I think defining the ideal standard GUI with total agreement from the Ada community would be incredibly difficult; much moreso than a component library. In my book an ideal GUI would be its own separate language with its own compiler anyway. Motif had such a thing (UIL), and its compiler would regularly catch GUI definition errors that would have gone undetected in Ada code. That kind of thing is why we like Ada for non-GUI code, right? -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-17 23:14 ` Kent Paul Dolan 2002-04-17 23:24 ` Darren New @ 2002-04-18 17:12 ` Pascal Obry 1 sibling, 0 replies; 425+ messages in thread From: Pascal Obry @ 2002-04-18 17:12 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> writes: > "Darren New" <dnew@san.rr.com> wrote:. > > > How about a binding to Tk (of Tcl fame)? I thought GNAT already supports > > that, yes? > > Reasonable, I presume you mean GtkAda, which I haven't seen (amazing how > much of the universe of discourse you can't explore when your pillow is > the pavement). GtkAda is a binding on top of the Gtk toolkit. TASH is an Ada to Tcl/Tk binding. 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] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 15:54 ` Larry Kilgallen 2002-04-14 16:33 ` Michael Erdmann @ 2002-04-15 15:11 ` Marin David Condic 2002-04-15 15:28 ` Marin David Condic 2 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-15 15:11 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:qnlsMmlYZCr9@eisner.encompasserve.org... > In article <3CB9375F.8040904@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > > > This is exaclty the impression i have my self. So i was wondering > > if Ada could take a new direction, when the open source communitiy is > > more directly involved by establishing a public process in order > > to enhance the predefined libraries, and may be later, to make an > > attempt to get these things into ISO etc.. > > Don't worry about getting it into the ISO standards, just get people > using a common set of packages and the rest will follow. There were > recent efforts here in this newsgroup in the area of containers; you > are free to choose a different venue. > > There is _nothing_ about the ISO process that is holding you back, > and libraries/packages have little to do with core language changes. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-14 15:54 ` Larry Kilgallen 2002-04-14 16:33 ` Michael Erdmann 2002-04-15 15:11 ` Marin David Condic @ 2002-04-15 15:28 ` Marin David Condic 2002-04-16 16:53 ` Michael Erdmann 2 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-15 15:28 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:qnlsMmlYZCr9@eisner.encompasserve.org... > > Don't worry about getting it into the ISO standards, just get people > using a common set of packages and the rest will follow. There were > recent efforts here in this newsgroup in the area of containers; you > are free to choose a different venue. > > There is _nothing_ about the ISO process that is holding you back, > and libraries/packages have little to do with core language changes. This is true. What matters with respect to libraries is not so much that they have some rigid, formally defined, validated, ISO standard as it is that at least most of the vendors provide pretty much the same thing. You probably want a good deal of flexibility for libraries (at least in their early lives) so they can be changed as experience dictates. Maybe at some point when a given library has become very widespread and stable you could get it declared part of the ISO standard - but you may never really want that. Yopu may want to maintain the flexibility of being able to easily change out the library for something else. If we had some community concensus that one or more libraries was what we wanted for doing job X, all you'd have to do is persuade the vendors to distribute it with their compilers and it instantly becomes part of Ada even if it isn't part of the "standard". MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-15 15:28 ` Marin David Condic @ 2002-04-16 16:53 ` Michael Erdmann 2002-04-16 17:49 ` Ingo Marks ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-16 16:53 UTC (permalink / raw) Marin David Condic wrote: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message > news:qnlsMmlYZCr9@eisner.encompasserve.org... > >>Don't worry about getting it into the ISO standards, just get people >>using a common set of packages and the rest will follow. There were >>recent efforts here in this newsgroup in the area of containers; you >>are free to choose a different venue. >> >>There is _nothing_ about the ISO process that is holding you back, >>and libraries/packages have little to do with core language changes. >> > > This is true. What matters with respect to libraries is not so much that > they have some rigid, formally defined, validated, ISO standard as it is > that at least most of the vendors provide pretty much the same thing. You > probably want a good deal of flexibility for libraries (at least in their > early lives) so they can be changed as experience dictates. Maybe at some > point when a given library has become very widespread and stable you could > get it declared part of the ISO standard - but you may never really want > that. Yopu may want to maintain the flexibility of being able to easily > change out the library for something else. Yes you may always want to change something, but using standard components means reliability by beening conservative even if you are loosing elegance. > If we had some community concensus that one or more libraries was what we > wanted for doing job X, all you'd have to do is persuade the vendors to > distribute it with their compilers and it instantly becomes part of Ada even > if it isn't part of the "standard". I dont think that we need the vendors this mutch, most of the popular open source software is distributed without them (thanks to sites as sourceforge etc..), In my mind the idea of a public ada process is showing up: - There is a job to be done and i have some solution for it. Propose the solution to the community (who is this, i gues comp.lang.ada?) - If sufficient interest has been raised, form a working group for this topic and provide an implemenation for public use. - Proceed until wide acceptance - Propose to ISO But this is nothing new, this is the typical open source process as we know it, the only difference is the last step. I think this is your second tier idea. May be it is possible to setup a new way of communication between the public and the ISO WG making the entry more easier for us. Or maybe it would be a good idea if ISO acts more proactive by asking the comminity for entires on certain issues (e.g. containers etc..)! Regards M.Erdmann > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:53 ` Michael Erdmann @ 2002-04-16 17:49 ` Ingo Marks 2002-04-16 17:57 ` Marin David Condic 2002-04-18 14:04 ` Bill Tate 2 siblings, 0 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-16 17:49 UTC (permalink / raw) Michael Erdmann wrote: > In my mind the idea of a public ada process is showing up: > > - If sufficient interest has been raised, form a working group > for this topic and provide an implemenation for public use. I would like to recommend to ask as many Ada website maintainers (like www.adapower.net) as possible to include a link to your project page together with some short description. Maybe developers visiting these sites could be made curious. Regards Ingo ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:53 ` Michael Erdmann 2002-04-16 17:49 ` Ingo Marks @ 2002-04-16 17:57 ` Marin David Condic 2002-04-18 14:04 ` Bill Tate 2 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-16 17:57 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CBC56F0.9050300@snafu.de... > > Yes you may always want to change something, but using standard > components means reliability by beening conservative even if > you are loosing elegance. > I'm not arguing against standards. I'm arguing in favor of a process that might mean a fresh release once a quarter that incorporates the latest and greatest ideas and extensions. You'd want to keep your interfaces as stable as possible, but allow for a process that would allow fixes, improvements and new things to enter into it (and be included in vendor distributions) without waiting for a ten-year language-revision-cycle to happen. > > I dont think that we need the vendors this mutch, most of the popular > open source software is distributed without them (thanks to sites > as sourceforge etc..), > Sure. You can always go put yet another container library out on the net somewhere and probably find a fair number of takers who will "standardize" on your particular library for their own development. (How many are out there as we speak?) The trick is to get one of the many fine container libraries that exist or may one day exist to be the one that everybody uses. If the vendors aren't in on it and don't include it along with their compiler distribution such that everyone knows they could either use what is there or go their own way and not be portable, then you've got the situation we have now: Lots of fine container libraries available and none of them The Standard. (I use container libraries just as an example. The same applies to any other collection of components/tools one might care to discuss.) That's why I think the vendors have to be behind it. If the same thing comes with (almost) every compiler, then it *is* the standard regardless of it being in the ARM or not. (I can always come up with Marin.Strings.Fixed and it might be fine for my needs, but would people use it if they new all they had to do was go: "with Ada.Strings.Fixed;" and have something everyone knew about and understood?) > > - Propose to ISO > Maybe. One day. But I still think that's asking for a lot of cost and time that would likely kill something in the process. > But this is nothing new, this is the typical open source process as > we know it, the only difference is the last step. I think this is > your second tier idea. May be it is possible to setup a new way of > communication between the public and the ISO WG making the entry > more easier for us. Or maybe it would be a good idea if ISO acts > more proactive by asking the comminity for entires on certain issues > (e.g. containers etc..)! > My second tier idea is simply some process for producing an agreed-upon language extension (library, not syntax/semantics) that gets acceptance by the vendors and the community at large. Its hard enough to get an agreement in an informal setting (we've tried here before, right? :-) that I think anything that starts moving towards "Let's go get ISO to accept it..." is going to guarantee failure. I'm suggesting that we'd be far better off setting the goals to something a little more achievable and see where it goes. If one day, it makes it back into ISO, fine. But I think just getting it into common usage is enough of a windmill to tilt at. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-16 16:53 ` Michael Erdmann 2002-04-16 17:49 ` Ingo Marks 2002-04-16 17:57 ` Marin David Condic @ 2002-04-18 14:04 ` Bill Tate 2002-04-18 14:45 ` Gary Scott 2002-04-18 20:09 ` Michael Erdmann 2 siblings, 2 replies; 425+ messages in thread From: Bill Tate @ 2002-04-18 14:04 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message > > If we had some community concensus that one or more libraries was what we [snip] > > wanted for doing job X, all you'd have to do is persuade the vendors to > > distribute it with their compilers and it instantly becomes part of Ada even > > if it isn't part of the "standard". > > I dont think that we need the vendors this mutch, most of the popular > open source software is distributed without them (thanks to sites > as sourceforge etc..), > > In my mind the idea of a public ada process is showing up: > > - There is a job to be done and i have some solution for it. Propose > the solution to the community (who is this, i gues comp.lang.ada?) > > - If sufficient interest has been raised, form a working group > for this topic and provide an implemenation for public use. > > - Proceed until wide acceptance > > - Propose to ISO > Michael, I would like to echo some of your points from an outsider's perspective. As someone who spends most of his time on comp.lang.python, Python suffers from some of the same "kinds" of perceptions (erroneous or otherwise) as Ada does, e.g., degree of acceptance, availability of developers, etc. However, Python does have considerable "traction" and "energy" in terms of its direction and the process for moving new features into its standard "core." While ISO adoption isn't part of the python agenda, the Python Evaluation Process (PEP) seems to fill the bill that your comments suggest. A specific PEP garners no shortage of posts from the devoted. Wide-spread use including version updates most often lead to incorporation into the standard distribution. Its the latter that seems to be the threshold that needs to be achieved for widespread community acceptance. WRT Ada and the ISO process, this would seem to be, at least, one logical jumping off point since many of the "important" battles would likely have already been fought and resolved. Information on the PEP process is available from www.python.org. Hopefully you wouldn't need to reinvent the wheel (too much) in order to adopt a process that would work for your community instead of the other way around - like the python language itself, this is something that borders on religious dogma in the python community. Hopefully this is of some use. cheers, Bill ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:04 ` Bill Tate @ 2002-04-18 14:45 ` Gary Scott 2002-04-18 20:12 ` Michael Erdmann 2002-04-18 20:09 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Gary Scott @ 2002-04-18 14:45 UTC (permalink / raw) Bill Tate wrote: > > Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message > > > If we had some community concensus that one or more libraries was what we > [snip] > > > wanted for doing job X, all you'd have to do is persuade the vendors to > > > distribute it with their compilers and it instantly becomes part of Ada even > > > if it isn't part of the "standard". > > > > I dont think that we need the vendors this mutch, most of the popular > > open source software is distributed without them (thanks to sites > > as sourceforge etc..), > > > > In my mind the idea of a public ada process is showing up: > > > > - There is a job to be done and i have some solution for it. Propose > > the solution to the community (who is this, i gues comp.lang.ada?) > > > > - If sufficient interest has been raised, form a working group > > for this topic and provide an implemenation for public use. > > > > - Proceed until wide acceptance > > > > - Propose to ISO > > > Michael, > I would like to echo some of your points from an outsider's > perspective. As someone who spends most of his time on > comp.lang.python, Python suffers from some of the same "kinds" of > perceptions (erroneous or otherwise) as Ada does, e.g., degree of > acceptance, availability of developers, etc. At least python has gobs (a technical term) of books available in the local book store and seems to be getting plenty of attention from the media and academia. Then consider Fortran 95. There are virtually no advertisements, no magazine articles (maybe one / year in Dr Dobbs), no books stocked in your local book store, etc. yet there are still somewhere between 5 and 10 commercial developers for x86 plugging away successfully. There are at least 4 fortran.net products in development for x86. Virtually every hardware vendor provides a Fortran compiler (Intel just bought Visual Fortran and is now merging with its own compiler (more or less)). It is still a niche language but has dramatically improved its general purpose utility and isn't likely to die anytime soon. It does this largely following the slow, cumbersome ANSI/ISO standard development process. I only wish REXX would get on the ball. > However, Python does > have considerable "traction" and "energy" in terms of its direction > and the process for moving new features into its standard "core." > While ISO adoption isn't part of the python agenda, the Python > Evaluation Process (PEP) seems to fill the bill that your comments > suggest. A specific PEP garners no shortage of posts from the > devoted. Wide-spread use including version updates most often lead to > incorporation into the standard distribution. Its the latter that > seems to be the threshold that needs to be achieved for widespread > community acceptance. WRT Ada and the ISO process, this would seem to > be, at least, one logical jumping off point since many of the > "important" battles would likely have already been fought and > resolved. Information on the PEP process is available from > www.python.org. Hopefully you wouldn't need to reinvent the wheel > (too much) in order to adopt a process that would work for your > community instead of the other way around - like the python language > itself, this is something that borders on religious dogma in the > python community. Hopefully this is of some use. > cheers, > Bill -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:45 ` Gary Scott @ 2002-04-18 20:12 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-18 20:12 UTC (permalink / raw) Gary Scott wrote: > Bill Tate wrote: > >>Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message >> >>>>If we had some community concensus that one or more libraries was what we >>>> >>[snip] >> >>>>wanted for doing job X, all you'd have to do is persuade the vendors to >>>>distribute it with their compilers and it instantly becomes part of Ada even >>>>if it isn't part of the "standard". >>>> >>>I dont think that we need the vendors this mutch, most of the popular >>>open source software is distributed without them (thanks to sites >>>as sourceforge etc..), >>> >>>In my mind the idea of a public ada process is showing up: >>> >>>- There is a job to be done and i have some solution for it. Propose >>> the solution to the community (who is this, i gues comp.lang.ada?) >>> >>>- If sufficient interest has been raised, form a working group >>> for this topic and provide an implemenation for public use. >>> >>>- Proceed until wide acceptance >>> >>>- Propose to ISO >>> >>> >>Michael, >>I would like to echo some of your points from an outsider's >>perspective. As someone who spends most of his time on >>comp.lang.python, Python suffers from some of the same "kinds" of >>perceptions (erroneous or otherwise) as Ada does, e.g., degree of >>acceptance, availability of developers, etc. >> > > At least python has gobs (a technical term) of books available in the > local book store and seems to be getting plenty of attention from the > media and academia. Then consider Fortran 95. Just write an Article how wunderfull Ada is, how easy to use etc... I know it is difficult to publish this but without try no failure! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-18 14:04 ` Bill Tate 2002-04-18 14:45 ` Gary Scott @ 2002-04-18 20:09 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-18 20:09 UTC (permalink / raw) Bill Tate wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message > >>>If we had some community concensus that one or more libraries was what we >>> > [snip] > >>>wanted for doing job X, all you'd have to do is persuade the vendors to >>>distribute it with their compilers and it instantly becomes part of Ada even >>>if it isn't part of the "standard". >>> >>I dont think that we need the vendors this mutch, most of the popular >>open source software is distributed without them (thanks to sites >>as sourceforge etc..), >> >>In my mind the idea of a public ada process is showing up: >> >>- There is a job to be done and i have some solution for it. Propose >> the solution to the community (who is this, i gues comp.lang.ada?) >> >>- If sufficient interest has been raised, form a working group >> for this topic and provide an implemenation for public use. >> >>- Proceed until wide acceptance >> >>- Propose to ISO >> >> > Michael, > I would like to echo some of your points from an outsider's > perspective. As someone who spends most of his time on > comp.lang.python, Python suffers from some of the same "kinds" of > perceptions (erroneous or otherwise) as Ada does, e.g., degree of > acceptance, availability of developers, etc. However, Python does > have considerable "traction" and "energy" in terms of its direction > and the process for moving new features into its standard "core." > While ISO adoption isn't part of the python agenda, the Python > Evaluation Process (PEP) seems to fill the bill that your comments > suggest. A specific PEP garners no shortage of posts from the > devoted. Wide-spread use including version updates most often lead to > incorporation into the standard distribution. Its the latter that > seems to be the threshold that needs to be achieved for widespread > community acceptance. WRT Ada and the ISO process, this would seem to > be, at least, one logical jumping off point since many of the > "important" battles would likely have already been fought and > resolved. Information on the PEP process is available from > www.python.org. Hopefully you wouldn't need to reinvent the wheel > (too much) in order to adopt a process that would work for your > community instead of the other way around - like the python language > itself, this is something that borders on religious dogma in the > python community. Hopefully this is of some use. > cheers, > Bill Thanks i like to documentation of the PEP process. Maybe we can reused some of it! Michael > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan ` (3 preceding siblings ...) 2002-04-13 0:23 ` Michael Erdmann @ 2002-04-13 0:59 ` Robert Dewar 2002-04-13 7:38 ` Michael Erdmann 4 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-13 0:59 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<dfc3a9eb805c5538c8b1d19eb9c9aff3.48257@mygate.mailgate.org>... > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > "We don't need no stinking programming community inputs > to the language!" Well I don't often visit these kinds of thread, but occasionally it makes a good laugh, and any post from KPD is sure to be an interesting case of rewriting history :-) :-) :-) "don't tell me no stinking facts about Ada or its history, I prefer to make them up!" ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Rant! (was) Development process in the Ada community 2002-04-13 0:59 ` Robert Dewar @ 2002-04-13 7:38 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-13 7:38 UTC (permalink / raw) Robert Dewar wrote: > "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<dfc3a9eb805c5538c8b1d19eb9c9aff3.48257@mygate.mailgate.org>... > > >>"Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: >>"We don't need no stinking programming community inputs >>to the language!" >> > > Well I don't often visit these kinds of thread, but > occasionally it makes a good laugh, and any post from > KPD is sure to be an interesting case of rewriting > history :-) :-) :-) > I am sorry, but i did not write this. I gues this might be a cust&paste error!!!! Michael Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann 2002-04-10 23:28 ` Randy Brukardt 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan @ 2002-04-13 7:46 ` Michael Erdmann 2002-04-13 13:24 ` Larry Kilgallen 2002-04-14 8:51 ` Michael Erdmann ` (3 subsequent siblings) 6 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-13 7:46 UTC (permalink / raw) Before the whole thread gets completly out of control, i like to get your ideas how such a "fast" process could be established? Such a process could have the following key attributes: - Public, all working results should be freely available - Open to the open source community and companies if they comply to open source rules. - Other key attributes ....? Regards M.Erdmann Michael Erdmann wrote: > Hallo all, > > i am wondering how standards are eveloving in the Ada community. > In the Java Community there is a process called Java Community > Process (JCP, http://www.jcp.org/) > > Is there something comparabel in the Ada communitiy? I gues > if there would be something like this there would be more > dynamic in the Ada 95 community. > > > Regards > M.Erdmann > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 7:46 ` Michael Erdmann @ 2002-04-13 13:24 ` Larry Kilgallen 2002-04-13 16:01 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-13 13:24 UTC (permalink / raw) In article <3CB7E244.4090105@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > Before the whole thread gets completly out of control, > i like to get your ideas how such a "fast" process could > be established? > > Such a process could have the following key attributes: > > - Public, all working results should be freely available > - Open to the open source community and companies if they > comply to open source rules. If membership on the deliberative body is based on criteria other than the contribution one might make to the effort, such as the criterion of being some "open source" entity, that would be a mistake. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 13:24 ` Larry Kilgallen @ 2002-04-13 16:01 ` Michael Erdmann 2002-04-13 17:18 ` Larry Kilgallen 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-13 16:01 UTC (permalink / raw) Larry Kilgallen wrote: > In article <3CB7E244.4090105@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > >>Before the whole thread gets completly out of control, >>i like to get your ideas how such a "fast" process could >>be established? >> >>Such a process could have the following key attributes: >> >>- Public, all working results should be freely available >>- Open to the open source community and companies if they >> comply to open source rules. >> > > If membership on the deliberative body is based on criteria > other than the contribution one might make to the effort, > such as the criterion of being some "open source" entity, > that would be a mistake. I am not sure if i am unerstanding correctly, but what i like to ensure, that the standards, components etc are available under open source licenses. I dont like to have the situation that part of the output of such a group is public and the other one not. May be a better term would be: - Open to everybody who accepts the fact that his working results will be put unter open source license. Regards M.Erdmann > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 16:01 ` Michael Erdmann @ 2002-04-13 17:18 ` Larry Kilgallen 2002-04-13 19:02 ` Michael Erdmann 2002-04-13 22:24 ` Kent Paul Dolan 0 siblings, 2 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-13 17:18 UTC (permalink / raw) In article <3CB85658.5050406@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > Larry Kilgallen wrote: >> If membership on the deliberative body is based on criteria >> other than the contribution one might make to the effort, >> such as the criterion of being some "open source" entity, >> that would be a mistake. > > I am not sure if i am unerstanding correctly, but what i > like to ensure, that the standards, components etc are > available under open source licenses. I dont like to have Is it ISO document charges that you are complaining about ? > the situation that part of the output of such a group > is public and the other one not. Aside from that, what output is not public ? > May be a better term would be: > > - Open to everybody who accepts the fact that his working > results will be put unter open source license. So you would admit to the deliberative body anyone who agreed to that, no matter how otherwise unqualified they might be. That seems quite wrong to me. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 17:18 ` Larry Kilgallen @ 2002-04-13 19:02 ` Michael Erdmann 2002-04-13 21:34 ` Larry Kilgallen 2002-04-13 22:24 ` Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-13 19:02 UTC (permalink / raw) Larry Kilgallen wrote: > In article <3CB85658.5050406@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > >>Larry Kilgallen wrote: >> > >>>If membership on the deliberative body is based on criteria >>>other than the contribution one might make to the effort, >>>such as the criterion of being some "open source" entity, >>>that would be a mistake. >>> >>I am not sure if i am unerstanding correctly, but what i >>like to ensure, that the standards, components etc are >>available under open source licenses. I dont like to have >> > > Is it ISO document charges that you are complaining about ? Yes, this is one face of the problem. > > >>the situation that part of the output of such a group >>is public and the other one not. >> > > Aside from that, what output is not public ? When is is not available on the net in a server from where you can download the information you need. Additionaly the term public does not cover only the availability but also the licensing. > > >>May be a better term would be: >> >>- Open to everybody who accepts the fact that his working >> results will be put unter open source license. >> > > So you would admit to the deliberative body anyone who > agreed to that, no matter how otherwise unqualified > they might be. That seems quite wrong to me. > What means unqualified? This is the problem i have with the JPC. There an executive board selects experts. The experts will be choosen based in the priorities of the executive board which is founded by SUN (i think). But from my experiences if you start serious work unqualified members are droping out of the group quite fast because they are not able to follow any more and they are loosing there interest. But you are right, i dont have any universal answer for this issue. Anyhow something like this is already exisiting http://www.ada-auth.org Maybe this orginisation could be reshaped slightly to create a larger momentum on the Ada 95 community. What do you think?? Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 19:02 ` Michael Erdmann @ 2002-04-13 21:34 ` Larry Kilgallen 2002-04-14 8:28 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-13 21:34 UTC (permalink / raw) In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > Larry Kilgallen wrote: >> Is it ISO document charges that you are complaining about ? > > Yes, this is one face of the problem. Personally I am happy to pay ISO document charges, but that is not required for the Ada Reference Manual. >>>the situation that part of the output of such a group >>>is public and the other one not. >>> >> >> Aside from that, what output is not public ? > > When is is not available on the net in a server from where > you can download the information you need. Although that definition is not universally agreed, how do you feel the Ada specification does not match that definition ? Have you looked at http://www.adapower.com ? > Additionaly the term public does not cover only the > availability but also the licensing. What aspect of the Ada documentation involves licensing ? >>>May be a better term would be: >>> >>>- Open to everybody who accepts the fact that his working >>> results will be put unter open source license. >>> >> >> So you would admit to the deliberative body anyone who >> agreed to that, no matter how otherwise unqualified >> they might be. That seems quite wrong to me. >> > What means unqualified? This is the problem i have with > the JPC. There an executive board selects experts. The > experts will be choosen based in the priorities of the > executive board which is founded by SUN (i think). I have not heard of such a problem with Ada. > Anyhow something like this is already exisiting > > http://www.ada-auth.org > > Maybe this orginisation could be reshaped slightly > to create a larger momentum on the Ada 95 community. > > What do you think?? I don't think there are any changes that can be made in that area to create a larger momentum in the Ada community. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 21:34 ` Larry Kilgallen @ 2002-04-14 8:28 ` Michael Erdmann 2002-04-14 16:00 ` Larry Kilgallen 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 8:28 UTC (permalink / raw) Larry Kilgallen wrote: > In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > >>Larry Kilgallen wrote: >> > >>>Is it ISO document charges that you are complaining about ? >>> >>Yes, this is one face of the problem. >> > > Personally I am happy to pay ISO document charges, > but that is not required for the Ada Reference Manual. Who is sponsering this, US Goverment? >>>>the situation that part of the output of such a group >>>>is public and the other one not. >>>> >>>> >>>Aside from that, what output is not public ? >>> >>When is is not available on the net in a server from where >>you can download the information you need. >> > > Although that definition is not universally agreed, > how do you feel the Ada specification does not match > that definition ? Have you looked at http://www.adapower.com ? I am not talking about the currently available Ada RM which i realy like. But for example what interface is Ada providing for data base access? All MS-Languages: ADO Java : JDBC, JDO Ada ? Ada is providing nothing, therefor i am forced to reuse design concepts from ADO or JDBC in order to limit the development effort, which already brings me into licensing problem (specially ADO) because these "defacto standards" are owned by companies (at least as far as i know). These are the Situations i am afraid of, with the consequence every result of such an organization should be clearly liecensed as open source. I have to admid i am not the specialist in licensing but i hope you got my idea! > > >>Additionaly the term public does not cover only the >>availability but also the licensing. >> > > What aspect of the Ada documentation involves licensing ? > > >>>>May be a better term would be: >>>> >>>>- Open to everybody who accepts the fact that his working >>>> results will be put unter open source license. >>>> >>>> >>>So you would admit to the deliberative body anyone who >>>agreed to that, no matter how otherwise unqualified >>>they might be. That seems quite wrong to me. >>> >>> >>What means unqualified? This is the problem i have with >>the JPC. There an executive board selects experts. The >>experts will be choosen based in the priorities of the >>executive board which is founded by SUN (i think). >> > > I have not heard of such a problem with Ada. But who is paying the peoples in the ISO Working groups? I guess these are the interested companies. From my past experiences with ETSI and ITU, you get only progress if the involved parties are interested to launch something new within a given time frame. After this has been achieved, the behaviour in the working groups changes drasticaly from supporting progress towards the attitude of protecting what has been achived. The motto then is "...everything which does not hurt my product is ok, but i will put no additional effort to change it unless my market requires it...". So i am not so sure if you don't have this problem already. I have read one of your discussions about the debug pragma, which reminded me imediatly about my earlier times with ETSI. >>Anyhow something like this is already exisiting >> >>http://www.ada-auth.org >> >>Maybe this orginisation could be reshaped slightly >>to create a larger momentum on the Ada 95 community. >> >>What do you think?? >> > > I don't think there are any changes that can be made in > that area to create a larger momentum in the Ada community. > I think, they could promote ther interface towards the public (Ada 95 community) by asking proactivly the Ada 95 community for comments on the topics which are of high interest. This would at least ensure that there activities are more in line with the market requirements are. An if they would be able to add additional Annexes to the RM relating to these hot Topics this would make the difference! Maybe i will try to contact the WG9 ARG chairman (i have not found out yet who it is) regarding this issue. Because the current situation in the Ada commmunity is like in the COBOL community some years a go (realy rediculess), but at least C OBOL was realy needed because of its large code base. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 8:28 ` Michael Erdmann @ 2002-04-14 16:00 ` Larry Kilgallen 0 siblings, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-14 16:00 UTC (permalink / raw) In article <3CB93DAD.3030007@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: > Larry Kilgallen wrote: >> In article <3CB880AF.5080407@snafu.de>, Michael Erdmann <Michael.Erdmann@snafu.de> writes: >> >>>Larry Kilgallen wrote: >>> >> >>>>Is it ISO document charges that you are complaining about ? >>>> >>>Yes, this is one face of the problem. >>> >> >> Personally I am happy to pay ISO document charges, >> but that is not required for the Ada Reference Manual. > Who is sponsering this, US Goverment? Who is sponsoring what ? You can find the Ada Reference Manual at http://www.adapower.com . ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 17:18 ` Larry Kilgallen 2002-04-13 19:02 ` Michael Erdmann @ 2002-04-13 22:24 ` Kent Paul Dolan 2002-04-14 0:00 ` Larry Kilgallen 2002-04-14 3:04 ` Gary Scott 1 sibling, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-13 22:24 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote: > Is it ISO document charges that you are complaining about ? They are certainly worth a complaint. The daunting cost of paper standards, and the standards process funding mechanism that prevents most of the standards from becoming freely downloadable softcopy, arguably are active deterents to widespread use, or even awareness, of standards. xanthian. Contrast with the Java API standards/docs from Sun, the W3C Cascading Style sheets standards, and the W3C HTML4.1standards, all of which spin on my laptop and are in daily use by me, just because I could afford them and download them. These are _immensely_ successful standards. I helped _write_ three other, high-cost, hardcopy-only standards, yet cannot afford, either by price or by carrying capacity, to own, use, or evangelize any of them. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 22:24 ` Kent Paul Dolan @ 2002-04-14 0:00 ` Larry Kilgallen 2002-04-15 3:03 ` Kent Paul Dolan 2002-04-14 3:04 ` Gary Scott 1 sibling, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-14 0:00 UTC (permalink / raw) In article <ee2c9a2989167c1c5ce5b90239a3d41a.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote: > >> Is it ISO document charges that you are complaining about ? > > They are certainly worth a complaint. The daunting cost of paper > standards, and the standards process funding mechanism that prevents > most of the standards from becoming freely downloadable softcopy, > arguably are active deterents to widespread use, or even awareness, of > standards. Again, I ask, what does this have to do with Ada95 ? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 0:00 ` Larry Kilgallen @ 2002-04-15 3:03 ` Kent Paul Dolan 0 siblings, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-15 3:03 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote: > Again, I ask, what does this have to do with Ada95 ? Nothing, I was replying only to the one line of yours which I quoted. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-13 22:24 ` Kent Paul Dolan 2002-04-14 0:00 ` Larry Kilgallen @ 2002-04-14 3:04 ` Gary Scott 2002-04-15 3:00 ` Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Gary Scott @ 2002-04-14 3:04 UTC (permalink / raw) Kent Paul Dolan wrote: > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote: > > > Is it ISO document charges that you are complaining about ? > > They are certainly worth a complaint. The daunting cost of paper > standards, and the standards process funding mechanism that prevents > most of the standards from becoming freely downloadable softcopy, > arguably are active deterents to widespread use, or even awareness, of > standards. > > xanthian. > > Contrast with the Java API standards/docs from Sun, the W3C Cascading > Style sheets standards, and the W3C HTML4.1standards, all of which spin > on my laptop and are in daily use by me, just because I could afford > them and download them. These are _immensely_ successful standards. I > helped _write_ three other, high-cost, hardcopy-only standards, yet > cannot afford, either by price or by carrying capacity, to own, use, or > evangelize any of them. I wish someone would resurrect GKS/CGM. I love those. It needs to be modernized a little, but I like the clear clean terminology and design. There are only a few things that I prefer about IBM's GDDM over GKS. > > -- > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 3:04 ` Gary Scott @ 2002-04-15 3:00 ` Kent Paul Dolan 2002-04-16 2:37 ` Gary Scott 0 siblings, 1 reply; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-15 3:00 UTC (permalink / raw) "Gary Scott" <scottg@flash.net> wrote: > I wish someone would resurrect GKS/CGM. I love those. It needs to be > modernized a little, but I like the clear clean terminology and design. > There are only a few things that I prefer about IBM's GDDM over GKS. Why bless your heart! There was a half-hearted GKS implementation or binding, I'm not sure which, for Ada 83, I believe in AdaSAGE; if it had been completed to handle all the interactive issues, GKS would probably be one of a working set of graphics packages highly used by the Ada community. I cannot really blame the implementors, though, when MS-Windows is the dominant platform and is infamous (at least with me, from harsh experience writing shrink-wrap software some time ago) for having few or no device interface standards. Doing a full up GKS when there is nothing standard to which it can interface is really tough. That is what the VDI (virtual device interface) was supposed to accomplish, but for all of me, that standard seems to have disappeared without a trace. The closest thing that exists today to a virtualized device interface is embedded in the Java Virtual Machine, and I'm too new to Java to know whether it really caters for all the nastiness of printing and all the various pointing and clicking devices. xanthian. On the bright side, a _lot_ of the interface devices that were popular back in the GKS days seem to have become deprecated by time; I don't see many analog to digital devices for real valued input in my limited viewport to the world, though there are a few 3D mice floating about of which I'm vbaguely aware. As to an upgraded GKS, the standards committee is always open to new membership. This little tidbit will prove interesting: Binding Status: The Ada binding to GKS (GKS/Ada) is an ANSI/ISO standard. Documentation: The ANSI GKS/Ada Binding is published by ANSI as document #X3.124.3. The International Standard is published as ISO 8651-3. To inquire about availability of either standard, contact: ANSI, 1430 Broadway, New York, NY 10018; tel (sales): 212/354-3300; general: 212/354-3300 For more information, contact: Richard F. Puk, Chairman, X3H3.4, Puk Consulting Services, 7644 Cortina Court, Carlsbad, CA 92009-8206; tel: 619/753-9027; fax: same as phone; e-mail: rpuk@ajpo.sei.cmu.edu. Found here: http://archive.adaic.com/tools/bindings/GKS/GKS-bindings.txt I have no idea whether Dick Puk is still X3H3 Chairman, and I was baffled by the ANSI main site that it doesn't seem to index its technical committees. [ I once implemented full bells-and-whistles 3D graphics on a stroke-drawn machine from a SIGGRAPH article by Dick Puk; he and I go back a couple of decades. Neither would recognize the other by now. ] -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 3:00 ` Kent Paul Dolan @ 2002-04-16 2:37 ` Gary Scott 0 siblings, 0 replies; 425+ messages in thread From: Gary Scott @ 2002-04-16 2:37 UTC (permalink / raw) Kent Paul Dolan wrote: > > "Gary Scott" <scottg@flash.net> wrote: > <snip> > As to an upgraded GKS, the standards committee is always open to new > membership. If I were actually qualified to join one, I'd probably join J3. But since I'm not, I'll just stand on the sidelines and criticize. > > This little tidbit will prove interesting: > > Binding Status: The Ada binding to GKS (GKS/Ada) is an ANSI/ISO > standard. > > Documentation: The ANSI GKS/Ada Binding is published by ANSI as document > #X3.124.3. The International Standard is published as ISO 8651-3. To > inquire about availability of either standard, contact: ANSI, 1430 > Broadway, New York, > NY 10018; tel (sales): 212/354-3300; general: 212/354-3300 I have copies of everything except VDI (didn't know about it). At one time, I was thinking of writing a binding subset for windows that was compliant, for my own use. The only product I was aware of at the time was by Ematek (bought a product called GSS I think) but it was way too expensive. I don't think they offer it any more. Anyway, I do tend to pattern most of the libraries I design somewhat on the general design of GKS and GDDM. I try to design them more or less language independent as well, but at least such that it is trivial to create bindings to other languages. GDDM does that by using a generic binary RPC-like interface. -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann ` (2 preceding siblings ...) 2002-04-13 7:46 ` Michael Erdmann @ 2002-04-14 8:51 ` Michael Erdmann 2002-04-14 9:52 ` Georg Bauhaus 2002-04-14 20:41 ` tmoran 2002-04-15 16:29 ` Michael Erdmann ` (2 subsequent siblings) 6 siblings, 2 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 8:51 UTC (permalink / raw) Michael Erdmann wrote: > Hallo all, > > i am wondering how standards are eveloving in the Ada community. > In the Java Community there is a process called Java Community > Process (JCP, http://www.jcp.org/) > > Is there something comparabel in the Ada communitiy? I gues > if there would be something like this there would be more > dynamic in the Ada 95 community. > During the Thread my main line of reasoning has got completly out of scope. You will find in the Ada 95 communit a lot of open source software solutions covering the following topics: GUI -> GtkAda, Claw etc. Networking -> adasockets http -> AWS ....XML,SOAP + 1 Million implemantions of lists and container (including mine). These components have been implemented because they are needed. Since they are not standarized the consequence that you will find a lot of derivates of these packages in the net (specially lists and containers are a nice example) because everybody reinvents the stuff. And i am wondering if there could be a processed established which brings these things back into the standard in order to avoid the reinvention of state of the art components. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 8:51 ` Michael Erdmann @ 2002-04-14 9:52 ` Georg Bauhaus 2002-04-14 10:37 ` Ingo Marks 2002-04-14 11:50 ` Michael Erdmann 2002-04-14 20:41 ` tmoran 1 sibling, 2 replies; 425+ messages in thread From: Georg Bauhaus @ 2002-04-14 9:52 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> wrote: : And i am wondering if there could be a processed : established which brings these things back into the : standard in order to avoid the reinvention of : state of the art components. Monoism isn't compatible with reality I think, starting at two sexes. If you have two well founded container libraries, with apparently significant theoretical knowledge visible in their design and accompanying talk, they may still have their relative merits. One uses inheritance, the other doesn't, how do you add (passive) persistency to the other? One is small and easy to use, the other is big and offers more containers and algorithms. However, why should the one not steal (or refuse) ideas from the other? This is not reinventing. If program users want different GUIs, this creates an opportunity to have more people work on the different implementations, and have users hand out the rewards, that is payment. They have a right to require this to be done. There were times when there were people using very different computers on their desktops, and it worked at the time, I'm sure you know. Now most PC users have one type of processor built into essentially one type of computer. Good or bad? (Incidentally, one type of compiler (Visual *), together with one great library/components on one VM might bring us one type of fpt precision, which is not the one lurking in most processors. (This is a guess.)) Java is presented to show how to do it, but: There is no way to have a method indicate success or failure other than boolean return or an exception. That is, the famous Java library offers no simple value wrapper with a set method, except the one in java.text to store parse positions. No in/out mechanism in that library. Georg Bauhaus, currently creating views of data for different media, using diffenrent libraries, because people want that. They also pay us. It's as entertainging as knowing there are fish, birds, wooly animals, snakes, dogs, ... ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 9:52 ` Georg Bauhaus @ 2002-04-14 10:37 ` Ingo Marks 2002-04-14 11:50 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-14 10:37 UTC (permalink / raw) Georg Bauhaus wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> wrote: > > : And i am wondering if there could be a processed > : established which brings these things back into the > : standard in order to avoid the reinvention of > : state of the art components. > > Monoism isn't compatible with reality I think, starting > ... > If program users want different GUIs, this creates > an opportunity to have more people work on the different > implementations, and have users hand out the rewards, > that is payment. They have a right to require this to be > done. > ... Michael didn't say the he wants to have universal monolithic libraries and throw all other developments away. I agree with Michael that it's better for the Ada community to work together to develop good universal solutions which fit the needs of many. That doesn't mean that these developments fit the needs of everyone and every application. See Mono (and DotGNU): They develop a new library standard for GTK/Gnome and don't pay much attention if these standards are compatible with .NET in the future (due to possible patent restrictions). They just see the power of standard libraries which help them to develop new applications with less effort in much shorter time than before. That doesn't mean that you cannot continue to write GTK/Gnome applications with the old libraries. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 9:52 ` Georg Bauhaus 2002-04-14 10:37 ` Ingo Marks @ 2002-04-14 11:50 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-14 11:50 UTC (permalink / raw) Georg Bauhaus wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> wrote: > > : And i am wondering if there could be a processed > : established which brings these things back into the > : standard in order to avoid the reinvention of > : state of the art components. > > Monoism isn't compatible with reality I think, starting You are right, but i think you have to admind, that the discussion about the best linked list implementation is simply not state of the art any more. There should be a standard list and container concept available for Ada. Thinking about such components is a wate of time because as you say theory and implementation are exisiting. It should find its into the Ada 95 standard. I think this applies also to other more or less stable areas like sockets, http protocol etc. I have to admid GUI's are a bad example because they are extremly dependant on the perception of a community. For example compare Windows/Gtk and the GUI of squeck. They are complelty different and everybody is happy with it. What i am targeting for is to get some of the established technologies into the Ada standard and at the same time to establish a process which ensures that in the future other stable interfaces will be added to the standard. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 8:51 ` Michael Erdmann 2002-04-14 9:52 ` Georg Bauhaus @ 2002-04-14 20:41 ` tmoran 2002-04-15 14:45 ` Ted Dennison ` (2 more replies) 1 sibling, 3 replies; 425+ messages in thread From: tmoran @ 2002-04-14 20:41 UTC (permalink / raw) > You will find in the Ada 95 communit a lot of open > source software solutions covering the following topics: > ....XML,SOAP + 1 Million implemantions of lists and container Why is it that the available solutions are a mile wide but an inch deep? Everybody wants to build an alternative to X, but nobody wants to build on top of X. What are the rewards/difficulties of building a new alternative to X? What are the rewards/difficulties of building something more complex that -uses- X? Apparently the latter is worse. As Randy Brukardt noted the other day, the original idea for Claw "was to create a de facto standard, make a subset freely available, and eventually put the binding into the public domain to be a standard." But it didn't happen. Recently someone complained that Claw didn't currently support several features he needs. Nobody, to my knowledge, has added support for X to Claw, but multiple people have created alternative Windows bindings, none of which has become a standard, and none of which supports the features that writer needed. So he plans to use C++. The same for "a lot of open source software solutions covering ..." Given all the time in the world, it's a fine thing to "let 100 flowers bloom" and explore all the alternative ways of doing X. That does not get you beyond X, however. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 20:41 ` tmoran @ 2002-04-15 14:45 ` Ted Dennison 2002-04-15 15:59 ` Kent Paul Dolan ` (3 more replies) 2002-04-15 17:19 ` Marin David Condic 2002-04-16 8:29 ` Georg Bauhaus 2 siblings, 4 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-15 14:45 UTC (permalink / raw) tmoran@acm.org wrote in message news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>... > As Randy Brukardt noted the other day, the original idea for Claw "was to > create a de facto standard, make a subset freely available, and eventually > put the binding into the public domain to be a standard." But it didn't > happen. Recently someone complained that Claw didn't currently support > several features he needs. Nobody, to my knowledge, has added support for > X to Claw, but multiple people have created alternative Windows bindings, > none of which has become a standard, and none of which supports the I would submit that this is because the "release it to the public domain" step was never followed through on. If they had done that first, instead of planning on doing it last, things might have been different. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 14:45 ` Ted Dennison @ 2002-04-15 15:59 ` Kent Paul Dolan 2002-04-15 19:45 ` Randy Brukardt ` (2 subsequent siblings) 3 siblings, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-15 15:59 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote: > I would submit that this is because the "release it to the public > domain" step was never followed through on. If they had done that > first, instead of planning on doing it last, things might have been > different. Indeed. The open source concept is built on trust, of which there isn't all that much around, and stuff needs to be "irrevocably" open source from the beginning for that trust to be given. I suppose that is one point in favor of the Gnu Public License. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 14:45 ` Ted Dennison 2002-04-15 15:59 ` Kent Paul Dolan @ 2002-04-15 19:45 ` Randy Brukardt 2002-04-17 16:29 ` Ted Dennison 2002-04-15 22:02 ` tmoran 2002-04-17 3:25 ` Richard Riehle 3 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-15 19:45 UTC (permalink / raw) Ted Dennison wrote in message <4519e058.0204150645.62003096@posting.google.com>... >tmoran@acm.org wrote in message news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>... >> As Randy Brukardt noted the other day, the original idea for Claw "was to >> create a de facto standard, make a subset freely available, and eventually >> put the binding into the public domain to be a standard." But it didn't >> happen. Recently someone complained that Claw didn't currently support >> several features he needs. Nobody, to my knowledge, has added support for >> X to Claw, but multiple people have created alternative Windows bindings, >> none of which has become a standard, and none of which supports the > >I would submit that this is because the "release it to the public >domain" step was never followed through on. If they had done that >first, instead of planning on doing it last, things might have been >different. Couldn't have done that, because it would have left us nothing to sell -- and thus we'd have been out of business in a hurry. (The ATIP-P seed money also required a product to sell back to the government to "recover" the investiment -- which couldn't have been done if there was no product). We needed the GUI builder to be reasonable before we could let go of the bindings. If we hadn't held onto it for the first couple of year, it would never have gotten to the stability point that it is now. However, it could have been released a couple of years ago, but by then it was fairly clear that there was little interest in that. Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 19:45 ` Randy Brukardt @ 2002-04-17 16:29 ` Ted Dennison 2002-04-17 22:30 ` Randy Brukardt 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-17 16:29 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubmbe6r24ii522@corp.supernews.com>... > Ted Dennison wrote in message > >I would submit that this is because the "release it to the public > >domain" step was never followed through on. If they had done that > >first, instead of planning on doing it last, things might have been > >different. > > Couldn't have done that, because it would have left us nothing to > sell -- and thus we'd have been out of business in a hurry. (The ATIP-P > seed money also required a product to sell back to the government to > "recover" the investiment -- which couldn't have been done if there was > no product). We needed the GUI builder to be reasonable before we could > let go of the bindings. Fair enough. You folks certianly know way more about staying afloat as an Ada vendor than I can pretend to. However, I think its fair to say that no Windows bindings can have any hope of becomming the "standard" Ada Windows bindings so long as they are kept proprietary to one vendor, no matter how wonderful they (bindings and/or vendor) may be. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 16:29 ` Ted Dennison @ 2002-04-17 22:30 ` Randy Brukardt 2002-04-21 5:56 ` David Botton 0 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-17 22:30 UTC (permalink / raw) Ted Dennison wrote in message <4519e058.0204170829.23915c65@posting.google.com>... >Fair enough. You folks certianly know way more about staying afloat as >an Ada vendor than I can pretend to. However, I think its fair to say >that no Windows bindings can have any hope of becomming the "standard" >Ada Windows bindings so long as they are kept proprietary to one >vendor, no matter how wonderful they (bindings and/or vendor) may be. Not really true. Remember something you said yesterday: > 1) It is distributed with every appropriate compiler (either by fiat or agreement). We did everything we could to make that happen. Indeed, the Claw Introductory version is distributed with Rational Apex for Windows, and Dave Wood was planning to do so with ObjectAda as well (but he left Aonix before it actually happened). It isn't really possible to include it with GNAT, unfortunately (we would have to GMGPL the Intro. version, which I won't do; I'd be more likely to use a FreeBSD license if we're going to give it up anyway). We negotiated with several vendors to include the full version, but we couldn't agree on a maintenance (support) price -- it had to be enough to be able to fix bugs and continue development, given no further license sales. (If we had succeeded with that, no one would need to buy it individually, because they would have it with the compiler. Thus, the support fees would be the only revenue, and that meant that they had to be fairly high. So it never made economic sense, I fear.) Randy Brukardt. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 22:30 ` Randy Brukardt @ 2002-04-21 5:56 ` David Botton 2002-04-21 7:13 ` tmoran 2002-04-21 11:02 ` Development process in the Ada community Adrian Hoe 0 siblings, 2 replies; 425+ messages in thread From: David Botton @ 2002-04-21 5:56 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:ubrtrt3lg3os74@corp.supernews.com... > So it never made economic sense, I fear. And thus the "old" non open source model killed off the possibility that CLAW would be the basis of a standard or be extended by the wider community of programmers..... or outlive its own developers.... Imagine if my development efforts would have been used to modify and extend CLAW instead of writing GWindows...... GWindows covers almost all areas of CLAW (some intentionally not covered) and is way beyond it in other areas (database to control bindings, ActiveX, etc.), CLAW would have been by now double its feature set and more and I likely would have already completed many of my long term goals. (For example, I only need about 6-8 months of full time work to complete, at least in 1.0 terms, my Delphi like environment for Ada.... Some day.... some how... eventually....) Economic sense can be made of this, but not in the traditional ways of thinking..... David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 5:56 ` David Botton @ 2002-04-21 7:13 ` tmoran 2002-04-21 21:14 ` David Botton 2002-04-21 11:02 ` Development process in the Ada community Adrian Hoe 1 sibling, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-21 7:13 UTC (permalink / raw) > Imagine if my development efforts would have been used to modify and extend > CLAW instead of writing GWindows...... I have, and I think it a great loss to the Ada community that you didn't. >GWindows covers almost all areas of CLAW (some intentionally not covered) >and is way beyond it in other areas (database to control bindings, ActiveX, David, it's good to see someone take pride in their product, but IMHO you exaggerate more than a bit. >CLAW would be the basis of a standard or be extended by the wider community >of programmers..... or outlive its own developers.... Is GWindows then the basis of some standard? Has it been extended by the wider community? Is it under as active development as Claw? As to outliving its developers, we'll have to leave that to others to see. ;) Tom Moran ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 7:13 ` tmoran @ 2002-04-21 21:14 ` David Botton 2002-04-22 21:46 ` Randy Brukardt 0 siblings, 1 reply; 425+ messages in thread From: David Botton @ 2002-04-21 21:14 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:QEtw8.3627$eg5.1828187369@newssvr14.news.prodigy.com... > > Imagine if my development efforts would have been used to modify and extend > > CLAW instead of writing GWindows...... > I have, and I think it a great loss to the Ada community that you didn't. Your lic. wasn't condusive to it..... I agree, sad. > >GWindows covers almost all areas of CLAW (some intentionally not covered) > >and is way beyond it in other areas (database to control bindings, ActiveX, > David, it's good to see someone take pride in their product, but IMHO > you exaggerate more than a bit. But less than a byte.... Note that I am not knocking your framework, I think it is a masterful work and only regret that it was not available under different lic. terms. These em' not fightin' words.... It just happens to be that I support certain areas CLAW doesn't and a few other areas I do support CLAW is a bit more thorough. If you had a better lic. you would of course be able to grab some code for GWindows and GNATCOM...... but oh well. > Is GWindows then the basis of some standard? In the same way the Java AWT and SWING is the basis of a standard ;-O > Has it been extended by > the wider community? Yes, there have been a number of additions (including entire features not just bug fixes!). The greatest complement in the world is that some one has extended your work and sent it back in for others to use. Their efforts are more knoble than mine! > Is it under as active development as Claw? Yes. I saddly have to take breaks here and there for extend amounts of time do to work load from the "other side", but my track record shows that I get more than a bit done in the days and months I manage to grab here and there (though they may be far apart....) :-) I am often envious that you have the opportunity to work full time in Ada and on your Ada based projects (in part perhaps do to your restrictive lic.), but in the long term I believe that my approach will pay off in a larger way (part of which concerns money, but certainly satisfaction comes not only in the financial arena). I am certainly already more satisified on a personal level than with any of what I have produced under traditional terms and licences (Although I do get a kick out of detecting a company is using software I wrote for their phone systems from my last gig). > As to > outliving its developers, we'll have to leave that to others to see. ;) Perhaps, but hopefully we will both be around for another 180 years to see others enjoy our work. Perhaps by then CLAW will well then be lic. with the GMGPL unless of course Ada takes over than GPL..... David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 21:14 ` David Botton @ 2002-04-22 21:46 ` Randy Brukardt 2002-04-23 4:47 ` GPL and the big picture (was Re: Development process in the Ada community) David Botton 0 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-22 21:46 UTC (permalink / raw) David Botton wrote in message ... > ><tmoran@acm.org> wrote in message >news:QEtw8.3627$eg5.1828187369@newssvr14.news.prodigy.com... >> > Imagine if my development efforts would have been used to modify and extend >> > CLAW instead of writing GWindows...... >> I have, and I think it a great loss to the Ada community that you didn't. > >Your lic. wasn't condusive to it..... I agree, sad. I don't buy it. You and I discussed Claw, including the licensing at the Washington SigAda (4 years ago!). I know I told you then that the long-term plan was to make Claw publically available. If you had simply asked before starting to work on an alternative, you would have reminded me that we needed to open up the license. And I'm sure we could have worked out an acceptable time-table for that. In any case, I have to wonder why you decided to build something from scratch rather than building on top of Windex, which already existed and had the appropriate license. My guess, is that you fell into the same trap that many of us do: "I can do better than that...". Such a waste of effort. >> >GWindows covers almost all areas of CLAW (some intentionally not covered) >> >and is way beyond it in other areas (database to control bindings, ActiveX, >> David, it's good to see someone take pride in their product, but IMHO >> you exaggerate more than a bit. > >But less than a byte.... Note that I am not knocking your framework, I think >it is a masterful work and only regret that it was not available under >different lic. terms. > >These em' not fightin' words.... It just happens to be that I support >certain areas CLAW doesn't and a few other areas I do support CLAW is a bit >more thorough. If you had a better lic. you would of course be able to grab >some code for GWindows and GNATCOM...... but oh well. What do you mean by this? Did you mean "grab some code *from* ..."? If that's what you mean, the answer is "possibly". The Claw tasking model makes it hard to use code in the bindings that wasn't designed for it. Luckily, that complexity doesn't extend to the user's code... > Perhaps, but hopefully we will both be around for another 180 years to see > others enjoy our work. Perhaps by then CLAW will well then be lic. with the > GMGPL unless of course Ada takes over than GPL..... You won't have to wait more than however long it takes to read cla today to see that.... Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* GPL and the big picture (was Re: Development process in the Ada community) 2002-04-22 21:46 ` Randy Brukardt @ 2002-04-23 4:47 ` David Botton 2002-04-23 5:11 ` David Botton 2002-04-24 19:52 ` Randy Brukardt 0 siblings, 2 replies; 425+ messages in thread From: David Botton @ 2002-04-23 4:47 UTC (permalink / raw) ----- Original Message ----- From: "Randy Brukardt" <randy@rrsoftware.com> > You and I discussed Claw, including the licensing at the Washington > SigAda (4 years ago!). > I know I told you then that the long-term plan > was to make Claw publically available. If you had simply asked before > starting to work on an alternative, you would have reminded me that we > needed to open up the license. And I'm sure we could have worked out an > acceptable time-table for that. I don't recall such a conversation, but that's ok. Action is louder than words, and you have certainly acted! > In any case, I have to wonder why you decided to build something from > scratch rather than building on top of Windex, which already existed and > had the appropriate license. My guess, is that you fell into the same > trap that many of us do: "I can do better than that...". Such a waste of > effort. GWindows took a different direction than both CLAW and Windex. It is easier to use (testimony of users with experience in all three frameworks) and like I said, offers many features not found elsewhere (I truly get the impression you don't know much about the framework - start with http://www.adapower.com/gwindows/GWindowsVsClaw.html then move on to the home page http://www.adapower.com/gwindows). I would hardly say the effort of creating GWindows was a waste (nor was it that big an effort, it is a labor of love ;-). I (and others) have written many programs with GWindows that are running in production environments today (those programs not always being Open Source). As with most of what I publish as GMGPL (as with many others actively developing GMGPL libraries), it is a means to an end. I make my living using my tools not per se building them (although I wish that was the case). The GMGPL is a tool to advocate Ada and having more than one GMGPL framework certainly has its P.R. plusses. You also only see a small part of the big picture. GWindows is part of the GNATCOM 2.0 design in order to support the creation and native Ada use of GUI ActiveX controls and a number of other COM/DCOM/ActiveX features. (There are a number of features in GWindows that are missing from CLAW needed for this along with the fact that CLAW's tasking model has many problems being use for this purpose). BTW, I know of at least two _major_ projects that used CLAW and GNATCOM together. GNATCOM itself is only part of a larger project (never named the blanket project itself...). Another component of that project that is in development and has taken some serious form is GNavi - The GNU Ada Visual IDE (There is a very old screen snap shot at http://www.adapower.com/gwindows/shots/gnavi_snap.jpg). There are other components in design stages that go with these components as well (Database related tools, Web Service tools, etc and far more - I certainly don't plan on spilling all the beans at this point in time :-). The basic CLAW is too far away from what I need to consider stopping development on GWindows, putting full force behind extending CLAW "basic" would be a trap that many fall in to, "cutting off your nose despite your face" :~) It would also truly be a waste just to catch CLAW basic up to CLAW full version when you have already written it (the first step before I can extend CLAW to GWindows functional level) Can you give a time table (if there is one) for the full version of CLAW to become GMGPL. Perhaps there is some future in merging with CLAW, but that is to be seen. I look forward to the day (I don't suspect it will be that long off) when your frustrations have vented and attacking my project will no longer be necessary for you and some clear thinking about the future possibilities shines forth. > What do you mean by this? Did you mean "grab some code *from* ..."? I was referring to the ability to incorporate GMGPL code in to CLAW from another project or vice versa. In a nut shell: I write in Ada because it is the better all around language, I write my frameworks and tools to make it possible to use Ada on my projects, I release my work as GMGPL to promote Ada usage. I've gotten the short end of the stick from Microsoft and Borland more than once, so I learned the hard way to believe in using (and creating) GPL lic. tools. (Although I prefer open development models, GPL does not always mean this...) Ada Core and other companies choosing the GPL to lic. their products will out live and prosper beyond the current MicroSoft Era of software development (they already are...) Making it these days (financially speaking) with the GPL requires the same skills that all true Entrepreneurs must have, broad vision and self discipline. Start thinking now about the new models of business that use open lic. schemes, for tomorrow it may just be too late. David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: GPL and the big picture (was Re: Development process in the Ada community) 2002-04-23 4:47 ` GPL and the big picture (was Re: Development process in the Ada community) David Botton @ 2002-04-23 5:11 ` David Botton 2002-04-24 19:52 ` Randy Brukardt 1 sibling, 0 replies; 425+ messages in thread From: David Botton @ 2002-04-23 5:11 UTC (permalink / raw) Just to make sure this is not misunderstood. I was expressing my joy at seeing that CLAW basic has gone GMGPL. David Botton "David Botton" <David@Botton.com> wrote in message news:uc9pspep4lmef2@corp.supernews.com... > Action is louder than words, and you have certainly acted! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: GPL and the big picture (was Re: Development process in the Ada community) 2002-04-23 4:47 ` GPL and the big picture (was Re: Development process in the Ada community) David Botton 2002-04-23 5:11 ` David Botton @ 2002-04-24 19:52 ` Randy Brukardt 1 sibling, 0 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-24 19:52 UTC (permalink / raw) David Botton wrote in message ... >----- Original Message ----- >From: "Randy Brukardt" <randy@rrsoftware.com> >> In any case, I have to wonder why you decided to build something from >> scratch rather than building on top of Windex, which already existed and >> had the appropriate license. My guess, is that you fell into the same >> trap that many of us do: "I can do better than that...". Such a waste of >> effort. > >GWindows took a different direction than both CLAW and Windex. (* Several pages >of the advantages of GWindows omitted *) I think you have made my point for me. It's pretty clear that you thought you could do better than Claw (and still do). I would argue that most of the differences between Claw and GWindows are just that: differences, not advantages. I thought that when I first read your overviews of GWindows (a long time ago...), and I still think that. Clearly, you don't know how to use Claw as well as I do (who does?). But I don't think a line-by-line rebuttal serves much a purpose here; it makes more sense to spend the time on something productive. >Can you give a time table (if there is one) for the full version of CLAW to >become GMGPL. Perhaps there is some future in merging with CLAW, but that is >to be seen. I haven't thought seriously about that recently. The Introductory version had a fairly similar license to the GPL anyway (less restrictive for non-commercial use, in fact), so that wasn't a large leap. The full Claw is a larger leap. Certainly, the next version of the Introductory version will include more stuff (suggestions of items to include are welcome), which will have the effect of bringing more of Claw under the GMGPL. Let's talk about this some more off-line, OK? >Making it these days (financially speaking) with the GPL requires the same >skills that all true Entrepreneurs must have, broad vision and self >discipline. Start thinking now about the new models of business that use >open lic. schemes, for tomorrow it may just be too late. I've been doing that for two years. So far, the only thing that seems to make sense is to convince Robert to hire me at ACT. :-) Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 5:56 ` David Botton 2002-04-21 7:13 ` tmoran @ 2002-04-21 11:02 ` Adrian Hoe 2002-04-21 21:21 ` David Botton 1 sibling, 1 reply; 425+ messages in thread From: Adrian Hoe @ 2002-04-21 11:02 UTC (permalink / raw) "David Botton" <David@Botton.com> wrote in message news:<uc4l4v8tett728@corp.supernews.com>... > "Randy Brukardt" <randy@rrsoftware.com> wrote in message > news:ubrtrt3lg3os74@corp.supernews.com... > > So it never made economic sense, I fear. > > And thus the "old" non open source model killed off the possibility that > CLAW would be the basis of a standard or be extended by the wider community > of programmers..... or outlive its own developers.... > > Imagine if my development efforts would have been used to modify and extend > CLAW instead of writing GWindows...... > > GWindows covers almost all areas of CLAW (some intentionally not covered) > and is way beyond it in other areas (database to control bindings, ActiveX, > etc.), CLAW would have been by now double its feature set and more and I > likely would have already completed many of my long term goals. (For > example, I only need about 6-8 months of full time work to complete, at > least in 1.0 terms, my Delphi like environment for Ada.... Some day.... some > how... eventually....) Yep, I am eager to see the tool arrives.. some day.. :) But then, there will be less fun writing Ada codes. All this interesting process will be subsituted by click, click, click and just click (like in Delphi right now). :( -- Adrian Hoe -- http://adrianhoe.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 11:02 ` Development process in the Ada community Adrian Hoe @ 2002-04-21 21:21 ` David Botton 0 siblings, 0 replies; 425+ messages in thread From: David Botton @ 2002-04-21 21:21 UTC (permalink / raw) The idea is that the tools free the developer up for more interesting and fun coding... David Botton "Adrian Hoe" <byhoe@greenlime.com> wrote in message news:9ff447f2.0204210302.5f706b6a@posting.google.com... > Yep, I am eager to see the tool arrives.. some day.. :) But then, > there will be less fun writing Ada codes. All this interesting process > will be subsituted by click, click, click and just click (like in > Delphi right now). :( ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 14:45 ` Ted Dennison 2002-04-15 15:59 ` Kent Paul Dolan 2002-04-15 19:45 ` Randy Brukardt @ 2002-04-15 22:02 ` tmoran 2002-04-17 16:55 ` Ted Dennison 2002-04-17 3:25 ` Richard Riehle 3 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-15 22:02 UTC (permalink / raw) > > X to Claw, but multiple people have created alternative Windows bindings, > > none of which has become a standard, and none of which supports the > > features that writer needed. >I would submit that this is because the "release it to the public >domain" step was never followed through on. If they had done that >first, instead of planning on doing it last, things might have been >different. And why then have people created, but not built on, multiple alternative "Open Source" Windows bindings, none of which has become a standard, and none of which supports the features that writer needed? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 22:02 ` tmoran @ 2002-04-17 16:55 ` Ted Dennison 2002-04-17 17:15 ` Stephen Leake 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-17 16:55 UTC (permalink / raw) tmoran@acm.org wrote in message news:<G5Iu8.3882$GN4.1981086988@newssvr21.news.prodigy.com>... > > > X to Claw, but multiple people have created alternative Windows bindings, > > > none of which has become a standard, and none of which supports the > > > features that writer needed. > >I would submit that this is because the "release it to the public > >domain" step was never followed through on. If they had done that > >first, instead of planning on doing it last, things might have been > >different. > And why then have people created, but not built on, multiple > alternative "Open Source" Windows bindings, none of which has become a > standard, and none of which supports the features that writer needed? I'm not too sure what you are referring to here. The ones I'm aware of are: o Claw - Nicely high-level, and compiler portable, but proprietary. o Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen, very low-level (think C in Ada). o GWindows - Free, high-Level, only works with Gnat, only realy supports GUI operations, not all of Win32. o Jewl - GPL (usable only in GPL-ed programs or ones that won't be distributed), *Too* High-level, Probably(?) only works with Gnat. I think the issues here are pretty obvious. The ideal would be something a bit like Claw, but free. Alternatively it would be a bit like GWindows, but with complete Win32 support and compiler-agnostic. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 16:55 ` Ted Dennison @ 2002-04-17 17:15 ` Stephen Leake 2002-04-17 18:01 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-17 17:15 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > > I'm not too sure what you are referring to here. The ones I'm aware of > are: > > o Claw - Nicely high-level, and compiler portable, but > proprietary. > o Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen, > very low-level (think C in Ada). > o GWindows - Free, high-Level, only works with Gnat, only realy > supports GUI operations, not all of Win32. > o Jewl - GPL (usable only in GPL-ed programs or ones that won't > be distributed), *Too* High-level, Probably(?) only works with Gnat. Windex : Open Source, unsupported, works with GNAT and maybe ObjectAda, reasonable subset of Win32. GtkAda : Open Source, supported by ACT, full GUI interface, portable to other windowing/operating system Windex "competes" directly with Claw and GWindows. I wrote it because Claw was not open source, and GWindows was not available. I'm not clear why David Botton wrote GWindows instead of extending Windex. They do have different designs under the hood. GtkAda also competes, but since it's strictly a GUI binding, not an OS binding, and it is platform independent, it's in a different class. Jewl could probably be written on top of any of these. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 17:15 ` Stephen Leake @ 2002-04-17 18:01 ` Marin David Condic 2002-04-18 19:22 ` Stephen Leake 2002-04-21 5:34 ` David Botton 2002-04-18 5:12 ` Eric G. Miller 2002-04-21 5:33 ` David Botton 2 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-17 18:01 UTC (permalink / raw) Lets see.. that's (onetwothreefour...) *six* different bindings to Windows - each with different features/capabilities, but probably a good deal of overlap. (Will we hear of more? Consider that a "binding to Windows" could/should include things like sockets and similar stuff, so maybe we've got to start rounding up the packages that do this as well...???) Sounds like a Department of Redundancy Department effort to me. :-) Kind of makes Tom's point, too. Probably, you really need to have Win32Ada (or similar) no matter what. This thin binding is needed just to keep up with whatever Microsoft comes out with next as the OS API, so that if it didn't get included in the more abstract API, the programmer still has access to it. (It was originally auto-generated, right? So if a new C interface comes out, it can easily be re-auto-generated? Sounds important to me...) But could CLAW be made to incorporate (in an abstract sense - not necessarily with an identical realization) whatever capabilities the others offer and provide a common platform for development? Probably, the hard part would be to define some sort of "portable" subset so it could work on Linux/Unix as well & cover features done by GtkAda. (Although it might be possible to map GtkAda's XML description of the GUI to a CLAW-equivalent implementation?) If you don't insist on portability, you've at least got A Good Start at a common Windows interface, right? Probably parts of it would constitute A Good Start at a common Ada utility library if the portable parts were identified. I think this is an indication of how we may tout Ada's reusability and portability, but we're not very good at exploiting it - because it wasn't invented here? Or because it costs money? Why? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:ud6wydz64.fsf@gsfc.nasa.gov... > dennison@telepath.com (Ted Dennison) writes: > > > > > I'm not too sure what you are referring to here. The ones I'm aware of > > are: > > > > o Claw - Nicely high-level, and compiler portable, but > > proprietary. > > o Win32Ada - Free, Comes with every Windows Ada95 compiler I've seen, > > very low-level (think C in Ada). > > o GWindows - Free, high-Level, only works with Gnat, only realy > > supports GUI operations, not all of Win32. > > o Jewl - GPL (usable only in GPL-ed programs or ones that won't > > be distributed), *Too* High-level, Probably(?) only works with Gnat. > > Windex : Open Source, unsupported, works with GNAT and maybe > ObjectAda, reasonable subset of Win32. > > GtkAda : Open Source, supported by ACT, full GUI interface, portable > to other windowing/operating system > > Windex "competes" directly with Claw and GWindows. I wrote it because > Claw was not open source, and GWindows was not available. I'm not > clear why David Botton wrote GWindows instead of extending Windex. > They do have different designs under the hood. > > GtkAda also competes, but since it's strictly a GUI binding, not an OS > binding, and it is platform independent, it's in a different class. > > Jewl could probably be written on top of any of these. > > -- > -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 18:01 ` Marin David Condic @ 2002-04-18 19:22 ` Stephen Leake 2002-04-21 5:35 ` David Botton 2002-04-21 5:34 ` David Botton 1 sibling, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-18 19:22 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Probably, you really need to have Win32Ada (or similar) no matter what. I don't think so. Certainly Windex is _not_ built on top of Win32Ada; I started to, but it was just too weird and C-like. I just imported the Win32 functions as needed, using Ada types for parameters directly when possible. > This thin binding is needed just to keep up with whatever Microsoft > comes out with next as the OS API, so that if it didn't get included > in the more abstract API, the programmer still has access to it. (It > was originally auto-generated, right? So if a new C interface comes > out, it can easily be re-auto-generated? Sounds important to me...) I don't think it is being updated; are there Win2000 and XP versions? > But could CLAW be made to incorporate (in an abstract sense - not > necessarily with an identical realization) whatever capabilities the > others offer and provide a common platform for development? With enough money for programmer time, it could. Except the main thing Windex offers over CLAW is the GMGPL license. Hmm. GWindows makes a start towards a "subscriber" model of event handling (but only a start). That is significantly different from Windex and CLAW, which use an "override" model. I don't think one windowing system can have both. Hmm; maybe it could; call the subscribers, then dispatch. GtkAda uses a "subscriber" model. Since it is not based on a langauge that supports dispatching and overriding, it probably can't do both. Although I could provide a subscribed handler that then dispatched. All kinds of weirdness is possible :). > Probably, the hard part would be to define some sort of "portable" > subset so it could work on Linux/Unix as well & cover features done > by GtkAda. I see no reason not to just use GtkAda. It needs some work, and it needs some tutorials (as you have pointed out before) but it easily does everything I need it to do, in many cases better than Windex does (which is why I'm switching to it). ACT is supporting it. The only thing I don't like about GtkAda at the moment is that it is possible to compile an incorrect program; you get run-time errors like "this handler has the wrong profile for this signal". Errors like that are caught at compile time in Windex. This is partly because of the subscriber model, but also because Gtk uses strings (rather than enumerals or tagged types) to identify signals. I think this can be fixed with an ASIS tool. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 19:22 ` Stephen Leake @ 2002-04-21 5:35 ` David Botton 0 siblings, 0 replies; 425+ messages in thread From: David Botton @ 2002-04-21 5:35 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:ur8lcvml9.fsf@gsfc.nasa.gov... > Hmm. GWindows makes a start towards a "subscriber" model of event > handling (but only a start). That is significantly different from > Windex and CLAW, which use an "override" model. I don't think one > windowing system can have both. Hmm; maybe it could; call the > subscribers, then dispatch. GWindows in fact offers both and it works out very nicely. GWindows strikes a good balance in its "subscriber" model of events by just basicly offering a simple call back registration mechanism removing most of the complexities of programming in that model. For more complex work the override model can be used to easily offer more. > I see no reason not to just use GtkAda. GtkAda is a nice solution for many problems, but if you are looking to be native to Win32, it doesn't cut the mustard. David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 18:01 ` Marin David Condic 2002-04-18 19:22 ` Stephen Leake @ 2002-04-21 5:34 ` David Botton 1 sibling, 0 replies; 425+ messages in thread From: David Botton @ 2002-04-21 5:34 UTC (permalink / raw) ----- Original Message ----- From: "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> > Lets see.. that's (onetwothreefour...) *six* different bindings to Windows - > each with different features/capabilities, but probably a good deal of > overlap. (Will we hear of more? Consider that a "binding to Windows" > could/should include things like sockets and similar stuff I disagree, if there are good Ada solutions already why bother. (In the case of sockets you have AdaSockets or GNAT.Sockets). Thus GWindows does not include support for Sockets or other aspects of Win32 already supported directly by Ada95 or GNAT. > Probably, you really need to have Win32Ada (or similar) no matter what. This > thin binding is needed just to keep up with whatever Microsoft comes out > with next as the OS API, so that if it didn't get included in the more > abstract API, the programmer still has access to it. (It was originally > auto-generated, right? So if a new C interface comes out, it can easily be > re-auto-generated? Sounds important to me...) Microsoft makes most updates to its platforms these days using COM APIs, so Win32Ada for those that insist on thin bindings is available and most everything else GNATCOM takes care of. David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 17:15 ` Stephen Leake 2002-04-17 18:01 ` Marin David Condic @ 2002-04-18 5:12 ` Eric G. Miller 2002-04-18 13:31 ` Marin David Condic 2002-04-21 5:33 ` David Botton 2 siblings, 1 reply; 425+ messages in thread From: Eric G. Miller @ 2002-04-18 5:12 UTC (permalink / raw) In <ud6wydz64.fsf@gsfc.nasa.gov>, Stephen Leake wrote: > GtkAda also competes, but since it's strictly a GUI binding, not an OS > binding, and it is platform independent, it's in a different class. Curious. What OS bindings do most people need/want? Gtk2 is certainly a bit more than just a GUI binding via GLIB (library of utility functions and data types), ATK (Accessibility Toolkit, think ADA), Pango (bi-directional text and font handling), and GdkPixBuf (image handling). Since GTK2.0 depends on all those libraries, if GtkAda provides bindings to them you'd get all the functionality "for free". Granted, I doubt most of these things have been well tested on other than *nix like environments (and I understand, not all functionality has been ported to Windows environs yet -- like it's IO channels [files, sockets, other?]). All of it licensed under GNU Library General Public License, so using it for proprietary software is okay. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 5:12 ` Eric G. Miller @ 2002-04-18 13:31 ` Marin David Condic 2002-04-19 2:50 ` Eric G. Miller 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-18 13:31 UTC (permalink / raw) "Eric G. Miller" <egm2@jps-nospam.net> wrote in message news:pan.2002.04.17.22.13.12.183692.16266@jps-nospam.net... > > to them you'd get all the functionality "for free". Granted, I doubt > most of these things have been well tested on other than *nix like > environments (and I understand, not all functionality has been ported > to Windows environs yet -- like it's IO channels [files, sockets, other?]). > So essentially you can port it to any system you like as long as that system is Unix? :-) If a toolset were to be included in Ada in some manner that was intended to interface to the OS, I would think it needs to be defined in such a way that it could be readily used with at minimum Unix, Windows, and Mac. If at all possible, you would want it to present an abstraction that could be implemented on any OS that supported the concepts. The "Least Common Denominator" criticism could be employed here, but I think it isn't entirely reasonable. One could say "For the standard interface, we support blah blah blah. If you need something more detailed and OS specific, you have a way to bind to the OS, but of course, you won't be portable..." MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 13:31 ` Marin David Condic @ 2002-04-19 2:50 ` Eric G. Miller 0 siblings, 0 replies; 425+ messages in thread From: Eric G. Miller @ 2002-04-19 2:50 UTC (permalink / raw) In <a9mhr1$sb1$1@nh.pace.co.uk>, Marin David Condic wrote: > "Eric G. Miller" <egm2@jps-nospam.net> wrote in message > news:pan.2002.04.17.22.13.12.183692.16266@jps-nospam.net... >> >> to them you'd get all the functionality "for free". Granted, I doubt >> most of these things have been well tested on other than *nix like >> environments (and I understand, not all functionality has been ported >> to Windows environs yet -- like it's IO channels [files, sockets, > other?]). >> > So essentially you can port it to any system you like as long as that system > is Unix? :-) If a toolset were to be included in Ada in some manner that was > intended to interface to the OS, I would think it needs to be defined in > such a way that it could be readily used with at minimum Unix, Windows, and > Mac. If at all possible, you would want it to present an abstraction that > could be implemented on any OS that supported the concepts. Most of the development is done on Linux systems. And since gtk2.0 is only recently stable, folks probably just haven't spent much time on the Windows port(s). There's no question the focus of gtk and related libraries is for *nix/X, but there's enough interest in Windows ports that it will probably be reality in the not too distant future (don't think anyone's attemping or wants to port to pre-MacOS X). I'm no authority on where GTK is at in its portability attempts, but it's clear from the API interfaces that they intend to port it as widely as possible (otherwise, why wouldn't they just use the POSIX interfaces for many of the functions?). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 17:15 ` Stephen Leake 2002-04-17 18:01 ` Marin David Condic 2002-04-18 5:12 ` Eric G. Miller @ 2002-04-21 5:33 ` David Botton 2 siblings, 0 replies; 425+ messages in thread From: David Botton @ 2002-04-21 5:33 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:ud6wydz64.fsf@gsfc.nasa.gov... > Windex "competes" directly with Claw and GWindows. I wrote it because > Claw was not open source, and GWindows was not available. I'm not > clear why David Botton wrote GWindows instead of extending Windex. > They do have different designs under the hood. GWindows has a number of fundamental differences in design (the most important to me is multiple event models) and implementation style (the complete lack of thin bindings as a starting point, ie. I prototype the needed Win32 functions with in each call in order to maximize the use of the Ada95 to C mappings). I've always wondered why you didn't take the time to update GWindows with some of the thicker parts of Windex ;-) There are only three thick bindings to Win32 (JEWL is a great teaching tool, but not practical nor intended to be used for professional development), GWindows, Windex and CLAW. A comparison (not updated recently) between GWindows and CLAW is available at http://www.adapower.com/gwindows/GWindowsVsClaw.html I should have an update to GWindows available soon and am back working on the GTK+ bindings and filling in the last gaps for GWindows 1.0 release.... (Sadly, I was sucked out of the Ada world for the last number of months. Although, I did develop an e-learning product using GWindows in Ada during that time.) David Botton ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 14:45 ` Ted Dennison ` (2 preceding siblings ...) 2002-04-15 22:02 ` tmoran @ 2002-04-17 3:25 ` Richard Riehle 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan ` (2 more replies) 3 siblings, 3 replies; 425+ messages in thread From: Richard Riehle @ 2002-04-17 3:25 UTC (permalink / raw) Ted Dennison wrote: > tmoran@acm.org wrote in message news:<zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com>... > > As Randy Brukardt noted the other day, the original idea for Claw "was to > > create a de facto standard, make a subset freely available, and eventually > > put the binding into the public domain to be a standard." But it didn't > > happen. Recently someone complained that Claw didn't currently support > > several features he needs. Nobody, to my knowledge, has added support for > > X to Claw, but multiple people have created alternative Windows bindings, > > none of which has become a standard, and none of which supports the > > I would submit that this is because the "release it to the public > domain" step was never followed through on. If they had done that > first, instead of planning on doing it last, things might have been > different. And who was going to pay Randy and RR Software for their effort in developing CLAW? It is all well and good to want free software, but someone, somewhere needs to pay for it. One reason we don't see more bindings to more environments for Ada is the widespread reluctance of people to commit resources when there is no financial benefit. Even GNAT will disappear if ACT discovers there is no financial reward in supporting it. Tom Moran is right when he complains that so many have spent so much energy creating partial implementations that discourage the use of CLAW instead of getting on board and adding to its already powerful set of capabilities. I suspect Randy would not turn down any offer of help in developing additional packages to extend the CLAW software. Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* Open Source: in conflict with the development process in the Ada community? 2002-04-17 3:25 ` Richard Riehle @ 2002-04-17 5:07 ` Kent Paul Dolan 2002-04-17 10:14 ` Hyman Rosen 2002-04-17 14:06 ` Marin David Condic 2002-04-17 13:53 ` Development process in the Ada community Marin David Condic 2002-04-17 17:58 ` Ted Dennison 2 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-17 5:07 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote: > Ted Dennison wrote: > > I would submit that this is because the "release it to the public > > domain" step was never followed through on. If they had done that > > first, instead of planning on doing it last, things might have been > > different. > And who was going to pay Randy and RR Software for their effort in > developing CLAW? It is all well and good to want free software, > but someone, somewhere needs to pay for it. One reason we don't > see more bindings to more environments for Ada is the widespread > reluctance of people to commit resources when there is no financial > benefit. Even GNAT will disappear if ACT discovers there is > no financial reward in supporting it. But since in point of fact Dr. Dewar and company seem to be making a quite comfortable living, perhaps the problem instead is that the expectation of being paid for software up front, rather than being paid for enhancements happy customers want to that software once it is in widespread use, is no longer the best model. It is tough as heck to take that first step, and the low return on investment of shareware distributors is certainly off-putting, but if the distribution step comes early, then there is a fairly low investment before the software developer learns if what has been created is going to be a viable "maintain-ware" product, while if the distribution is left until late, "giving it away for nothing" is simply too painful to contemplate. I'm guessing, since I haven't enough entrepenurial skills to fill a thimble (my brother got them all in our family), but I think Ted has the right of it. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan @ 2002-04-17 10:14 ` Hyman Rosen 2002-04-17 13:20 ` Robert Dewar 2002-04-17 14:06 ` Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Hyman Rosen @ 2002-04-17 10:14 UTC (permalink / raw) Kent Paul Dolan wrote: > But since in point of fact Dr. Dewar and company seem to be making a > quite comfortable living, perhaps the problem instead is that the > expectation of being paid for software up front, rather than being paid > for enhancements happy customers want to that software once it is in > widespread use, is no longer the best model. But Dewar, et al. were paid to develop GNAT! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-17 10:14 ` Hyman Rosen @ 2002-04-17 13:20 ` Robert Dewar 0 siblings, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-17 13:20 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBD4B3E.6030501@mail.com>... > But Dewar, et al. were paid to develop GNAT! That's a bit misleading. The government contract provided somewhat under $3 million to NYU. The total development cost of GNAT and its tool set so far has been something like $15 million, and the development continues at a rapid pace. And that does not include the huge past and present investment in GCC and the GNU tools infrastructure. Yes, the DoD contract helped get things going, no doubt about it. But once ACT was formed as a company we have many development projects that are entirely internally funded. For example, the current development of our new integrated development environment (GPS - GNAT Programming System) is int his category. By the way, please don't misuse the term public domain. No ACT software is in the public domain. Ada Core Technologies provides supported licensed copyrighted software, as do other software companies. The only difference is that we use a much less restrictive license that allows users more freedom than licenses from many other companies. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan 2002-04-17 10:14 ` Hyman Rosen @ 2002-04-17 14:06 ` Marin David Condic 2002-04-19 14:20 ` Robert Dewar 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-17 14:06 UTC (permalink / raw) Not every software product can exist on the ACT model. It requires something of sufficient complexity and size and criticality to a project that enough people will want to buy support. Do people regularly go shopping to buy support contracts for word processors or computer games? Not usually, because they do what they do & their bug-free functioning is not critical to a project. Even GNAT could arrive at a point where customers say "It works well enough for me to do my job and I don't need any add-on, custom features, so thanks for your support, but we'll be terminating our contract now..." (Even Microsoft is up against that sort of problem - why do you think they want to invent some kind of software leasing scheme?) If a product doesn't offer much promise of back-end payment by way of support/enhancement/consulting contracts and you don't charge anything for it up front, how do people get paid to develop it? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Kent Paul Dolan" <xanthian@well.com> wrote in message news:35c5c360dfe83cb34ea9648445bd0e95.48257@mygate.mailgate.org... > > But since in point of fact Dr. Dewar and company seem to be making a > quite comfortable living, perhaps the problem instead is that the > expectation of being paid for software up front, rather than being paid > for enhancements happy customers want to that software once it is in > widespread use, is no longer the best model. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-17 14:06 ` Marin David Condic @ 2002-04-19 14:20 ` Robert Dewar 2002-04-19 16:04 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-19 14:20 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9jvhq$lbg$1@nh.pace.co.uk>... > Even GNAT could arrive at a point where customers say "It works > well enough for me to do my job and I don't need any add-on, custom > features, so thanks for your support, but we'll be terminating our contract > now..." Well I don't remember if Marin was ever a customer or not, I think not, but in fact this misunderstands the support we provide. It goes far beyond fixing bugs, and providing custom features. What we provide most importantly is consulting and help on the use of Ada, both at the language and applications level, and at the level of dealing with problems of interactions with operating systems, and other software components. So Microsoft may have a problem in its long term marketing, but that's not comparable at all, since by our standards Microsoft does not provide support (and that's not surprising because they don't charge for it -- having top qualified engineers available for immediate assistance is not inexpensive) Certainly part of our support services involves fixing bugs, but that's a declining part of the total support traffic, and that's fine with us. At the same time, our total customer base for support services is growing steadily. Why? Not hard to see. We are in an industry where a days delay for one engineer costs something like $1000, *NOT* counting the collateral costs of delays. It's pretty easy for us to save a company money once you take this into account. As to the question of whether other products can be marketed in this manner. I see no reason why not. For example, for a word processor, I am certainly NOT about to mess around and build from sources if I can buy a prebuilt and pretested executable in a convenient distribution. If in addition, the product comes with real support, I am definitely willing to pay more. I agree that a word processor probably requires less support, and in particular that it does not require top engineering experts to provide this support, so I would expect such support to be less expensive than GNAT. People just assume that using a license that is favorable to users means that it is imnpossible to make money. But most of this assumption comes from gut feeling, tuned by years of exposure to alternative models, rather than hard facts. My viewpoint is that you make money by providing customers with something they need. One of the needs is for licenses that are less restrictive and do not get in the way of people doing what they need to do. We are in the business of responding to this need. We guess that others could succeed by being attentive to their users in a similar manner. Think about the whole discussion of COTS products. What are the two main concerns about COTS: 1. Support being tied to a single company 2. Long term availability of this support 3. Ability to customize if needed The open source free software model responds effectively to all these concerns. At the same time, people who are interested in the economies of scale that come from the use of COTS products are definitely NOT interested in using unsupported software. I think there is a perfect synergy between producer and consumer here, and I think it could be applied to many other software products successfully. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-19 14:20 ` Robert Dewar @ 2002-04-19 16:04 ` Marin David Condic 2002-04-22 13:44 ` Robert Dewar 2002-04-19 23:48 ` How Open Source software developers pay the bills, from within a successful such operation (was): " Kent Paul Dolan 2002-04-20 6:28 ` tmoran 2 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-19 16:04 UTC (permalink / raw) My point was that all products go through a cycle and as GNAT (being a product) matures in its cycle, new things have to step in to take its place. That's just conventional business wisdom. To the extent that you sell services (educational, training, consulting, whatever) you've got a different kind of value added that is not exactly tied to the product. Even that goes through its own kind of "product cycle" wherein it has to change over time or it dries up. At one time there were lots of companies selling buggy whips. Presumably, there might have been a whole market for maintaining, repairing and educating users of buggy whips. But if those companies didn't move on to maintaining, repairing and educating users of - say - automobile tires, they're consigned to the dustbin of history. Product & service cycles are always going to require something new be developed. As for a business model that gives the product away to produce a market needing the services? I'm not against that, but I think it has yet to be demonstrated that it works for any and all kinds of software. Word processors being the current example, I've worked for a number of companies that have used a number of different word processors in a variety of settings and I don't recall ever once being asked to go find a small team of experts to contract with for some sort of ongoing support. Maybe we bought training courses - but that hardly required an open source model. There might even have been a need for a certain amount of "help desk" support, but again that didn't require an open source model. One company could sell you the software and another provide training and question-answering and so forth. Does that mean I'm against "Open Source" software? Certainly not. Am I against giving away the razors in order to later sell the blades? Not if it works. Can any and all software projects survive and prosper with an open source, "give the software away to sell the services" model? Maybe. But I don't think that has yet been demonstrated and I'll bet we could probably go find examples of business's that have failed using this model. Hence I wouldn't begrudge any businessman saying "I won't put my software out on the net under GPL (or similar) because I don't think I can make a profit doing so." MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204190620.1902ede@posting.google.com... > > Well I don't remember if Marin was ever a customer or not, I think > not, but > in fact this misunderstands the support we provide. It goes far beyond > fixing > bugs, and providing custom features. What we provide most importantly > is consulting and help on the use of Ada, both at the language and > applications > level, and at the level of dealing with problems of interactions with > operating > systems, and other software components. > > So Microsoft may have a problem in its long term marketing, but that's > not > comparable at all, since by our standards Microsoft does not provide > support > (and that's not surprising because they don't charge for it -- having > top qualified engineers available for immediate assistance is not > inexpensive) > > Certainly part of our support services involves fixing bugs, but > that's a > declining part of the total support traffic, and that's fine with us. > At > the same time, our total customer base for support services is growing > steadily. > > Why? Not hard to see. We are in an industry where a days delay for one > engineer > costs something like $1000, *NOT* counting the collateral costs of > delays. It's > pretty easy for us to save a company money once you take this into > account. > > As to the question of whether other products can be marketed in this > manner. > I see no reason why not. For example, for a word processor, I am > certainly > NOT about to mess around and build from sources if I can buy a > prebuilt and > pretested executable in a convenient distribution. If in addition, the > product > comes with real support, I am definitely willing to pay more. > > I agree that a word processor probably requires less support, and in > particular > that it does not require top engineering experts to provide this > support, so > I would expect such support to be less expensive than GNAT. > > People just assume that using a license that is favorable to users > means that > it is imnpossible to make money. But most of this assumption comes > from gut > feeling, tuned by years of exposure to alternative models, rather than > hard > facts. > > My viewpoint is that you make money by providing customers with > something > they need. One of the needs is for licenses that are less restrictive > and > do not get in the way of people doing what they need to do. We are in > the > business of responding to this need. We guess that others could > succeed by > being attentive to their users in a similar manner. > > Think about the whole discussion of COTS products. What are the two > main > concerns about COTS: > > 1. Support being tied to a single company > 2. Long term availability of this support > 3. Ability to customize if needed > > The open source free software model responds effectively to all these > concerns. At the same time, people who are interested in the economies > of > scale that come from the use of COTS products are definitely NOT > interested > in using unsupported software. > > I think there is a perfect synergy between producer and consumer here, > and > I think it could be applied to many other software products > successfully. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-19 16:04 ` Marin David Condic @ 2002-04-22 13:44 ` Robert Dewar 0 siblings, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-22 13:44 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9pf6e$bo8$1@nh.pace.co.uk>... > Hence I wouldn't begrudge any businessman saying "I won't put my software > out on the net under GPL (or similar) because I don't think I can make a > profit doing so." Putting your software out on the net is an orthogonal decision on what license to use. The GPL does not require you to make your software available on the net, and you can put your software on the net without giving permission to redistribute. > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > "Robert Dewar" <dewar@gnat.com> wrote in message > news:5ee5b646.0204190620.1902ede@posting.google.com... Marin, please don't quote entire articles, quote selectively, thanks! It is annoying to have to delete these junk second level quotes. We all have thread following news readers at this stage. ^ permalink raw reply [flat|nested] 425+ messages in thread
* How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-19 14:20 ` Robert Dewar 2002-04-19 16:04 ` Marin David Condic @ 2002-04-19 23:48 ` Kent Paul Dolan 2002-04-20 16:41 ` Robert Dewar 2002-04-21 1:44 ` Robert Dewar 2002-04-20 6:28 ` tmoran 2 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-19 23:48 UTC (permalink / raw) Thanks extremely much for that economics lesson, Robert. I was about to frame as a query a completely wrongheaded guess at how open source folks get paid a living wage, to promote discussion, and you have not only saved readers in c.l.a the grief, but provided something deeply needed in the community _considering_ open source, a discussion from within a successful operation of how it works. I have taken the liberty of reformatting what you wrote (your text producer is too wide for your posting tool's wrapper length), and crossposting to another venue where similar discussions are underway. Robert Dewar wrote in comp.lang.ada: : "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote :> Even GNAT could arrive at a point where customers say "It :> works well enough for me to do my job and I don't need any :> add-on, custom features, so thanks for your support, but :> we'll be terminating our contract now..." => Well I don't remember if Marin was ever a customer or not, I => think not, but in fact this misunderstands the support we => provide. It goes far beyond fixing bugs, and providing => custom features. What we provide most importantly is => consulting and help on the use of Ada, both at the language => and applications level, and at the level of dealing with => problems of interactions with operating systems, and other => software components. => So Microsoft may have a problem in its long term marketing, => but that's not comparable at all, since by our standards => Microsoft does not provide support (and that's not => surprising because they don't charge for it -- having top => qualified engineers available for immediate assistance is => not inexpensive) => Certainly part of our support services involves fixing bugs, => but that's a declining part of the total support traffic, => and that's fine with us. At the same time, our total => customer base for support services is growing steadily. => Why? Not hard to see. We are in an industry where a days => delay for one engineer costs something like $1000, *NOT* => counting the collateral costs of delays. It's pretty easy => for us to save a company money once you take this into => account. => As to the question of whether other products can be marketed => in this manner. I see no reason why not. For example, for a => word processor, I am certainly NOT about to mess around and => build from sources if I can buy a prebuilt and pretested => executable in a convenient distribution. If in addition, the => product comes with real support, I am definitely willing to => pay more. => I agree that a word processor probably requires less => support, and in particular that it does not require top => engineering experts to provide this support, so I would => expect such support to be less expensive than GNAT. => People just assume that using a license that is favorable to => users means that it is imnpossible to make money. But most => of this assumption comes from gut feeling, tuned by years of => exposure to alternative models, rather than hard facts. => My viewpoint is that you make money by providing customers => with something they need. One of the needs is for licenses => that are less restrictive and do not get in the way of => people doing what they need to do. We are in the business of => responding to this need. We guess that others could succeed => by being attentive to their users in a similar manner. => Think about the whole discussion of COTS products. What are => the two main concerns about COTS: => 1. Support being tied to a single company => 2. Long term availability of this support => 3. Ability to customize if needed => The open source free software model responds effectively to => all these concerns. At the same time, people who are => interested in the economies of scale that come from the use => of COTS products are definitely NOT interested in using => unsupported software. => I think there is a perfect synergy between producer and => consumer here, and I think it could be applied to many other => software products successfully. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-19 23:48 ` How Open Source software developers pay the bills, from within a successful such operation (was): " Kent Paul Dolan @ 2002-04-20 16:41 ` Robert Dewar 2002-04-20 18:08 ` Florian Weimer 2002-04-21 1:44 ` Robert Dewar 1 sibling, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-20 16:41 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>... One thing that is interesting here is that we are not really an Open Source developer. The idea of open source development is that development is a shared community activity, and that all sorts of people contribute to the development. The advantages of such a model are clear: you get a larger community of people involved in the development. The disadvantages are also clear, you have far less control over the development process. If you follow the gcc development mailing list, you will certainly see both of these effects in action. GNAT Pro is not an open source product in this respect. The development of GNAT Pro is tightly controlled, more tightly controlled indeed internally than is the case in most other software companies. Now there is also an open source development community developing for the FSF version of GNAT at gnu.org, and we participate in this. We hope that we will be able to take advantage of contributions here and eventually have some of them show up in GNAT Pro after going through our rigorous internal process. But it is fairly critical that our internal development process is not open to uncontrolled community contributions. We have heard recently that the Army has a policy against open source development, and while I don't know if this is true, or what the details are, I have some sympathy with the thought behind such a policy. The concern is centered on the disadvantages that can come with uncontrolled development, and this is indeed a real concern. That's why I think the model of commercial closed development will always persist, and what I think the ACT experience has shown is that this is by no means inconsistent with the notions of Free Software and the use of the GPL. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-20 16:41 ` Robert Dewar @ 2002-04-20 18:08 ` Florian Weimer 2002-04-21 0:38 ` Robert Dewar 0 siblings, 1 reply; 425+ messages in thread From: Florian Weimer @ 2002-04-20 18:08 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>... > > One thing that is interesting here is that we are not really an > Open Source developer. The idea of open source development is that > development is a shared community activity, and that all sorts of > people contribute to the development. According to Eric S. Raymond, "Open Source" does not necessarily imply the Bazaar model, the Cathedral model (which was once common to many GNU projects---Emacs, for example, joined the Bazaar only rather recently) is still considered "Open Source". ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-20 18:08 ` Florian Weimer @ 2002-04-21 0:38 ` Robert Dewar 0 siblings, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-21 0:38 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87bsce1bve.fsf@deneb.enyo.de>... > dewar@gnat.com (Robert Dewar) writes: > > According to Eric S. Raymond, "Open Source" does not > necessarily imply the Bazaar model, the Cathedral model > (which was once common to many GNU projects---Emacs, for > example, joined the Bazaar only rather > recently) is still considered "Open Source". Well I don't think Eric defines these terms for the industry :-) When people worry about "open source" what they are usually worrying about is an open and uncontrolled development process. Of course there can be closed and uncontrolled development and open and controlled development, but there is a significant perception that open tends to go with uncontrolled, and to some extent that's reasonable, if you want a community to participate energetically then you can't tie their hands too tightly :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-19 23:48 ` How Open Source software developers pay the bills, from within a successful such operation (was): " Kent Paul Dolan 2002-04-20 16:41 ` Robert Dewar @ 2002-04-21 1:44 ` Robert Dewar 2002-04-22 16:06 ` Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-21 1:44 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<fabfb33253b2dea9ae61e01e4a71de03.48257@mygate.mailgate.org>... > Thanks extremely much for that economics lesson, Robert. > I was about to frame as a query a completely wrongheaded > guess at how open source folks get paid a living wage. As I said earlier, the issue is not really open source per se but rather the issue is whether companies can successfully use licenses that convey considerable rights to customers, including rights to free use, modification and redistribution (collectively such licenses have been referred to as Free Software licenses). I have explained how this model works well for Ada Core Technologies and its customers. I should mention one more important aspect of this model (again remember I am wearing my ACT hat :-) The way our support works is that people purchase a copy of GNAT Pro with support for a year. Then, at their option they can renew this support, which includes getting all the updated latest versions of GNAT Pro. Will they renew their support? In practice almost all our customers do renew. They certainly don't have to, they can continue to use the version of the compiler they have (since the license gives them this right, and there are certainly no time bombs or anything else like that which would prevent that). The answer is simple, they will renew if they find a) that development of GNAT Pro is continuing and valuable new features are being added, so that it is worth getting the latest versions. b) that the support we provide is valuable Now remember that ACT is a commercial company, we definitely want customers to renew. That means we have a very significant financial incentive to deliver on both points a) and b) above. This keeps us running fast. Unlike a proprietary software company that can use restrictive licenses to keep its customer base captive, we can't just stop development, degrade support, and sit back and milk the customer base, since that would be financially disadvantageous to us (and at the risk of sounding like General Motors, we think that the continued health of ACT is an important element in the continued success and usage of Ada, which we definitely want to encourage!) Now of course I am not saying that all proprietary companies provide poor support, or fail to keep up a strong development program, but I like the fact that in our model, our interests are aligned with those of our customers both philosphically and commercially. Now, an interesting question, could you use this model for all software, or at least let's say other software? Well I can't answer that, but I do remember my brother saying when he was running DISC (Dewar Information Systems Corporation) and had over a hundred people working for him, that he found it annoying that he could only pay Microsoft $300 for a C compiler. He said "I would far rather pay 10 or 20 times that, and get a corresponding better product with better support, since I am betting my company on the integrity of this product". Hobbyists and students often evaluate software purely on the basis of whether it does what they personally need. They would not appear to be customers for the kind of full-service support that is part of this model. On the other hand, not much of the software industry depends on the money spent by students and hobbyists on software, and it seems quite reasonable to let them get hold of the software they need with no support and no fees (in practice such communities tend to regard it as legitimate to trade software regardless of licensing conditions). I like the model of unsupported public versions for meeting this need because I think it realistically addresses this segment. But when it comes to industrial use, I don't think most companies want to rely on downloaded software with no support. Suppose I came up with a really good piece of presentation software that competed effectively with Power Point? Could I sell this with a non-restrictive license. I think the answer is that it depends on the price. Power Point itself is remarkably expensive, and Microsoft's total income from this product exceeds the cost of producing it by some enormous factor. I concede that if you think this kind of discrepancy is reasonable, then it's hard to sustain without restrictive licensing, but I think if you sold such a product for a reasonable price, you could definitely succeed. I know that for my own usage, I have no problem in paying reasonable prices for software that I need to rely on. What's the definition of reasonable? For me it is that the company is making a reasonable profit but not an excessive one. I think software producers should be able to make a good living, but I don't see that they have to get super rich. Obviously if I get more extensive support I expect to pay more so I need to select a product whose level of support meets my needs. Ada Core Technologies has a quite clear philosophy of providing very extensive high level support. That's not cheap, but that's the market segment we have chosen to address, because typically Ada is used in large scale critical systems where this level of support is needed. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-21 1:44 ` Robert Dewar @ 2002-04-22 16:06 ` Marin David Condic 2002-04-23 12:44 ` Robert Dewar 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-22 16:06 UTC (permalink / raw) I don't know of any company in any industry that can get away with that sort of attitude for very long. This seems especially true for the software industry - for either "proprietary" of "open" companies. I don't think the license has anything to do with it. The specific license might raise/lower the entrance/exit barriers, but in the end, a company must provide value with their software or the customer will go elsewhere. Microsoft with all its proprietary licensing still brought out software that cost substantially less and provided substantially more value than (for example) OS-360. In addition, they *must* find some way of creating *more* value in the future or the cash cow dries up. They can't lock in their customers any moreso than DeSoto, Studebaker, Dusenberg, Cord, American Motors, Delorean ....... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204201744.587dfec7@posting.google.com... > Unlike a proprietary software company that can use restrictive > licenses to keep its customer base captive, > we can't just stop development, degrade support, and sit > back and milk the customer base, since that would be financially > disadvantageous to us (and at the risk of ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-22 16:06 ` Marin David Condic @ 2002-04-23 12:44 ` Robert Dewar 2002-04-23 20:48 ` Marin David Condic 2002-04-23 23:50 ` Jeffrey Carter 0 siblings, 2 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-23 12:44 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aa1cde$rbr$1@nh.pace.co.uk>... > I don't know of any company in any industry that can get away with that sort > of attitude for very long. This seems especially true for the software > industry - for either "proprietary" of "open" companies. I don't think the > license has anything to do with it. The specific license might raise/lower > the entrance/exit barriers, but in the end, a company must provide value > with their software or the customer will go elsewhere. Microsoft with all > its proprietary licensing still brought out software that cost substantially > less and provided substantially more value than (for example) OS-360. In > addition, they *must* find some way of creating *more* value in the future > or the cash cow dries up. They can't lock in their customers any moreso than > DeSoto, Studebaker, Dusenberg, Cord, American Motors, Delorean ....... You miss the point. Of course this (behavior commonly referred to as "bottom feeding") cannot persist for long with respect to a particular product, but it is remarkably common for a company with a proprietary software product to essentially abandon continued support, and then continue to profit from a captive market for what can be a suprising long time. All I am noting is that our model won't let us do this for even a short time, and that seems a good thing all round. As a company, our policy is to rely on rapid innovation rather than on restrictive intellectual property rights. We are convinced that if we continue to innovate rapidly, we can continue to be successful, and we think this is a model that benefits both us and our customers. I should also say that I think it leads to a much more satisfying environment for software developers. I still spend a lot of my time improving GNAT by adding new functionality and improving what is already there, and I find it very satisfying that the code I write is open for examination (and hopefully appreciation :-) by others. In more concrete terms, I think that this openness is one of the reasons that no software engineer has ever left Ada Core Technologies in its seven years of existance. Which is surprising, especially since we can't dangle stock options worth potential millions as an incentive. Again, please interpret the above remembering that I have an interest (both financial, but more importantly personal, and from the point of view of general success of Ada) in the continuing success of ACT :-) Robert Dewar ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-23 12:44 ` Robert Dewar @ 2002-04-23 20:48 ` Marin David Condic 2002-04-23 23:50 ` Jeffrey Carter 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-23 20:48 UTC (permalink / raw) Then maybe we're in violent agreement. I don't doubt that having open source might make for building a fire under a company to continue to provide support and innovate because the barriers to entry are lower for someone else to come along and do so as well. Its possible that this is a critical selling point to the end customer - depending on the product and customer. I'd continue to contend that the barriers are not infinite even without open source - just higher. And even Microsoft with large resources and high barriers to competitors are not in a position to avoid innovation. They have to at least do what the car companies do with model year changes - keep the guts unchanged but bend the sheet metal a little different - or nobody wants to buy the next generation. As for the wisdom of that strategy? ACT seems to be making it work and other companies have been successful by adopting a rapid-innovation and customer-centric approach. Other companies have been successful for long stretches of time without changing their products much at all (witness the VW Beetle). So the answer seems to be - as with many things in life - "It Depends". Is open source critical to that success? Maybe. Maybe its just the current software-buyer's fad - like tailfins. Maybe it depends on the product at hand. In any case, its hard to argue with success. Incidentally, I had not heard it called "bottom feeding". I've heard it called "milking the cash cow". Bottom feeding is what I've associated with a stock-buying strategy - find hurting to bankrupt companies and buy the stock for less than the liquidation value. But I could see how a twist of the phrase could apply to scouring up the crumbs of business left with a product as it decays. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0204230444.6684ac@posting.google.com... > > You miss the point. Of course this (behavior commonly referred to as > "bottom feeding") cannot persist for long with respect to a particular > product, but it is remarkably common for a company with a proprietary ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: How Open Source software developers pay the bills, from within a successful such operation (was): Open Source: in conflict with the development process in the Ada community? 2002-04-23 12:44 ` Robert Dewar 2002-04-23 20:48 ` Marin David Condic @ 2002-04-23 23:50 ` Jeffrey Carter 1 sibling, 0 replies; 425+ messages in thread From: Jeffrey Carter @ 2002-04-23 23:50 UTC (permalink / raw) Robert Dewar wrote: > > I should also say that I think it leads to a much more satisfying > environment > for software developers. I still spend a lot of my time improving GNAT > by > adding new functionality and improving what is already there, and I > find it > very satisfying that the code I write is open for examination (and > hopefully > appreciation :-) by others. In more concrete terms, I think that this > openness > is one of the reasons that no software engineer has ever left Ada Core > Technologies in its seven years of existance. Which is surprising, > especially > since we can't dangle stock options worth potential millions as an > incentive. Sounds nice. Too bad I have neither compiler development experience nor a desire to live in New York. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-19 14:20 ` Robert Dewar 2002-04-19 16:04 ` Marin David Condic 2002-04-19 23:48 ` How Open Source software developers pay the bills, from within a successful such operation (was): " Kent Paul Dolan @ 2002-04-20 6:28 ` tmoran 2002-04-20 6:53 ` Florian Weimer 2 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-20 6:28 UTC (permalink / raw) > What we provide most importantly is consulting and help on the use of Ada, So ACT should be thought of as a software consulting company that happens to also maintain a compiler? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 6:28 ` tmoran @ 2002-04-20 6:53 ` Florian Weimer 2002-04-20 11:53 ` Frank J. Lhota 2002-04-20 16:07 ` Robert Dewar 0 siblings, 2 replies; 425+ messages in thread From: Florian Weimer @ 2002-04-20 6:53 UTC (permalink / raw) tmoran@acm.org writes: >> What we provide most importantly is consulting and help on the use of Ada, > So ACT should be thought of as a software consulting company that > happens to also maintain a compiler? Yes, probably. If they were a compiler company, they wouldn't be permitted to give GNAT away for free (at least in Germany, but I think U.S. law is similar). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 6:53 ` Florian Weimer @ 2002-04-20 11:53 ` Frank J. Lhota 2002-04-20 13:14 ` Florian Weimer 2002-04-20 16:07 ` Robert Dewar 1 sibling, 1 reply; 425+ messages in thread From: Frank J. Lhota @ 2002-04-20 11:53 UTC (permalink / raw) Under what law (in either Germany or the U.S.) would forbid a company from giving away a compiler? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 11:53 ` Frank J. Lhota @ 2002-04-20 13:14 ` Florian Weimer 2002-04-20 14:50 ` Frank J. Lhota ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Florian Weimer @ 2002-04-20 13:14 UTC (permalink / raw) "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes: > Under what law (in either Germany or the U.S.) would forbid a company from > giving away a compiler? Regulations against unfair competition. Hmm, I couldn't find a reference to specific German law, but I remember a few cases in which companies were forced to stop giving services away for free. However, I'm no longer sure if general provisions against unfair competition were applied, or some special case law (telco regulations, for example). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 13:14 ` Florian Weimer @ 2002-04-20 14:50 ` Frank J. Lhota 2002-04-21 11:13 ` Ingo Marks 2002-04-22 16:11 ` Marin David Condic 2 siblings, 0 replies; 425+ messages in thread From: Frank J. Lhota @ 2002-04-20 14:50 UTC (permalink / raw) If there is a law against giving away software, AOL is in real trouble. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 13:14 ` Florian Weimer 2002-04-20 14:50 ` Frank J. Lhota @ 2002-04-21 11:13 ` Ingo Marks 2002-04-21 21:23 ` Darren New 2002-04-22 13:42 ` Robert Dewar 2002-04-22 16:11 ` Marin David Condic 2 siblings, 2 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-21 11:13 UTC (permalink / raw) Florian Weimer wrote: > "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes: > >> Under what law (in either Germany or the U.S.) would forbid a company >> from giving away a compiler? > > Regulations against unfair competition. Hmm, I couldn't find a > reference to specific German law, but I remember a few cases in which > companies were forced to stop giving services away for free. However, > I'm no longer sure if general provisions against unfair competition > were applied, or some special case law (telco regulations, for > example). As far I remember a telco (Deutsche Telekom?) was forced to stop a free service that customers usually had to pay for. But they gave this free service away just to decoy oodles of new customers who normally had went to several other telcos. This was a serious unfair competition with a clear monopolistic tendency. But as long you don't gain a monopoly then of course you can give products and services away for free in Germany. Even Microsoft does it :-) You can buy cheap computer magazines with free Microsoft Visual C++ compilers on CD. Regards, Ingo ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-21 11:13 ` Ingo Marks @ 2002-04-21 21:23 ` Darren New 2002-04-22 13:42 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-21 21:23 UTC (permalink / raw) Ingo Marks wrote: > As far I remember a telco (Deutsche Telekom?) was forced to stop a free > service that customers usually had to pay for. This has happened in the US too, on the grounds that the customers paying for the service were the ones who weren't receiving it. Even the phones inside the offices of the telcos here have to be paid for by the telcos. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-21 11:13 ` Ingo Marks 2002-04-21 21:23 ` Darren New @ 2002-04-22 13:42 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-22 13:42 UTC (permalink / raw) Ingo Marks <adv@region-nord.de> wrote in message news:<a9u6sm$24c$01$1@news.t-online.com>... > Florian Weimer wrote: > > > "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes: > > > >> Under what law (in either Germany or the U.S.) would forbid a company > >> from giving away a compiler? > > > > Regulations against unfair competition. Please go look up the notion of unfair competition. It is far far more restrictive than you think. Don't guess about the law! > But as long you don't gain a monopoly then of course you can give products > and services away for free in Germany. Even Microsoft does it :-) You can > buy cheap computer magazines with free Microsoft Visual C++ compilers on CD. Indeed! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 13:14 ` Florian Weimer 2002-04-20 14:50 ` Frank J. Lhota 2002-04-21 11:13 ` Ingo Marks @ 2002-04-22 16:11 ` Marin David Condic 2 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 16:11 UTC (permalink / raw) Anti-trust laws might force you to unbundle products. When a computer company sells you hardware and throws in a "free" OS and other software, it isn't really "free", is it? The courts may stop it under an anti-trust suit, but companies have been giving away stuff "free" for a long time now and I don't know of any laws that would stop it. (Giving away razors to sell the blades is the usual example.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87znzy1pif.fsf@deneb.enyo.de... > > Regulations against unfair competition. Hmm, I couldn't find a > reference to specific German law, but I remember a few cases in which > companies were forced to stop giving services away for free. However, > I'm no longer sure if general provisions against unfair competition > were applied, or some special case law (telco regulations, for > example). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Open Source: in conflict with the development process in the Ada community? 2002-04-20 6:53 ` Florian Weimer 2002-04-20 11:53 ` Frank J. Lhota @ 2002-04-20 16:07 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-20 16:07 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87lmbidfny.fsf@deneb.enyo.de>... > tmoran@acm.org writes: > > >> What we provide most importantly is consulting and help on the use of Ada, > > > So ACT should be thought of as a software consulting company that > > happens to also maintain a compiler? No. That's quite incorrect. Just like Microsoft (for instance) we provide licensed copyrighted software with support for a fee. What distinguishes us from Microsoft in this regard is two things 1. Our software license is much more advantageous to users 2. We provide much more extensive support. > Yes, probably. If they were a compiler company, they wouldn't be > permitted to give GNAT away for free (at least in Germany, but I think > U.S. law is similar). Please don't play amateur lawyer, the above statement is nonsense! And in any case we are a compiler company, and we do NOT give GNAT Pro (the name of our commercial product) away for free! Robert Dewar Ada Core Technologies P.S. how anyone even a little remotely aware of current events could think that there was a law against giving software away free is surprising to me. Florian, don't you follow current events (e.g. Netscape vs Microsoft, at all?) Bundling of software can in some cases have Sherman act implications, but no, there is no law per se against giving things away free :-) However, don't expect ACT to be in that business :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 3:25 ` Richard Riehle 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan @ 2002-04-17 13:53 ` Marin David Condic 2002-04-18 14:50 ` Stephen Leake 2002-04-17 17:58 ` Ted Dennison 2 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-17 13:53 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3CBCEB15.E104D1F5@adaworks.com... > > And who was going to pay Randy and RR Software for their effort in > developing CLAW? It is all well and good to want free software, > but someone, somewhere needs to pay for it. One reason we don't > see more bindings to more environments for Ada is the widespread > reluctance of people to commit resources when there is no financial > benefit. Even GNAT will disappear if ACT discovers there is > no financial reward in supporting it. > Unfortunately, there sometimes seems to be a perception that because some software can be downloaded and used free of charge, that it must be possible for *all* software to be downloaded and used free of charge. It really stands in violation of some gas law I used to know back in high school - the one about there being no free lunch? :-) To some extent, I think this gets fostered by the FSF having a slight bias against business & capitalism. What gets lost in the rhetoric is that most of us don't go into work every day and write software for the companies we work for and then refuse to accept a paycheck at the end of the week. Software costs money to develop, enhance and maintain. Who should pay for that? It seems fair that it ought to be the people getting the benefit of using it. Giving it away "free" is really just a strategy to get payment in some other manner - like "Free Beer" might be a strategy to sell hot dogs. Any way you slice it, *someone* has to pay. GNAT isn't "free" - its just subsidized by the companies that buy support from ACT. We get it at no cost because someone else pays for its development & maintenance. But not every product can subsist on that model and even GNAT could eventually fall on the wayside if there were insufficient numbers of companies willing to buy support. > Tom Moran is right when he complains that so many have spent so > much energy creating partial implementations that discourage the > use of CLAW instead of getting on board and adding to its already > powerful set of capabilities. I suspect Randy would not turn down > any offer of help in developing additional packages to extend the > CLAW software. > Perhaps enhancing CLAW and making it the de facto "standard" for OS interfacing (at least on Windows - could it ever become more general?) might be a really good idea. As you observed before, RR Software can't be expected to do that without some kind of remuneration either from direct sales or some other mechanism. The problem is one of incentivizing people to add to the product. Will people jump up and beg for the chance to help develop a product in their spare time so that someone else can sell it? If it were "free software" would they be more eager to do so? But then we just get back to that problem of who is going to pay the freight, right? So maybe RR Software could find a way of partnering with the spare-time developers & get a bigger, better product as a result? Dare I suggest the Ada Developer's Cooperative License as a mechanism to do that? :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 13:53 ` Development process in the Ada community Marin David Condic @ 2002-04-18 14:50 ` Stephen Leake 2002-04-18 15:43 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-18 14:50 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > <snip> > GNAT isn't "free" - its just subsidized by the companies that buy support > from ACT. We get it at no cost because someone else pays for its development > & maintenance. But not every product can subsist on that model and even GNAT > could eventually fall on the wayside if there were insufficient numbers of > companies willing to buy support. And ACT is now extending this model to GtkAda, which is a cross-platform GUI tool. It will be interesting to see if that fares better than CLAW (or Windex :). -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 14:50 ` Stephen Leake @ 2002-04-18 15:43 ` Marin David Condic 2002-04-19 5:23 ` Simon Wright 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-18 15:43 UTC (permalink / raw) That's one of the standard-issue strategies companies adopt with products. Especially software products. You produce something initially which might become your "cash cow", but you know eventually the market for it is going to dry up. Hence you have to start developing new products to take its place. Sooner or later, the GNAT compiler will reach a point where nobody will want to buy suport for it. That's just life. In the mean time, if you want to be in business after that happens, you've got to develop new products like GtkAda to take its place. Is GtkAda a big enough deal to generate enough paying support? Possibly, but it never hurts to have some additional irons in the fire. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:ud6wxvz69.fsf@gsfc.nasa.gov... > > And ACT is now extending this model to GtkAda, which is a > cross-platform GUI tool. It will be interesting to see if that fares > better than CLAW (or Windex :). > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 15:43 ` Marin David Condic @ 2002-04-19 5:23 ` Simon Wright 2002-04-22 15:41 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-19 5:23 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Sooner or later, the GNAT compiler will reach a point where nobody > will want to buy suport for it. There's still a market for support in how to _use_ a product. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-19 5:23 ` Simon Wright @ 2002-04-22 15:41 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 15:41 UTC (permalink / raw) The year is 2099. Programming is now done by plugging an Ethernet wire into the side of someone's head. (They're called "wireheads" now - not programmers. But normal people still find them impossible to communicate with and they have a hard time getting dates. Strangely, pocket protectors are still worn, but nobody uses pens or pencils anymore.) They "think" the code into the machine. The main computer at "Alpha Complex" still "remembers" the GNAT compiler and can regurgitate its source and translate it into any instruction set the Historians would like for their studies. But sadly, nobody has inquired about it in quite a while. ACT made a huge fortune back in the big Ada Fad of 2010 - enough so the organization had a permanent endowment, but they never built anything new. Now Ada Core Technologies consists of a single secretary sitting in front of a Fiber Op waiting for someone to call asking for a support contract and once the check clears for the Eleventy-Gagillion Dollars (inflation! :-) annual support fee, she will push the button that will thaw out the brains of all the techies that were frozen back in 2030 so they can get to work on the problems. But the jars holding the brains have been collecting dust for some time now and the secretary spends most of her time polishing her nails and talking to her boyfriend on the phone. Its nice work, if you can get it. A bit extreme, maybe, but I think it illustrates my point about how *all* products have a life-span and ACT, I'm sure, are smart enough to know that & will evolve new products & services to accommodate that. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Simon Wright" <simon@pushface.org> wrote in message news:x7vr8lci7mf.fsf@smaug.pushface.org... > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > > > Sooner or later, the GNAT compiler will reach a point where nobody > > will want to buy suport for it. > > There's still a market for support in how to _use_ a product. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 3:25 ` Richard Riehle 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan 2002-04-17 13:53 ` Development process in the Ada community Marin David Condic @ 2002-04-17 17:58 ` Ted Dennison 2002-04-17 20:39 ` Stephen Leake 2002-04-17 22:18 ` Randy Brukardt 2 siblings, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-17 17:58 UTC (permalink / raw) Richard Riehle <richard@adaworks.com> wrote in message news:<3CBCEB15.E104D1F5@adaworks.com>... > Ted Dennison wrote: > > > I would submit that this is because the "release it to the public > > domain" step was never followed through on. If they had done that > > first, instead of planning on doing it last, things might have been > > different. > > And who was going to pay Randy and RR Software for their effort in > developing CLAW? It is all well and good to want free software, That's not the issue. Its *an* issue of course, but not the one being discussed. The issue is how something can become "standard". I can only see two ways: 1) It is distributed with every appropriate compiler (either by fiat or agreement). Examples of this are the standard Ada libraries, and the Win32Ada bindings. Let us not forget that the Win32Ada bindings are indeed the *standard* low-level Win32 bindings. No one's been talking about them because low-level bindings are so yucky that no one really wants to use them. Let us also not forget that the Win32Ada bindings were created by Intermetrics, a company that, like RR, is in the business of selling licenses to proprietary software (or at least was at the time). 2) It is released freely, and is so wonderful compared to the alternatives that everyone who wants to do that kind of thing goes out and downloads it. Now perhaps you are saying that creating a standard is incompatable with making a profit. I'm not really qualified to answer that, but I somehow doubt that's the case. > benefit. Even GNAT will disappear if ACT discovers there is > no financial reward in supporting it. That is wrong. ACT does not own Gnat. Its source copyrights are held by the FSF, and it is now part of the gcc baseline. As long as gcc is around, Gnat will be around. > powerful set of capabilities. I suspect Randy would not turn down > any offer of help in developing additional packages to extend the > CLAW software. I'm sure he wouldn't. What I'm missing here is what's in it for *me*. I have no interest in helping to improve some company's proprietary product, unless I am paid to do so. (and frankly I have plenty of paying work on my plate at the moment already. I'm not interested in taking on any more.) I certianly do some volunteer work that involves using, and perhaps improving, Windows bindings. However, I do that for the good of the community, not any one party's private good (that's why its called "volunteer" work). I've dealt with RR before, and they seemed like a great company, and great guys. If there were true justice in the universe I'm sure they'd be swimming in cash by now. But I just can't convince myself that their stockholders are a worthy enough cause to become the primary benificiary of my volunteer efforts. I'd rather donate time on something that everyone in the (Ada) community can use, not just the select few to whom some company deigns to grant a license. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 17:58 ` Ted Dennison @ 2002-04-17 20:39 ` Stephen Leake 2002-04-17 20:54 ` Marin David Condic 2002-04-17 22:18 ` Randy Brukardt 1 sibling, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-17 20:39 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Richard Riehle <richard@adaworks.com> wrote in message > news:<3CBCEB15.E104D1F5@adaworks.com>... > > Even GNAT will disappear if ACT discovers there is > > no financial reward in supporting it. > > That is wrong. ACT does not own Gnat. Its source copyrights are held > by the FSF, and it is now part of the gcc baseline. As long as gcc is > around, Gnat will be around. Not quite true. Parts of gcc and binutils are dropped from the gcc baseline when they are no longer maintained. Old processors are the most common parts dropped. If ACT stops maintaining GNAT, and nobody else picks it up, it will eventually be dropped from gcc. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 20:39 ` Stephen Leake @ 2002-04-17 20:54 ` Marin David Condic 2002-04-18 15:43 ` Ted Dennison 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-17 20:54 UTC (permalink / raw) "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:u4riadpq3.fsf@gsfc.nasa.gov... > > If ACT stops maintaining GNAT, and nobody else picks it up, it will > eventually be dropped from gcc. > The important observation is that unless there is some reasonably large body of people willing to pay money to get support from someone, GNAT would remain largely static. You might have a few hobyists who would tinker with it and put changes back into the tree, but would you see any really serious work done on it? What if a new language revision came out? What if new target hardware comes about? On the one hand, sure, GNAT is around so long as there is a source tree somewhere that folks can download from. On the other hand, lack of paying customers looking for support means - if not "death" - at least a "vegitative state" as a project. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 20:54 ` Marin David Condic @ 2002-04-18 15:43 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 15:43 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9kne6$3qc$1@nh.pace.co.uk>... > "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message > news:u4riadpq3.fsf@gsfc.nasa.gov... > > > > If ACT stops maintaining GNAT, and nobody else picks it up, it will > > eventually be dropped from gcc. > > > The important observation is that unless there is some reasonably large body > of people willing to pay money to get support from someone, GNAT would > remain largely static. You might have a few hobyists who would tinker with Considering that there are actually 2 Mac ports being supported solely by users (one under very active development), I highly doubt that the main compiler itself would suddenly loose all support w/o ACT. Its just that with ACT around there are better things for volunteers to spend their time on. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 17:58 ` Ted Dennison 2002-04-17 20:39 ` Stephen Leake @ 2002-04-17 22:18 ` Randy Brukardt 2002-04-18 15:39 ` Ted Dennison 1 sibling, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-17 22:18 UTC (permalink / raw) Ted Dennison wrote in message <4519e058.0204170958.22f797c4@posting.google.com>... >Richard Riehle <richard@adaworks.com> wrote in message news:<3CBCEB15.E104D1F5@adaworks.com>... >> Ted Dennison wrote: >The issue is how something can become "standard". I can >only see two ways: > >1) It is distributed with every appropriate compiler (either by fiat >or agreement). Examples of this are the standard Ada libraries, and >the Win32Ada bindings. Let us not forget that the Win32Ada bindings >are indeed the *standard* low-level Win32 bindings. No one's been >talking about them because low-level bindings are so yucky that no one >really wants to use them. Let us also not forget that the Win32Ada >bindings were created by Intermetrics, a company that, like RR, is in >the business of selling licenses to proprietary software (or at least >was at the time). Win32Ada was created under a contract which required Intemetrics to make it available free. So, of course they did so. Moreover, what they created is NOT pure, portable, Ada, and in fact is NOT available with "every appropriate compiler" (in so much as it is not included with Janus/Ada, and in fact doesn't compile with Janus/Ada, either. We of course provide a Win32 binding based on our 16-bit Win 3.1 binding, but it isn't much like the Intermetrics one. That's no real issue, as no one ought to use Win32Ada anyway: for GUI, use Claw or something else; for the occassional thread or file system API, bind it in place.) >> powerful set of capabilities. I suspect Randy would not turn down >> any offer of help in developing additional packages to extend the >> CLAW software. > >I'm sure he wouldn't. What I'm missing here is what's in it for *me*. >I have no interest in helping to improve some company's proprietary >product, unless I am paid to do so. (and frankly I have plenty of >paying work on my plate at the moment already. I'm not interested in >taking on any more.) I certianly do some volunteer work that involves >using, and perhaps improving, Windows bindings. However, I do that for >the good of the community, not any one party's private good (that's >why its called "volunteer" work). > >I've dealt with RR before, and they seemed like a great company, and >great guys. If there were true justice in the universe I'm sure they'd >be swimming in cash by now. But I just can't convince myself that >their stockholders are a worthy enough cause to become the primary >benificiary of my volunteer efforts. I'd rather donate time on >something that everyone in the (Ada) community can use, not just the >select few to whom some company deigns to grant a license. Of course, you can always put any such work out under any license that you prefer (including the GMGPL), which would certainly have the effect of prevent us from including it in the Claw package and making any money off of it. And certainly, the Claw Introductory version is available under a "free for non-commercial use" license. So that hardly qualifies as a "select few". (Indeed, that always has been true for the Claw Introductory version, although we didn't originally spell it out clearly on our website.) You may even be able to talk me to widening that more; the primary reason for the "non-commercial" restriction is to prevent people from selling the Introductory version itself (or enhancements of it), not to prevent people from using it in a commercial environment. We could find any words that covered the one that didn't cover the other, or get so complicated as to be impossible to understand. Finally we decided to use a variation on Aonix's ObjectAda license. Randy Brukardt. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 22:18 ` Randy Brukardt @ 2002-04-18 15:39 ` Ted Dennison 2002-04-19 3:16 ` Randy Brukardt 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-18 15:39 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubrt5mbbdrtk10@corp.supernews.com>... > Win32Ada was created under a contract which required Intemetrics to make > it available free. So, of course they did so. Moreover, what they > created is NOT pure, portable, Ada, and in fact is NOT available with I had actually noticed that. I figured that either vendors change the appropriate data types and import conventions to fit their compiler, or they all just happened to use the same ones. > "every appropriate compiler" (in so much as it is not included with > Janus/Ada, and in fact doesn't compile with Janus/Ada, either. We of Ahhh, I stand corrected then. Janus is one I haven't ever had a chance to use (my loss, I'm sure). > it isn't much like the Intermetrics one. That's no real issue, as no one > ought to use Win32Ada anyway: for GUI, use Claw or something else; for > the occassional thread or file system API, bind it in place.) I actually agree completely with this. Low-level bindings are just plain ugly to use, and I see no reason why anyone willing to pay for your compiler shouldn't be willing to shell out the extra dough for Claw. I don't really use Win32Ada myself either, for just that reason. At best, I use it as a guide for developing proper bindings to Win32 myself. :-) > on our website.) You may even be able to talk me to widening that more; > the primary reason for the "non-commercial" restriction is to prevent > people from selling the Introductory version itself (or enhancements of > it), not to prevent people from using it in a commercial environment. We > could find any words that covered the one that didn't cover the other, > or get so complicated as to be impossible to understand. Finally we > decided to use a variation on Aonix's ObjectAda license. I guess it depends on exactly what kind of behavior you want to prevent. If you were to use the GMGPL, then anyone who tried to resell Claw (Introductory) would have to compete with thier customer's ability to download it for free from you or someone else, and they could not prohibit further redistribution. They can't change the license. Given that, it would be tough to justify charging significantly more than media costs. It could be argued that such people would be actually doing you guys a favor by helping to expose your introductory version to more users, without you having to go through the expense of making hard copies and mailing them yourself. The worst I can see happening from your perspective is that its use might take off, and development might outstrip that of your full version. If you were to use the GPL (but license the full version however you want, you can do that since its your copyright), then anyone who uses the introductory version would have to GPL their program. This would still allow for "non-commercial use" like the current license does, but it would also allow for commercial use in GPL programs, and more importantly use in GPL programs themselves. Again, people could redistribute and charge for it, but it would have to be under the GPL. You could even release the *full* version this way, and make a non-GPL-infecting license one of the things that you are selling (in addition to support) to customers. The worst that I could see happen here is that some folks might ignore the license and use the GPL CLAW in non-GPL programs, which would require lawyers to get involved. From my perspective, I'd prefer to see you folks take the first tack. (I'd actually prefer to see you release the full Claw as GMGPL, with paid versions from RR getting media and support, but we've been over that already). But its your perspective that matters. What precisely worries you about doing either of these? -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 15:39 ` Ted Dennison @ 2002-04-19 3:16 ` Randy Brukardt 2002-04-20 5:56 ` Ted Dennison 0 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-19 3:16 UTC (permalink / raw) Ted Dennison wrote in message <4519e058.0204180739.4cbea611@posting.google.com>... >"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubrt5mbbdrtk10@corp.supernews.com>... >> You may even be able to talk me to widening that more; >> the primary reason for the "non-commercial" restriction is to prevent >> people from selling the Introductory version itself (or enhancements of >> it), not to prevent people from using it in a commercial environment. We >> could find any words that covered the one that didn't cover the other, >> or get so complicated as to be impossible to understand. Finally we >> decided to use a variation on Aonix's ObjectAda license. > >I guess it depends on exactly what kind of behavior you want to >prevent. The most important concern is having people sell versions of Claw which really are just the Introductory version. People often get confused between the Introductory version and the Full version. That was a significant problem for us with the Demo compilers that we sold for $30 (media and shipping costs) back in the early days (mid-80s). People complained that they were a toy. Duh! But that "toy" reputation was hard to shake. We need to avoid a repeat. A secondary concern is someone using the Introductory Claw to compete with us (presumably by implementing some of the missing classes). But that probably isn't a real problem; the Introductory Claw contains about 1/3 of the SLOC of the Full Claw (I have been keeping this as an invariant, so each new Introductory Claw is enhanced). So, to truely compete with us, someone would have to (at least) do 30% of the work put in on Claw -- which would be a pretty big job. >If you were to use the GMGPL, then anyone who tried to resell Claw >(Introductory) would have to compete with thier customer's ability to >download it for free from you or someone else, and they could not >prohibit further redistribution. They can't change the license. Given >that, it would be tough to justify charging significantly more than >media costs. It could be argued that such people would be actually >doing you guys a favor by helping to expose your introductory version >to more users, without you having to go through the expense of making >hard copies and mailing them yourself. The worst I can see happening >from your perspective is that its use might take off, and development >might outstrip that of your full version. Right, that might work. >If you were to use the GPL (but license the full version however you >want, you can do that since its your copyright), then anyone who uses >the introductory version would have to GPL their program. This would >still allow for "non-commercial use" like the current license does, >but it would also allow for commercial use in GPL programs, and more >importantly use in GPL programs themselves. Again, people could >redistribute and charge for it, but it would have to be under the GPL. >You could even release the *full* version this way, and make a >non-GPL-infecting license one of the things that you are selling (in >addition to support) to customers. The worst that I could see happen >here is that some folks might ignore the license and use the GPL CLAW >in non-GPL programs, which would require lawyers to get involved. That is also an interesting idea. >From my perspective, I'd prefer to see you folks take the first tack. >(I'd actually prefer to see you release the full Claw as GMGPL, with >paid versions from RR getting media and support, but we've been over >that already). But its your perspective that matters. What precisely >worries you about doing either of these? Well, I have a philosophical objection to the GPL (or, more accurately, Open Source). I believe programmers have an ethical obligation to stand behind their programming. There are exceptions, of course (if the software was stolen, used in a dangerous or illegal way, the software is for obsolete or unobtainable equipment, or the owner of the software fired the programmer), but in general, software should be fixed if practical in a timely fashion. The problem is that the only Open Source business model that works requires charging for fixes. To make that work, it is necessary to provide (much) better service to paid customers, often meaning delaying the availability of public fixes. And I find that mildy distrubing. OTOH, I'm plenty aware that the world has changed. Charging for support has been an important part of RR's business for years. The main problem (personally) is that I have a hard time delaying the support for unsupported customers. I've actually tried to figure out how to delay seeing messages on the Claw mailing list for a couple of days, simply to facilitate that. (This is the same reason I rarely buy a newspaper -- because I feel compelled to read it all -- a time investment I can't make.) So, I'll seriously consider your suggestions. Either may work sufficiently well to adopt. Randy Brukardt. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-19 3:16 ` Randy Brukardt @ 2002-04-20 5:56 ` Ted Dennison 2002-04-20 16:30 ` Robert Dewar 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-20 5:56 UTC (permalink / raw) Randy Brukardt wrote: > Well, I have a philosophical objection to the GPL (or, more accurately, > Open Source). I believe programmers have an ethical obligation to stand > behind their programming. There are exceptions, of course (if the I really didn't understand what you were getting at here, till I got down to this next part: > has been an important part of RR's business for years. The main problem > (personally) is that I have a hard time delaying the support for > unsupported customers. I've actually tried to figure out how to delay > seeing messages on the Claw mailing list for a couple of days, simply to Ahhhh. I think I understand. As someone who has multiple publicly available projects out there, I certianly know the feeling of moral obligation when someone asks for help with a problem in *your* code. With me, occasionally someone will just be so lost that it would take forever to help them out, and I have other commitments (a job, a house and yard, a wife and 2 kids) that preclude me from spending the time to give them the help they need. Its always painful when I have to tell someone I can't help them any further. I think no matter how you go, at some point you do have to draw a line. ACT seems to do it by prioritzing bug fixes in favor of paying customers by being a bit anal about submitted bug reports being in the proper form from unsupported users, and by giving supported customers first dibbs on newly-developed code and bug fixes. It apparently works for them, but I have at times thought I'd have trouble being as rutheless about it as they seem to be. And let's not even get into the fact that asking customers not to redistribute the fixes you give them to non-customers is quite against the spirit of the GPL... > facilitate that. (This is the same reason I rarely buy a newspaper -- > because I feel compelled to read it all -- a time investment I can't > make.) Funny. I have that exact same problem with newspapers too. I tried explaining this to my father-in-law (a retired English teacher and regular newspaper reader) and he looked at me like I had 3 heads. :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 5:56 ` Ted Dennison @ 2002-04-20 16:30 ` Robert Dewar 2002-04-20 18:31 ` tmoran ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-20 16:30 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote in message news:<3CC10367.4000904@telepath.com>... > Randy Brukardt wrote: > > > Well, I have a philosophical objection to the GPL (or, more accurately, > > Open Source). I believe programmers have an ethical obligation to stand > > behind their programming. There are exceptions, of course (if the The GPL has very little to do with Open Source. I would say the above indicates that Randy does not understand the term. The GPL is merely a software license that gives users of your software more rights than most typical licenses. If you say you are philosophically opposed to the GPL, you are simply saying that you are happy only with restrictive licenses that give your users few rights. Hard to see how you could be philosophically in favor of restricting rights in this way, easy enough to see how you could be commercially in favor of such restrictions. And indeed it is clear enough that Randy's objections to open source should be taken with a grain of salt, considering that, like Microsoft, he is in the proprietary software business and finding himself in competition with GPL'ed software :-) > Ahhhh. I think I understand. As someone who has multiple publicly > available projects out there, I certianly know the feeling of moral > obligation when someone asks for help with a problem in *your* code. > With me, occasionally someone will just be so lost that it would take > forever to help them out, and I have other commitments (a job, a house > and yard, a wife and 2 kids) that preclude me from spending the time to > give them the help they need. Its always painful when I have to tell > someone I can't help them any further. And it is *less* painful not to give them anything in the first place??? Sort of like meeting a beggar on the street and deciding to give nothing, because otherwise you will feel a moral obligation to provide food, clothing, and housing :-) > I think no matter how you go, at some point you do have to draw a line. > ACT seems to do it by prioritizing bug fixes in favor of paying customers It is not a matter of prioritizing, ALL our work is aimed at providing services to our customers. You need to get used, as you would with any other company, of assuming that everything we do is aimed at satisfying our existing customers and getting more customers. > by being a bit anal about submitted bug reports being in the proper form > from unsupported users That's because we find it is only worth while for us to pay attention to well submitted reports. We pay attention to such reports not to help those who submit them, to whom we have no obligations at all, but because if the reports are clear and cleanly submitted, then it may be helpful to our customers to fix problems found in this way. Most useful reports from ACT come from a small group of people to whom we have give "external tester" status (those of you reading this know you are). These are people who have in the past submitted helpful reports in a constructive manner, and we give them a special pseudo-customer number and track their submissions. Again, we do this not because of any obligation to this group of people, but because they help us with our primary goal of providing high quality products for our customers. The majority of reports on the public version from outside this group have proved of relatively small value (there are exceptions, but few and far between). Mostly they are people asking questions that could for instance be answered by reading the manual. For our customers, we are more than happy to answer all questions, that's part of what they are paying for, but we have no time for non-customers unless they are helping us! > and by giving supported customers first dibbs on > newly-developed code and bug fixes. It apparently works for them, but I > have at times thought I'd have trouble being as rutheless about it as > they seem to be. How odd .. Ted Dennison is indeed one of the people who over the years has chafed at not being able to get free support, but I don't feel the least bit "ruthless" in not providing Ted any kind of support. We are like any other company, we have to provide services for our customers, we are not some kind of charitable organization that has been set up to keep non-customers like Ted happy :-) > And let's not even get into the fact that asking > customers not to redistribute the fixes you give them to non-customers > is quite against the spirit of the GPL... We have never said this to customers (Ted wouldn't know, he has never been a customer). Now of course this does not mean Boeing is going to take the time, effort (and incur the possible liability) of distributing software to Ted. The GPL is about giving Boeing all the freedom that Boeing needs to make full use of the software. That is relatively unlikely to include sending copies to Ted :-) By the way, I find it highly amusing for Ted to be pontificating on the GPL like this. It is in fact perfectly within the spirit of the GPL to ask (not require) people not to distribute certain software at certain times. For example, the GNU project itself frowns on people taking untested snapshots and making them into widely distributed products. It's just not helpful to the GNU project to have this kind of half baked software wandering around. Richard Stallman certainly would not agree with Ted's assessment of the "spirit of the GPL" here. The spirit of the GPL is about allowing effective sharing of software. Sometimes, effective sharing involves NOT prematurely widely distributing things, and everyone understands this. > Funny. I have that exact same problem with newspapers too. I tried > explaining this to my father-in-law (a retired English teacher and > regular newspaper reader) and he looked at me like I had 3 heads. :-) Yes I can sympathize (with your father-in-law -- most odd indeeed) :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 16:30 ` Robert Dewar @ 2002-04-20 18:31 ` tmoran 2002-04-20 21:32 ` Ted Dennison ` (2 more replies) 2002-04-20 19:41 ` tmoran 2002-04-20 21:16 ` Ted Dennison 2 siblings, 3 replies; 425+ messages in thread From: tmoran @ 2002-04-20 18:31 UTC (permalink / raw) > > > Open Source). I believe programmers have an ethical obligation to stand > > > behind their programming. > > The GPL has very little to do with Open Source. I would say the above > indicates that Randy does not understand the term. The GPL is merely a Perhaps I shouldn't be guessing what Randy meant, but I suspect he was thinking "in practice" rather than "in theory", and considering the "give it away for free, charge a bundle for support" model for GPL product funding. That model requires that you do support only for cash, ignoring any latent feelings of obligation to stand behind your programming. > The GPL is merely a software license that gives users of your software > more rights ... Different, not More. A set of rights is not one-dimensional with an obvious ordering. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 18:31 ` tmoran @ 2002-04-20 21:32 ` Ted Dennison 2002-04-22 0:30 ` Larry Kilgallen 2002-04-21 0:57 ` Robert Dewar 2002-04-21 1:03 ` Robert Dewar 2 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-20 21:32 UTC (permalink / raw) tmoran@acm.org wrote: >>The GPL is merely a software license that gives users of your software >>more rights ... >> > Different, not More. A set of rights is not one-dimensional with an > obvious ordering. I'd say different, and almost always more. I've certianly never read a shrink-wrap software license that gives me as much freedom as the GPL. Usually they say you can't do anything, and then list a few exceptions (eg: install on one machine, make one backup copy, etc). The GPL bascily says I can do anything, then lists a few exceptions. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 21:32 ` Ted Dennison @ 2002-04-22 0:30 ` Larry Kilgallen 2002-04-22 13:40 ` Robert Dewar 2002-04-22 14:27 ` Ted Dennison 0 siblings, 2 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-22 0:30 UTC (permalink / raw) In article <3CC1DEF2.4060204@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > tmoran@acm.org wrote: > >>>The GPL is merely a software license that gives users of your software >>>more rights ... >>> >> Different, not More. A set of rights is not one-dimensional with an >> obvious ordering. > > > I'd say different, and almost always more. I've certianly never read a > shrink-wrap software license that gives me as much freedom as the GPL. > Usually they say you can't do anything, and then list a few exceptions > (eg: install on one machine, make one backup copy, etc). The GPL bascily > says I can do anything, then lists a few exceptions. That is in the end-user dimension. The licensing for many commercial libraries included into other products allows modifications to those libraries without distributing those changes. Those libraries allow "more" in the software vendor dimension. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 0:30 ` Larry Kilgallen @ 2002-04-22 13:40 ` Robert Dewar 2002-04-22 14:27 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-22 13:40 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<+JjhQCmJYCyP@eisner.encompasserve.org>... > That is in the end-user dimension. > > The licensing for many commercial libraries included into other products > allows modifications to those libraries without distributing those changes. > Those libraries allow "more" in the software vendor dimension. Just like the GNAT run-time library for example ... ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 0:30 ` Larry Kilgallen 2002-04-22 13:40 ` Robert Dewar @ 2002-04-22 14:27 ` Ted Dennison 2002-04-22 17:40 ` Ted Dennison 2002-04-22 17:48 ` Robert Dewar 1 sibling, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-22 14:27 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<+JjhQCmJYCyP@eisner.encompasserve.org>... > In article <3CC1DEF2.4060204@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > > tmoran@acm.org wrote: > > > >>>The GPL is merely a software license that gives users of your software > >>>more rights ... > >>> > >> Different, not More. A set of rights is not one-dimensional with an > >> obvious ordering. > > > > > > I'd say different, and almost always more. I've certianly never read a > > shrink-wrap software license that gives me as much freedom as the GPL. > > Usually they say you can't do anything, and then list a few exceptions > > (eg: install on one machine, make one backup copy, etc). The GPL bascily > > says I can do anything, then lists a few exceptions. > > That is in the end-user dimension. > > The licensing for many commercial libraries included into other products > allows modifications to those libraries without distributing those changes. > Those libraries allow "more" in the software vendor dimension. Errr...The GPL *also* allows modifications to GPL-ed software without distributing those changes. It also allows modifications *with* distributing the changes, under some circumstances. I have yet to see how anyone has less freedom this way. As fate would have it, today Eben Moglen, the lawyer for the FSF, has put an article up at http://moglen.law.columbia.edu/publications/lu-12.html that touches on this very subject. (Those of you who don't like reading "GPL propaganda" would do well to skip the first two paragraphs). His basic thesis is that defending the GPL is a breeze compared to other licenses, becuase other licenses generally try to make you trade some of your legal rights away, while the GPL just *gives* you rights that you would not otherwise have. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 14:27 ` Ted Dennison @ 2002-04-22 17:40 ` Ted Dennison 2002-04-22 17:48 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-22 17:40 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204220627.4da138a8@posting.google.com>... > As fate would have it, today Eben Moglen, the lawyer for the FSF, has > put an article up at > http://moglen.law.columbia.edu/publications/lu-12.html that touches on Err...change "today" to "today I discovered that". The article itself seems to be fairly on. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 14:27 ` Ted Dennison 2002-04-22 17:40 ` Ted Dennison @ 2002-04-22 17:48 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Robert Dewar @ 2002-04-22 17:48 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0204220627.4da138a8@posting.google.com>... > As fate would have it, today Eben Moglen, the lawyer for > the FSF, has put an article up at > http://moglen.law.columbia.edu/publications/lu-12.html > that touches on this very subject. Yes, indeed a useful reference, thanks Ted for posting this. Note that in practice it is important that typical GNU compilers, including GNU-C, g++ and GNAT are issued with relaxed licensing on the runtime that spefically allows uses of this runtime (or a modification of it) without imposing GPL licensing on the result ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 18:31 ` tmoran 2002-04-20 21:32 ` Ted Dennison @ 2002-04-21 0:57 ` Robert Dewar 2002-04-21 5:23 ` tmoran 2002-04-21 1:03 ` Robert Dewar 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-21 0:57 UTC (permalink / raw) tmoran@acm.org wrote in message news:<Itiw8.3027$Wl4.1626920993@newssvr14.news.prodigy.com>... > and considering the "give > it away for free, charge a bundle for support" model for > GPL product funding. That model requires that you do > support only for cash Well perhaps some software is sold on that model, I am not sure what but that's certainly not the Ada Core Technologies model. We provide licensed copyrighted software bundled with support (a not unusual model). Yes, there are some public versions of GNAT, but they are, from the point of view of our customer base, quite different. (warning remember that I have a definite interest in the success of ACT, so read the following with that in mind, just as you need to remember that Tom Moran is involved in commercial products that are to some extent competitive with ACT, and which have a very different model). If a customer gets GNAT Pro, they are getting a software product that is fully backed by our company. They know that it has been extensively tested, They know that it is properly licensed (a real concern for many users, since you never really know the license situation of stuff you download from miscellaneous places). They know that ACT will stand behind the product, and they know that ACT support is unusual in that they have immediate access to our entire engineering staff, for help not only with problems with GNAT Pro, but general problems and questions in the use of Ada and bring their projects to a successful conclusion. Ada Core Technologies is definitely not in the business of giving things away! > ignoring any latent feelings of obligation to stand > behind your programming. We definitely stand behind GNAT Pro, and will make sure that users of GNAT Pro are successful in their use of this product. From time to time we make public binaries available, and we make the sources available at gnu.org, and we do this because we think it is generally advantageous to the Ada community, but this is done on the basis that there is no support from us. If people find that worrisome, they should stay away from unsupported software, but for students and hobbyists and academic researchers, it is often quite acceptable to use unsupported software, and we hope that the public versions of GNAT will be helpful. What some people seem to be saying is "Hey you shouldn't make this stuff public, unless you are willing to stand behind it and support it!" Well that's not the way the world works. There is no free lunch here. If some philanthropist wants to make a significant donation to support the binary version, then that would change things. So if we really thought people agreed with this quote, we would have to react by simply not making it available (remember that the GPL never forces ACT or anyone else to distribute anything). That would be too bad, and in fact we know perfectly well that the great majority of users of the public version understand the situation exactly. Indeed, the criticisms often come from competitors who definitely do NOT make their software available, so you have to wonder :-) > > The GPL is merely a software license that gives users > > of your software > > more rights ... > Different, not More. A set of rights is not o > one-dimensional with an > obvious ordering. I disagree in this case, my specific comparison was with the Microsoft license, and it is clear that the GPL and GMGPL as used by Ada Core Technologies gives you absolutely *ALL* the rights you get from Microsoft, plus a whole lot more. Indeed I would be very surprised to see any license from any seller of proprietary software that was not a subset of the rights you have with GNAT Pro. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 0:57 ` Robert Dewar @ 2002-04-21 5:23 ` tmoran 2002-04-21 15:59 ` Robert Dewar 0 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-21 5:23 UTC (permalink / raw) > > > The GPL is merely a software license that gives users > > > of your software more rights ... > > Different, not More. A set of rights is not > > one-dimensional with an obvious ordering. > > I disagree in this case, my specific comparison was with > the Microsoft license, Well why didn't you say so. > and it is clear that the GPL and GMGPL as used The GMGPL is quite different from the GPL. The GPL significantly restricts what I can do with GPLed software, in a way that other licenses commonly don't. It's misleading nonsense to say flatly "McDonald's is less restrictive than Hamburger Hamlet because it lets me order an Egg McMuffin". ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 5:23 ` tmoran @ 2002-04-21 15:59 ` Robert Dewar 2002-04-21 17:47 ` tmoran 0 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-21 15:59 UTC (permalink / raw) tmoran@acm.org wrote in message news:<r1sw8.3545$Dh5.1795316993@newssvr14.news.prodigy.com>> The GMGPL is quite different from the GPL. The GPL > significantly restricts what I can do with GPLed > software, in a way that other licenses > commonly don't. You are setting up a strawman here. For tools, like Powerpoint say, it is absolutely clear that similar tools that are GPL'ed give you uniformly MORE rights than Microsoft (or any other similar company would give you). For libraries, it is standard (and recommended practice) to use a license like the GMGPL, and when this is done the same comment applies. So the practical situation in the world is that Free Software virtually always comes with uniformly more rights. Tom, you certainly have a motive to argue against the use of the GPL, GMGPL etc, since you work for a company represented by someone who has "philosophical objections" to the GPL, and you have chosen to work on software that most definitely is not free software. I understand this, and as I have said before I strongly support people's right to use any license they please. But if you argue that your licensing policy is in any sense superior from a users point of view, let's have the argument on the basis of the real and not the imaginary :-) Please compare CLAW with any commercial free software library, and describe the manner in which CLAW provides more rights. That seems a fair challenge to me, I am allowing you to pick absolutely any commercial free software, it does not have to be GNAT (I perfectly well understand that you might be able to find some non-commercial software that was rerstricted, but that's really comparing apples and oranges to me). It's misleading nonsense to say flatly "McDonald's is > less restrictive than Hamburger Hamlet because it lets me order an Egg > McMuffin". ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 15:59 ` Robert Dewar @ 2002-04-21 17:47 ` tmoran 0 siblings, 0 replies; 425+ messages in thread From: tmoran @ 2002-04-21 17:47 UTC (permalink / raw) > Tom, you certainly have a motive to argue against the Where I come from that's called "resorting to ad hominem argument" and it's recognized that it has nothing to do with the merits of a case. > significantly restricts what I can do with GPLed > software, in a way that other licenses The original statement was: > The GMGPL is quite different from the GPL. The GPL significantly >restricts what I can do with GPLed software, in a way that other licenses So your defense of the GPL on the basis of the lessened restrictions in the GMPL amounts to quoting out of context. That may be OK in propaganda, but it's recognized as inimical to exploring the merits of a case. I'm not interested in a propaganda battle. If you are not interested in a clear exploration of the merits of the case, then we have nothing to discuss. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 18:31 ` tmoran 2002-04-20 21:32 ` Ted Dennison 2002-04-21 0:57 ` Robert Dewar @ 2002-04-21 1:03 ` Robert Dewar 2002-04-21 9:07 ` Florian Weimer 2 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-21 1:03 UTC (permalink / raw) tmoran@acm.org wrote in message news:<Itiw8.3027$Wl4.1626920993@newssvr14.news.prodigy.com> > Different, not More. A set of rights is not > one-dimensional with an obvious ordering. Tom, since you work with RR, which markets proprietary products with a proprietary license, here is a specific challenge. In what respect do the rights conveyed to a user by RR exceed those conveyed by Ada Core Technologies? It's certainly the case that some licenses DO convey more rights, e.g. the BSD license. Microsoft certainly prefers the BSD license to the GPL (though they of course would use neither themselves) since they can take BSD stuff and incorporate it into their proprietary products. We deliberately prohibit Microsoft from doing this, just as they prohibit us from using their software (indeed they don't even give us the sources :-) One thing I should make clear is that I am not saying I disapprove of the license that RR uses (unlike Randy who philosophically objects to our licensing). I think that companies may use any license that makes sense to them, that's the way copyright works. We prefer to use a rather free license because, as I said before, this is better for our customers, and we find it is smart from all points of view to give our customers what they need! Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 1:03 ` Robert Dewar @ 2002-04-21 9:07 ` Florian Weimer 2002-04-22 15:11 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Florian Weimer @ 2002-04-21 9:07 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > It's certainly the case that some licenses DO convey more > rights, e.g. the BSD license. Microsoft certainly prefers the BSD > license to the GPL (though they of course would > use neither themselves) Of course they use the GPL only if they have to (e.g. for parts of Interix), but they pay at least one person for working on free software which is licensed under the BSD license (and no, it doesn't run only on Windows)... ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 9:07 ` Florian Weimer @ 2002-04-22 15:11 ` Marin David Condic 2002-04-23 15:38 ` Hyman Rosen 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-22 15:11 UTC (permalink / raw) The problem with any license is that once it gets expensive enough or restrictive enough, sooner or later someone says "Go Pound Sand!" If someone says "Here's Library X under the GPL..." and Microsoft doesn't want to be forced into GPL'ing their stuff just to use Library X, they're going to go hire a few dozen programmers and say "Go make me something that looks kind of like this..." They certainly have the money they need not to be cornered into using someone else's stuff for lack of ability to build one of their own. Hoping that one day they'll accidentally include some GPL'ed code into Microsoft Office and be forced to release their source is probably unrealistic. I don't begrudge Microsoft using any license they like and I seriously doubt that the bulk of their customers care if they get the source code or not. If you don't like their license - go buy something else. That's the free market system. Maybe one day the Open Source crowd will have everyone using their products and insisting they get the source or they won't buy and Microsoft will go the way of Studebaker. I'm just not going to hold my breath waiting for that event. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87vgalbetj.fsf@deneb.enyo.de... > > Of course they use the GPL only if they have to (e.g. for parts of > Interix), but they pay at least one person for working on free > software which is licensed under the BSD license (and no, it doesn't > run only on Windows)... ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 15:11 ` Marin David Condic @ 2002-04-23 15:38 ` Hyman Rosen 2002-04-23 16:03 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Hyman Rosen @ 2002-04-23 15:38 UTC (permalink / raw) Marin David Condic wrote: > Hoping that one day they'll accidentally include some GPL'ed code into > Microsoft Office and be forced to release their source is probably > unrealistic. If it was discovered that MSO included GPLed code, MS could choose to honor the GPL and distribute the source, or they could stop selling the version of the product which included the GPLed code. This would generally mean that unsold product (store shelves, or at distributors) would be recalled, but people who have bought copies would be permitted to keep them. If the violation is found to be deliberate, then various civil or criminal penalties could apply, but it's unlikely that revealing the MSO sources would be part of the penalty. Remember, if someone commits a copyright violation, the copyright holder does not get to decide what the penalty should be. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-23 15:38 ` Hyman Rosen @ 2002-04-23 16:03 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-23 16:03 UTC (permalink / raw) Well, that's kind of the point. For one thing, Microsoft isn't likely to want to open itself to liability by using GPL'ed code and then not handing out the source. Better to simply spend a million or so having an in-house team develop their own version that they control. What does it buy them to try to gain leverage with GPL'ed code? For another thing, Microsoft has little to zero incentive to want to expose their code publically. That could only benefit their competitors. So why would they one day have a change of heart and decide to start GPL-ing things? Finally, I doubt very much that the bulk of their customers care if they get the source code or not. Arguing that somehow the customer is going to gain some benefit like protection from Microsoft going out of business (probably not in my lifetime or at least the useful life of the software) or that they can get third-party support (they can get training and help now, but no bug-fix/feature changes - yet still they buy, so why should Microsoft care?) just doesn't seem to carry much weight. Maybe one day Open Source vendors will overtake Microsoft. I just don't see Microsoft giving up and joining the Open Source strategy either by accident or design so long as they are on top. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3CC57FEA.8020208@mail.com... > > If it was discovered that MSO included GPLed code, MS > could choose to honor the GPL and distribute the source, > or they could stop selling the version of the product > which included the GPLed code. This would generally mean > that unsold product (store shelves, or at distributors) > would be recalled, but people who have bought copies > would be permitted to keep them. If the violation is > found to be deliberate, then various civil or criminal > penalties could apply, but it's unlikely that revealing > the MSO sources would be part of the penalty. > > Remember, if someone commits a copyright violation, the > copyright holder does not get to decide what the penalty > should be. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 16:30 ` Robert Dewar 2002-04-20 18:31 ` tmoran @ 2002-04-20 19:41 ` tmoran 2002-04-21 0:28 ` Richard Riehle 2002-04-20 21:16 ` Ted Dennison 2 siblings, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-20 19:41 UTC (permalink / raw) > > I certianly know the feeling of moral obligation when someone asks > > for help with a problem in *your* code. > > ... > > Its always painful when I have to tell > > someone I can't help them any further. > > And it is *less* painful not to give them anything in the first > place??? > Sort of like meeting a beggar on the street and deciding to give > nothing, > because otherwise you will feel a moral obligation to provide food, > clothing, > and housing :-) Perhaps giving them software, then not helping when they get stuck, is more like finding a beggar, showing him the beer and chips in your car, driving him out to the beautiful countryside, set him down to munch the salty chips, then, when he asks for a beer, you announce the beer, and the ride back to town, are expensive. I suppose there are those who would claim the moral high ground "but I fed the beggar". ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 19:41 ` tmoran @ 2002-04-21 0:28 ` Richard Riehle 2002-04-21 0:33 ` Jason King 2002-04-22 15:22 ` Marin David Condic 0 siblings, 2 replies; 425+ messages in thread From: Richard Riehle @ 2002-04-21 0:28 UTC (permalink / raw) tmoran@acm.org wrote: > > Perhaps giving them software, then not helping when they get stuck, > is more like finding a beggar, showing him the beer and chips in your > car, driving him out to the beautiful countryside, set him down to > munch the salty chips, then, when he asks for a beer, you announce the > beer, and the ride back to town, are expensive. I suppose there are > those who would claim the moral high ground "but I fed the beggar". Someone once described a difference between conservative and a liberal this way. The conservative throws a rope toward a drowning man but makes him swim part of the way to reach it. A liberal throws the rope directly to him and lets go of the rope before he reaches shore. What do you call someone who throws the rope, requires the drowning person to swim for it, and then lets go of the rope too? ACT, when working on behalf of its customers, throws them a rope and requires them to do their part. This seems an appropriate business model. Free GNAT is a rope that has no one holding it at the shoreline end, and you still have to swim a little bit to use it properly. Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 0:28 ` Richard Riehle @ 2002-04-21 0:33 ` Jason King 2002-04-22 15:22 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Jason King @ 2002-04-21 0:33 UTC (permalink / raw) Guys, Get a grip. You're complaining about the quality of support for a FREE product! Support costs money to provide. If you want support buy a product that costs money, don't sit around whining about how the free compiler you get doesn't come with vendor provided support. Richard Riehle wrote: > tmoran@acm.org wrote: > > >> Perhaps giving them software, then not helping when they get stuck, >>is more like finding a beggar, showing him the beer and chips in your >>car, > Free GNAT is a rope that has no one holding it at the shoreline end, > and you still have to swim a little bit to use it properly. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-21 0:28 ` Richard Riehle 2002-04-21 0:33 ` Jason King @ 2002-04-22 15:22 ` Marin David Condic 2002-04-23 4:09 ` Randy Brukardt 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-22 15:22 UTC (permalink / raw) I remember the days when acquiring an Ada compiler required maybe five to six figures and you couldn't run them on just any old PC. Now I can download GNAT at no cost from a modest PC and it installs without much fuss and basically works. Am I going to complain because I can't afford ACT support for my hobbyist/hacker projects? Not likely. Nor do I feel like I really *need* much support for the things I'm doing. If ACT wants to make any version of GNAT available to the general public at no cost, more power to them and thanks a lot. Its more than I had pre-GNAT. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Richard Riehle" <richard@adaworks.com> wrote in message news:3CC207BA.5F039C6D@adaworks.com... > > Someone once described a difference between conservative and a > liberal this way. The conservative throws a rope toward a drowning > man but makes him swim part of the way to reach it. A liberal throws > the rope directly to him and lets go of the rope before he reaches shore. > What do you call someone who throws the rope, requires the drowning > person to swim for it, and then lets go of the rope too? > > ACT, when working on behalf of its customers, throws them a rope and > requires them to do their part. This seems an appropriate business > model. > Free GNAT is a rope that has no one holding it at the shoreline end, > and you still have to swim a little bit to use it properly. > > Richard Riehle > > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-22 15:22 ` Marin David Condic @ 2002-04-23 4:09 ` Randy Brukardt 2002-04-23 5:30 ` Simon Wright 2002-04-23 13:28 ` Development process in the Ada community Marin David Condic 0 siblings, 2 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-23 4:09 UTC (permalink / raw) Marin David Condic wrote in message ... >I remember the days when acquiring an Ada compiler required maybe five to >six figures and you couldn't run them on just any old PC. Sigh. Nothing like reminscing about the bad old days. There were always affordable PC compilers (including Janus/Ada on 56K Z-80 CP/M machines). I suppose you might be able to find a year (1986?) which would meet this description if you required a validated Ada compiler; but in the years before it there were no validated Ada compilers that ran on PCs at all, and in the years after it, there was Janus/Ada (starting at $99) and Merdian and Ada/Ed. Janus/Ada just required a 640K PC (which was pretty standard by then). >Now I can download GNAT at no cost from a modest PC and it installs without much fuss and >basically works. Of course, a "modest PC" now has 100 times the memory and is 100 times faster. Hardly a fair comparison. About the only difference is the cost ($99 versus nothing). Certainly Janus/Ada "basically worked". Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-23 4:09 ` Randy Brukardt @ 2002-04-23 5:30 ` Simon Wright 2002-04-26 18:25 ` Randy Brukardt 2002-04-23 13:28 ` Development process in the Ada community Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-23 5:30 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Of course, a "modest PC" now has 100 times the memory and is 100 > times faster. Hardly a fair comparison. About the only difference is > the cost ($99 versus nothing). Certainly Janus/Ada "basically > worked". Yep, I remember that! Even so far as having shared generics, if I remember correctly. The modest PC I used was an 8 MHz PC-AT clone with 2 MB RAM and 20 MB HDD. Sigh. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-23 5:30 ` Simon Wright @ 2002-04-26 18:25 ` Randy Brukardt 2002-04-29 14:44 ` Shared generics Hyman Rosen 0 siblings, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-26 18:25 UTC (permalink / raw) Simon Wright wrote in message ... >"Randy Brukardt" <randy@rrsoftware.com> writes: > >> Of course, a "modest PC" now has 100 times the memory and is 100 >> times faster. Hardly a fair comparison. About the only difference is >> the cost ($99 versus nothing). Certainly Janus/Ada "basically >> worked". > >Yep, I remember that! Even so far as having shared generics, if I >remember correctly. Yes, Janus/Ada 95 still has shared generics. Really ugly to get right in Ada 95 (Ada 83 was much easier that way). Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Shared generics 2002-04-26 18:25 ` Randy Brukardt @ 2002-04-29 14:44 ` Hyman Rosen 2002-04-29 19:47 ` Randy Brukardt 0 siblings, 1 reply; 425+ messages in thread From: Hyman Rosen @ 2002-04-29 14:44 UTC (permalink / raw) Randy Brukardt wrote: > Yes, Janus/Ada 95 still has shared generics. Really ugly to get right in > Ada 95 (Ada 83 was much easier that way). I have a question about Ada generics. If I have understood my text book correctly, one can instantiate a generic with a local variable as a parameter. This is different from C++, where a variable used as a generic parameter must be global. So it seems to me that at least some Ada generics *must* be implemented by sharing, rather than *can* be. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Shared generics 2002-04-29 14:44 ` Shared generics Hyman Rosen @ 2002-04-29 19:47 ` Randy Brukardt 0 siblings, 0 replies; 425+ messages in thread From: Randy Brukardt @ 2002-04-29 19:47 UTC (permalink / raw) Hyman Rosen wrote in message <3CCD5C64.2030303@mail.com>... >Randy Brukardt wrote: >> Yes, Janus/Ada 95 still has shared generics. Really ugly to get right in >> Ada 95 (Ada 83 was much easier that way). > >I have a question about Ada generics. If I have understood >my text book correctly, one can instantiate a generic with >a local variable as a parameter. This is different from C++, >where a variable used as a generic parameter must be global. Yes, of course generic instantiations can be in nested scopes, and there are no restrictions on the parameters. >So it seems to me that at least some Ada generics *must* be >implemented by sharing, rather than *can* be. Depends on what you mean here. Clearly, the instantiation will be elaborated every time that the outer subprogram is called. So in that sense, the generic is 'shared'. Of course, that means that you are thinking of the subprogram body itself as 'shared' as well. That is not the conventional meaning of 'shared' when talking about generics. The basic idea is whether or not the code for the generic appears at the point of the instantiation, tailored for the parameters. Sharing occurs when two or more (textual) instantiations share part of the code for the generic unit (usually the body). This can vary from partial sharing (where what is shared depends on the parameters to the instantiation) to universal sharing (where there is only a single copy of the code for the generic unit, which is used by all instantiations). When an instantiation occurs in a subprogram, there is only one copy of the code for that instantiation, just as there is only one copy of the code for the subprogram body. This is not considered that sharing, because no (sane) implementation would generate multiple copies of the code for a single subprogram body, and the instantiation is just part of that body. Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-23 4:09 ` Randy Brukardt 2002-04-23 5:30 ` Simon Wright @ 2002-04-23 13:28 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-23 13:28 UTC (permalink / raw) I actually owned the Janus Ada compiler back then, but I've been hanging around Ada since probably about 1980 when it was first being discussed & draft standards were being published. The first Ada compiler I owned was the Telesoft Ada compiler and that was not validated. IIRC, the version of Janus Ada I owned was not validated either. There was a time back in The Bad Old Days when if you wanted a validated compiler, they couldn't be had except on some rather expensive platforms and at some rather steep prices and generally there were lots of reasons not to be happy with what they (or the companies that sold them) did. Certainly Janus Ada was a turning point in the history of Ada in that it made it accessible at a price within the bounds of an average programmer. And of course what today is considered "modest" hardware would have been considered fast/big for a mainframe back then. One of the things that hurt Ada was that it was ahead of the hardware needed by a few years. Once we got beyond 640k limits and hard drives didn't require a bank note to buy, the environment was there - but already the bad reputation had got started. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:uc9nipnjt9615c@corp.supernews.com... > > Sigh. Nothing like reminscing about the bad old days. There were always > affordable PC compilers (including Janus/Ada on 56K Z-80 CP/M machines). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-20 16:30 ` Robert Dewar 2002-04-20 18:31 ` tmoran 2002-04-20 19:41 ` tmoran @ 2002-04-20 21:16 ` Ted Dennison 2 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-20 21:16 UTC (permalink / raw) Robert Dewar wrote: > Ted Dennison <dennison@telepath.com> wrote in message news:<3CC10367.4000904@telepath.com>... > >>With me, occasionally someone will just be so lost that it would take >>forever to help them out, and I have other commitments (a job, a house >>and yard, a wife and 2 kids) that preclude me from spending the time to >>give them the help they need. Its always painful when I have to tell >>someone I can't help them any further. >> > > And it is *less* painful not to give them anything in the first > place??? > Sort of like meeting a beggar on the street and deciding to give > nothing, > because otherwise you will feel a moral obligation to provide food, > clothing, > and housing :-) I'm not sure how your analogy relates to what I said at all (perhaps you thought I was talking about not helping at all, rather than giving up when there's no more I can reasonably do?). However, that is actually a fair charactarization of my attitude toward beggars, so perhaps you are onto something. :-) >>by being a bit anal about submitted bug reports being in the proper form >>from unsupported users >> > > That's because we find it is only worth while for us to pay attention > to well submitted reports. We pay attention to such reports not to help those Exactly. I wasn't trying to complain about it, so no explanation was really nessecary. I was pointing out what I thought was a pretty effective policy of yours. > How odd .. Ted Dennison is indeed one of the people who over the years > has chafed at not being able to get free support, but I don't feel the > least bit "ruthless" in not providing Ted any kind of support. We are like any Hmmm. I really don't remember ever having any big problem with ACT not doing free work for me. However, we've both been around here a very long time, and my memory's notoriously bad, so I'll grant that I could be wrong. If I ever did cop that kind of attitude, I'm sorry. That's a really stupid way for me (or anyone else) to behave. OK...now that I think about it there was that one time I fatally flubbed a bug report (in a way that would have required work on ACT's part to straighten it out). But that was my own stupid fault. You were absolutely right to bounce it. >For >example, the GNU project itself frowns on people taking untested >snapshots >and making them into widely distributed products. It's just not >helpful to ... > "spirit of the GPL" here. The spirit of the GPL is about allowing > effective > sharing of software. Sometimes, effective sharing involves NOT > prematurely > widely distributing things, and everyone understands this. I guess you're right there, as far as the current situation goes. It was really more of an issue in days gone by, when there was no public baseline like typical GNU projects have to go to for interim bug fixes. Thus you were effectively asking people not to allow anyone else access to baselined bug fixes. Since Gnat is part of the gcc baseline now, we don't really have that problem any more. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 20:41 ` tmoran 2002-04-15 14:45 ` Ted Dennison @ 2002-04-15 17:19 ` Marin David Condic 2002-04-17 18:09 ` Ted Dennison 2002-04-16 8:29 ` Georg Bauhaus 2 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-15 17:19 UTC (permalink / raw) I certainly wouldn't mind at all adopting an existing solution as the starting point for a standard. The problem is quite often that everybody has a different idea about what they want and short of having a solution unilaterally imposed on them, agreement isn't likely. If Claw could evolve into a generic interface for GUI building (rather than be Windows specific) then I have no objection to it. It might even be fair to say "Here's the 'official' Ada interface to Windows..." and see if it could migrate elsewhere at a later point. But if it were to stand a chance of success, the best way I can think of it getting accepted would be if it were shipped with most of the Ada compilers out there so that the developer's thinking would have to be: "Well, I may not like it, but its here and certainly a lot easier to take advantage of than to roll my own or go looking for an alternative..." MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com <tmoran@acm.org> wrote in message news:zPlu8.90$2a2.158913722@newssvr13.news.prodigy.com... > > Why is it that the available solutions are a mile wide but an inch deep? > Everybody wants to build an alternative to X, but nobody wants to build on > top of X. What are the rewards/difficulties of building a new alternative > to X? What are the rewards/difficulties of building something more complex > that -uses- X? Apparently the latter is worse. > > As Randy Brukardt noted the other day, the original idea for Claw "was to > create a de facto standard, make a subset freely available, and eventually > put the binding into the public domain to be a standard." But it didn't > happen. Recently someone complained that Claw didn't currently support > several features he needs. Nobody, to my knowledge, has added support for > X to Claw, but multiple people have created alternative Windows bindings, > none of which has become a standard, and none of which supports the > features that writer needed. So he plans to use C++. The same for > "a lot of open source software solutions covering ..." > > Given all the time in the world, it's a fine thing to "let 100 flowers > bloom" and explore all the alternative ways of doing X. That does not get > you beyond X, however. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 17:19 ` Marin David Condic @ 2002-04-17 18:09 ` Ted Dennison 2002-04-17 20:42 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-17 18:09 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9f22c$av7$1@nh.pace.co.uk>... > I certainly wouldn't mind at all adopting an existing solution as the > starting point for a standard. The problem is quite often that everybody has > a different idea about what they want and short of having a solution > unilaterally imposed on them, agreement isn't likely. If Claw could evolve > into a generic interface for GUI building (rather than be Windows specific) > then I have no objection to it. It might even be fair to say "Here's the > 'official' Ada interface to Windows..." and see if it could migrate > elsewhere at a later point. I doubt that. There's just too many different systems out there for there to ever be only one. No matter what you do, there are going to be people who want their OS's standard OS look and feel, or who want to use stuff like DirectX or OpenGL. > But if it were to stand a chance of success, the best way I can think of it > getting accepted would be if it were shipped with most of the Ada compilers > out there so that the developer's thinking would have to be: "Well, I may > not like it, but its here and certainly a lot easier to take advantage of > than to roll my own or go looking for an alternative..." ...which is precisely what was done with Win32Ada. Exactly. In another post I called this something like "standardization path 1". Path 2 (release it publicly and hope everyone uses it) is probably a distant second, and nothing else is even in the ballpark. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 18:09 ` Ted Dennison @ 2002-04-17 20:42 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-17 20:42 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0204171009.30336212@posting.google.com... > > ...which is precisely what was done with Win32Ada. Exactly. In another > post I called this something like "standardization path 1". Path 2 > (release it publicly and hope everyone uses it) is probably a distant > second, and nothing else is even in the ballpark. > > I agree and Win32Ada is an excellent example of how some packages/libraries can become a lower-case "standard" just because the vendors make it come along for the ride. Win32Ada may be "icky", but people use it just because they can count on it being there. So IMHO, the same sort of thing could be done with data structures, math libraries, etc., to the benefit of Ada. It might even be possible to have it done for more complex things like a GUI - a platform-specific standard but the one that all vendors deliver if they target that platform. Evidence indicates that the technique will work, but the hard part is the process for getting "Library X" into everyone's distribution. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-14 20:41 ` tmoran 2002-04-15 14:45 ` Ted Dennison 2002-04-15 17:19 ` Marin David Condic @ 2002-04-16 8:29 ` Georg Bauhaus 2002-04-16 13:31 ` Marin David Condic 2002-04-16 17:46 ` tmoran 2 siblings, 2 replies; 425+ messages in thread From: Georg Bauhaus @ 2002-04-16 8:29 UTC (permalink / raw) tmoran@acm.org wrote: : Nobody, to my knowledge, has added support for : X to Claw, but multiple people have created alternative Windows bindings, : none of which has become a standard, and none of which supports the : features that writer needed. some wild guesses: Is it too well done, triggering the expectation of a lot of learning to do for serious use? Popularity problem in Free Software days? (i.e., not politically correct :-) :-) :-) Is there no way of asking business clients to pay you for your work even if the license doesn't require them (or others) to do so? I, for one, have no problem of paying craftspeople if I need their service, and I think I'm not alone. Georg Bauhaus ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-16 8:29 ` Georg Bauhaus @ 2002-04-16 13:31 ` Marin David Condic 2002-04-16 17:46 ` tmoran 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-16 13:31 UTC (permalink / raw) Lots of models have been tried with mixed success. How exactly do you say "Here, you can have this product free of charge, but if you feel like it you can give me some money..." and get that to generate the kind of revenue needed to continue to support & enhance the product? For something like Gnat, the model is "You can have the product free of charge, but enough people will want support to pay for it and that keeps the project afloat." It apparently works for a compiler reasonably well, but lots of products have little to zero demand for support. Others have tried "You can have the source code free of charge, but if you'd like pre-compiled versions with documentation, we can do that for a price..." That works for other things like Linux or RTEMS. Crippled versions of things at no charge with full-features available at a price has sometimes worked - but that doesn't work well if you are of the One True Religion of "Open Source" :-) At the end of the day, products need people to develop/enhance/support them and those people need to do things like eat and pay rent, so *somebody* is going to have to pay the freight. Even the "free" software out there is paid for via the developer(s) generosity with their time or their employer's subsidizing the effort in some manner. I'm of the belief that if Ada developers find a way to make Ada development pay, it will create more Ada developers - and that's a good thing for all of us. (How many times do we see posts with some version of "Ada may be cool, but why should I waste my time learning it if I can't get a job doing it....?" :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:a9gnce$9td$2@a1-hrz.uni-duisburg.de... > > Is there no way of asking business clients to pay you for your > work even if the license doesn't require them (or others) to do > so? I, for one, have no problem of paying craftspeople if I need > their service, and I think I'm not alone. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-16 8:29 ` Georg Bauhaus 2002-04-16 13:31 ` Marin David Condic @ 2002-04-16 17:46 ` tmoran 2002-04-17 3:34 ` Richard Riehle 1 sibling, 1 reply; 425+ messages in thread From: tmoran @ 2002-04-16 17:46 UTC (permalink / raw) > : Nobody, to my knowledge, has added support for > : X to Claw, but multiple people have created alternative Windows bindings, Sorry, I didn't mean that nobody has added anything to Claw since its birth, I meant nobody has recently become a new Claw developer. People could post additional Claw modules in the public domain or with a license of their choosing, either to work with full ($>0) Claw, or to work with the $=0 version, or they could make an arrangement with RR Software. Claw is pretty straightforwardly structured (see the original TriAda article at www.rrsoftware.com) so it wouldn't be all that hard. Maybe people have been bombarding Randy Brukardt with offers to do this, but I doubt it. A previous writer asked for interfaces to midi, data entry widgets with popup calculator, etc. etc. so there is demand. But multiple people have spent a lot of time creating alternative Windows bindings. Not that those aren't good, especially when, as in JEWL, they address a special audience, but it does mean that someone who wants a midi interface does not find it on the shelf, and goes looking instead to C++. (Presumably after checking out gnatcom) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-16 17:46 ` tmoran @ 2002-04-17 3:34 ` Richard Riehle 2002-04-17 12:11 ` John English 0 siblings, 1 reply; 425+ messages in thread From: Richard Riehle @ 2002-04-17 3:34 UTC (permalink / raw) tmoran@acm.org wrote: > But multiple people have spent a lot of time creating alternative > Windows bindings. Not that those aren't good, especially when, as in > JEWL, they address a special audience, but it does mean that someone who > wants a midi interface does not find it on the shelf, and goes looking > instead to C++. (Presumably after checking out gnatcom) Actually, the mention of JEWL is appropriate. John English is to be commended for designing a package specification that is wonderfully accessible to the novice Windows programmer using Ada. However, John would probably be the first to agree that JEWL is not intended for the kind of robust applications one can create with CLAW. He never intended it to compete with CLAW, if I understand him correctly. I wonder whether someone might take the JEWL and JEWL.Windows package specifications and implement them with CLAW. The benefit would be that one would have the simplicity of the JEWL specification for beginner programmers along with the full power of CLAW when one needed to do more than JEWL offers. . Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 3:34 ` Richard Riehle @ 2002-04-17 12:11 ` John English 0 siblings, 0 replies; 425+ messages in thread From: John English @ 2002-04-17 12:11 UTC (permalink / raw) Richard Riehle wrote: > > tmoran@acm.org wrote: > > > But multiple people have spent a lot of time creating alternative > > Windows bindings. Not that those aren't good, especially when, as in > > JEWL, they address a special audience, but it does mean that someone who > > wants a midi interface does not find it on the shelf, and goes looking > > instead to C++. (Presumably after checking out gnatcom) > > Actually, the mention of JEWL is appropriate. John English is to be > commended for designing a package specification that is wonderfully > accessible to the novice Windows programmer using Ada. However, > John would probably be the first to agree that JEWL is not intended > for the kind of robust applications one can create with CLAW. He > never intended it to compete with CLAW, if I understand him correctly. You are exactly correct -- I wanted something simple enough for total beginners to use, which made it justifiable (IMHO) to sacrifice completeness and flexibility in favour of simplicity. > I wonder whether someone might take the JEWL and JEWL.Windows > package specifications and implement them with CLAW. The > benefit would be that one would have the simplicity of the JEWL > specification for beginner programmers along with the full > power of CLAW when one needed to do more than JEWL offers. . That would be nice -- any takers? :-) ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann ` (3 preceding siblings ...) 2002-04-14 8:51 ` Michael Erdmann @ 2002-04-15 16:29 ` Michael Erdmann 2002-04-16 11:28 ` Martin Dowie 2002-04-17 18:36 ` Ted Dennison 2002-04-17 18:04 ` Outside view (still): " Kent Paul Dolan 2002-04-27 8:26 ` Michael Erdmann 6 siblings, 2 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-15 16:29 UTC (permalink / raw) Michael Erdmann wrote: > Hallo all, > > i am wondering how standards are eveloving in the Ada community. > In the Java Community there is a process called Java Community > Process (JCP, http://www.jcp.org/) > > Is there something comparabel in the Ada communitiy? I gues > if there would be something like this there would be more > dynamic in the Ada 95 community. > What i got out of this discussion ================================= Below you find the major topics of this thread with some subjective statements: - There is no well establsihed process in the Ada community which leads to standarized components. There is ISO, but it is a relativly slow an quiet process without a large backup from comp.lang.ada communitiy. - There is a common understanding that standarization would be a nice thing, but there are a lot of examples that standarization creates nothing usefull. But what is the problem with it, if you are never fixing you positionthen you will be able to choose next time a better direction. So if you find a standard not suitable any more, make a new one! This means no dmonating monolits, diversification is an issue. - The questions was raised if there is a community problem which originates from the old DoD days. May be this is true for old established organisations but i dont believe this is the problem of the open source communitiy in comp.lang.ada, or at least i cant find any evidence for such an assumption. - What needs to be standarized? This was interesting, only a view reactions related to what is missing. I thinks this point contains the key to the unserstanding of the relativly static Ada community. Maybe there is not so mutch to do? Personally i am interested not so mutch in the lagnuage but in extending the predefined lanaguage environment. What will i am going to make out of this: ========================================= Since i still believe there are some things missing in the predefined language environment i dont like to drop the issue without having made an attempt to test where the actual problems are. I believe that i have to go through the following natural process - Having a problem - Raising interest for my solution within comp.lang.ada. - Following the old bazar guidleling, release early and often - Include new ideas of the interested people - Include the ARG WG 9 informative in the process. - Loop thrught the last three steps until it is stable. - Propose the solution to the ARG WG for inclusion in the Ada RM predefined language environment. I this process works once, maybe the experiences gained there might lead to an established procedure in the communitiy, or simply does not work! So stay tuned, i will setup today a page in my private webspace: http://www.snafu.de/~boavista/napc.html Everybody is invited to participate the program to make the Ada 95 community a little bit more dynmaic. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 16:29 ` Michael Erdmann @ 2002-04-16 11:28 ` Martin Dowie 2002-04-16 13:38 ` Marin David Condic 2002-04-17 18:36 ` Ted Dennison 1 sibling, 1 reply; 425+ messages in thread From: Martin Dowie @ 2002-04-16 11:28 UTC (permalink / raw) > - What needs to be standarized? > > This was interesting, only a view reactions related to > what is missing. I thinks this point contains the > key to the unserstanding of the relativly static > Ada community. Maybe there is not so mutch to do? > > Personally i am interested not so mutch in the lagnuage > but in extending the predefined lanaguage environment. An interesting quote from Bjarne Stroustrup on his web page on what he thinks C++0X should be, is: "My personal view is that the key principles should be no major changes to the language itself major extensions to the standard library" We are not alone... :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-16 11:28 ` Martin Dowie @ 2002-04-16 13:38 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-16 13:38 UTC (permalink / raw) At some point a language is descriptive enough to express all the things anyone knows how to say in a sufficiently large number of ways of saying it. I'd think that until some whole new programming paradigm comes along, both Ada and C++ have sufficient expressive capabilities. (Maybe filing off some burrs is in order, but that's about all that can be constructively done.) So what else is left except adding to predefined libraries to extend the language capabilities? IDEs and other tools aren't really a language issue while libraries and execution environments might be. So data structure, math, GUI, communication, OS and other libraries all sound like good candidates to me. It seems like the thing to do at this stage in Ada's life... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Martin Dowie" <martin.m.dowie@ntlworld.com> wrote in message news:8a63570b.0204160328.de7bf8d@posting.google.com... > > An interesting quote from Bjarne Stroustrup on his web page on > what he thinks C++0X should be, is: > > "My personal view is that the key principles should be > > no major changes to the language itself > major extensions to the standard library" > > We are not alone... :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-15 16:29 ` Michael Erdmann 2002-04-16 11:28 ` Martin Dowie @ 2002-04-17 18:36 ` Ted Dennison 2002-04-17 20:14 ` Michael Erdmann 2002-04-17 23:31 ` martin.m.dowie 1 sibling, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-17 18:36 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBAFFEE.2080708@snafu.de>... > Since i still believe there are some things missing > in the predefined language environment i dont like ... > > I believe that i have to go through the following > natural process What you have probably missed is that we have already gone through this process a bit, starting on the subject of a new standard component library in general, and a list package in particular. Many people had the vision of slowly increasing this library's scope to include much more than just components. The process is currently stalled a bit, and I have to take pretty much full blame for that. But you and anyone else interested may want to keep an eye on this site: http://savannah.gnu.org/projects/grace/ Which is the home I'm trying to set up for the project. There's nothing up there right now but 2 mailing lists, but I'm pretty close to posting the main webpage and the list package should follow closely. Once I get the basics set up, I can add administrators other than myself, and one person will no longer be the bottleneck (which will be a good thing, as I also have a new baby due in less than a week). From what I see on the website you posted, are goals are almost entirely in agreement. But I've been known to misread things. :-) I'm particularly in agreement with your "release early, release often" point. There was a trememdous amount of interest in this project a few months ago when we were making freqeunt source proposals and revisions for the list package, and I'd like to see us get back to that as soon as possible. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 18:36 ` Ted Dennison @ 2002-04-17 20:14 ` Michael Erdmann 2002-04-18 16:00 ` Ted Dennison 2002-04-17 23:31 ` martin.m.dowie 1 sibling, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-17 20:14 UTC (permalink / raw) Ted Dennison wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBAFFEE.2080708@snafu.de>... > >>Since i still believe there are some things missing >>in the predefined language environment i dont like >> > ... > >>I believe that i have to go through the following >>natural process >> > > What you have probably missed is that we have already gone through > this process a bit, starting on the subject of a new standard > component library in general, and a list package in particular. Many > people had the vision of slowly increasing this library's scope to > include much more than just components. The process is currently > stalled a bit, and I have to take pretty much full blame for that. But > you and anyone else interested may want to keep an eye on this site: > http://savannah.gnu.org/projects/grace/ I cannot access this page?!!! > > Which is the home I'm trying to set up for the project. There's > nothing up there right now but 2 mailing lists, but I'm pretty close > to posting the main webpage and the list package should follow > closely. Once I get the basics set up, I can add administrators other > than myself, and one person will no longer be the bottleneck (which > will be a good thing, as I also have a new baby due in less than a > week). > > From what I see on the website you posted, are goals are almost > entirely in agreement. But I've been known to misread things. :-) I'm > particularly in agreement with your "release early, release often" > point. There was a trememdous amount of interest in this project a few > months ago when we were making freqeunt source proposals and revisions > for the list package, and I'd like to see us get back to that as soon > as possible. What is wirtten there is quite general, not yet any technical things. This will change this week. I will public my idea of basic container package. Just look at this, on the next ada conference in vienna they will have a talk about this as well. http://www.auto.tuwien.ac.at/AE2002/problems.html > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 20:14 ` Michael Erdmann @ 2002-04-18 16:00 ` Ted Dennison 2002-04-18 17:32 ` Hyman Rosen 2002-04-18 20:28 ` Michael Erdmann 0 siblings, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 16:00 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CBDD795.4060706@snafu.de>... > > you and anyone else interested may want to keep an eye on this site: > > http://savannah.gnu.org/projects/grace/ > I cannot access this page?!!! Odd. I can get to it fine from both my work and home machines (while not logged in to savannah). Perhaps it was down when you tried? > Just look at this, on the next ada conference in vienna they will > have a talk about this as well. > > http://www.auto.tuwien.ac.at/AE2002/problems.html Yes, one of the organizers invited me to attend, based on my leading of our List work. Unfortunately, a trip overseas to Vienna doesn't exactly fit into my vacation schedule or personal budget this year. Since we mostly have a package worked out (at great pains) for lists, hopefully they will concentrate on defining what other containers are needed and how best to extend what we have. If there are any really nasty flaws or fatal problems with the current package, that would be an important issue too though. Since you are interested in this, I highly suggest you look over the "strawman" threads in Google to bring yourself up to speed before comming up with anything. It was a very extensive process and I'm not really keen on going back over what has alredy been done yet again. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 16:00 ` Ted Dennison @ 2002-04-18 17:32 ` Hyman Rosen 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic ` (4 more replies) 2002-04-18 20:28 ` Michael Erdmann 1 sibling, 5 replies; 425+ messages in thread From: Hyman Rosen @ 2002-04-18 17:32 UTC (permalink / raw) Ted Dennison wrote: > Since we mostly have a package worked out (at great pains) for lists, > hopefully they will concentrate on defining what other containers are > needed and how best to extend what we have. I was just reading somewhere (exactly where escapes me) of a recent survey done on C++ programmers who have started using the STL. There was some surprise to discover that the most used container was map. Apparently what happens is that once programmers have map available, they begin using it all over the place, replacing little local ad-hoc lookup structures such as linear searches through arrays. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Grace and Maps (was Re: Development process in the Ada community) 2002-04-18 17:32 ` Hyman Rosen @ 2002-04-18 17:48 ` Marin David Condic 2002-04-19 13:29 ` Ted Dennison 2002-04-20 0:42 ` David Bolen 2002-04-18 18:50 ` [OT] Focusing on tools you know in programming libraries. (was): Development process in the Ada community Kent Paul Dolan ` (3 subsequent siblings) 4 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 17:48 UTC (permalink / raw) When the whole discussion of what eventually began to emerge as Grace got started, there seemed to be a consensus that if you had lists and maps, most of the other sorts of containers just wouldn't be that big a deal. Lists and Maps just cover the bulk of what you need to do in most practical programming situations. I wouldn't be surprised that C++ programmers have had similar experience. At some point you go: "Maybe there's a more efficient structure for this data, but I'm not doing realtime and here's a solution already put together for me, so lets just go with it for looking up information..." IIRC, there was general agreement to concentrate on Lists as a start and then, when the structure of it was settled, a similar spec would be discussed for Maps. If the Lists specification is considered done, perhaps its time to look at it with an eye towards proposing a Map specification? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3CBF0341.8020406@mail.com... > > I was just reading somewhere (exactly where escapes me) of a recent > survey done on C++ programmers who have started using the STL. There > was some surprise to discover that the most used container was map. > Apparently what happens is that once programmers have map available, > they begin using it all over the place, replacing little local ad-hoc > lookup structures such as linear searches through arrays. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic @ 2002-04-19 13:29 ` Ted Dennison 2002-04-19 14:23 ` Marin David Condic 2002-04-20 0:42 ` David Bolen 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-19 13:29 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9n0tk$6fs$1@nh.pace.co.uk>... > When the whole discussion of what eventually began to emerge as Grace got > started, there seemed to be a consensus that if you had lists and maps, most > of the other sorts of containers just wouldn't be that big a deal. Lists and > Maps just cover the bulk of what you need to do in most practical > programming situations. I wouldn't be surprised that C++ programmers have > had similar experience. At some point you go: "Maybe there's a more > efficient structure for this data, but I'm not doing realtime and here's a > solution already put together for me, so lets just go with it for looking up > information..." I've actually been thinking along similar lines. What I'm wondering is if we should keep the list package as "Lists.Unbounded", or if we should just bag the whole bounded/unbounded issue and make it "Lists". > IIRC, there was general agreement to concentrate on Lists as a start and > then, when the structure of it was settled, a similar spec would be > discussed for Maps. > > If the Lists specification is considered done, perhaps its time to look at > it with an eye towards proposing a Map specification? Indeed. I still don't have the website up unfortunately (I've never used ssl before, which is required to upload things, so I'm having "issues".) But the last published proposal spec is still available at http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html to refresh everyone's memory. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-19 13:29 ` Ted Dennison @ 2002-04-19 14:23 ` Marin David Condic 2002-04-20 13:42 ` Michael Erdmann ` (3 more replies) 0 siblings, 4 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-19 14:23 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0204190529.559a47ae@posting.google.com... > > I've actually been thinking along similar lines. What I'm wondering is > if we should keep the list package as "Lists.Unbounded", or if we > should just bag the whole bounded/unbounded issue and make it "Lists". > > O.K. Let's cash in our reality checks and see if they bounce. Would it be fair to say that *most* Ada developers and applications are some flavor of Windows/Unix with no realtime requirement beyond "Don't run so slow as to annoy the user..."? If that's the case, then we're looking at virtual memory machines that probably run very fast and hence, having fixed or bounded lists doesn't seem like it would be very important. If we put out a Grace.Lists and a Grace.Maps, that would certainly be a really good start. If at a later point in time there was some kind of groundswell indicating that there really was a need for bounded versions, why couldn't we go with Grace.Lists.Bounded as an extension? The only reason I can think of is that it isn't consistent with Ada.Strings. An interesting observation: When I write most apps for a PC in Ada, I tend to use the standard, fixed strings only at the points where Ada defined functions require them. (Stuff like Text_IO) The rest of the time, I just go to Unbounded because from a programming perspective, its just so much more convenient. In most instances, whatever performance penalties might exist for it are so far below the noise floor that they are invisible. Is this experience unique to me or would most Ada programmers report similar experience? If Ada were to totally abandon fixed and bounded strings (in the sense that they were never there - not from any sort of compatibility perspective), would you notice or care most of the time? (Presuming you could get them via some add-on package of your own creation if you ever really needed them?) My inclination would be to make Grace.Lists and Grace.Maps and add children at a later date if we thought we needed special cases. I'd again make an appeal for some version of "Grace.Containers.Lists" and "Grace.Containers.Maps" (or some variant thereof) so that there might also be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML", "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real important to me but thinking along the line of problem domains & dividing things up under a subheading is something I think would be beneficial in the long run. > > > > If the Lists specification is considered done, perhaps its time to look at > > it with an eye towards proposing a Map specification? > > Indeed. I still don't have the website up unfortunately (I've never > used ssl before, which is required to upload things, so I'm having > "issues".) But the last published proposal spec is still available at > http://www.telepath.com/dennison/Ted/Containers-Lists-Unbounded.ads.html > to refresh everyone's memory. > I've still got the link bookmarked and could possibly spend some time developing some test code, etc., if you think that's of value. (Do you have a body in some preliminary state I could work to?) I don't think you need to have the full-blown project setup done in order to discuss an interface to Maps. What would you suggest as a means of getting that ball rolling? Would you like someone to take the Lists spec and turn it into a strawman for Maps? (I hear you're a little preoccupied at the moment... :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-19 14:23 ` Marin David Condic @ 2002-04-20 13:42 ` Michael Erdmann 2002-04-20 19:54 ` Ted Dennison 2002-04-20 19:12 ` Jeffrey Carter ` (2 subsequent siblings) 3 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-20 13:42 UTC (permalink / raw) To: Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> Marin David Condic wrote: > "Ted Dennison" <dennison@telepath.com> wrote in message > news:4519e058.0204190529.559a47ae@posting.google.com... > >>I've actually been thinking along similar lines. What I'm wondering is >>if we should keep the list package as "Lists.Unbounded", or if we >>should just bag the whole bounded/unbounded issue and make it "Lists". >> >> >> > O.K. Let's cash in our reality checks and see if they bounce. Would it be > fair to say that *most* Ada developers and applications are some flavor of > Windows/Unix with no realtime requirement beyond "Don't run so slow as to > annoy the user..."? If that's the case, then we're looking at virtual memory > machines that probably run very fast and hence, having fixed or bounded > lists doesn't seem like it would be very important. > > If we put out a Grace.Lists and a Grace.Maps, that would certainly be a > really good start. If at a later point in time there was some kind of > groundswell indicating that there really was a need for bounded versions, > why couldn't we go with Grace.Lists.Bounded as an extension? The only reason > I can think of is that it isn't consistent with Ada.Strings. > > An interesting observation: When I write most apps for a PC in Ada, I tend > to use the standard, fixed strings only at the points where Ada defined > functions require them. (Stuff like Text_IO) The rest of the time, I just go > to Unbounded because from a programming perspective, its just so much more > convenient. In most instances, whatever performance penalties might exist > for it are so far below the noise floor that they are invisible. Is this > experience unique to me or would most Ada programmers report similar > experience? If Ada were to totally abandon fixed and bounded strings (in the > sense that they were never there - not from any sort of compatibility > perspective), would you notice or care most of the time? (Presuming you > could get them via some add-on package of your own creation if you ever > really needed them?) I have to agree on your observation, convenience is very important. In earlier days there was a lot of disussion about the yield of high level languages compared with low level methods like assembler. The discusion was around the same issue, performance, realtime behaviour, memory usage etc.... So i agree, i would be a good start which is proably covering most of our requirements. Without trying it, we will never fail, which means we will continue discussing without learning anything by testing the aproach in real life development scenarios. Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 13:42 ` Michael Erdmann @ 2002-04-20 19:54 ` Ted Dennison 2002-04-22 13:21 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-20 19:54 UTC (permalink / raw) Michael Erdmann wrote: > Without trying it, we will never fail, which means we will continue That ought to be my battle cry! :-) Tick: "Spoon!" Authur: "Not in the face! Not in the face!" T.E.D.: "Without trying, we will never fail!" (melee ensues) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 19:54 ` Ted Dennison @ 2002-04-22 13:21 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 13:21 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:3CC1C7C6.5030404@telepath.com... > Michael Erdmann wrote: > > > Without trying it, we will never fail, which means we will continue > > > That ought to be my battle cry! :-) > > Tick: "Spoon!" > Authur: "Not in the face! Not in the face!" > T.E.D.: "Without trying, we will never fail!" > (melee ensues) > "If we don't succeed, we run the risk of failure." -- Al Gore (Don't know if its an accurate quote, but it applies even if it isn't. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-19 14:23 ` Marin David Condic 2002-04-20 13:42 ` Michael Erdmann @ 2002-04-20 19:12 ` Jeffrey Carter 2002-04-22 13:40 ` Marin David Condic 2002-04-20 19:49 ` Ted Dennison 2002-04-25 2:29 ` Brian Gaffney 3 siblings, 1 reply; 425+ messages in thread From: Jeffrey Carter @ 2002-04-20 19:12 UTC (permalink / raw) Marin David Condic wrote: > > O.K. Let's cash in our reality checks and see if they bounce. Would it be > fair to say that *most* Ada developers and applications are some flavor of > Windows/Unix with no realtime requirement beyond "Don't run so slow as to > annoy the user..."? If that's the case, then we're looking at virtual memory > machines that probably run very fast and hence, having fixed or bounded > lists doesn't seem like it would be very important. No, it wouldn't be fair, at least not from my perspective. But it would be a good start, so I have no objection to it. > > If we put out a Grace.Lists and a Grace.Maps, that would certainly be a > really good start. If at a later point in time there was some kind of > groundswell indicating that there really was a need for bounded versions, > why couldn't we go with Grace.Lists.Bounded as an extension? The only reason > I can think of is that it isn't consistent with Ada.Strings. While I agree with this, if Grace becomes accepted, and we submit it to the ARG as has been requested on the Ada-Comment mailing list, then it would become part of the Ada.* hierarchy, so I suggest that consistency with those naming conventions would be a Good Thing. -- Jeff Carter "You cheesy lot of second-hand electric donkey-bottom biters." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 19:12 ` Jeffrey Carter @ 2002-04-22 13:40 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 13:40 UTC (permalink / raw) "Jeffrey Carter" <jrcarter@acm.org> wrote in message news:3CC1BD77.EFDD044C@acm.org... > > No, it wouldn't be fair, at least not from my perspective. But it would > be a good start, so I have no objection to it. > Note that the question is more one about generality. I certainly accept that there *are* people who use Ada in realtime apps where performance & determinism & possibly task safety would be a critical concern. Just more of an issue of "who is in the majority" so we can do the Greatest Good For The Greatest Number. (Also, I don't think that the Grace list package as it stands at the moment wouldn't be useful in realtime - just that it might not be applicable without careful analysis & for a number of cases, fixed or bounded versions might be better. They can always be added if there seems to be a crying need.) > > While I agree with this, if Grace becomes accepted, and we submit it to > the ARG as has been requested on the Ada-Comment mailing list, then it > would become part of the Ada.* hierarchy, so I suggest that consistency > with those naming conventions would be a Good Thing. > I'd actually be opposed to getting it into the Ada.* tree. A couple of reasons: First, this is going to exist as a stand alone tree initially because you can't add it to the Ada.* tree without being the compiler. Once it starts showing up in people's code as "Grace.Lists..." nobody is going to want to go change their existing code to make it all "Ada.Grace.Lists...." My experience with software is that early decisions about structure are something you have to live with for a very long time, so you'd better consider them carefully. My second reason is that if this collection of stuff should ever get put under the Ada.* tree, you would instantly make it very difficult to extend and enhance with future ideas. You'd be up against the inability to modify anything in the Ada.* tree without being the compiler, plus you'd be up against all sorts of political forces lobbying for stability and fighting against an ISO bureaucracy, etc. etc. etc. Far better it should stand on its own so that it can be treated as a "Convention" rather than a "Standard" and remain far more flexible & extensible. A library such as this needs to be enhanced with a fairly rapid product cycle or we would be lagging behind other languages instead of taking the lead. That's my take on it anyway. It would be good to know what the rest of the interested parties think on it - should Grace aim for inclusion in the Ada.* tree and become part of the ARM? (Can it be part of the ARM and remain flexible with a fast update cycle?) Or should it aim to be a sideline convention? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-19 14:23 ` Marin David Condic 2002-04-20 13:42 ` Michael Erdmann 2002-04-20 19:12 ` Jeffrey Carter @ 2002-04-20 19:49 ` Ted Dennison 2002-04-21 1:33 ` Ted Dennison ` (2 more replies) 2002-04-25 2:29 ` Brian Gaffney 3 siblings, 3 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-20 19:49 UTC (permalink / raw) Marin David Condic wrote: > "Ted Dennison" <dennison@telepath.com> wrote in message > news:4519e058.0204190529.559a47ae@posting.google.com... > >>I've actually been thinking along similar lines. What I'm wondering is >>if we should keep the list package as "Lists.Unbounded", or if we >>should just bag the whole bounded/unbounded issue and make it "Lists". >> >> >> > O.K. Let's cash in our reality checks and see if they bounce. Would it be > fair to say that *most* Ada developers and applications are some flavor of > Windows/Unix with no realtime requirement beyond "Don't run so slow as to > annoy the user..."? If that's the case, then we're looking at virtual memory I honestly have no clue. The vast majority of my Ada use has been real-time or embedded (where dynamic allocation is often unavailable), and I do notice that there seem to be a large number of Ada compilers for such platforms. But I also realise that's just the view from my window, not a scientific representative sample. What I was thinking is that we have 2 reasonable approaches: The first would be to keep "Lists" as a parent package with an "Unbounded" child. The main advantage to this, and the reason it currently is this way, is that it matches what we already have in place for string support. Another possiblity would be to keep the name simple (Grace.Lists), and give the bounded version its own name when/if the time comes. Something like "Circular_Lists" (or Booch's "Ring") might be a possibility. This concept extends to Maps too, as we could call them "Maps" and "Hashes" rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a simpler structure, we no longer have the name talking about internal features of the structure instead of external features. That could be good enough for real-time and embedded folks if we document its use (or lack of use) of heap properly. But the argument for consistency with Ada.Strings.* is fairly compelling too. > An interesting observation: When I write most apps for a PC in Ada, I tend > to use the standard, fixed strings only at the points where Ada defined > functions require them. (Stuff like Text_IO) The rest of the time, I just go > to Unbounded because from a programming perspective, its just so much more > convenient. In most instances, whatever performance penalties might exist That's funny. If anything, I'm the opposite. I go with fixed strings wherever I can without having to keep a separate length variable (which can be nearly anywhere once you learn how to do it). Text_IO.Get_Line is the annyoing exception where I'd like to use Unbounded, but can't. Strings a generally the kind of object that only holds one value for their entire lifetime. The trick is that figuring out what the proper one value is can sometimes be a bit of work. Reading textual input is the primary significant exception to this. > My inclination would be to make Grace.Lists and Grace.Maps and add children > at a later date if we thought we needed special cases. I'd again make an > appeal for some version of "Grace.Containers.Lists" and > "Grace.Containers.Maps" (or some variant thereof) so that there might also > be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML", > "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real > important to me but thinking along the line of problem domains & dividing > things up under a subheading is something I think would be beneficial in the > long run. I'm curious if other people feel this way. I'd lean towards "Grace.Lists", as the standard Ada library is equally flat, our list of components may not end up being large, and there isn't liable to be much common code sitting in the "Components" spec. But I'm not married to the idea. We certianly need to name for proper growth, as renaming files in CVS is kind of a kludge. > I've still got the link bookmarked and could possibly spend some time > developing some test code, etc., if you think that's of value. (Do you have > a body in some preliminary state I could work to?) Its actually pretty much done. It could perhaps use some more testing. But we just need to arrive at a proper name, and I'll check it into Grace's CVS. > I don't think you need to have the full-blown project setup done in order to > discuss an interface to Maps. What would you suggest as a means of getting > that ball rolling? Would you like someone to take the Lists spec and turn it > into a strawman for Maps? (I hear you're a little preoccupied at the > moment... :-) Yeah, that would be a good start. Right now in addtion to this I'm trying to figure out if I need to buy 3 smaller child car seats or a larger car. :-( ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 19:49 ` Ted Dennison @ 2002-04-21 1:33 ` Ted Dennison 2002-04-21 5:49 ` Simon Wright ` (5 more replies) 2002-04-21 5:46 ` Simon Wright 2002-04-22 14:31 ` Marin David Condic 2 siblings, 6 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-21 1:33 UTC (permalink / raw) Ted Dennison wrote: > Marin David Condic wrote: >> I don't think you need to have the full-blown project setup done in >> order to >> discuss an interface to Maps. What would you suggest as a means of >> getting >> that ball rolling? Would you like someone to take the Lists spec and >> turn it >> into a strawman for Maps? (I hear you're a little preoccupied at the >> moment... :-) > > > Yeah, that would be a good start. Right now in addtion to this I'm On second thought, we really ought to get some kind of consensus on requirements before rushing headlong into design. If nothing else, it will save a lot of arguments. Requirements I think ought to be included (using the usual should/shall language): Maps shall provide for key lookup in no worse than O(logn) average time and O(n) worst case (where n is the # of elements in the map). Maps shall provide for creation of a sorted list or array, or traversal in sorted order, in no worse than O(n) time. (In other words, the map is kept sorted as elements are added). Maps should provide an interface consistent with Lists, as far as is practicable. Comments? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison @ 2002-04-21 5:49 ` Simon Wright 2002-04-21 8:55 ` Hyman Rosen 2002-04-21 20:17 ` Ted Dennison 2002-04-22 0:36 ` Larry Kilgallen ` (4 subsequent siblings) 5 siblings, 2 replies; 425+ messages in thread From: Simon Wright @ 2002-04-21 5:49 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Maps shall provide for key lookup in no worse than O(logn) average > time and O(n) worst case (where n is the # of elements in the map). > > Maps shall provide for creation of a sorted list or array, or > traversal in sorted order, in no worse than O(n) time. (In other > words, the map is kept sorted as elements are added). I was quite surprised by the idea that a map had to (be|behave as though it was) implemented using a sorted vector of keys .. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 5:49 ` Simon Wright @ 2002-04-21 8:55 ` Hyman Rosen 2002-04-21 18:49 ` Ted Dennison 2002-04-21 20:17 ` Ted Dennison 1 sibling, 1 reply; 425+ messages in thread From: Hyman Rosen @ 2002-04-21 8:55 UTC (permalink / raw) Simon Wright wrote: > I was quite surprised by the idea that a map had to (be|behave as > though it was) implemented using a sorted vector of keys .. C++ maps are pretty much universally implemented using red-black trees. I was quite surprised by the idea that keeping a map sorted requires a vector :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 8:55 ` Hyman Rosen @ 2002-04-21 18:49 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-21 18:49 UTC (permalink / raw) Hyman Rosen wrote: > Simon Wright wrote: > >> I was quite surprised by the idea that a map had to (be|behave as >> though it was) implemented using a sorted vector of keys .. > > > C++ maps are pretty much universally implemented using > red-black trees. I was quite surprised by the idea that I've never implemented a general Map myself, or looked at one. I was picturing something along the lines of a binary tree, perhaps balanced if you want to get sexy. So that makes sense. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 5:49 ` Simon Wright 2002-04-21 8:55 ` Hyman Rosen @ 2002-04-21 20:17 ` Ted Dennison 1 sibling, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-21 20:17 UTC (permalink / raw) Simon Wright wrote: > I was quite surprised by the idea that a map had to (be|behave as > though it was) implemented using a sorted vector of keys .. Thanks. This is a perfect example of why we need to get consensus on requirements before implementing anything. :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison 2002-04-21 5:49 ` Simon Wright @ 2002-04-22 0:36 ` Larry Kilgallen 2002-04-22 5:20 ` Simon Wright 2002-04-22 13:31 ` Ted Dennison 2002-04-22 14:37 ` Marin David Condic ` (3 subsequent siblings) 5 siblings, 2 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-22 0:36 UTC (permalink / raw) In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > On second thought, we really ought to get some kind of consensus on > requirements before rushing headlong into design. If nothing else, it > will save a lot of arguments. > > Requirements I think ought to be included (using the usual should/shall > language): > > Maps shall provide for key lookup in no worse than O(logn) average time > and O(n) worst case (where n is the # of elements in the map). > > Maps shall provide for creation of a sorted list or array, or traversal > in sorted order, in no worse than O(n) time. (In other words, the map is > kept sorted as elements are added). > > Maps should provide an interface consistent with Lists, as far as is > practicable. > > Comments? While the interface should not _prevent_ implementations from achieving certain performance goals, I don't think performance goals should be part of the requirements. If a vendor wants to provide a relatively slow implementation, that is their choice, just like their choice regarding how fast A := B'length should perform. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 0:36 ` Larry Kilgallen @ 2002-04-22 5:20 ` Simon Wright 2002-04-22 13:34 ` Ted Dennison ` (6 more replies) 2002-04-22 13:31 ` Ted Dennison 1 sibling, 7 replies; 425+ messages in thread From: Simon Wright @ 2002-04-22 5:20 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > While the interface should not _prevent_ implementations from > achieving certain performance goals, I don't think performance goals > should be part of the requirements. If a vendor wants to provide a > relatively slow implementation, that is their choice, just like > their choice regarding how fast A := B'length should perform. As a user as well as a provider, it seems to me that I need both bounded and unbounded memory behaviour in the same program (for different instances, of course!); and I'd like to be able to change without huge costs. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 5:20 ` Simon Wright @ 2002-04-22 13:34 ` Ted Dennison 2002-04-22 16:16 ` Darren New 2002-04-22 22:31 ` Jeffrey Carter ` (5 subsequent siblings) 6 siblings, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-22 13:34 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote in message news:<x7vr8l871it.fsf@smaug.pushface.org>... > As a user as well as a provider, it seems to me that I need both > bounded and unbounded memory behaviour in the same program (for > different instances, of course!); and I'd like to be able to change > without huge costs. Hmmm. This seems to be going back to the "naming" issue: Do we want *.Maps.Bounded or *.Hashes? -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 13:34 ` Ted Dennison @ 2002-04-22 16:16 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-22 16:16 UTC (permalink / raw) Ted Dennison wrote: > Hmmm. This seems to be going back to the "naming" issue: Do we want > *.Maps.Bounded or *.Hashes? A hash and a map are two different levels. A hash is simply a particular way of implementing a map. (Assuming you mean "hashtable", but then a "hash" by itself makes no sense as a datastructure.) I.e., what keeps a bounded map from being implemented as a tree instead of a hash? Indeed, for many types, I'd think a tree would be a better implementation, as a hashtable requires you to be able to manipulate the key items in a non-opaque manner, while a tree requires only a ordering operator. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 5:20 ` Simon Wright 2002-04-22 13:34 ` Ted Dennison @ 2002-04-22 22:31 ` Jeffrey Carter [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com> ` (4 subsequent siblings) 6 siblings, 0 replies; 425+ messages in thread From: Jeffrey Carter @ 2002-04-22 22:31 UTC (permalink / raw) Darren New wrote: > > I.e., what keeps a bounded map from being implemented as a tree instead > of a hash [table]? Indeed, for many types, I'd think a tree would be a better > implementation, as a hashtable requires you to be able to manipulate the > key items in a non-opaque manner, while a tree requires only a ordering > operator. Trees also have the advantage that they do not waste space. The trouble with a tree is that, if it is not balanced, operations can be O(N) in the worst case. If the tree is balanced, searching is O(log N), but insertion and deletion are slow, because the tree must be rebalanced after every modification. This is why I use skip lists. They do not waste space, and operations are O(log N) but no rebalancing is needed after modification. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com> @ 2002-04-22 23:26 ` Darren New 2002-04-23 2:15 ` Jeffrey Carter ` (2 more replies) 2002-04-23 2:32 ` Ted Dennison 1 sibling, 3 replies; 425+ messages in thread From: Darren New @ 2002-04-22 23:26 UTC (permalink / raw) Jeffrey Carter wrote: > The trouble with a tree is that, if it is not balanced, operations can > be O(N) in the worst case. If the tree is balanced, searching is O(log > N), but insertion and deletion are slow, because the tree must be > rebalanced after every modification. Well, that's why you use something a little more sophisticated, like a red-black tree, or a B-tree if your memory I/O works in blocks (like a disk). -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 23:26 ` Darren New @ 2002-04-23 2:15 ` Jeffrey Carter 2002-04-23 4:57 ` Darren New 2002-04-23 6:26 ` Kent Paul Dolan 2002-04-23 2:38 ` Ted Dennison 2002-04-23 18:57 ` Anders Gidenstam 2 siblings, 2 replies; 425+ messages in thread From: Jeffrey Carter @ 2002-04-23 2:15 UTC (permalink / raw) Darren New wrote: > > Jeffrey Carter wrote: > > The trouble with a tree is that, if it is not balanced, operations can > > be O(N) in the worst case. If the tree is balanced, searching is O(log > > N), but insertion and deletion are slow, because the tree must be > > rebalanced after every modification. > > Well, that's why you use something a little more sophisticated, like a > red-black tree, or a B-tree if your memory I/O works in blocks (like a > disk). Maybe my memory is faulty, but I seem to recall that these trees still need rebalancing to maintain O(log N) search times. -- Jeff Carter "We call your door-opening request a silly thing." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 2:15 ` Jeffrey Carter @ 2002-04-23 4:57 ` Darren New 2002-04-23 7:10 ` Ole-Hjalmar Kristensen 2002-04-23 12:49 ` Alan Reynolds 2002-04-23 6:26 ` Kent Paul Dolan 1 sibling, 2 replies; 425+ messages in thread From: Darren New @ 2002-04-23 4:57 UTC (permalink / raw) Jeffrey Carter wrote: > Maybe my memory is faulty, but I seem to recall that these trees still > need rebalancing to maintain O(log N) search times. Yes, but only on inserts, only rebalancing of a limited amount of the tree (O(log N) for the worst case rebalance) and generally do *not* require rebalances on every insert. It's not like keeping a list sorted, for example. For example, a red-black tree touches at worse the nodes between the node you just inserted and the root, IIRC. A B-tree (which is based on blocks of pointers) touches the block you inserted in and potentially back to the root, either splitting or combining as needed. Red/black trees don't get nodes moved when they're rebalanced. You just adjust the pointers. I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if all the elements hash to the same value) or how you'd guarantee any particular limit on execution time of inserting a value (for example, in the same case). In contrast, a red-black tree is *never* going to see O(N) time in any operation. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 4:57 ` Darren New @ 2002-04-23 7:10 ` Ole-Hjalmar Kristensen 2002-04-23 14:52 ` Stephen Leake 2002-04-23 19:08 ` Darren New 2002-04-23 12:49 ` Alan Reynolds 1 sibling, 2 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-23 7:10 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Jeffrey Carter wrote: > > Maybe my memory is faulty, but I seem to recall that these trees still > > need rebalancing to maintain O(log N) search times. > > Yes, but only on inserts, only rebalancing of a limited amount of the > tree (O(log N) for the worst case rebalance) and generally do *not* > require rebalances on every insert. It's not like keeping a list sorted, > for example. For example, a red-black tree touches at worse the nodes > between the node you just inserted and the root, IIRC. A B-tree (which > is based on blocks of pointers) touches the block you inserted in and > potentially back to the root, either splitting or combining as needed. > > Red/black trees don't get nodes moved when they're rebalanced. You just > adjust the pointers. > Yes, they are very nice. > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if > all the elements hash to the same value) or how you'd guarantee any > particular limit on execution time of inserting a value (for example, in > the same case). In contrast, a red-black tree is *never* going to see > O(N) time in any operation. > You're right, you cannot in general guarantee it. But if you use hash functions which on average change half the bits as a result of a single bit change in the input, you can rest assured that it will not happen in practice. A more serious problem is that the average time increases as you add more data items. For your typical hash link table, you should try to keep the table not more than 50-80% full. This will give you search times very close to O(1) with a good hash function. For general use, I would certainly prefer a good tree implementation, but when you need the utmost speed and have a fixed size data set, I would go for the hash table. > -- > Darren New > San Diego, CA, USA > (PST). Cryptokeys on demand. > The 90/10 rule of toothpaste: the last > 10% of > the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 7:10 ` Ole-Hjalmar Kristensen @ 2002-04-23 14:52 ` Stephen Leake 2002-04-23 19:08 ` Darren New 1 sibling, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-23 14:52 UTC (permalink / raw) Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes: > For general use, I would certainly prefer a good tree implementation, > but when you need the utmost speed and have a fixed size data set, I > would go for the hash table. So we need to allow for both: Grace.Maps.Tree_implementation Grace.Maps.Hash_Implementation Hash_implementation will take a generic parameter giving the max N of the data set, or the size of the hash table, or something similar. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 7:10 ` Ole-Hjalmar Kristensen 2002-04-23 14:52 ` Stephen Leake @ 2002-04-23 19:08 ` Darren New 2002-04-24 12:22 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-23 19:08 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > You're right, you cannot in general guarantee it. But if you use hash > functions which on average change half the bits as a result of a > single bit change in the input, you can rest assured that it will not > happen in practice. I haven't done any safety-critical work, but is this how it's really done? "It's very unlikely this airplane will crash into that nuclear plant, unless 20 items all hash to the same value"? :-) No, seriously... In any case, the hashes still have two problems: 1) You *could* be hosed this way, so while they may be faster, they're still not deterministic, while a red-black tree has a strictly bounded upper limit on the number of operations (given a particular number of nodes) which is much lower than that of a hash table. In other words, the worst-case for a hashtable is still O(N), which if you need realtime and safety-critical, you have to take it into account. 2) You need to be able to hash the value. A red-black tree needs only an ordering operator (like "<"), not something that gropes the insides of an object like a hash needs to. If you want to ensure you have a particularly good hash, then you are going to have trouble with the strong typing in Ada, yes? That is, every type of hash table I create is going to work only if I implement a hash appropriate to the key type, and that'll have to get reimplemented (to some extent at least) for every type. On the other hand, most of the built-in types and metatypes ("record", "array", etc) already have ordering operators or rules on how to deduce them from the components. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 19:08 ` Darren New @ 2002-04-24 12:22 ` Ole-Hjalmar Kristensen 2002-04-24 13:53 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 12:22 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Ole-Hjalmar Kristensen wrote: > > You're right, you cannot in general guarantee it. But if you use hash > > functions which on average change half the bits as a result of a > > single bit change in the input, you can rest assured that it will not > > happen in practice. > > I haven't done any safety-critical work, but is this how it's really > done? "It's very unlikely this airplane will crash into that nuclear > plant, unless 20 items all hash to the same value"? :-) No, > seriously... I agree, not the thing you would want in a hard real time safety-critical system. Buf for soft real time, non saftey critical systems it's good enough. And it really can make a difference in throughput in for instance applications like relational algebra processing. > > In any case, the hashes still have two problems: > > 1) You *could* be hosed this way, so while they may be faster, they're > still not deterministic, while a red-black tree has a strictly bounded > upper limit on the number of operations (given a particular number of > nodes) which is much lower than that of a hash table. In other words, > the worst-case for a hashtable is still O(N), which if you need realtime > and safety-critical, you have to take it into account. > Agree, although even O(N) might be good enough, depending on you application. Also, if the probability of O(N) behaviour is sufficiently low, it may be way below the probability of a system failure caused by other errors. > 2) You need to be able to hash the value. A red-black tree needs only an > ordering operator (like "<"), not something that gropes the insides of > an object like a hash needs to. If you want to ensure you have a > particularly good hash, then you are going to have trouble with the > strong typing in Ada, yes? That is, every type of hash table I create is > going to work only if I implement a hash appropriate to the key type, > and that'll have to get reimplemented (to some extent at least) for > every type. On the other hand, most of the built-in types and metatypes > ("record", "array", etc) already have ordering operators or rules on how > to deduce them from the components. > Yes, although the reimplementation usually just consists of calling the same hash functions with different parameters. After all, we don't really care what we are hashing, all we need to know is the location and size of the key, so one good hash function is really all you need. > -- > Darren New > San Diego, CA, USA (PST). Cryptokeys on demand. > The 90/10 rule of toothpaste: the last 10% of > the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 12:22 ` Ole-Hjalmar Kristensen @ 2002-04-24 13:53 ` Darren New 2002-04-24 15:02 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-24 13:53 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > I agree, not the thing you would want in a hard real time > safety-critical system. Buf for soft real time, non saftey critical > systems it's good enough. And it really can make a difference in > throughput in for instance applications like relational algebra > processing. Well, there's also the question of the malicious user, who intentionally inserts a lot of items that hash to the same value (over a web interface, say) and thereby breaks something. > Yes, although the reimplementation usually just consists of calling the > same hash functions with different parameters. After all, we don't > really care what we are hashing, all we need to know is the location > and size of the key, so one good hash function is really all you need. Hmmm... So if you have keys you can't break up? I mean, I'm not sure how you would make a generic hash function that would hash any record, or any array, or any private type, or ... In C it's easy - you cast the pointer to a char* and hash, and hope there's no randomly-initialized padding in the middle. I don't know how to do this in Ada, tho - it would seem that every private type (for example) would have to implement its own hash function. Wouldn't it? -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 13:53 ` Darren New @ 2002-04-24 15:02 ` Ole-Hjalmar Kristensen 2002-04-24 15:25 ` Darren New 2002-04-24 19:14 ` Randy Brukardt 0 siblings, 2 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 15:02 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Ole-Hjalmar Kristensen wrote: > > I agree, not the thing you would want in a hard real time > > safety-critical system. Buf for soft real time, non saftey critical > > systems it's good enough. And it really can make a difference in > > throughput in for instance applications like relational algebra > > processing. > > Well, there's also the question of the malicious user, who intentionally > inserts a lot of items that hash to the same value (over a web > interface, say) and thereby breaks something. > OK, but how does this malicious user manage to do this when I'm using a hash function which on average changes half the bits of its output for any single bit change in its input? I'm not saying it's impossible, but it seems pretty far-fetched to me. Of course, if he's got the source to my program and is good at inverting hash functions he can do it. In particular (pardon the C code, but as you say yourself, in C it's easy), how do you construct your keys so they all hash to the same value given this particular hash function? : /* The mixing step */ #define mix(a,b,c) \ { \ a=a-b; a=a-c; a=a^(c>>13); \ b=b-c; b=b-a; b=b^(a<<8); \ c=c-a; c=c-b; c=c^(b>>13); \ a=a-b; a=a-c; a=a^(c>>12); \ b=b-c; b=b-a; b=b^(a<<16); \ c=c-a; c=c-b; c=c^(b>>5); \ a=a-b; a=a-c; a=a^(c>>3); \ b=b-c; b=b-a; b=b^(a<<10); \ c=c-a; c=c-b; c=c^(b>>15); \ } /* The whole new hash function */ inline u4 burtle( register u1 *k, /* the key */ u4 length, /* the length of the key in bytes */ u4 initval /* the previous hash, or an arbitrary value */ ) { register u4 a,b,c; /* the internal state */ u4 len; /* how many key bytes still need mixing */ /* Set up the internal state */ len = length; a = b = 0x9e3779b9; /* the golden ratio; an arbitrary value */ c = initval; /* variable initialization of internal state */ /*---------------------------------------- handle most of the key */ while (len >= 12) { a=a+(k[0]+((u4)k[1]<<8)+((u4)k[2]<<16) +((u4)k[3]<<24)); b=b+(k[4]+((u4)k[5]<<8)+((u4)k[6]<<16) +((u4)k[7]<<24)); c=c+(k[8]+((u4)k[9]<<8)+((u4)k[10]<<16)+((u4)k[11]<<24)); mix(a,b,c); k = k+12; len = len-12; } /*------------------------------------- handle the last 11 bytes */ c = c+length; switch(len) /* all the case statements fall through */ { case 11: c=c+((u4)k[10]<<24); case 10: c=c+((u4)k[9]<<16); case 9 : c=c+((u4)k[8]<<8); /* the first byte of c is reserved for the length */ case 8 : b=b+((u4)k[7]<<24); case 7 : b=b+((u4)k[6]<<16); case 6 : b=b+((u4)k[5]<<8); case 5 : b=b+k[4]; case 4 : a=a+((u4)k[3]<<24); case 3 : a=a+((u4)k[2]<<16); case 2 : a=a+((u4)k[1]<<8); case 1 : a=a+k[0]; /* case 0: nothing left to add */ } mix(a,b,c); return c; } > > Yes, although the reimplementation usually just consists of calling the > > same hash functions with different parameters. After all, we don't > > really care what we are hashing, all we need to know is the location > > and size of the key, so one good hash function is really all you need. > > Hmmm... So if you have keys you can't break up? I mean, I'm not sure how > you would make a generic hash function that would hash any record, or > any array, or any private type, or ... > Sure, in that case you will have to call the hash function for each part of the key. But in that case, wouldn't you also need to define a comparision operator if you used a tree? > In C it's easy - you cast the pointer to a char* and hash, and hope > there's no randomly-initialized padding in the middle. I don't know In Ada, you can get rid of any packing if you insist, at least more portably than in C. > how to do this in Ada, tho - it would seem that every private type > (for example) would have to implement its own hash > function. Wouldn't it? > Hmm. What's wrong with having a generic hash function which you instantiate for your private type? Provided that you can read the key as an array of bytes, it should work the same in both C and Ada. I know this is low-level and dirty, but for hashing, I think it's a reasonable approach. > -- > Darren New > San Diego, CA, USA (PST). Cryptokeys on demand. > The 90/10 rule of toothpaste: the last 10% of > the tube lasts as long as the first 90%. BTW., I'm not arguing for hash tables everywhere. I'm just saying there are some appliactions where O(log N) just isn't good enough, and that hash tables *in practice* is what you need. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 15:02 ` Ole-Hjalmar Kristensen @ 2002-04-24 15:25 ` Darren New 2002-04-24 15:39 ` Darren New 2002-04-24 19:32 ` Ole-Hjalmar Kristensen 2002-04-24 19:14 ` Randy Brukardt 1 sibling, 2 replies; 425+ messages in thread From: Darren New @ 2002-04-24 15:25 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > OK, but how does this malicious user manage to do this when I'm using > a hash function which on average changes half the bits of its output > for any single bit change in its input? It's called the birthday paradox. You hash enough values, you're going to find collisions. > I'm not saying it's > impossible, but it seems pretty far-fetched to me. It seemed far-fetched to me that someone would disassemble IIS or XP in order to find unchecked buffer overflows, but they managed within days of the release of the software, too. > Of course, if he's got the source to my program I kind of thought that was the point of this exercise - to make source, yes? >and is good at inverting hash functions > he can do it. In particular (pardon the C code, but as you say > yourself, in C it's easy), how do you construct your keys so they all > hash to the same value given this particular hash function? : Well, it's hard to read when it isn't complete C, but assuming "u4" is an unsigned integer four bytes long, it's pretty easy. /* Crappy pseudo-C... This should find about 2**16 collisions. */ for (i = 0; i < 2**32; i++) { if (burtle(i, ...) == 27) { printf("Found one that hashes to 27: %ul\n", i); } } > > Hmmm... So if you have keys you can't break up? I mean, I'm not sure how > > you would make a generic hash function that would hash any record, or > > any array, or any private type, or ... > > > > Sure, in that case you will have to call the hash function for each > part of the key. But in that case, wouldn't you also need to define a > comparision operator if you used a tree? I think there are many more private types that can be ordered than those that can be hashed, in Ada at least. Most of the fundamental types in Ada come with ordering operators defined, while few come with hashes defined. (In Java, "hash" is defined everywhere, for just this reason.) > In Ada, you can get rid of any packing if you insist, at least more > portably than in C. Well, yeah, but I don't think you'd want to. > Hmm. What's wrong with having a generic hash function which you > instantiate for your private type? Provided that you can read the key > as an array of bytes, it should work the same in both C and Ada. Well, yeah, but I dont think you can. Doing so would mean that you're dependent on the packing of the structure, for example. If your private type contains pointers or gaps in the structure or fields that don't participate in an equality comparison anything like that, your hash is going to fail. Remember that you not only have to generate a hash, but that the hash has to be the same for all values that are considered equal. If you have a string implementation that has a length count but leaves junk at the end of the array of characters, a hash based on the physical contents of the record isn't going to work. > BTW., I'm not arguing for hash tables everywhere. I'm just saying > there are some appliactions where O(log N) just isn't good enough, and that > hash tables *in practice* is what you need. Agreed. There are many applications where you can control the kind of key and almost never want the results softed, in which hash tables are perfect. Symbol tables leap to mind. Perhaps the hashtable would be the third data structure, after sorted maps. :-) Hashtables are actually pretty simple to do, if you make the user supply the hash value and don't make keys or values limited. A hash table with implementations specifically having keys being the various string types would probably satisfy 90% of the need for hash tables, as well. There aren't a whole lot of operations on a hash table, so it's pretty easy to put one together, methinks. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 15:25 ` Darren New @ 2002-04-24 15:39 ` Darren New 2002-04-24 19:32 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-24 15:39 UTC (permalink / raw) Darren New wrote: > /* Crappy pseudo-C... This should find about 2**16 collisions. */ > for (i = 0; i < 2**32; i++) { > if (burtle(i, ...) == 27) { > printf("Found one that hashes to 27: %ul\n", i); > } > } Actually, I take that back. That was dumb. It won't find nearly that many collisions, if "burtle" is returning a 32-bit integer. But the point is severalfold: 1) I *can* find collisions, regardless of the code that implements the hash, 2) Using a cryptographically secure hash with a large range is probably overkill for a basic hash library, so at least the vulnerability should be thought about, 3) if you can insert multiple records with the same key, you can wind up with a system that hashes lots of different stuff to the same value. 4) Hashes are nevertheless an extremely useful library component. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 15:25 ` Darren New 2002-04-24 15:39 ` Darren New @ 2002-04-24 19:32 ` Ole-Hjalmar Kristensen 2002-04-24 19:58 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 19:32 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Ole-Hjalmar Kristensen wrote: > > OK, but how does this malicious user manage to do this when I'm using > > a hash function which on average changes half the bits of its output > > for any single bit change in its input? > > It's called the birthday paradox. You hash enough values, you're going > to find collisions. > > > I'm not saying it's > > impossible, but it seems pretty far-fetched to me. > > It seemed far-fetched to me that someone would disassemble IIS or XP in > order to find unchecked buffer overflows, but they managed within days > of the release of the software, too. > > > Of course, if he's got the source to my program > > I kind of thought that was the point of this exercise - to make source, > yes? > > >and is good at inverting hash functions > > he can do it. In particular (pardon the C code, but as you say > > yourself, in C it's easy), how do you construct your keys so they all > > hash to the same value given this particular hash function? : > > Well, it's hard to read when it isn't complete C, but assuming "u4" is > an unsigned integer four bytes long, it's pretty easy. > > /* Crappy pseudo-C... This should find about 2**16 collisions. */ > for (i = 0; i < 2**32; i++) { > if (burtle(i, ...) == 27) { > printf("Found one that hashes to 27: %ul\n", i); > } > } I'm curious why you expect this to produce 2**16 collisions. The input has a range of 2**32, but so has the output. Of course, when you fold it to a shorter table, you will get collisions, so I would expect 2**16 collisions only if my hash link table has 2**16 elements. But yes, I see your point that a determined malicious user might make some very long hash chains. This may or may not be fatal to the system > > > > Hmmm... So if you have keys you can't break up? I mean, I'm not sure how > > > you would make a generic hash function that would hash any record, or > > > any array, or any private type, or ... > > > > > > > Sure, in that case you will have to call the hash function for each > > part of the key. But in that case, wouldn't you also need to define a > > comparision operator if you used a tree? > > I think there are many more private types that can be ordered than those > that can be hashed, in Ada at least. Most of the fundamental types in > Ada come with ordering operators defined, while few come with hashes > defined. (In Java, "hash" is defined everywhere, for just this reason.) > > > In Ada, you can get rid of any packing if you insist, at least more > > portably than in C. > > Well, yeah, but I don't think you'd want to. > > > Hmm. What's wrong with having a generic hash function which you > > instantiate for your private type? Provided that you can read the key > > as an array of bytes, it should work the same in both C and Ada. > > Well, yeah, but I dont think you can. Doing so would mean that you're > dependent on the packing of the structure, for example. If your private > type contains pointers or gaps in the structure or fields that don't > participate in an equality comparison anything like that, your hash is > going to fail. Remember that you not only have to generate a hash, but > that the hash has to be the same for all values that are considered > equal. If you have a string implementation that has a length count but > leaves junk at the end of the array of characters, a hash based on the > physical contents of the record isn't going to work. > Neither is a predefined relational operator for the array likely to work. According to my admittedly rusty memory, the relational operators are only defined for scalar types and discrete array types, so I cannot see how you can avoid defining your own for record types. So trees have the same problem, really. > > BTW., I'm not arguing for hash tables everywhere. I'm just saying > > there are some appliactions where O(log N) just isn't good enough, and that > > hash tables *in practice* is what you need. > > Agreed. There are many applications where you can control the kind of > key and almost never want the results softed, in which hash tables are > perfect. Symbol tables leap to mind. > Also join processing, hash filters and mappings from disk blocks to buffers to name a few examples of applications I am familiar with. But those applications are probably so specialized that most programmers would write their own hash anyway. > Perhaps the hashtable would be the third data structure, after sorted > maps. :-) Hashtables are actually pretty simple to do, if you make the > user supply the hash value and don't make keys or values limited. A hash > table with implementations specifically having keys being the various > string types would probably satisfy 90% of the need for hash tables, as > well. There aren't a whole lot of operations on a hash table, so it's > pretty easy to put one together, methinks. > > -- > Darren New > San Diego, CA, USA (PST). Cryptokeys on demand. > The 90/10 rule of toothpaste: the last 10% of > the tube lasts as long as the first 90%. I have usually taken the easy way out and required the existence of a hash function for any type which is used as a key. Given that something like the hash function above is available, the hash function itself for a new type usually reduces to a one-liner. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 19:32 ` Ole-Hjalmar Kristensen @ 2002-04-24 19:58 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 19:58 UTC (permalink / raw) Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> writes: <snip> > > Neither is a predefined relational operator for the array likely to work. > > According to my admittedly rusty memory, the relational operators are Should have been *ordering operators*, of course. > only defined for scalar types and discrete array types, so I cannot > see how you can avoid defining your own for record types. So trees > have the same problem, really. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 15:02 ` Ole-Hjalmar Kristensen 2002-04-24 15:25 ` Darren New @ 2002-04-24 19:14 ` Randy Brukardt 2002-04-24 20:01 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 425+ messages in thread From: Randy Brukardt @ 2002-04-24 19:14 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote in message <7vbsc9w367.fsf@vlinux.voxelvision.no>... >Darren New <dnew@san.rr.com> writes: >> how to do this in Ada, tho - it would seem that every private type >> (for example) would have to implement its own hash >> function. Wouldn't it? > >Hmm. What's wrong with having a generic hash function which you >instantiate for your private type? Provided that you can read the key >as an array of bytes, it should work the same in both C and Ada. I >know this is low-level and dirty, but for hashing, I think it's a >reasonable approach. Actually, it doesn't even need to be generic. It is easy to write a hashing algorithm that works with any type that can be streamed (use streaming operations to convert to an array of stream elements, hash that) -- I've seen two such implementations in the last few days. Using streams to do this has the advantage of eliminating packing and implementation-defined components from concern. It does limit the applicability of the package to non-limited keys, but that seems to be an acceptable limitation (do you really need to hash tasks??). Randy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 19:14 ` Randy Brukardt @ 2002-04-24 20:01 ` Ole-Hjalmar Kristensen 2002-04-24 20:09 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 20:01 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Ole-Hjalmar Kristensen wrote in message > <7vbsc9w367.fsf@vlinux.voxelvision.no>... > >Darren New <dnew@san.rr.com> writes: > > >> how to do this in Ada, tho - it would seem that every private type > >> (for example) would have to implement its own hash > >> function. Wouldn't it? > > > >Hmm. What's wrong with having a generic hash function which you > >instantiate for your private type? Provided that you can read the key > >as an array of bytes, it should work the same in both C and Ada. I > >know this is low-level and dirty, but for hashing, I think it's a > >reasonable approach. > > > Actually, it doesn't even need to be generic. It is easy to write a > hashing algorithm that works with any type that can be streamed (use > streaming operations to convert to an array of stream elements, hash > that) -- I've seen two such implementations in the last few days. > > Using streams to do this has the advantage of eliminating packing and > implementation-defined components from concern. It does limit the > applicability of the package to non-limited keys, but that seems to be > an acceptable limitation (do you really need to hash tasks??). > > Randy. Excellent idea, unless there is much overhead involved in the streaming operation. But I suspect it's probably OK. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 20:01 ` Ole-Hjalmar Kristensen @ 2002-04-24 20:09 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-24 20:09 UTC (permalink / raw) > Excellent idea, unless there is much overhead involved in the > streaming operation. But I suspect it's probably OK. That's probably a good way to work it if you don't have a user-defined hash function, or if the user doesn't want to create one. Since you have to hash the key on every lookup, this would seem to be a lot of overhead if you can avoid it. And of course you still have to ensure that two "equal" keys hash to equal values, implying that two equal keys have to stream out to the same sequence of bytes. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 4:57 ` Darren New 2002-04-23 7:10 ` Ole-Hjalmar Kristensen @ 2002-04-23 12:49 ` Alan Reynolds 2002-04-23 16:46 ` Darren New 1 sibling, 1 reply; 425+ messages in thread From: Alan Reynolds @ 2002-04-23 12:49 UTC (permalink / raw) Darren New wrote: > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if > all the elements hash to the same value) or how you'd guarantee any > particular limit on execution time of inserting a value (for example, in > the same case). In contrast, a red-black tree is *never* going to see > O(N) time in any operation. > Except for creation :) Have fun, Al ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 12:49 ` Alan Reynolds @ 2002-04-23 16:46 ` Darren New 2002-04-23 18:55 ` Alan Reynolds 0 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-23 16:46 UTC (permalink / raw) Alan Reynolds wrote: > > Darren New wrote: > > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if > > all the elements hash to the same value) or how you'd guarantee any > > particular limit on execution time of inserting a value (for example, in > > the same case). In contrast, a red-black tree is *never* going to see > > O(N) time in any operation. > > > > Except for creation :) Well, I think you're misunderstanding what O(N) means here. Red-black trees don't support a "create the whole tree" operation, and inserting a single element isn't O(N). I know you're likely joking. (Note that if you include "creation from scratch and filling it with N items", there's no algorithm possible that's faster than O(N), as you have to at least look at all the items.) The advantage of a red-black tree (or any other search tree) over a hash is, of course, that the results are sorted, so iterating over it in order is simple. Implementing a hash version with the same interface as either a hash or a tree would lose this nice property. It's possible that there's a version of one of these data structures that's even faster, based on array heaps or something, but I don't remember what they might be. There's also other forms of trees, like AVL trees, whose properties I also don't remember offhand. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 16:46 ` Darren New @ 2002-04-23 18:55 ` Alan Reynolds 0 siblings, 0 replies; 425+ messages in thread From: Alan Reynolds @ 2002-04-23 18:55 UTC (permalink / raw) Hi Darren, It was a tongue in cheek comment. Often creation (or destruction) is not looked at as an operation but can have a significant cost. A lessen I learned using C++. Ted's requirements steer the implementation right at binary trees. A hash table cannot support sorted traversal in O(n) time. Have fun, Al Darren New wrote: > Alan Reynolds wrote: > >>Darren New wrote: >> >>>I'm not sure why a hashtable wouldn't have a worst-case time of O(N) (if >>>all the elements hash to the same value) or how you'd guarantee any >>>particular limit on execution time of inserting a value (for example, in >>>the same case). In contrast, a red-black tree is *never* going to see >>>O(N) time in any operation. >>> >> >>Except for creation :) > > > Well, I think you're misunderstanding what O(N) means here. Red-black > trees don't support a "create the whole tree" operation, and inserting a > single element isn't O(N). I know you're likely joking. (Note that if > you include "creation from scratch and filling it with N items", there's > no algorithm possible that's faster than O(N), as you have to at least > look at all the items.) > > The advantage of a red-black tree (or any other search tree) over a hash > is, of course, that the results are sorted, so iterating over it in > order is simple. Implementing a hash version with the same interface as > either a hash or a tree would lose this nice property. > > It's possible that there's a version of one of these data structures > that's even faster, based on array heaps or something, but I don't > remember what they might be. There's also other forms of trees, like AVL > trees, whose properties I also don't remember offhand. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 2:15 ` Jeffrey Carter 2002-04-23 4:57 ` Darren New @ 2002-04-23 6:26 ` Kent Paul Dolan 1 sibling, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-23 6:26 UTC (permalink / raw) "Jeffrey Carter" <jrcarter@acm.org> wrote: > Darren New wrote: > > Jeffrey Carter wrote: > > > The trouble with a tree is that, if it is not balanced, operations can > > > be O(N) in the worst case. If the tree is balanced, searching is O(log > > > N), but insertion and deletion are slow, because the tree must be > > > rebalanced after every modification. No, the balance need only be _checked_ after every modification; many insertions or deletions leave the tree in balance, and rebalancing is still a cheap operation. It's been a while, but I thought that for many, the amortized cost of insertion and deletion was still order log N? The TreeSet that I used in Java derived from a class with that software contract. > > Well, that's why you use something a little more sophisticated, like a > > red-black tree, or a B-tree if your memory I/O works in blocks (like a > > disk). > Maybe my memory is faulty, but I seem to recall that these trees still > need rebalancing to maintain O(log N) search times. Yes, you are correct; free lunches are still scarce. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 23:26 ` Darren New 2002-04-23 2:15 ` Jeffrey Carter @ 2002-04-23 2:38 ` Ted Dennison 2002-04-23 18:57 ` Anders Gidenstam 2 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-23 2:38 UTC (permalink / raw) Darren New wrote: > Jeffrey Carter wrote: > >>The trouble with a tree is that, if it is not balanced, operations can >>be O(N) in the worst case. If the tree is balanced, searching is O(log >>N), but insertion and deletion are slow, because the tree must be >>rebalanced after every modification. >> > > Well, that's why you use something a little more sophisticated, like a > red-black tree, or a B-tree if your memory I/O works in blocks (like a > disk). A red-black tree still requires balancing when nodes are added, doesn't it? Balancing on a bounded structure is likely going to involve moving data contents, which is undesirable. That's why I thought it might make sense to just include a Map, and another map-like structure that is naturally bounded. Hash tables came to mind. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 23:26 ` Darren New 2002-04-23 2:15 ` Jeffrey Carter 2002-04-23 2:38 ` Ted Dennison @ 2002-04-23 18:57 ` Anders Gidenstam 2 siblings, 0 replies; 425+ messages in thread From: Anders Gidenstam @ 2002-04-23 18:57 UTC (permalink / raw) In article <3CC49C50.485AE213@san.rr.com>, Darren New <dnew@san.rr.com> writes: > Jeffrey Carter wrote: >> The trouble with a tree is that, if it is not balanced, operations can >> be O(N) in the worst case. If the tree is balanced, searching is O(log >> N), but insertion and deletion are slow, because the tree must be >> rebalanced after every modification. > > Well, that's why you use something a little more sophisticated, like a > red-black tree, or a B-tree if your memory I/O works in blocks (like a > disk). > Just to add one more possible implementation data structure, there is also the random treap, which at least is a bit easier to implement than an AVL tree. The random treap is a search tree w.r.t the element keys and a heap w.r.t an extra field that is assigned a random (uniformly distributed) value when the element is inserted in the tree. This will, with a high probability, keep the tree well balanced. All operations are (amortized) O(log N). I read about them in a course and have a simple implementation on my (old) homepage: http://www.dtek.chalmers.se/~d96andgi/Ada/ /Anders -- -------------------------------------------- "A well-written program is its own heaven; a poorly-written program is its own hell." - The Tao of Programming ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com> 2002-04-22 23:26 ` Darren New @ 2002-04-23 2:32 ` Ted Dennison 2002-04-23 23:46 ` Jeffrey Carter 1 sibling, 1 reply; 425+ messages in thread From: Ted Dennison @ 2002-04-23 2:32 UTC (permalink / raw) Jeffrey Carter wrote: > Trees also have the advantage that they do not waste space. ...which is something we are already agreeing to trade off when we make a structure bounded. > The trouble with a tree is that, if it is not balanced, operations can > be O(N) in the worst case. If the tree is balanced, searching is O(log > N), but insertion and deletion are slow, because the tree must be > rebalanced after every modification. Exactly. > This is why I use skip lists. They do not waste space, and operations > are O(log N) but no rebalancing is needed after modification. Hmmm. I'm unfamiliar with skip lists. (quick web search ensues) It looks like they are probability based, which means that in the worst case it could still behave like a linked-list. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 2:32 ` Ted Dennison @ 2002-04-23 23:46 ` Jeffrey Carter 2002-04-24 15:01 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Jeffrey Carter @ 2002-04-23 23:46 UTC (permalink / raw) Ted Dennison wrote: > > Jeffrey Carter wrote: > > > This is why I use skip lists. They do not waste space, and operations > > are O(log N) but no rebalancing is needed after modification. > Hmmm. I'm unfamiliar with skip lists. > > (quick web search ensues) > > It looks like they are probability based, which means that in the worst > case it could still behave like a linked-list. Skip lists are probabilistically balanced. Average search times are O(log N). The good news is that even a halfway decent random-number generator ensures decent balancing if N is large enough to matter. See figure 8 in ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf "Although a skip list may not be balanced, the probability of a skip list being substantially unbalanced is insignificant. Algorithms for insertion and deletion in skip lists are simpler and faster than equivalent algorithms for balanced trees." -- http://www.cs.umd.edu/~pugh/ Skip lists, like trees and unlike hash tables, provide easy traversal in sorted order. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 23:46 ` Jeffrey Carter @ 2002-04-24 15:01 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-24 15:01 UTC (permalink / raw) Jeffrey Carter wrote: > Skip lists are probabilistically balanced. Average search times are > O(log N). The good news is that even a halfway decent random-number > generator ensures decent balancing if N is large enough to matter. See > figure 8 in > > ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf Excellent reference. But I think there's still a number of advantages to red-black trees over skip lists. I'm interested in hearing why you think skip-lists are superior. Here's my "Top Ten" list... 10) A malicious user could make even the best skip list perform really poorly. In these days of internet break-ins, this could make a difference. All the user has to do is know what the random number generator generates. The user can either delete all the non-level-1 nodes, or run a copy of the PRNG and insert nodes whose value equals the height of the node. In the latter case, you'd wind up with a string of 1 values, all at height 1, then a string of 2 values all at height 2, then a string of 3 values all at height 3, etc. 9) The skip-lists look like they take more space. In addition to an average of 2 pointers for each node, you also have the 'Range value. Since tree nodes are fixed size, I would think a decent compiler wouldn't bother to actually encode the size of the node in each node. 8) The skip-lists look like they take more space, part deux. If I do "insert 1, insert 2, delete 1, insert 3, insert 4, delete 3, insert 5, insert 6, delete 5, ..." 100 times on a tree, I'm going to use up 100 nodes of memory and have one free left over. With a skip-list, since the nodes are different sizes, I'll likely have some additional memory fragmentation. On the other hand, I think after re-reading some red-black and AVL algorithms again, I'm mistaken about the "more space" bit. The problems with a red-black tree are... 7) The balanced trees require you to carry balance information around in the nodes - the red-black tree carries the color and the AVL trees carry the balance. 6) The tree has no obvious way of going from a node to the next node, making an iterator complex to implement. That is, it's easy to traverse a tree in order recursively, but somewhat more difficult to traverse a tree iteratively (in the sense used in Grace.Lists). In a skip-list, each node points to the next node. On the other hand, I don't see any obvious way, given an arbitrary node, to do an insert/delete on a skip-list without repeating the search. 5) The algorithms are admittedly a little more complicated, with probably a few more assignments of pointers than with skip-lists. However, the algorithms are well-known, widely available, and only need to be implemented once, so I don't see the complexity factor as very important. It might be a touch slower tho, with maybe 8 or 10 pointer assignments where a skip-list doing the same thing might have 2 or 4. +=+=+ Overall, it might be that the best implementation is a doubly-linked list with either a tree or a skip-list on top. That is, either a skip-list where each node also includes back pointers to the previous nodes, or a red-black or an AVL tree where each node includes pointers to the previous and next value. This way, there's an very similar interface to the List package, except that "insert" takes both a key and a value, and instantiation requires the "<" operator. You could build it as essentially a doubly-linked list that keeps itself in order efficiently. I don't see any compelling value of using a skip-list over using a tree, or vica versa. Perhaps providing both implementations would be of interest, proving that the interface is sufficiently generic that the implementation can be completely changed under the covers. This would allow the real-time folks to get deterministic behavior when they wanted at the expense of better probabilistic performance. I'd be interested in hearing what the advantages of the skip-list are over trees, other than slightly simpler code. Is it just the performance? (Which is, of course, important.) > "Although a skip list may not be balanced, the probability of a skip > list being substantially unbalanced is insignificant. I think he means a *random* skip-list. The probability is insignificant if you don't actually *try* to unbalance it. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <4519e058.0204220534.2eb33730@posting.go <3CC4E9DA.E02BE0DA@san.rr.com>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC4E9DA.E02BE0DA@san.rr.com> @ 2002-04-23 5:21 ` Simon Wright 2002-04-23 7:37 ` Ole-Hjalmar Kristensen 2002-04-23 22:33 ` David Bolen 0 siblings, 2 replies; 425+ messages in thread From: Simon Wright @ 2002-04-23 5:21 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) > (if all the elements hash to the same value) or how you'd guarantee > any particular limit on execution time of inserting a value (for > example, in the same case). In contrast, a red-black tree is *never* > going to see O(N) time in any operation. I would have expected a hash table to have O(N) anyway, at least for searching; it's just that the multiplier is reduced by the number of hash buckets. This is certainly the case for the BCs, now you all come to mention it! Insertion is constant time, though. Are red-black trees much better than AVL trees (which is what you get in the BCs)? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 5:21 ` Simon Wright @ 2002-04-23 7:37 ` Ole-Hjalmar Kristensen 2002-04-23 22:33 ` David Bolen 1 sibling, 0 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-23 7:37 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Darren New <dnew@san.rr.com> writes: > > > I'm not sure why a hashtable wouldn't have a worst-case time of O(N) > > (if all the elements hash to the same value) or how you'd guarantee > > any particular limit on execution time of inserting a value (for > > example, in the same case). In contrast, a red-black tree is *never* > > going to see O(N) time in any operation. > > I would have expected a hash table to have O(N) anyway, at least for > searching; it's just that the multiplier is reduced by the number of > hash buckets. > > This is certainly the case for the BCs, now you all come to mention > it! Insertion is constant time, though. > > Are red-black trees much better than AVL trees (which is what you get > in the BCs)? You size your hash link table so that the order is what you want. I usually aim for O(1). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 5:21 ` Simon Wright 2002-04-23 7:37 ` Ole-Hjalmar Kristensen @ 2002-04-23 22:33 ` David Bolen 2002-04-24 6:42 ` Jean-Marc Bourguet 1 sibling, 1 reply; 425+ messages in thread From: David Bolen @ 2002-04-23 22:33 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Darren New <dnew@san.rr.com> writes: > > Are red-black trees much better than AVL trees (which is what you get > in the BCs)? I believe the primary difference is a better bound on the number of operations to perform to re-balance the tree. In an AVL tree you may need to perform lg n rotations, whereas in an red-black tree you have a maximum of 2 rotations for insertion, and 3 for deletion. How much of an improvement this is would depend on the cost of performing the rotation. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 22:33 ` David Bolen @ 2002-04-24 6:42 ` Jean-Marc Bourguet 2002-04-24 18:18 ` David Bolen 0 siblings, 1 reply; 425+ messages in thread From: Jean-Marc Bourguet @ 2002-04-24 6:42 UTC (permalink / raw) David Bolen <db3l@fitlinxx.com> writes: > Simon Wright <simon@pushface.org> writes: > > > Darren New <dnew@san.rr.com> writes: > > > > Are red-black trees much better than AVL trees (which is what you get > > in the BCs)? > > I believe the primary difference is a better bound on the number of > operations to perform to re-balance the tree. In an AVL tree you may > need to perform lg n rotations, whereas in an red-black tree you have > a maximum of 2 rotations for insertion, and 3 for deletion. Red-Black trees are a special case of B-Trees (consider a black node with its red child and you have a B-Tree bucket). So the maximum number of operations needed on insertion and deletioon is of the order of log n. -- Jean-Marc ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 6:42 ` Jean-Marc Bourguet @ 2002-04-24 18:18 ` David Bolen 2002-04-25 7:40 ` Jean-Marc Bourguet 0 siblings, 1 reply; 425+ messages in thread From: David Bolen @ 2002-04-24 18:18 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > David Bolen <db3l@fitlinxx.com> writes: (...) > > I believe the primary difference is a better bound on the number of > > operations to perform to re-balance the tree. In an AVL tree you may > > need to perform lg n rotations, whereas in an red-black tree you have > > a maximum of 2 rotations for insertion, and 3 for deletion. > > Red-Black trees are a special case of B-Trees (consider a black node > with its red child and you have a B-Tree bucket). So the maximum > number of operations needed on insertion and deletioon is of the order > of log n. Yes, total operations for insertion/deletion is lg n - but the question was the difference between red-black and AVL (both of which are balanced trees with O(lg n)), and the difference there is how many actual rotations you perform while re-balancing the tree. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 18:18 ` David Bolen @ 2002-04-25 7:40 ` Jean-Marc Bourguet 2002-04-25 22:23 ` David Bolen 0 siblings, 1 reply; 425+ messages in thread From: Jean-Marc Bourguet @ 2002-04-25 7:40 UTC (permalink / raw) David Bolen <db3l@fitlinxx.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > David Bolen <db3l@fitlinxx.com> writes: > (...) > > > I believe the primary difference is a better bound on the number of > > > operations to perform to re-balance the tree. In an AVL tree you may > > > need to perform lg n rotations, whereas in an red-black tree you have > > > a maximum of 2 rotations for insertion, and 3 for deletion. > > > > Red-Black trees are a special case of B-Trees (consider a black node > > with its red child and you have a B-Tree bucket). So the maximum > > number of operations needed on insertion and deletioon is of the order > > of log n. > > Yes, total operations for insertion/deletion is lg n - but the > question was the difference between red-black and AVL (both of which > are balanced trees with O(lg n)), and the difference there is how many > actual rotations you perform while re-balancing the tree. There is an isomorphism between Red-Black trees and B-Trees (if this is not clear, look for 2-3 and 2-3-4 trees in the litterature, if memory serves Aho's books on algorithms is a good place) and rotation with color change are the equivalent of bucket split/merge. As on insertion or deletion in a B-Tree, the number of bucket split/merge is O(lg n) -- I think this is easier to see --, it is true also of the number of rotation in a Red-Black trees when rebalancing after an insertion/deletion. Examples: insert numbers from 1 to 17 in this order in a red-black trees. delete the numbers from 1 to 8 in this order in the resulting tree. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 7:40 ` Jean-Marc Bourguet @ 2002-04-25 22:23 ` David Bolen 0 siblings, 0 replies; 425+ messages in thread From: David Bolen @ 2002-04-25 22:23 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > David Bolen <db3l@fitlinxx.com> writes: (...) > > Yes, total operations for insertion/deletion is lg n - but the > > question was the difference between red-black and AVL (both of which > > are balanced trees with O(lg n)), and the difference there is how many > > actual rotations you perform while re-balancing the tree. > > There is an isomorphism between Red-Black trees and B-Trees (if this > is not clear, look for 2-3 and 2-3-4 trees in the litterature, if > memory serves Aho's books on algorithms is a good place) and rotation > with color change are the equivalent of bucket split/merge. As on > insertion or deletion in a B-Tree, the number of bucket split/merge is > O(lg n) -- I think this is easier to see --, it is true also of the > number of rotation in a Red-Black trees when rebalancing after an > insertion/deletion. Hmm, this may just be a terminology issue, and I'm far from an expert on these algorithms, but I did take a quick double check in Cormen's Intro to Algorithms before that last reply and sections 13.3 and 13.4 cover insertion and deletion and the analysis of only 2 and 3 rotations respectively. Note that I'm not suggesting that the running time is anything other than O(lg n), which is definitely true for both operations; just that the actual number of rotations performed (adjustment of location within the tree of internal nodes) as the tree is traversed during the rebalancing is more limited with red-black trees. Of course, during the overall process nodes may be re-colored without being rotated, but while such color changes are part of re-balancing, I don't consider them a "rotation". > Examples: insert numbers from 1 to 17 in this order in a red-black trees. > delete the numbers from 1 to 8 in this order in the > resulting tree. I tried a quick test of this using the RB implemention in the GNU libavl library, and in this particular case never found more than a single rotation per insertion/deletion: I found (R=rotation, r=red, b=black): Insertion: 1,2,3R,4,5R,6,7R,8R,9R,10,11R,12R,13R,14,15R,16R,17R 1: 1b 2: 1b(,2r) R 3: 2b(1r,3r) 4: 2b(1b,3b(,4r)) R 5: 2b(1b,4b(3r,5r)) 6: 2b(1b,4r(3b,5b(,6r))) R 7: 2b(1b,4r(3b,6b(5r,7r))) R 8: 4b(2r(1b,3b),6r(5b,7b(,8r))) R 9: 4b(2r(1b,3b),6r(5b,8b(7r,9r))) 10: 4b(2b(1b,3b),6b(5b,8r(7b,9b(,10r)))) R 11: 4b(2b(1b,3b),6b(5b,8r(7b,10b(9r,11r)))) R 12: 4b(2b(1b,3b),8b(6r(5b,7b),10r(9b,11b(,12r)))) R 13: 4b(2b(1b,3b),8b(6r(5b,7b),10r(9b,12b(11r,13r)))) 14: 4b(2b(1b,3b),8r(6b(5b,7b),10b(9b,12r(11b,13b(,14r))))) R 15: 4b(2b(1b,3b),8r(6b(5b,7b),10b(9b,12r(11b,14b(13r,15r))))) R 16: 4b(2b(1b,3b),8r(6b(5b,7b),12b(10r(9b,11b),14r(13b,15b(,16r))))) R 17: 4b(2b(1b,3b),8r(6b(5b,7b),12b(10r(9b,11b),14r(13b,16b(15r,17r))))) +----------- 4b ----------+ +-- 2b --+ +------- 8r -------+ 1b 3b +-- 6b --+ +---- 12b ----+ 5b 7b +- 10r -+ +- 14r -+ 9b 11b 13b +- 16b -+ 15r 17r Deletion: 1R,2R,3R,4R,5R,6R,7R,8R R 1: 8b(4b(2b(,3r),6r(5b,7b)),12b(10r(9b,11b),14r(13b,16b(15r,17r)))) R 2: 8b(4b(3b,6r(5b,7b)),12b(10r(9b,11b),14r(13b,16b(15r,17r)))) R 3: 8b(6b(4b(,5r),7b),12b(10r(9b,11b),14r(13b,16b(15r,17r)))) R 4: 8b(6b(5b,7b),12b(10r(9b,11b),14r(13b,16b(15r,17r)))) R 5: 12b(8b(6b(,7r),10r(9b,11b)),14b(13b,16b(15r,17r))) R 6: 12b(8b(7b,10r(9b,11b)),14b(13b,16b(15r,17r))) R 7: 12b(10b(8b(,9r),11b),14b(13b,16b(15r,17r))) R 8: 12b(10b(9b,11b),14b(13b,16b(15r,17r))) +---- 12b ----+ +- 10b -+ +- 14b -+ 9b 11b 13b +- 16b -+ 15r 17r -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 5:20 ` Simon Wright ` (3 preceding siblings ...) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC4E9DA.E02BE0DA@san.rr.com> @ 2002-04-24 17:25 ` Jeffrey Carter [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com> [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC5B161.C719C5D8@san.rr.com> 6 siblings, 0 replies; 425+ messages in thread From: Jeffrey Carter @ 2002-04-24 17:25 UTC (permalink / raw) <3CC48F34.5A474E0F@boeing.com> <3CC4C800.10107@telepath.com> <3CC5F26A.6F74BD0F@boeing.com> <3CC6C8DA.162604F7@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Darren New wrote: > > Jeffrey Carter wrote: > > Skip lists are probabilistically balanced. Average search times are > > O(log N). The good news is that even a halfway decent random-number > > generator ensures decent balancing if N is large enough to matter. See > > figure 8 in > > > > ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf I was a bit imprecise in my language here. The quality of the generator is not very important if insertions are fairly random. If insertions tend to be ordered, a poor generator can degrade performance. With a decent generator, such as the Ada.Float_Random that comes with GNAT, the order of insertions is immaterial. > > Excellent reference. But I think there's still a number of advantages to > red-black trees over skip lists. I'm interested in hearing why you think > skip-lists are superior. This is the paper in CACM in which Pugh introduced skip lists. Those were the good old days. You don't find useful algorithms in CACM anymore ... > > Here's my "Top Ten" list... Looks like 6 to me, with three of them being reasons skip lists are better :) > > 10) A malicious user could make even the best skip list perform really > poorly. In these days of internet break-ins, this could make a > difference. All the user has to do is know what the random number > generator generates. The user can either delete all the non-level-1 > nodes, or run a copy of the PRNG and insert nodes whose value equals the > height of the node. In the latter case, you'd wind up with a string of 1 > values, all at height 1, then a string of 2 values all at height 2, then > a string of 3 values all at height 3, etc. This is difficult to do if, as one would expect, the random number generator is seeded using the time. Not impossible, I agree. Is it worth worrying about in the general case? For small N, the difference in time is negligible; for large N, the best you can achieve is to slow the system down. I don't expect generic components to be suitable for secure applications. > > 9) The skip-lists look like they take more space. In addition to an > average of 2 pointers for each node, you also have the 'Range value. > Since tree nodes are fixed size, I would think a decent compiler > wouldn't bother to actually encode the size of the node in each node. With the recommended p=0.25, they take an average of 1.333 pointers/node. They have a Height component lacking in trees, but balanced trees tend to have balance information in the nodes. You've addressed this below. Some argue that skip lists take less space, but I consider them equivalent. > > 8) The skip-lists look like they take more space, part deux. If I do > "insert 1, insert 2, delete 1, insert 3, insert 4, delete 3, insert 5, > insert 6, delete 5, ..." 100 times on a tree, I'm going to use up 100 > nodes of memory and have one free left over. With a skip-list, since the > nodes are different sizes, I'll likely have some additional memory > fragmentation. True for an unbounded implementation. You could make all the nodes the same size, if you don't mind the wasted space :) Naturally, a bounded implementation avoids fragmentation. > 6) The tree has no obvious way of going from a node to the next node, > making an iterator complex to implement. That is, it's easy to traverse > a tree in order recursively, but somewhat more difficult to traverse a > tree iteratively (in the sense used in Grace.Lists). In a skip-list, > each node points to the next node. On the other hand, I don't see any > obvious way, given an arbitrary node, to do an insert/delete on a > skip-list without repeating the search. For a general purpose component, I don't see trees offering insert/delete without a search, either. If you're going to keep state information about the last search and use it to optimize insert/delete, you could do that for any implementation. > > 5) The algorithms are admittedly a little more complicated, with > probably a few more assignments of pointers than with skip-lists. > However, the algorithms are well-known, widely available, and only need > to be implemented once, so I don't see the complexity factor as very > important. It might be a touch slower tho, with maybe 8 or 10 pointer > assignments where a skip-list doing the same thing might have 2 or 4. A *little* more complicated? I've seen balanced tree deletion algorithms in texts that run to 4 pages; compare that to the 20 lines or so for a skip list. As for timing, Pugh compares the CPU time of skip lists against several kinds of balanced trees. Skip lists are about as fast or faster than the trees for searching, and faster than the trees for insert/delete. http://www.csihq.com/analysis/skiplist.pdf compares insertion times in skip lists to B-trees (N=50,000 to 950,000 in 50,000 steps) and found that Unix system time increased exponentially for N>=600,000, while it increased linearly for skip lists, indicating that large B-trees did significantly. Considering only Unix CPU time, skip lists were 5-10 times as fast as B-trees; an order of magnitude is not a "touch" slower. > I'd be interested in hearing what the advantages of the skip-list are > over trees, other than slightly simpler code. Is it just the > performance? (Which is, of course, important.) Between the significantly simpler algorithms, which are more likely to be implemented correctly, and the observed performance advantages of skip lists, the choice seems obvious. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com> @ 2002-04-24 17:48 ` Darren New 2002-04-24 23:12 ` Jeffrey Carter 2002-04-24 19:51 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-24 17:48 UTC (permalink / raw) Jeffrey Carter wrote: > Darren New wrote: > > > > Jeffrey Carter wrote: > > > Skip lists are probabilistically balanced. Average search times are > > > O(log N). The good news is that even a halfway decent random-number > > > generator ensures decent balancing if N is large enough to matter. See > > > figure 8 in > > > > > > ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf > > I was a bit imprecise in my language here. The quality of the generator > is not very important if insertions are fairly random. If insertions > tend to be ordered, a poor generator can degrade performance. With a > decent generator, such as the Ada.Float_Random that comes with GNAT, the > order of insertions is immaterial. FWIW, I didn't write this part, in spite of quoting anomolies. :-) > > Here's my "Top Ten" list... > > Looks like 6 to me, with three of them being reasons skip lists are > better :) <foghorn_leghorn> It's a joke, son. A joke, Ah say. </foghorn_leghorn> > I don't expect generic components to be suitable for secure > applications. I would expect generic components to be sufficiently secure to allow them to be used as (say) part of a CGI script or something. But I think as long as the potential pitfalls of a worst-case performance are documented along with how to get around them, it's cool. > With the recommended p=0.25, they take an average of 1.333 > pointers/node. This would degrade performance, tho, yes? An average of two extra link-follows per search? Or am I misunderstanding? (Maybe "p" should be a parameter? Nah, too messy.) > True for an unbounded implementation. You could make all the nodes the > same size, if you don't mind the wasted space :) Naturally, a bounded > implementation avoids fragmentation. And I guess with a bounded implementation, you know the right maximum height too. > For a general purpose component, I don't see trees offering > insert/delete without a search, either. I think you can do this, since Red-Black trees keep a pointer to the parent. I'm not sure tho, and yes, another friend explained how you'd go about keeping enough info in a skip-list iterator (basically, N backpointers where N is the height of the head) to do the inserts and deletes without the search. > A *little* more complicated? I've seen balanced tree deletion algorithms > in texts that run to 4 pages; Nah. http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/red_black.html Not *that* complicated. I'll admit it's not *obvious*, but once given, it's not *complicated*. On the other hand, skip-list implementations are *obvious*, but whether they're efficient isn't obvious. Of course, the paper shows they are. > Between the significantly simpler algorithms, which are more likely to > be implemented correctly, and the observed performance advantages of > skip lists, the choice seems obvious. Fair enough. I'm convinced. :-) Add a backpointer to each node as well, and you've got a doubly-linked list that you can search really, really fast. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 17:48 ` Darren New @ 2002-04-24 23:12 ` Jeffrey Carter 2002-04-25 0:11 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Jeffrey Carter @ 2002-04-24 23:12 UTC (permalink / raw) Darren New wrote: > > Jeffrey Carter wrote: > > With the recommended p=0.25, they take an average of 1.333 > > pointers/node. > > This would degrade performance, tho, yes? An average of two extra > link-follows per search? Or am I misunderstanding? (Maybe "p" should be > a parameter? Nah, too messy.) It increases the probability that a search path is longer than expected compared to p=0.5. But with N=256 and p=0.25, the probability of a search path of 3*log N (24) is about 0.001. > > A *little* more complicated? I've seen balanced tree deletion algorithms > > in texts that run to 4 pages; > > Nah. > http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/red_black.html > Not *that* complicated. I'll admit it's not *obvious*, but once given, > it's not *complicated*. On the other hand, skip-list implementations are > *obvious*, but whether they're efficient isn't obvious. Of course, the > paper shows they are. Let's see, the else part is just as long as the if part, so the insert is really nearly twice as long as shown, 1.5-2 pages in a text. Full code for both rotations is another page, and your basic tree insertion is another page, so that's getting on to 4 pages. At least it's not recursive. One of the advantages of skip lists is that there's really only 1 way to implement insert and delete. With most balanced trees the easier way is with recursion, and eliminating that recursion is complicated enough that most people don't try. > Fair enough. I'm convinced. :-) Add a backpointer to each node as well, > and you've got a doubly-linked list that you can search really, really > fast. :-) But now I'm starting to like red-black trees ... :) -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 23:12 ` Jeffrey Carter @ 2002-04-25 0:11 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-25 0:11 UTC (permalink / raw) Jeffrey Carter wrote: > Let's see, the else part is just as long as the if part, Ah. I hadn't realized it isn't complete. Nevertheless, you still only have to code it once. :-) > But now I'm starting to like red-black trees ... :) Well, B-trees are really the way to go for sorted lists on disk. I've never seen them implemented any other way. (Not that they haven't been, I've just never seen it. If someone has, let me know. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com> 2002-04-24 17:48 ` Darren New @ 2002-04-24 19:51 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 19:51 UTC (permalink / raw) Jeffrey Carter <jeffrey.carter@boeing.com> writes: <snip> > As for timing, Pugh compares the CPU time of skip lists against several > kinds of balanced trees. Skip lists are about as fast or faster than the > trees for searching, and faster than the trees for insert/delete. > http://www.csihq.com/analysis/skiplist.pdf compares insertion times in > skip lists to B-trees (N=50,000 to 950,000 in 50,000 steps) and found > that Unix system time increased exponentially for N>=600,000, while it > increased linearly for skip lists, indicating that large B-trees did > significantly. Considering only Unix CPU time, skip lists were 5-10 > times as fast as B-trees; an order of magnitude is not a "touch" slower. > This benchmark is a bit strange, in that it compares the performance of a structure specifically tuned for use on disk (if indeed the B-tree it refers to is the same as defined by Bayer & McCreight) with the skip list, which is intented for in-memory use. Do you know if anyone has bechmarked or analysed the performance of a skip list if it were to reside on disk? I'm not arguing against skip lists, just curious if it might be a viable alternative to B-trees for disk based storage. > > I'd be interested in hearing what the advantages of the skip-list are > > over trees, other than slightly simpler code. Is it just the > > performance? (Which is, of course, important.) > > Between the significantly simpler algorithms, which are more likely to > be implemented correctly, and the observed performance advantages of > skip lists, the choice seems obvious. > > -- > Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <4519e058.0204220534.2eb33730@posting.go <3CC5B161.C719C5D8@san.rr.com>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC5B161.C719C5D8@san.rr.com> @ 2002-04-26 5:27 ` Simon Wright 0 siblings, 0 replies; 425+ messages in thread From: Simon Wright @ 2002-04-26 5:27 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: "<" vs hash] > On the other hand, most of the built-in types and > metatypes ("record", "array", etc) already have ordering operators > or rules on how to deduce them from the components. One of my examples is the Vehicle type, keyed by [licence issueing office + licence serial code] (both strings): a sort is just as artificial as a hash, I think. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 0:36 ` Larry Kilgallen 2002-04-22 5:20 ` Simon Wright @ 2002-04-22 13:31 ` Ted Dennison 2002-04-22 14:15 ` Ole-Hjalmar Kristensen 2002-04-22 23:59 ` Larry Kilgallen 1 sibling, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-22 13:31 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>... > In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > > > On second thought, we really ought to get some kind of consensus on > > requirements before rushing headlong into design. If nothing else, it > > will save a lot of arguments. > > > > Requirements I think ought to be included (using the usual should/shall > > language): > > > > Maps shall provide for key lookup in no worse than O(logn) average time > > and O(n) worst case (where n is the # of elements in the map). > > > > Maps shall provide for creation of a sorted list or array, or traversal > > in sorted order, in no worse than O(n) time. (In other words, the map is > > kept sorted as elements are added). > > > > Maps should provide an interface consistent with Lists, as far as is > > practicable. > > > > Comments? > > While the interface should not _prevent_ implementations from > achieving certain performance goals, I don't think performance > goals should be part of the requirements. If a vendor wants to > provide a relatively slow implementation, that is their choice, > just like their choice regarding how fast A := B'length should > perform. I can see your point. For real-time use its vital to know this. I'd prefer to see it in the requrements that Maps are usable in real-time once the map is already built, which is what these requirements are getting at. Perhaps I am committing the cardinal sin of trying to design with requirements though. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 13:31 ` Ted Dennison @ 2002-04-22 14:15 ` Ole-Hjalmar Kristensen 2002-04-22 23:59 ` Larry Kilgallen 1 sibling, 0 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-22 14:15 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>... > > In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes: > > > > > On second thought, we really ought to get some kind of consensus on > > > requirements before rushing headlong into design. If nothing else, it > > > will save a lot of arguments. > > > > > > Requirements I think ought to be included (using the usual should/shall > > > language): > > > > > > Maps shall provide for key lookup in no worse than O(logn) average time > > > and O(n) worst case (where n is the # of elements in the map). > > > > > > Maps shall provide for creation of a sorted list or array, or traversal > > > in sorted order, in no worse than O(n) time. (In other words, the map is > > > kept sorted as elements are added). > > > > > > Maps should provide an interface consistent with Lists, as far as is > > > practicable. > > > > > > Comments? > > > > While the interface should not _prevent_ implementations from > > achieving certain performance goals, I don't think performance > > goals should be part of the requirements. If a vendor wants to > > provide a relatively slow implementation, that is their choice, > > just like their choice regarding how fast A := B'length should > > perform. > > I can see your point. For real-time use its vital to know this. I'd > prefer to see it in the requrements that Maps are usable in real-time > once the map is already built, which is what these requirements are > getting at. > > Perhaps I am committing the cardinal sin of trying to design with > requirements though. > > > -- > T.E.D. > Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) > Homepage - http://www.telepath.com/dennison/Ted/TED.html I think that it should be part of the specification. Otherwise, you will be tempted to roll your own because you do not trust the implementation. Essentially, it's a guarantee of 'quality of service'. If you are not interested in performance, you could very well get by with just a list implementation and limit your library to that :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 13:31 ` Ted Dennison 2002-04-22 14:15 ` Ole-Hjalmar Kristensen @ 2002-04-22 23:59 ` Larry Kilgallen 1 sibling, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-22 23:59 UTC (permalink / raw) In article <4519e058.0204220531.3a47ba39@posting.google.com>, dennison@telepath.com (Ted Dennison) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<V+UgdHreGTJg@eisner.encompasserve.org>... >> In article <3CC21747.5000501@telepath.com>, Ted Dennison <dennison@telepath.com> writes: >> >> > On second thought, we really ought to get some kind of consensus on >> > requirements before rushing headlong into design. If nothing else, it >> > will save a lot of arguments. >> > >> > Requirements I think ought to be included (using the usual should/shall >> > language): >> > >> > Maps shall provide for key lookup in no worse than O(logn) average time >> > and O(n) worst case (where n is the # of elements in the map). >> > >> > Maps shall provide for creation of a sorted list or array, or traversal >> > in sorted order, in no worse than O(n) time. (In other words, the map is >> > kept sorted as elements are added). >> > >> > Maps should provide an interface consistent with Lists, as far as is >> > practicable. >> > >> > Comments? >> >> While the interface should not _prevent_ implementations from >> achieving certain performance goals, I don't think performance >> goals should be part of the requirements. If a vendor wants to >> provide a relatively slow implementation, that is their choice, >> just like their choice regarding how fast A := B'length should >> perform. > > I can see your point. For real-time use its vital to know this. I'd > prefer to see it in the requrements that Maps are usable in real-time > once the map is already built, which is what these requirements are > getting at. Certain operating systems are not suitable for "real-time"[1] use. Why would you place a requirement on compiler vendors for those operating systems that they support a performance level no genuine customer would ever use ? What aspect of the current Ada95 standard has such a performance specification ? [1] For suitable definitions of "real-time". In fact, for suitable definitions of "operating systems" :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison 2002-04-21 5:49 ` Simon Wright 2002-04-22 0:36 ` Larry Kilgallen @ 2002-04-22 14:37 ` Marin David Condic 2002-04-22 18:44 ` Michael Erdmann ` (2 subsequent siblings) 5 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 14:37 UTC (permalink / raw) Can the requirements be kept lean enough to be put in the banner of the code? For a widely circulated project, it would be nice to be sure all the important things go along with the code. A separate document could be problematic. I have no objections to doing some requirements first. I think in the case of our relatively small container stuff, there probably are not a really long list of them - but there could be for some other libraries. My suggestions: 1) Maps shall be Stuff That's Cool. 2) Maps shall not be Stuff That Sucks. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ted Dennison" <dennison@telepath.com> wrote in message news:3CC21747.5000501@telepath.com... > > > On second thought, we really ought to get some kind of consensus on > requirements before rushing headlong into design. If nothing else, it > will save a lot of arguments. > > Requirements I think ought to be included (using the usual should/shall > language): > > Maps shall provide for key lookup in no worse than O(logn) average time > and O(n) worst case (where n is the # of elements in the map). > > Maps shall provide for creation of a sorted list or array, or traversal > in sorted order, in no worse than O(n) time. (In other words, the map is > kept sorted as elements are added). > > Maps should provide an interface consistent with Lists, as far as is > practicable. > > Comments? > > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison ` (2 preceding siblings ...) 2002-04-22 14:37 ` Marin David Condic @ 2002-04-22 18:44 ` Michael Erdmann 2002-04-23 2:18 ` Ted Dennison 2002-04-23 14:46 ` Stephen Leake 2002-04-23 17:50 ` Warren W. Gay VE3WWG 5 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-22 18:44 UTC (permalink / raw) To: Ted Dennison Ted Dennison wrote: > Ted Dennison wrote: > >> Marin David Condic wrote: >> >>> I don't think you need to have the full-blown project setup done in >>> order to >>> discuss an interface to Maps. What would you suggest as a means of >>> getting >>> that ball rolling? Would you like someone to take the Lists spec and >>> turn it >>> into a strawman for Maps? (I hear you're a little preoccupied at the >>> moment... :-) >> >> >> >> Yeah, that would be a good start. Right now in addtion to this I'm > > > > On second thought, we really ought to get some kind of consensus on > requirements before rushing headlong into design. If nothing else, it > will save a lot of arguments. I guess a reference implementation which could be discussed will have less lines than this thread. Working in a group on an exsiting reference implementation (which might be even a bad solution) is more open source style working then trying to get some kind of consensus in such a loosly connected community as comp.lang.ada is! Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 18:44 ` Michael Erdmann @ 2002-04-23 2:18 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-23 2:18 UTC (permalink / raw) Michael Erdmann wrote: > Working in a group on an exsiting reference implementation (which > might be even a bad solution) is more open source style working then > trying to get some kind of consensus in such a loosly connected > community as comp.lang.ada is! ESR's theory about "OpenSource" development mostly talks about just that: development. Before development you have to do some kind of design, and before that you have to do some kind of requirements analysis. ESR does mention that most OpenSource projects have it fairly easy in the RA department, either because their requirements are "clone *this* BSD Unix command", or because they start life as one person's personal playtoy and grow organicly from there. We don't have either of those advantages here, so we must do real requriements analysis. We can do it by actually trying to achieve consensus up front, or by fighting in circles around differing implementations created from differing philosophies. The former method is ususally much quicker. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison ` (3 preceding siblings ...) 2002-04-22 18:44 ` Michael Erdmann @ 2002-04-23 14:46 ` Stephen Leake 2002-04-23 17:50 ` Warren W. Gay VE3WWG 5 siblings, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-23 14:46 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Requirements I think ought to be included (using the usual > should/shall language): > > Maps shall provide for key lookup in no worse than O(logn) average > time and O(n) worst case (where n is the # of elements in the map). > > Maps shall provide for creation of a sorted list or array, or > traversal in sorted order, in no worse than O(n) time. (In other > words, the map is kept sorted as elements are added). > > Maps should provide an interface consistent with Lists, as far as is > practicable. > > Comments? These work for me. We could add something about no memory leaks, but maybe that's implied. One of the requirements for Grace.Lists was that it be useable with one instantiation. That had a significant impact on the final design. Do we want to keep that in general for Grace? I think not, if we have any intention of it being used in serious work. Both the Booch Components and SAL generally need several instantiations to get useful stuff, because they provide more flexibility. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 1:33 ` Ted Dennison ` (4 preceding siblings ...) 2002-04-23 14:46 ` Stephen Leake @ 2002-04-23 17:50 ` Warren W. Gay VE3WWG 2002-04-23 18:27 ` Marin David Condic 2002-04-23 18:59 ` Stephen Leake 5 siblings, 2 replies; 425+ messages in thread From: Warren W. Gay VE3WWG @ 2002-04-23 17:50 UTC (permalink / raw) Ted Dennison wrote: > Ted Dennison wrote: >> Marin David Condic wrote: >>> I don't think you need to have the full-blown project setup done in >>> order to >>> discuss an interface to Maps. What would you suggest as a means of >>> getting >>> that ball rolling? Would you like someone to take the Lists spec and >>> turn it >>> into a strawman for Maps? (I hear you're a little preoccupied at the >>> moment... :-) >> >> Yeah, that would be a good start. Right now in addtion to this I'm > > On second thought, we really ought to get some kind of consensus on > requirements before rushing headlong into design. If nothing else, it > will save a lot of arguments. > > Requirements I think ought to be included (using the usual should/shall > language): > > Maps shall provide for key lookup in no worse than O(logn) average time > and O(n) worst case (where n is the # of elements in the map). > > Maps shall provide for creation of a sorted list or array, or traversal > in sorted order, in no worse than O(n) time. (In other words, the map is > kept sorted as elements are added). I'm not sure about this sort requirement. Many applications only need to fetch a value based upon a key. Requiring that the map be sorted will probably impose suboptimal performance if your requirement doesn't require sorting. The sort requirment could be made as part of iteration, and optionally at that. Just my $0.02 Cdn, which isn't worth much these days ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 17:50 ` Warren W. Gay VE3WWG @ 2002-04-23 18:27 ` Marin David Condic 2002-04-24 14:20 ` John English 2002-04-23 18:59 ` Stephen Leake 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-23 18:27 UTC (permalink / raw) I'd think we would want to retrieve the elements back in order as the general case. Think about using it to store a directory of files or something similar - you add/delete elements from the map and then want to refresh a display to show it to the user. Chances are, sorting is important. It might pay to have a specific case for a hash table that adds performance at the price of lack of sorted order, but for a Mark 1, Mod 0 map package, I'd say it should have sorting. What do other languages provide with maps? MFC? STL? I'll bet you can get items sorted on the key. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:3CC59ED2.1000803@home.com... > > I'm not sure about this sort requirement. Many applications only need to > fetch a value based upon a key. Requiring that the map be sorted will > probably impose suboptimal performance if your requirement doesn't require > sorting. > > The sort requirment could be made as part of iteration, and optionally > at that. Just my $0.02 Cdn, which isn't worth much these days ;-) > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 18:27 ` Marin David Condic @ 2002-04-24 14:20 ` John English 2002-04-24 15:05 ` Marin David Condic 2002-04-26 5:41 ` Simon Wright 0 siblings, 2 replies; 425+ messages in thread From: John English @ 2002-04-24 14:20 UTC (permalink / raw) Marin David Condic wrote: > > What do other languages provide with maps? MFC? STL? I'll bet you can get > items sorted on the key. A common approach is to provide a way to get a list of keys, which you can then sort as you wish before using it to extract elements, rather than building all the same old sorting functionality into yet another data structure. ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 14:20 ` John English @ 2002-04-24 15:05 ` Marin David Condic 2002-04-26 5:41 ` Simon Wright 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-24 15:05 UTC (permalink / raw) The important thing being that if you can store elements in a map based on a key for which you have an operation "<" that makes sense, you will in all likelihood want to scan that map such that you retrieve the elements in ascending or descending order. How you get there doesn't matter much to me, except that it should be relatively simple and obvious. I could convince myself that probably 90% of the uses for a map in practical programming will want to retrieve the data this way from time to time and designing a package that precludes (or makes difficult/expensive) this possibility would be A Bad Thing. I'd suggest that it should be designed to cover the most general case and leave a hash-table implementation as an alternate/separate structure. (Grace.Lists, Grace.Maps, Grace.Hash_Tables, ...?) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "John English" <je@brighton.ac.uk> wrote in message news:3CC6BF2E.51BEC7E1@brighton.ac.uk... > > A common approach is to provide a way to get a list of keys, which > you can then sort as you wish before using it to extract elements, > rather than building all the same old sorting functionality into > yet another data structure. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 14:20 ` John English 2002-04-24 15:05 ` Marin David Condic @ 2002-04-26 5:41 ` Simon Wright 1 sibling, 0 replies; 425+ messages in thread From: Simon Wright @ 2002-04-26 5:41 UTC (permalink / raw) John English <je@brighton.ac.uk> writes: > Marin David Condic wrote: > > > > What do other languages provide with maps? MFC? STL? I'll bet you can get > > items sorted on the key. > > A common approach is to provide a way to get a list of keys, which > you can then sort as you wish before using it to extract elements, > rather than building all the same old sorting functionality into > yet another data structure. This is certainly the BC approach. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 17:50 ` Warren W. Gay VE3WWG 2002-04-23 18:27 ` Marin David Condic @ 2002-04-23 18:59 ` Stephen Leake 2002-04-23 19:13 ` Darren New 1 sibling, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-23 18:59 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes: > I'm not sure about this sort requirement. Many applications only need to > fetch a value based upon a key. Requiring that the map be sorted will > probably impose suboptimal performance if your requirement doesn't require > sorting. If they want to fetch a value based on a key, a sorted structure is the fasted way to do that. If they don't want to pay for the sorting overhead on insert, they will pay for the very slow fetch time. What are the _timing_ requirements in general? fetching a value from a non-sorted structure is O(n). Fetching from a sorted structure is generally O(logn), and can be O(1) for an optimal hash table. Just because the user doesn't need a sorted iteration thru the map contents, that doesn't mean they don't want a sorted structure. > The sort requirment could be made as part of iteration, and > optionally at that. This is true; we should allow for different implementations. However, I seriously doubt anyone would implement a non-sorted map for a serious application. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 18:59 ` Stephen Leake @ 2002-04-23 19:13 ` Darren New 2002-04-23 19:26 ` Stephen Leake ` (3 more replies) 0 siblings, 4 replies; 425+ messages in thread From: Darren New @ 2002-04-23 19:13 UTC (permalink / raw) Stephen Leake wrote: > This is true; we should allow for different implementations. However, > I seriously doubt anyone would implement a non-sorted map for a > serious application. I think there are *tons* of applications that use unsorted maps, i.e., hash tables. Entire file systems have been built on same, for example. If the key is an arbitrary value (e.g., some random token used merely to identify the object, like a social-security-number) then there's little point in sorting the values. Of course, if you ever need it sorted, chances are you want to keep it sorted. But AFAIK, none of the scripting languages (Tcl, Perl, Python) have sorts for their internally-implemented maps. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 19:13 ` Darren New @ 2002-04-23 19:26 ` Stephen Leake 2002-04-23 19:44 ` Darren New [not found] ` <uznzumd1p.fsf@gsfc.nasa.gov <aac468$3hh$1@nh.pace.co.uk> ` (2 subsequent siblings) 3 siblings, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-23 19:26 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > This is true; we should allow for different implementations. However, > > I seriously doubt anyone would implement a non-sorted map for a > > serious application. > > I think there are *tons* of applications that use unsorted maps, i.e., > hash tables. Entire file systems have been built on same, for example. > If the key is an arbitrary value (e.g., some random token used merely to > identify the object, like a social-security-number) then there's little > point in sorting the values. Of course, if you ever need it sorted, > chances are you want to keep it sorted. But AFAIK, none of the scripting > languages (Tcl, Perl, Python) have sorts for their > internally-implemented maps. And they all live with O (n) time? amazing ! :). -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 19:26 ` Stephen Leake @ 2002-04-23 19:44 ` Darren New 2002-04-24 16:49 ` Stephen Leake 0 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-23 19:44 UTC (permalink / raw) Stephen Leake wrote: > > point in sorting the values. Of course, if you ever need it sorted, > > chances are you want to keep it sorted. But AFAIK, none of the scripting > > languages (Tcl, Perl, Python) have sorts for their > > internally-implemented maps. > > And they all live with O (n) time? amazing ! :). No. Hash tables aren't O(n) except in the worst case. In the best case, they're O(1). When you'd doing things like looking up variables, it's pretty easy to pay the sort time if you want to iterate over all variable names in sorted order, compared to getting close to O(1) when referencing a variable instead of O(logN) each time. Think "symbol table". -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 19:44 ` Darren New @ 2002-04-24 16:49 ` Stephen Leake 2002-04-24 17:10 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-24 16:49 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > > point in sorting the values. Of course, if you ever need it sorted, > > > chances are you want to keep it sorted. But AFAIK, none of the scripting > > > languages (Tcl, Perl, Python) have sorts for their > > > internally-implemented maps. > > > > And they all live with O (n) time? amazing ! :). > > No. Hash tables aren't O(n) except in the worst case. In the best case, > they're O(1). But if I just declare a map in Python, there's no way it's guaranteed to be best case. So I think you are saying "yes, they live with the O(n) worst case, and hope for the O(1) best case, and take whatever they actually get". Hmm. Maybe there is a way to tell Python what the hash table size should be, and what hash function to use? Then I can get O(1). I confess to never having used either a Perl or Python map. > When you'd doing things like looking up variables, it's pretty easy > to pay the sort time if you want to iterate over all variable names > in sorted order, compared to getting close to O(1) when referencing > a variable instead of O(logN) each time. Think "symbol table". Well, the question is, is a "typical" map in Perl or Python "close to" O(n), or "close to" O(1)? Anybody have any data? If I use a red-black tree, I _know_ it is O(log n). -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 16:49 ` Stephen Leake @ 2002-04-24 17:10 ` Marin David Condic 2002-04-25 12:30 ` Georg Bauhaus ` (3 more replies) 2002-04-24 17:25 ` Darren New 2002-04-24 19:38 ` David Bolen 2 siblings, 4 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-24 17:10 UTC (permalink / raw) This is just a guess based on years of experience building apps - not any sort of statistical survey. Most of the time that you are likely to use maps in a garden variety program, they will be used to store a relatively small amount of data. A few dozen directory names with a few hundred files under them, might be one example. A few hundred employees indexed by SSN, might be another. *Most* of the time, I'd suspect you're dealing with some number less than 1000. Probably, with today's hardware, you'd not notice the difference if the performance were on the order of O(n!) :-) So the question is: "Is it worth arguing over the relative performance between a few alternate implementations?" My guess is that the best solution is to pick one that will handle the general cases needed for maps reasonably well and that will be easy to implement and move on. I certainly have no objection to providing alternate structures that offer different performance benefits, but the important thing is to get a general solution available that will work well enough for most of the programmer's needs. (I'd see those as being "easy to use" and "works reliably", rather than "must have optimal performance".) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uhem1m47l.fsf@gsfc.nasa.gov... > > But if I just declare a map in Python, there's no way it's guaranteed > to be best case. So I think you are saying "yes, they live with the > O(n) worst case, and hope for the O(1) best case, and take whatever > they actually get". > > Hmm. Maybe there is a way to tell Python what the hash table size > should be, and what hash function to use? Then I can get O(1). I > confess to never having used either a Perl or Python map. > > > When you'd doing things like looking up variables, it's pretty easy > > to pay the sort time if you want to iterate over all variable names > > in sorted order, compared to getting close to O(1) when referencing > > a variable instead of O(logN) each time. Think "symbol table". > > Well, the question is, is a "typical" map in Perl or Python "close to" > O(n), or "close to" O(1)? Anybody have any data? > > If I use a red-black tree, I _know_ it is O(log n). > > -- > -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 17:10 ` Marin David Condic @ 2002-04-25 12:30 ` Georg Bauhaus 2002-04-25 13:35 ` Marin David Condic 2002-04-25 16:44 ` Darren New ` (2 subsequent siblings) 3 siblings, 1 reply; 425+ messages in thread From: Georg Bauhaus @ 2002-04-25 12:30 UTC (permalink / raw) Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote: : My guess is that the best solution is to pick : one that will handle the general cases needed for maps reasonably well and : that will be easy to implement and move on. No I don't think the general case arguement is really helpful here. The following is possible and desirable with the existing libraries (probably not just in my view since it is essentially about ADTs, isn't it): You declare you want a map, pick the right one for your purpose at declaraion or initialisation time but then shut that choice away, hide it from sight. A decision to be made per program part, essentially at (re)declaration, and _not_ anywhere else. A la box: map := some_impl.create(...); : I certainly have no objection to providing alternate structures that offer : different performance benefits, but the important thing is to get a general : solution available that will work well enough for most of the programmer's : needs. Wouldn't you want, in a language like Ada, the programmer to be able to choose an appropriate specific map implementation and use that for the real thing behind a declared map, and _then_ FORGET about it most of the time. No need to think about the general solution, because you will still be writing programs AS IF there is a general solution, namely by using an interface, the Map interface. And if there _is_ a standardised Map interface, implementors, producers, vendors can glue their specific implemention(s) to that interface, and you as a programmer will still be writing essentially portable code, since only the few lines where a specific container that offers the Map interface is chosen. Reading this thread, I start wondering whether the existing libraries have been studied as a rich source of ideas? For example, the most recent addition (afair), Charles, demonstrates Red-Black trees for containers, Simon's BCs are full of information about topics covered in this thread, GNAT.* also adds a wealth of implemention ideas, ... But I start sounding like I don't want to. --georg ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 12:30 ` Georg Bauhaus @ 2002-04-25 13:35 ` Marin David Condic 2002-04-27 8:57 ` Ole-Hjalmar Kristensen 2002-04-29 15:07 ` Hyman Rosen 0 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-25 13:35 UTC (permalink / raw) What I imagine is that a Map package spec can be designed that basically allows for insertion, deletion & update of individual elements and contains some kind of abstraction to walk through the elements of the map and some means of making the data persistent. I imagine that the Version-1.0 implementation will be something that supports reasonable access time for average use. There can be 1024 different implementations behind it that satisfy any particular implementor's desires if some vendor or some user wants to do something totally different for whatever reasons. The Mark 1, Mod 0 Grace implementation just needs to be *an* implementation that works reasonably well. The danger is that this discussion is going to drift off expounding endlessly on the relative merits of hash tables versus b-trees versus who-knows-what. The mission was to come up with a specification that would present the developer with something consistent with the spec for Grace.Lists, yet provided the operations that would be needed & expected for a map. It doesn't need to be perfect. It doesn't need to be optimal for all uses. It doesn't need to be the final word on indexed data structures. It needs to *exist* and be acceptable to a reasonably large majority of Ada users. After that, it can be polished and polished and polished until it shines like the sun. After that, any number of variations on a theme can be composed to satisfy whatever different criteria someone may have. That's the beauty of being able to create child packages or utilize inheritance - we can create those variations easily. Maybe this is an ongoing problem we Ada programmers have - we so much want to find the perfect solutions that we tend to forget some important practical concerns. Lots of competing languages *already* have libraries full of stuff - including Maps. Those competing languages don't present every possible implementation or even an optimal implementation. What they present is something that an implementor will find useful *today* to get their job done. If all Ada can promise is "One day, its going to be really, really great!!!" developers are going to continue to choose C++, Java, etc., where the promise is: "Here's the leverage you need to get an app built fast right now..." Sorry. I'm not intending to criticize anyone in particular. Its one of those "We're all guilty..." kind of situations. My concern is that if this language wants to have a bigger, better, brighter future, it needs to provide things that are bigger, better and brighter than what other languages already offer. It cannot continue to lag behind what developers can get elsewhere and expect to attract new adherents. In that sense, we've got a lot of catching up to do and that will require staying focused on what's important to moving the mission forward. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:aa8ssi$qjr$1@a1-hrz.uni-duisburg.de... > > Wouldn't you want, in a language like Ada, the programmer to be > able to choose an appropriate specific map implementation and > use that for the real thing behind a declared map, and _then_ > FORGET about it most of the time. No need to think about the > general solution, because you will still be writing programs AS IF > there is a general solution, namely by using an interface, > the Map interface. And if there _is_ a standardised Map > interface, implementors, producers, vendors can glue their > specific implemention(s) to that interface, and you as a > programmer will still be writing essentially portable code, > since only the few lines where a specific container that offers > the Map interface is chosen. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 13:35 ` Marin David Condic @ 2002-04-27 8:57 ` Ole-Hjalmar Kristensen 2002-04-29 14:57 ` Marin David Condic 2002-04-29 15:07 ` Hyman Rosen 1 sibling, 1 reply; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-27 8:57 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > What I imagine is that a Map package spec can be designed that basically > allows for insertion, deletion & update of individual elements and contains > some kind of abstraction to walk through the elements of the map and some > means of making the data persistent. I imagine that the Version-1.0 > implementation will be something that supports reasonable access time for > average use. There can be 1024 different implementations behind it that > satisfy any particular implementor's desires if some vendor or some user > wants to do something totally different for whatever reasons. The Mark 1, > Mod 0 Grace implementation just needs to be *an* implementation that works > reasonably well. > > The danger is that this discussion is going to drift off expounding > endlessly on the relative merits of hash tables versus b-trees versus > who-knows-what. The mission was to come up with a specification that would > present the developer with something consistent with the spec for > Grace.Lists, yet provided the operations that would be needed & expected for > a map. It doesn't need to be perfect. It doesn't need to be optimal for all > uses. It doesn't need to be the final word on indexed data structures. It > needs to *exist* and be acceptable to a reasonably large majority of Ada > users. After that, it can be polished and polished and polished until it > shines like the sun. After that, any number of variations on a theme can be > composed to satisfy whatever different criteria someone may have. That's the > beauty of being able to create child packages or utilize inheritance - we > can create those variations easily. > > Maybe this is an ongoing problem we Ada programmers have - we so much want > to find the perfect solutions that we tend to forget some important > practical concerns. Lots of competing languages *already* have libraries > full of stuff - including Maps. Those competing languages don't present > every possible implementation or even an optimal implementation. What they > present is something that an implementor will find useful *today* to get > their job done. If all Ada can promise is "One day, its going to be really, > really great!!!" developers are going to continue to choose C++, Java, etc., > where the promise is: "Here's the leverage you need to get an app built fast > right now..." > <snip> For an interesting discussion about perfect vs. good enough, see the link below or do a search on "worse is better".... http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-27 8:57 ` Ole-Hjalmar Kristensen @ 2002-04-29 14:57 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-29 14:57 UTC (permalink / raw) I liked the article. I'm not sure I agree that the only two alternatives are to a) build a perfect system that takes forever to get there or b) build a lousy system that gets out quickly. I *do* agree that a lousy system that gets out first and still manages to fill a void is going to generally become the dominant thing and not allow the "perfect" system that's still in the lab to get a toe-hold in the marketplace. But why does "Quick" have to equate to "Lousy"? Couldn't it equate to "Small-And-Incomplete-But-A-Solid-Basis-On-Which-To-Build"? My contention would be that it is better to get some useful piece of the "perfect" solution out there early. When we're talking about the Grace components, this would be some version of "Get a couple of useful data structures out there that more-or-less are accepted as the 'conventional answer' and then build from there." (If Grace.Lists and Grace.Maps got accepted and shipped with compilers, we'd have A Good Start. The interfaces are not weak and the design is not poor - just not the answer to all problems, everywhere.) This is a similar situation to the AdaOS discussion going on in another thread. If the AdaOS project had enough software to build a successful bootstrap and kernel that allowed someone to load one or more programs & execute, then it would constitute A Good Start that would likely mushroom from there. If the RTEMS kernel could be used as a kick-off point, maybe that's a good thing. So what if it doesn't have all the security one might want or that its a realtime scheduler (on which a non-realtime scheduler could be built!) - its there and it works. Get a "kit" built that would let someone compile it with Gnat for a PC and build a bootable floppy. Add on to it so it could load/execute some rudimentary programs from a floppy. At that point, you've got a project going that could be enhanced over time. Maybe RTEMS isn't the right answer - it does present a POSIX interface so its Just Another Realtime OS rather than being something unique and Ada-ish. But if it were used to simply provide the RTK (and some device drivers) for a monolithic realtime Ada program (sounds like an apt description of an OS to me!), it would allow building a more "Ada-ish" OS on top of it. Possibly there are other answers that could be made to work even better. But the point is that getting something out there *NOW* is a whole lot better than waiting around forever for a thousand other things to get done so that a "perfect" system can be eventually built. Get the scope of the project down to something that would be A Good Start & there's no reason that this small piece can't be well designed and well implemented. It doesn't have to be a turd to succeed - it could be a diamond-like jewel. Just make it a *SMALL* jewel that a beginning jeweler can afford to buy and put in a setting. Add more gems later. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message news:7vvgadecxc.fsf@vlinux.voxelvision.no... > > For an interesting discussion about perfect vs. good enough, see the > link below or do a search on "worse is better".... > > http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 13:35 ` Marin David Condic 2002-04-27 8:57 ` Ole-Hjalmar Kristensen @ 2002-04-29 15:07 ` Hyman Rosen 2002-04-29 15:10 ` Darren New 1 sibling, 1 reply; 425+ messages in thread From: Hyman Rosen @ 2002-04-29 15:07 UTC (permalink / raw) Marin David Condic wrote: > some means of making the data persistent Why? What does persistence have to do with maps? Besides, doesn't Ada already have serialization for this kind of thing? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-29 15:07 ` Hyman Rosen @ 2002-04-29 15:10 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-29 15:10 UTC (permalink / raw) Hyman Rosen wrote: > > Marin David Condic wrote: > > some means of making the data persistent > > Why? What does persistence have to do with maps? It's orthogonal and highly useful, so it's worth making sure it works. > Besides, doesn't Ada already have serialization > for this kind of thing? Yes, but you have to make it work, yes? It's not automatic. I think the point *I* was making was that if you define the actual format on the stream, then you can switch between implementations of maps by serializing it out and back in again. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 17:10 ` Marin David Condic 2002-04-25 12:30 ` Georg Bauhaus @ 2002-04-25 16:44 ` Darren New 2002-04-25 17:05 ` Marin David Condic 2002-04-25 17:44 ` Stephen Leake [not found] ` <aa8ssi$qjr$1 <3CCD6197.9070905@mail.com> 3 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-25 16:44 UTC (permalink / raw) Marin David Condic wrote: > This is just a guess based on years of experience building apps - not any > sort of statistical survey. Most of the time that you are likely to use maps > in a garden variety program, they will be used to store a relatively small > amount of data. A few dozen directory names with a few hundred files under > them, might be one example. A few hundred employees indexed by SSN, might be > another. *Most* of the time, I'd suspect you're dealing with some number > less than 1000. While I think this is true of in-memory maps, I think it would be most excellent if we also had disk-based maps (b-trees, for example) that had the same package interface. It doesn't have to be there day one, but I think it's worthwhile double-checking the API to make sure there's nothing there that implies all the data is in memory at once. > alternate implementations?" My guess is that the best solution is to pick > one that will handle the general cases needed for maps reasonably well and > that will be easy to implement and move on. Sure. I think that's what was being discussed. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 16:44 ` Darren New @ 2002-04-25 17:05 ` Marin David Condic 2002-04-26 16:31 ` Stephen Leake 2002-04-26 17:16 ` Darren New 0 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-25 17:05 UTC (permalink / raw) In the olden days, disk based maps were called "ISAM Files" :-) 1) As long as we have some kind of stream based mechanism to be able to load/store a map or list to a file, this ought to account for *most* uses of the data structures since it has to get pretty big to start causing problems in today's world of cheap & virtual memory. 2) If you want some version of an ISAM file, that's fine, but it *is* a file so it will likely have needs beyond what an in-memory structure would require. At that point, I'd say you'd want to at least have a high level of similarity between the interfaces, but I wouldn't feel the need to have a slavish compatibility between the two. We should put it in our back pocket for another day and just be sure that whatever spec is built for Maps, that it is sufficiently abstract to hide the particulars of the implementation. That really ought to be enough. 3) Speaking of files, couldn't Ada benefit from having a "Standard" RDBMS? There used to be AdaSage, but I don't think it was a generic DBMS thing. I don't even know if it gets much use these days or if it is being actively maintained. Is there something that could be declared "The Conventional Ada Answer" for an RDBMS? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Darren New" <dnew@san.rr.com> wrote in message news:3CC83282.69C1884F@san.rr.com... > > While I think this is true of in-memory maps, I think it would be most > excellent if we also had disk-based maps (b-trees, for example) that had > the same package interface. It doesn't have to be there day one, but I > think it's worthwhile double-checking the API to make sure there's > nothing there that implies all the data is in memory at once. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 17:05 ` Marin David Condic @ 2002-04-26 16:31 ` Stephen Leake 2002-04-29 15:06 ` Marin David Condic 2002-04-26 17:16 ` Darren New 1 sibling, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-26 16:31 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > 3) Speaking of files, couldn't Ada benefit from having a "Standard" RDBMS? > There used to be AdaSage, but I don't think it was a generic DBMS thing. I > don't even know if it gets much use these days or if it is being actively > maintained. Is there something that could be declared "The Conventional Ada > Answer" for an RDBMS? http://sourceforge.net/projects/gnade/ This is a "standard" interface to databases, both via ODBC, and direct to a few open source dbms. I don't see any need to reimplement a dbms in Ada. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-26 16:31 ` Stephen Leake @ 2002-04-29 15:06 ` Marin David Condic 2002-04-30 17:16 ` Stephen Leake 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-29 15:06 UTC (permalink / raw) Maybe there doesn't need to be a DBMS built in Ada, but it might be nice to present a "conventional" answer for database work from Ada. IOW, if an interface to one or more DBMS's is adopted as the "convention" and it ships with compilers (and maybe an open source DBMS so it all just works right out of the box) and books get written on how to use Ada with its "conventional" interface to a database, all that starts to conspire to present the developer with a really big leverage package. Can C++ interface to a dbms? Sure. Does your average C++ compiler come with a "standard" interface to a DBMS and a working open source DBMS so you can just start programming a database out of the box? No? Boy that sounds like an opportunity to create some product distinction and offer lots of leverage to the developer to me! MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uwuuu1kx8.fsf@gsfc.nasa.gov... > > This is a "standard" interface to databases, both via ODBC, and direct > to a few open source dbms. I don't see any need to reimplement a dbms > in Ada. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-29 15:06 ` Marin David Condic @ 2002-04-30 17:16 ` Stephen Leake 2002-04-30 18:31 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Stephen Leake @ 2002-04-30 17:16 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Maybe there doesn't need to be a DBMS built in Ada, but it might be nice to > present a "conventional" answer for database work from Ada. That's the mission of GNADE. > <snip> > Can C++ interface to a dbms? Sure. Does your average C++ compiler > come with a "standard" interface to a DBMS and a working open source > DBMS so you can just start programming a database out of the box? > No? Then the market must not want one. Database access has been around a _long_ time, and is a _huge_ market! What the market seems to want is Visual Basic-like tools, that make it easy to build GUI interfaces, with data fields bound to databases. Actually, SQL and ODBC are the conventional answers. GNADE provides Ada bindings to ODBC, and SQL as either normal Ada strings, or a preprocessed "embedded" language addon. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-30 17:16 ` Stephen Leake @ 2002-04-30 18:31 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-30 18:31 UTC (permalink / raw) Milton Freidman is walking down the street with his wife. She says "Honey, there's a $20 bill lying on the sidewalk." Milton replies "You must be mistaken dear. If there was a $20 bill on the pavement the market would have picked it up a long time ago..." :-) Yes, database access has been around for a long time. Are you sure there's never been a compiler that shipped with a database at the same time? And met with some market success? I don't know, but I'd suspect there were probably some that had at least fairly primitive databases sold with them. I know if I got one that just came along with the compiler, I'd make use of it - especially if there was no effort to get it working as might be the case if I wanted to do something like, say, interface to Oracle. Maybe if Ada had a "conventional" interface to a database & possibly if compilers included a usable database (maybe not with every feature possible, but useful for something more than trivial projects) that fit that interface, it would be something the market might take notice of. Especially if the pitch was "You can get it to work on a dozen different machines/compilers without changing a line of your application..." Its a big "maybe" but sometimes it pays to float ideas and see what comes up. Perhaps GNADE attempts to address this need and it might do so fairly well. I don't know, not being in the database business for quite some time and never having taken a look at GNADE. (I used to interface Ada to RDB via an SQL precompiler a very long time ago in a galaxy far, far, away.) My biggest objection would be that it is not (at present) part of "Conventional Ada" and it might be tied to a specific compiler at this time. However, if it was proposed as being "The Answer" and accepted as such, it might help add leverage to Ada, making Ada a more attractive solution. A rising Ada tide lifts all boats. If Ada is going to gain market share, it needs to offer *more* leverage to the developer than other languages and a DBMS of some sort sounds like "more" to me. Other ideas? :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:uelgxqf79.fsf@gsfc.nasa.gov... > > Then the market must not want one. Database access has been around a > _long_ time, and is a _huge_ market! > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 17:05 ` Marin David Condic 2002-04-26 16:31 ` Stephen Leake @ 2002-04-26 17:16 ` Darren New 2002-04-26 17:53 ` Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-26 17:16 UTC (permalink / raw) Marin David Condic wrote: > In the olden days, disk based maps were called "ISAM Files" :-) Actually, I think that was IBM nomenclature for an access mode. I've seen "KSAM" as well (Keyed Sequential Access Method) to get around the trademarks. But yes, ISAM was that API to disk-based maps, with b-trees or whatever being the implementation. > 1) As long as we have some kind of stream based mechanism to be able to > load/store a map or list to a file, this ought to account for *most* uses of > the data structures since it has to get pretty big to start causing problems > in today's world of cheap & virtual memory. Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd hate to suck up and blow out a 10-meg stream file for every hit on my CGI site where I want to look up one record out of 100,000. Now, what *would* be cool is if the read-stream routines for the ISAM implementation could understand the write-stream results from the in-memory set. Then moving from your suggestion to a "real" disk-based database is a matter of sucking it in once, then stuffing it into the disk-based map. > 2) If you want some version of an ISAM file, that's fine, but it *is* a file > so it will likely have needs beyond what an in-memory structure would > require. At that point, I'd say you'd want to at least have a high level of > similarity between the interfaces, but I wouldn't feel the need to have a > slavish compatibility between the two. We should put it in our back pocket > for another day and just be sure that whatever spec is built for Maps, that > it is sufficiently abstract to hide the particulars of the implementation. > That really ought to be enough. I think that was my suggestion. Obviously, you'd need stuff like a file name, a utility to perhaps pack the file down to minimum size, etc. But my intent in saying they had the same spec was to imply that in actuall *access* routines, there needn't be arbitrary changes to the API. Open and close, sure. But not iterating thru the records, adding or deleting, etc. > We've got to be *real* careful not to make a naming scheme that tries to > have so many branches to such a depth that everyone will later decide that > it is a Royal Pain In The Posterior to use it. Yah. Welcome to Java, where you need to instantiate half a dozen abstract mail APIs just to send an email message that's a printf in C. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-26 17:16 ` Darren New @ 2002-04-26 17:53 ` Marin David Condic 2002-04-28 0:09 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-26 17:53 UTC (permalink / raw) "Darren New" <dnew@san.rr.com> wrote in message news:3CC98B8E.D49A2CEE@san.rr.com... > > Hrm. Maybe, maybe. Depends on what kind of program you're writing. I'd > hate to suck up and blow out a 10-meg stream file for every hit on my > CGI site where I want to look up one record out of 100,000. > O.K., but that's where I'm saying we're looking at 10% of the usages. If we presume that most of the time, we're talking about maps to hold a few hundred employee's records, or a few dozen directories & files or whatever an average map is likely to be used for. The structure should fit into available memory rather easily & you may only need load/store for persistence between program runs. If you have a few hundred thousand on up of something, then you probably want some kind of file since you don't want to load/store the whole thing - just access/update individual items. For that, you have an alternative file-based map that will have a similar, but not identical, interface. What percentage of the time would you think that an in-memory map might be just fine? My personal guess would be that if I had an in-memory map it would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV) Getting that far would satisfy some reasonably large need and the rest we can worry about as an extra package to be added at a later date. > > I think that was my suggestion. Obviously, you'd need stuff like a file > name, a utility to perhaps pack the file down to minimum size, etc. But > my intent in saying they had the same spec was to imply that in actuall > *access* routines, there needn't be arbitrary changes to the API. Open > and close, sure. But not iterating thru the records, adding or deleting, > etc. > O.K. Sounds like we agree. Package 1 defines the interface needed for an in-memory map with facilities to get them in and out of streams. Package 2 defines the interface for a disk-based map that probably doesn't need streams but would need certain file manipulation capabilities. For the garden variety add/change/delete and scan kinds of stuff, there doesn't need to be any difference in the interface presented. But you can't just unplug the one and substitute the other because of some different requirements. > > Yah. Welcome to Java, where you need to instantiate half a dozen > abstract mail APIs just to send an email message that's a printf in C. > :-) > Sometimes, you can't avoid it, but I'd prefer to keep the names for the things that will get used most commonly short and sweet. Don't make it painful to use basic lists and basic maps. We can always create special flavors that have longer names and if you need the capabilities, you put up with the typing burden. But can you imagine the heat Ada would take if instead of being able to declare an object as an Integer, you had to do some version of Ada.Numerics.Scalars.Whole.Bounded.Integer? :-) Or if you simply wanted to output an integer to the screen you had to do something like "package My_Integer_IO is new Ada.Text_IO.Integer_IO (Num => Integer) ;"? Wait a minute.... Ooopps! :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-26 17:53 ` Marin David Condic @ 2002-04-28 0:09 ` Darren New 0 siblings, 0 replies; 425+ messages in thread From: Darren New @ 2002-04-28 0:09 UTC (permalink / raw) Marin David Condic wrote: > What percentage of the time would you think that an in-memory map might be > just fine? My personal guess would be that if I had an in-memory map it > would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV) > Getting that far would satisfy some reasonably large need and the rest we > can worry about as an extra package to be added at a later date. I agree 100%. I'm just saying that one should check that other than instantiation and destruction, one should be able to do the same things with the new package as you did with the old. I dunno, maybe this goes without saying in Ada, but (for example) making iterators private so you can't easily get locked into knowing they're memory addresses instead of file offsets, things like that. Of course, locking comes into it too, once you get to disk-based stuff, so I think the disk stuff will be a *superset* of the memory-based stuff. Perhaps you could even map an instantiation of a disk-based map using the memory-based instantiator into a temp-file-based map. But yes, this is just idle rambling at this point. I think another good thing would be to define the behavior of the map if it's modified while you're iterating. Or to at a minimum make it clear that the behavior is undefined. But if you're using a sorted map, it shouldn't be hard to define the behavior in a relatively intuitive way. Perhaps all I really need to be saying is that it's likely you want a tagged type for the lists and maps, just so they *can* be extended in the future. > O.K. Sounds like we agree. Package 1 defines the interface needed for an > in-memory map with facilities to get them in and out of streams. Package 2 > defines the interface for a disk-based map that probably doesn't need > streams but would need certain file manipulation capabilities. For the > garden variety add/change/delete and scan kinds of stuff, there doesn't need > to be any difference in the interface presented. But you can't just unplug > the one and substitute the other because of some different requirements. Right. I think that's good. I'd include the streams in version 2, if only for stuffing said maps over network connections, upgrading formats to newer versions, etc. Everything I snipped, I agree with. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 17:10 ` Marin David Condic 2002-04-25 12:30 ` Georg Bauhaus 2002-04-25 16:44 ` Darren New @ 2002-04-25 17:44 ` Stephen Leake [not found] ` <aa8ssi$qjr$1 <3CCD6197.9070905@mail.com> 3 siblings, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-25 17:44 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > I certainly have no objection to providing alternate structures that offer > different performance benefits, but the important thing is to get a general > solution available that will work well enough for most of the programmer's > needs. (I'd see those as being "easy to use" and "works reliably", rather > than "must have optimal performance".) I agree. And making the Grace maps "the same as Python" or "the same as Perl" would be good too. Let's reuse the design experience those environments have. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <aa8ssi$qjr$1 <3CCD6197.9070905@mail.com>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <aa8ssi$qjr$1 <3CCD6197.9070905@mail.com> @ 2002-04-30 4:49 ` Simon Wright 2002-04-30 14:05 ` Ted Dennison 0 siblings, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-30 4:49 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Marin David Condic wrote: > > some means of making the data persistent > > Why? What does persistence have to do with maps? > Besides, doesn't Ada already have serialization > for this kind of thing? Serialization (support of Ada.Streams) is only supported out of the box for some types; not sure of the full details, but things referenced by pointers are not included. So any unbounded container will need some work. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-30 4:49 ` Simon Wright @ 2002-04-30 14:05 ` Ted Dennison 2002-04-30 14:32 ` Marin David Condic 2002-05-01 22:17 ` Simon Wright 0 siblings, 2 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-30 14:05 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote in message news:<x7vsn5d23l0.fsf@smaug.pushface.org>... > Hyman Rosen <hyrosen@mail.com> writes: > > > Besides, doesn't Ada already have serialization > > for this kind of thing? > > Serialization (support of Ada.Streams) is only supported out of the > box for some types; not sure of the full details, but things > referenced by pointers are not included. So any unbounded container > will need some work. Its supported out of the box for all types, but for some (eg: pointers) it doesn't work so well. (Actually, it works just fine for pointers too, as long as the program continues to run. :-) ). Yes, a container will need some work to make it do the "right thing" for a stream read or write. I don't see any reason why that work should not be done. I believe that what we had the Lists package do. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-30 14:05 ` Ted Dennison @ 2002-04-30 14:32 ` Marin David Condic 2002-05-02 15:52 ` Ted Dennison 2002-05-01 22:17 ` Simon Wright 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-30 14:32 UTC (permalink / raw) The spec for the Lists certainly defines some stream operations that provides for a solution to persistence as well as communication. Maps ought to do the same. Personally, I think it would be handy to have a couple of subprograms to explicitly load & store the structure from/to a stream file, for the sake of simplicity. Some version of: "Here, I figured out a file for you and went and opened it already - you go put/get your data to/from it and I don't want to know how you did it..." But maybe that's just me... :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Ted Dennison" <dennison@telepath.com> wrote in message news:4519e058.0204300605.13180548@posting.google.com... > > Yes, a container will need some work to make it do the "right thing" > for a stream read or write. I don't see any reason why that work > should not be done. I believe that what we had the Lists package do. > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-30 14:32 ` Marin David Condic @ 2002-05-02 15:52 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-05-02 15:52 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<aam9tu$9ja$1@nh.pace.co.uk>... > The spec for the Lists certainly defines some stream operations that > provides for a solution to persistence as well as communication. Maps ought > to do the same. Personally, I think it would be handy to have a couple of That would be my input as well. > subprograms to explicitly load & store the structure from/to a stream file, > for the sake of simplicity. Some version of: "Here, I figured out a file for > you and went and opened it already - you go put/get your data to/from it and > I don't want to know how you did it..." But maybe that's just me... :-) Given that Ada.Streams.Stream_IO exists, you pretty much already have that. If you opened the file using Ada.Streams.Stream_IO.Open (or .Create), the rest is a one-liner. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-30 14:05 ` Ted Dennison 2002-04-30 14:32 ` Marin David Condic @ 2002-05-01 22:17 ` Simon Wright 1 sibling, 0 replies; 425+ messages in thread From: Simon Wright @ 2002-05-01 22:17 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Simon Wright <simon@pushface.org> wrote in message news:<x7vsn5d23l0.fsf@smaug.pushface.org>... > > Serialization (support of Ada.Streams) is only supported out of the > > box for some types; not sure of the full details, but things > > referenced by pointers are not included. So any unbounded container > > will need some work. > > Its supported out of the box for all types, but for some (eg: > pointers) it doesn't work so well. (Actually, it works just fine for > pointers too, as long as the program continues to run. :-) ). Unless you send the serialized pointer into a different address context .. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 16:49 ` Stephen Leake 2002-04-24 17:10 ` Marin David Condic @ 2002-04-24 17:25 ` Darren New 2002-04-24 19:36 ` Ole-Hjalmar Kristensen 2002-04-24 19:38 ` David Bolen 2 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-24 17:25 UTC (permalink / raw) Stephen Leake wrote: > > Darren New <dnew@san.rr.com> writes: > > > Stephen Leake wrote: > > > > point in sorting the values. Of course, if you ever need it sorted, > > > > chances are you want to keep it sorted. But AFAIK, none of the scripting > > > > languages (Tcl, Perl, Python) have sorts for their > > > > internally-implemented maps. > > > > > > And they all live with O (n) time? amazing ! :). > > > > No. Hash tables aren't O(n) except in the worst case. In the best case, > > they're O(1). > > But if I just declare a map in Python, there's no way it's guaranteed > to be best case. So I think you are saying "yes, they live with the > O(n) worst case, and hope for the O(1) best case, and take whatever > they actually get". Well, if you want to look at it like this, yes. But it's O(N) with a really tiny constant multiplier. I'd also expect that the hash tables get grown as the chains get long. > > When you'd doing things like looking up variables, it's pretty easy > > to pay the sort time if you want to iterate over all variable names > > in sorted order, compared to getting close to O(1) when referencing > > a variable instead of O(logN) each time. Think "symbol table". > > Well, the question is, is a "typical" map in Perl or Python "close to" > O(n), or "close to" O(1)? Anybody have any data? Well, honestly, a hash table of any fixed size is technically O(N), but divided by the number of buckets in the hash table. If the number of buckets is sufficiently larger than the number of entries, you have O(1) for practical purposes. Nobody really stores unlimited numbers of items in a hash. As far as the rehashing goes, you have to touch each item whenever you rearrange the buckets, to put each in the right bucket, so that's probably at least O(N) also. So yes, my guess is that hashes are O(N) with a really, really small multiplier, small enough to make O(lg N) operations not worthwhile. > If I use a red-black tree, I _know_ it is O(log n). O(N)/1000 < O(log N) for sufficiently small N. I think that's the trick. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 17:25 ` Darren New @ 2002-04-24 19:36 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 425+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-04-24 19:36 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > > > Darren New <dnew@san.rr.com> writes: > > <snip> > > So yes, my guess is that hashes are O(N) with a really, really small > multiplier, small enough to make O(lg N) operations not worthwhile. > > > If I use a red-black tree, I _know_ it is O(log n). > > O(N)/1000 < O(log N) for sufficiently small N. I think that's the trick. > Yes. For time-critical operations I routinely size my hash link table to be twice as big as the expected max number of entries... > -- > Darren New > San Diego, CA, USA (PST). Cryptokeys on demand. > The 90/10 rule of toothpaste: the last 10% of > the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 16:49 ` Stephen Leake 2002-04-24 17:10 ` Marin David Condic 2002-04-24 17:25 ` Darren New @ 2002-04-24 19:38 ` David Bolen 2002-04-24 21:57 ` Stephen Leake 2 siblings, 1 reply; 425+ messages in thread From: David Bolen @ 2002-04-24 19:38 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: > But if I just declare a map in Python, there's no way it's guaranteed > to be best case. So I think you are saying "yes, they live with the > O(n) worst case, and hope for the O(1) best case, and take whatever > they actually get". Yes. But it's also that a good deal of implementation effort has gone into making the odds of the O(1) case much better than that of the O(n) case. > Hmm. Maybe there is a way to tell Python what the hash table size > should be, and what hash function to use? Then I can get O(1). I > confess to never having used either a Perl or Python map. Python automatically maintains (grows) the hash table so that it is no more than 2/3 full. It is limited to a 32-bit key, and is open-addressed, not chained. Any "hashable" object in Python may be used as a dictionary key - objects may implement their own hashing function if they prefer. The default hashing function for user created objects is to hash to the object's location in memory. The built-in types tend to have type-specific tuned hashing functions. The source indicates the algorithm was originally based on Algorithm D from Knuth Vol. 3, Sec. 6.4. > Well, the question is, is a "typical" map in Perl or Python "close to" > O(n), or "close to" O(1)? Anybody have any data? In Python it's expected to be average O(1), and only extremely rarely O(n) (e.g., if everything hashes to the same value). But formally the operations are still O(n) - a lot of tuning over the course of Python's evolution just makes the typical case much closer to best than worst. In particular, Python's hash table does not depend on the randomness of the hashing function, and in fact works very well for very regular (even monotonically increasing) hash functions. There are some newsgroup posts over the years (look for stuff by Tim Peters in particular), but I don't know of a formal algorithm analysis online anywhere. The dictionary object source itself has quite a bit of information: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/dictobject.c?rev=HEAD (Hoping this isn't too off-topic for an Ada group) -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-24 19:38 ` David Bolen @ 2002-04-24 21:57 ` Stephen Leake 0 siblings, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-24 21:57 UTC (permalink / raw) David Bolen <db3l@fitlinxx.com> writes: Ok, thanks. That answers my questions. Python maps (hash tables) should in general be close to O (1). -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <uznzumd1p.fsf@gsfc.nasa.gov <aac468$3hh$1@nh.pace.co.uk>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <uznzumd1p.fsf@gsfc.nasa.gov <aac468$3hh$1@nh.pace.co.uk> @ 2002-04-27 5:29 ` Simon Wright 2002-04-29 15:16 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-27 5:29 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > O.K. Sounds like we agree. Package 1 defines the interface needed > for an in-memory map with facilities to get them in and out of > streams. Package 2 defines the interface for a disk-based map that > probably doesn't need streams but would need certain file > manipulation capabilities. For the garden variety add/change/delete > and scan kinds of stuff, there doesn't need to be any difference in > the interface presented. But you can't just unplug the one and > substitute the other because of some different requirements. The BCs already do 'Input and 'Output for Maps (and indeed many other container kinds; provided you use GNAT 3.14 or later!). The problem it seems to me with disk-based containers is that you need to think very hard about whether they're limited or not; what does assignment mean for disk-based maps? overwrite, I suppose? Creation is interesting, too. If you say M : Disk_Based_Map; how do you make sure it's associated with a file? ... well, I guess that's easy: procedure Associate (M : in out Disk_Based_Map; With_File_Named : String); and raise an exception (No_Associated_File) if the punter tries to use it before association. I certainly would expect a Disk_Based_Map to be in Abstract_Map'Class (perhaps just because that's the way the BCs do it). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-27 5:29 ` Simon Wright @ 2002-04-29 15:16 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-29 15:16 UTC (permalink / raw) That's sort of where I was going - a disk based map is going to have issues of its own that will likely mean it can't have an interface that is identical to a memory based map. Hence, the Grace components should just concentrate on getting the memory based map interface right and possibly it can later be used with adaptations for a disk based map. Also, I have never had any objection to the BC's being adopted as the "conventional answer" with the exception that it needed some stuff to provide a "simple" answer for the uninitiate or the student. I'd still think it might be a good idea to take something like the Grace components and graft them onto the BC's in some manner that basically said: "If you need a simple list or map, for some basic data, go with these components. If you want to do really sophisticated stuff, then go with these alternate components." But then this has been hashed over before and nobody seems to be willing to settle on one existing library unless its their personal favorite. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Simon Wright" <simon@pushface.org> wrote in message news:x7vg01hzp2x.fsf@smaug.pushface.org... > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > > The BCs already do 'Input and 'Output for Maps (and indeed many other > container kinds; provided you use GNAT 3.14 or later!). The problem > it seems to me with disk-based containers is that you need to think > very hard about whether they're limited or not; what does assignment > mean for disk-based maps? overwrite, I suppose? > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-23 19:13 ` Darren New 2002-04-23 19:26 ` Stephen Leake [not found] ` <uznzumd1p.fsf@gsfc.nasa.gov <aac468$3hh$1@nh.pace.co.uk> @ 2002-04-27 14:37 ` Larry Kilgallen [not found] ` <uznzumd1p.fsf@gsfc.nasa.govOrganization: LJK Software <tW4Tz4KHL8Bt@eisner.encompasserve.org> 3 siblings, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-27 14:37 UTC (permalink / raw) In article <aac468$3hh$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > What percentage of the time would you think that an in-memory map might be > just fine? My personal guess would be that if I had an in-memory map it > would satisfy maybe 80% to 90% of the instances where I'd need a map. (YMMV) > Getting that far would satisfy some reasonably large need and the rest we > can worry about as an extra package to be added at a later date. Just as I can change: Result := By_Location ( US, Massachusetts, Cambridge ); from an array access to a function call at will, access to sparse data (which is my understanding of what you folks mean by "maps") should be the same from the client programmer view regardless of whether the data is in memory or on disk. ^ permalink raw reply [flat|nested] 425+ messages in thread
[parent not found: <uznzumd1p.fsf@gsfc.nasa.govOrganization: LJK Software <tW4Tz4KHL8Bt@eisner.encompasserve.org>]
* Re: Grace and Maps (was Re: Development process in the Ada community) [not found] ` <uznzumd1p.fsf@gsfc.nasa.govOrganization: LJK Software <tW4Tz4KHL8Bt@eisner.encompasserve.org> @ 2002-04-29 15:26 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-29 15:26 UTC (permalink / raw) I can't speak for what everyone else means by a map - I mean something where I store and look up data based on a key. An ISAM file being a typical example. I want to say "Put (Some_Social_Security_Number, Some_Student_Record) ;" and "Get (This_SSN, The_Student_Record);" If that constitutes "sparse data" then I guess that's fine. If you had "Get" and "Put" and iterators and similar operations, those could be common without respect to the actual implementation or storage mechanism. But I think if the intention was to support some disk file with possibly millions of records in it, then you would likely need a bunch of operations that would make little to no sense for an in-memory, dynamically allocated, linked structure. Hence, I'd opt to be as similar as possible, but not make that a slavish goal. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:tW4Tz4KHL8Bt@eisner.encompasserve.org... > > access to sparse data (which is my understanding of what you folks > mean by "maps") should be the same from the client programmer view > regardless of whether the data is in memory or on disk. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 19:49 ` Ted Dennison 2002-04-21 1:33 ` Ted Dennison @ 2002-04-21 5:46 ` Simon Wright 2002-04-21 18:44 ` Ted Dennison 2002-04-22 14:31 ` Marin David Condic 2 siblings, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-21 5:46 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Another possiblity would be to keep the name simple (Grace.Lists), > and give the bounded version its own name when/if the time > comes. Something like "Circular_Lists" (or Booch's "Ring") might be > a possibility. This concept extends to Maps too, as we could call > them "Maps" and "Hashes" rather than "Maps.Unbounded" and > "Maps.Bounded". Not only is this a simpler structure, we no longer > have the name talking about internal features of the structure > instead of external features. That could be good enough for > real-time and embedded folks if we document its use (or lack of use) > of heap properly. That seems plain peculiar to me. The BC "Collection" and "Ring" have quite different semantics because they support different concepts. Collection.Bounded and Collection.Unbounded are different because they have different runtime behaviour, but they both have the same interface! In this respect they map onto Ada.Strings, I think. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-21 5:46 ` Simon Wright @ 2002-04-21 18:44 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-21 18:44 UTC (permalink / raw) Simon Wright wrote: > Ted Dennison <dennison@telepath.com> writes: > > >>Another possiblity would be to keep the name simple (Grace.Lists), >>and give the bounded version its own name when/if the time >>comes. Something like "Circular_Lists" (or Booch's "Ring") might be > > That seems plain peculiar to me. The BC "Collection" and "Ring" have > quite different semantics because they support different > concepts. Collection.Bounded and Collection.Unbounded are different > because they have different runtime behaviour, but they both have the > same interface! In this respect they map onto Ada.Strings, I think. My thought was that it would be sensible to give the "bounded" structure an interface (and name) commensurate with its unique capabilities and weak spots, rather than just try to provide identical interfaces with the "unbounded" one. Sort of a "function follows form" concept. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 19:49 ` Ted Dennison 2002-04-21 1:33 ` Ted Dennison 2002-04-21 5:46 ` Simon Wright @ 2002-04-22 14:31 ` Marin David Condic 2 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-22 14:31 UTC (permalink / raw) "Ted Dennison" <dennison@telepath.com> wrote in message news:3CC1C6B3.6060306@telepath.com... > > I honestly have no clue. The vast majority of my Ada use has been > real-time or embedded (where dynamic allocation is often unavailable), > and I do notice that there seem to be a large number of Ada compilers > for such platforms. But I also realise that's just the view from my > window, not a scientific representative sample. > To be fair, I have to admit similar ignorance. All I can go on is a general perception that most programs written are not realtime/embedded so extrapolate from there and presume that most Ada programs are not realtime/embedded. You've got to ask "who's the audience?" and starting from an unproven assumption and using a weak extrapolation, I'm willing to leap to the forgone conclusion that we ought to target PC/Workstation non-realtime apps as the first concern. Extensions can always follow. > > Another possiblity would be to keep the name simple (Grace.Lists), and > give the bounded version its own name when/if the time comes. Something > like "Circular_Lists" (or Booch's "Ring") might be a possibility. This > concept extends to Maps too, as we could call them "Maps" and "Hashes" > rather than "Maps.Unbounded" and "Maps.Bounded". Not only is this a > simpler structure, we no longer have the name talking about internal > features of the structure instead of external features. That could be > good enough for real-time and embedded folks if we document its use (or > lack of use) of heap properly. > No reason I can think of not to use new names if we change the underlying implementation to create a new kind of structure. I could see doing something like "Grace.Lists" and "Grace.Static_Lists" or any variant that some dedicated word-scientist would care to come up with. Avoiding saying anything about the underlying implementation is desirable, but I wouldn't insist if the alternative is to go through linguistic gyrations to get there. OTOH, this is all kind of "new" and someone has to invent names for new things. So why couldn't we just rectally extract names for new components that don't necesarily have anything to do with anything? Grace.Lists - a dynamically linked list. Grace.Gazorenthorpes - a statically allocated list with a maximum upper bound. Grace.Blivets - Like a Gazorenthorpe only with task safety built in. Grace.Doohickies - Like a map, but static. We can probably do this all day long - maybe even get a CS book written about it and be immortalized in the annals of Geekdom forever. :-) > But the argument for consistency with Ada.Strings.* is fairly compelling > too. > I feel your compellation! :-) I'd like to be consistent with what has gone before as well. But maybe its time to break with the past? Didn't Mark Twain say "A foolish consistency is the product of little minds..." ? This is a tough call, but I think I'd prefer to go with coming up with a separate name for a list or map that had a significantly different behavior. > > > I'm curious if other people feel this way. I'd lean towards > "Grace.Lists", as the standard Ada library is equally flat, our list of > components may not end up being large, and there isn't liable to be much > common code sitting in the "Components" spec. But I'm not married to the > idea. We certianly need to name for proper growth, as renaming files in > CVS is kind of a kludge. > Well, maybe there is no reason we can't mix-n-match. If we don't see some general category of "Containers" being likely - just Lists & Maps (and variant implementations thereof) then maybe it doesn't need another layer. I could envision at a later point doing something like "Grace.XML", "Grace.XML.DOM", "Grace.XML.SAX" and so on if we did want to add something that had logical sub-domains and/or deeper hierarchy. My brain seems to like having a phylogenetic tree around for some reason. Something like: <Library>.<Problem Domain>.<Specific Tool> would seem to be sufficient to keep my brain happily amused and tranquil in the beautiful serenity that can only come from a sublime sense of order. How does the rest of the world feel? Of course, if we got rid of the "Grace" part and just went with a bunch of separate libraries under the <Problem Domain>.<Specific Tool> kind of thing, we'd have categorization without so deep a tree. But then we lose any sense of a unified library. No really perfect answers out there, are there? > > Yeah, that would be a good start. Right now in addtion to this I'm > trying to figure out if I need to buy 3 smaller child car seats or a > larger car. :-( > I hear minivans are nice. (Wasn't there a parody of the "Spiderman" theme song called "Married Man" that alluded to minivans? Here we go: http://www.thebigshow.com/BITPAGES/MARRDMAN.HTM) I should watch it - my lovely bride could easily take umbrage and seek revenge by coming home with a fake-wood pannel station wagon. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-19 14:23 ` Marin David Condic ` (2 preceding siblings ...) 2002-04-20 19:49 ` Ted Dennison @ 2002-04-25 2:29 ` Brian Gaffney 2002-04-25 14:06 ` Marin David Condic 3 siblings, 1 reply; 425+ messages in thread From: Brian Gaffney @ 2002-04-25 2:29 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9p98h$8hn$1@nh.pace.co.uk>... > "Ted Dennison" <dennison@telepath.com> wrote in message > news:4519e058.0204190529.559a47ae@posting.google.com... > > > > I've actually been thinking along similar lines. What I'm wondering is > > if we should keep the list package as "Lists.Unbounded", or if we > > should just bag the whole bounded/unbounded issue and make it "Lists". > > > > . . . > > If we put out a Grace.Lists and a Grace.Maps, that would certainly be a > really good start. If at a later point in time there was some kind of > groundswell indicating that there really was a need for bounded versions, > why couldn't we go with Grace.Lists.Bounded as an extension? The only reason > I can think of is that it isn't consistent with Ada.Strings. If I get your intent, I don't think this would work since Grace.List would be generic. (Which would be a pain if you needed Bounded because you didn't wish to instantiate an Unbounded.) . . . > My inclination would be to make Grace.Lists and Grace.Maps and add children > at a later date if we thought we needed special cases. I'd again make an > appeal for some version of "Grace.Containers.Lists" and > "Grace.Containers.Maps" (or some variant thereof) so that there might also > be easy extensions like: "Grace.Linear_A", "Grace.Statistics", "Grace.XML", > "Grace.Whatever_Else_Seems_Like_A_Good_Idea"... The names aren't real > important to me but thinking along the line of problem domains & dividing > things up under a subheading is something I think would be beneficial in the > long run. I like the Grace.Containers.Lists idea. Perhaps the children could be something like Grace.Containers.Bounded.Lists? Then you could have a Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc. I don't know how well this would extend to other types of containers. Another way to get a default (assuming anyone could stand it) would be to provide the different version (unbounded, bounded, etc.) and uses a renames to define the 'default' type (i.e. generic package Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists). ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-25 2:29 ` Brian Gaffney @ 2002-04-25 14:06 ` Marin David Condic 0 siblings, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-25 14:06 UTC (permalink / raw) "Brian Gaffney" <Brian.Gaffney@myrealbox.com> wrote in message news:5e9b8c34.0204241829.67633bdf@posting.google.com... > > If I get your intent, I don't think this would work since Grace.List > would be generic. (Which would be a pain if you needed Bounded > because you didn't wish to instantiate an Unbounded.) > O.K. So maybe we just need Grace.Lists and Grace.Bounded_Lists? Probably, 90% of the uses will just want a dynamically allocated, linked list implementation as being Good Enough(tm). Hence, it can benefit from the shorter name. Lesser demand packages can have longer names either by dotted-child notation or just more detailed names. Or we could just invent new names to describe data structures with different characteristics as I suggested somewhat less seriously elsewhere. You could have Grace.Lists, Grace.BLists, Grace.Whatever.... So long as it is documented what the characteristics of a BList are, we don't have a problem. Or completely make up new names that don't play to anyone's preconceived notions of what they are.Grace.Rosters? Grace.Rolls? Grace.Catalogs? There you've got three more names to describe lists with different caracteristics. > > I like the Grace.Containers.Lists idea. Perhaps the children could be > something like Grace.Containers.Bounded.Lists? Then you could have a > Grace.Containers.Maps and Grace.Containers.Bounded.Maps, etc. I don't > know how well this would extend to other types of containers. > We've got to be *real* careful not to make a naming scheme that tries to have so many branches to such a depth that everyone will later decide that it is a Royal Pain In The Posterior to use it. If we start creating subtrees to describe implementation strategies and characteristics, where does it end? Grace.Containers.Bounded.Task_Safe.Realtime.Deterministic.Maps? :-) We can't solve *all* the problems today. A Grace.Containers.Lists and Grace.Containers.Maps is probably sufficient granularity for now and a sub-branch could be created later if there is any real need. (Some flavor of Grace.Bounded_Containers? Although I'd favor shorter names for these things. Like Grace.Boxes or Grace.Jars - or even an acronym.) > Another way to get a default (assuming anyone could stand it) would be > to provide the different version (unbounded, bounded, etc.) and uses a > renames to define the 'default' type (i.e. generic package > Grace.Containers.Lists renames Grace.Containers.Unbounded.Lists). Apply the K.I.S.S. principle here. One of the design criteria was that it be relatively easy to explain to students - and that was one of the reasons people had objections to the Booch Components. Too many layers and too much complexity for the average beginner to make good use of it. Providing a default renaming of some alternate implementations might not be a bad way to go, but I'm wondering if it would create too much confusion? Would it be easy to explain to a beginner? I think that so long as the tree structure is extensible without too much pain, it will be satisfactory. One day, we might want a bunch of packages with the power of the Booch Components & I could see building it under a heading Grace.Rich_Containers (or whatever) but we need to continue to have something reasonably simple and straightforward to handle a large percentage of the needs without too much pain. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic 2002-04-19 13:29 ` Ted Dennison @ 2002-04-20 0:42 ` David Bolen 2002-04-22 2:57 ` Robert Dewar 1 sibling, 1 reply; 425+ messages in thread From: David Bolen @ 2002-04-20 0:42 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > When the whole discussion of what eventually began to emerge as Grace got > started, there seemed to be a consensus that if you had lists and maps, most > of the other sorts of containers just wouldn't be that big a deal. Lists and > Maps just cover the bulk of what you need to do in most practical > programming situations. I wouldn't be surprised that C++ programmers have > had similar experience. (...) And from another language perspective, in Python, the fundamental built-in data structure types (aside from numerics) are sequences (lists/tuples) and mappings (dictionaries) and certainly in my experience they cover the vast majority of practical situations quite capably. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-20 0:42 ` David Bolen @ 2002-04-22 2:57 ` Robert Dewar 2002-04-22 22:58 ` David Bolen 0 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-22 2:57 UTC (permalink / raw) David Bolen <db3l@fitlinxx.com> wrote in message news:<ur8lbkxo1.fsf@ctwd0143.fitlinxx.com>... > And from another language perspective, in Python, the fundamental > built-in data structure types (aside from numerics) are sequences > (lists/tuples) and mappings (dictionaries) and certainly in my > experience they cover the vast majority of practical situations quite > capably. Yes, and of course this is an old old idea, copied into Python from the heritage of ABC, SETL and other precursors. Mappings are of course powerful enough to represent anything (and sequences are just special cases of mappings). That's been known since long before computers existed! But whether general mappings have a legitimate place in a low level language (by SETL standards :-) like Ada is open for debate. And in particular, having them as second class citizens without decent syntax seems quite dubious. So you might want to throw into the pot user defined subscripting and slicing operations :-) My own view is that it is unlikely that any of this will get anywhere near smooth enough and with enough consensus to be standardized. I think people would better spend their effort implementing sample packages than discussing at random on CLA :-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Grace and Maps (was Re: Development process in the Ada community) 2002-04-22 2:57 ` Robert Dewar @ 2002-04-22 22:58 ` David Bolen 0 siblings, 0 replies; 425+ messages in thread From: David Bolen @ 2002-04-22 22:58 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > David Bolen <db3l@fitlinxx.com> wrote in message news:<ur8lbkxo1.fsf@ctwd0143.fitlinxx.com>... > > > And from another language perspective, in Python, the fundamental > > built-in data structure types (aside from numerics) are sequences > > (lists/tuples) and mappings (dictionaries) and certainly in my > > experience they cover the vast majority of practical situations quite > > capably. > > Yes, and of course this is an old old idea, copied into Python from the > heritage of ABC, SETL and other precursors. Mappings are of course > powerful enough to represent anything (and sequences are just special > cases of mappings). That's been known since long before computers existed! Sorry, didn't mean that to come across as Python inventing the ideas, only to point out that they prove eminently useful in practice and without requiring the large number of variations as you might find in the STL. > But whether general mappings have a legitimate place in a low level > language (by SETL standards :-) like Ada is open for debate. And in > particular, having them as second class citizens without decent syntax > seems quite dubious. That's actually an interesting point. Certainly to my mind part of what makes lists/dictionaries more convenient (in Python) is the native syntax support for manipulating them. But barring an easy way to do that, at least having them available as clean libraries consistently available would, I think, go a long way. > So you might want to throw into the pot user defined subscripting > and slicing operations :-) Just have to figure out how to open up Ada's syntax first without a 10 year ISO effort :-) > My own view is that it is unlikely that any of this will get anywhere > near smooth enough and with enough consensus to be standardized. I think > people would better spend their effort implementing sample packages than > discussing at random on CLA :-) Ah, but brainstorming is cheap and simple for everyone to have an opinion :-) Sounds like there might be some coding in the works though from elsewhere in the thread. -- -- David -- /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ ^ permalink raw reply [flat|nested] 425+ messages in thread
* [OT] Focusing on tools you know in programming libraries. (was): Development process in the Ada community 2002-04-18 17:32 ` Hyman Rosen 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic @ 2002-04-18 18:50 ` Kent Paul Dolan 2002-04-18 18:57 ` Data!, was " tmoran ` (2 subsequent siblings) 4 siblings, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 18:50 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote: > I was just reading somewhere (exactly where escapes me) of a recent > survey done on C++ programmers who have started using the STL. There > was some surprise to discover that the most used container was map. > Apparently what happens is that once programmers have map available, > they begin using it all over the place, replacing little local ad-hoc > lookup structures such as linear searches through arrays. That corresponds to my recent experience when someone introduced me a few days ago (by mentioning it in a posting) to Java's TreeSet, which is probably similar in part to Map, from your description. It turned a big nasty programming chore (implementing a Tabu Search from scratch) I'd been avoiding, into something I was able to toss off in five hours. Like the STL, the Java API is rather overwhelming, so I'll probably use TreeSet a lot where other classes unknown to me might really be a better fit, like the STL newbies seem to focus on Map. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Data!, was Re: Development process in the Ada community 2002-04-18 17:32 ` Hyman Rosen 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic 2002-04-18 18:50 ` [OT] Focusing on tools you know in programming libraries. (was): Development process in the Ada community Kent Paul Dolan @ 2002-04-18 18:57 ` tmoran 2002-04-18 20:51 ` Ted Dennison 2002-04-19 11:00 ` John English 4 siblings, 0 replies; 425+ messages in thread From: tmoran @ 2002-04-18 18:57 UTC (permalink / raw) > I was just reading somewhere (exactly where escapes me) of a recent > survey done on C++ programmers who have started using the STL. There > was some surprise to discover ... If you can possibly remember where that was, please post it. Actual information on what makes programmers more productive is extremely rare. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 17:32 ` Hyman Rosen ` (2 preceding siblings ...) 2002-04-18 18:57 ` Data!, was " tmoran @ 2002-04-18 20:51 ` Ted Dennison 2002-04-18 21:28 ` Gary Scott ` (2 more replies) 2002-04-19 11:00 ` John English 4 siblings, 3 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-18 20:51 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBF0341.8020406@mail.com>... > Ted Dennison wrote: > > Since we mostly have a package worked out (at great pains) for lists, > > hopefully they will concentrate on defining what other containers are > > needed and how best to extend what we have. > > I was just reading somewhere (exactly where escapes me) of a recent > survey done on C++ programmers who have started using the STL. There > was some surprise to discover that the most used container was map. > Apparently what happens is that once programmers have map available, > they begin using it all over the place, replacing little local ad-hoc > lookup structures such as linear searches through arrays. Maps would certianly be my prime candidate. My last project incorporated the Booch Components just for the map support. It also seemed to be the most talked about other component during the strawman list discussions (although admittedly I was doing a lot of that talking). -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 20:51 ` Ted Dennison @ 2002-04-18 21:28 ` Gary Scott 2002-04-18 22:10 ` Pascal Obry 2002-04-18 22:28 ` Jeffrey Carter 2002-04-20 5:12 ` Simon Wright 2 siblings, 1 reply; 425+ messages in thread From: Gary Scott @ 2002-04-18 21:28 UTC (permalink / raw) Ted Dennison wrote: > > Hyman Rosen <hyrosen@mail.com> wrote in message news:<3CBF0341.8020406@mail.com>... > > Ted Dennison wrote: > > > Since we mostly have a package worked out (at great pains) for lists, > > > hopefully they will concentrate on defining what other containers are > > > needed and how best to extend what we have. > > > > I was just reading somewhere (exactly where escapes me) of a recent > > survey done on C++ programmers who have started using the STL. There > > was some surprise to discover that the most used container was map. > > Apparently what happens is that once programmers have map available, > > they begin using it all over the place, replacing little local ad-hoc > > lookup structures such as linear searches through arrays. > > Maps would certianly be my prime candidate. My last project > incorporated the Booch Components just for the map support. It also > seemed to be the most talked about other component during the strawman > list discussions (although admittedly I was doing a lot of that > talking). Could someone please define a MAP. The only one I'm familiar with is the Fortran STRUCTURE/UNION/MAP storage association. > > -- > T.E.D. > Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) > Homepage - http://www.telepath.com/dennison/Ted/TED.html -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 21:28 ` Gary Scott @ 2002-04-18 22:10 ` Pascal Obry 2002-04-18 23:08 ` Darren New 0 siblings, 1 reply; 425+ messages in thread From: Pascal Obry @ 2002-04-18 22:10 UTC (permalink / raw) Gary Scott <scottg@flash.net> writes: > Could someone please define a MAP. I think we are talking about associative arrays here. 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] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 22:10 ` Pascal Obry @ 2002-04-18 23:08 ` Darren New 2002-04-19 13:29 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Darren New @ 2002-04-18 23:08 UTC (permalink / raw) > > Could someone please define a MAP. > I think we are talking about associative arrays here. A MAP is a function that, given a key, returns a value. An implementation in an imperitive language obviously has the ability to change the function, adding keys and values, deleting keys, etc. I believe the STL version allows you to iterate thru in order of sorted keys. In other words, a "map" is the API to a hash table or a search tree or etc. You can implement them with trees, hash tables, linear lists, whatever. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The 90/10 rule of toothpaste: the last 10% of the tube lasts as long as the first 90%. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 23:08 ` Darren New @ 2002-04-19 13:29 ` Marin David Condic 2002-04-20 3:04 ` Larry Kilgallen 0 siblings, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-19 13:29 UTC (permalink / raw) "Darren New" <dnew@san.rr.com> wrote in message news:3CBF5244.93CD9323@san.rr.com... > > In other words, a "map" is the API to a hash table or a search tree or > etc. You can implement them with trees, hash tables, linear lists, > whatever. > Don't forget ISAM files. :-) The concept of looking up something from a key value has been with us for a long time and maybe that's one of the reasons why maps get beat to death in programming once they're present. My experience is that if you've got arrays, lists and maps, you don't really need much else for most applications. Especially once you can easily load and store them from/to files. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-19 13:29 ` Marin David Condic @ 2002-04-20 3:04 ` Larry Kilgallen 0 siblings, 0 replies; 425+ messages in thread From: Larry Kilgallen @ 2002-04-20 3:04 UTC (permalink / raw) In article <a9p63b$71q$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > "Darren New" <dnew@san.rr.com> wrote in message > news:3CBF5244.93CD9323@san.rr.com... >> >> In other words, a "map" is the API to a hash table or a search tree or >> etc. You can implement them with trees, hash tables, linear lists, >> whatever. >> > > Don't forget ISAM files. :-) Funny you should mention that. I am currently working on a program that does such ordered lookups on temporary data read into the program, and I did not even consider the possibility of using (virtual) memory to store it, since I do not want to make assumptions regarding how much data there will be. ISAM files are just a natural fit. If you tell me that what you are calling "maps" are a portable way of doing that, I suppose that would be useful, although using files directly is fine with me. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 20:51 ` Ted Dennison 2002-04-18 21:28 ` Gary Scott @ 2002-04-18 22:28 ` Jeffrey Carter 2002-04-19 10:07 ` Georg Bauhaus 2002-04-20 5:12 ` Simon Wright 2 siblings, 1 reply; 425+ messages in thread From: Jeffrey Carter @ 2002-04-18 22:28 UTC (permalink / raw) Ted Dennison wrote: > > > I was just reading somewhere (exactly where escapes me) of a recent > > survey done on C++ programmers who have started using the STL. There > > was some surprise to discover that the most used container was map. > > Apparently what happens is that once programmers have map available, > > they begin using it all over the place, replacing little local ad-hoc > > lookup structures such as linear searches through arrays. > > Maps would certianly be my prime candidate. My last project > incorporated the Booch Components just for the map support. It also > seemed to be the most talked about other component during the strawman > list discussions (although admittedly I was doing a lot of that > talking). I've never used a map, but I do use skip lists frequently, probably for the same sort of thing. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 22:28 ` Jeffrey Carter @ 2002-04-19 10:07 ` Georg Bauhaus 2002-04-19 10:13 ` Georg Bauhaus 0 siblings, 1 reply; 425+ messages in thread From: Georg Bauhaus @ 2002-04-19 10:07 UTC (permalink / raw) Jeffrey Carter <jeffrey.carter@boeing.com> wrote: : I've never used a map, but I do use skip lists frequently, probably for : the same sort of thing. Are you sure? From the Booch components: generic type Key is private; with function "=" (L, R : Key) return Boolean is <>; package BC.Containers.Maps is -- ... -- A map denotes a collection forming a dictionary of domain/range -- pairs. -- The parameter Key denotes the universe from which the map draws -- its doamin; the parameter Item denotes the universe from which -- the map draws its range. The parameters Key and Item typically -- represent different types, although they may may represent the -- same types. Either may be a primitive type or user-defined. -- ... end BC.Containers.Maps; ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-19 10:07 ` Georg Bauhaus @ 2002-04-19 10:13 ` Georg Bauhaus 0 siblings, 0 replies; 425+ messages in thread From: Georg Bauhaus @ 2002-04-19 10:13 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: : Jeffrey Carter <jeffrey.carter@boeing.com> wrote: : : : I've never used a map, but I do use skip lists frequently, probably for : : the same sort of thing. : : Are you sure? ah probably yes. Darn. I've missed the lookup part. sorry. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 20:51 ` Ted Dennison 2002-04-18 21:28 ` Gary Scott 2002-04-18 22:28 ` Jeffrey Carter @ 2002-04-20 5:12 ` Simon Wright 2 siblings, 0 replies; 425+ messages in thread From: Simon Wright @ 2002-04-20 5:12 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Maps would certianly be my prime candidate. My last project > incorporated the Booch Components just for the map support. It also > seemed to be the most talked about other component during the > strawman list discussions (although admittedly I was doing a lot of > that talking). My current (work) project is using the BCs as the infrastructure for a (Rose)UML-to-Ada tool of mine called ColdFrame (work in progresss at http://www.pushface.org/coldframe/). I've used Maps as the container for all the instances of a class (keyed by the Identifier, the (combination of) attributes that uniquely identify instances) Collections for dealing with the results of searches Sets for ensuring uniqueness when navigating from Collections of one class via an association (this was overkill, perhaps) Ordered Queues for handling events. No trace of Stacks, Bags, Rings, Graphs, Trees! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 17:32 ` Hyman Rosen ` (3 preceding siblings ...) 2002-04-18 20:51 ` Ted Dennison @ 2002-04-19 11:00 ` John English 2002-04-19 16:45 ` Ingo Marks 4 siblings, 1 reply; 425+ messages in thread From: John English @ 2002-04-19 11:00 UTC (permalink / raw) Hyman Rosen wrote: > > I was just reading somewhere (exactly where escapes me) of a recent > survey done on C++ programmers who have started using the STL. There > was some surprise to discover that the most used container was map. > Apparently what happens is that once programmers have map available, > they begin using it all over the place, replacing little local ad-hoc > lookup structures such as linear searches through arrays. This figures. Java's Hashtable class (and more recent replacements HashMap and TreeMap) takes a similar pounding; and hashes in Perl are an absolute godsend. Amazing how much programmer time & effort can be wasted in languages that don't have something like these. ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-19 11:00 ` John English @ 2002-04-19 16:45 ` Ingo Marks 0 siblings, 0 replies; 425+ messages in thread From: Ingo Marks @ 2002-04-19 16:45 UTC (permalink / raw) John English wrote: > Hyman Rosen wrote: > > This figures. Java's Hashtable class (and more recent replacements > HashMap and TreeMap) takes a similar pounding; and hashes in Perl > are an absolute godsend. Amazing how much programmer time & effort > can be wasted in languages that don't have something like these. Perl has several nice features which makes it easy to write applications in short time with small effort. But I tell you from experience, it doesn't make it easy to maintain them! IMHO Perl (like APL) is a pretty "write-only" language ;-) When code reaches a "critical mass" of size then readibility and helpful features like range constrained data types (which AFAIK Perl and Java don't have) become much more important than the nice builtin-language features of Perl. Hence to clone these features in Ada is no wasted effort at all. On the contrary, it makes us able to used the so appreciated Perl and Java features in Ada too, in its much cleaner syntax. Regards, Ingo ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-18 16:00 ` Ted Dennison 2002-04-18 17:32 ` Hyman Rosen @ 2002-04-18 20:28 ` Michael Erdmann 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-18 20:28 UTC (permalink / raw) To: Ted Dennison > >>Just look at this, on the next ada conference in vienna they will >>have a talk about this as well. >> >>http://www.auto.tuwien.ac.at/AE2002/problems.html >> > > Yes, one of the organizers invited me to attend, based on my leading > of our List work. Unfortunately, a trip overseas to Vienna doesn't > exactly fit into my vacation schedule or personal budget this year. > > Since we mostly have a package worked out (at great pains) for lists, > hopefully they will concentrate on defining what other containers are > needed and how best to extend what we have. If there are any really > nasty flaws or fatal problems with the current package, that would be > an important issue too though. > > Since you are interested in this, I highly suggest you look over the > "strawman" threads in Google to bring yourself up to speed before > comming up with anything. It was a very extensive process and I'm not > really keen on going back over what has alredy been done yet again. > Please can you direct me a little more detailed? Michael. > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-17 18:36 ` Ted Dennison 2002-04-17 20:14 ` Michael Erdmann @ 2002-04-17 23:31 ` martin.m.dowie 1 sibling, 0 replies; 425+ messages in thread From: martin.m.dowie @ 2002-04-17 23:31 UTC (permalink / raw) > will be a good thing, as I also have a new baby due in less than a > week). I trust there will be a suitable c.l.a. announcement? ;-) "Break a leg" to your other half. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Outside view (still): Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann ` (4 preceding siblings ...) 2002-04-15 16:29 ` Michael Erdmann @ 2002-04-17 18:04 ` Kent Paul Dolan 2002-04-17 19:10 ` Michael Erdmann 2002-04-17 22:15 ` Robert Dewar 2002-04-27 8:26 ` Michael Erdmann 6 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-17 18:04 UTC (permalink / raw) "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > i am wondering how standards are eveloving in the Ada community. > In the Java Community there is a process called Java Community > Process (JCP, http://www.jcp.org/) > Is there something comparabel in the Ada communitiy? I gues > if there would be something like this there would be more > dynamic in the Ada 95 community. I thought this snippet of an email from the Ratio Group made an interesting commentary along the same lines; the problem of "too brittle ... too rigid" in a dynamic world seems to be generic, not limited to the Ada language capabilities development process. xanthian, not that this is going to be a huge surprise to any long-time software practitioner. (B) Extended Call for Position Papers: "Feyerabend Redefining Computing Workshop" at ECOOP 2002. The goal of this workshop is to bring together everyone who is interested in the redefinition of computing and/or in the use of alternative metaphors/languages/ ideas for entering the Next Era of computer science. The major problem with the current flow of ideas is that current approaches merely enable the construction of software that is too brittle and too rigid in order to survive and operate in our real world which is dynamic and constantly subject to change. For more information, visit http://www.dreamsongs.com/Feyerabend/ECOOP02/ -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 18:04 ` Outside view (still): " Kent Paul Dolan @ 2002-04-17 19:10 ` Michael Erdmann 2002-04-17 22:15 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-17 19:10 UTC (permalink / raw) Kent Paul Dolan wrote: > "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote: > > >>i am wondering how standards are eveloving in the Ada community. >>In the Java Community there is a process called Java Community >>Process (JCP, http://www.jcp.org/) >> > >>Is there something comparabel in the Ada communitiy? I gues >>if there would be something like this there would be more >>dynamic in the Ada 95 community. >> > > I thought this snippet of an email from the Ratio Group made an > interesting commentary along the same lines; the problem of "too brittle > ... too rigid" in a dynamic world seems to be generic, not limited to > the Ada language capabilities development process. > > xanthian, not that this is going to be a huge surprise to any long-time > software practitioner. > > (B) Extended Call for Position Papers: "Feyerabend Redefining Computing > Workshop" at ECOOP 2002. This is a nice title. In german language this sounds like "Feierabend..." This gives me some association which are translated back into english: "lets call it a day, ...and go for a drink" ... any how it is an interesting thing i am going to watch....:-) > The goal of this workshop is to bring together everyone who is > interested in the redefinition of computing and/or in the use of > alternative metaphors/languages/ ideas for entering the Next Era of > computer science. > The major problem with the current flow of ideas is > that current approaches merely enable the construction of software that > is too brittle and too rigid in order to survive and operate in our real > world which is dynamic and constantly subject to change. I am not so sure. I guess we three different aspects: Technically: Ada is missing some things we need every day.......... Social Wise There is no real homogenious community which is trying to achive the same thing (simply to survive). Newgroups are to informal to setup a real community. What community? There are a lot different members types in this community: - 100% Ada professional who are trying to make a living out of it. - Students which are trying solve there problems - Students which are persuing there ideas, diploma works etc.... - Peoples like my self, which are involved in software development in there professional time but using Ada in there spare time outside there professinal life persuing there personal ideas of differnet software. - Simply wise guys ...... .... and lots more.... Process Wise All these peoples are producing important software in Ada but most of the stuff goes down the drain, either because the software is not known, not stable or just because i am a wise guy which thinks i am doing every thing better then some body else. Simply there is no established process to make components a defact standard. :-( I know, real world is not this simple, each of these topics are related to each other, but my original idea was to do improve the "world" at least process wise by finding a development process which starts with a loose collection of ideas in the net and ends up in the ISO documentents, so that every body can rely on it! Regards M.Erdmann > > For more information, visit > http://www.dreamsongs.com/Feyerabend/ECOOP02/ > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 18:04 ` Outside view (still): " Kent Paul Dolan 2002-04-17 19:10 ` Michael Erdmann @ 2002-04-17 22:15 ` Robert Dewar 2002-04-17 23:20 ` Kent Paul Dolan 1 sibling, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-17 22:15 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:<cc3099f93a91d1e9c18e88d1a6381f6f.48257@mygate.mailgate.org>... > I thought this snippet of an email from the Ratio Group made an > interesting commentary along the same lines; the problem of "too brittle > ... too rigid" in a dynamic world seems to be generic, not limited to > the Ada language capabilities development process. Well that's certainly a reach! The quote is about software being too brittle and too rigid. From the point of view of the Ada community we would argue that Ada is all about avoiding such problems. The idea that the Ada language is itself brittle and rigid is unrelated (and also not supportable in my view). What makes languages brittle is when they accumulate ill thought out junk that does not work well and cannot be easily modified. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 22:15 ` Robert Dewar @ 2002-04-17 23:20 ` Kent Paul Dolan 2002-04-18 1:19 ` Pat Rogers ` (2 more replies) 0 siblings, 3 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-17 23:20 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote: > What makes languages brittle is when they accumulate ill thought out > junk that does not work well and cannot be easily modified. And what makes languages rigid is that they fail to incorporate good ideas that do work out well and have been widely praised. [Or was your earlier denial that Ada ignores inputs from the programming community a hint that you'd somehow managed to sneak in programming by contract, high power text parsing capabilities, et al., to the Ada language standard as long ago promoted here by dozens to hundreds of correspondents, and me not noticed?] xanthian. [Robert and I will never get along, the rest of you please do your best to ignore us.] -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 23:20 ` Kent Paul Dolan @ 2002-04-18 1:19 ` Pat Rogers 2002-04-18 4:53 ` Kent Paul Dolan ` (2 more replies) 2002-04-18 2:12 ` Larry Kilgallen 2002-04-18 4:21 ` Richard Riehle 2 siblings, 3 replies; 425+ messages in thread From: Pat Rogers @ 2002-04-18 1:19 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> wrote in message news:99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org... > "Robert Dewar" <dewar@gnat.com> wrote: > > > What makes languages brittle is when they accumulate ill thought out > > junk that does not work well and cannot be easily modified. > > And what makes languages rigid is that they fail to incorporate good > ideas that do work out well and have been widely praised. > > [Or was your earlier denial that Ada ignores inputs from the programming > community a hint that you'd somehow managed to sneak in programming by > contract, high power text parsing capabilities, et al., to the Ada > language standard as long ago promoted here by dozens to hundreds of > correspondents, and me not noticed?] And why would I want high-powered text parsing in my hard real-time embedded application? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 1:19 ` Pat Rogers @ 2002-04-18 4:53 ` Kent Paul Dolan 2002-04-18 5:40 ` Simon Wright 2002-04-18 8:25 ` Dmitry A. Kazakov 2 siblings, 0 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 4:53 UTC (permalink / raw) "Pat Rogers" <rogers@gnat.com> wrote: > And why would I want high-powered text parsing in my hard real-time embedded > application? 1) Don't make the common error of assuming that the whole world is a clone of the view seen from your desk; Ada does lots more than "hard, real time embedded" apps. The future health of Ada depends on it providing a balanced set of capabilities to do them all well. 2) Especially for exactly such apps, turning strings of bytes (whether originally text or not) into reports (even if only old fashioned text debugging messages) is much less unpleasant with decent tools; I know for creating embedded SNMP agent summary reports, being able to parse bales of haystack to find needles of useful information was always an issue. I would certainly anticipate similar needs in a battlefield evaluation tool; often the human at the receiving end needs to see the answer as text. 3) That the language contains the capability doesn't at all imply that your code image downloaded into your embedded app would show any trace of that ability in the language. There is rarely indeed overhead for unused capabilities in code emitted from any decent compiler, certainly the compiler writers' goal is that that overhead be zero. Just to give you the first three of probably several hundred available reasons that happened to pop into my head. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 1:19 ` Pat Rogers 2002-04-18 4:53 ` Kent Paul Dolan @ 2002-04-18 5:40 ` Simon Wright 2002-04-19 13:22 ` Ted Dennison 2002-04-18 8:25 ` Dmitry A. Kazakov 2 siblings, 1 reply; 425+ messages in thread From: Simon Wright @ 2002-04-18 5:40 UTC (permalink / raw) "Pat Rogers" <rogers@gnat.com> writes: > And why would I want high-powered text parsing in my hard real-time > embedded application? Because you want to read the systems's controlling parameter set (in our case, a few hundred options) fron an XML-format file (in Flash, perhaps)? OK, not likely for a digital watch, but I'm not making this one up! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 5:40 ` Simon Wright @ 2002-04-19 13:22 ` Ted Dennison 0 siblings, 0 replies; 425+ messages in thread From: Ted Dennison @ 2002-04-19 13:22 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote in message news:<x7vu1q9fttc.fsf@smaug.pushface.org>... > "Pat Rogers" <rogers@gnat.com> writes: > > > And why would I want high-powered text parsing in my hard real-time > > embedded application? > > Because you want to read the systems's controlling parameter set (in > our case, a few hundred options) fron an XML-format file (in Flash, > perhaps)? I have to chime in here that OpenToken was originally developed as a configuration file parse tool for a real-time flight simulation. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 1:19 ` Pat Rogers 2002-04-18 4:53 ` Kent Paul Dolan 2002-04-18 5:40 ` Simon Wright @ 2002-04-18 8:25 ` Dmitry A. Kazakov 2 siblings, 0 replies; 425+ messages in thread From: Dmitry A. Kazakov @ 2002-04-18 8:25 UTC (permalink / raw) On Thu, 18 Apr 2002 01:19:27 GMT, "Pat Rogers" <rogers@gnat.com> wrote: >"Kent Paul Dolan" <xanthian@well.com> wrote in message >news:99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org... >> "Robert Dewar" <dewar@gnat.com> wrote: >> >> > What makes languages brittle is when they accumulate ill thought out >> > junk that does not work well and cannot be easily modified. >> >> And what makes languages rigid is that they fail to incorporate good >> ideas that do work out well and have been widely praised. >> >> [Or was your earlier denial that Ada ignores inputs from the programming >> community a hint that you'd somehow managed to sneak in programming by >> contract, high power text parsing capabilities, et al., to the Ada >> language standard as long ago promoted here by dozens to hundreds of >> correspondents, and me not noticed?] > >And why would I want high-powered text parsing in my hard real-time embedded >application? I could be well possible. An example is a real project of autopilot I am involved in. It is an embedded soft real-time application. By the nature of autopilot, it should have some AI gears. Here you are. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 23:20 ` Kent Paul Dolan 2002-04-18 1:19 ` Pat Rogers @ 2002-04-18 2:12 ` Larry Kilgallen 2002-04-18 5:03 ` Kent Paul Dolan 2002-04-18 4:21 ` Richard Riehle 2 siblings, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-18 2:12 UTC (permalink / raw) In article <99c4aee4a9ea33ca8fbe1e634b3b4f14.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes: > "Robert Dewar" <dewar@gnat.com> wrote: > >> What makes languages brittle is when they accumulate ill thought out >> junk that does not work well and cannot be easily modified. > > And what makes languages rigid is that they fail to incorporate good > ideas that do work out well and have been widely praised. ACT has experimented with several pragmas and attributes outside the standard. What other ideas have been worked out and proven in an Ada environment ? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 2:12 ` Larry Kilgallen @ 2002-04-18 5:03 ` Kent Paul Dolan 2002-04-18 12:50 ` Larry Kilgallen 2002-04-18 13:43 ` Marin David Condic 0 siblings, 2 replies; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 5:03 UTC (permalink / raw) "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:.. > ACT has experimented with several pragmas and attributes outside > the standard. What other ideas have been worked out and proven > in an Ada environment ? Sorry, but read your own words. Don't they scream "inbred" to you? xanthian, who would mildly suggest that ideas that have been worked out and proven in other programming language environments are at this point _much_ more important to Ada's future as a viable programming language, than merely rechurning stuff already known to work here. Again, if you don't provide in Ada the modern functionalities the students learn to value in school, they will turn away to the tools that do. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 5:03 ` Kent Paul Dolan @ 2002-04-18 12:50 ` Larry Kilgallen 2002-04-18 14:34 ` Gary Scott 2002-04-18 13:43 ` Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Larry Kilgallen @ 2002-04-18 12:50 UTC (permalink / raw) In article <1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes: > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:.. > >> ACT has experimented with several pragmas and attributes outside >> the standard. What other ideas have been worked out and proven >> in an Ada environment ? > > > Sorry, but read your own words. Don't they scream "inbred" to you? No, think of it as an entrance examination. If you think something is useful, prove that it is useful in Ada. By that, you will prove to us all that it is worth doing in Ada. If even an advocate will not go to the effort to provide a worked example, the idea cannot be presumed worthwhile. > xanthian, who would mildly suggest that ideas that have been worked out > and proven in other programming language environments are at this point > _much_ more important to Ada's future as a viable programming language, > than merely rechurning stuff already known to work here. > > Again, if you don't provide in Ada the modern functionalities the > students learn to value in school, they will turn away to the tools that > do. The fact that something is taught in school does not automatically make it worthwhile. The fact that it is attractive to students is even less compelling. I am much more interested in Ada's effectiveness than I am in its popularity. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 12:50 ` Larry Kilgallen @ 2002-04-18 14:34 ` Gary Scott 0 siblings, 0 replies; 425+ messages in thread From: Gary Scott @ 2002-04-18 14:34 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org>, "Kent Paul Dolan" <xanthian@well.com> writes: > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote:.. > > > >> ACT has experimented with several pragmas and attributes outside > >> the standard. What other ideas have been worked out and proven > >> in an Ada environment ? > > > > > > Sorry, but read your own words. Don't they scream "inbred" to you? > > No, think of it as an entrance examination. > > If you think something is useful, prove that it is useful in Ada. > By that, you will prove to us all that it is worth doing in Ada. > If even an advocate will not go to the effort to provide a worked > example, the idea cannot be presumed worthwhile. > > > xanthian, who would mildly suggest that ideas that have been worked out > > and proven in other programming language environments are at this point > > _much_ more important to Ada's future as a viable programming language, > > than merely rechurning stuff already known to work here. > > > > Again, if you don't provide in Ada the modern functionalities the > > students learn to value in school, they will turn away to the tools that > > do. > > The fact that something is taught in school does not automatically > make it worthwhile. The fact that it is attractive to students is > even less compelling. I am much more interested in Ada's effectiveness > than I am in its popularity. Certainly by far the most important, but if the language dies because of lack of responsiveness to market pressures, then who cares. -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com Support the GNU Fortran G95 Project: http://g95.sourceforge.net ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 5:03 ` Kent Paul Dolan 2002-04-18 12:50 ` Larry Kilgallen @ 2002-04-18 13:43 ` Marin David Condic 1 sibling, 0 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-18 13:43 UTC (permalink / raw) Well, there's a danger for Ada to attempt to be all things to all programmers. Just because a feature worked out nicely in some other language doesn't mean it fits well with the design goals of Ada (which is already criticized for trying to do too much.) To the extent that some capability could be provided by an add-on library, it might be a good idea to add it to the language - with all sorts of cautions about doing it informally at first, etc. etc. etc. If it starts requiring some syntactic/semantic changes to the language itself, I'd consider the Fools Rush In principle to be an important one to keep in mind. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Kent Paul Dolan" <xanthian@well.com> wrote in message news:1a976f56c5a59e7ee74d2030a5702737.48257@mygate.mailgate.org... > > xanthian, who would mildly suggest that ideas that have been worked out > and proven in other programming language environments are at this point > _much_ more important to Ada's future as a viable programming language, > than merely rechurning stuff already known to work here. > > Again, if you don't provide in Ada the modern functionalities the > students learn to value in school, they will turn away to the tools that > do. > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-17 23:20 ` Kent Paul Dolan 2002-04-18 1:19 ` Pat Rogers 2002-04-18 2:12 ` Larry Kilgallen @ 2002-04-18 4:21 ` Richard Riehle 2002-04-18 4:59 ` Kent Paul Dolan 2002-04-18 14:07 ` Outside view (still): Development process in the Ada community Marin David Condic 2 siblings, 2 replies; 425+ messages in thread From: Richard Riehle @ 2002-04-18 4:21 UTC (permalink / raw) Kent Paul Dolan wrote: > "Robert Dewar" <dewar@gnat.com> wrote: > > > What makes languages brittle is when they accumulate ill thought out > > junk that does not work well and cannot be easily modified. > > And what makes languages rigid is that they fail to incorporate good > ideas that do work out well and have been widely praised. In my view, it is more a problem of deciding what to include in the language and what to include in the libraries written in the language. Ada, C++, Java, C#, and Ruby, to name a few, are designed so one can extend the core functionality with libaries. The very idea of extensible types/classes, enables us to build powerful functionality such as CLAW, GtkAda, JEWL, CAMP, and many other software frameworks. These frameworks, in turn, let us build applications. Earlier languages such as COBOL, PL/I, and Fortran were less extensible and certainly characterized by a kind of brittleness. Perhaps I should say, earlier versions of these languages since all three have gone through considerable revision. Someone at IBM even mentioned that there would be an OOP version of PL/I someday. That was four years ago and we still have not seen it published. Dr. Dewar is correct in his view that the designers of Ada have taken great pains to avoid including language features that could be better implemented as library modules. The question is whether these libraries should be part of the standard Annexes. Should be expand the Annexes to include generalize GUI specifications, Database specifications, etc? The answer is not so simple. When one realizes that the vast majority of desktop software is written for the monopolisic operating system from one company, it is all too easy to capitulate and agree to facilitating that monopoly even further. Some of us would hope that such a thing would not happen to Ada, even at the risk of limiting Ada's popularity. From other postings in this thread, it is clear that capitulation is not necessary. There are bindings in Ada that support the operating system from the "dark side" as well as bindings for those operating systems one might classify as "open." All this has happened without adding features to the language that are platform-specific. I'd say that, despite its failure to become popular, Ada is evolving as it should as a language. We do need more tools, development environments, GUI builders, and debugging environments, but those are not a concern of the language designers. Rather, they are the concern of people who use the language as it is designed. Richard Riehle ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 4:21 ` Richard Riehle @ 2002-04-18 4:59 ` Kent Paul Dolan 2002-04-18 14:44 ` new Ada language features needed? Stephen Leake 2002-04-18 14:07 ` Outside view (still): Development process in the Ada community Marin David Condic 1 sibling, 1 reply; 425+ messages in thread From: Kent Paul Dolan @ 2002-04-18 4:59 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote: [...] > I'd say that, despite its failure to become popular, Ada is evolving > as it should as a language. We do need more tools, development > environments, GUI builders, and debugging environments, but those > are not a concern of the language designers. Rather, they are the > concern of people who use the language as it is designed. A useful set of words, but not responsive to a posting in which the things mentioned (better parsing capabilities, programming by contract) were explicitly things that very much need to be part of the language, not some library capability. xanthian. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG ^ permalink raw reply [flat|nested] 425+ messages in thread
* new Ada language features needed? 2002-04-18 4:59 ` Kent Paul Dolan @ 2002-04-18 14:44 ` Stephen Leake 0 siblings, 0 replies; 425+ messages in thread From: Stephen Leake @ 2002-04-18 14:44 UTC (permalink / raw) "Kent Paul Dolan" <xanthian@well.com> writes: > "Richard Riehle" <richard@adaworks.com> wrote: > > [...] > > > I'd say that, despite its failure to become popular, Ada is evolving > > as it should as a language. We do need more tools, development > > environments, GUI builders, and debugging environments, but those > > are not a concern of the language designers. Rather, they are the > > concern of people who use the language as it is designed. > > A useful set of words, but not responsive to a posting in which the > things mentioned (better parsing capabilities, What's wrong with the parsing capabilities in the GNAT Spitbol and regexp packages? Or the GNAT front end, or OpenToken? What, exactly, needs to be added to the language to better support parsing? > programming by contract) In some forms, this does need more language support than Ada currently provides. However, I have yet to see convincing proof that it is worth it. I've seen simple examples where the effort needed to write and compute the contract is comparable to the effort needed to write and compute the code; that's a marginal gain. For real-life, complex code, thorough unit testing is a far more efficient use of my time and the CPU's time, and the current Ada features that allow defining and enforcing interfaces to software subsystems are just fine. > were explicitly things that very much need to be part of the > language, not some library capability. -- -- Stephe ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 4:21 ` Richard Riehle 2002-04-18 4:59 ` Kent Paul Dolan @ 2002-04-18 14:07 ` Marin David Condic 2002-04-19 17:39 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Marin David Condic @ 2002-04-18 14:07 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3CBE49C4.99CFA22D@adaworks.com... > > Dr. Dewar is correct in his view that the designers of Ada have taken > great pains to avoid including language features that could be better > implemented as library modules. The question is whether these > libraries should be part of the standard Annexes. Should be expand > the Annexes to include generalize GUI specifications, Database > specifications, etc? The answer is not so simple. When one realizes O.K., but here's a fair question: If the language is designed to be extended with libraries, why do we seem to have such difficulty in incorporating libraries in some kind of "standard" way? There's extension of the language by my personal definition of libraries in my own development environment and that's fine. I realize there are all sorts of sticky issues in terms of actually updating the ARM annexes with additional libraries that would probably be useful to everyone, so I can see the reluctance to do so. But shouldn't we have some means of less formally extending the language via libraries that might be viewed more as "convention" than "standard"? Something formal enough that everybody understands what the libraries are about and they become "The Answer" for the problem domain in question (as opposed to "An Answer") but not so formal as to make it difficult to get things into or out of it? I think the W3C has a kind of interesting approach. They sort of look over a problem and put up a web page that says "Here's a standard that addresses the problem. Do you like it?" They might even put out two or three competing or overlapping standards to see which ones seem to begin to fly. The standards keep going through revisions as comments come in and sooner or later they declare victory and say "O.K. This standard is considered stable, so we promise no more changes to it." If better ideas and enhancements come along, they start a "Level 2" for the standard. Wouldn't something similar work for adding libraries to Ada? Some sort of consortium of vendors and users to develop library specs & possibly bodies that go through iterations until everyone is happy or at least too tired to keep arguing about it? Then declare some version of "By Convention, Ada Compilers Will Include This..." as a non-binding "standard" for adoption by members. Just an idea.... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-18 14:07 ` Outside view (still): Development process in the Ada community Marin David Condic @ 2002-04-19 17:39 ` Michael Erdmann 2002-04-19 18:58 ` Marin David Condic 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-19 17:39 UTC (permalink / raw) Marin David Condic wrote: > "Richard Riehle" <richard@adaworks.com> wrote in message > news:3CBE49C4.99CFA22D@adaworks.com... > > > I think the W3C has a kind of interesting approach. They sort of look over a > problem and put up a web page that says "Here's a standard that addresses > the problem. Do you like it?" They might even put out two or three competing > or overlapping standards to see which ones seem to begin to fly. The > standards keep going through revisions as comments come in and sooner or > later they declare victory and say "O.K. This standard is considered stable, > so we promise no more changes to it." If better ideas and enhancements come > along, they start a "Level 2" for the standard. I agree on this. The process which leads to a standard always has to considder the evolution process for standards by establishing procedures for refinement and reworking. I guess ISO/ITU/ETSI just name it do have such procedures. The problem is a different one, If you invested a lot effort in implementing a standard, then you are not automatically interested in revising it unless is simply does not work. I think this is the reason why new standards go along with social changes in the respective community. > > Wouldn't something similar work for adding libraries to Ada? Some sort of > consortium of vendors and users to develop library specs & possibly bodies > that go through iterations until everyone is happy or at least too tired to > keep arguing about it? Then declare some version of "By Convention, Ada > Compilers Will Include This..." as a non-binding "standard" for adoption by > members. > For example if you look at the python enhancement process you will find that it works like this. This is not a standarization but it is an improvement process (pep - http://www.python.org/pep/pep-0001.html). May be we can adopt this some how to establish an ada enhancment process? > Just an idea.... > > MDC > -- > Marin David Condic > Senior Software Engineer > Pace Micro Technology Americas www.pacemicro.com > Enabling the digital revolution > e-Mail: marin.condic@pacemicro.com > > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-19 17:39 ` Michael Erdmann @ 2002-04-19 18:58 ` Marin David Condic 2002-04-20 17:35 ` Michael Erdmann 2002-04-22 17:57 ` Robert Dewar 0 siblings, 2 replies; 425+ messages in thread From: Marin David Condic @ 2002-04-19 18:58 UTC (permalink / raw) Other than issues of time and money, I don't see why it *can't* work. Here's the thing: I could put up a web page and declare myself the Informal Ada Conventions Consortium and declare "Henceforth, the following packages are considered to be Official IACC standards and all Ada implementations need to include them in order to be conformant!" What weight does it carry? That's why it would need some kind of committee of concerned citizens under the aegis of SIGAda (or some other organization) with some pretty strong willingness on the part of vendors to buy into it. The process needs to be agile and probably needs to yield reference implementations rather than just specifications, or it isn't likely to effectively get anything into various compiler distributions.You'd like to think that perhaps it could produce some sort of new extension to the library, say, every 6 months? That might do a lot to make it reactive to the needs of the community & move Ada closer to the capabilities of its competitors. Of course, getting any of this off bottom-dead-center is a difficult thing. It would require some corporate and institutional support, both for the concept and by way of some finances. Is that likely to happen? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Michael Erdmann" <Michael.Erdmann@snafu.de> wrote in message news:3CC05650.5060908@snafu.de... > > May be we can adopt this some how to establish an ada enhancment > process? > > ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-19 18:58 ` Marin David Condic @ 2002-04-20 17:35 ` Michael Erdmann 2002-04-22 17:57 ` Robert Dewar 1 sibling, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-20 17:35 UTC (permalink / raw) Marin David Condic wrote: > Other than issues of time and money, I don't see why it *can't* work. Here's > the thing: I could put up a web page and declare myself the Informal Ada > Conventions Consortium and declare "Henceforth, the following packages are > considered to be Official IACC standards and all Ada implementations need to > include them in order to be conformant!" What weight does it carry? > > That's why it would need some kind of committee of concerned citizens under > the aegis of SIGAda (or some other organization) with some pretty strong > willingness on the part of vendors to buy into it. In the Moment i can see only one vendor.But SIGAda may be a good idea! > The process needs to be > agile and probably needs to yield reference implementations rather than just > specifications, or it isn't likely to effectively get anything into various > compiler distributions. Yes, this is what we talked earlier about. Step 1 -Get a group together Step 2 - make a reference implementation Step 3 - distribute it with one of the most common compiler(s). > You'd like to think that perhaps it could produce > some sort of new extension to the library, say, every 6 months? Yes, follow the guideline, release early and often when you are building the reference implemenation. > That might > do a lot to make it reactive to the needs of the community & move Ada closer > to the capabilities of its competitors. > This is not all, what you need is to have some kind of crystalization point for such kind of work, in order to avoid that if a maintainer of a package drops out, a package is without any maintainer. > Of course, getting any of this off bottom-dead-center is a difficult thing. > It would require some corporate and institutional support, both for the > concept and by way of some finances. Is that likely to happen? I do not think so. In the case of the python enhancement process have hove not yet found out who is the commercial engiene. But i am not so sure if it is realy needed. I think the most important thing in the moment is the step 1, getting a groups of people together, working( not only discussing) on packages which are important to the Ada community! Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-19 18:58 ` Marin David Condic 2002-04-20 17:35 ` Michael Erdmann @ 2002-04-22 17:57 ` Robert Dewar 2002-04-22 19:46 ` Michael Erdmann 1 sibling, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-22 17:57 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a9ppc5$fve$1@nh.pace.co.uk>... > Other than issues of time and money, I don't see why it > *can't* work. Here's the thing: I could put up a web page > and declare myself the Informal Ada Conventions > Consortium and declare "Henceforth, the following > packages are considered to be Official IACC standards and > all Ada implementations need to include them in order to > be conformant!" What weight does it carry? Well none at all of course. And one thing to realize is that the ISO process does not have some external legitimacy. It derives legitimacy from reflecting input of vendors and serious Ada users. If you can't get vendors or serious Ada users to buy in, you should not imagine that you can persuade ISO to issue standards for things that do not have this kind of interest level. You certainly can't go to ISO and say, "look, we don't seem to be able to get any vendors or major Ada users interested, but those folks who post on CLA are really enthusiastic". On the other hand actual useful implementations are definitely a way to generate such interest, and that remains the best way to make progress. An interesting precedent here is the attempt to pseudo-standardize the Win32 bindings in the ARA environment. There just was not enough interest to overcome the problems. One thing to realize is that official conformance and validation has largely disappeared as a major concern. The validation process itself has now been relaxed so that basically all that needs to happen is a vendor says that they pass the tests, pay some money, and you get a certificate. ACT views this kind of validation as pretty meaningless, and if we do further validations they will be in the old style with on-site verification. In fact, while we certainly find it very useful to run the ACATS tests (we run them every night on all targets and make sure that we pass them), we see almost no demand for formal validation. What I think would be most useful is to generate new bindings and useful packages. Quite a few people (like Tom and Ted and Florian and Michael and others -- I am not trying to make a complete list here, and I would never succeeed) have put in effort on this, and that seems to be by far the best use of energy. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-22 17:57 ` Robert Dewar @ 2002-04-22 19:46 ` Michael Erdmann 2002-04-22 20:24 ` Florian Weimer 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-22 19:46 UTC (permalink / raw) Robert Dewar wrote: level. > > You certainly can't go to ISO and say, "look, we don't seem > to be able to get any vendors or major Ada users interested, but those > folks who post on CLA are really > enthusiastic". I agree on this. I have removed the ISO completly from my Agenda. .......... > > What I think would be most useful is to generate new bindings and > useful packages. Quite a few people (like Tom and Ted and Florian and > Michael and others -- I am not trying to make a complete list here, > and I would never succeeed) have put in effort on this, and that seems > to > be by far the best use of energy. > I think you are right. If you look at the open source community, progress has not been achieved by ISO style of working groups. In most cases "..release early and often.." and the fact that the code was "..use full.." in community context was generating most of the dynamic and the progress. So i am realy wondering why it is not possible to gather some people, make a reference implementation of a reasonable set of simple and well documented package set. There have been a lot of attempts so far as i know, but my personal impression was that the way woas more important then the reaching the destination. So i am realy wondering if the "..community .." namely comp.lang.ada realy needs these nice package? Any how, i need these packages saving precious time. So I guess somebody else may need them as well. This already makes it worth to make an additional attempt! So i am realy wondering if ACT could establish some kind of public contribtion process. This would make it possible to boundle the compiler with some of these packages. I would expect that ACT, which is an authority in comp.lang.ada, could be the crystalisation point for a lot of currently uncoordinated activities. What do you think? Regards M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-22 19:46 ` Michael Erdmann @ 2002-04-22 20:24 ` Florian Weimer 2002-04-23 4:54 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Florian Weimer @ 2002-04-22 20:24 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> writes: > So i am realy wondering if ACT could establish some kind of public > contribtion process. This would make it possible to boundle the > compiler with some of these packages. There is already a contribution process: submit a patch to gcc-patches@gcc.gnu.org. ;-) ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-22 20:24 ` Florian Weimer @ 2002-04-23 4:54 ` Michael Erdmann 2002-04-23 20:37 ` Florian Weimer 0 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-23 4:54 UTC (permalink / raw) Florian Weimer wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> writes: > > >>So i am realy wondering if ACT could establish some kind of public >>contribtion process. This would make it possible to boundle the >>compiler with some of these packages. >> > > There is already a contribution process: submit a patch to > gcc-patches@gcc.gnu.org. ;-) > But this has more the falvour of beeing an error correction process!? ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-23 4:54 ` Michael Erdmann @ 2002-04-23 20:37 ` Florian Weimer 2002-04-25 17:29 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Florian Weimer @ 2002-04-23 20:37 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> writes: >> There is already a contribution process: submit a patch to >> gcc-patches@gcc.gnu.org. ;-) > But this has more the falvour of beeing an error correction > process!? Yes, your patch is subjected to review, of course. Or do you think that the list is for GCC bug fixes only? This is wrong, all patches (even patches adding new features) should be sent to this list for consideration. ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Outside view (still): Development process in the Ada community 2002-04-23 20:37 ` Florian Weimer @ 2002-04-25 17:29 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-25 17:29 UTC (permalink / raw) Florian Weimer wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> writes: > > >>>There is already a contribution process: submit a patch to >>>gcc-patches@gcc.gnu.org. ;-) >>> > >>But this has more the falvour of beeing an error correction >>process!? >> > > Yes, your patch is subjected to review, of course. > > Or do you think that the list is for GCC bug fixes only? This is > wrong, all patches (even patches adding new features) should be sent > to this list for consideration. > This is new to me! ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-10 16:33 Development process in the Ada community Michael Erdmann ` (5 preceding siblings ...) 2002-04-17 18:04 ` Outside view (still): " Kent Paul Dolan @ 2002-04-27 8:26 ` Michael Erdmann 2002-04-27 23:54 ` Robert Dewar 6 siblings, 1 reply; 425+ messages in thread From: Michael Erdmann @ 2002-04-27 8:26 UTC (permalink / raw) To: Michael Erdmann After having a long discussion with several people in the community i think we should proceed in the following way: Setup a project with the following objectives: * Creation of a Ada support library which ranges from light to havy weight packages till end of this year which are making lfe easier. * In long terms the library should become a defacto standard for the Ada community and should be boundeld with Ada compilers. * The licensing of the library will be the commonly used FSF 2.0 Liecense with the exceptions listed "As a special exception, if other files instantiate generics from this unit, or you link this unit with other files to produce an executable, this unit does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License.." To achive this the following principles shall be applied: * Since the idea is to establish a code base relatively fast reuse goes over redesign. * This first component delivered for a certain domain defines the base from where the development start. * For each domain a chmpion has to be defined who is in charge of organizing the packages in the hirarchy of his domain, but she/he shall take only a minimal influence on the contents of the packages. * The contents of the packages is completly in the responsibility of the package author. * Please no extensive style discussions, a common style will evolve during the first iterations of the project. * Technical discussions? yes, but please keep in mind, that the idea is to produce a code base till end of the year. Not always the technically best solution is needed in the market. A timely solution to a problem is the one which counts! * Documentation is part of the source code. This is the only restriction to the contents of the packages. It has to be possible to extract automatically the package documentations. Since i have a project at sourceforge.net with the name ASCL (Application Standard Component library) but no activity any more i would be willing to drop the current contents of this project and reorganize it for this project called: Ada Standard Component Library - ASCL Currently i do see the following domains: Networking Communication Data structures (Containers, lists .....) Files Configuration Any thing i forgot? Any how i like to invite every body in the community to spend some time in checking there repositories for usefull components. If you find something usefull (which means you already used it your self) or if you are willing to be the champion of a domain simply send me a mail, that we get organized! So lets try it again! Regrads M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-27 8:26 ` Michael Erdmann @ 2002-04-27 23:54 ` Robert Dewar 2002-04-28 14:18 ` Michael Erdmann 0 siblings, 1 reply; 425+ messages in thread From: Robert Dewar @ 2002-04-27 23:54 UTC (permalink / raw) Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CCA609F.9030503@snafu.de>... > * In long terms the library should become a defacto > standard for the Ada community and should be > boundeld with Ada compilers. Don't count on this kind of bundling. Speaking for ACT, we would only bundle a library if: a) our customers actively needed a supported version b) we had the resources to provide full support I think it's still a success to generate some useful packages even if they don't get bundled by vendors. > * Please no extensive style discussions, a common style > will evolve during the first iterations of the > project. That seems a mistake to me, it is very difficult to impose a common standard later on. Why not at least adopt -gnaty as a starting point together with the general guidelines in AQ&S. I don't think -gnaty is someone better than some other possible standard, but consistency is important, and it is important to agree on something. > Any how i like to invite every body in the community > to spend some time in checking there repositories > for usefull components. If you find something > usefull (which means you already used it your self) > or if you are willing to be the champion of a domain > simply send me a mail, that we get organized! A reasonable invitation! Most certainly ACT spends quite a bit of time generating such components, and they get put in our GNAT library, which is available for anyone to look at and either use, or derive inspirations from :-) Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 425+ messages in thread
* Re: Development process in the Ada community 2002-04-27 23:54 ` Robert Dewar @ 2002-04-28 14:18 ` Michael Erdmann 0 siblings, 0 replies; 425+ messages in thread From: Michael Erdmann @ 2002-04-28 14:18 UTC (permalink / raw) To: Robert Dewar Robert Dewar wrote: > Michael Erdmann <Michael.Erdmann@snafu.de> wrote in message news:<3CCA609F.9030503@snafu.de>... > > >>* In long terms the library should become a defacto >> standard for the Ada community and should be >> boundeld with Ada compilers. >> > > Don't count on this kind of bundling. Speaking for ACT, we > would only bundle a library if: > > a) our customers actively needed a supported version > b) we had the resources to provide full support > > I think it's still a success to generate some useful packages > even if they don't get bundled by vendors. I dont count on it, this is just an statement of intention! >>* Please no extensive style discussions, a common style >> will evolve during the first iterations of the >> project. >> > > That seems a mistake to me, it is very difficult to impose a common > standard later on. Why not at least adopt -gnaty as a starting point > together with the general guidelines in AQ&S. I don't think -gnaty > is someone better than some other possible standard, but consistency > is important, and it is important to agree on something. But i won't reject a package for style reasons, if it does what it is expected to do. I like to avoid discussions about the form of identifiers, e.g. Container_Type or simply Container. Sure complete anarchy has to be avoided, but i like to discuss this issue on a case to case basis not in general > >>Any how i like to invite every body in the community >>to spend some time in checking there repositories >>for usefull components. If you find something >>usefull (which means you already used it your self) >>or if you are willing to be the champion of a domain >>simply send me a mail, that we get organized! >> > > A reasonable invitation! Most certainly ACT spends quite > a bit of time generating such components, and they get > put in our GNAT library, which is available for anyone > to look at and either use, or derive inspirations from :-) I hope it works out! M.Erdmann ^ permalink raw reply [flat|nested] 425+ messages in thread
end of thread, other threads:[~2002-05-02 15:52 UTC | newest] Thread overview: 425+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-10 16:33 Development process in the Ada community Michael Erdmann 2002-04-10 23:28 ` Randy Brukardt 2002-04-11 4:53 ` Michael Erdmann 2002-04-11 7:34 ` Petter Fryklund 2002-04-11 16:39 ` Michael Erdmann 2002-04-11 8:37 ` Eric G. Miller 2002-04-11 13:27 ` Marin David Condic 2002-04-12 12:33 ` Larry Kilgallen 2002-04-12 12:56 ` Marin David Condic 2002-04-12 23:59 ` Michael Erdmann 2002-04-11 17:26 ` Michael Erdmann 2002-04-11 10:41 ` Martin Dowie 2002-04-11 16:50 ` Michael Erdmann 2002-04-11 18:21 ` Marin David Condic 2002-04-12 4:43 ` tmoran 2002-04-12 11:13 ` Claw thick bindings to sockets (was: Development process in the Ada..) Larry Kilgallen 2002-04-12 17:22 ` tmoran 2002-04-12 21:24 ` Larry Kilgallen 2002-04-12 23:18 ` tmoran 2002-04-12 23:19 ` Development process in the Ada community tony 2002-04-12 23:52 ` Michael Erdmann 2002-04-15 14:35 ` Marin David Condic 2002-04-11 20:26 ` Randy Brukardt 2002-04-11 12:38 ` Jim Rogers 2002-04-11 16:48 ` Michael Erdmann 2002-04-11 18:09 ` Ted Dennison 2002-04-11 18:26 ` Michael Erdmann 2002-04-11 21:05 ` Randy Brukardt 2002-04-11 22:26 ` Ted Dennison 2002-04-12 13:13 ` Marin David Condic 2002-04-15 14:28 ` Ted Dennison 2002-04-15 17:53 ` Marin David Condic 2002-04-12 8:35 ` Ingo Marks 2002-04-12 14:37 ` Ted Dennison 2002-04-12 15:44 ` Georg Bauhaus 2002-04-11 21:14 ` Rant! (was) " Kent Paul Dolan 2002-04-11 23:20 ` tony 2002-04-12 0:55 ` Chad R. Meiners 2002-04-12 1:21 ` Pat Rogers 2002-04-12 15:57 ` Georg Bauhaus 2002-04-12 22:20 ` Chad R. Meiners 2002-04-12 21:02 ` --off topic " tony 2002-04-12 23:52 ` Chad R. Meiners 2002-04-14 10:57 ` Georg Bauhaus 2002-04-14 22:17 ` Chad R. Meiners 2002-04-12 14:57 ` Ted Dennison 2002-04-12 23:12 ` tony 2002-04-12 10:10 ` Ingo Marks 2002-04-12 11:11 ` Larry Kilgallen 2002-04-12 23:18 ` tmoran 2002-04-12 17:22 ` Florian Weimer 2002-04-12 17:38 ` Mário Amado Alves 2002-04-12 18:29 ` Kent Paul Dolan 2002-04-13 3:30 ` Robert Dewar 2002-04-13 10:12 ` martin.m.dowie 2002-04-13 13:21 ` Larry Kilgallen 2002-04-13 13:39 ` martin.m.dowie 2002-04-13 14:12 ` Gary Scott 2002-04-13 14:20 ` Robert Dewar 2002-04-13 16:03 ` martin.m.dowie 2002-04-15 15:03 ` Marin David Condic 2002-04-16 8:30 ` Frank 2002-04-21 11:35 ` Michal Nowak 2002-04-16 15:43 ` martin.m.dowie 2002-04-16 16:53 ` Marin David Condic 2002-04-17 6:16 ` martin.m.dowie 2002-04-17 12:55 ` Marin David Condic 2002-04-17 7:50 ` Ingo Marks 2002-04-17 12:01 ` Gary Scott 2002-04-17 13:29 ` Robert Dewar 2002-04-17 18:40 ` Ted Dennison 2002-04-18 15:02 ` Ted Dennison 2002-04-18 15:28 ` Marin David Condic 2002-04-17 13:29 ` Robert Dewar 2002-04-17 19:31 ` Chad R. Meiners 2002-04-18 14:15 ` Ted Dennison 2002-04-18 18:35 ` Paranoia about .NET (still): " Kent Paul Dolan 2002-04-18 21:43 ` Ted Dennison 2002-04-19 11:49 ` Robert Dewar 2002-04-19 23:34 ` Kent Paul Dolan 2002-04-19 23:14 ` rc211v 2002-04-20 3:00 ` Larry Kilgallen 2002-04-23 17:27 ` Wish List : Ada95 to FOX Warren W. Gay VE3WWG 2002-04-23 19:24 ` Stephen Leake 2002-04-23 19:30 ` Randy Brukardt 2002-04-26 22:06 ` rc211v 2002-04-24 0:00 ` Jeffrey Carter [not found] ` <3CC5997E.4 <3CC5F5B0.DBC6A6B8@boeing.com> 2002-04-24 8:47 ` Jean-Pierre Rosen 2002-04-24 15:15 ` Marin David Condic 2002-04-16 1:41 ` Rant! (was) Development process in the Ada community Richard Riehle 2002-04-16 19:40 ` [OT] MS vs Linux vs who in the student heart? (still mostly): " Kent Paul Dolan 2002-04-17 2:09 ` Adrian Hoe 2002-04-12 21:17 ` Wes Groleau 2002-04-13 0:23 ` Michael Erdmann 2002-04-13 22:07 ` Kent Paul Dolan 2002-04-14 8:01 ` Michael Erdmann 2002-04-14 10:24 ` Ingo Marks 2002-04-14 10:26 ` Ingo Marks 2002-04-14 11:41 ` Michael Erdmann 2002-04-14 12:48 ` Ingo Marks 2002-04-14 13:42 ` Michael Erdmann 2002-04-17 3:13 ` Richard Riehle 2002-04-17 13:19 ` Marin David Condic 2002-04-14 14:44 ` Gary Scott 2002-04-14 15:44 ` Michael Erdmann 2002-04-14 15:54 ` Larry Kilgallen 2002-04-14 16:33 ` Michael Erdmann 2002-04-14 21:46 ` Larry Kilgallen 2002-04-15 15:39 ` Marin David Condic 2002-04-16 16:34 ` Michael Erdmann 2002-04-16 17:28 ` Marin David Condic 2002-04-17 17:02 ` Michael Erdmann 2002-04-17 21:09 ` Kent Paul Dolan 2002-04-17 21:25 ` Darren New 2002-04-17 23:14 ` Kent Paul Dolan 2002-04-17 23:24 ` Darren New 2002-04-18 4:34 ` Eric G. Miller 2002-04-18 14:08 ` Ted Dennison 2002-04-18 18:34 ` Al Reynolds 2002-04-18 19:15 ` Marin David Condic 2002-04-18 20:03 ` Michael Erdmann 2002-04-18 20:45 ` Ingo Marks 2002-04-18 4:42 ` Kent Paul Dolan 2002-04-18 13:16 ` Marin David Condic 2002-04-18 13:54 ` Ted Dennison 2002-04-18 18:25 ` Kent Paul Dolan 2002-04-18 19:05 ` Marin David Condic 2002-04-18 21:41 ` Ted Dennison 2002-04-18 17:12 ` Pascal Obry 2002-04-15 15:11 ` Marin David Condic 2002-04-15 15:28 ` Marin David Condic 2002-04-16 16:53 ` Michael Erdmann 2002-04-16 17:49 ` Ingo Marks 2002-04-16 17:57 ` Marin David Condic 2002-04-18 14:04 ` Bill Tate 2002-04-18 14:45 ` Gary Scott 2002-04-18 20:12 ` Michael Erdmann 2002-04-18 20:09 ` Michael Erdmann 2002-04-13 0:59 ` Robert Dewar 2002-04-13 7:38 ` Michael Erdmann 2002-04-13 7:46 ` Michael Erdmann 2002-04-13 13:24 ` Larry Kilgallen 2002-04-13 16:01 ` Michael Erdmann 2002-04-13 17:18 ` Larry Kilgallen 2002-04-13 19:02 ` Michael Erdmann 2002-04-13 21:34 ` Larry Kilgallen 2002-04-14 8:28 ` Michael Erdmann 2002-04-14 16:00 ` Larry Kilgallen 2002-04-13 22:24 ` Kent Paul Dolan 2002-04-14 0:00 ` Larry Kilgallen 2002-04-15 3:03 ` Kent Paul Dolan 2002-04-14 3:04 ` Gary Scott 2002-04-15 3:00 ` Kent Paul Dolan 2002-04-16 2:37 ` Gary Scott 2002-04-14 8:51 ` Michael Erdmann 2002-04-14 9:52 ` Georg Bauhaus 2002-04-14 10:37 ` Ingo Marks 2002-04-14 11:50 ` Michael Erdmann 2002-04-14 20:41 ` tmoran 2002-04-15 14:45 ` Ted Dennison 2002-04-15 15:59 ` Kent Paul Dolan 2002-04-15 19:45 ` Randy Brukardt 2002-04-17 16:29 ` Ted Dennison 2002-04-17 22:30 ` Randy Brukardt 2002-04-21 5:56 ` David Botton 2002-04-21 7:13 ` tmoran 2002-04-21 21:14 ` David Botton 2002-04-22 21:46 ` Randy Brukardt 2002-04-23 4:47 ` GPL and the big picture (was Re: Development process in the Ada community) David Botton 2002-04-23 5:11 ` David Botton 2002-04-24 19:52 ` Randy Brukardt 2002-04-21 11:02 ` Development process in the Ada community Adrian Hoe 2002-04-21 21:21 ` David Botton 2002-04-15 22:02 ` tmoran 2002-04-17 16:55 ` Ted Dennison 2002-04-17 17:15 ` Stephen Leake 2002-04-17 18:01 ` Marin David Condic 2002-04-18 19:22 ` Stephen Leake 2002-04-21 5:35 ` David Botton 2002-04-21 5:34 ` David Botton 2002-04-18 5:12 ` Eric G. Miller 2002-04-18 13:31 ` Marin David Condic 2002-04-19 2:50 ` Eric G. Miller 2002-04-21 5:33 ` David Botton 2002-04-17 3:25 ` Richard Riehle 2002-04-17 5:07 ` Open Source: in conflict with the development process in the Ada community? Kent Paul Dolan 2002-04-17 10:14 ` Hyman Rosen 2002-04-17 13:20 ` Robert Dewar 2002-04-17 14:06 ` Marin David Condic 2002-04-19 14:20 ` Robert Dewar 2002-04-19 16:04 ` Marin David Condic 2002-04-22 13:44 ` Robert Dewar 2002-04-19 23:48 ` How Open Source software developers pay the bills, from within a successful such operation (was): " Kent Paul Dolan 2002-04-20 16:41 ` Robert Dewar 2002-04-20 18:08 ` Florian Weimer 2002-04-21 0:38 ` Robert Dewar 2002-04-21 1:44 ` Robert Dewar 2002-04-22 16:06 ` Marin David Condic 2002-04-23 12:44 ` Robert Dewar 2002-04-23 20:48 ` Marin David Condic 2002-04-23 23:50 ` Jeffrey Carter 2002-04-20 6:28 ` tmoran 2002-04-20 6:53 ` Florian Weimer 2002-04-20 11:53 ` Frank J. Lhota 2002-04-20 13:14 ` Florian Weimer 2002-04-20 14:50 ` Frank J. Lhota 2002-04-21 11:13 ` Ingo Marks 2002-04-21 21:23 ` Darren New 2002-04-22 13:42 ` Robert Dewar 2002-04-22 16:11 ` Marin David Condic 2002-04-20 16:07 ` Robert Dewar 2002-04-17 13:53 ` Development process in the Ada community Marin David Condic 2002-04-18 14:50 ` Stephen Leake 2002-04-18 15:43 ` Marin David Condic 2002-04-19 5:23 ` Simon Wright 2002-04-22 15:41 ` Marin David Condic 2002-04-17 17:58 ` Ted Dennison 2002-04-17 20:39 ` Stephen Leake 2002-04-17 20:54 ` Marin David Condic 2002-04-18 15:43 ` Ted Dennison 2002-04-17 22:18 ` Randy Brukardt 2002-04-18 15:39 ` Ted Dennison 2002-04-19 3:16 ` Randy Brukardt 2002-04-20 5:56 ` Ted Dennison 2002-04-20 16:30 ` Robert Dewar 2002-04-20 18:31 ` tmoran 2002-04-20 21:32 ` Ted Dennison 2002-04-22 0:30 ` Larry Kilgallen 2002-04-22 13:40 ` Robert Dewar 2002-04-22 14:27 ` Ted Dennison 2002-04-22 17:40 ` Ted Dennison 2002-04-22 17:48 ` Robert Dewar 2002-04-21 0:57 ` Robert Dewar 2002-04-21 5:23 ` tmoran 2002-04-21 15:59 ` Robert Dewar 2002-04-21 17:47 ` tmoran 2002-04-21 1:03 ` Robert Dewar 2002-04-21 9:07 ` Florian Weimer 2002-04-22 15:11 ` Marin David Condic 2002-04-23 15:38 ` Hyman Rosen 2002-04-23 16:03 ` Marin David Condic 2002-04-20 19:41 ` tmoran 2002-04-21 0:28 ` Richard Riehle 2002-04-21 0:33 ` Jason King 2002-04-22 15:22 ` Marin David Condic 2002-04-23 4:09 ` Randy Brukardt 2002-04-23 5:30 ` Simon Wright 2002-04-26 18:25 ` Randy Brukardt 2002-04-29 14:44 ` Shared generics Hyman Rosen 2002-04-29 19:47 ` Randy Brukardt 2002-04-23 13:28 ` Development process in the Ada community Marin David Condic 2002-04-20 21:16 ` Ted Dennison 2002-04-15 17:19 ` Marin David Condic 2002-04-17 18:09 ` Ted Dennison 2002-04-17 20:42 ` Marin David Condic 2002-04-16 8:29 ` Georg Bauhaus 2002-04-16 13:31 ` Marin David Condic 2002-04-16 17:46 ` tmoran 2002-04-17 3:34 ` Richard Riehle 2002-04-17 12:11 ` John English 2002-04-15 16:29 ` Michael Erdmann 2002-04-16 11:28 ` Martin Dowie 2002-04-16 13:38 ` Marin David Condic 2002-04-17 18:36 ` Ted Dennison 2002-04-17 20:14 ` Michael Erdmann 2002-04-18 16:00 ` Ted Dennison 2002-04-18 17:32 ` Hyman Rosen 2002-04-18 17:48 ` Grace and Maps (was Re: Development process in the Ada community) Marin David Condic 2002-04-19 13:29 ` Ted Dennison 2002-04-19 14:23 ` Marin David Condic 2002-04-20 13:42 ` Michael Erdmann 2002-04-20 19:54 ` Ted Dennison 2002-04-22 13:21 ` Marin David Condic 2002-04-20 19:12 ` Jeffrey Carter 2002-04-22 13:40 ` Marin David Condic 2002-04-20 19:49 ` Ted Dennison 2002-04-21 1:33 ` Ted Dennison 2002-04-21 5:49 ` Simon Wright 2002-04-21 8:55 ` Hyman Rosen 2002-04-21 18:49 ` Ted Dennison 2002-04-21 20:17 ` Ted Dennison 2002-04-22 0:36 ` Larry Kilgallen 2002-04-22 5:20 ` Simon Wright 2002-04-22 13:34 ` Ted Dennison 2002-04-22 16:16 ` Darren New 2002-04-22 22:31 ` Jeffrey Carter [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC48F34.5A474E0F@boeing.com> 2002-04-22 23:26 ` Darren New 2002-04-23 2:15 ` Jeffrey Carter 2002-04-23 4:57 ` Darren New 2002-04-23 7:10 ` Ole-Hjalmar Kristensen 2002-04-23 14:52 ` Stephen Leake 2002-04-23 19:08 ` Darren New 2002-04-24 12:22 ` Ole-Hjalmar Kristensen 2002-04-24 13:53 ` Darren New 2002-04-24 15:02 ` Ole-Hjalmar Kristensen 2002-04-24 15:25 ` Darren New 2002-04-24 15:39 ` Darren New 2002-04-24 19:32 ` Ole-Hjalmar Kristensen 2002-04-24 19:58 ` Ole-Hjalmar Kristensen 2002-04-24 19:14 ` Randy Brukardt 2002-04-24 20:01 ` Ole-Hjalmar Kristensen 2002-04-24 20:09 ` Darren New 2002-04-23 12:49 ` Alan Reynolds 2002-04-23 16:46 ` Darren New 2002-04-23 18:55 ` Alan Reynolds 2002-04-23 6:26 ` Kent Paul Dolan 2002-04-23 2:38 ` Ted Dennison 2002-04-23 18:57 ` Anders Gidenstam 2002-04-23 2:32 ` Ted Dennison 2002-04-23 23:46 ` Jeffrey Carter 2002-04-24 15:01 ` Darren New [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC4E9DA.E02BE0DA@san.rr.com> 2002-04-23 5:21 ` Simon Wright 2002-04-23 7:37 ` Ole-Hjalmar Kristensen 2002-04-23 22:33 ` David Bolen 2002-04-24 6:42 ` Jean-Marc Bourguet 2002-04-24 18:18 ` David Bolen 2002-04-25 7:40 ` Jean-Marc Bourguet 2002-04-25 22:23 ` David Bolen 2002-04-24 17:25 ` Jeffrey Carter [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com> 2002-04-24 17:48 ` Darren New 2002-04-24 23:12 ` Jeffrey Carter 2002-04-25 0:11 ` Darren New 2002-04-24 19:51 ` Ole-Hjalmar Kristensen [not found] ` <4519e058.0204220534.2eb33730@posting.go <3CC5B161.C719C5D8@san.rr.com> 2002-04-26 5:27 ` Simon Wright 2002-04-22 13:31 ` Ted Dennison 2002-04-22 14:15 ` Ole-Hjalmar Kristensen 2002-04-22 23:59 ` Larry Kilgallen 2002-04-22 14:37 ` Marin David Condic 2002-04-22 18:44 ` Michael Erdmann 2002-04-23 2:18 ` Ted Dennison 2002-04-23 14:46 ` Stephen Leake 2002-04-23 17:50 ` Warren W. Gay VE3WWG 2002-04-23 18:27 ` Marin David Condic 2002-04-24 14:20 ` John English 2002-04-24 15:05 ` Marin David Condic 2002-04-26 5:41 ` Simon Wright 2002-04-23 18:59 ` Stephen Leake 2002-04-23 19:13 ` Darren New 2002-04-23 19:26 ` Stephen Leake 2002-04-23 19:44 ` Darren New 2002-04-24 16:49 ` Stephen Leake 2002-04-24 17:10 ` Marin David Condic 2002-04-25 12:30 ` Georg Bauhaus 2002-04-25 13:35 ` Marin David Condic 2002-04-27 8:57 ` Ole-Hjalmar Kristensen 2002-04-29 14:57 ` Marin David Condic 2002-04-29 15:07 ` Hyman Rosen 2002-04-29 15:10 ` Darren New 2002-04-25 16:44 ` Darren New 2002-04-25 17:05 ` Marin David Condic 2002-04-26 16:31 ` Stephen Leake 2002-04-29 15:06 ` Marin David Condic 2002-04-30 17:16 ` Stephen Leake 2002-04-30 18:31 ` Marin David Condic 2002-04-26 17:16 ` Darren New 2002-04-26 17:53 ` Marin David Condic 2002-04-28 0:09 ` Darren New 2002-04-25 17:44 ` Stephen Leake [not found] ` <aa8ssi$qjr$1 <3CCD6197.9070905@mail.com> 2002-04-30 4:49 ` Simon Wright 2002-04-30 14:05 ` Ted Dennison 2002-04-30 14:32 ` Marin David Condic 2002-05-02 15:52 ` Ted Dennison 2002-05-01 22:17 ` Simon Wright 2002-04-24 17:25 ` Darren New 2002-04-24 19:36 ` Ole-Hjalmar Kristensen 2002-04-24 19:38 ` David Bolen 2002-04-24 21:57 ` Stephen Leake [not found] ` <uznzumd1p.fsf@gsfc.nasa.gov <aac468$3hh$1@nh.pace.co.uk> 2002-04-27 5:29 ` Simon Wright 2002-04-29 15:16 ` Marin David Condic 2002-04-27 14:37 ` Larry Kilgallen [not found] ` <uznzumd1p.fsf@gsfc.nasa.govOrganization: LJK Software <tW4Tz4KHL8Bt@eisner.encompasserve.org> 2002-04-29 15:26 ` Marin David Condic 2002-04-21 5:46 ` Simon Wright 2002-04-21 18:44 ` Ted Dennison 2002-04-22 14:31 ` Marin David Condic 2002-04-25 2:29 ` Brian Gaffney 2002-04-25 14:06 ` Marin David Condic 2002-04-20 0:42 ` David Bolen 2002-04-22 2:57 ` Robert Dewar 2002-04-22 22:58 ` David Bolen 2002-04-18 18:50 ` [OT] Focusing on tools you know in programming libraries. (was): Development process in the Ada community Kent Paul Dolan 2002-04-18 18:57 ` Data!, was " tmoran 2002-04-18 20:51 ` Ted Dennison 2002-04-18 21:28 ` Gary Scott 2002-04-18 22:10 ` Pascal Obry 2002-04-18 23:08 ` Darren New 2002-04-19 13:29 ` Marin David Condic 2002-04-20 3:04 ` Larry Kilgallen 2002-04-18 22:28 ` Jeffrey Carter 2002-04-19 10:07 ` Georg Bauhaus 2002-04-19 10:13 ` Georg Bauhaus 2002-04-20 5:12 ` Simon Wright 2002-04-19 11:00 ` John English 2002-04-19 16:45 ` Ingo Marks 2002-04-18 20:28 ` Michael Erdmann 2002-04-17 23:31 ` martin.m.dowie 2002-04-17 18:04 ` Outside view (still): " Kent Paul Dolan 2002-04-17 19:10 ` Michael Erdmann 2002-04-17 22:15 ` Robert Dewar 2002-04-17 23:20 ` Kent Paul Dolan 2002-04-18 1:19 ` Pat Rogers 2002-04-18 4:53 ` Kent Paul Dolan 2002-04-18 5:40 ` Simon Wright 2002-04-19 13:22 ` Ted Dennison 2002-04-18 8:25 ` Dmitry A. Kazakov 2002-04-18 2:12 ` Larry Kilgallen 2002-04-18 5:03 ` Kent Paul Dolan 2002-04-18 12:50 ` Larry Kilgallen 2002-04-18 14:34 ` Gary Scott 2002-04-18 13:43 ` Marin David Condic 2002-04-18 4:21 ` Richard Riehle 2002-04-18 4:59 ` Kent Paul Dolan 2002-04-18 14:44 ` new Ada language features needed? Stephen Leake 2002-04-18 14:07 ` Outside view (still): Development process in the Ada community Marin David Condic 2002-04-19 17:39 ` Michael Erdmann 2002-04-19 18:58 ` Marin David Condic 2002-04-20 17:35 ` Michael Erdmann 2002-04-22 17:57 ` Robert Dewar 2002-04-22 19:46 ` Michael Erdmann 2002-04-22 20:24 ` Florian Weimer 2002-04-23 4:54 ` Michael Erdmann 2002-04-23 20:37 ` Florian Weimer 2002-04-25 17:29 ` Michael Erdmann 2002-04-27 8:26 ` Michael Erdmann 2002-04-27 23:54 ` Robert Dewar 2002-04-28 14:18 ` Michael Erdmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox