* RE: ADA Popularity Discussion Request @ 2004-09-01 12:18 Lionel.DRAGHI 0 siblings, 0 replies; 387+ messages in thread From: Lionel.DRAGHI @ 2004-09-01 12:18 UTC (permalink / raw) To: comp.lang.ada | -----Message d'origine----- | De: Ole-Hjalmar Kristensen ... | Yes, I agree. However maybe there is less resistance to doing | restructuring of the system when it is needed with agile methods? I think there is less resistance: 1 - because of the continuously up to date regression test suite, changes are less risky, 2 - and also because it's well known for the management that in agile method, 5 to 10% of the time is dedicated to refactoring, so you don't feel unconfortable announcing that you are back working on an existing stuff. Restructuring is now accepted and not considered more or less like a flaw in your previous work. Hopefully, none of those point (complete regression testing and smart managment) is specific to Agile method. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* RE: ADA Popularity Discussion Request @ 2004-08-31 17:58 Lionel.DRAGHI 2004-09-01 7:21 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 387+ messages in thread From: Lionel.DRAGHI @ 2004-08-31 17:58 UTC (permalink / raw) To: comp.lang.ada | -----Message d'origine----- | De: kevin.cline@gmail.com [mailto:kevin.cline@gmail.com] ... | | The efficacy of much pre-code activity is debatable. Many | organizations have had great success with more agile methods of | minimal up-front design followed by test-driven development and | continuous refactoring. Test-driven development includes a part of "pre-code activities". In fact, test-driven development is an odd name, because it's as much about design than about test. As you said, even wit agile methods, there is still an up-front design to do. Refactoring may let's people thinks that starting almost without design is less risky with Agile methods, but that's plain wrong. No one can afford periodically refactoring the whole project because of a poor architecture. Settling down the initial design requires experienced and smart guys, whatever is the method. So, I don't think there is less time on design and more time on coding in agile methods. The time is just distributed in a different way. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 17:58 Lionel.DRAGHI @ 2004-09-01 7:21 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 387+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-01 7:21 UTC (permalink / raw) >>>>> "LD" == Lionel DRAGHI <Lionel.DRAGHI@fr.thalesgroup.com> writes: LD> | -----Message d'origine----- LD> | De: kevin.cline@gmail.com [mailto:kevin.cline@gmail.com] LD> ... LD> | LD> | The efficacy of much pre-code activity is debatable. Many LD> | organizations have had great success with more agile methods of LD> | minimal up-front design followed by test-driven development and LD> | continuous refactoring. LD> Test-driven development includes a part of "pre-code activities". In fact, LD> test-driven development is an odd name, because it's as much about design LD> than about test. LD> As you said, even wit agile methods, there is still an up-front design to LD> do. LD> Refactoring may let's people thinks that starting almost without design is LD> less risky with Agile methods, but that's plain wrong. LD> No one can afford periodically refactoring the whole project because of a LD> poor architecture. LD> Settling down the initial design requires experienced and smart guys, LD> whatever is the method. Yes, I agree. However maybe there is less resistance to doing restructuring of the system when it is needed with agile methods? This could be a good thing, in many large projects you tend to get stuck with the initial design when the system evolves. Sometimes you would be better off with a major redesign, but it is often put off. On the other hand, I cannot really see how test-driven development and continuous refactoring would work on a 2 million LOC soft real time distributed RDBMS. Usually, there just isn't a substitute for good design. LD> So, I don't think there is less time on design and more time on coding in LD> agile methods. The time is just distributed in a different way. LD> -- LD> Lionel Draghi -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request @ 2004-08-26 2:08 Robert C. Leif 0 siblings, 0 replies; 387+ messages in thread From: Robert C. Leif @ 2004-08-26 2:08 UTC (permalink / raw) To: Comp. Lang. Ada The real reason for Ada's perceived and probably real lack of popularity is the lack of sales and marketing effort or resources. For instance, the Real-Time & Embedded Computing Conferences will be in many cities including San Diego. How many companies are selling Ada or SPARK? Is anyone providing a seminar on Ravenscar or embedded systems in Ada? How many Ada companies have exhibited at these meetings this year? Green Hills exhibits. However, I have never seen them say anything other than they have Ada. I am usually the one who asks. I might add that the Ada companies still do not have compilers for Windows CE or XP embedded. A commercially supported complete version of A# would be perfect for these operating systems. Bob Leif --------------------------------------------------------------- THE ROLE OF AN OPERATING SYSTEM AND NETWORK STACK IN DESIGNED HIGH RELIABILITY NETWORKED DEVICES presented by Green Hills Software Join us for a technical discussion on the role of an operating system and network stack in designed high reliability networked devices. We'll discuss networking requirements as well as implementation details to provide performance, uptime, and response time guarantees for embedded systems. --------------------------------------------- "The Real-Time & Embedded Computing Conferences (RTECC) are a unique, one-day event showcasing the newest products and latest information from industry leaders." http://www.rtecc.com Registration is now open for the following locations: San Diego, CA August 31, 2004 Long Beach, CA September 2, 2004 Helsinki, Finland 14 September 2004 Toronto, Ontario September 17, 2004 Ottawa, Ontario September 21, 2004 Montreal, Quebec September 23, 2004 Gothenburg, Sweden 28 September 2004 Oslo, Norway 30 September 2004 Reston, VA October 5, 2004 Patuxent River, MD October 7, 2004 Toulouse, France 26 October 2004 Bristol, United Kingdom 28 October 2004 Eindhoven, The Netherlands 4 November 2004 Vancouver, BC November 16, 2004 Seattle, WA November 18, 2004 ^ permalink raw reply [flat|nested] 387+ messages in thread
* ADA Popularity Discussion Request @ 2004-08-11 13:56 Chris Humphries 2004-08-11 14:14 ` Hyman Rosen ` (6 more replies) 0 siblings, 7 replies; 387+ messages in thread From: Chris Humphries @ 2004-08-11 13:56 UTC (permalink / raw) Hello, Would like to open up the newsgroup for discussion of why ADA is not as popular as (of now me learning it) to it is not as popular as other languages (Perl, Java, C++, C#, C). I can understand why C is popular, UNIX and all the tools for it and most of everything that runs the internet services (smtp, http [apache mostly according to netcraft.com], bind). Perl (well I use it at work, for legacy reasons of taking over code) I can understand due to it just being so easy to get something done fast in (and I must say that the regex abilities are definitely something that you can get used to quickly, heh. CPAN is also a nice feature, tons of modules/libraries to use for most everything one command line away. Java and C++ got huge during the OOP boom of the 90's, and now almost every Computer Science student in college has taken at least one of those languages. Java does have some nice OO abilities and there are a ton of libraries for it. C++ has some OO-ish abilities, yet can be compiled and also has a ton of libraries. Yet as I grew in my programming experience and abilities, I learned that most of my time was spent updating and fixing code. C/C++ took a lot of time to develop in, and I didn't like having to worry about memory management and use my gdb-fu to figure out why something did not work. Perl is somewhat better, though it is mostly just if syntax doesn't match up right. If it is quick and dirty, Perl excels. Granted, I do have a written from bottom up programs we now use in the company here as a core part of daily life and it is in nothing by Perl. Java is kinda nice, but honestly the dependency of the VM is nice in concept, but a pain in real life. You need to make sure that your program either is portable to several versions of virtual machines or you have to bundle your own (for client apps). Java is just too slow (I can not afford the hardware or even justify it's use of hardware money to make it's speed comparable with other "free" alternatives) for cgi based applications, though the whole application server thing with db connection pooling is cool. Python is nice too, and I suppose no real reason to not use it. I have coded python since 1.5 and early Zope releases. I just would like to not code in it anymore, though reason are because I am sick of it. So, why is ADA not as popular as the above languages to the world (well especially opensource developers) outside of dod and defense contractors and banks? It seems like an extremely powerful and awesome language, and it is just so easy to look at the code and tell what is going on and what is what. It can be OO and can run tasks concurrently. It's runtime and compile checking is awesome. GNAT is free and available to all to use. So what is stopping ADA from being a language everyone knows? Is it just viewed as old and arcane like COBOL and Fortran (no offense to those that know these languages better than me)? Is it just lacking some killer apps? Is it because most ADA is closed source, so there are just not libraries out there (like a SSH library)? Thanks, Chris ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries @ 2004-08-11 14:14 ` Hyman Rosen 2004-08-11 15:39 ` sk 2004-08-11 15:54 ` Marc A. Criley 2004-08-11 15:45 ` Jerry Petrey ` (5 subsequent siblings) 6 siblings, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-11 14:14 UTC (permalink / raw) Chris Humphries wrote: > Would like to open up the newsgroup for discussion of why > ADA is not as popular as (of now me learning it) to it is > not as popular as other languages (Perl, Java, C++, C#, C). Aagh! Run for your lives! :-) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 14:14 ` Hyman Rosen @ 2004-08-11 15:39 ` sk 2004-08-11 15:54 ` Marc A. Criley 1 sibling, 0 replies; 387+ messages in thread From: sk @ 2004-08-11 15:39 UTC (permalink / raw) To: comp.lang.ada > Aagh! Run for your lives! :-) How about we just shoot the messanger ? :-) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 14:14 ` Hyman Rosen 2004-08-11 15:39 ` sk @ 2004-08-11 15:54 ` Marc A. Criley 2004-08-12 4:54 ` Larry Kilgallen 2004-08-13 2:29 ` Brian May 1 sibling, 2 replies; 387+ messages in thread From: Marc A. Criley @ 2004-08-11 15:54 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:1092233689.719755@master.nyc.kbcfp.com... > Chris Humphries wrote: > > Would like to open up the newsgroup for discussion of why > > ADA is not as popular as (of now me learning it) to it is > > not as popular as other languages (Perl, Java, C++, C#, C). > > Aagh! Run for your lives! :-) Oh, what the hell... :-) My take on why the Ada language itself (regardless of availability of tools and libraries and such) isn't as popular among programmers as other languages: Every programmer thinks they're better than average--half of them are wrong. Most programmers think they're much better than average--most are not. Ada's enforcement of strong typing and runtime checks points out when a programmer has made a mistake, whether as a result of requirements, design, or coding error. (Of course no one is suggesting that Ada would catch all requirements or design errors--that's a ridiculous mischaracterization--but when errant reqs or design lead to a particular implementation, internal contradictions may result in type conflicts or constraint errors.) Over the years I've heard much cursing from coworkers about how they can't get their Ada program to compile, or it just keeps raising these exceptions when they run it, and they don't have anything like that to deal with when coding in C or C++. Here's a clue: the problem isn't with the language! Fix your code! So Ada has the "unfortunate" characteristic of strictly enforcing what a programmer codes, and therefore when errors are present there's no sliding by with out-of-range data or quiet ignoring of inconsistent interfaces or arguments. The language hits you over the head with them, and makes you deal with your errors right now. Which can sometimes be a humbling experience. Marc A. Criley McKae Technologies "The Efficient Production of High Quality Software" ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 15:54 ` Marc A. Criley @ 2004-08-12 4:54 ` Larry Kilgallen 2004-08-13 2:29 ` Brian May 1 sibling, 0 replies; 387+ messages in thread From: Larry Kilgallen @ 2004-08-12 4:54 UTC (permalink / raw) In article <2nutq5F4sdqqU1@uni-berlin.de>, "Marc A. Criley" <mcNOSPAM@mckae.com> writes: > "Hyman Rosen" <hyrosen@mail.com> wrote in message > news:1092233689.719755@master.nyc.kbcfp.com... >> Chris Humphries wrote: >> > Would like to open up the newsgroup for discussion of why >> > ADA is not as popular as (of now me learning it) to it is >> > not as popular as other languages (Perl, Java, C++, C#, C). >> >> Aagh! Run for your lives! :-) > > Oh, what the hell... :-) > > My take on why the Ada language itself (regardless of availability of tools > and libraries and such) isn't as popular among programmers as other > languages: > > Every programmer thinks they're better than average--half of them are wrong. > > Most programmers think they're much better than average--most are not. That is a good concept. I think a more terse presentation would be: Disuse of Ada is because it appeals only to humble programmers. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 15:54 ` Marc A. Criley 2004-08-12 4:54 ` Larry Kilgallen @ 2004-08-13 2:29 ` Brian May 2004-08-13 5:27 ` Ada " Puckdropper ` (2 more replies) 1 sibling, 3 replies; 387+ messages in thread From: Brian May @ 2004-08-13 2:29 UTC (permalink / raw) >>>>> "Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes: Marc> Ada's enforcement of strong typing and runtime checks points Marc> out when a programmer has made a mistake, whether as a Marc> result of requirements, design, or coding error. (Of course Marc> no one is suggesting that Ada would catch all requirements Marc> or design errors--that's a ridiculous Marc> mischaracterization--but when errant reqs or design lead to Marc> a particular implementation, internal contradictions may Marc> result in type conflicts or constraint errors.) Ada has a lot of rules which you have to comply with when programming. I suspect some programmers find these rules obscure, weird and limiting[1]. These people prefer the freedom in other languages like Perl where there is infinity+1 ways of doing the same thing. Personally, if I make a mistake, I want to find out sooner rather then later, and this requires good compiler time checking. Even if the program is not a mission critical program. Ada is the language I know with the highest level of checks at compile time. There is the argument that languages like PHP are best for quick&dirty prototypes. The counter argument is that these quick&dirty prototypes often evolve into the one complicated mess of code that everyone relies on. I can't understand the trend in the other direction towards languages like PHP, if you make a typo in a function name for instance, you won't realize until that like of code is executed, and even then you might miss the error message (for instance if it is not on screen). Worst case scenario I have had is if you accidently change low-usage code (e.g. error handling) unintentionally (e.g. by typing in wrong window), you may not realize (although a good version control system may help, if you check every commit) until months later. You have no need to retest this code either, it was working last time... I have also seen cases when the programmer (myself) included have considered the C compiler broken because it says undefined variable when it looks identical, when in actual fact it is mistyped - the same thing is much more confusing if you just get random results instead of an error. Examples: "OK" instead of "Ok" and "Saved_XYZ" vs "Save_XYZ". Then in another extreme, while the SPIM program (MIPS emulator) is very fussy about program code, on certain errors it won't generate any messages, but instead ignore all code past that point. Any symbols defined beyond that point will be flagged as undefined. Now this is pure evil... Ada is also seen as a procedural language as opposed to an object orientated language. I don't know why, I believe it has all the key features of an OO language, eg. inheritance, run-time binding to functions, etc. Sure it doesn't have the "object->function" syntax, but none of my notes on OO programming say this is required. As stated elsewhere, Ada2005 will be even better. Notes: [1] It is interesting to note that the same arguments of "rules" vs. "flexibility" don't only apply to programming. For instance, in aviation, I have heard some pilots prefer flying in USA compared with Australia because airspace rules are more flexible. At the same time, there are air traffic controllers in USA who complain that the rules are too flexible, and this limits safety. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: Ada Popularity Discussion Request 2004-08-13 2:29 ` Brian May @ 2004-08-13 5:27 ` Puckdropper 2004-08-21 3:41 ` ADA " Wes Groleau 2004-08-26 21:11 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 387+ messages in thread From: Puckdropper @ 2004-08-13 5:27 UTC (permalink / raw) I'm a sophomore in a Computer Science degree. When I found out last year that we were going to be using Ada to program, I was surprised to find it was still in use. I had only read about it in some old books. I thought everyone used C except a select few who still hung on to BASIC (like me) or some other old language. From someone who's learning Ada, I'd like to suggest a few problems I've had so far in learning it: 1) Lack of good tutorial-type documentation. (I can't find it if it exists. Michael Feldman likes to do about 5 things per example in his books, and I don't want to do all 5, just one. It's hard to extract the data from there.) 2) Poor explanations of what something does. I'm looking for a sentence to a paragraph discribing what a package does, not what it includes. An example of what I want is: "AdaGraph is a package that allows for graphical programming and basic mouse control. You are limited to only 16 colors." I suppose what would help Ada tremendously is doing something to be picked up by the news stations. Unfortunately, news stations tend to want to warn you more than inform you. Puckdropper -- www.uncreativelabs.net Old computers are getting to be a lost art. Here at Uncreative Labs, we still enjoy using the old computers. Sometimes we want to see how far a particular system can go, other times we use a stock system to remind ourselves of what we once had. To email me directly, send a message to puckdropper (at) fastmail.fm ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-13 2:29 ` Brian May 2004-08-13 5:27 ` Ada " Puckdropper @ 2004-08-21 3:41 ` Wes Groleau 2004-08-26 21:11 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 387+ messages in thread From: Wes Groleau @ 2004-08-21 3:41 UTC (permalink / raw) Brian May wrote: > There is the argument that languages like PHP are best for quick&dirty > prototypes. The counter argument is that these quick&dirty prototypes > often evolve into the one complicated mess of code that everyone > relies on.... ... but no one understands. :-) > I have also seen cases when the programmer (myself) included have > considered the C compiler broken because it says undefined variable > when it looks identical, when in actual fact it is mistyped - the same > thing is much more confusing if you just get random results instead of > an error. Examples: "OK" instead of "Ok" and "Saved_XYZ" vs > "Save_XYZ". I just love the times where the warning (unless, as usual, warnings are turned off) says "this is undefined, so I'll just make it an int" -- Wes Groleau Expert, n.: Someone who comes from out of town and shows slides. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-13 2:29 ` Brian May 2004-08-13 5:27 ` Ada " Puckdropper 2004-08-21 3:41 ` ADA " Wes Groleau @ 2004-08-26 21:11 ` Warren W. Gay VE3WWG 2004-08-27 10:30 ` Georg Bauhaus 2004-09-10 23:12 ` Kevin Cline 2 siblings, 2 replies; 387+ messages in thread From: Warren W. Gay VE3WWG @ 2004-08-26 21:11 UTC (permalink / raw) Brian May wrote: >>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes: > Marc> Ada's enforcement of strong typing and runtime checks points > Marc> out when a programmer has made a mistake, whether as a > Marc> result of requirements, design, or coding error. (Of course > Marc> no one is suggesting that Ada would catch all requirements > Marc> or design errors--that's a ridiculous > Marc> mischaracterization--but when errant reqs or design lead to > Marc> a particular implementation, internal contradictions may > Marc> result in type conflicts or constraint errors.) > > Ada has a lot of rules which you have to comply with when > programming. I suspect some programmers find these rules obscure, > weird and limiting[1]. These people prefer the freedom in other > languages like Perl where there is infinity+1 ways of doing the same > thing. > > Personally, if I make a mistake, I want to find out sooner rather then > later, and this requires good compiler time checking. Even if the > program is not a mission critical program. Ada is the language I know > with the highest level of checks at compile time. Agree completely. > There is the argument that languages like PHP are best for quick&dirty > prototypes. The counter argument is that these quick&dirty prototypes > often evolve into the one complicated mess of code that everyone > relies on. This reminds me of Perl. I have always maintained that Perl has its place, but not in "production". > I can't understand the trend in the other direction towards languages > like PHP, if you make a typo in a function name for instance, you > won't realize until that like of code is executed, and even then you > might miss the error message (for instance if it is not on screen). Postscript is very much like this (nice language for what it does). You write out your code and you execute it. Ie. you go from writing the code straight into debugging. There is not even a precompile step (like BASIC). And if your testing doesn't cover all of the cases (path coverage), then surprises lurk for you on some future black Monday. I have to say that for most applications, I would rather have as much static analysis done up front as possible. This substantially reduces the need for testing for non-mission critical things. With dynamic languages (like Postscript for example), you need to test everything to have any confidence at all in the code. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:11 ` Warren W. Gay VE3WWG @ 2004-08-27 10:30 ` Georg Bauhaus 2004-08-31 16:34 ` Warren W. Gay VE3WWG 2004-09-10 23:12 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-27 10:30 UTC (permalink / raw) Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote: : With dynamic languages (like Postscript for : example), you need to test everything to have any confidence : at all in the code. I had thought that even with dynamic languages you can show that a given algorithm is correct. When the language is welldefined. Can the following Postscript program fail? %! newpath 10 10 moveto 100 0 rlineto 0 100 rlineto 100 neg 0 rlineto closepath stroke showpage -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 10:30 ` Georg Bauhaus @ 2004-08-31 16:34 ` Warren W. Gay VE3WWG 2004-08-31 17:48 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Warren W. Gay VE3WWG @ 2004-08-31 16:34 UTC (permalink / raw) Georg Bauhaus wrote: > Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote: > > : With dynamic languages (like Postscript for > : example), you need to test everything to have any confidence > : at all in the code. > > I had thought that even with dynamic languages you can > show that a given algorithm is correct. When the language > is welldefined. Can the following Postscript program fail? > > %! > newpath > 10 10 moveto > 100 0 rlineto > 0 100 rlineto > 100 neg 0 rlineto > closepath > stroke > showpage It can, if the code executing prior to it has redefined "neg" for example. This is all beside the point, because anyone can produce small examples. They don't prove anything in general. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 16:34 ` Warren W. Gay VE3WWG @ 2004-08-31 17:48 ` Georg Bauhaus 2004-09-01 16:58 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-31 17:48 UTC (permalink / raw) Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote: : It can, if the code executing prior to it has : redefined "neg" for example. This is all beside : the point, because anyone can produce small : examples. They don't prove anything in general. OK, if the meaning of predefined identifiers if changed, there is nothing to prove. OTOH, there is nothing to be tested in such a language, because you could as well assume that the value of an expression is a function of time... -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 17:48 ` Georg Bauhaus @ 2004-09-01 16:58 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 387+ messages in thread From: Warren W. Gay VE3WWG @ 2004-09-01 16:58 UTC (permalink / raw) Georg Bauhaus wrote: > Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote: > : It can, if the code executing prior to it has > : redefined "neg" for example. This is all beside > : the point, because anyone can produce small > : examples. They don't prove anything in general. > > OK, if the meaning of predefined identifiers if changed, > there is nothing to prove. OTOH, there is nothing to be > tested in such a language, because you could as well assume > that the value of an expression is a function of time... > > -- Georg Exactly - welcome to dynamic languages! ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:11 ` Warren W. Gay VE3WWG 2004-08-27 10:30 ` Georg Bauhaus @ 2004-09-10 23:12 ` Kevin Cline 2004-09-12 16:50 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-10 23:12 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<5ksXc.22738$_H5.696424@news20.bellglobal.com>... > Brian May wrote: > >>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes: > > Marc> Ada's enforcement of strong typing and runtime checks points > > Marc> out when a programmer has made a mistake, whether as a > > Marc> result of requirements, design, or coding error. (Of course > > Marc> no one is suggesting that Ada would catch all requirements > > Marc> or design errors--that's a ridiculous > > Marc> mischaracterization--but when errant reqs or design lead to > > Marc> a particular implementation, internal contradictions may > > Marc> result in type conflicts or constraint errors.) > > > > Ada has a lot of rules which you have to comply with when > > programming. I suspect some programmers find these rules obscure, > > weird and limiting[1]. These people prefer the freedom in other > > languages like Perl where there is infinity+1 ways of doing the same > > thing. > > > > Personally, if I make a mistake, I want to find out sooner rather then > > later, and this requires good compiler time checking. Even if the > > program is not a mission critical program. Ada is the language I know > > with the highest level of checks at compile time. > > Agree completely. > > > There is the argument that languages like PHP are best for quick&dirty > > prototypes. The counter argument is that these quick&dirty prototypes > > often evolve into the one complicated mess of code that everyone > > relies on. > > This reminds me of Perl. I have always maintained that Perl > has its place, but not in "production". But there are millions of lines of Perl serving web pages reliably every day. When I was at DSC we used Tcl/Tk to build production GUIs for telecom switch control, and found it about ten times more productive than building Motif GUIs in C++. Customers were very happy because we could redesign the GUI to meet their needs interactively. No compiling or linking -- just make the change and go. Reducing line count by programming at a higher level is an effective way to reduce the bug count. It's possible to find libraries for C++ or Ada that will provide the built-in features of Perl, but relatively few development projects bother to use them. Instead programmers laboriously and incorrectly hand-code things like string manipulations that could be done correctly in Perl in a few seconds. > > I can't understand the trend in the other direction towards languages > > like PHP, if you make a typo in a function name for instance, you > > won't realize until that like of code is executed, and even then you > > might miss the error message (for instance if it is not on screen). If your Ada code raises Constraint_Error, you won't realize that until you execute it. I don't see the big difference between a Constraint_Error and a missing function error. Since the compiler can't catch all the errors, I still have to test. And if I'm going to test anyway, trivial errors like misspelled function names will be discovered pretty quickly. > I have to say that for most applications, I would rather > have as much static analysis done up front as possible. This > substantially reduces the need for testing for non-mission > critical things. I'm skeptical of this argument. Are you saying that you have no problems delivering code that has never been tested? I have learned to write the tests first just to make sure that I know exactly what I'm trying to do before I start doing it. And since every line of code is tested, static analysis doesn't add much. If it slows down the test execution so that I have to wait idle for more than a few secondes, then it breaks the flow and is more of a distraction than it's worth. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 23:12 ` Kevin Cline @ 2004-09-12 16:50 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-12 16:50 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > "Warren W. Gay VE3WWG" > > Brian May wrote: > > >>>>>>"Marc" == Marc A Criley <mcNOSPAM@mckae.com> writes: > > > > I can't understand the trend in the other direction towards languages > > > like PHP, if you make a typo in a function name for instance, you > > > won't realize until that like of code is executed, and even then you > > > might miss the error message (for instance if it is not on screen). > > If your Ada code raises Constraint_Error, you won't realize that until > you execute it. I don't see the big difference between a > Constraint_Error and a missing function error. Since the compiler > can't catch all the errors, I still have to test. And if I'm going to > test anyway, trivial errors like misspelled function names will be > discovered pretty quickly. In practice, I have found Kevin's position here to be exactly right. Typos are found immediately. The real problem here is that static typing (certainly as found in non formal type systems like Ada/C++/Eiffel/etc.) solves a problem that is actually fairly trivial. Note: The _solution_ is highly _non_ trivial. > > I have to say that for most applications, I would rather > > have as much static analysis done up front as possible. This > > substantially reduces the need for testing for non-mission > > critical things. > > I'm skeptical of this argument. Are you saying that you have no > problems delivering code that has never been tested? I would go beyond Kevin here and claim that the proposition (as much static analysis up front for most applications) is exactly backward. In nearly all applications this basically becomes a recipe for "naval gazing". /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries 2004-08-11 14:14 ` Hyman Rosen @ 2004-08-11 15:45 ` Jerry Petrey 2004-08-11 15:55 ` Hyman Rosen 2004-08-11 17:14 ` Nick Roberts ` (4 subsequent siblings) 6 siblings, 1 reply; 387+ messages in thread From: Jerry Petrey @ 2004-08-11 15:45 UTC (permalink / raw) Chris Humphries wrote: > Hello, > > Would like to open up the newsgroup for discussion of why > ADA is not as popular as (of now me learning it) to it is > not as popular as other languages (Perl, Java, C++, C#, C). > > Thanks, > Chris ADA is very popular. Almost all dentists are members of it. Now if you're talking about Ada, the language ... that's another story. Jerry -- --------------------------------------------------------------------- -- Jerry Petrey - Senior Principal Systems Engineer -- Navigation (GPS/INS), Guidance, & Control -- Raytheon Missile Systems - Member Team Ada & Team Forth -- NOTE: please perform appendectomy on email address before replying --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 15:45 ` Jerry Petrey @ 2004-08-11 15:55 ` Hyman Rosen 2004-08-11 16:54 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-08-11 15:55 UTC (permalink / raw) Jerry Petrey wrote: > ADA is very popular. Almost all dentists are members of it. > Now if you're talking about Ada, the language ... that's another story. Oh no! It's starting! I'm scared, mommy! ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 15:55 ` Hyman Rosen @ 2004-08-11 16:54 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-11 16:54 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: : Jerry Petrey wrote: :> ADA is very popular. Almost all dentists are members of it. :> Now if you're talking about Ada, the language ... that's another story. : : Oh no! It's starting! I'm scared, mommy! How is Michael Jackson, BTW? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries 2004-08-11 14:14 ` Hyman Rosen 2004-08-11 15:45 ` Jerry Petrey @ 2004-08-11 17:14 ` Nick Roberts 2004-08-11 18:00 ` Hyman Rosen ` (2 more replies) 2004-08-11 18:58 ` fabio de francesco ` (3 subsequent siblings) 6 siblings, 3 replies; 387+ messages in thread From: Nick Roberts @ 2004-08-11 17:14 UTC (permalink / raw) On 11 Aug 2004 06:56:17 -0700, Chris Humphries <chris@unixfu.net> wrote: > Would like to open up the newsgroup for discussion of why > ADA is not as popular as (of now me learning it) to it is > not as popular as other languages (Perl, Java, C++, C#, C). I'm pretty sure the main reasons are: that there has never been a (really) big corporation backing Ada, in the same way that many of the languages you mention have had; that Ada is not a language suited for or much liked by many non-professional programmers. Microsoft have a huge historical investment in Basic (VB), C (in which Windows was written (it was nearly Pascal)), C++ (in which they hedged the future of their C codebase). They have poured vast resources into developing and marketing tools supporting these languages. The latest big thing from Microsoft is C#, and they have promoted it relentlessly. Sun's fortunes were founded on Unix, so they have a huge vested interest in the C language. They have done much to promote both. Lately, Sun have placed all their faith in Java, and they have poured vast resources into popularising it. Languages such as Javascript, Perl, PHP, Python, Ruby, and many others have gained popularity with non-professional programmers, who are several orders of magnitude greater in number than the professionals, thus boosting the following of these languages to such large numbers as to create their own unstoppable momentum. This is not to denegrate non-pros, by the way; some of these languages are now used by pros, for applications they are suited to. It's not to dengrate the languages, either. I think Python and Ruby are both excellent designs. > So, why is ADA not as popular as the above languages to the > world (well especially opensource developers) outside of dod and > defense contractors and banks? It seems like an extremely powerful > and awesome language, Ada isn't really an awesome or extremely powerful language. It has many advantages over many other compiled imperative languages, including C (and probably also C++, C#, and Java). It also has its fair share of limitations and annoying quirks. > and it is just so easy to look at the code and tell what is going > on and what is what. If the program is well written. C code /can/ be easy to look at etc., but it tends not to be in practice. Honestly, this is probably because most C code is written by bad programmers, whereas most Ada code is not. I have seen superb C code (often written by a non-pro, what is more). Ada does /help/ the programmer to write good code. > It can be OO Albeit a somewhat limited form of OO :-) Actually, Ada 2005 promises to be much better in this area. > and can run tasks concurrently. I think this is one of Ada's greatest strengths. > It's runtime and compile checking is awesome. It's good, and certainly one of the biggest practical advantages of the language. However, there are many other languages that have good checking (C and C++ are notably not among them). > GNAT is free and available to all to use. Yes, and GNAT is one of the language's biggest assets. It is of very high quality, and is used in many commercial applications. Programming languages are very much a case of horses for courses, and there are many, many courses that Python and other languages are far better suited to than Ada. For /some/ kinds of application (typically embedded, systems, and safety-critical software) Ada is one of the classiest acts in town. I am currently considering Python or Ruby to write an XML application, in preference to Ada, because it will probably be a lot easier to write this kind of application in Python or Ruby, both because of the languages themselves, and also because of the superb utility libraries available for them. Now, where did I put that asbestos suit? -- Nick Roberts ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 17:14 ` Nick Roberts @ 2004-08-11 18:00 ` Hyman Rosen 2004-08-12 11:48 ` Marin David Condic 2004-08-26 8:07 ` Adrian Hoe 2 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-11 18:00 UTC (permalink / raw) Nick Roberts wrote: > The latest big thing from Microsoft is C#, > and they have promoted it relentlessly. They are also working on an implementation and ISO standard for C++/CLI, which is an extension of C++ to support garbage collection and the CLI data objects with minimal intrusiveness into C++ standard-conforming code. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 17:14 ` Nick Roberts 2004-08-11 18:00 ` Hyman Rosen @ 2004-08-12 11:48 ` Marin David Condic 2004-08-26 8:07 ` Adrian Hoe 2 siblings, 0 replies; 387+ messages in thread From: Marin David Condic @ 2004-08-12 11:48 UTC (permalink / raw) In fairness, the DoD actually *did* throw a lot of money at Ada. IMHO, it just didn't get spent effectively. Not much was done to "Market" the language or "Prime The Pump" by getting good, inexpensive compilers out into the hands of lots of programmers. Gnat was a good example of how that can help, but it came along rather late in the day and by then, opinions had been formed and other things had come along that had captured the market better, so it wasn't as effective as it might have been. (Imagine what the world would have been like if back in 1983, the DoD had funded a free compiler of descent quality that would run on a PC or some of the other popular hardware of the day. There wasn't anything quite like that back then and maybe people would have used it just because it was the only free compiler you could get.) Ada still has a pretty good following, but it does need to expand on that base. Things like Gnat and GtkAda help provide some of the necessary infrastructure. An "Out Of The Box" database and a library of utilities that goes along with it would be good additions that would help provide a more complete programming kit. That, and a little "Newness" that could be hyped as providing something you can't get elsewhere and Ada might see some new growth in new arenas. MDC Nick Roberts wrote: > > I'm pretty sure the main reasons are: that there has never been a > (really) big corporation backing Ada, in the same way that many of the > languages you mention have had; that Ada is not a language suited for > or much liked by many non-professional programmers. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 17:14 ` Nick Roberts 2004-08-11 18:00 ` Hyman Rosen 2004-08-12 11:48 ` Marin David Condic @ 2004-08-26 8:07 ` Adrian Hoe 2004-08-26 11:52 ` Marin David Condic 2 siblings, 1 reply; 387+ messages in thread From: Adrian Hoe @ 2004-08-26 8:07 UTC (permalink / raw) Nick Roberts wrote: > > I'm pretty sure the main reasons are: that there has never been a > (really) big corporation backing Ada, in the same way that many of the > languages you mention have had; that Ada is not a language suited for > or much liked by many non-professional programmers. > > Microsoft have a huge historical investment in Basic (VB), C (in which > Windows was written (it was nearly Pascal)), C++ (in which they hedged > the future of their C codebase). They have poured vast resources into > developing and marketing tools supporting these languages. The latest > big thing from Microsoft is C#, and they have promoted it relentlessly. > > Sun's fortunes were founded on Unix, so they have a huge vested > interest in the C language. They have done much to promote both. Lately, > Sun have placed all their faith in Java, and they have poured vast > resources into popularising it. Yes. You are right. There has never been a corporation to sponsor Ada. Unlike Java and C# which have vigorous and aggressive advertisement sponsored by Sun and M$ respectively. They are the owner of the respective "products". Sun has invested millions of dollars to promote Java, for example, Sun set up a Java Competency Center in Malaysia. Millions of dollars were poured in. People who chose a programming language based on its popularity like advertisement and loud noisy announcement, are those have no technical merit in evaluating the programming language. Anyone care to send me an asbestos suit? :) -- Adrian Hoe m a i l b o x AT a d r i a n h o e . c o m ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 8:07 ` Adrian Hoe @ 2004-08-26 11:52 ` Marin David Condic 2004-08-27 8:10 ` Adrian Hoe 0 siblings, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-08-26 11:52 UTC (permalink / raw) Here's the problem: We can say "That's not fair!" or "That's not right!" all we want, but reality can be a real bitch sometimes. If you don't "market" the language in some manner, nobody knows about it or has any reason to believe it is superior to what they *do* know about. Shoving the lamp under a bushel basket doesn't do much good. MDC Adrian Hoe wrote: > > People who chose a programming language based on its popularity like > advertisement and loud noisy announcement, are those have no technical > merit in evaluating the programming language. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 11:52 ` Marin David Condic @ 2004-08-27 8:10 ` Adrian Hoe 2004-08-27 14:37 ` Ed Falis 0 siblings, 1 reply; 387+ messages in thread From: Adrian Hoe @ 2004-08-27 8:10 UTC (permalink / raw) Marin David Condic wrote: > Here's the problem: We can say "That's not fair!" or "That's not right!" > all we want, but reality can be a real bitch sometimes. If you don't > "market" the language in some manner, nobody knows about it or has any > reason to believe it is superior to what they *do* know about. Shoving > the lamp under a bushel basket doesn't do much good. > > MDC > > Adrian Hoe wrote: > >> >> People who chose a programming language based on its popularity like >> advertisement and loud noisy announcement, are those have no technical >> merit in evaluating the programming language. >> > But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada compiler vendors do? They did nothing to promote Ada. -- Adrian Hoe m a i l b o x AT a d r i a n h o e . c o m ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 8:10 ` Adrian Hoe @ 2004-08-27 14:37 ` Ed Falis 2004-08-27 17:52 ` Richard Riehle 0 siblings, 1 reply; 387+ messages in thread From: Ed Falis @ 2004-08-27 14:37 UTC (permalink / raw) On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com> wrote: > But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada > compiler vendors do? They did nothing to promote Ada. What a crock of horse-hockey! And no, I'm not going to list 15 years of Ada advocacy efforts on the part of the vendors. - Ed ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 14:37 ` Ed Falis @ 2004-08-27 17:52 ` Richard Riehle 2004-08-27 18:20 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-27 17:52 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> wrote in message news:opsdeaw7ox5afhvo@localhost... > On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com> > wrote: > > > But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada > > compiler vendors do? They did nothing to promote Ada. > > What a crock of horse-hockey! > > And no, I'm not going to list 15 years of Ada advocacy efforts on the part > of the vendors. > I will say a few words about this. Ada Core Technologies has, and continues to have, an initiative for promoting Ada. The very fact that GNAT is available free is a substantial achievement. Aonix, though more recently less of an advocated, also has a free compiler and gave away thousands of copies of its early Ada 95 compiler at conferences and elsewhere. During the early years, there was a lot of advocacy. I recall getting excellent support for my own advocacy efforts from Alsys, especially when Lori Heyman was in charge of public relations there. Ben Brosgol traveled all over the world presenting Ada to a wide range of audiences. Let's not forget the efforts of Ralph Crafts. He worked his butt off trying to promote Ada to a larger venue. He finally burned out and left the Ada industry, but his work on the behalf of Ada was second to none. For Ada 83, we had the Meridian Ada compiler, and the Janus Ada compiler, both of which were reasonably priced. Though Janus was probably a slightly better compiler, Meridian took the trouble to provide a good library for writing DOS programs and that made it popular in a lot of university environments. Then there were other organizations, composed mostly of Ada compiler publishers. When Ada 95 came on the scene, a large chunk of money was set aside for publicity and promotion. Sadly, much of it was squandered on silly advertisements and posters that had no chance of convincing anyone. Even so, the ARA did give it a try even with very limited resources. Promotion takes money. In the current world of Ada, there is not much of that available. Some compiler publishers are not earning much money on Ada at present. This is due, in large part, to the move away from Ada toward other languages for some important military projects. Few compiler companies can thrive, at present, by relying solely on its Ada products. Ada suffered some early setbacks because of bad policy decisions on the part of the DoD as well as the compiler publishers. When the DoD insisted that all software be written in a language for which compilers did not yet exist, it set up a plan for failure. That policy was followed with a waiver policy that added to the problem. Overall, the early DoD management of its Ada initiative was pretty bad. The blame for this can be assigned to a fairly high level within the DoD, indeed, within the U.S. Government, where officials failed to understand the value, the importance, of this initiative. The compiler publishers, all of which were staffed by a lot of bright, enthusiastic, and conscientious people, made their own mistakes. Failure to provide a full set of facilities for the popular targeted platforms was one (except for Meridian, cited earlier). Failure to coordinate with each other to develop a set of portable libraries. Setting prices so high, for the really good compilers, that Non-DoD companies could not justify the use of Ada to their own management. Failure to fully grasp the impact of the microcomputer revolution and adapt their compilers, at appropriate pricing, to meet the demand (again Meridian and Janus were the exceptions). Failure to be flexible enough as the microcomputer industry evolved through a variety of human-machine interaction modes. Failure to develop good file management, database management, and other libraries that could attract a larger following. Ada entered the marketplace at a time of marketplace change. The changes were occurring so fast that a language that could not change at the same pace, or where tools and libraries could not keep up with that pace, was bound to be suspect. Finally, just as Ada reached a point where it was the ideal solution for a larger range of environments and applications (free compilers, better tools for windowing environments, good editors, lots of good libraries, etc), it had its support cut from under it by the very organization that needed it most, the DoD. Funding was cut, the AdaIC was disbanded, and the developers rushed to C++ in droves. It was a classic case where the DoD grabbed defeat from the jaws of victory. Ada had become one of the most effective development tools available, in my view, far superior to the C++ of the time, and the DoD management simply abandoned it. I continue to encounter DoD officials who seriously believe that the DoD has now banned the use of Ada for future software projects. At present, I know of no high-ranking DoD official who will rebut that view. At present, no one in the DoD, certainly no one in the Pentagon, wants to have his/her name publicly associated with Ada in any way. They look upon it as a failed project. How does anyone counter that view? How do we revive confidence in Ada once it has become a pariah among the very people who will benefit from it? Sadly, these senior officials have washed their hands of anything to do with language selection, and our weapon systems are going to be awash with awful, unmaintainable software, and probably less reliable software written in C++. The deleterious effects of all this C++ code will not manifest itself for a long time, and when it does, it will be too late. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 17:52 ` Richard Riehle @ 2004-08-27 18:20 ` Hyman Rosen 2004-08-27 22:45 ` Wes Groleau 2004-09-03 6:48 ` Adrian Hoe 2 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-27 18:20 UTC (permalink / raw) Richard Riehle wrote: > The deleterious effects of all this C++ code will not > manifest itself for a long time, and when it does, it > will be too late. Now, now. Anyway, it's all going to be written in real-time Java :-) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 17:52 ` Richard Riehle 2004-08-27 18:20 ` Hyman Rosen @ 2004-08-27 22:45 ` Wes Groleau 2004-09-03 6:48 ` Adrian Hoe 2 siblings, 0 replies; 387+ messages in thread From: Wes Groleau @ 2004-08-27 22:45 UTC (permalink / raw) Richard Riehle wrote: > publicly associated with Ada in any way. They look > upon it as a failed project. How does anyone counter And they're right. It failed to achieve the government's standard level of mediocrity and incompetence. :-) -- Wes Groleau There are some ideas so wrong that only a very intelligent person could believe in them. -- George Orwell ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 17:52 ` Richard Riehle 2004-08-27 18:20 ` Hyman Rosen 2004-08-27 22:45 ` Wes Groleau @ 2004-09-03 6:48 ` Adrian Hoe 2004-09-03 12:14 ` stephane richard 2 siblings, 1 reply; 387+ messages in thread From: Adrian Hoe @ 2004-09-03 6:48 UTC (permalink / raw) Richard Riehle wrote: > "Ed Falis" <falis@verizon.net> wrote in message > news:opsdeaw7ox5afhvo@localhost... > >>On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com> >>wrote: >> >> >>>But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada >>>compiler vendors do? They did nothing to promote Ada. >> >>What a crock of horse-hockey! >> >>And no, I'm not going to list 15 years of Ada advocacy efforts on the part >>of the vendors. >> > > I will say a few words about this. > > Ada Core Technologies has, and continues to have, an initiative > for promoting Ada. The very fact that GNAT is available free > is a substantial achievement. Aonix, though more recently less > of an advocated, also has a free compiler and gave away > thousands of copies of its early Ada 95 compiler at conferences > and elsewhere. > > During the early years, there was a lot of advocacy. I recall > getting excellent support for my own advocacy efforts from > Alsys, especially when Lori Heyman was in charge of public > relations there. Ben Brosgol traveled all over the world > presenting Ada to a wide range of audiences. > > Let's not forget the efforts of Ralph Crafts. He worked his > butt off trying to promote Ada to a larger venue. He finally > burned out and left the Ada industry, but his work on the > behalf of Ada was second to none. > > For Ada 83, we had the Meridian Ada compiler, and the > Janus Ada compiler, both of which were reasonably > priced. Though Janus was probably a slightly better > compiler, Meridian took the trouble to provide a good > library for writing DOS programs and that made it > popular in a lot of university environments. > > Then there were other organizations, composed mostly of > Ada compiler publishers. When Ada 95 came on the scene, > a large chunk of money was set aside for publicity and > promotion. Sadly, much of it was squandered on silly > advertisements and posters that had no chance of convincing > anyone. Even so, the ARA did give it a try even with > very limited resources. > > Promotion takes money. In the current world of Ada, there > is not much of that available. Some compiler publishers > are not earning much money on Ada at present. This is > due, in large part, to the move away from Ada toward > other languages for some important military projects. Few > compiler companies can thrive, at present, by relying > solely on its Ada products. > > Ada suffered some early setbacks because of bad policy > decisions on the part of the DoD as well as the compiler > publishers. When the DoD insisted that all software > be written in a language for which compilers did not > yet exist, it set up a plan for failure. That policy was > followed with a waiver policy that added to the problem. > Overall, the early DoD management of its Ada initiative > was pretty bad. The blame for this can be assigned to > a fairly high level within the DoD, indeed, within the > U.S. Government, where officials failed to understand > the value, the importance, of this initiative. > > The compiler publishers, all of which were staffed by > a lot of bright, enthusiastic, and conscientious people, > made their own mistakes. Failure to provide a full > set of facilities for the popular targeted platforms was > one (except for Meridian, cited earlier). Failure to > coordinate with each other to develop a set of > portable libraries. Setting prices so high, for the > really good compilers, that Non-DoD companies > could not justify the use of Ada to their own > management. Failure to fully grasp the impact > of the microcomputer revolution and adapt their > compilers, at appropriate pricing, to meet the > demand (again Meridian and Janus were the > exceptions). Failure to be flexible enough as > the microcomputer industry evolved through a > variety of human-machine interaction modes. > Failure to develop good file management, database > management, and other libraries that could attract > a larger following. > > Ada entered the marketplace at a time of marketplace > change. The changes were occurring so fast that > a language that could not change at the same pace, > or where tools and libraries could not keep up with > that pace, was bound to be suspect. > > Finally, just as Ada reached a point where it was the > ideal solution for a larger range of environments and > applications (free compilers, better tools for windowing > environments, good editors, lots of good libraries, etc), > it had its support cut from under it by the very organization > that needed it most, the DoD. Funding was cut, the > AdaIC was disbanded, and the developers rushed to > C++ in droves. It was a classic case where the DoD > grabbed defeat from the jaws of victory. Ada had > become one of the most effective development tools > available, in my view, far superior to the C++ of the > time, and the DoD management simply abandoned > it. I continue to encounter DoD officials who seriously > believe that the DoD has now banned the use of > Ada for future software projects. At present, I know > of no high-ranking DoD official who will rebut that > view. At present, no one in the DoD, certainly no > one in the Pentagon, wants to have his/her name > publicly associated with Ada in any way. They look > upon it as a failed project. How does anyone counter > that view? How do we revive confidence in Ada once > it has become a pariah among the very people who > will benefit from it? Sadly, these senior officials > have washed their hands of anything to do with language > selection, and our weapon systems are going to be > awash with awful, unmaintainable software, and > probably less reliable software written in C++. The > deleterious effects of all this C++ code will not > manifest itself for a long time, and when it does, it > will be too late. > > Richard Riehle > > > > And no, this is not a crock! What use to have fully functional and free compiler available for download? For someone who has not heard of Ada and does not even know the existence of such programming language, how does one come to know there is a fully functional and free Ada compiler for download? Turn the pages of computing magazines, advertisements and projects write-outs about Java, Perl, C#, .NET, Delphi, Kylix and etc. come alive in front of these magazines readers. Ada? I knew about Ada when I flipped through a catalog of pirated software around mid 1980's. I bought it for M$5 for an Apple CP/M. I could not find an Ada book then. After mingling with it for sometimes, I put the floppy disk in a cupboard until the end of 1993. I recalled something called Ada and did a search on Internet and there began my Ada love affairs. I read about one article about Alsys Ada in PC Magazine (I can't exactly remember the name of the magazine, I hope the name is correct) in late 80's or early 90's. That's the only article I read about Ada since then (I might have missed some other Ada articles in later years). Providing a free Ada compiler is not enough to promote Ada. -- Adrian Hoe m a i l b o x AT a d r i a n h o e . c o m ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 6:48 ` Adrian Hoe @ 2004-09-03 12:14 ` stephane richard 2004-09-03 17:33 ` Björn Persson 0 siblings, 1 reply; 387+ messages in thread From: stephane richard @ 2004-09-03 12:14 UTC (permalink / raw) I agree, People need to know that Ada exists or they'll never enter any Ada related search words hence never get Ada related results on search engines. Seems all people are looking for today are RAD environments, very integrated IDE's with of course code completion and all them time saving mechanisms as discussed in another thread on this board. people that know Ada are on comp.lang.ada, the problem is to get people on other languages to see what Ada can do. and that's what lacks the most. If people don't search for specific programming languages, for example, if they search for OpenGL, they'll come across the AdaOpenGL project and might be curious about it then. Doesn't seem to be enough to say that Ada was born as a superset of Pascal either. I'm trying to see what could be added to or created to bring any programmer to the Ada community. One thing I did notice is in past "popularity threads" is that Ada developers won't change their preferences, hence to know Ada is to love Ada (hey that might make a quote somewhere ;-). But I do think it's true. I think we need a different side of Ada to promote maybe, alot of websites I've been to emphasize how Ada is made to work with software Engineering methods for example, that's good to software engineers, how many C/C++ or Delphi programmers are software engineers? I'm sure there are some, but these languages are promoted to be used for anything at all. hence the home user. Maybe we need to push more the home user, the fella that wants to work in his basement to create the next revolutionary software, the common user? I think if we find the right approach, it can happen. Now what would that approach be? Of course, to see applications developed in Ada helps, but I wonder, if we had enough software developed in Ada, if would help. A free compiler is a good boost, but seems to be insufficient. So then, I'm on a quest to see what people what to know about Ada that can and would convince them to give it a good shot. Sure Libraries are good, Bindings too, but what else? there must be something else, if there isn't then maybe that's the missing link. Stephane Richard "Ada World" webmaster http://www.adaworld.com "Adrian Hoe" <AdrianHoe@nowhere.com> wrote in message news:413812b7_2@news.tm.net.my... > Richard Riehle wrote: >> "Ed Falis" <falis@verizon.net> wrote in message >> news:opsdeaw7ox5afhvo@localhost... >> >>>On Fri, 27 Aug 2004 16:10:34 +0800, Adrian Hoe <AdrianHoe@nowhere.com> >>>wrote: >>> >>> >>>>But, what did GNAT, Aonix, Intermetrics, Greenhill and other Ada >>>>compiler vendors do? They did nothing to promote Ada. >>> >>>What a crock of horse-hockey! >>> >>>And no, I'm not going to list 15 years of Ada advocacy efforts on the >>>part >>>of the vendors. >>> >> >> I will say a few words about this. >> >> Ada Core Technologies has, and continues to have, an initiative >> for promoting Ada. The very fact that GNAT is available free >> is a substantial achievement. Aonix, though more recently less >> of an advocated, also has a free compiler and gave away >> thousands of copies of its early Ada 95 compiler at conferences >> and elsewhere. >> >> During the early years, there was a lot of advocacy. I recall >> getting excellent support for my own advocacy efforts from >> Alsys, especially when Lori Heyman was in charge of public >> relations there. Ben Brosgol traveled all over the world >> presenting Ada to a wide range of audiences. >> >> Let's not forget the efforts of Ralph Crafts. He worked his >> butt off trying to promote Ada to a larger venue. He finally >> burned out and left the Ada industry, but his work on the >> behalf of Ada was second to none. >> >> For Ada 83, we had the Meridian Ada compiler, and the >> Janus Ada compiler, both of which were reasonably >> priced. Though Janus was probably a slightly better >> compiler, Meridian took the trouble to provide a good >> library for writing DOS programs and that made it >> popular in a lot of university environments. >> >> Then there were other organizations, composed mostly of >> Ada compiler publishers. When Ada 95 came on the scene, >> a large chunk of money was set aside for publicity and >> promotion. Sadly, much of it was squandered on silly >> advertisements and posters that had no chance of convincing >> anyone. Even so, the ARA did give it a try even with >> very limited resources. >> >> Promotion takes money. In the current world of Ada, there >> is not much of that available. Some compiler publishers >> are not earning much money on Ada at present. This is >> due, in large part, to the move away from Ada toward >> other languages for some important military projects. Few >> compiler companies can thrive, at present, by relying >> solely on its Ada products. >> >> Ada suffered some early setbacks because of bad policy >> decisions on the part of the DoD as well as the compiler >> publishers. When the DoD insisted that all software >> be written in a language for which compilers did not >> yet exist, it set up a plan for failure. That policy was >> followed with a waiver policy that added to the problem. >> Overall, the early DoD management of its Ada initiative >> was pretty bad. The blame for this can be assigned to >> a fairly high level within the DoD, indeed, within the >> U.S. Government, where officials failed to understand >> the value, the importance, of this initiative. >> >> The compiler publishers, all of which were staffed by >> a lot of bright, enthusiastic, and conscientious people, >> made their own mistakes. Failure to provide a full >> set of facilities for the popular targeted platforms was >> one (except for Meridian, cited earlier). Failure to >> coordinate with each other to develop a set of >> portable libraries. Setting prices so high, for the >> really good compilers, that Non-DoD companies >> could not justify the use of Ada to their own >> management. Failure to fully grasp the impact >> of the microcomputer revolution and adapt their >> compilers, at appropriate pricing, to meet the >> demand (again Meridian and Janus were the >> exceptions). Failure to be flexible enough as >> the microcomputer industry evolved through a >> variety of human-machine interaction modes. >> Failure to develop good file management, database >> management, and other libraries that could attract >> a larger following. >> >> Ada entered the marketplace at a time of marketplace >> change. The changes were occurring so fast that >> a language that could not change at the same pace, >> or where tools and libraries could not keep up with >> that pace, was bound to be suspect. >> >> Finally, just as Ada reached a point where it was the >> ideal solution for a larger range of environments and >> applications (free compilers, better tools for windowing >> environments, good editors, lots of good libraries, etc), >> it had its support cut from under it by the very organization >> that needed it most, the DoD. Funding was cut, the >> AdaIC was disbanded, and the developers rushed to >> C++ in droves. It was a classic case where the DoD >> grabbed defeat from the jaws of victory. Ada had >> become one of the most effective development tools >> available, in my view, far superior to the C++ of the >> time, and the DoD management simply abandoned >> it. I continue to encounter DoD officials who seriously >> believe that the DoD has now banned the use of >> Ada for future software projects. At present, I know >> of no high-ranking DoD official who will rebut that >> view. At present, no one in the DoD, certainly no >> one in the Pentagon, wants to have his/her name >> publicly associated with Ada in any way. They look >> upon it as a failed project. How does anyone counter >> that view? How do we revive confidence in Ada once >> it has become a pariah among the very people who >> will benefit from it? Sadly, these senior officials >> have washed their hands of anything to do with language >> selection, and our weapon systems are going to be >> awash with awful, unmaintainable software, and >> probably less reliable software written in C++. The >> deleterious effects of all this C++ code will not >> manifest itself for a long time, and when it does, it >> will be too late. >> >> Richard Riehle >> >> >> >> > > > And no, this is not a crock! > > What use to have fully functional and free compiler available for > download? For someone who has not heard of Ada and does not even know the > existence of such programming language, how does one come to know there is > a fully functional and free Ada compiler for download? > > Turn the pages of computing magazines, advertisements and projects > write-outs about Java, Perl, C#, .NET, Delphi, Kylix and etc. come alive > in front of these magazines readers. Ada? > > I knew about Ada when I flipped through a catalog of pirated software > around mid 1980's. I bought it for M$5 for an Apple CP/M. I could not find > an Ada book then. After mingling with it for sometimes, I put the floppy > disk in a cupboard until the end of 1993. I recalled something called Ada > and did a search on Internet and there began my Ada love affairs. > > I read about one article about Alsys Ada in PC Magazine (I can't exactly > remember the name of the magazine, I hope the name is correct) in late > 80's or early 90's. That's the only article I read about Ada since then (I > might have missed some other Ada articles in later years). > > Providing a free Ada compiler is not enough to promote Ada. > -- > Adrian Hoe > m a i l b o x AT a d r i a n h o e . c o m > ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 12:14 ` stephane richard @ 2004-09-03 17:33 ` Björn Persson 0 siblings, 0 replies; 387+ messages in thread From: Björn Persson @ 2004-09-03 17:33 UTC (permalink / raw) stephane richard wrote: > People need to know that Ada exists or they'll never enter any Ada related > search words hence never get Ada related results on search engines. Oh I think most programmers know it exists. The problem is that they seem to think its name is "Oh no, not Ada!", and that's all they know about it. > Maybe we need to push more the home user, the fella that wants to > work in his basement to create the next revolutionary software, the common > user? That'd be me. Well, I don't think what I've done so far is exactly revolutionary, but I have dreams. :-) I don't need to see ads for something in every magazine to get interested. Excessive advertising is more likely to drive me away. When I read about computer languages, protocols, programs or operating systems I often want to try them out. In most cases I never get around to it; there are just too many things to try. What made me actually try Ada was a section about exception handling in a book. I had been coding in Turbo Pascal and been annoyed at all the error handling I had to do all over the code. I instantly knew I wanted exceptions. And the code example in that section was in Ada. So, maybe we should sprinkle the Web with short examples of how to do things in Ada that other languages can't do? Free software enthusiasts take pride in making more stable and secure software than the closed source vendors, and at least some of them are frustrated over the never-ceasing stream of security holes in everything from kernels to media players. They usually think better testing and more code review is the answer. I do my best to spread the idea that buffer overflows are caused by a bad choice of language. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries ` (2 preceding siblings ...) 2004-08-11 17:14 ` Nick Roberts @ 2004-08-11 18:58 ` fabio de francesco 2004-08-12 0:05 ` Larry Elmore 2004-08-12 22:41 ` Richard Riehle ` (2 subsequent siblings) 6 siblings, 1 reply; 387+ messages in thread From: fabio de francesco @ 2004-08-11 18:58 UTC (permalink / raw) chris@unixfu.net (Chris Humphries) wrote in message news:<49dc98cf.0408110556.18ae7df@posting.google.com>... > Hello, > > Would like to open up the newsgroup for discussion of why > ADA is not as popular as (of now me learning it) to it is > not as popular as other languages (Perl, Java, C++, C#, C). > > I can understand why C is popular, UNIX and all the tools > for it and most of everything that runs the internet services > (smtp, http [apache mostly according to netcraft.com], bind). > Perl (well I use it at work, for legacy reasons of taking over > code) I can understand due to it just being so easy to get > something done fast in (and I must say that the regex abilities > are definitely something that you can get used to quickly, heh. > CPAN is also a nice feature, tons of modules/libraries to use > for most everything one command line away. > > Java and C++ got huge during the OOP boom of the 90's, and now > almost every Computer Science student in college has taken at > least one of those languages. > > Java does have some nice OO abilities and there are a ton of > libraries for it. C++ has some OO-ish abilities, yet can be > compiled and also has a ton of libraries. > > Yet as I grew in my programming experience and abilities, I > learned that most of my time was spent updating and fixing code. > > C/C++ took a lot of time to develop in, and I didn't like > having to worry about memory management and use my gdb-fu to > figure out why something did not work. I also must thank Ada for not to make me spend my time playing with the debugger. > Perl is somewhat better, though it is mostly just if syntax > doesn't match up right. If it is quick and dirty, Perl excels. > Granted, I do have a written from bottom up programs we now use > in the company here as a core part of daily life and it is in > nothing by Perl. I can't imagine anything less readable than Perl. I see it like the exact opposite of Ada for that. > Java is kinda nice, but honestly the dependency of the VM is > nice in concept, but a pain in real life. You need to make sure > that your program either is portable to several versions of > virtual machines or you have to bundle your own (for client apps). > Java is just too slow (I can not afford the hardware or even justify > it's use of hardware money to make it's speed comparable with other > "free" alternatives) for cgi based applications, though the whole > application server thing with db connection pooling is cool. > > Python is nice too, and I suppose no real reason to not use it. > I have coded python since 1.5 and early Zope releases. I just would > like to not code in it anymore, though reason are because I am > sick of it. > > So, why is ADA not as popular as the above languages to the > world (well especially opensource developers) outside of dod and > defense contractors and banks? It seems like an extremely powerful > and awesome language, and it is just so easy to look at the code > and tell what is going on and what is what. It can be OO and can > run tasks concurrently. It's runtime and compile checking is awesome. > GNAT is free and available to all to use. Since a couple of months I have been learning Ada95 and I like it much more than C/C++, even if I can say I am a good programmer with the latter ones. I think that the lack of Ada programmers produces little amount of code to expand and to maintain and this produces little interest in becoming an Ada programmer. I think that the more software ( especially more open source software ) in a specific language exists the more programmers in this language are needed. I was leaded to learn C/C++ because I wanted to understand how my Linux box worked, seen that from the kernel to the vast majority of the user applications have been written with those. So I started to hack that C/C++ code. There is nobody I know that need Ada programs, so why matter? Just for fun, but not for more I suppose. If Linux and the user apps had been made with Ada I would had begun to learn this beautiful language a long time before. > So what is stopping ADA from being a language everyone knows? Is > it just viewed as old and arcane like COBOL and Fortran (no offense > to those that know these languages better than me)? Is it just lacking > some killer apps? Is it because most ADA is closed source, so there > are just not libraries out there (like a SSH library)? Yes I do think so. > Thanks, > Chris Ciao, Fabio ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 18:58 ` fabio de francesco @ 2004-08-12 0:05 ` Larry Elmore 2004-08-12 12:29 ` Adam Ruth 0 siblings, 1 reply; 387+ messages in thread From: Larry Elmore @ 2004-08-12 0:05 UTC (permalink / raw) fabio de francesco wrote: > > I can't imagine anything less readable than Perl. I see it like the > exact opposite of Ada for that. J is definitely harder to read than Perl. It's a descendent of APL, but replaced the special symbols with combinations of punctuation symbols. Like APL, you can write some incredible one-liners, but even you won't be able to easily figure out what it does a week later. http://www.jsoftware.com --Larry ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 0:05 ` Larry Elmore @ 2004-08-12 12:29 ` Adam Ruth 2004-08-13 6:55 ` Wojtek Narczynski 0 siblings, 1 reply; 387+ messages in thread From: Adam Ruth @ 2004-08-12 12:29 UTC (permalink / raw) In article <cvySc.290200$XM6.53864@attbi_s53>, Larry Elmore <ljelmore_@_comcast_._net> wrote: > fabio de francesco wrote: > > > > I can't imagine anything less readable than Perl. I see it like the > > exact opposite of Ada for that. > > J is definitely harder to read than Perl. It's a descendent of APL, but > replaced the special symbols with combinations of punctuation symbols. > Like APL, you can write some incredible one-liners, but even you won't > be able to easily figure out what it does a week later. > > http://www.jsoftware.com > > --Larry I think that BF wins, hands down, for the hardest to read language. WARNING: THIS PAGE CONTAINS A NAUGHTY WORD, PROCEED AT YOUR OWN RISK. http://www.muppetlabs.com/~breadbox/bf/ -- Adam Ruth adamruth at mac dot com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 12:29 ` Adam Ruth @ 2004-08-13 6:55 ` Wojtek Narczynski 0 siblings, 0 replies; 387+ messages in thread From: Wojtek Narczynski @ 2004-08-13 6:55 UTC (permalink / raw) Adam Ruth <adam.ruth@mac.com> wrote in message news:<adam.ruth-5C5819.06294112082004@localhost>... > In article <cvySc.290200$XM6.53864@attbi_s53>, > Larry Elmore <ljelmore_@_comcast_._net> wrote: > > > fabio de francesco wrote: > > > > > > I can't imagine anything less readable than Perl. I see it like the > > > exact opposite of Ada for that. > > > > J is definitely harder to read than Perl. It's a descendent of APL, but > > replaced the special symbols with combinations of punctuation symbols. > > Like APL, you can write some incredible one-liners, but even you won't > > be able to easily figure out what it does a week later. > > > > http://www.jsoftware.com > > > > --Larry > > > I think that BF wins, hands down, for the hardest to read language. > > WARNING: THIS PAGE CONTAINS A NAUGHTY WORD, > PROCEED AT YOUR OWN RISK. > > http://www.muppetlabs.com/~breadbox/bf/ Or Whitespace http://compsoc.dur.ac.uk/whitespace/, but those to are joke languages. My anti-favourite real language is M of MUMPS. Regards, Wojtek ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries ` (3 preceding siblings ...) 2004-08-11 18:58 ` fabio de francesco @ 2004-08-12 22:41 ` Richard Riehle 2004-08-12 23:20 ` Ed Falis 2004-08-13 2:55 ` Matt Morgan 2004-08-14 7:26 ` j 2004-08-16 21:09 ` Keith H Duggar 6 siblings, 2 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-12 22:41 UTC (permalink / raw) "Chris Humphries" <chris@unixfu.net> wrote in message news:49dc98cf.0408110556.18ae7df@posting.google.com... > Hello, > > Would like to open up the newsgroup for discussion of why > ADA is not as popular as (of now me learning it) to it is > not as popular as other languages (Perl, Java, C++, C#, C). > There are a lot of reasons. One of my favorites is the one that suggests that it was killed by the compiler publishers. In early Ada 83, this argument goes, the compiler publishers realized that they had a captive audience in the DoD. This led them to charge per-programmer prices for their compilers that were so high that the ordinary programmer could not afford to buy a compiler. On top of that, the larger compiler publishers, while giving lip service to commercial utilization of the language, focused all their sales effort on the DoD -- not even the other branches of government -- just the DoD. Further, machine vendors who had to bid an Ada compiler for the DoD often had no intention of anyone ever actually using their compiler. Tandem, for example, had a "checkbox" compiler, but provided no interfaces to its own operating system, development tools, or anything else in its product line that would make using Ada attractive. They were not alone in this. There were some low-cost compilers, notably Janus and Meridian. While these were pretty good products, they did not quite meet the needs of day-to-day programmers, and most programmers of the early microcomputer era found they could accomplish more with BASIC than they could with the existing Ada compilers and associated toolsets. In general, the Ada compiler publishers never put the kind of energy into creating an attractive environment for commercial Ada as would have been necessary. There were those within those organizations who did strive for that kind of thing. Dr. Brosgol worked very hard to make commercial Ada a reality, but he was pretty much (but not totally) alone much of the time. So, as the compiler publishers found themselves able to charge whatever the traffic would bear, they kept their prices so high that no commercial organization could justify Ada as a choice of languages -- not when so many other tools were so available, including development environments, database interfaces, VDT development tools, etc. This whole picture changed with the advent of GNAT, CLAW, JEWL, and many other good compilers and tools based on the Ada 95 standard. But by that time, Ada had already developed a reputation as cumbersome (not true), too big (not true), and only used by the Department of Defense (most true). Once a language, or any other product, has gotten a bad reputation, it is difficult to overcome it. I know people who will not buy a Jaguar because it is, by reputation, so hard to maintain. Others will not buy a Volkswagen because it is Hitler's car (and the VW van was designed, according to them, to help transport people to the holocaust). One can name countless products that, no matter how they fix themselves, have lost their potential market because of a bad reputation. Are the Ada 83 compiler publishers partly to blame because of their greed or shortsightedness? Well, maybe not entirely, but there are those in our community who do see it that way. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 22:41 ` Richard Riehle @ 2004-08-12 23:20 ` Ed Falis 2004-08-13 0:37 ` Nick Roberts 2004-08-13 7:01 ` Richard Riehle 2004-08-13 2:55 ` Matt Morgan 1 sibling, 2 replies; 387+ messages in thread From: Ed Falis @ 2004-08-12 23:20 UTC (permalink / raw) On Thu, 12 Aug 2004 22:41:27 GMT, Richard Riehle <adaworks@earthlink.net> wrote: > Are the Ada 83 compiler publishers partly to blame because > of their greed or shortsightedness? Well, maybe not entirely, > but there are those in our community who do see it that way. > > Richard Riehle After putting 16 years of my life into working for one of those Ada 83 (and 95) compiler publishers, and constantly striving to put good value products on the street, making zero profit year after year, I have to say I resent these remarks. There are plenty of other "members of the community" at whom fingers could be pointed. But I'll refrain because it won't change a thing. - Ed -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 23:20 ` Ed Falis @ 2004-08-13 0:37 ` Nick Roberts 2004-08-13 1:22 ` Ed Falis 2004-08-13 7:01 ` Richard Riehle 1 sibling, 1 reply; 387+ messages in thread From: Nick Roberts @ 2004-08-13 0:37 UTC (permalink / raw) On Thu, 12 Aug 2004 23:20:35 GMT, Ed Falis <falis@verizon.net> wrote: > On Thu, 12 Aug 2004 22:41:27 GMT, Richard Riehle > <adaworks@earthlink.net> wrote: > >> Are the Ada 83 compiler publishers partly to blame because >> of their greed or shortsightedness? Well, maybe not entirely, >> but there are those in our community who do see it that way. >> >> Richard Riehle > > After putting 16 years of my life into working for one of those > Ada 83 (and 95) compiler publishers, and constantly striving to > put good value products on the street, making zero profit year > after year, I have to say I resent these remarks. Ed, I'm pretty certain that Richie was not implicating Alsys in his comments. Everybody knows that Alsys was one of the few companies that struggled to bring a good Ada compiler to the masses (I was one of those masses). I specifically remember that any development system for the IBM PC, at that time (mid 1980s) was inevitably compared with Borland TurboPascal, which set the price bar for that kind of thing at an unprecendentedly low level, whilst setting the convenience bar at an unprecendentedly high level, and was hard for anyone to compete with. It is easy to forget now that few people had a personal computer then. Nearly everyone then who would become one of the hoards of professional progrmmers in the nineties cut their teeth on a computer either at work or at university. Ada was not (in the 1980s) available at any workplace outside the military (and a few aerospace and communications companies, and one French train company), and available at very few unis. I think Ada publishers failed to do all the things that, with the aid of hindsight, they should have done to collectively promote the language. But I think this was mainly because they did not feel that it was their role to do that sort of thing, rather than just sheer greed as such. Of course, they /should/ have realised that it /was/ their role -- for the simple reason that nobody else was going to do it -- but I think typical corporate attitudes were against that kind of thing in the eighties. > There are plenty of other "members of the community" at whom > fingers could be pointed. But I'll refrain because it won't > change a thing. Quite. -- Nick Roberts ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-13 0:37 ` Nick Roberts @ 2004-08-13 1:22 ` Ed Falis 0 siblings, 0 replies; 387+ messages in thread From: Ed Falis @ 2004-08-13 1:22 UTC (permalink / raw) On Fri, 13 Aug 2004 01:37:26 +0100, Nick Roberts <nick.roberts@acm.org> wrote: > Ed, I'm pretty certain that Richie was not implicating Alsys in his > comments. Everybody knows that Alsys was one of the few companies > that struggled to bring a good Ada compiler to the masses (I was one > of those masses). Richard and I know each other well, and I'm pretty sure he knows that my having to comment on his statement was not personal in any way. There were those of us who thought it was our job to do some of those things to make the language successful. And you're right, the corporate environment of the times mitigated against it. - Ed -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 23:20 ` Ed Falis 2004-08-13 0:37 ` Nick Roberts @ 2004-08-13 7:01 ` Richard Riehle 1 sibling, 0 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-13 7:01 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> wrote in message news:opscm64kqg5afhvo@localhost... > On Thu, 12 Aug 2004 22:41:27 GMT, Richard Riehle <adaworks@earthlink.net> > wrote: > > > Are the Ada 83 compiler publishers partly to blame because > > of their greed or shortsightedness? Well, maybe not entirely, > > but there are those in our community who do see it that way. > > > > Richard Riehle > > After putting 16 years of my life into working for one of those Ada 83 > (and 95) compiler publishers, and constantly striving to put good value > products on the street, making zero profit year after year, I have to say > I resent these remarks. > Sorry for posting such a derisive screed, Ed. To quote Laura Huxley (I know you will understand this better than some others who might read it), "You are not the target." The people at Alsys that I know were among those who fought for wider accpetance of Ada in the commercial community. There are others including Randy over at RR, and some of the folks at Meridian. > There are plenty of other "members of the community" at whom fingers could > be pointed. But I'll refrain because it won't change a thing. > I mentioned in my earlier post the "checkbox" compilers. These were among the worst of the Ada offerings. In most cases, the vendor had no expectations that anyone would use Ada on their computer. The compiler was created only to satisfy the checkbox on an RFQ where it said, "Validated Ada." As far as the DoD was concerned, Validated Ada meant that there was a minimal implementation of Ada for a vendors computer. The fact that there were no tools relating to that computer's operating system, no development environments, no way to access the database, and no committment to Ada within the organization, was indication enough that the vendor was not serious about Ada. At least one vendor's VP confided to me around 1989 that, for them, Ada was a "checkbox" compiler. If you wanted to create real programs, you needed to use one of their supported languages, one that supported their proprietary OS. That company no longer makes computers. They have been acquired. This was not uncommon in those times. Most of us had the experience of being confronted with a compiler environment that satisfied the checkbox, but did not have all the tools necessary to create programs easily for the targeted platform. There is a line from "Who Killed Roger Rabbit," where the cartoon character named Jessica says, "I'm not really bad. I'm just drawn that way." One can imagine Ada saying something such as, "I'm not really bad. I've just been implemented that way." In the end, all of us involved in promoting Ada made our mistakes, myself included. In my current role, that of a professor of computer science, I hope I am doing better. My students seem to come away from my Ada classes with a good feeling about it. Still, I encounter people from the DoD, industry, and elsewhere who say to me, "I thought the DoD now forbids the use of Ada." Somehow, the correct message is still not getting out. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-12 22:41 ` Richard Riehle 2004-08-12 23:20 ` Ed Falis @ 2004-08-13 2:55 ` Matt Morgan 1 sibling, 0 replies; 387+ messages in thread From: Matt Morgan @ 2004-08-13 2:55 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:rmSSc.19355$cK.6880@newsread2.news.pas.earthlink.net... > Once a language, or any other product, has gotten a bad > reputation, it is difficult to overcome it. I know people who > will not buy a Jaguar because it is, by reputation, so hard to > maintain. Others will not buy a Volkswagen because it is > Hitler's car (and the VW van was designed, according to > them, to help transport people to the holocaust). I have recently come back to the Ada95 table (both professionally and as a hobbyist), and I happen to drive a VW... Surely that has to count for *something*... <g> ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries ` (4 preceding siblings ...) 2004-08-12 22:41 ` Richard Riehle @ 2004-08-14 7:26 ` j [not found] ` <fvavh0lmv0644gn5dt45sbj574t3ivqhlt@4ax.com> 2004-08-16 21:09 ` Keith H Duggar 6 siblings, 1 reply; 387+ messages in thread From: j @ 2004-08-14 7:26 UTC (permalink / raw) I know for a fact that Boeing uses Ada 83 on the F/A-22 (fighter jet of the future). --= It Lives!! =-- ^ permalink raw reply [flat|nested] 387+ messages in thread
[parent not found: <fvavh0lmv0644gn5dt45sbj574t3ivqhlt@4ax.com>]
* Re: ADA Popularity Discussion Request [not found] ` <fvavh0lmv0644gn5dt45sbj574t3ivqhlt@4ax.com> @ 2004-08-15 21:26 ` Nick Roberts 2004-08-16 1:02 ` Richard Riehle 0 siblings, 1 reply; 387+ messages in thread From: Nick Roberts @ 2004-08-15 21:26 UTC (permalink / raw) On Sun, 15 Aug 2004 18:56:22 GMT, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > On Sat, 14 Aug 2004 02:26:33 -0500, "j" <toddbiz@highstream.net> > declaimed the following in comp.lang.ada: > >> I know for a fact that Boeing uses Ada 83 on the F/A-22 (fighter >> jet of the future). > > That's interesting, as the F/A-22 is a Lockheed Martin > development... > > (also interesting -- I missed the announcement of the designator > change from fighter to fighter/attack) The Raptor has always been officially designated F/A-22, I think. It was always conceived in a joint interdictor and ground support role. Nevertheless, the forms "F22", "F-22", "F 22" and so on also seem to be commonly used (odd, really). Boeing developed a complete prototype for the competition with Lockheed Martin for the Raptor contract. Of course, Lockheed Martin won, but I believe Boeing are involved in the manufacturing programme. From the F/A-22 web site: The software that provides the avionics system's full functionality is composed of approximately 1.7 million lines of code. Ninety percent of the software is written in Ada, the Department of Defense's common computer language. Exceptions to the Ada requirement are granted only for special processing or maintenance requirements. -- Nick Roberts ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-15 21:26 ` Nick Roberts @ 2004-08-16 1:02 ` Richard Riehle 0 siblings, 0 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-16 1:02 UTC (permalink / raw) "Nick Roberts" <nick.roberts@acm.org> wrote in message news:opscslubwup4pfvb@bram-2... > > From the F/A-22 web site: > > The software that provides the avionics system's full > functionality is composed of approximately 1.7 million lines of > code. Ninety percent of the software is written in Ada, the > Department of Defense's common computer language. Exceptions to > the Ada requirement are granted only for special processing or > maintenance requirements. > Too bad this kind of intelligent decision-making could not have been applied to the Joint Strike Fighter. Instead, some idiot decided to do all the software for JSF in C++. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-11 13:56 Chris Humphries ` (5 preceding siblings ...) 2004-08-14 7:26 ` j @ 2004-08-16 21:09 ` Keith H Duggar 2004-08-16 22:24 ` Ludovic Brenta ` (4 more replies) 6 siblings, 5 replies; 387+ messages in thread From: Keith H Duggar @ 2004-08-16 21:09 UTC (permalink / raw) Greetings all. Thank you for opening this thread I'm very eager to learn more about Ada. If I may explain. I'm a proficient C++ coder and have been using it for scientific research coding for eight years. And I have experience with various other languages including C and Fortran. Recently, quite by accident, I ran into the Ada language having (unfortunately) barely heard of it and having never seen or been taught anything about it. When I first saw Ada I thought wow this looks like an excellent language. In the very least it is a language that I wish I had known about much earlier. For example, I wish Georgia Tech had included Ada in a course of two as they had included Fortran and C. So, after researching a bit on the web I still couldn't find and explanations for why Ada isn't that popular. I decided to email a well known programming and compiler guru who had once commented positively on Ada. I asked why Ada wasn't as popular as C++ (a language which he is also a guru of). Here was his reply: "Ada was an experiment that failed. It was specified in such a way that it's hard to get adequate performance. So a critical mass of users and vendors never materialized. Now we see people devoting more energy to making C/C++ safer for programming large systems." Can any of you help me understand the details behind what he stated? Was it difficult to write compilers that gave good performance? Was the language specification too complex or difficult to implement? Or are there simply missing features that preclude some efficient coding idioms (does Ada have pointers?). I'm very ignorant when it comes to Ada so please forgive these newbie questions. Keith ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 21:09 ` Keith H Duggar @ 2004-08-16 22:24 ` Ludovic Brenta 2004-08-16 22:30 ` Ed Falis 2004-08-17 6:13 ` Keith H Duggar 2004-08-16 22:26 ` Ed Falis ` (3 subsequent siblings) 4 siblings, 2 replies; 387+ messages in thread From: Ludovic Brenta @ 2004-08-16 22:24 UTC (permalink / raw) (Keith H Duggar) writes: > "Ada was an experiment that failed. It was specified in such a way > that it's hard to get adequate performance. So a critical mass of > users and vendors never materialized. Now we see people devoting > more energy to making C/C++ safer for programming large systems." I wouldn't consider whoever said that a guru. A real guru keeps posted about new developments. > Can any of you help me understand the details behind what he stated? > Was it difficult to write compilers that gave good performance? Was > the language specification too complex or difficult to implement? Most of this has to deal with history. C was designed for ease of implementation; Ada was designed for safety, predictability, portability and maintainability. Of course, Ada compilers are more difficult to write than C compilers. This is a Good Thing; it means that Ada compilers do more work for you than do C compilers. C++ compilers are quite hard to get right; but then again, so are C++ programs. In the early 1980's, the DoD mandated use of Ada for most new software development. Contractors used to provide expensive, proprietary, and slow compilers just because the DoD mandated it. In return, their compilers were Validated, i.e. certified to conform to the Ada 83 standard. There were a few vendors that did not actually believe in Ada and offered only "check-box compilers" - compilers barely good enough to check a box saying "yes, we support Ada" in a form, but lacking any real features or tools for serious development. But things have changed since then. The "check-box" vendors have all but disappeared; the remaining Ada vendors are all quite serious about Ada and software quality. The Ada language evolved into a powerful object-oriented language (Ada 95) without losing any of its inherent safety, and a new standard (Ada 2005) is in the works for even more improvements. There are several good, inexpensive Ada compilers to choose from. One such compiler is even free, both in the sense of freedom and free beer. > Or are there simply missing features that preclude some efficient > coding idioms (does Ada have pointers?). I'm very ignorant when it > comes to Ada so please forgive these newbie questions. Yes, Ada does have pointers. They're called "access types" in Ada. In Ada 95, "access to subprograms" were added among other things. The "guru" you mentioned ought to know that. The only feature that I think Ada lacks is functional programming; apart from that, it has everything C++ has, and more (don't talk to me about multiple inheritance before you've read Tucker Taft's paper on the subject). I think that Ada is still entrenched, and thrives in safety-critical environments, but these environments are traditionally neither Free Software nor commercial-off-the-shelf. As a result, the millions of lines of Ada programs out there that fly aircraft, run trains, or control nuclear power stations remain largely unknown to the general public. I think that Ada deserves more exposure by means of more Free Software and more COTS software. There *are* quite a few available free software packages out there, but not nearly as many as in other languages. Quality compensates for that, IMHO, but there is still the nagging impression that Ada is being ignored by the masses. I appreciate that you took the time to ask questions here rather than just take some uninformed bloke's word for it. I have found that the people interested in Ada tend to be independent thinkers. A scarcity nowadays. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 22:24 ` Ludovic Brenta @ 2004-08-16 22:30 ` Ed Falis 2004-08-17 6:13 ` Keith H Duggar 1 sibling, 0 replies; 387+ messages in thread From: Ed Falis @ 2004-08-16 22:30 UTC (permalink / raw) On Tue, 17 Aug 2004 00:24:24 +0200, Ludovic Brenta <ludovic.brenta@insalien.org> wrote: > There *are* quite a few available > free software packages out there, but not nearly as many as in other > languages. And Ludovic is one of the heroes because he packages Ada development tools for Debian ;-) - Ed -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 22:24 ` Ludovic Brenta 2004-08-16 22:30 ` Ed Falis @ 2004-08-17 6:13 ` Keith H Duggar 2004-08-17 20:13 ` Ludovic Brenta 1 sibling, 1 reply; 387+ messages in thread From: Keith H Duggar @ 2004-08-17 6:13 UTC (permalink / raw) > I wouldn't consider whoever said that a guru. A real guru > keeps posted about new developments > > ... > > Yes, Ada does have pointers. They're called "access types" > in Ada. In Ada 95, "access to subprograms" were added among > other things. The "guru" you mentioned ought to know that. Unfortunately, I think my comment was a little vague. I didn't mean to imply he was an Ada guru. Rather a guru of C/C++ and C/C++ compiler implementation. However, he had once commented positively on Ada so I thought he might be able to give me some insight on Ada from a C/C++ perspective since that was my strongest background. Also, I mentioned pointers not because he had mentioned them but rather because I was trying to think of "performance" related features. > The Ada language evolved into a powerful > object-oriented language (Ada 95) without losing any of its inherent > safety, and a new standard (Ada 2005) is in the works for even more > improvements. There are several good, inexpensive Ada compilers to > choose from. One such compiler is even free, both in the sense of > freedom and free beer. Excellent on both accounts! I look forward to seeing what comes out of the the new standard. And is this the GNAT compiler you are referring to? Would that be a good choice me to get a first taste of Ada? > I think that Ada deserves more exposure by means of more > Free Software and more COTS software. I don't know enough to support that generally; but, on a personal basis I sure wish I had been exposed to Ada more and earlier. > I appreciate that you took the time to ask questions here > rather than just take some uninformed bloke's word for it. > I have found that the people interested in Ada tend to be > independent thinkers. Thank you. And thank you for taking the time to respond. > A scarcity nowadays. You definitely won't get any argument from me there. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 6:13 ` Keith H Duggar @ 2004-08-17 20:13 ` Ludovic Brenta 0 siblings, 0 replies; 387+ messages in thread From: Ludovic Brenta @ 2004-08-17 20:13 UTC (permalink / raw) (Keith H Duggar) writes: > Also, I mentioned pointers not because he had mentioned them but > rather because I was trying to think of "performance" related > features. As Marin mentioned, performance is not a good reason to use access types; the compiler chooses how to pass parameters (by value, by reference, or in registers), and you can trust it to make the best decision. The language rules also allow you to force by-reference parameter passing without using access types (e.g. with limited types). In object-oriented programming, you also do not need pointers to do dispatching of subprograms. Tagged types (the Ada equivalent of a C++ class) are always passed by reference, too, without any explicit pointers. You use access types primarily when you build dynamic data structures like linked lists. > Excellent on both accounts! I look forward to seeing what comes out > of the the new standard. And is this the GNAT compiler you are > referring to? Would that be a good choice me to get a first taste of > Ada? Yes, I was alluding to GNAT. And if you'll allow me another of my customary shameless plugs here, I'd suggest you try Debian [1] as your development platform. One of the problems people face when they try Ada is that they have to hunt the Internet to find compilers, libraries and documentation, and that they sometimes have to compile everything by hand. Debian solves that for you; with "apt-get" you can install about 1 million lines of code's worth of Ada software, all pre-compiled and configured for you. If you use Windows, my friend Stéphane Rivière has a similar distribution called AIDE [2,3] waiting for you. (end of shameless plug :) ) [1] http://www.debian.org [2] http://eig.unige.ch/lii/Aide.htm [3] http://stephane.rochebrune.org Oh BTW, are you aware of the main Ada portals? They'll get you to a wealth of documentation, software and info. [4] http://www.adaic.org [5] http://www.adapower.org [6] http://www.adaworld.com [7] http://libre.act-europe.fr -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 21:09 ` Keith H Duggar 2004-08-16 22:24 ` Ludovic Brenta @ 2004-08-16 22:26 ` Ed Falis 2004-08-17 6:28 ` Keith H Duggar 2004-08-17 7:50 ` Dmitry A. Kazakov ` (2 subsequent siblings) 4 siblings, 1 reply; 387+ messages in thread From: Ed Falis @ 2004-08-16 22:26 UTC (permalink / raw) On 16 Aug 2004 14:09:41 -0700, Keith H Duggar <duggar@mit.edu> wrote: Keith, I'll take a shot at it, though understand this is just my opinion. (However, I've been in the compiler and real-time executive side of the business since 1981). > "Ada was an experiment that failed. It was specified in such a way > that it's hard to get adequate performance. So a critical mass of > users and vendors never materialized. Now we see people devoting more > energy to making C/C++ safer for programming large systems." > Can any of you help me understand the details behind what he > stated? Was it difficult to write compilers that gave good > performance? Was the language specification too complex or > difficult to implement? The language was not specified in such a way that good performance couldn't be achieved. But at the time (early 80's), it was ambitious enough that it went out onto the bleeding edge of implementation techniques. It tried to work at a level of abstraction that was a bit pressing for the HW resources of the day, and tried to solve software development problems that other languages did not. The compiler itself went way beyond the usual expectations for compilers of the time in detecting semantic problems in applications. That said, you would be hard-pressed to find significant performance differences from C++ in areas where they overlap. (There are a number of language-defined capabilities in Ada that are addressed by libraries in C++, or which fall outside the standard of the latter - and less so, vice-versa). > Or are there simply missing features that preclude some > efficient coding idioms (does Ada have pointers?). I'm > very ignorant when it comes to Ada so please forgive these > newbie questions. Ada has pointers, but the abstraction is a bit "safer" / "more restricted" than in C or in C++ - not too different from Java, which appears to have been influenced by many of the ideas in Ada. Ada was an attempt to summarize best practice at the time it was designed. It's still a beautiful language, and was much improved by its 1995 revision. It is also in the process of a current revision, which should finalize next year. Check it out further - like many recent newcomers, you may find yourself becoming an aficionado. You can see, of course, that I consider your "expert"'s opinion to be biased and inaccurate. - Ed -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 22:26 ` Ed Falis @ 2004-08-17 6:28 ` Keith H Duggar 2004-08-17 13:30 ` Ed Falis 2004-08-18 3:30 ` Dale Stanbrough 0 siblings, 2 replies; 387+ messages in thread From: Keith H Duggar @ 2004-08-17 6:28 UTC (permalink / raw) Ed, > That said, you would be hard-pressed to find significant > performance differences from C++ in areas where they > overlap. Indeed, I was having a little trouble seeing how they could differ greatly in speed. It seems to me that Ada and C++ share a lot of "performance" related features such as static typing, "access" types, and generics. So it seems entirely reasonable that they are comparable in performance. Also, I could even believe that the more restricted "access" types vs pointers and built-in support for concurrency rather than library based concurrency could actually give Ada an edge in certain areas. > (There are a number of language-defined capabilities > in Ada that are addressed by libraries in C++, or which fall > outside the standard of the latter - and less so, vice-versa). If you have the time, could you give me some examples of these? In particular, examples of C++ capabilities that aren't built-in to Ada would help me to get a better feel for Ada in relation to what I already know and use (C++). Thank you for the help, Keith ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 6:28 ` Keith H Duggar @ 2004-08-17 13:30 ` Ed Falis 2004-08-17 13:38 ` Martin Dowie 2004-08-18 3:30 ` Dale Stanbrough 1 sibling, 1 reply; 387+ messages in thread From: Ed Falis @ 2004-08-17 13:30 UTC (permalink / raw) On 16 Aug 2004 23:28:34 -0700, Keith H Duggar <duggar@mit.edu> wrote: > If you have the time, could you give me some examples of these? > In particular, examples of C++ capabilities that aren't built-in > to Ada would help me to get a better feel for Ada in relation to > what I already know and use (C++). Ada: integrated concurrency annexes providing more specific semantics for common application domains (eg real-time, info systems) more specific classes of predefined types (eg fixed, decimal) explicit support for interfacing to other languages separate control over visibility and inheritance (as against "classes") safety-oriented semantics by default with syntactically well-flagged escapes C++: STL (though Ada '05 will have a standard collections suite) Explicit syntax for multiple inheritance (Ada requires building it up at the application level) relatively unrestricted semantics by default, with the ability to construct safe abstractions more flexible templates I'm sure others will join in. -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 13:30 ` Ed Falis @ 2004-08-17 13:38 ` Martin Dowie 0 siblings, 0 replies; 387+ messages in thread From: Martin Dowie @ 2004-08-17 13:38 UTC (permalink / raw) Ed Falis wrote: > C++: > > STL (though Ada '05 will have a standard collections suite) > Explicit syntax for multiple inheritance (Ada requires building it up > at the application level) Ada0Y should/will have multiple inheritance through interfaces (a la Java). Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 6:28 ` Keith H Duggar 2004-08-17 13:30 ` Ed Falis @ 2004-08-18 3:30 ` Dale Stanbrough 1 sibling, 0 replies; 387+ messages in thread From: Dale Stanbrough @ 2004-08-18 3:30 UTC (permalink / raw) Keith H Duggar wrote: > > (There are a number of language-defined capabilities > > in Ada that are addressed by libraries in C++, or which fall > > outside the standard of the latter - and less so, vice-versa). > > If you have the time, could you give me some examples of these? > In particular, examples of C++ capabilities that aren't built-in > to Ada would help me to get a better feel for Ada in relation to > what I already know and use (C++). > > Thank you for the help, Multiple inheritance. Constructor/Destructors that don't require inheriting from a fixed class. In place constructors i.e. you don't have to have a function that then copies the new object. I seem to remember that compilers could remove the copy as an optimisation. Anyone care to comment? Templates that can calculate a *lot* of stuff at compile time. (you can multiply matrices using a = b * c; notation with no copying). The #include model for including files in C++ means that there isn't a problem with recursively defined types in different files. and Keith H Duggar also wrote: > Excellent on both accounts! I look forward to seeing what > comes out of the the new standard. And is this the GNAT > compiler you are referring to? Would that be a good choice > me to get a first taste of Ada? Gnat is an excellent compiler and has the best error messages I have ever seen in a compiler. I groan every time I have to use the junk they call a Java compiler. The GNU C compiler is not much better. > > I don't know enough to support that generally; but, on a > personal basis I sure wish I had been exposed to Ada more > and earlier. Have a look at my notes at... http://www.adaware.net.au/ for a good discussion. Let me know if you would like to see more info in the notes. Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 21:09 ` Keith H Duggar 2004-08-16 22:24 ` Ludovic Brenta 2004-08-16 22:26 ` Ed Falis @ 2004-08-17 7:50 ` Dmitry A. Kazakov [not found] ` <mfb4i09d5kqk8fjdfmrj62kgmooftf1ma8@4ax.com> 2004-08-26 5:22 ` Dave Thompson 2004-08-17 10:58 ` Marin David Condic 2004-08-17 23:54 ` Kevin Cline 4 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-17 7:50 UTC (permalink / raw) On 16 Aug 2004 14:09:41 -0700, Keith H Duggar wrote: > "Ada was an experiment that failed. It was specified in such a way > that it's hard to get adequate performance. Theoretically Ada has better support for optimizations than C. For example, in C you can get pointer to any object. This assumes that compiler is restricted in how and where it allocates them. In Ada an object has to be "aliased" to allow that. Another example is for Index in A'Range loop A (I) := ... -- There is no need to check array bounds Yet another example, in C++ any call to a virtual function is dispatching. In Ada it is only when the object is class-wide. For an OO application the difference in terms performance could be huge. > Or are there simply missing features that preclude some > efficient coding idioms (does Ada have pointers?). I'm > very ignorant when it comes to Ada so please forgive these > newbie questions. Yes, Ada has pointers, and interestingly, because that wasn't design intent, richer than C++ has. 1. Ada has specific and class-wide pointers. In C++ all pointers are class-wide. Dereferenced class-wide pointers dispatch on member functions. In Ada you have a choice. 2. Ada has anonymous pointers. It is difficult to find any equivalent in C++, because it has many limitations Ada does not have. It is something like: class X // This is not C++! { public : friend void Foo (int Something, virtual X * This); 3. Ada has pool-specific and general access pointers. A rough C++ equivalent would be operators new and operator delete. But Ada is more flexible here, its "new" is attached not to the object type, but to the pointer one. So you can have many pools of objects of same type. 4. Ada pointers are true types. In C++ pointers have structure equivalence. The difference appears when building large libraries. Consider objects of type X to be sorted using different ways. In Ada you can: type X_By_Name is access X; -- Pointer to X function "<" (Left, Right : X_By_Name) return Boolean; -- Dereferences and compares names type X_By_Value is access X; -- Another pointer to X function "<" (Left, Right : X_By_Values) return Boolean; -- Dereferences and compares values Now, you can instantiate a Sort procedure once with X_By_Name and its "<" and once with X_By_Value and its "<". The result is two different sorts with no extra control parameters to pass and no subsequent parameter checks. 5. Ada pointers are transparent to member extraction and array indexing. I.e. in Ada "->" and "." are same. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
[parent not found: <mfb4i09d5kqk8fjdfmrj62kgmooftf1ma8@4ax.com>]
* Re: ADA Popularity Discussion Request [not found] ` <mfb4i09d5kqk8fjdfmrj62kgmooftf1ma8@4ax.com> @ 2004-08-18 8:58 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-18 8:58 UTC (permalink / raw) On Tue, 17 Aug 2004 16:30:45 GMT, Dennis Lee Bieber wrote: > On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> declaimed the following in comp.lang.ada: > >> >> for Index in A'Range loop >> A (I) := ... -- There is no need to check array bounds >> > Where'd the "I" come from... I suspect you mean > > A(Index) := ... Yes, of course -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 7:50 ` Dmitry A. Kazakov [not found] ` <mfb4i09d5kqk8fjdfmrj62kgmooftf1ma8@4ax.com> @ 2004-08-26 5:22 ` Dave Thompson 2004-08-26 8:06 ` Dale Stanbrough 2004-08-26 8:14 ` Dmitry A. Kazakov 1 sibling, 2 replies; 387+ messages in thread From: Dave Thompson @ 2004-08-26 5:22 UTC (permalink / raw) On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: > On 16 Aug 2004 14:09:41 -0700, Keith H Duggar wrote: > > > "Ada was an experiment that failed. It was specified in such a way > > that it's hard to get adequate performance. > > Theoretically Ada has better support for optimizations than C. For example, > in C you can get pointer to any object. This assumes that compiler is > restricted in how and where it allocates them. In Ada an object has to be In C if you declare with storage-class 'register' its address cannot be taken and so it cannot be aliased, since C also does not have call-by-reference. This is not quite as easy and not as clear, but it works. But not in C++; there 'register' exists for compatibility with C but is overridden by prefix&. For a local or 'static' (private to source file/module ~= package) variable, even if not declared register, the compiler can usually determine that its address is never taken or at least never exported. In C99 you can declare a pointer 'restrict' meaning the compiler may assume its target is unaliased (within scope) -- but it's your (the programmer's) responsibility to ensure that, it doesn't check for you. > "aliased" to allow that. Another example is > > for Index in A'Range loop > A (I) := ... -- There is no need to check array bounds > Of course in C there aren't required to be, and almost never are, any bounds checks in the first place. Nor in C++ for builtin arrays, but you can get them with std::vector or your own array-like classes. > Yet another example, in C++ any call to a virtual function is dispatching. > In Ada it is only when the object is class-wide. For an OO application the > difference in terms performance could be huge. > See below. > > Or are there simply missing features that preclude some > > efficient coding idioms (does Ada have pointers?). I'm > > very ignorant when it comes to Ada so please forgive these > > newbie questions. > > Yes, Ada has pointers, and interestingly, because that wasn't design > intent, richer than C++ has. > > 1. Ada has specific and class-wide pointers. In C++ all pointers are > class-wide. Dereferenced class-wide pointers dispatch on member functions. > In Ada you have a choice. > C++ pointers and references are polymorphic, but you can "narrow" them for a specific call by ptr-> /* or ref . */ base:: method (args). > 2. Ada has anonymous pointers. It is difficult to find any equivalent in > C++, because it has many limitations Ada does not have. It is something > like: > > class X // This is not C++! > { > public : > friend void Foo (int Something, virtual X * This); > > 3. Ada has pool-specific and general access pointers. A rough C++ > equivalent would be operators new and operator delete. But Ada is more > flexible here, its "new" is attached not to the object type, but to the > pointer one. So you can have many pools of objects of same type. > Yep. You can write your own pool-bound pointer type (sub)classes in or for a class in C++ if you want, and I think even a (nondefault) operator new that selects them, something like the (optional, and AFAIK rarely used) 'allocator's on standard library containers and streams. You would get locality and free-all-at-once, but it is very unlikely the compiler would figure out to make them pool-relative and give you optimized representation or access. Except, for the very restricted case of (sub)allocating within a array of fixed or bounded size you could make a smart "pointer" that is really just a subscript. > 4. Ada pointers are true types. In C++ pointers have structure equivalence. More: all C++ constructed types (pointer, reference, array, function) have structural equivalence except named (or uniquely typedef'ed) classes, unions, and enums. > The difference appears when building large libraries. Consider objects of > type X to be sorted using different ways. In Ada you can: > > type X_By_Name is access X; -- Pointer to X > function "<" (Left, Right : X_By_Name) return Boolean; > -- Dereferences and compares names > > type X_By_Value is access X; -- Another pointer to X > function "<" (Left, Right : X_By_Values) return Boolean; > -- Dereferences and compares values > > Now, you can instantiate a Sort procedure once with X_By_Name and its "<" > and once with X_By_Value and its "<". The result is two different sorts > with no extra control parameters to pass and no subsequent parameter > checks. > Not as conveniently, but you can write pointer classes that are distinct types yet collapse (inline if you like) to actual pointers: struct X { int y,z; }; class X_By_y { X* x; public: /*ctor*/X_By_y (X* xx) : x(xx) {} int operator< (X_By_y that) { return x->y < that.x->y; } }; class X_By_z { X* x; public: /*ctor*/X_By_z (X* xx) : x(xx) {} int operator< (X_By_z that) { return x->z < that.x->z; } }; > 5. Ada pointers are transparent to member extraction and array indexing. > I.e. in Ada "->" and "." are same. Again you can write a smart pointer to do this if you want, but I consider it only a minor convenience. - David.Thompson1 at worldnet.att.net ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 5:22 ` Dave Thompson @ 2004-08-26 8:06 ` Dale Stanbrough 2004-08-26 13:37 ` Martin Krischik 2004-08-26 8:14 ` Dmitry A. Kazakov 1 sibling, 1 reply; 387+ messages in thread From: Dale Stanbrough @ 2004-08-26 8:06 UTC (permalink / raw) Dave Thompson <david.thompson1@worldnet.att.net> wrote: > > 5. Ada pointers are transparent to member extraction and array indexing. > > I.e. in Ada "->" and "." are same. > > Again you can write a smart pointer to do this if you want, but I > consider it only a minor convenience. I (for one!) don't like this aspect of Ada. I prefer the model adopted by Pascal or C where you dereference explicitly. Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 8:06 ` Dale Stanbrough @ 2004-08-26 13:37 ` Martin Krischik 0 siblings, 0 replies; 387+ messages in thread From: Martin Krischik @ 2004-08-26 13:37 UTC (permalink / raw) Dale Stanbrough wrote: > Dave Thompson <david.thompson1@worldnet.att.net> wrote: > >> > 5. Ada pointers are transparent to member extraction and array >> > indexing. I.e. in Ada "->" and "." are same. >> >> Again you can write a smart pointer to do this if you want, but I >> consider it only a minor convenience. > > I (for one!) don't like this aspect of Ada. I prefer the model > adopted by Pascal or C where you dereference explicitly. Then you should try the new GNAT on gcc 3.4.1 - there is a warning now against implicid dereferencing Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 5:22 ` Dave Thompson 2004-08-26 8:06 ` Dale Stanbrough @ 2004-08-26 8:14 ` Dmitry A. Kazakov 2004-08-26 17:28 ` Hyman Rosen 1 sibling, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-26 8:14 UTC (permalink / raw) On Thu, 26 Aug 2004 05:22:17 GMT, Dave Thompson wrote: > On Tue, 17 Aug 2004 09:50:07 +0200, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> wrote: >> 1. Ada has specific and class-wide pointers. In C++ all pointers are >> class-wide. Dereferenced class-wide pointers dispatch on member functions. >> In Ada you have a choice. >> > C++ pointers and references are polymorphic, Except that in constructors / destructors... Hyman Rosen would disagree with me, but I believe it was a design fault. IMO the only consistent way is to distinguish specific and class-wide objects as Ada does. > but you can "narrow" them > for a specific call by ptr-> /* or ref . */ base:: method (args). Yes, but that is not a new pointer type. It is just way to circumvent vptr. [ Discussion point: there should be no need to specify the parent type anywhere, except that once in the type declaration. Unfortunately neither Ada nor C++ fulfill that. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 8:14 ` Dmitry A. Kazakov @ 2004-08-26 17:28 ` Hyman Rosen 0 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-26 17:28 UTC (permalink / raw) Dmitry A. Kazakov wrote: >>C++ pointers and references are polymorphic, > > Except that in constructors / destructors... Hyman Rosen would disagree > with me, but I believe it was a design fault. Yes, we've had our discussions on that. But just to be precise, C++ pointers and references *are* polymorphic even within [cd]tors, but the class to which they are polymorphic is the class of the [cd]tor which is currently active. extern "C" int printf(const char *, ...); struct A { virtual void f() { printf("A"); } void g() { f(); } A() { g(); } }; struct B : A { virtual void f() { printf("B"); } B() { g(); } }; struct C : B { virtual void f() { printf("C"); } C() { g(); } }; int main() { C c; } // prints ABC ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 21:09 ` Keith H Duggar ` (2 preceding siblings ...) 2004-08-17 7:50 ` Dmitry A. Kazakov @ 2004-08-17 10:58 ` Marin David Condic 2004-08-17 11:33 ` Martin Dowie 2004-08-17 12:33 ` Georg Bauhaus 2004-08-17 23:54 ` Kevin Cline 4 siblings, 2 replies; 387+ messages in thread From: Marin David Condic @ 2004-08-17 10:58 UTC (permalink / raw) Keith H Duggar wrote: > > If I may explain. I'm a proficient C++ coder and have been > using it for scientific research coding for eight years. And > I have experience with various other languages including C > and Fortran. I think you will find that Ada is a really wonderful language for scientific programming. It has excellent support for mathematical programming. (Look at the attributes for floating point numbers, for example.) The only area I could think of it being weak in that regard is perhaps having a plethora of mathematical libraries already in existence. They do exist, but probably not in the number they do in Fortran and to my disappointment, there are not a large number of math libraries (beyond log and trig stuff) that are either part of the standard or so ingrained that they might as well be part of the standard. Still, with all the numeric types, standard attributes and other features, if you want mathematical precision, Ada can give it to you. > > "Ada was an experiment that failed. It was specified in such a way > that it's hard to get adequate performance. So a critical mass of > users and vendors never materialized. Now we see people devoting more > energy to making C/C++ safer for programming large systems." > "Failed" may be a bit of a relative term. I don't think it achieved its stated goals, but it is still used in a variety of places for its inherent advantages. It is certainly not as big a language as I think it ought to be given its merits and the ammount of money thrown at it. As for inherent inefficiency, this is largely a myth. Part of the problem was that 'Back In The Day..." Ada had a lot of new concepts that compiler writers didn't thoroughly understand. It also had lots of implied runtime checking going on that added overhead to executable code. The thing is that fundamentally, all of its structures *can* be implemented efficiently and these days, they typically are. Runtime checks *can* be turned off when you want efficiency and, for the small number of applications where it makes a difference, they typically are disabled. So the efficiency thing kind of came about because of bad initial implementations and was fueled by people looking for excuses not to use the language. Now, this is not true, but its hard to overcome the bad reputation. If you want proof by demonstration, get the free Gnat compiler and do some benchmarking with it. Its also a C compiler. Write some example code typical of what you do and clock it. Chances are, *if* you learn to use the compiler effectively (setting the optimization switches, turning off checks, etc.) you'll find it is competitive with equivalent C code. > Can any of you help me understand the details behind what he > stated? Was it difficult to write compilers that gave good > performance? Was the language specification too complex or > difficult to implement? > Back in 1983, Ada rather exceeded the capacity of existing computer hardware and strained the limits of compiler technology. Sooner or later, both caught up and these days, efficiency is hardly a concern. > Or are there simply missing features that preclude some > efficient coding idioms (does Ada have pointers?). I'm > very ignorant when it comes to Ada so please forgive these > newbie questions. > Naturally, Ada has pointers. They are called "access types". Be aware that usually when a C/C++ programmer starts talking about pointers from an efficiency standpoint, they mean as a mechanism for passing parameters to subroutines. This is because C was developed at a really primitive level. Compilers are perfectly capable of deciding that a data structure is too big to pass on the stack and will generate a reference automagically for you. No need to fuss with dereferencing pointer parameters inside your subroutines, etc. Its all done behind the scenes. *Trust* the compiler in that regard and learn to use it effectively. Ada programs typically use pointers a *lot* less than do C/C++ programs because they don't need them. However, when you want to build linked data structures or other things where pointers are needed, Ada has them. Just don't try to write C++ code in Ada syntax or you'll find it is really tough to do. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 10:58 ` Marin David Condic @ 2004-08-17 11:33 ` Martin Dowie 2004-08-17 11:59 ` Marin David Condic 2004-08-17 12:33 ` Georg Bauhaus 1 sibling, 1 reply; 387+ messages in thread From: Martin Dowie @ 2004-08-17 11:33 UTC (permalink / raw) Marin David Condic wrote: > Ada programs typically use pointers a *lot* less than do C/C++ > programs because they don't need them. However, when you want to > build linked > data structures or other things where pointers are needed, Ada has > them. Just don't try to write C++ code in Ada syntax or you'll find > it is really tough to do. And the need for doing this deminishes further with the inclusion of standard containers, see http://www.martin.dowie.btinternet.co.uk/ for an Ada95 implementation of the proposed new Ada0Y container libraries - there are (doubly linked) lists, vectors, (ordered) sets and (hashed) maps. Indefinate versions of each are available too. Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 11:33 ` Martin Dowie @ 2004-08-17 11:59 ` Marin David Condic 2004-08-17 12:49 ` Martin Dowie 0 siblings, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-08-17 11:59 UTC (permalink / raw) Looks like good work & hopefully something that will be built upon & extended to include new capabilities. I suspect that Ada0Y is not going to allow the garden variety programmer to extend packages under the "Ada..." tree, so it is hard to imagine "growth" without some sort of agreed upon support from the compiler vendors. Still, one could imagine work being done under a different, independent branch with the possibility that in "Ada1Z" a given branch might be drawn into the standard if it proves to be something generally useful, standardizable and portable to a variety of implementations. I still think there is good reason to have some kind of "supplimental standard" library that exists as a reference implementation that is allowed to grow & change at a faster rate than updates to the Ada standard allow - but its looking like there is at least a good start in that general direction... BTW: I like the fact that there is an HTML "user's manual" written up for it. Hopefully, there might evolve from that some sort of "Ada Library Usage For Smart People (because the "dummies" are using C)" book. Its wonderful to have a user's manual that lays out what each operation does, but an example guide with practical applications can be a real plus for actually getting people to use it. MDC Martin Dowie wrote: > > And the need for doing this deminishes further with the inclusion of > standard containers, see http://www.martin.dowie.btinternet.co.uk/ for an > Ada95 implementation of the proposed new Ada0Y container libraries - there > are (doubly linked) lists, vectors, (ordered) sets and (hashed) maps. > Indefinate versions of each are available too. > > Cheers > > -- Martin > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 11:59 ` Marin David Condic @ 2004-08-17 12:49 ` Martin Dowie 2004-08-17 13:07 ` Marin David Condic 0 siblings, 1 reply; 387+ messages in thread From: Martin Dowie @ 2004-08-17 12:49 UTC (permalink / raw) Marin David Condic wrote: > Looks like good work & hopefully something that will be built upon & > extended to include new capabilities. I suspect that Ada0Y is not > going to allow the garden variety programmer to extend packages under > the "Ada..." tree, so it is hard to imagine "growth" without some > sort of agreed upon support from the compiler vendors. Still, one > could imagine work being done under a different, independent branch > with the possibility that in "Ada1Z" a given branch might be drawn > into the standard if it proves to be something generally useful, > standardizable and portable to a variety of implementations. I've already approached Jim Moore of "WG9" about setting up a "IWA" that might be used to expand on what is proposed for Ada0Y, e.g. Algorithms for the containers (these were part of the original 'Charles' library) or new containers (Fibonacci Heaps anyone?). Note, there is currently nothing to stop you adding whatever you like as a /grandchild/ of Ada - you just can't add a child to package "Ada" in 'normal mode'. > I still think there is good reason to have some kind of "supplimental > standard" library that exists as a reference implementation that is > allowed to grow & change at a faster rate than updates to the Ada > standard allow - but its looking like there is at least a good start > in that general direction... That is a possibility with the "IWA". It does /*NOT*/ make it part of the standard but it could be used as a basis for inclusion. > BTW: I like the fact that there is an HTML "user's manual" written up > for it. Hopefully, there might evolve from that some sort of "Ada > Library Usage For Smart People (because the "dummies" are using C)" > book. Its wonderful to have a user's manual that lays out what each > operation does, but an example guide with practical applications can > be a real plus for actually getting people to use it. Thanks, I did that myself - that's not part of the 'normal' AI process :-) It's actually the text of the AI copied into the source code (by hand!) and into "AdaBrowse" format (big "hello" to Thomas Wolf!). If I get time I'll embed more examples from the AI or from elsewhere. Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 12:49 ` Martin Dowie @ 2004-08-17 13:07 ` Marin David Condic 2004-08-19 14:53 ` Martin Dowie 0 siblings, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-08-17 13:07 UTC (permalink / raw) Martin Dowie wrote: > > > That is a possibility with the "IWA". It does /*NOT*/ make it part of > the standard but it could be used as a basis for inclusion. > That's good news. I think the key here is that Ada needs to be able to add new functionality at a faster rate than every ten years. Any scheme that helps do that would be a good thing so long as the vendors go along with it. > > Thanks, I did that myself - that's not part of the 'normal' AI > process :-) It's actually the text of the AI copied into the source > code (by hand!) and into "AdaBrowse" format (big "hello" to Thomas > Wolf!). > > If I get time I'll embed more examples from the AI or from elsewhere. > > Give some thought to some kind of "textbook" format. User's guides are nice if you already know basically how to use the library and just want to look up the specifics of what a call to some subroutine does. But something that addresses "What the heck to I *do* with this package???" might help people get started with it. You know: "Suppose you want to maintain a mailing list of people and search it based on last name..." Explaining how to do that with a container library and pointing at code or code snippets can be invaluable to a new user. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 13:07 ` Marin David Condic @ 2004-08-19 14:53 ` Martin Dowie 0 siblings, 0 replies; 387+ messages in thread From: Martin Dowie @ 2004-08-19 14:53 UTC (permalink / raw) Marin David Condic wrote: > Give some thought to some kind of "textbook" format. User's guides are > nice if you already know basically how to use the library and just > want to look up the specifics of what a call to some subroutine does. > But something that addresses "What the heck to I *do* with this > package???" might help people get started with it. You know: "Suppose > you want to maintain a mailing list of people and search it based on > last name..." Explaining how to do that with a container library and > pointing at code or code snippets can be invaluable to a new user. Part of the problem with writing examples is that the _best_ way to use the library will come with the new access level rules wrt access to subprograms. Just now we have the 'cludgy' Ada95 ways, e.g. procedure Process (C : Cursor) is begin ... end Process; procedure Do_Something (V : Vector) is begin Iterate (V, Process'Access); end Do_Something; Can become procedure Do_Something (V : Vector) is procedure Process (C : Cursor) is begin ... end Process; begin Iterate (V, Process'Access); end Do_Something; Which is a bit nicer... However, since the versions I'm providing are Ada95, I guess I could try and write up something in that style but with a very large health warning! :-) Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 10:58 ` Marin David Condic 2004-08-17 11:33 ` Martin Dowie @ 2004-08-17 12:33 ` Georg Bauhaus 2004-08-17 12:54 ` Marin David Condic 2004-08-17 12:58 ` Martin Dowie 1 sibling, 2 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-17 12:33 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> wrote: : The only area I could think of it being weak in that regard is : perhaps having a plethora of mathematical libraries already in : existence. The next standard may provide some more: http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17 -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 12:33 ` Georg Bauhaus @ 2004-08-17 12:54 ` Marin David Condic 2004-08-26 1:27 ` Randy Brukardt 2004-08-17 12:58 ` Martin Dowie 1 sibling, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-08-17 12:54 UTC (permalink / raw) Again, more good news. Vector and matrix math included as a standard annex of some form would add functionality & help encourage people to make use of Ada. Personally, I think there is enough grist for the mill in the area of mathematics that there could be a lot more than just vector and matrix functionality added. As the item you cite observes, the packages can be implemented in "pure" Ada and hence should pose no problems to adoption. I'd disagree where it says: "Providing secondary standards has not proved satisfactory because they are not sufficiently visible to the user community as a whole." Maybe historically, and to a point. The question is "Would people use a secondary standard if it was blessed by Ada and included with most/all compilers?" Perhaps people have avoided "secondary standards" because they aren not viewed as "sufficiently standard"? They ask "Can I count on this to be portable to some other implementation?" If it comes with most/all implementations, then the answer is "Yes". If its just someone's blob of code out there somewhere with no "official" standing and it is their problem to insure it works on their platform/compiler then they may avoid it out of fear that it will cost too much or take too long to deal with it themselves & opt for their own implementation because they at least understand and control it. One might also ask if the "secondary standards" are "good" standards? I've seen lots of standards that were so overly complex that people have difficulty understanding how they work and what to do with them. It is critical that they be sufficiently clear, easy to use and well documented or the burden of trying to utilize them is less than that needed to roll your own. MDC Georg Bauhaus wrote: > > The next standard may provide some more: > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17 > > > -- Georg -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "All reformers, however strict their social conscience, live in houses just as big as they can pay for." --Logan Pearsall Smith ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 12:54 ` Marin David Condic @ 2004-08-26 1:27 ` Randy Brukardt 2004-08-26 11:49 ` Marin David Condic 0 siblings, 1 reply; 387+ messages in thread From: Randy Brukardt @ 2004-08-26 1:27 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:4121FFF1.80404@noplace.com... > Again, more good news. Vector and matrix math included as a standard > annex of some form would add functionality & help encourage people to > make use of Ada. Personally, I think there is enough grist for the mill > in the area of mathematics that there could be a lot more than just > vector and matrix functionality added. As the item you cite observes, > the packages can be implemented in "pure" Ada and hence should pose no > problems to adoption. > > I'd disagree where it says: "Providing secondary standards has not > proved satisfactory because they are not sufficiently visible to the > user community as a whole." Maybe historically, and to a point. The > question is "Would people use a secondary standard if it was blessed by > Ada and included with most/all compilers?" It says that because of history. AI-296 is a slightly modified copy of a standard that has existed for roughly 10 years. When it came up for its 5 year review, many of the people in the WG9 meeting (myself included) had never ever heard of it. There are no known implementations. It's clear that historically at least, secondary standards like this might as well not exist. I think that the implementation rate will go from roughly 0% of all vendors to near 100% of all vendors simply by including it in the primary standard. There have been exceptions to the rule that secondary standards are widely ignored (the original GEF and POSIX 5.a come to mind, but neither of those were ever supported by anywhere near 100% of the compilers), but for the most part, they just don't exist. That goes for users as well - after all, if users demanded support for the standard matrix library, vendors would have given it to them. But users are no more likely to look for and/or know about secondary standards than vendors are. One hopes that an IWA on extending the containers libraries would be more like POSIX than the matrix stuff (and we intend that there is a set of agreed upon extensions for this containers), but there can be no guarantee of that. Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 1:27 ` Randy Brukardt @ 2004-08-26 11:49 ` Marin David Condic 0 siblings, 0 replies; 387+ messages in thread From: Marin David Condic @ 2004-08-26 11:49 UTC (permalink / raw) I would agree, but add this: It is not sufficient to simply create a secondary standard in a vacuum. This is why many independently developed libraries have failed to gain traction. If the vendors of Ada and the standard-makers of Ada and some large users of Ada were to get together and discuss "The Future Strategy For Ada" and agree on a direction & some basic content goals, perhaps something can be made to happen. I can write a standard an put it on the Internet and say "Would some vendor please make this..." but what good does that do? I could write a library (I happen to have some of it in my back pocket) and put it on the internet and say "Would someone please incorporate this as part of Ada and circulate it with all compilers..." but people have done this already with only modest success. (Charles seems to be making its way into the standard, but my complaint is that it a) doesn't go far enough and b) won't get expanded/updated except on a ten year cycle.) Writing a standard for a library is probably not as practical as providing a reference implementation anyway. The "Standard" part should come from Ada's portability and everyone distributing the same thing rather than through a written document. Expanding the possible future for Ada is best done with some major subset of the interested parties working *together* to an agreed-upon course of action. Independent efforts - while noble - are not as likely to get results. MDC Randy Brukardt wrote: > > > It says that because of history. AI-296 is a slightly modified copy of a > standard that has existed for roughly 10 years. When it came up for its 5 > year review, many of the people in the WG9 meeting (myself included) had > never ever heard of it. There are no known implementations. It's clear that > historically at least, secondary standards like this might as well not > exist. > > I think that the implementation rate will go from roughly 0% of all vendors > to near 100% of all vendors simply by including it in the primary standard. > > There have been exceptions to the rule that secondary standards are widely > ignored (the original GEF and POSIX 5.a come to mind, but neither of those > were ever supported by anywhere near 100% of the compilers), but for the > most part, they just don't exist. That goes for users as well - after all, > if users demanded support for the standard matrix library, vendors would > have given it to them. But users are no more likely to look for and/or know > about secondary standards than vendors are. > > One hopes that an IWA on extending the containers libraries would be more > like POSIX than the matrix stuff (and we intend that there is a set of > agreed upon extensions for this containers), but there can be no guarantee > of that. > > Randy. > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 12:33 ` Georg Bauhaus 2004-08-17 12:54 ` Marin David Condic @ 2004-08-17 12:58 ` Martin Dowie 2004-08-17 13:06 ` Martin Dowie 1 sibling, 1 reply; 387+ messages in thread From: Martin Dowie @ 2004-08-17 12:58 UTC (permalink / raw) Georg Bauhaus wrote: >> The only area I could think of it being weak in that regard is >> perhaps having a plethora of mathematical libraries already in >> existence. > > The next standard may provide some more: > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17 And you can get most of it now @ http://www.martin.dowie.btinternet.co.uk/ Not complete but it does cover all the 'everyday' stuff like multiplication/addition. 29 out of 31 subprograms for Real numbers and 71 out of 75 subprogram for Complex numbers. I haven't had much chance to test these but I'm more than happy to hear about any bugs - preferably with a solution attached! ;-). Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 12:58 ` Martin Dowie @ 2004-08-17 13:06 ` Martin Dowie 0 siblings, 0 replies; 387+ messages in thread From: Martin Dowie @ 2004-08-17 13:06 UTC (permalink / raw) Martin Dowie wrote: > And you can get most of it now @ > http://www.martin.dowie.btinternet.co.uk/ > > Not complete but it does cover all the 'everyday' stuff like > multiplication/addition. 29 out of 31 subprograms for Real numbers > and 71 out of 75 subprogram for Complex numbers. > > I haven't had much chance to test these but I'm more than happy to > hear about any bugs - preferably with a solution attached! ;-). You should note that for /really/ good performance from this library in Ada0Y, I think we need to hope that AI-318 also makes it. Cheers -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-16 21:09 ` Keith H Duggar ` (3 preceding siblings ...) 2004-08-17 10:58 ` Marin David Condic @ 2004-08-17 23:54 ` Kevin Cline 2004-08-18 0:30 ` Richard Riehle ` (3 more replies) 4 siblings, 4 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-17 23:54 UTC (permalink / raw) duggar@mit.edu (Keith H Duggar) wrote in message news:<b47de02.0408161309.151f6a53@posting.google.com>... > Greetings all. Thank you for opening this thread I'm very > eager to learn more about Ada. > > If I may explain. I'm a proficient C++ coder and have been > using it for scientific research coding for eight years. And > I have experience with various other languages including C > and Fortran. > > Recently, quite by accident, I ran into the Ada language > having (unfortunately) barely heard of it and having never > seen or been taught anything about it. > > When I first saw Ada I thought wow this looks like an > excellent language. In the very least it is a language that > I wish I had known about much earlier. For example, I wish > Georgia Tech had included Ada in a course of two as they had > included Fortran and C. > > So, after researching a bit on the web I still couldn't find > and explanations for why Ada isn't that popular. I decided > to email a well known programming and compiler guru who had > once commented positively on Ada. I asked why Ada wasn't as > popular as C++ (a language which he is also a guru of). Here > was his reply: > > "Ada was an experiment that failed. It was specified in such a way > that it's hard to get adequate performance. So a critical mass of > users and vendors never materialized. Now we see people devoting more > energy to making C/C++ safer for programming large systems." > > Can any of you help me understand the details behind what he > stated? Was it difficult to write compilers that gave good > performance? Was the language specification too complex or > difficult to implement? I don't your guru got it quite right. Ada failed because most programmers who tried it found Ada programming to be relative less productive than programming in other available languages. Ada never attracted a large enough base of motivated users to develop the libraries and IDEs that would make it easy to use. Even with available public domain compilers, almost no one is choosing to program in Ada. Since Ada was introduced, other new languages like C++ and Perl and Java and C# and Python and Ruby have been relatively successful. While those languages are far from perfect, programmers have learned to work with or around those imperfections, and have found enough other benefits to learn them and use them. In a nutshell, Ada is not popular because most people who have tried it didn't like it. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 23:54 ` Kevin Cline @ 2004-08-18 0:30 ` Richard Riehle 2004-08-18 1:29 ` Björn Persson ` (2 more replies) 2004-08-18 0:37 ` Jeffrey Carter ` (2 subsequent siblings) 3 siblings, 3 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-18 0:30 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0408171554.2f9c48b4@posting.google.com... > > I don't your guru got it quite right. Ada failed because most > programmers who tried it found Ada programming to be relative less > productive than programming in other available languages. Ada never > attracted a large enough base of motivated users to develop the > libraries and IDEs that would make it easy to use. > I wonder why you think Ada is less productive than other available languages. Is it the static typing? Is the ability to define one's own types? Is it the syntax? Is it the way the ALRM is written? Over the years, I have come to the conclusion that a key problem with Ada, in those early days, was that few of those involved in teaching it really understood it well enough to make it clear to those who needed to use it. There are a few simple underlying ideas in the language. One of them is type safety, and that has never been beyond the comprehension of any programmer. The idea that seems to have been difficult to grasp, even by many who consider themselves sophisticated software developers, is the separation of scope and visibility. Chapter Eight of the ALRM is rarely read by anyone, it seems. I recall being at a conference some years ago where someone was giving a tutorial involving Ada. At one point I suggested changing a part of the design to a limited private type. The response, from a member of the technical staff of a well-known compiler publisher, "Oh. We don't design with limited because you can't do anything with a limited type." During nearly twenty years with Ada, I find that more programmers have more trouble with the visibility rules than any other single aspect of the language. Sometimes, I as see a person struggling to overcome those rules, I am reminded of the time during high school when I took a part-time janitorial job and had to learn to use a floor buffer. Anyone who has ever had the experience of a circular floor buffer will know what I am describing. As soon as you take hold of the handle, the buffer goes where it chooses, and no amount of human muscle will overpower it. In fact, the more one tries to control it with brute force, the more it drags you around the room. Eventually, after nearly wrecking the furniture, I discovered that I could take control of the buffer by lightly adjusting its position relative to the floor. In time, I learned to show off by moving the buffer wherever I wanted, using one finger. Instead of fighting the design of the buffer, I learned to accomodate myself to it. Those who had the most difficulty with Ada, and those who continue to have difficulty with it, are often trying to force the language to do things the old way. They are unable to learn how a light touch, using the features of the language, will make one more productive, not less productive. I currently teach Ada in an academic environment. My students are in graduate school and very bright. Many of them have written programs in other languages. When they first encounter Ada, they too want to approach it the way they did other languages. After a short time, they learn the simple ideas behind the design of the language and they learn to like it (most of them). In fact, many like it far better than C++, Java, or many of the other options they have been taught. The benefits of the visibility rules needs to be given emphasis. Those rules are among the most powerful benefits of Ada, even though some programmers continue to see them as a nuisance. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 0:30 ` Richard Riehle @ 2004-08-18 1:29 ` Björn Persson 2004-08-20 16:39 ` Kevin Cline 2004-08-20 17:53 ` Alexander E. Kopilovich 2 siblings, 0 replies; 387+ messages in thread From: Björn Persson @ 2004-08-18 1:29 UTC (permalink / raw) Richard Riehle wrote: > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0408171554.2f9c48b4@posting.google.com... > >>I don't your guru got it quite right. Ada failed because most >>programmers who tried it found Ada programming to be relative less >>productive than programming in other available languages. Ada never >>attracted a large enough base of motivated users to develop the >>libraries and IDEs that would make it easy to use. > > I wonder why you think Ada is less productive than other > available languages. Is it the static typing? Is the ability > to define one's own types? Is it the syntax? Is it the way > the ALRM is written? The way I read the part of Kevin's post that you quoted, he said it's because of lack of libraries and IDEs. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 0:30 ` Richard Riehle 2004-08-18 1:29 ` Björn Persson @ 2004-08-20 16:39 ` Kevin Cline 2004-08-20 17:41 ` Richard Riehle 2004-08-20 19:50 ` Jeffrey Carter 2004-08-20 17:53 ` Alexander E. Kopilovich 2 siblings, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-20 16:39 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<TqxUc.26181$9Y6.25639@newsread1.news.pas.earthlink.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0408171554.2f9c48b4@posting.google.com... > > > > I don't your guru got it quite right. Ada failed because most > > programmers who tried it found Ada programming to be relative less > > productive than programming in other available languages. Ada never > > attracted a large enough base of motivated users to develop the > > libraries and IDEs that would make it easy to use. > > > I wonder why you think Ada is less productive than other > available languages. Is it the static typing? No, I'm very comfortable with static typing in C++. > Is the ability to define one's own types? That is a problem. User defined types are less compatable with built-in types than they are in C++. This makes generic programming more difficult. I find it more difficult to factor out duplication in Ada than I do in C++. > Is it the syntax? Yes. The syntax, and particularly the need for explicit generic instantiation, makes Ada programs much longer than equivalent C++ programs. Longer programs take longer to write and longer to read. The Ada type model, with special cases for types that overload assignment or require a destructor, seems much more complex than the C++ type model. > Is it the way the ALRM is written? The ALRM is ok, but I feel the type system is fatally flawed. > Over the years, I have come to the conclusion that a key > problem with Ada, in those early days, was that few of > those involved in teaching it really understood it well > enough to make it clear to those who needed to use it. The early Ada compilers were horribly expensive, and horribly buggy. This turned a lot of programmers away from Ada, and the battle for mindshare was quickly lost. The battle for mindshare was lost early when Ada failed to gain any popularity among the DARPA research triangle of MIT, CMU, and Stanford. > There are a few simple underlying ideas in the language. One > of them is type safety, and that has never been beyond the > comprehension of any programmer. The idea that seems to > have been difficult to grasp, even by many who consider themselves > sophisticated software developers, is the separation of scope > and visibility. Chapter Eight of the ALRM is rarely read by > anyone, it seems. > > I recall being at a conference some years ago where someone > was giving a tutorial involving Ada. At one point I suggested > changing a part of the design to a limited private type. I think the very existence of limited types is a fundamental flaw in Ada. > Those who had the most difficulty with Ada, and those who > continue to have difficulty with it, are often trying to force > the language to do things the old way. They are unable to > learn how a light touch, using the features of the language, > will make one more productive, not less productive. The difficulty of learning Ada is a flaw in the language. > > I currently teach Ada in an academic environment. My students > are in graduate school and very bright. I am too, but even among very bright people few become facile programmers. > > Many of them have written programs in other languages. > When they first encounter > Ada, they too want to approach it the way they did other > languages. After a short time, they learn the simple ideas behind > the design of the language and they learn to like it (most of them). > In fact, many like it far better than C++, Java, or many of the > other options they have been taught. > > The benefits of the visibility rules needs to be given emphasis. Those > rules are among the most powerful benefits of Ada, even though > some programmers continue to see them as a nuisance. For most applications, the benefits of the available infrastructure, e.g. the STL and Boost for C++, the CPAN for Perl, the Java libraries, completely dominates any possible benefit from the additional safety afforded by Ada. I have learned to write safe C++ code with little effort, and have learned to use C++ templates to build extremely powerful domain-specific libraries. It doesn't matter to me that weak programmers can theoretically make a mess in C++. What matters is the amount of effort required for a good programmer to produce sound code, and Ada is simply not competitive for most applications. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 16:39 ` Kevin Cline @ 2004-08-20 17:41 ` Richard Riehle 2004-08-21 23:23 ` fabio de francesco 2004-08-20 19:50 ` Jeffrey Carter 1 sibling, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-20 17:41 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0408200838.43e841d@posting.google.com... Kevin, I have read your reasons for preferring C++ over Ada, and appreciate that you have looked at this matter with diligence and an honest sense of inquiry. Because of my confidence in the intelligent approach you took to reach your conclusions, I will not presume to persuade you to depart from your position. I will say that, the more I compare C++ and Ada (and I do have to use C++ in some of my own work), the more I prefer Ada. Reasonable people can disagree on this kind of thing. None of these programming languages represent revealed truth. All have flaws. We often must decide which flaws we can best tolerate, rather than which good features can be of greatest benefit. It is a bit like voting in a major election. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 17:41 ` Richard Riehle @ 2004-08-21 23:23 ` fabio de francesco 2004-08-22 7:16 ` fabio de francesco ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: fabio de francesco @ 2004-08-21 23:23 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0408200838.43e841d@posting.google.com... > > Kevin, > > I have read your reasons for preferring C++ over Ada, > and appreciate that you have looked at this matter > with diligence and an honest sense of inquiry. Because > of my confidence in the intelligent approach you took > to reach your conclusions, I will not presume to persuade > you to depart from your position. What intelligent approach? He (Kevin) was able(?) to demonstrate that some of the most interesting and powerful features of Ada represent its major faults. I think He simply doesn't understand how to use those features for achieving the better results and for the clever maintaining of programs. > I will say that, the > more I compare C++ and Ada (and I do have to use > C++ in some of my own work), the more I prefer > Ada. Reasonable people can disagree on this kind > of thing. None of these programming languages > represent revealed truth. All have flaws. We often > must decide which flaws we can best tolerate, rather > than which good features can be of greatest benefit. I have been writing Ada code since only a couple of months and the more I learn Ada the more I prefer this one to C++ and to all the other programming languages I know, with the only exception of Assembly. > It is a bit like voting in a major election. > > Richard Riehle I don't think so. It shouldn't be just a matter of personal preference or a matter of taste. I have begun to think that in order to really understand, appreciate and use Ada, someone is to have some more experience, open mind and a more vast computer science background than that we commonly find in the average programmer. In some way, the refuse of Ada recalls to me the same ridiculus position took by some C programmer towards C++. Ciao, Fabio De Francesco ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-21 23:23 ` fabio de francesco @ 2004-08-22 7:16 ` fabio de francesco 2004-08-22 9:44 ` Richard Riehle 2004-08-26 20:32 ` Kevin Cline 2 siblings, 0 replies; 387+ messages in thread From: fabio de francesco @ 2004-08-22 7:16 UTC (permalink / raw) fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408211523.389cf201@posting.google.com>... > In some way, the > refuse of Ada recalls to me the same ridiculus position took by some C > programmer towards C++. Sorry for my poor English, please read: In some way, the refusal of Ada recalls me the same ridiculous position taken up by some C programmer against the adoption of C++. Regards, Fabio De Francesco ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-21 23:23 ` fabio de francesco 2004-08-22 7:16 ` fabio de francesco @ 2004-08-22 9:44 ` Richard Riehle 2004-08-23 0:18 ` fabio de francesco 2004-08-26 20:32 ` Kevin Cline 2 siblings, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-22 9:44 UTC (permalink / raw) "fabio de francesco" <fmdf@tiscali.it> wrote in message news:ba2f9c57.0408211523.389cf201@posting.google.com... > "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>... > > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > > news:e749549b.0408200838.43e841d@posting.google.com... > > > > Kevin, > > > > I have read your reasons for preferring C++ over Ada, > > and appreciate that you have looked at this matter > > with diligence and an honest sense of inquiry. Because > > of my confidence in the intelligent approach you took > > to reach your conclusions, I will not presume to persuade > > you to depart from your position. > > What intelligent approach? He (Kevin) was able(?) to demonstrate that > some of the most interesting and powerful features of Ada represent > its major faults. I think He simply doesn't understand how to use > those features for achieving the better results and for the clever > maintaining of programs. > It seems that, even when I am trying to be generous toward someone with a different point-of-view, a few on my side of the argument can still be offended by that very generosity. I am satisfied that Kevin has applied his own criteria with intelligence and and sincerity to reaching his conclusions. I don't share his conclusions, and given the same information, have come to a different viewpoint. My concession is not an admission of defeat in the argument. It is a recognition that intelligent people can reach different conclusions even after examining the same information. I am sorry you find fault with that. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-22 9:44 ` Richard Riehle @ 2004-08-23 0:18 ` fabio de francesco 2004-08-23 3:44 ` Wes Groleau ` (3 more replies) 0 siblings, 4 replies; 387+ messages in thread From: fabio de francesco @ 2004-08-23 0:18 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<GVZVc.9513$3O3.1068@newsread2.news.pas.earthlink.net>... > It seems that, even when I am trying to be generous toward someone > with a different point-of-view, a few on my side of the argument > can still be offended by that very generosity. I don't think that "offended" is the right verb, it seems excessive to me. > I am satisfied that Kevin has applied his own criteria with intelligence > and and sincerity to reaching his conclusions. I don't share his > conclusions, and given the same information, have come to a > different viewpoint. My concession is not an admission of defeat > in the argument. I also don't want to make any assumptions on the cleverness of people. I just say that whenever you discuss matters of taste people can have different points of view, but in the case of a scientific problem with given informations people should come to the same conclusions. The only exceptions are either you have wrong given data or you take the wrong explanation path. He only lists wrong and 'unproven assumptions' and he also gets 'unrelated consequencies'. At http://groups.google.com/groups?q=g:thl4042257105d&dq=&hl=en&lr=&ie=UTF-8&selm=e749549b.0408200838.43e841d%40posting.google.com&rnum=53 Kevin says: 1) "Yes. The syntax, and particularly the need for explicit generic instantiation, makes Ada programs much longer than equivalent C++ programs. Longer programs take longer to write and longer to read." Where is the evidence that an Ada program is longer than a C++ one? ( Unproven Assumption ). What does demonstrate that the time it takes to read and understand lines of code are related to the lenght of the code itself? ( Unrelated Consequences ). 2) (Question: Is the ability to define one's own types?) "That is a problem." ( Unproven Assumption. He wants to demonstrate that a capability doesn't add anything to the power of a language, instead he says that the feature steals something to Ada ) "User defined types are less compatable with built-in types than they are in C++." ( This means nothing to me ) "This makes generic programming more difficult." ( Whom for? Unrelated Consequence ) "I find it more difficult to factor out duplication in Ada than I do in C++." ( This is only his problem and it doesn't prove anything ) 3) "I think the very existence of limited types" (Ok, Proven Assumption) "is a fundamental flaw in Ada".(Unrelated Consequences). How can it be proved? Please will someone ( may be Kevin itself ) show me the rationale of this reasoning? 4) " The difficulty of learning Ada" ( Unproven Assumption. How can he state that learning Ada is more difficult than learning C++? How is it proved? This shows only his difficult to learn Ada ) "is a flaw in the language." ( Unrelated Consequences ) I don't want to go on, I'm tired. > It is a recognition that intelligent people can reach > different conclusions even after examining the same information. I > am sorry you find fault with that. > > Richard Riehle It seems to me that he has examined informations from different sources than the ones you have, if you are the author of "Ada Distilled". Anyway do you think that two doctors that look at the same informations and come up with different diagnoses are both them right? With science it's never a matter of points of view. Ciao, Fabio De Francesco ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 0:18 ` fabio de francesco @ 2004-08-23 3:44 ` Wes Groleau 2004-08-26 21:36 ` Kevin Cline 2004-08-23 15:23 ` Richard Riehle ` (2 subsequent siblings) 3 siblings, 1 reply; 387+ messages in thread From: Wes Groleau @ 2004-08-23 3:44 UTC (permalink / raw) fabio de francesco wrote: > What does demonstrate that the time it takes to read and understand > lines of code are related to the lenght of the code itself? ( Simple disproof would be to compare a typical APL program with an Ada program that does the same thing. > With science it's never a matter of points of view. OK, you are definitely exaggerating on that one. -- Wes Groleau ----------- Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 3:44 ` Wes Groleau @ 2004-08-26 21:36 ` Kevin Cline 2004-08-27 11:39 ` Georg Bauhaus 2004-08-29 15:08 ` jayessay 0 siblings, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-26 21:36 UTC (permalink / raw) Wes Groleau <groleau+news@freeshell.org> wrote in message news:<ptmdnX73DcCT9bTcRVn-tQ@gbronline.com>... > fabio de francesco wrote: > > > What does demonstrate that the time it takes to read and understand > > lines of code are related to the lenght of the code itself? ( > > Simple disproof would be to compare a typical APL program > with an Ada program that does the same thing. But an experienced APL programmer would undoubtedly find the shorter APL program easier to read. You can not judge the readability of a program by testing whether a naive programmer can understand the program line by line. Would you consider a book on multivariate calculus to be poorly written because it was not immediately understandable by the average high-school graduate? Concise mathematical notation makes it possible to reason about mathematical objects at a high level. So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)" Similarly, writing applications concisely at a high level of abstraction makes it easier for programmers experienced in the domain to modify the application to meet new requirements. The Boost::spirit parser library for C++ is an excellent example of the power of C++ templates that is unmatched by Ada generics. Relatively few programmers would be capable of writing the SPIRIT parser library, but when that's what you need, Ada just won't get you there. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:36 ` Kevin Cline @ 2004-08-27 11:39 ` Georg Bauhaus 2004-08-29 15:08 ` jayessay 1 sibling, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-27 11:39 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : But an experienced APL programmer would undoubtedly find the shorter : APL program easier to read. Though not all of them would agree that J programs are as easy to read. Conversly, if you know J's operators and functions by heart, and you read one of the 2-letter sequences in ML or Eiffel or Ada, overload resolution has to happen in you "reading apparatus". Why not try to avoid this when it makes sense to do so? : Concise mathematical notation makes it possible to reason : about mathematical objects at a high level. : So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)" Uhm, the left formula is, in a sense, the body of the spec on the right; they are *both* in concise mathematical notation. To me, the second is as much an abbreviation as "non-inlined subprogram calls". How many items of concise notation should there be per page, in a program of some size, given a set of programmers with different areas and depths of knowledge? At least there should be a "modularisation of notations". How can you achieve that when the language, not the modules, defineds or invites conciseness? : Relatively few programmers would be capable of writing the SPIRIT : parser library, but when that's what you need, Ada just won't get you : there. It does get me there, unless you are referring to writing an exact copy the SPIRIT parser based on Ada templates. But there is no need. If you need an EBNF like executable notation in Ada, SPITBOL patterns are at your service; they are readily available for Ada. It is not exactly the same thing as template computing, but it should turn out to be equally powerful. This is working code, the rules are copied from the example in the SPIRIT introduction: begin integer := span("0123456789"); group := '(' & (+expression) & ')'; -- "+" defers factor := integer or group; term := factor & arbno(('*' & factor) or ('/' & factor)); expression := term & arbno(('+' & term) or ('-' & term)); -- `input_text` is an Unbounded_String as per the above grammar. -- (which omits white space patterns.) match(input_text, group ** output, result); -- in addition to matching, displays, on `output`, what has been -- matched end expr; Ada will get me there, if along a slightly different path. :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:36 ` Kevin Cline 2004-08-27 11:39 ` Georg Bauhaus @ 2004-08-29 15:08 ` jayessay 2004-08-30 19:59 ` Kevin Cline 2004-08-30 20:21 ` Kevin Cline 1 sibling, 2 replies; 387+ messages in thread From: jayessay @ 2004-08-29 15:08 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > You can not judge the readability of a program by testing whether a > naive programmer can understand the program line by line. Would you > consider a book on multivariate calculus to be poorly written because > it was not immediately understandable by the average high-school > graduate? Concise mathematical notation makes it possible to reason > about mathematical objects at a high level. > So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)" I tend to agree with you here. Paul Graham has some interesting things to say about this stuff: http://www.paulgraham.com/power.html [Actually, he has insightful things to say about a lot of stuff...] With Common Lisp you could (actually this has been done...) define some macros creating a small domain specific language for differentiation and integration. Then you could do things like: (d/d? (3*x + (cos x)/x) x) ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba> (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3 where the function returned is the compiled (yes, to machine code) form of the derivative.[1] So, you could then write something like this: (defun apply-derivative (fn &key (of 'x) to) (funcall (d/d? fn of) to)) (apply-derivative ((x ^ 2) + 2) :to 3) ==> 6 For functions the system doesn't know how to differentiate (or more likely integrate), you could punt off to a typical iterative approximater. > Similarly, writing applications concisely at a high level of > abstraction makes it easier for programmers experienced in the domain > to modify the application to meet new requirements. This is definitely true. This is why domain specific languages are so potent, but unless you are using something like Common Lisp they tend not to be built because the effort is much too high to make them cost effective [2]. > The Boost::spirit parser library for C++ is an excellent example of > the power of C++ templates... But this is what I don't understand. Why would anyone with this point of view hamstring themselves by using something so inexpressive as C++??? /Jon 1. The actual input form resulting in the compiled function here would be (lambda (x) (+ 3 (/ (- (cos x) (* x (- (sin x)))) (expt x 2)))) 2. See: Greenspun's tenth law -- 'jay' - a n t h o n y at romeo/november/charley com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 15:08 ` jayessay @ 2004-08-30 19:59 ` Kevin Cline 2004-09-02 14:26 ` jayessay 2004-08-30 20:21 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-08-30 19:59 UTC (permalink / raw) jayessay <nospam@foo.com> wrote in message news:<m3sma6f0d9.fsf@rigel.goldenthreadtech.com>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > You can not judge the readability of a program by testing whether a > > naive programmer can understand the program line by line. Would you > > consider a book on multivariate calculus to be poorly written because > > it was not immediately understandable by the average high-school > > graduate? Concise mathematical notation makes it possible to reason > > about mathematical objects at a high level. > > So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)" > > I tend to agree with you here. Paul Graham has some interesting > things to say about this stuff: > > http://www.paulgraham.com/power.html > > [Actually, he has insightful things to say about a lot of stuff...] > > With Common Lisp you could (actually this has been done...) define > some macros creating a small domain specific language for > differentiation and integration. Then you could do things like: > > (d/d? (3*x + (cos x)/x) x) > > ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba> > (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3 > > where the function returned is the compiled (yes, to machine code) > form of the derivative.[1] > > So, you could then write something like this: > > (defun apply-derivative (fn &key (of 'x) to) > (funcall (d/d? fn of) to)) > > (apply-derivative ((x ^ 2) + 2) :to 3) > > ==> 6 > > For functions the system doesn't know how to differentiate (or more > likely integrate), you could punt off to a typical iterative > approximater. > > > > Similarly, writing applications concisely at a high level of > > abstraction makes it easier for programmers experienced in the domain > > to modify the application to meet new requirements. > > This is definitely true. This is why domain specific languages are so > potent, but unless you are using something like Common Lisp they tend > not to be built because the effort is much too high to make them cost > effective [2]. As awkward as they are, you can get pretty far with C++ templates. > > > > The Boost::spirit parser library for C++ is an excellent example of > > the power of C++ templates... > > But this is what I don't understand. Why would anyone with this point > of view hamstring themselves by using something so inexpressive as > C++??? That is a good question. At home my projects are small, and I don't use C++ unless they are compute-bound. At work really expressive languages aren't an option, since no one else here knows any of them. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-30 19:59 ` Kevin Cline @ 2004-09-02 14:26 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-02 14:26 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > jayessay <nospam@foo.com> wrote in message news > > kevin.cline@gmail.com (Kevin Cline) writes: > > > > > > With Common Lisp you could (actually this has been done...) define > > some macros creating a small domain specific language for > > differentiation and integration. Then you could do things like: > > > > (d/d? (3*x + (cos x)/x) x) > > > > ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba> > > (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3 > > > > where the function returned is the compiled (yes, to machine code) > > form of the derivative.[1] > > > > So, you could then write something like this: > > > > (defun apply-derivative (fn &key (of 'x) to) > > (funcall (d/d? fn of) to)) > > > > (apply-derivative ((x ^ 2) + 2) :to 3) > > > > ==> 6 > > > > For functions the system doesn't know how to differentiate (or more > > likely integrate), you could punt off to a typical iterative > > approximater. > > > > > > > Similarly, writing applications concisely at a high level of > > > abstraction makes it easier for programmers experienced in the domain > > > to modify the application to meet new requirements. > > > > This is definitely true. This is why domain specific languages are so > > potent, but unless you are using something like Common Lisp they tend > > not to be built because the effort is much too high to make them cost > > effective [2]. > > As awkward as they are, you can get pretty far with C++ templates. You can get even further with a good macro assember. C++ templates are a good example of what is fundamentally wrong with C++: The entire _programming_ system (core language, stl, runtime, adhoc add on libs like boost, etc) is becoming an example of Greenspun's tenth. This is much worse than other such examples which are at least limited to one off applications. > > > The Boost::spirit parser library for C++ is an excellent example of > > > the power of C++ templates... > > > > But this is what I don't understand. Why would anyone with this point > > of view hamstring themselves by using something so inexpressive as > > C++??? > > That is a good question. At home my projects are small, and I don't > use C++ unless they are compute-bound. Even then it is extremely unlikely that C++ would buy you anything over Common Lisp (which has been shown on numerous occasions to beat C++ code in performance). OTOH, if you're using Python or Perl or somesuch, C++ will typically blow them away on this count. > At work really expressive languages aren't an option, since no one > else here knows any of them. You have my condolences. Your situation is not exactly atypical, it's just sad. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 15:08 ` jayessay 2004-08-30 19:59 ` Kevin Cline @ 2004-08-30 20:21 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-30 20:21 UTC (permalink / raw) jayessay <nospam@foo.com> wrote in message news:<m3sma6f0d9.fsf@rigel.goldenthreadtech.com>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > You can not judge the readability of a program by testing whether a > > naive programmer can understand the program line by line. Would you > > consider a book on multivariate calculus to be poorly written because > > it was not immediately understandable by the average high-school > > graduate? Concise mathematical notation makes it possible to reason > > about mathematical objects at a high level. > > So, instead of "limit(e->0) [f(x + e) - f(e)] / e", we write "f'(x)" > > I tend to agree with you here. Paul Graham has some interesting > things to say about this stuff: > > http://www.paulgraham.com/power.html > > [Actually, he has insightful things to say about a lot of stuff...] > > With Common Lisp you could (actually this has been done...) define > some macros creating a small domain specific language for > differentiation and integration. Then you could do things like: > > (d/d? (3*x + (cos x)/x) x) > > ==> #<Function (:ANONYMOUS-LAMBDA 1971) @ #x774811ba> > (((cos x) - (x * (- (sin x)))) / (x ^ 2)) + 3 > > where the function returned is the compiled (yes, to machine code) > form of the derivative.[1] > > So, you could then write something like this: > > (defun apply-derivative (fn &key (of 'x) to) > (funcall (d/d? fn of) to)) > > (apply-derivative ((x ^ 2) + 2) :to 3) > > ==> 6 > > For functions the system doesn't know how to differentiate (or more > likely integrate), you could punt off to a typical iterative > approximater. > > > > Similarly, writing applications concisely at a high level of > > abstraction makes it easier for programmers experienced in the domain > > to modify the application to meet new requirements. > > This is definitely true. This is why domain specific languages are so > potent, but unless you are using something like Common Lisp they tend > not to be built because the effort is much too high to make them cost > effective [2]. As awkward as they are, you can get pretty far with C++ templates. > > > > The Boost::spirit parser library for C++ is an excellent example of > > the power of C++ templates... > > But this is what I don't understand. Why would anyone with this point > of view hamstring themselves by using something so inexpressive as > C++??? That is a good question. At home my projects are small, and I don't use C++ unless they are compute-bound. At work really expressive languages aren't an option, since no one else here knows any of them. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 0:18 ` fabio de francesco 2004-08-23 3:44 ` Wes Groleau @ 2004-08-23 15:23 ` Richard Riehle 2004-08-26 21:08 ` Kevin Cline 2004-08-29 15:13 ` jayessay 2004-08-23 17:27 ` Dmitry A. Kazakov 2004-08-26 21:22 ` Kevin Cline 3 siblings, 2 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-23 15:23 UTC (permalink / raw) Fabio, First, yes, I am the author of Ada Distilled. Thank you for the acknowledgement. I am working on a updated version, but I am being delayed in its release by the press of other concerns. Perhaps I should not spend as much time engaged in dialogue of this sort on comp.lang.ada. :-) Second. People do look at issues in programming languages differently, given the same information. While I don't agree with their conclusions, I appreciate that they will apply different criteria to their evaluation than I would. For example, when Kevin states that limited types are a flaw in the language, I choose to accept that he is correct, only because I realize that some people find this to be a difficult concept. I do disagree with Kevin on this, and many other points since limited is a powerful and effective feature when used by a designer who understands it. Syntax, in programming languages, seems to be a personal thing. I know people who dislike the syntax of the C family of languages as well as the Pascal family. Some of these people are attracted to Lisp, Haskell, or Ruby, or even Smalltalk or Eiffel. I once sat in on a meeting where, after the presentation by a prominent speaker, the room erupted in a spirited argument about the virtue of := versus = for assignment. Sometimes I have seen people get so upset about the placement of the type identifier in relationship to the variable/object that I half expect to seem white foam drooling from the corners of their mouths. As to learning Ada being difficult. My own experience is quite different, and I have taught Ada to a lot of people during the last eighteen years. A present, I teach a class that is populated by students who have previously learned Java, some of whom also know some C++. My class is a multi-language class in which students are learning Ada, C++, Lisp, and a little bit about Eiffel, COBOL, Fortran, Smaltalk, and other languages. Their reaction to Ada is that it is no more difficult to learn than Java, and certainly easier to learn to do well than C++. Of course, there are C++ die-hards, and I don't attempt to discourage them since most of the other professors are also C++ enthusiasts. As they take classes from those other professors, they must be prepared to do exercises in the language preferred by those professors. Finally, Kevin makes his case from his own viewpoint, using his own criteria. Oddly enough, the issues he raises are not those that represent weaknesses vis a vis Ada. If he had examined both languages more carefully he would have found some really good points that show some advantages of C++ over Ada. However, that kind of analysis would also have shown some excellent advantages of Ada over C++. At this stage of programming language development, there is no perfect language, certainly no perfect language for every set of circumstances. I ama personally comfortable with, and often prefer, Ada for most of my own programming. However, I also like Smalltalk and functional languages for certain kinds of problem solving. I am not a fan of Java or C++ but I do like much of what Eiffel has to offer. Most important, I continue to look for improvements in language design, hoping that some reasonable approach will manifest itself during my remaining work life. At present, the current design of Ada is one of the best languages for general purpose programming, but someone will someday improve upon it, and later someone will improve upon that improvement. By then, I will no longer have a pulse, global warming will have become more important than any other issue confronting human civilization, and my great grandchildren will look at Ada Distilled and wonder what I could have possibly been thinking when I wrote it. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 15:23 ` Richard Riehle @ 2004-08-26 21:08 ` Kevin Cline 2004-08-27 5:23 ` Wes Groleau 2004-08-27 11:45 ` Georg Bauhaus 2004-08-29 15:13 ` jayessay 1 sibling, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-26 21:08 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<oZnWc.31328$9Y6.14222@newsread1.news.pas.earthlink.net>... > Fabio, > > First, yes, I am the author of Ada Distilled. Thank you > for the acknowledgement. I am working on a updated > version, but I am being delayed in its release by the press > of other concerns. Perhaps I should not spend as much > time engaged in dialogue of this sort on comp.lang.ada. :-) > > Second. People do look at issues in programming languages > differently, given the same information. While I don't agree > with their conclusions, I appreciate that they will apply > different criteria to their evaluation than I would. > > For example, when Kevin states that limited types are a > flaw in the language, I choose to accept that he is correct, > only because I realize that some people find this to be a > difficult concept. I do disagree with Kevin on this, and many > other points since limited is a powerful and effective feature > when used by a designer who understands it. Somehow I've never understood the point of making limited types a special case. Why not consider assignment as just another operation a type can support, or not, just like addition or ordered comparison? I think this is one of the fundamental errors in the Ada design -- certain operations are somehow "more equal" than others, and redefining them requires special syntax. > Syntax, in programming languages, seems to be a personal > thing. I know people who dislike the syntax of the C family > of languages as well as the Pascal family. Some of these > people are attracted to Lisp, Haskell, or Ruby, or even Smalltalk > or Eiffel. I once sat in on a meeting where, after the presentation > by a prominent speaker, the room erupted in a spirited argument > about the virtue of := versus = for assignment. Sometimes I > have seen people get so upset about the placement of the type > identifier in relationship to the variable/object that I half expect > to seem white foam drooling from the corners of their mouths. That kind of syntax I don't much care about. I care about whether I have to write 500 lines of code or 1500. As a general rule, 500 lines is better. > As to learning Ada being difficult. My own experience is quite > different, and I have taught Ada to a lot of people during the > last eighteen years. But how much of the language have your students really learned? To most programmers, all languages are essentially just FORTRAN. They store all their data in arrays and write loop upon loop ad nauseum. For such programmers, Ada is undoubtedly better than C or C++, because it has extensive facilities to support static array-based programming. However, defining or using more complex and dynamic data structures in Ada is a chore. Dynamic structures requires use of unchecked allocation and deallocation, leaving one exposed to the same sort of heap corruption errors that plagued naive C and C++ programmers. However, with the introduction of the C++ standard library, programming in C++ with advanced data structures is simple and fast, and it's easy to avoid memory leaks, null dereferences, and heap corruption. > Finally, Kevin makes his case from his own viewpoint, using > his own criteria. Oddly enough, the issues he raises are not > those that represent weaknesses vis a vis Ada. If he had > examined both languages more carefully he would have found > some really good points that show some advantages of C++ > over Ada. I wrote an Ada-83 specification parser in Ada using AYACC. That required a rather thorough examination of the language. > Most important, I continue to look for improvements in language > design, And this is what we should all do. Assuming that differing opinions have no value will not lead to progress. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:08 ` Kevin Cline @ 2004-08-27 5:23 ` Wes Groleau 2004-08-27 17:29 ` Kevin Cline 2004-08-27 11:45 ` Georg Bauhaus 1 sibling, 1 reply; 387+ messages in thread From: Wes Groleau @ 2004-08-27 5:23 UTC (permalink / raw) Kevin Cline wrote: > Somehow I've never understood the point of making limited types a > special case. Why not consider assignment as just another operation a > type can support, or not, just like addition or ordered comparison? I > think this is one of the fundamental errors in the Ada design -- > certain operations are somehow "more equal" than others, and > redefining them requires special syntax. I don't think it's an _error_. What other language at that time could redefine an assignment operator? Now, Ada does allow redefining assignment--for certain types. -- Wes Groleau "Ideas are more powerful than guns, We would not let our enemies have guns; why should we let them have ideas?" -- Jozef Stalin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 5:23 ` Wes Groleau @ 2004-08-27 17:29 ` Kevin Cline 2004-08-27 22:50 ` Wes Groleau 0 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-08-27 17:29 UTC (permalink / raw) Wes Groleau <groleau+news@freeshell.org> wrote in message news:<dZqdnehSibTGWLPcRVn-uw@gbronline.com>... > Kevin Cline wrote: > > Somehow I've never understood the point of making limited types a > > special case. Why not consider assignment as just another operation a > > type can support, or not, just like addition or ordered comparison? I > > think this is one of the fundamental errors in the Ada design -- > > certain operations are somehow "more equal" than others, and > > redefining them requires special syntax. > > I don't think it's an _error_. What other language at > that time could redefine an assignment operator? Which time are we talking about, 1983 or 1995? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 17:29 ` Kevin Cline @ 2004-08-27 22:50 ` Wes Groleau 0 siblings, 0 replies; 387+ messages in thread From: Wes Groleau @ 2004-08-27 22:50 UTC (permalink / raw) Kevin Cline wrote: >>I don't think it's an _error_. What other language at >>that time could redefine an assignment operator? > > Which time are we talking about, 1983 or 1995? 1983 - when Ada was not able to redefine assignment and therefore allowed limited types where predefined assignment was unavailable, forcing the use of subprograms as a workaround. IOW, there are situations where straight copy is bad. Limited types prevented it. Ada 95 does have a way to redefine assignment, but still has limited types for compatibility and for cases where predefined assignment would be bad but no redefined is needed. -- Wes Groleau Heroes, Heritage, and History http://freepages.genealogy.rootsweb.com/~wgroleau/ ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 21:08 ` Kevin Cline 2004-08-27 5:23 ` Wes Groleau @ 2004-08-27 11:45 ` Georg Bauhaus 2004-08-27 18:22 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-27 11:45 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : However, with the introduction of the C++ standard library, : programming in C++ with advanced data structures is simple and fast, : and it's easy to avoid memory leaks, null dereferences, and heap : corruption. Though given the Charles library I doubt that C++ vs Ada is a major issue here. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 11:45 ` Georg Bauhaus @ 2004-08-27 18:22 ` Kevin Cline 2004-08-27 19:14 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-27 18:22 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : However, with the introduction of the C++ standard library, > : programming in C++ with advanced data structures is simple and fast, > : and it's easy to avoid memory leaks, null dereferences, and heap > : corruption. > > Though given the Charles library I doubt that C++ vs Ada is a major > issue here. Charles is a pale imitation of the C++ STL. It defines containers, but provides no generic algorithms. My Ada is now a bit rusty, but it also appears that Charles containers can not be used with limited types. The author of the C++ STL started working in Ada but abandoned it because explicit instantiation was just too unwieldy. A single C++ template function call like this one: merge(c1.begin(), c1.end(), c2.begin(), c2.end(), c3.back_inserter()) would require half a dozen lines of Ada just for the function instantiation. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 18:22 ` Kevin Cline @ 2004-08-27 19:14 ` Hyman Rosen 2004-08-28 14:17 ` Kevin Cline 2004-08-27 21:42 ` Kevin Cline 2004-08-29 6:22 ` Martin Krischik 2 siblings, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-08-27 19:14 UTC (permalink / raw) Kevin Cline wrote: > A single C++ template function call like this one: > merge(c1.begin(), c1.end(), c2.begin(), c2.end(), c3.back_inserter()); > would require half a dozen lines of Ada just for the function instantiation. No fair picking an easy one. Suppose you have a vector of complex numbers and want to set the real part of each to zero. That's far from a one liner in C++ even though it's conceptually trivial. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 19:14 ` Hyman Rosen @ 2004-08-28 14:17 ` Kevin Cline 2004-08-28 18:07 ` Georg Bauhaus 2004-08-30 17:30 ` Hyman Rosen 0 siblings, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-28 14:17 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<1093634083.931713@master.nyc.kbcfp.com>... > Kevin Cline wrote: > > A single C++ template function call like this one: > > merge(c1.begin(), c1.end(), c2.begin(), c2.end(), c3.back_inserter()); > > would require half a dozen lines of Ada just for the function instantiation. > > No fair picking an easy one. Suppose you have a vector of complex numbers and > want to set the real part of each to zero. That's far from a one liner in C++ > even though it's conceptually trivial. With boost::lambda, it would be a one liner: for_each(v.begin(), v.end(), _1.r = 0); ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 14:17 ` Kevin Cline @ 2004-08-28 18:07 ` Georg Bauhaus 2004-08-29 16:14 ` jayessay 2004-08-30 17:30 ` Hyman Rosen 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-28 18:07 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Hyman Rosen <hyrosen@mail.com> wrote in message news:<1093634083.931713@master.nyc.kbcfp.com>... :> :> No fair picking an easy one. Suppose you have a vector of complex numbers and :> want to set the real part of each to zero. That's far from a one liner in C++ :> even though it's conceptually trivial. : With boost::lambda, it would be a one liner: : for_each(v.begin(), v.end(), _1.r = 0); With Ada 200Y there is "procedure Set_Re (X : in out Complex_Vector; Re : in Real_Vector); procedure Set_Im (X : in out Complex_Vector; Im : in Real_Vector); Each procedure replaces the specified (cartesian) component of each of the components of X by the value of the matching component of Re or Im; the other (cartesian) component of each of the components is unchanged. Constraint_Error is raised if X'Length is not equal to Re'Length or Im'Length." I think no one will deny that there is power in C++ template computing, and in CLOS makros etc. (Hey, lambda is cool!) How many specials like _1, embedded languages, and coding conventions are desirable? When does code suffer from abbreviation? What about compiler error messages involving deeply nested template instantiations? When people complain about explicit instantiations, for example about the necessity to express their choices of characteristics of a Booch Collection using three explicit instantiations, what is the complaint about? I think that once you have understood the model, and have learned to appreciate the why and how, it is no longer an issue. So the complaint might be about - the need to understand the model. - the need to be explicit. - the need to choose rather than relying on an implicit default. - the need to type rather than having a number of thoughts be condensed in very few characters. - ... Hm. Why do they still write "for_each(v.begin(), v.end," so frequently? :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 18:07 ` Georg Bauhaus @ 2004-08-29 16:14 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-08-29 16:14 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: > Hyman Rosen <hyrosen@mail.com> wrote in message > news:<1093634083.931713@master.nyc.kbcfp.com>... >> >> No fair picking an easy one. Suppose you have a vector of complex >> numbers and want to set the real part of each to zero. That's far >> from a one liner in C++ even though it's conceptually trivial. > > With boost::lambda, it would be a one liner: > for_each(v.begin(), v.end(), _1.r = 0); Why not just use the real thing (instead of a pale emasculated hack) (map 'vec (lambda (c) (complex 0 (imagpart c))) v) Actually it's simple to be more flexible: (defun zero-realpart (vec &optional (type (type-of vec))) (map type (lambda (c) (complex 0 (imagpart c))) vec)) (let ((vc1 (vector #c(1 2) #c(2 3) #c(1/3 4.5)))) (zero-realpart vc1)) ==> #(#c(0 2) #c(0 3) #c(0.0 4.5)) (let ((vc1 (list #c(1 2) #c(2 3) #c(1/3 4.5)))) (zero-realpart vc1)) ==> (#c(0 2) #c(0 3) #c(0.0 4.5)) (let ((vc1 (list #c(1 2) #c(2 3) #c(1/3 4.5)))) (zero-realpart vc1 'vector)) ==> #(#c(0 2) #c(0 3) #c(0.0 4.5)) It wouldn't take much to generalize this to be much more flexible and generic while still generating optimal code. /Jon -- 'jay' - a n t h o n y at romeo/november/charley com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 14:17 ` Kevin Cline 2004-08-28 18:07 ` Georg Bauhaus @ 2004-08-30 17:30 ` Hyman Rosen 1 sibling, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-30 17:30 UTC (permalink / raw) Kevin Cline wrote: > With boost::lambda, it would be a one liner: > for_each(v.begin(), v.end(), _1.r = 0); No, it wouldn't. There is no way to delay the evaluation of the expression '_1.r', and the _1 placeholdr has no such member, so this would result in a compilation error. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 18:22 ` Kevin Cline 2004-08-27 19:14 ` Hyman Rosen @ 2004-08-27 21:42 ` Kevin Cline 2004-08-29 6:22 ` Martin Krischik 2 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-27 21:42 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0408271022.47abd0e2@posting.google.com>... > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>... > > Kevin Cline <kevin.cline@gmail.com> wrote: > > : However, with the introduction of the C++ standard library, > > : programming in C++ with advanced data structures is simple and fast, > > : and it's easy to avoid memory leaks, null dereferences, and heap > > : corruption. > > > > Though given the Charles library I doubt that C++ vs Ada is a major > > issue here. > > Charles is a pale imitation of the C++ STL. It defines containers, > but provides no generic algorithms. My Ada is now a bit rusty, but it > also appears that Charles containers can not be used with limited > types. I hate to follow up my own post, but after further research I found that Charles does indeed provide some generic algorithms. It also provides a number of example applications. It will be interesting to pick a couple and perform a side-by-side comparison of corresponding Ada and C++ code. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 18:22 ` Kevin Cline 2004-08-27 19:14 ` Hyman Rosen 2004-08-27 21:42 ` Kevin Cline @ 2004-08-29 6:22 ` Martin Krischik 2004-08-31 7:25 ` Kevin Cline 2 siblings, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-08-29 6:22 UTC (permalink / raw) Kevin Cline wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message > news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>... > Charles is a pale imitation of the C++ STL. It defines containers, > but provides no generic algorithms. My Ada is now a bit rusty, but it > also appears that Charles containers can not be used with limited > types. But C++ containers don't support limited types as well. If you define: class T { private: operator = (T const& value); } then you can't have: vector <T>; With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 6:22 ` Martin Krischik @ 2004-08-31 7:25 ` Kevin Cline 2004-08-31 9:37 ` Jean-Pierre Rosen ` (3 more replies) 0 siblings, 4 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-31 7:25 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1198227.gWQ0keDDOY@linux1.krischik.com>... > Kevin Cline wrote: > > > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message > > news:<cgn6sd$snk$2@a1-hrz.uni-duisburg.de>... > > > Charles is a pale imitation of the C++ STL. It defines containers, > > but provides no generic algorithms. My Ada is now a bit rusty, but it > > also appears that Charles containers can not be used with limited > > types. > > But C++ containers don't support limited types as well. If you define: > > class T > { > private: > > operator = (T const& value); > } > > then you can't have: > > vector <T>; This is true. Classes stored in STL containers need not be default-constructible, but they must be assignable and copyable. I seem to have confused limited types and controlled types, probably because I stopped programming in Ada before there were controlled types. Still, using controlled types also seems to be problematical. For example, I found this at http://www.gidenstam.org/Ada/: "In Ada controlled types, i.e. types with user defined initialize and finalize operations, must be declared at the library level - either as direct descendents of Ada.Finalization./Limited_/Controlled or via a mixin component that inherits from Ada.Finalization./Limited_/Controlled. This makes it a bit of a hassel to use controlled types, and in particular it makes it quite limiting to use controlled types in generic packages that one otherwise would have liked to instansiate at other levels than the library level. This library, the Add Finalization Anywhere Library, provides a nice(?) way to add finalization to any (limited) tagged type at any level. The structure of the library is inspired by Christoph Karl Walter Grein's library for adding finalization to library level tagged types and my library is designed to integrate well with his. However, since declaring controlled types elsewhere than at the library level isn't supported by Ada there is a lot of hackish things going on inside the library. Currently, I don't know whether the these things work on any other compiler than GNAT 3.13p and whether they are at all sane." I don't know about you, but that mades my head hurt. In C++ there are some things that make my head hurt too, but they mostly are there to determine the meaning of code that I would naver write in the first place. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 7:25 ` Kevin Cline @ 2004-08-31 9:37 ` Jean-Pierre Rosen 2004-08-31 10:54 ` Martin Dowie 2004-08-31 12:42 ` Hyman Rosen 2004-08-31 9:57 ` Dmitry A. Kazakov ` (2 subsequent siblings) 3 siblings, 2 replies; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-08-31 9:37 UTC (permalink / raw) Kevin Cline a écrit : > I seem to have confused limited types and controlled types, probably > because I stopped programming in Ada before there were controlled > types. Still, using controlled types also seems to be problematical. > For example, I found this at http://www.gidenstam.org/Ada/: > > "In Ada controlled types, i.e. types with user defined initialize and > finalize operations, must be declared at the library level - either as > direct descendents of Ada.Finalization./Limited_/Controlled or via a > mixin component that inherits from > Ada.Finalization./Limited_/Controlled. This makes it a bit of a hassel > to use controlled types, and in particular it makes it quite limiting > to use controlled types in generic packages that one otherwise would > have liked to instansiate at other levels than the library level. > [...] > I don't know about you, but that mades my head hurt. In C++ there are > some things that make my head hurt too, but they mostly are there to > determine the meaning of code that I would naver write in the first > place. It is true that controlled *types* (not objects) need to be declared at library level. However, all other OO languages (that I know of) require *all* classes to be declared at library level. So, there is no reason to have your head hurt. It's just one of the few cases where Ada makes even with other programming languages, not better. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 9:37 ` Jean-Pierre Rosen @ 2004-08-31 10:54 ` Martin Dowie 2004-08-31 12:42 ` Hyman Rosen 1 sibling, 0 replies; 387+ messages in thread From: Martin Dowie @ 2004-08-31 10:54 UTC (permalink / raw) Jean-Pierre Rosen wrote: > It is true that controlled *types* (not objects) need to be declared > at library level. However, all other OO languages (that I know of) > require *all* classes to be declared at library level. > So, there is no reason to have your head hurt. It's just one of the > few cases where Ada makes even with other programming languages, not > better. And if AI-344 gets the nod for Ada0Y then it will be ahead of the game! It's current status is "Amendment 200Y" :-) -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 9:37 ` Jean-Pierre Rosen 2004-08-31 10:54 ` Martin Dowie @ 2004-08-31 12:42 ` Hyman Rosen 2004-08-31 13:22 ` Hyman Rosen 2004-08-31 17:29 ` Jean-Pierre Rosen 1 sibling, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-31 12:42 UTC (permalink / raw) Jean-Pierre Rosen wrote: > However, all other OO languages (that I know of) require > *all* classes to be declared at library level. Certainly neither C++ nor Java require this. I will occasionally write the following C++ code, when I'm too lazy to do the right thing and make a more widely reusable class. void some_func() { extern int some_global_a, some_global_b; struct restorer { int &sg, oldval; restorer(int &var, int newval) : sg(var), oldval(var) { } ~restorer() { sg = oldval; } }; restorer rsga(some_global_a, 53); restorer rsgb(some_global_b, -1); // ... } Java allows you to write "inner classes", even anonymous ones, at pretty much any point in your code. They are often used to create tiny class objects which implement an interface, as callbacks for example. Something like this button.setClickCB(new INotify { void notify() { /* stuff */ } }); ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 12:42 ` Hyman Rosen @ 2004-08-31 13:22 ` Hyman Rosen 2004-08-31 16:02 ` Georg Bauhaus 2004-08-31 17:29 ` Jean-Pierre Rosen 1 sibling, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-08-31 13:22 UTC (permalink / raw) Hyman Rosen wrote: > restorer(int &var, int newval) : sg(var), oldval(var) { } Oops. That should be { var = newval; } of course. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 13:22 ` Hyman Rosen @ 2004-08-31 16:02 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-31 16:02 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: : Hyman Rosen wrote: :> restorer(int &var, int newval) : sg(var), oldval(var) { } : : Oops. That should be { var = newval; } of course. I think there is still an interesting difference. If, for the sake of an example, I write void some_func(int some_para) { extern int some_global_a, some_global_b; struct restorer { int &sg, oldval, def; restorer(int &var, int newval) : sg(var), oldval(var) { var = newval; def = some_para; // <-- } ~restorer() { sg = oldval; } }; the compiler tells me I can't do this, because I am using a parameter from the containing function. In Ada, this works: procedure nc is type Int_Ref is access all Integer; some_global_a, some_global_b: aliased Integer; -- global to `some_func` anyway procedure some_func(some_para: Integer) is type Restorer is record -- "new Controlled with" for the real thing ... sg: Int_Ref; oldval: Integer; def: Integer; -- only for this example end record; function make_restorer(var: Int_Ref; newval: Integer) return restorer is result: constant restorer := (sg => var, oldval => var.all, def => some_para); begin var.all := newval; return result; end make_restorer; begin declare rsga: restorer := make_restorer(some_global_a'access, 53); rsgb: restorer := make_restorer(some_global_b'access, -1); begin null; -- ... end; end some_func; begin -- nc some_func(5); end nc; ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 12:42 ` Hyman Rosen 2004-08-31 13:22 ` Hyman Rosen @ 2004-08-31 17:29 ` Jean-Pierre Rosen 2004-08-31 20:17 ` Hyman Rosen 1 sibling, 1 reply; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-08-31 17:29 UTC (permalink / raw) Hyman Rosen a écrit : > Jean-Pierre Rosen wrote: > > However, all other OO languages (that I know of) require > >> *all* classes to be declared at library level. > > > Certainly neither C++ nor Java require this. I will occasionally > write the following C++ code, when I'm too lazy to do the right > thing and make a more widely reusable class. > > void some_func() > { > extern int some_global_a, some_global_b; > struct restorer { > int &sg, oldval; > restorer(int &var, int newval) : sg(var), oldval(var) { } > ~restorer() { sg = oldval; } > }; > restorer rsga(some_global_a, 53); > restorer rsgb(some_global_b, -1); > // ... > } > If I'm not mistaken, last time I looked at C++ such inner types had local visibility, but still global scope. Not the same thing as truly "local" classes. Correct me if I'm wrong. > Java allows you to write "inner classes", even anonymous ones, at > pretty much any point in your code. They are often used to create > tiny class objects which implement an interface, as callbacks for > example. Something like this > button.setClickCB(new INotify { void notify() { /* stuff */ } }); Inner classes are classes within classes (same as package inside package, which Ada of course allows), not classes inside functions. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 17:29 ` Jean-Pierre Rosen @ 2004-08-31 20:17 ` Hyman Rosen 2004-09-01 7:08 ` Jean-Pierre Rosen 2004-09-02 7:59 ` Martin Krischik 0 siblings, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-08-31 20:17 UTC (permalink / raw) Jean-Pierre Rosen wrote: > If I'm not mistaken, last time I looked at C++ such inner types had > local visibility, but still global scope. Not the same thing as truly > "local" classes. Correct me if I'm wrong. It's not a terribly meaningful distinction for C++. In C++ types do not have any runtime dependencies the way they can in Ada, and therefore they also do not any notion of lifetime or extent. So in that sense, all types are global. But they are local in the sense that you can declare them where you need them, like my example. > Inner classes are classes within classes (same as package inside > package, which Ada of course allows), not classes inside functions. Anonymous classes are a type of inner class, and they most certainly can be declared/created within functions. Please see this reference: <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 20:17 ` Hyman Rosen @ 2004-09-01 7:08 ` Jean-Pierre Rosen 2004-09-01 12:25 ` Georg Bauhaus 2004-09-02 7:59 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-09-01 7:08 UTC (permalink / raw) Hyman Rosen a écrit : > Anonymous classes are a type of inner class, and they most certainly > can be declared/created within functions. Please see this reference: > <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>. Anyway, all objects are global in Java, so you cannot compare with Ada. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-01 7:08 ` Jean-Pierre Rosen @ 2004-09-01 12:25 ` Georg Bauhaus 2004-09-01 14:27 ` Jean-Pierre Rosen 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-01 12:25 UTC (permalink / raw) Jean-Pierre Rosen <rosen@adalog.fr> wrote: : Hyman Rosen a ?crit : : :> Anonymous classes are a type of inner class, and they most certainly :> can be declared/created within functions. Please see this reference: :> <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>. : Anyway, all objects are global in Java, so you cannot compare with Ada. Uhm, in the following program, how is the object created by "self.new Frob()" global? class I { private class Frob { boolean foo() { return true; } } boolean q(Frob f) { return f.foo(); } public static void main(String[] args) { I self = new I(); if (self.q(self.new Frob())) { // global? return; } } } -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-01 12:25 ` Georg Bauhaus @ 2004-09-01 14:27 ` Jean-Pierre Rosen 2004-09-01 20:21 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-09-01 14:27 UTC (permalink / raw) Georg Bauhaus a écrit : > Jean-Pierre Rosen <rosen@adalog.fr> wrote: > : Anyway, all objects are global in Java, so you cannot compare with Ada. > > Uhm, in the following program, how is the object created by > "self.new Frob()" global? > > class I { > > private class Frob { > boolean foo() { return true; } > } > > boolean q(Frob f) { return f.foo(); } > > public static void main(String[] args) { > I self = new I(); > > if (self.q(self.new Frob())) { // global? > return; > } > } > } > It is on the heap, and can reference only other objects on the heap. There is therefore no issue of accessing non-existent variables. In Ada, you can declare an access type local to a subprogram. Objects created by allocators for this access type will similarly be accessible only from within the subprogram. They are still global. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-01 14:27 ` Jean-Pierre Rosen @ 2004-09-01 20:21 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-01 20:21 UTC (permalink / raw) Jean-Pierre Rosen <rosen@adalog.fr> wrote: : In Ada, you can declare an access type local to a subprogram. Objects : created by allocators for this access type will similarly be accessible : only from within the subprogram. They are still global. Is this an Ada definition of "global" (as in RM 8.1 (15), I guess)? That is, are the objects created by the allocators in the nested block below global entities? procedure I is type T is range 1 .. 42; begin declare type Local is access T; x: Local; y: Local := new T; begin x := new T; end; end I; -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 20:17 ` Hyman Rosen 2004-09-01 7:08 ` Jean-Pierre Rosen @ 2004-09-02 7:59 ` Martin Krischik 2004-09-02 13:33 ` Hyman Rosen 1 sibling, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-09-02 7:59 UTC (permalink / raw) Hyman Rosen wrote: > Jean-Pierre Rosen wrote: >> If I'm not mistaken, last time I looked at C++ such inner types had >> local visibility, but still global scope. Not the same thing as truly >> "local" classes. Correct me if I'm wrong. > > It's not a terribly meaningful distinction for C++. > In C++ types do not have any runtime dependencies > the way they can in Ada, and therefore they also do > not any notion of lifetime or extent. So in that > sense, all types are global. But they are local in > the sense that you can declare them where you need > them, like my example. > >> Inner classes are classes within classes (same as package inside >> package, which Ada of course allows), not classes inside functions. > > Anonymous classes are a type of inner class, and they most certainly > can be declared/created within functions. Please see this reference: > <http://java.sun.com/docs/books/tutorial/java/javaOO/innerclasses.html>. But that is only a syntax -hack for lazy typers. The so called "local" classes are actualy global classes with special naming convention - usualy invoving a "$" in the middle of the name. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 7:59 ` Martin Krischik @ 2004-09-02 13:33 ` Hyman Rosen 2004-09-02 14:38 ` Jean-Pierre Rosen 2004-09-02 16:32 ` Martin Krischik 0 siblings, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-02 13:33 UTC (permalink / raw) Martin Krischik wrote: > But that is only a syntax -hack for lazy typers. The so called "local" > classes are actualy global classes with special naming convention - usualy > invoving a "$" in the middle of the name. This discussion started when JPR said However, all other OO languages (that I know of) require *all* classes to be declared at library level. This is demonstrably untrue (unless JPR knows of neither C++ nor Java); Java and C++ do allow classes to be declared other than at library level, including inside functions. Neither C++ nor Java has Pascal-like block structure, so these local classes interact more weakly with their declaration environment than would be the case otherwise, but they are nevertheless locally declared. Because of this weaker interaction, types in C++ and Java do not have or need a lifetime, so they are global in that sense, but not in a name lookup sense. In C++, I can do void f() { static int x; struct c { int f() { return x; } }; } ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 13:33 ` Hyman Rosen @ 2004-09-02 14:38 ` Jean-Pierre Rosen 2004-09-02 15:33 ` Hyman Rosen 2004-09-02 16:32 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-09-02 14:38 UTC (permalink / raw) Hyman Rosen a écrit : > This discussion started when JPR said > However, all other OO languages (that I know of) require > *all* classes to be declared at library level. > > This is demonstrably untrue (unless JPR knows of neither C++ nor Java); > Java and C++ do allow classes to be declared other than at library level, > including inside functions. Neither C++ nor Java has Pascal-like block > structure, so these local classes interact more weakly with their > declaration environment than would be the case otherwise, but they are > nevertheless locally declared. Because of this weaker interaction, types > in C++ and Java do not have or need a lifetime, so they are global in > that sense, but not in a name lookup sense. > > In C++, I can do > void f() { static int x; struct c { int f() { return x; } }; } They can be *declared* in functions, but they behave as globals. For examples, I think (correct me if I'm wrong) that they cannot refer to local parameters of the functions. They are global classes, whose visibility is restricted to a function. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 14:38 ` Jean-Pierre Rosen @ 2004-09-02 15:33 ` Hyman Rosen 0 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-02 15:33 UTC (permalink / raw) Jean-Pierre Rosen wrote: > They can be *declared* in functions Yes. You said they couldn't be! > but they behave as globals. For examples, they cannot refer to local parameters > of the functions. Correct for C++. Java local classes may refer to constant local parameters and variables of the defining scope, but Java does this by cheating; the local class gets copies of these when it is created. > They are global classes, whose visibility is restricted to a function. Yes (for a suitable definition of global). This does not make the ability to declare them locally any less useful. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 13:33 ` Hyman Rosen 2004-09-02 14:38 ` Jean-Pierre Rosen @ 2004-09-02 16:32 ` Martin Krischik 2004-09-02 18:50 ` Hyman Rosen 1 sibling, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-09-02 16:32 UTC (permalink / raw) Hyman Rosen wrote: > Martin Krischik wrote: >> But that is only a syntax -hack for lazy typers. The so called "local" >> classes are actualy global classes with special naming convention - >> usualy invoving a "$" in the middle of the name. > > This discussion started when JPR said > However, all other OO languages (that I know of) require > *all* classes to be declared at library level. > > This is demonstrably untrue (unless JPR knows of neither C++ nor Java); > Java and C++ do allow classes to be declared other than at library level, > including inside functions. Neither C++ nor Java has Pascal-like block > structure, so these local classes interact more weakly with their > declaration environment than would be the case otherwise, but they are > nevertheless locally declared. Because of this weaker interaction, types > in C++ and Java do not have or need a lifetime, so they are global in > that sense, but not in a name lookup sense. But my argument is: "Java cheats". You declare at local level, but you get library level. Have a look at the following list: -rw-rw----+ 1 2,7K 2004-09-01 13:42 Empfangen.class -rw-rw----+ 1 1,1K 2004-09-01 13:42 Empfangen$My_Authenticator.class -rw-rw----+ 1 991 2004-09-01 13:42 Empfangen$Nachricht.class -rw-rw----+ 1 1,2K 2004-09-01 12:46 Messages.class -rw-rw----+ 1 132 2004-09-01 13:28 messages.properties -rw-rw----+ 1 2,2K 2004-09-01 13:45 Senden.class The so called "local" classes even get there own files. With Regards Maritn -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 16:32 ` Martin Krischik @ 2004-09-02 18:50 ` Hyman Rosen 0 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-02 18:50 UTC (permalink / raw) Martin Krischik wrote: > But my argument is: "Java cheats". You declare at local level, but you get > library level. The so called "local" classes even get there own files. That's not cheating, that's compiling. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 7:25 ` Kevin Cline 2004-08-31 9:37 ` Jean-Pierre Rosen @ 2004-08-31 9:57 ` Dmitry A. Kazakov 2004-08-31 11:51 ` Martin Krischik 2004-09-02 19:10 ` Simon Wright 3 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-31 9:57 UTC (permalink / raw) On 31 Aug 2004 00:25:27 -0700, Kevin Cline wrote: > This is true. Classes stored in STL containers need not be > default-constructible, but they must be assignable and copyable. Consider this: procedure Foo (Object : Thing'Class) is Copy : Thing'Class := Object; -- Assignment "dispatches" in Ada! begin ... I should admit that I do not know how to do it in C++. Probably it is fundamentally impossible. [ Background: once I designed a kind of rendezvous for C++. I was stunned by the problem of exception handling. One catches an exception in one thread and then re-raises it in another. Well, all exceptions have to be derived from the same base. But you cannot copy a class-wide object in C++! (throw is like return) ] > I seem to have confused limited types and controlled types, probably > because I stopped programming in Ada before there were controlled > types. Still, using controlled types also seems to be problematical. Much as classes in C++, controlled types in Ada are a hack designed to not disturb the rest language. It quickly achieves its goal, to make OO programming possible, but in a long term perspective a more consequent solution is needed. IMO the program for Ada 2010 should be: 1. all specific types have T'Class-classes 2. all types have constructors/destructors 3. all attributes are primitive operations 4. all built-in operations are primitive 5. all predefined classes (array, record, access etc) are T'Class-classes 6. multiple inheritance 7. multiple dispatch -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 7:25 ` Kevin Cline 2004-08-31 9:37 ` Jean-Pierre Rosen 2004-08-31 9:57 ` Dmitry A. Kazakov @ 2004-08-31 11:51 ` Martin Krischik 2004-09-02 19:10 ` Simon Wright 3 siblings, 0 replies; 387+ messages in thread From: Martin Krischik @ 2004-08-31 11:51 UTC (permalink / raw) Kevin Cline wrote: > Martin Krischik <krischik@users.sourceforge.net> wrote in message > news:<1198227.gWQ0keDDOY@linux1.krischik.com>... > I don't know about you, but that mades my head hurt. In C++ there are > some things that make my head hurt too, but they mostly are there to > determine the meaning of code that I would naver write in the first > place. Well there where looking for problems where there arn't any. Or how often us use the following C++ Feature: void Function () { class Nested { ... } return; } Because that is what the problem described was about. There is a reason why Ada can't do it. And the reason was that Ada can actualy have the equivalent of vector<T> - and that is far more helpfull then non library level classes. There was discussion about that before - please no repeat. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 7:25 ` Kevin Cline ` (2 preceding siblings ...) 2004-08-31 11:51 ` Martin Krischik @ 2004-09-02 19:10 ` Simon Wright 2004-09-12 11:02 ` Anders Gidenstam 3 siblings, 1 reply; 387+ messages in thread From: Simon Wright @ 2004-09-02 19:10 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > For example, I found this at http://www.gidenstam.org/Ada/: > This library, the Add Finalization Anywhere Library, provides a > nice(?) way to add finalization to any (limited) tagged type at any > level. The structure of the library is inspired by Christoph Karl > Walter Grein's library for adding finalization to library level > tagged types and my library is designed to integrate well with his. > > However, since declaring controlled types elsewhere than at the > library level isn't supported by Ada there is a lot of hackish > things going on inside the library. Currently, I don't know whether > the these things work on any other compiler than GNAT 3.13p and > whether they are at all sane." I'm pretty sure that Christophe's library only worked because of bugs in GNAT 3.13p. The reference (after a _very_ strange compilation problem) loops with 3.16a1; with 5.02a1 it does something which looks not unreasonable... -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-02 19:10 ` Simon Wright @ 2004-09-12 11:02 ` Anders Gidenstam 2004-09-12 13:47 ` Simon Wright 0 siblings, 1 reply; 387+ messages in thread From: Anders Gidenstam @ 2004-09-12 11:02 UTC (permalink / raw) In article <x7vllfsa3mc.fsf@smaug.pushface.org>, Simon Wright <simon@pushface.org> writes: > kevin.cline@gmail.com (Kevin Cline) writes: > >> For example, I found this at http://www.gidenstam.org/Ada/: > >> This library, the Add Finalization Anywhere Library, provides a >> nice(?) way to add finalization to any (limited) tagged type at any >> level. The structure of the library is inspired by Christoph Karl >> Walter Grein's library for adding finalization to library level >> tagged types and my library is designed to integrate well with his. >> >> However, since declaring controlled types elsewhere than at the >> library level isn't supported by Ada there is a lot of hackish >> things going on inside the library. Currently, I don't know whether >> the these things work on any other compiler than GNAT 3.13p and >> whether they are at all sane." > > I'm pretty sure that Christophe's library only worked because of bugs > in GNAT 3.13p. > > The reference (after a _very_ strange compilation problem) loops with > 3.16a1; with 5.02a1 it does something which looks not unreasonable... Hi! Yes, my experiment (Add Finalization Anywhere, http://www.gidenstam.org/Ada/) is very much a hack and it does not work on GNAT 3.15p either. Do not use it for anything that needs to work! Btw, I suppose you meant "does something which looks unreasonable" above, right? :) (Or does it work with 5.02a?! That would be a suprise..) Best Regards, Anders Gidenstam -- "Luck is my middle name," said Rincewind, indistinctly. "Mind you, my first name is Bad." -- (Terry Pratchett, Interesting Times) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 11:02 ` Anders Gidenstam @ 2004-09-12 13:47 ` Simon Wright 2004-09-12 15:20 ` Anders Gidenstam 0 siblings, 1 reply; 387+ messages in thread From: Simon Wright @ 2004-09-12 13:47 UTC (permalink / raw) anders@legolas.gidenstam.se (Anders Gidenstam) writes: > In article <x7vllfsa3mc.fsf@smaug.pushface.org>, > Simon Wright <simon@pushface.org> writes: > > The reference (after a _very_ strange compilation problem) loops with > > 3.16a1; with 5.02a1 it does something which looks not unreasonable... [...] > Btw, I suppose you meant "does something which looks unreasonable" > above, right? :) > (Or does it work with 5.02a?! That would be a suprise..) Since I don't know what it is supposed to do I can't tell whether what it seems to do is right. The program terminates without an exception after printing out progress messages .. that's all I meant. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 13:47 ` Simon Wright @ 2004-09-12 15:20 ` Anders Gidenstam 2004-09-12 16:36 ` Simon Wright 0 siblings, 1 reply; 387+ messages in thread From: Anders Gidenstam @ 2004-09-12 15:20 UTC (permalink / raw) In article <x7vllffzjj5.fsf@smaug.pushface.org>, Simon Wright <simon@pushface.org> writes: > anders@legolas.gidenstam.se (Anders Gidenstam) writes: > >> In article <x7vllfsa3mc.fsf@smaug.pushface.org>, >> Simon Wright <simon@pushface.org> writes: >> > The reference (after a _very_ strange compilation problem) loops with >> > 3.16a1; with 5.02a1 it does something which looks not unreasonable... > [...] >> Btw, I suppose you meant "does something which looks unreasonable" >> above, right? :) >> (Or does it work with 5.02a?! That would be a suprise..) > > Since I don't know what it is supposed to do I can't tell whether what > it seems to do is right. The program terminates without an exception > after printing out progress messages .. that's all I meant. Well, the small test program should output something like this when it works: # ./test_finalization_anywhere Tjo! Controlled_Local: Finalized 3221223464. (Dummy => 1, Bepa => 12) # On GNAT 3.15p it gets stuck in a loop and keeps calling Finalize. The cause seems to be that the part of the Limited_Controlled_Component belonging to Ada.Finalization.Controlled does not get initialized when the Limited_Controlled_Component, which is derived from it, is. The relevant part of the code in the package Add_Finalization.Anywhere.To_Limited_Uncontrolled: type Limited_Controlled is abstract new Uncontrolled with record Controller : Limited_Controlled_Component := Limited_Controlled_Component' (Ada.Finalization.Controlled with Object => To_Raw (Limited_Controlled'Unchecked_Access), Initialize => To_Operation (Raw_Initialize'Access), Finalize => To_Operation (Raw_Finalize'Access)); ... end record; What I try to do is to connect the real controlled type to the non-library level type, but with 3.15p the Ada.Finalization.Controlled part does not get initialized properly (it did with GNAT 3.11p). Does anyone know if it is possible to successfully initialize the Limited_Controlled_Component with the values above while at the same time ensuring that the Ada.Finalization.Controlled part is also initialized? (The full code is available here: http://www.gidenstam.org/Ada/add_finalization_anywhere20031106.tar.gz ) Best Regards, Anders Gidenstam -- "Luck is my middle name," said Rincewind, indistinctly. "Mind you, my first name is Bad." -- (Terry Pratchett, Interesting Times) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 15:20 ` Anders Gidenstam @ 2004-09-12 16:36 ` Simon Wright 2004-09-12 18:33 ` Anders Gidenstam 0 siblings, 1 reply; 387+ messages in thread From: Simon Wright @ 2004-09-12 16:36 UTC (permalink / raw) anders@legolas.gidenstam.se (Anders Gidenstam) writes: > Well, the small test program should output something like this when > it works: > # ./test_finalization_anywhere > Tjo! > Controlled_Local: Finalized 3221223464. (Dummy => 1, Bepa => 12) > # I certainly wouldn't run it as root! Here, I get smaug.pushface.org[17]$ ./test_finalization_anywhere Tjo! Controlled_Local2: Finalized 3221222688. ( 0, 12, 74) Controlled_Local: Finalized 3221222752. ( 2, 12) Controlled_Local: Finalized 3221222816. ( 0, 12) smaug.pushface.org[18]$ -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:36 ` Simon Wright @ 2004-09-12 18:33 ` Anders Gidenstam 0 siblings, 0 replies; 387+ messages in thread From: Anders Gidenstam @ 2004-09-12 18:33 UTC (permalink / raw) In article <x7vhdq3zboc.fsf@smaug.pushface.org>, Simon Wright <simon@pushface.org> writes: > I certainly wouldn't run it as root! No, I certainly wouldn't do that either, but since '>' is the quotation mark I had to be creative.. :) > Here, I get > > smaug.pushface.org[17]$ ./test_finalization_anywhere > Tjo! > Controlled_Local2: Finalized 3221222688. ( 0, 12, 74) > Controlled_Local: Finalized 3221222752. ( 2, 12) > Controlled_Local: Finalized 3221222816. ( 0, 12) > smaug.pushface.org[18]$ Thanks! Interesting, then it actually seems to work in that case, as the three test objects (LC, LC2 and LC3) seems to be finalized properly. The next step would be to write some more extensive tests but I don't know if it is worth the effort considering the shakiness of the whole approach. /Anders -- "Luck is my middle name," said Rincewind, indistinctly. "Mind you, my first name is Bad." -- (Terry Pratchett, Interesting Times) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 15:23 ` Richard Riehle 2004-08-26 21:08 ` Kevin Cline @ 2004-08-29 15:13 ` jayessay 2004-08-29 16:34 ` Richard Riehle 1 sibling, 1 reply; 387+ messages in thread From: jayessay @ 2004-08-29 15:13 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > also know some C++. My class is a multi-language class in > which students are learning Ada, C++, Lisp, and a little bit Please, please tell me you are not telling them that Lisp is a functional language which only has recursion for looping and only has symbols and lists for data representation. And please say you never use examples like: (setq foo '(a b c)) /Jon -- 'jay' - a n t h o n y at romeo/november/charley com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 15:13 ` jayessay @ 2004-08-29 16:34 ` Richard Riehle 0 siblings, 0 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-29 16:34 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3oekuf050.fsf@rigel.goldenthreadtech.com... > "Richard Riehle" <adaworks@earthlink.net> writes: > > > also know some C++. My class is a multi-language class in > > which students are learning Ada, C++, Lisp, and a little bit > > Please, please tell me you are not telling them that Lisp is a > functional language which only has recursion for looping and only has > symbols and lists for data representation. > > And please say you never use examples like: > > (setq foo '(a b c)) > Good question, Jay. Actually, whenever possible, for the Lisp unit in this class, I invite one of our other professors, a Lisp advocate and Lisp expert, to guest lecture a few sessions. For Prolog, I do the same. In each case, those guest lecturers illustrate the capabilities of those languages with large, real-life applications they have actually deployed. The combination of their experience and their enthusiasm for their preferred language encourages students to consider such alternatives when they need to make a choice. One of my goals, in this course, is to broaden the perspective of the students so they will understand the benefits of the choices available to them when they are confronted with real-world problems. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 0:18 ` fabio de francesco 2004-08-23 3:44 ` Wes Groleau 2004-08-23 15:23 ` Richard Riehle @ 2004-08-23 17:27 ` Dmitry A. Kazakov 2004-08-23 18:59 ` Georg Bauhaus 2004-08-23 22:20 ` Richard Riehle 2004-08-26 21:22 ` Kevin Cline 3 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-23 17:27 UTC (permalink / raw) On 22 Aug 2004 17:18:28 -0700, fabio de francesco wrote: > 3) "I think the very existence of limited types" (Ok, Proven > Assumption) > "is a fundamental flaw in Ada".(Unrelated Consequences). > How can it be proved? Please will someone ( may be Kevin itself ) show > me the rationale of this reasoning? Whether it was a fundamental flaws is a question, but not everybody is happy with limited types. They are a mixture of quite different concepts which probably should be dealt separately: 1. No assignment, never 2. No predefined [in]equality 3. Cannot be initialized (who need such? Ada 2005 will probably fix that) 4. Cannot be copied (no copy constructor) 5. Passed by reference 4 => 5, but why 5 should imply 4? 2 is unrelated to anything else. 1 should be no different from 2 or any other *operation*. 3 is nonsense. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 17:27 ` Dmitry A. Kazakov @ 2004-08-23 18:59 ` Georg Bauhaus 2004-08-24 7:07 ` Dmitry A. Kazakov 2004-08-23 22:20 ` Richard Riehle 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-23 18:59 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : 1 ["="] should : be no different from 2 [":="] or any other *operation*. (just not predefined?) What should be the rule for extensions, then? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 18:59 ` Georg Bauhaus @ 2004-08-24 7:07 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-24 7:07 UTC (permalink / raw) On Mon, 23 Aug 2004 18:59:36 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: 1 ["="] should >: be no different from 2 [":="] or any other *operation*. > > (just not predefined?) What should be the rule for extensions, then? No different in the sense that ":=" should be treated as a primitive operation rather than a hard-wired something. I do not propose ":=" to have a result, like in C++. But clearly, it should be [multiple] dispatching. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 17:27 ` Dmitry A. Kazakov 2004-08-23 18:59 ` Georg Bauhaus @ 2004-08-23 22:20 ` Richard Riehle 2004-08-24 7:07 ` Dmitry A. Kazakov 1 sibling, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-23 22:20 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1w3sfkwcp4q0e.1u4xeln7msgi5$.dlg@40tude.net... > Regarding limited types: > Whether it was a fundamental flaws is a question, but not everybody is > happy with limited types. They are a mixture of quite different concepts > which probably should be dealt separately: > > 1. No assignment, never > 2. No predefined [in]equality > 3. Cannot be initialized (who need such? Ada 2005 will probably fix that) > 4. Cannot be copied (no copy constructor) > 5. Passed by reference > Of your criticisms, only number 3 is an occasional, but not insurmountable nuisance. I take 1 and 4 together. Assignment and copy are identical in many respects. When I design with limited types, I nearly always include a "copy" procedure in my design. Someties I include a "Move." And sometimes I include a more specific "copy" one that tells the client of my package specifically what to expect in calling the copy procedure. As to point number 3. For composite types, especially record types, I don't want predefined equality. This is one of the most important ideas in limited types. Instead, I design functions that test for equality that do not use the "=" operator. For example, function Key_is_Equal (L, R : limited_type) return Boolean; function Data_Is_Equal (L, R : limited_type) return Boolean; When someone calls one of these functions, they know exactly what they are getting. It may not be as convenient as the "=", but no one every complains about being surprised by the result. > 4 => 5, but why 5 should imply 4? 2 is unrelated to anything else. 1 should > be no different from 2 or any other *operation*. 3 is nonsense. > Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 22:20 ` Richard Riehle @ 2004-08-24 7:07 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-24 7:07 UTC (permalink / raw) On Mon, 23 Aug 2004 22:20:59 GMT, Richard Riehle wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:1w3sfkwcp4q0e.1u4xeln7msgi5$.dlg@40tude.net... >> Regarding limited types: > >> Whether it was a fundamental flaws is a question, but not everybody is >> happy with limited types. They are a mixture of quite different concepts >> which probably should be dealt separately: >> >> 1. No assignment, never >> 2. No predefined [in]equality >> 3. Cannot be initialized (who need such? Ada 2005 will probably fix that) >> 4. Cannot be copied (no copy constructor) >> 5. Passed by reference >> > Of your criticisms, only number 3 is an occasional, but not insurmountable > nuisance. > > I take 1 and 4 together. Assignment and copy are identical in many > respects. When I design with limited types, I nearly always include a > "copy" procedure in my design. Someties I include a "Move." And > sometimes I include a more specific "copy" one that tells the client > of my package specifically what to expect in calling the copy procedure. I would separate copy constructors from ":=". You may have no copy constructor, preventing by-copy parameter passing, but still have ":=". Similarly you can have a copy constructor and so an ability to pass something by copy, but no ":=" (for example, to prevent random numbers or smart pointers from copying). Though one can generate ":=" from a copy constructor, what Ada compilers actually do, they are unrelated. Why not to open this mechanics for user-defined types? In my view absence of constructors is a real problem of Ada. Should we have them (and for all types), many problems (user-defined assignments, streaming limited tagged types, construction of limited types on the stack, effective implementation of user-defined access types [smart pointers], default values for standard types etc) could be solved. I agree that it would not be easy to do. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-23 0:18 ` fabio de francesco ` (2 preceding siblings ...) 2004-08-23 17:27 ` Dmitry A. Kazakov @ 2004-08-26 21:22 ` Kevin Cline 3 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-26 21:22 UTC (permalink / raw) fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408221618.475d5941@posting.google.com>... > "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<GVZVc.9513$3O3.1068@newsread2.news.pas.earthlink.net>... > > > It seems that, even when I am trying to be generous toward someone > > with a different point-of-view, a few on my side of the argument > > can still be offended by that very generosity. > > I don't think that "offended" is the right verb, it seems excessive to > me. > > > I am satisfied that Kevin has applied his own criteria with intelligence > > and and sincerity to reaching his conclusions. I don't share his > > conclusions, and given the same information, have come to a > > different viewpoint. My concession is not an admission of defeat > > in the argument. > > I also don't want to make any assumptions on the cleverness of people. > I just say that whenever you discuss matters of taste people can have > different points of view, but in the case of a scientific problem with > given informations people should come to the same conclusions. The > only exceptions are either you have wrong given data or you take the > wrong explanation path. > He only lists wrong and 'unproven assumptions' and he also gets > 'unrelated consequencies'. > > At > http://groups.google.com/groups?q=g:thl4042257105d&dq=&hl=en&lr=&ie=UTF-8&selm=e749549b.0408200838.43e841d%40posting.google.com&rnum=53 > Kevin says: > > 1) "Yes. The syntax, and particularly the need for explicit generic > instantiation, makes Ada programs much longer than equivalent C++ > programs. Longer programs take longer to write and longer to read." > Where is the evidence that an Ada program is longer than a C++ one? ( > Unproven Assumption ). > What does demonstrate that the time it takes to read and understand > lines of code are related to the lenght of the code itself? ( > Unrelated Consequences ). From http://home.t-online.de/home/christ-usch.grein/Ada/Dimension.html by Christopher Grein: "There exists also the Ada Issue 324, an Ada0Y proposal by the Ada Rapporteur Group for handling physical dimensions. Unfortunately I could not include my view on it in the conference proceedings because the final submission date for papers had just expired when the ARG proposal was published. So a very short outline thereof is included only in the PowerPoint presentation. The proposal exhibits a very clever use of generics and generic package parameters, so it is worth reading just for the expressive power of Ada. However because of the tremendous number of instantiations needed, it is yet another demonstration that Ada is not suited to doing unit checking during compile time. It is therefor no longer pursued by the ARG. You can find details directly in the Ada Issues Database of the Ada Conformity Assessment Authority. A C++ solution, which is very similar to the Ada one presented here - it does however not include fractional powers, can be found at http://www.fnal.gov/docs/working-groups/fpcltf/html/SIunits-summary.html. The big difference is that C++ templates allow type checking during compile-time, so that no overhead neither in memory space nor in runtime is incurred. In this respect, C++ templates are more powerful than Ada generics. However at the time of this writing (11 February 2004), not all C++ compilers, although capable of compiling the code, are able to actually perform this type checking (as stated in the documentation of the method)." The need for explicit generic instantiation is a major roadblock in building sophisticated type systems and libraries in Ada. I repeatedly found that repeated code which could easily be refactored into C++ templates could not be conveniently expressed with Ada generics. > > 2) (Question: Is the ability to define one's own types?) > "That is a problem." > ( Unproven Assumption. He wants to demonstrate > that a capability doesn't add anything to the power of a language, > instead he says that the feature steals something to Ada ) > "User defined types are less compatable with built-in types than they > are in C++." ( This means nothing to me ) > "This makes generic programming more difficult." ( Whom for? > Unrelated Consequence ) > "I find it more difficult to factor out duplication in Ada than I do > in C++." ( This is only his problem and it doesn't prove anything ) Perhaps these isues are outside your experience as a programmer? How much experience do you have writing Ada generics and C++ templates? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-21 23:23 ` fabio de francesco 2004-08-22 7:16 ` fabio de francesco 2004-08-22 9:44 ` Richard Riehle @ 2004-08-26 20:32 ` Kevin Cline 2004-08-27 11:53 ` Georg Bauhaus 2 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-08-26 20:32 UTC (permalink / raw) fmdf@tiscali.it (fabio de francesco) wrote in message news:<ba2f9c57.0408211523.389cf201@posting.google.com>... > "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<tJqVc.7839$3O3.4242@newsread2.news.pas.earthlink.net>... > > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > > news:e749549b.0408200838.43e841d@posting.google.com... > > > > Kevin, > > > > I have read your reasons for preferring C++ over Ada, > > and appreciate that you have looked at this matter > > with diligence and an honest sense of inquiry. Because > > of my confidence in the intelligent approach you took > > to reach your conclusions, I will not presume to persuade > > you to depart from your position. > > What intelligent approach? He (Kevin) was able(?) to demonstrate that > some of the most interesting and powerful features of Ada represent > its major faults. I think He simply doesn't understand how to use > those features for achieving the better results and for the clever > maintaining of programs. I programmed in Ada-83 for two years before starting with C++. I knew Ada-83 inside-out, and stressed it enough to find bugs in both the Verdix and Telesoft compilers. Unfortunately, most of the claimed advantages of Ada just don't make much of an impact on the applications I have worked on over the past 25 years. And there are few features of Ada that can't be duplicated by writing a C++ template class. OTOH, there is no way in Ada to produce the equivalent of sophisticated C++ libraries like the Boost spirit parser. > I don't think so. It shouldn't be just a matter of personal preference > or a matter of taste. I have begun to think that in order to really > understand, appreciate and use Ada, someone is to have some more > experience, open mind and a more vast computer science background than > that we commonly find in the average programmer. But Ada has been almost universally ignored by the Computer Science research community. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 20:32 ` Kevin Cline @ 2004-08-27 11:53 ` Georg Bauhaus 2004-08-27 21:48 ` Kevin Cline 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-27 11:53 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : OTOH, there is no way in Ada to produce the equivalent of : sophisticated C++ libraries like the Boost spirit parser. There might be no way to produce the exact equivalent of C++ template computing based libraries using Ada generics. There certainly are ways to produce sophisticated libraries in Ada. For the spirit parser, see my other post about the SPITBOL library. : But Ada has been almost universally ignored by the Computer Science : research community. Could you give some examples? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 11:53 ` Georg Bauhaus @ 2004-08-27 21:48 ` Kevin Cline 2004-08-28 5:02 ` Richard Riehle ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-27 21:48 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn7bm$snk$3@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : OTOH, there is no way in Ada to produce the equivalent of > : sophisticated C++ libraries like the Boost spirit parser. > > There might be no way to produce the exact equivalent of C++ template > computing based libraries using Ada generics. > There certainly are ways to produce sophisticated libraries in Ada. > For the spirit parser, see my other post about the SPITBOL library. > > : But Ada has been almost universally ignored by the Computer Science > : research community. > > Could you give some examples? An example of what? Of computer scientists who do not program in or teach Ada? Are there any CS programs that have chosen Ada as their core language? I rarely meet recent graduates with any exposure to Ada at all. For better or worse, (worse in my opinion), most CS departments seem to have settled on Java. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 21:48 ` Kevin Cline @ 2004-08-28 5:02 ` Richard Riehle 2004-08-30 19:16 ` Kevin Cline 2004-08-28 10:20 ` Georg Bauhaus 2004-08-30 12:20 ` Jano 2 siblings, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-28 5:02 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0408271348.74f5a957@posting.google.com... > > Are there any CS programs that have chosen Ada as their core language? > I rarely meet recent graduates with any exposure to Ada at all. For > better or worse, (worse in my opinion), most CS departments seem to > have settled on Java. > On this point we agree. In my programming paradigms course (taught at the graduate school level), I have opted to begin with functional languages instead of imperative languages. The students entering this course already have at least one Quarter of Java. In my view, they need to understand how to write programs without doing any assignment at all. I follow that with C then C++ then Ada and a brief look at Eiffel, Prolog, and a few others (sometimes Smalltalk if there is time). Students need to have more languages and need to learn them from a positive viewpoint. As much as I dislike C++, I try to keep students interested in it from a positive attitude. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 5:02 ` Richard Riehle @ 2004-08-30 19:16 ` Kevin Cline 2004-08-31 12:16 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-08-30 19:16 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<olUXc.625$8d1.548@newsread2.news.pas.earthlink.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0408271348.74f5a957@posting.google.com... > > > > Are there any CS programs that have chosen Ada as their core language? > > I rarely meet recent graduates with any exposure to Ada at all. For > > better or worse, (worse in my opinion), most CS departments seem to > > have settled on Java. > > > On this point we agree. In my programming paradigms > course (taught at the graduate school level), I have opted > to begin with functional languages instead of imperative > languages. I applaud you for this. In my experience, programmers familiar with functional languages learn a deeper way of thinking about code, and tend to produce much smaller and more maintainable code than programmers who have never been exposed to FP. > The students entering this course already > have at least one Quarter of Java. In my view, they > need to understand how to write programs without > doing any assignment at all. Perhaps more importantly, how to write programs without the array and the for-loop. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-30 19:16 ` Kevin Cline @ 2004-08-31 12:16 ` Georg Bauhaus 2004-09-03 15:25 ` Kevin Cline 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-31 12:16 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Perhaps more importantly, how to write programs without : the array and the for-loop. I'd agree with you if this weren't about Ada arrays. True, some programs with little to no support for "true" arrays still show arrays where sets, maps, lists, etc. should be, using that language. But then I always miss the close connection of Ada's enumeration types and Ada's arrays, and Ada's predefined operations of array types. Ada enums allow me to name things known at compile time. In addition, Ada arrays made with an Ada enum as index type can be used like a map. Due to the index type mechanism, completeness checks are made at compile time. For example, an array aggregate must be completely specified. A case distinction looking at a value of an array's index must handle each case. Ada arrays can also be used like lists, with concatenation predefined, and with a NIL (null range). Using any number of dimensions. They can be used with generic array algorithms, with built in bounds checking and loop index optimizations. They can also be used with STL like array algorithms when there is a simple adapter that makes them look like a container. Bounds can be determined and set at run time, like index subtypes. Arrays can be returned on the stack, allowing typical recursive list processing subprograms. No for loops required. :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-31 12:16 ` Georg Bauhaus @ 2004-09-03 15:25 ` Kevin Cline 2004-09-03 18:51 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-03 15:25 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ch1q7n$q56$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > > : Perhaps more importantly, how to write programs without > : the array and the for-loop. > > I'd agree with you if this weren't about Ada arrays. > True, some programs with little to no support for "true" > arrays still show arrays where sets, maps, lists, etc. > should be, using that language. But then I always miss the > close connection of Ada's enumeration types and Ada's arrays, > and Ada's predefined operations of array types. > > Ada enums allow me to name things known at compile time. In addition, > Ada arrays made with an Ada enum as index type can be used like > a map. Due to the index type mechanism, completeness checks > are made at compile time. For example, an array aggregate > must be completely specified. A case distinction looking at > a value of an array's index must handle each case. > > Ada arrays can also be used like lists, with concatenation predefined, > and with a NIL (null range). Using any number of dimensions. > > They can be used with generic array algorithms, with built > in bounds checking and loop index optimizations. > They can also be used with STL like array algorithms when > there is a simple adapter that makes them look like a > container. > > Bounds can be determined and set at run time, like index > subtypes. > Arrays can be returned on the stack, allowing typical recursive > list processing subprograms. No for loops required. :-) No doubt that Ada has fabulous support for integer-indexed arrays. Still, in my experience what is most often wanted in applications is not an integer-indexed array, but a map or set. In 25 years of programming I have seen about 17,000 implementations of linear search and 5,000 implementations of sorted insertion, almost all of which could and should have been eliminated by using an associative container of some sort. I've seen large applications where over half the code was devoted to looping through arrays in one way or another. I've seen multiple instances where someone had written array-based code with O(n^3) run-time while vastly simpler map-based code would have run in O(n) time. By providing extensive facilities for array-based programming while ignoring all other data structures, Ada leads most programmers to do the wrong thing, and frustrates most of the remainder. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 15:25 ` Kevin Cline @ 2004-09-03 18:51 ` Georg Bauhaus 2004-09-05 3:59 ` Kevin Cline 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-03 18:51 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : No doubt that Ada has fabulous support for integer-indexed arrays. (and name-indexed arrays :-) : In 25 years of : programming I have seen about 17,000 implementations of linear search : and 5,000 implementations of sorted insertion, almost all of which : could and should have been eliminated by using an associative : container of some sort. OK : By providing extensive facilities for array-based programming while : ignoring all other data structures, Ada leads most programmers to do : the wrong thing, and frustrates most of the remainder. Well, ignoring... the next Ada will have vectors, sets, tables, lists, and then some, such that more (queues, ...) can be built on top of them, by default, and standardised. AFAIKT the specifications are influenced by experience with libraries in at least Ada and STL. So if programmers have been using arrays for things that arent't arrays, there must be a problem other than availability of data structure libraries? A general lack of awareness of how ADTs work? Maybe, if the situation is really that bad, the standardised components will ameliorate Ada programming WRT proper data structures. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 18:51 ` Georg Bauhaus @ 2004-09-05 3:59 ` Kevin Cline 0 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-05 3:59 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chaeg8$32k$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > > : No doubt that Ada has fabulous support for integer-indexed arrays. > > (and name-indexed arrays :-) > > : In 25 years of > : programming I have seen about 17,000 implementations of linear search > : and 5,000 implementations of sorted insertion, almost all of which > : could and should have been eliminated by using an associative > : container of some sort. > > OK > > : By providing extensive facilities for array-based programming while > : ignoring all other data structures, Ada leads most programmers to do > : the wrong thing, and frustrates most of the remainder. > > Well, ignoring... the next Ada will have vectors, sets, tables, lists, > and then some, such that more (queues, ...) can be built on top of them, > by default, and standardised. > AFAIKT the specifications are influenced by experience with > libraries in at least Ada and STL. So if programmers have been > using arrays for things that arent't arrays, there must be > a problem other than availability of data structure libraries? > A general lack of awareness of how ADTs work? One might expect that graduates from a four-year degree program in computer science would at least understand the characteristics of basic data structures, but sadly that seems not to be the case. I've interviewed many, and relatively few were able to even tell me the run-time complexity of code they had just written. Generally I've found that programmers use the features that were covered in class or described in their chosen textbook or manual. And most programmers will read only one or two books on any given language. Textbooks and manuals rarely cover anything that is not part of the core language. I would expect that most C++ texts to at least superficially describe the STL, but very few will even mention multi-threaded programming. I would expect Ada texts to cover threading, but would be surprised to see anything more than a mention of CHARLES or other data structure libraries. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 21:48 ` Kevin Cline 2004-08-28 5:02 ` Richard Riehle @ 2004-08-28 10:20 ` Georg Bauhaus 2004-08-28 10:30 ` Adrian Knoth ` (2 more replies) 2004-08-30 12:20 ` Jano 2 siblings, 3 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-28 10:20 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgn7bm$snk$3@a1-hrz.uni-duisburg.de>... :> : But Ada has been almost universally ignored by the Computer Science :> : research community. :> :> Could you give some examples? : An example of what? Of computer scientists who do not program in or : teach Ada? I had thought of Computer Science research. When it deals with concurrent execution in language studies or in programming oriented presentation, or the development of programming languages, there seems to be a certain awareness of Ada, even of proteced types, for example. Quite a few people I've met didn't like Ada because of they have seen it as associated with the political, military, and industrial organisations mentioned in Richard Riehle's posting. Indeed, if computer languages and compilers do not care about the purpose of a program, people do. (This is a reason why I'm somewhat uncomfortable using Ada, sometimes. The military and the weapon makers seem to be so close... ;-) People also judge languages not only by their technical merits or by how well you can express ideas in code. They appear to be influenced largely by the (non-technical) reputation of a language, by watching the peer group for acceptable pet languages, or "in"-languages, etc. (For example, Robert Axelrodt (The Complexity of Cooperation, 1997, Princeton University Press) recommends some languages to his students/readers. He compares C, FORTRAN, (Visual) Basic, Pascal, and C++. LISP, and some math languages are mentioned in a footnote. "LISP ... is especially good for handling data structures and programs interchangeably". ... "My advice is to avoid FORTRAN" ... "is an old language that is not as convenient to use as the others." ... "If a friend or coworker is available to answer questions about Pascal, for example, pick Pascal. ... designed to be a first language for serious programmers. It is easy to learn, and is structured to encourage good programming habits. Most of simulations in this volume were programmed in Pascal." ... C is the most common procedural language among serious programmers." ... "C++ was chosen as the foundation for the Java programming language" ... "If you are fairly sure that you will be doing programming for some time and want to start with a language that you can grow with, then C or C++ is the best choice." It would be interesting to know how influential this book is. But what will people who know these languages say about the comments? In particular, the "or" in the last relative clause is misinformation that if spread leads to a serious misconception in my view. (If you look at the FORTRAN code, http://pscs.physics.lsa.umich.edu/Software/ComplexCoop.html, you get an idea of why the author, referring to FORTRAN's "age and prior popularity" still says no to FORTRAN in 1997.) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 10:20 ` Georg Bauhaus @ 2004-08-28 10:30 ` Adrian Knoth 2004-08-28 11:23 ` Georg Bauhaus 2004-08-28 14:45 ` User Name 2004-08-28 20:02 ` Alexander E. Kopilovich 2 siblings, 1 reply; 387+ messages in thread From: Adrian Knoth @ 2004-08-28 10:30 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > Quite a few people I've met didn't like Ada because of they have > seen it as associated with the political, military, and industrial > organisations mentioned in Richard Riehle's posting. [..] > The military and the weapon makers seem to be so close... ;-) The possibility of writing software for airplanes like the YF22, submarines or long distance missiles and thereby having the chance to take a drink with James Bond one day was one of reasons when I decided to choose Ada. -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Mit 16 schon 'nen Freund haben aber nicht zu Mutters 32. kommen! ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 10:30 ` Adrian Knoth @ 2004-08-28 11:23 ` Georg Bauhaus 2004-08-28 12:28 ` Ludovic Brenta 2004-08-28 16:45 ` Richard Riehle 0 siblings, 2 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-08-28 11:23 UTC (permalink / raw) Adrian Knoth <adi@thur.de> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: : :> Quite a few people I've met didn't like Ada because of they have :> seen it as associated with the political, military, and industrial :> organisations mentioned in Richard Riehle's posting. : [..] :> The military and the weapon makers seem to be so close... ;-) : : The possibility of writing software for airplanes like the YF22, : submarines or long distance missiles and thereby having the chance : to take a drink with James Bond one day was one of reasons when : I decided to choose Ada. See? :-) So if this were the only factor for choosing a language, Ada's popularity will be a function of the popularity of the military. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 11:23 ` Georg Bauhaus @ 2004-08-28 12:28 ` Ludovic Brenta 2004-08-28 16:45 ` Richard Riehle 1 sibling, 0 replies; 387+ messages in thread From: Ludovic Brenta @ 2004-08-28 12:28 UTC (permalink / raw) Georg Bauhaus writes: > Adrian Knoth wrote: > : The possibility of writing software for airplanes like the YF22, > : submarines or long distance missiles and thereby having the chance > : to take a drink with James Bond one day was one of reasons when > : I decided to choose Ada. > > See? :-) So if this were the only factor for choosing a language, > Ada's popularity will be a function of the popularity of the > military. The military are not the only ones using Ada. If a language is good enough to fly airliners, run trains, or control a scanner in a hospital, then it's good enough for me. And let's not discount the "Wow!" factor, which is commonly associated with safety-critical applications, military or not. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 11:23 ` Georg Bauhaus 2004-08-28 12:28 ` Ludovic Brenta @ 2004-08-28 16:45 ` Richard Riehle 2004-08-29 15:57 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-28 16:45 UTC (permalink / raw) "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:cgppvn$t4m$1@a1-hrz.uni-duisburg.de... > > See? :-) So if this were the only factor for choosing a language, > Ada's popularity will be a function of the popularity of the military. > Popularity is rarely a good reason for choosing any tool, including a programming language. We who are software developers must understand how to use more than one tool (language, method, process, etc). Certainly some software practitioners may restrict themselves to one toolset, but this will have the long-term effect of also restricting their own career progress. We choose a tool, in any domain, according to its being appropriate for the problem we are trying to solve. To draw a somewhat rough analogy, one that I have used before in public lectures and in my publications, when I need a torque wrench (Ada) that is the tool I should choose. When I can get by with an adjustable, fits anything wrench, I might find C satisfactory for the job. Smalltalk is an excellent tool for object-oriented programming, and a good choice when the deeper concern is not software safety. Functional languages free the developer from concerns about the underlying representation issues, and allow one to work at a level of abstraction not easily available in imperative languages. I find it difficult to use functional languages for multiple programmer projects that are what we might call, large-scale. A poet friend of mine once explained that he writes some of his poems in more than one form before he is satisfied with the outcome. For example, he might have an idea for a poem which he first writes as free verse. Then he might try to write the same poem as a sonnet. Later he might try to express the idea in several haiku. At some point he might toy with it as a kind of jingle. He plays with the language, the meter, the structure, and the style before he decides on what the final poem should look like. A well-known software practitioner once explained that he first likes to write his software in Smalltalk, then produce the final code in Ada. This is somewhat like an artist who works in oil, but first sketches some ideas on the canvas with a pencil. Each of us works toward the completion of a software product in a different way. Some are more comfortable with C++. I'm not one of them. Others are more comfortable with Smalltalk, Lisp, OCAML, etc. Over the years, I have become more comfortable with Ada. I find myself able to express my ideas in the language, most of the time. There is no perfect programming language. Sometimes I might want to mix Ada and some other language (e.g., SQL or C) to achieve a level of expressiveness not directly available in Ada. That does not make Ada bad. Rather, the ability to mix other languages into my Ada code is one of the things I like about the language. So, we choose a language, not because it is popular, but because it has the expressive power for the problem space we require. In large-scale software, where lots of people will be involved in the development, and a high level of reuse is required, the structural and semantic model of Ada seems to be better than most. When certain features of some other language need to be incorporated into that large-scale design, it is no sin to admit such and take advantage of the expressive power of both Ada and the imported language to develop the appropriate solution. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 16:45 ` Richard Riehle @ 2004-08-29 15:57 ` jayessay 2004-08-29 16:47 ` Richard Riehle 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-08-29 15:57 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > Smalltalk is an excellent tool for object-oriented programming, and > a good choice when the deeper concern is not software safety. Are you trying to say that Smalltalk is somehow inherently less "safe" than things like Ada and Eiffel? What is "safe" here? > Functional languages free the developer from concerns about the > underlying representation issues, and allow one to work at a level > of abstraction not easily available in imperative languages. This isn't true as simply stated. There are counterexamples (most notably Common Lisp and to a somewhat lesser degree Scheme). What real functional languages buy you is the absence of side effects, which makes proofs about them significantly simpler /Jon -- 'jay' - a n t h o n y at romeo/november/charley com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 15:57 ` jayessay @ 2004-08-29 16:47 ` Richard Riehle 2004-09-03 16:43 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-08-29 16:47 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... > "Richard Riehle" <adaworks@earthlink.net> writes: > > > > Smalltalk is an excellent tool for object-oriented programming, and > > a good choice when the deeper concern is not software safety. > > Are you trying to say that Smalltalk is somehow inherently less "safe" > than things like Ada and Eiffel? What is "safe" here? > Ada and Eiffel are designed with more compile-time checking capabilities than Smalltalk. For safety-critical software, Ada is more appropriate, in most cases than Smalltalk. This is not meant to deprecate Smalltalk. Rather, it is intended to recognize that there are differences in languages, and some have benefits for certain kinds of problem space than others. Smalltalk certainly has its benefits, but large-scale, safety-critical software is not one of them. > > > Functional languages free the developer from concerns about the > > underlying representation issues, and allow one to work at a level > > of abstraction not easily available in imperative languages. > > This isn't true as simply stated. There are counterexamples (most > notably Common Lisp and to a somewhat lesser degree Scheme). What > real functional languages buy you is the absence of side effects, > which makes proofs about them significantly simpler > Ah, yes. Those wonderful counter-examples. You are correct about the absence of side-effects (though one can argue counter-examples even there, but I won't). When I speak of "underlying representation issues" I mean the absence of side-effects that accompany the kind of assignment that concerns an imperative language programmer. For example, a Common Lisp programmer rarely agnonizes over such silliness as constructors, copy constructors, overloading assignment operators, friends, and all the hideous little details that characterize so much of C++ programming. Functional languages tend to more focused on the problem at hand rather than the environment in which the problem will be solved and the implications of that environment on the outcome. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-29 16:47 ` Richard Riehle @ 2004-09-03 16:43 ` jayessay 2004-09-05 4:36 ` Kevin Cline ` (3 more replies) 0 siblings, 4 replies; 387+ messages in thread From: jayessay @ 2004-09-03 16:43 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > "jayessay" <nospam@foo.com> wrote in message > news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... > > "Richard Riehle" <adaworks@earthlink.net> writes: > > ... > Ada and Eiffel are designed with more compile-time checking capabilities > than Smalltalk. Static typing is largely overrated - even Hindley-Milner type systems such as in Haskell or ML (which are significantly more potent than the type systems of Eiffel or Ada). The whole thing sounds great in theory and you can make some pretty plausible arguments for its efficacy, but it just doesn't make much difference in practice. I used to be a real advocate of this stuff and made those arguments myself (both here and elsewhere). It (static typing) was one of the things I was unsure about losing when I switched to Common Lisp (aka Lisp in this message) for all my major work 7 years ago. So, I kept a log of all the errors that I knew would have been caught by compile time type checking. I don't rigorously follow this practice anymore, but as I recall there were only 15 or so in 50K "lines" of Lisp [1]. Furthermore, all but a couple of these were caught immediately on first testing of function in question. No such errors ever manefested themselves in production code. Yes, I know the typical rebuttal here is "Yet!". In theory that's true, but the evidence at this point suggests it is extremely unlikely. Also, logic errors (what most people would consider significantly more negative) are far rarer. There turn out to be various reasons for this, but two worth mentioning are the sort of bottom up style of programming as described by Paul Graham (a kind of agile/extreme programming) and the ability to move Lisp to the expressive level of the application domain. In any application/system of any significance these two go hand in hand. The second is achieved by crafting a constrained narrowly focused domain specific language _within_ Lisp, which allows the programmer to then work at the level of the domain, _both_ syntactically as well as semantically. This is why Lisp macros (please don't confuse with any other kind of macro you've come across before) are such a big deal. Now, admittedly, creating these is not something your typical code monkey is going to grok. This is one of the big reasons why Lisp will never be as "popular" as something like Java. But then your typical code monkey isn't going to be building your core internal application api either. Once you've built this though, even a code monkey will be a lot more productive and produce much more clean and robust code. > For safety-critical software, Ada is more appropriate, > in most cases than Smalltalk. This is not meant to deprecate Smalltalk. > Rather, it is intended to recognize that there are differences in languages, > and some have benefits for certain kinds of problem space than others. > Smalltalk certainly has its benefits, but large-scale, safety-critical > software > is not one of them. > > > > > Functional languages free the developer from concerns about the > > > underlying representation issues, and allow one to work at a level > > > of abstraction not easily available in imperative languages. > > > > This isn't true as simply stated. There are counterexamples (most > > notably Common Lisp and to a somewhat lesser degree Scheme). What > > real functional languages buy you is the absence of side effects, > > which makes proofs about them significantly simpler > > > Ah, yes. Those wonderful counter-examples. You are correct about > the absence of side-effects (though one can argue counter-examples > even there, but I won't). Counter examples are important for getting the _concepts_ correct. If you want to say "typically this" or "typically that", that's fine and such points can carry important information. > For example, a Common Lisp programmer rarely agnonizes over such > silliness as constructors, copy constructors, overloading assignment > operators, friends, and all the hideous little details that > characterize so much of C++ programming. True (actually "rarely" should be replaced with "never"), but those horrors are orthogonal to being imperative. Afterall, Java, lame as it is, doesn't have this type of grime to work through. > Functional languages tend to more focused on the problem at hand > rather than the environment in which the problem will be solved and > the implications of that environment on the outcome. Partly. But typical functional languages (haskell, ml, ...) don't have any means for directly encompassing domain semantics into them. For that, you need something like Lisp macros. /Jon ---- 1. Which from experience would typically be in the range of 250K-500K lines of equivalent Ada/C++/Eiffel/etc. An order of magnitude is not hyperbole here even though most uninitiated developers will raise their eyebrows or roll their eyes. I have a few examples where _two_ orders of magnitude would not be hyperbole as you would need a fully integrated and embedded optimizing compiler to achieve an equivalent result. -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 16:43 ` jayessay @ 2004-09-05 4:36 ` Kevin Cline 2004-09-05 16:13 ` Richard Riehle ` (3 more replies) 2004-09-05 18:28 ` Larry Kilgallen ` (2 subsequent siblings) 3 siblings, 4 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-05 4:36 UTC (permalink / raw) jayessay <nospam@foo.com> wrote in message news:<m3656vfgmf.fsf@rigel.goldenthreadtech.com>... > "Richard Riehle" <adaworks@earthlink.net> writes: > > > "jayessay" <nospam@foo.com> wrote in message > > news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... > > > "Richard Riehle" <adaworks@earthlink.net> writes: > > > > ... > > Ada and Eiffel are designed with more compile-time checking capabilities > > than Smalltalk. > > Static typing is largely overrated - even Hindley-Milner type systems > such as in Haskell or ML (which are significantly more potent than the > type systems of Eiffel or Ada). The whole thing sounds great in > theory and you can make some pretty plausible arguments for its > efficacy, but it just doesn't make much difference in practice. I've come to the same conclusion. Once you decide to test code before you write it, strong typing loses most of it's value. On the other hand, if I'm working on code without a good set of automated tests, then strong typing is a very nice thing to have. > Furthermore, all but a couple of these were caught immediately on > first testing of function in question. > No such errors ever manefested > themselves in production code. Yes, I know the typical rebuttal here > is "Yet!". In theory that's true, but the evidence at this point > suggests it is extremely unlikely. In theory and in practice, no useful programming language can eliminate all possibility of runtime errors. No matter what, you still have to test the code. > Also, logic errors (what most > people would consider significantly more negative) are far rarer. > > There turn out to be various reasons for this, but two worth > mentioning are the sort of bottom up style of programming as described > by Paul Graham (a kind of agile/extreme programming) and the ability > to move Lisp to the expressive level of the application domain. > > In any application/system of any significance these two go hand in > hand. The second is achieved by crafting a constrained narrowly > focused domain specific language _within_ Lisp, which allows the > programmer to then work at the level of the domain, _both_ > syntactically as well as semantically. This is why Lisp macros > (please don't confuse with any other kind of macro you've come across > before) are such a big deal. > > Now, admittedly, creating these is not something your typical code > monkey is going to grok. This is one of the big reasons why Lisp will > never be as "popular" as something like Java. But then your typical > code monkey isn't going to be building your core internal application > api either. Once you've built this though, even a code monkey will be > a lot more productive and produce much more clean and robust code. > > > For example, a Common Lisp programmer rarely agnonizes over such > > silliness as constructors, copy constructors, overloading assignment > > operators, friends, and all the hideous little details that > > characterize so much of C++ programming. I'm skeptical. In any language, data structures will require initialization to reach the empty state. You still have to write the code, it just has a different name. Instead of MyThing(int mobys, ...) you have (defun make-my-thing(mobys ...). Instead of a copy constructor, you have (defun clone-my-thing(thing) ...). And if you open files or lock mutexes or consume any other limited resource, you are going to have to ensure they are released by writing the equivalent of a destructor. When done well, C++ programming does not get mired in hideous little details. But like most programming, it is rarely done well. And the more popular a language, the lower the performance of the average practitioner. Lots of people learned C++ and Java because that's what the market demanded. So there is lots of horrible C++ code and Java code. People learn LISP because they love programming. Not all LISP programmers are geniuses, but almost all are well above the mean. ... > 1. Which from experience would typically be in the range of 250K-500K > lines of equivalent Ada/C++/Eiffel/etc. An order of magnitude is not > hyperbole here even though most uninitiated developers will raise > their eyebrows or roll their eyes. This I know to be true, although again it's not fair to compare the C++ code from an average programmer to the LISP code from an expert. An expert C++ programmer can reduce the line count of typical code by 60% or more. In either language, experts will refactor until a new domain-specific language appears. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 4:36 ` Kevin Cline @ 2004-09-05 16:13 ` Richard Riehle 2004-09-05 17:28 ` Jean-Marc Bourguet ` (2 subsequent siblings) 3 siblings, 0 replies; 387+ messages in thread From: Richard Riehle @ 2004-09-05 16:13 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409042036.5d4822a2@posting.google.com... > jayessay <nospam@foo.com> wrote in message news:<m3656vfgmf.fsf@rigel.goldenthreadtech.com>... > > "Richard Riehle" <adaworks@earthlink.net> writes: > > ... > > > Ada and Eiffel are designed with more compile-time checking capabilities > > > than Smalltalk. > > > > Static typing is largely overrated - even Hindley-Milner type systems > > such as in Haskell or ML (which are significantly more potent than the > > type systems of Eiffel or Ada). The whole thing sounds great in > > theory and you can make some pretty plausible arguments for its > > efficacy, but it just doesn't make much difference in practice. > > I've come to the same conclusion. Once you decide to test code before > you write it, strong typing loses most of it's value. On the other > hand, if I'm working on code without a good set of automated tests, > then strong typing is a very nice thing to have. > No one argues that testing is unimportant. However, testing is not sufficient in the creation of dependable large-scale software systems. We test for the expected, and design for the unexpected. We can test for the errors we anticipate, but must design for those we cannot anticipate. This is an essential idea in creating software with Ada. Static typing is only one aspect of design. In Ada, types have proven over and over their value when used in conjuction with the other design features of the language, including such things as the visibility rules, accessibility rules, and named association. Ada goes well beyond compile-time type checking. In fact, if it were nothing more than another language based solely on type checking, much of this criticism would be justified. Happily, it is a far more comprehensive software design language than seems evident from some of the criticism, so far. No language can protect us, at compile time, from every possible error. No tool can prevent us from every kind of mistake, whether it is a software tool or hardware tool. But some kinds of tools can reduce the number of mistakes we make. Does it not seem reasonable to use those tools when they make economic sense. The type model, the visibility rules, the named association rules, separate compilation units, the ability to truly encapsulate the structure of types while making them usable, the restrictions on pointers, the compiler checked generic instantiations, and the many other aspects of Ada that can be evaluated by the compiler simply help to improve the life of the programmer, the designer, and the quality of the final product. This capability, when combined with testing, allows us to build the kind of software our customers should expect. We certainly can use these features incorrectly. However, when used properly, Ada gives the designer a better set of options for dependable software creation than its nearest competitors. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 4:36 ` Kevin Cline 2004-09-05 16:13 ` Richard Riehle @ 2004-09-05 17:28 ` Jean-Marc Bourguet 2004-09-06 16:45 ` jayessay 2004-09-05 21:01 ` Jeffrey Carter 2004-09-06 21:12 ` jayessay 3 siblings, 1 reply; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-05 17:28 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Once you decide to test code before you write it, strong > typing loses most of it's value. Well, I've been told that the earlier you detect an error, the easier and the cheaper it was to fix it. This is corrobated by my experience. Errors detected by strong type checking are found earlier than those detected by testing. More, testing can only show that something happen. Type checking ensure that something does not happen. So with testing you'll test only the cases you have though about. Most probably the one which are corrects. So testing will catch only parts of the error that strong type checking will find and that at an higher price. That is not to say that testing should be dropped: there are problems which are not detected by type checking, but the earlier detection -- and more precise localisation -- of the problems worth the cost of strong type checking. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 17:28 ` Jean-Marc Bourguet @ 2004-09-06 16:45 ` jayessay 2004-09-06 17:15 ` Georg Bauhaus 2004-09-06 18:47 ` Jean-Marc Bourguet 0 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-06 16:45 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > kevin.cline@gmail.com (Kevin Cline) writes: > > > Once you decide to test code before you write it, strong > > typing loses most of it's value. > > Well, I've been told that the earlier you detect an error, > the easier and the cheaper it was to fix it. Absolutely. > Errors detected by strong type checking are found earlier than > those detected by testing. Not if the testing is the sort used in bottom-up dynamic incremental development. There you are often testing both the "type constraints" _and_ logic at the subexpression level up through clause and finally to function! This is way earlier and faster than any static type checking. It is also more robust as it is checking a lot more over a far greater set of code paths. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:45 ` jayessay @ 2004-09-06 17:15 ` Georg Bauhaus 2004-09-07 15:13 ` jayessay 2004-09-06 18:47 ` Jean-Marc Bourguet 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-06 17:15 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Not if the testing is the sort used in bottom-up dynamic incremental : development. There you are often testing both the "type constraints" : _and_ logic at the subexpression level up through clause and finally : to function! This is way earlier and faster than any static type : checking. It is also more robust as it is checking a lot more over a : far greater set of code paths. It isn't surprising that testing checks more than static type checking alone. I don't know, has anybody suggested that static type checking is to be used alone? When you are testing "type constraints", how is that different from a compiler testing type constraints at compile time? What do you mean by robust? If a translator sees a function call, where the function has a specific formal T parameter, and the translator can do type checking before running this piece of the program, doesn't this remove the necessity to test a number of code paths in the first place? In the following sense, if I have: (DEFUN ANY (X) ...) ; old LISP versus function any(x: T) return N; the first notation would leave two additional things that have to be tested by running the piece of program: 1 can "ANY" work with some actual parameter value that happens to be of type S (different from T) at test time? 2 provided 1, can the value returned by "ANY" be used in expression E that expects a value of type N (that is, not of type (Q or S or T or ...))? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 17:15 ` Georg Bauhaus @ 2004-09-07 15:13 ` jayessay 2004-09-07 15:57 ` jayessay 2004-09-07 15:57 ` Georg Bauhaus 0 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-07 15:13 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > > : Not if the testing is the sort used in bottom-up dynamic incremental > : development. There you are often testing both the "type constraints" > : _and_ logic at the subexpression level up through clause and finally > : to function! This is way earlier and faster than any static type > : checking. It is also more robust as it is checking a lot more over a > : far greater set of code paths. > > It isn't surprising that testing checks more than static type checking > alone. I don't know, has anybody suggested that static type checking > is to be used alone? No. But the point is with static typing you lose this sort of dynamic incremental development. See my other post on this (reply to you). > When you are testing "type constraints", how is that different from > a compiler testing type constraints at compile time? Because you don't need to set up an entire boiler plate to test one thing and then go throug a compile-link-execute-edit-again cycle. Further, you are simultaneously testing the logic. > What do you mean by robust? Both type checks and logic errors are checked simultaneously and at very fine grained levels. > If a translator sees a function call, where the function has a > specific formal T parameter, and the translator can do type checking > before running this piece of the program, doesn't this remove the > necessity to test a number of code paths in the first place? That is often insufficient because it doesn't ensure anything about whether the _content_ of a value conforming to the type is correct for the input of the function. > In the following sense, if I have: > > (DEFUN ANY (X) ...) ; old LISP > > function any(x: T) return N; -- Ada "any" seems like an odd name if you don't really want x to be _anything_. Anyway here's a couple of ways to achieve the same _typing_ constraint [1] (defun any (x) (assert x any-type "a value of type any-type") (let ((result ...)) ... (assert result N "a return value of type N") result)) (declaim (ftype (function (a-type) N) foo)) (defun any (x) ...) /Jon [1] I think you are getting confused into thinking Lisp is somehow not typed simply because it doesn't have static typing. It is actually very strongly typed - actually stronger than Ada as there is no equivalent of Unchecked_Conversion. All _values_ have a type and that cannot be changed. -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:13 ` jayessay @ 2004-09-07 15:57 ` jayessay 2004-09-07 15:57 ` Georg Bauhaus 1 sibling, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-07 15:57 UTC (permalink / raw) jayessay <nospam@foo.com> writes: brain fart... > (declaim (ftype (function (a-type) N) foo)) ^^^ should be any > (defun any (x) ...) /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:13 ` jayessay 2004-09-07 15:57 ` jayessay @ 2004-09-07 15:57 ` Georg Bauhaus 2004-09-07 18:20 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-07 15:57 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: :> What do you mean by robust? : : Both type checks and logic errors are checked simultaneously and at : very fine grained levels. And static type checking can't add, at least in many relevant cases? :> If a translator sees a function call, where the function has a :> specific formal T parameter, and the translator can do type checking :> before running this piece of the program, doesn't this remove the :> necessity to test a number of code paths in the first place? : : That is often insufficient because it doesn't ensure anything about : whether the _content_ of a value conforming to the type is correct for : the input of the function. Sure it is insufficient. But it adds value by removing the need to test what the compiler has already found out. How about typos? Here is a fake: (defun next (n) (1 + n)) (defun hext (n) (1 + (mod n 16))) ; ... (defun advance (n) (hext n)) ; a slip of the finger (advance 3) 4 Fine. (advance 16) 1 Oops. Types could help I'd say. :> In the following sense, if I have: :> :> (DEFUN ANY (X) ...) ; old LISP :> :> function any(x: T) return N; -- Ada : : "any" seems like an odd name if you don't really want x to be : _anything_. OK, I have chosen the name to be irrelevant, a better name would have been SOME-FUNC. : Anyway here's a couple of ways to achieve the same : _typing_ constraint [1] I know that Lisp values are of a type. But I simply don't see how declaring the type of a function (via arguments), say, can't be a win. What will the ML programmers say? : (assert x any-type "a value of type any-type") : (declaim (ftype (function (a-type) N) foo)) : (defun any (x) ...) Does this hinder incremental testing? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:57 ` Georg Bauhaus @ 2004-09-07 18:20 ` jayessay 2004-09-08 10:40 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-07 18:20 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > > > :> What do you mean by robust? > : > : Both type checks and logic errors are checked simultaneously and at > : very fine grained levels. > > And static type checking can't add, at least in many relevant > cases? In some scenarios it can indeed add a certain level of confidence. I think most dynamic type folks (certainly most everyone over on c.l.l) would look at it something like this: "Static typing can indeed provide some value. Dynamic typing provides an enormous level of value. If I could have static typing without it destroying the value provided by dynamic typing, I'd take it. But the two are fundamentally at odds in what they _need_ in order to _provide_ what they offer. > :> If a translator sees a function call, where the function has a > :> specific formal T parameter, and the translator can do type checking > :> before running this piece of the program, doesn't this remove the > :> necessity to test a number of code paths in the first place? > : > : That is often insufficient because it doesn't ensure anything about > : whether the _content_ of a value conforming to the type is correct for > : the input of the function. > > Sure it is insufficient. But it adds value by removing the need to > test what the compiler has already found out. How about typos? True. But since this is determined anyway as part of incremental development it doesn't actually save anything in practice. Typos are a good example. > Here is a fake: > > (defun next (n) (1 + n)) > (defun hext (n) (1 + (mod n 16))) Let's see this in practice: (defun next (n) (1+ n)) ==> next ;; let's try it (dotimes (i 10) (let ((n (random 100000))) (format t "~%(next ~a) --> ~a" n (next n)))) ==> (next 97872) --> 97873 (next 73063) --> 73064 (next 74426) --> 74427 (next 84763) --> 84764 (next 45797) --> 45798 (next 82856) --> 82857 (next 35267) --> 35268 (next 732) --> 733 (next 90138) --> 90139 (next 73850) --> 73851 (defun hext (n) (1+ (mod n 16))) ==> hext ;; prove it: (dotimes (n 17) (format t "~%(hext ~a) --> ~a" n (hext n))) ==> (hext 0) --> 1 (hext 1) --> 2 (hext 2) --> 3 (hext 3) --> 4 (hext 4) --> 5 (hext 5) --> 6 (hext 6) --> 7 (hext 7) --> 8 (hext 8) --> 9 (hext 9) --> 10 (hext 10) --> 11 (hext 11) --> 12 (hext 12) --> 13 (hext 13) --> 14 (hext 14) --> 15 (hext 15) --> 16 (hext 16) --> 1 Hey, hext is broken ;; fix it (defun hext (n) (mod (1+ n) 16)) ==> hext ;; prove it: (dotimes (n 17) (format t "~%(hext ~a) --> ~a" n (hext n))) ==> (hext 0) --> 1 (hext 1) --> 2 (hext 2) --> 3 (hext 3) --> 4 (hext 4) --> 5 (hext 5) --> 6 (hext 6) --> 7 (hext 7) --> 8 (hext 8) --> 9 (hext 9) --> 10 (hext 10) --> 11 (hext 11) --> 12 (hext 12) --> 13 (hext 13) --> 14 (hext 14) --> 15 (hext 15) --> 0 (hext 16) --> 1 That's better. (defun advance (n) (hext n)) ; a slip of the finger ==> advance ;; try it (dotimes (n 17) (format t "~%(advance ~a) --> ~a" n (advance n))) ==> (advance 0) --> 1 (advance 1) --> 2 (advance 2) --> 3 (advance 3) --> 4 (advance 4) --> 5 (advance 5) --> 6 (advance 6) --> 7 (advance 7) --> 8 (advance 8) --> 9 (advance 9) --> 10 (advance 10) --> 11 (advance 11) --> 12 (advance 12) --> 13 (advance 13) --> 14 (advance 14) --> 15 (advance 15) --> 0 (advance 16) --> 1 Hey, this is broken. Looks like hext was used when I wanted next! Or ;;; Pre condition: N a number ;;; Post condition: result = (1+ N) ;;; (defun advance (n) (check-type n number "a number") (let ((result (hext n))) (assert (= result (1+ n)) nil (format nil "ADVANCE: Post condition (= RESULT (1+ N)) failed; ~ [~A /= ~A]" result n)) result)) > Oops. Types could help I'd say. What you are saying is, range types (as in Ada) could have caught this. True, but they would not have caught it quicker (or even as quick) as this did. Also, they wouldn't have caught the error in hext until you ran it anyway. > I know that Lisp values are of a type. But I simply don't see how > declaring the type of a function (via arguments), say, can't be a win. > What will the ML programmers say? They will (more or less) agree with you. Of course they will go further and claim that things like Ada/Eiffel/C++/Java/etc have lame type systems and that what you buy with a true formal type system (like one based on say, Hindley-Milner) makes dynamic arguments less potent/interesting/valuable/whatever. > : (assert x any-type "a value of type any-type") > > : (declaim (ftype (function (a-type) N) foo)) > : (defun any (x) ...) > > Does this hinder incremental testing? No. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 18:20 ` jayessay @ 2004-09-08 10:40 ` Georg Bauhaus 2004-09-08 19:46 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-08 10:40 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: :> Sure it is insufficient. But it adds value by removing the need to :> test what the compiler has already found out. How about typos? : : True. But since this is determined anyway as part of incremental : development it doesn't actually save anything in practice. Typos are : a good example. : : :> Here is a fake: :> :> (defun next (n) (1 + n)) :> (defun hext (n) (1 + (mod n 16))) : : Let's see this in practice: [lengthy testing snipped] Do you see what I mean? ;-) ;-) ;-) Wouldn't have happend with proper typing and static type checks, see below. : What you are saying is, range types (as in Ada) could have caught : this. True, but they would not have caught it quicker (or even as : quick) as this did. No, I'm saying that this error can occur in an executing piece of program if and only if the compiler allows me to mix operations of an integer type and operations a modular type without notice. Things like this don't happen if you get the types right at compiletime. Similarly, physical units can be checked at compile time using C++ templates. Is there a set of Lisp macros that guarantees unit safe computations before a program runs? : Also, they wouldn't have caught the error in hext : until you ran it anyway. Not true as explained above. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 10:40 ` Georg Bauhaus @ 2004-09-08 19:46 ` jayessay 2004-09-09 1:47 ` Georg Bauhaus 2004-09-09 5:38 ` Chad R. Meiners 0 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-08 19:46 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > > :> Sure it is insufficient. But it adds value by removing the need to > :> test what the compiler has already found out. How about typos? > : > : True. But since this is determined anyway as part of incremental > : development it doesn't actually save anything in practice. Typos are > : a good example. > : > : > :> Here is a fake: > :> > :> (defun next (n) (1 + n)) > :> (defun hext (n) (1 + (mod n 16))) > : > : Let's see this in practice: > > [lengthy testing snipped] > > Do you see what I mean? ;-) ;-) ;-) Wouldn't have happend with > proper typing and static type checks, see below. I never said types here would not have caught the "advance" error. I simply state that the dynamic version was as efficacious at catching that error and also caught the logic error in hext at the same time. > : What you are saying is, range types (as in Ada) could have caught > : this. True, but they would not have caught it quicker (or even as > : quick) as this did. > > No, I'm saying that this error can occur in an executing piece > of program if and only if the compiler allows me to mix > operations of an integer type and operations a modular type > without notice. OK, that is a better way than simple ranges. But it doesn't change the point, see below. > Things like this don't happen if you get the types right at > compiletime. Yes, and they don't happen at runtime if pre and post are checked during incremental development. If you don't do this, then you will likely have problems - just like if you don't get the types right in static languages. > Similarly, physical units can be checked at compile time using C++ > templates. Is there a set of Lisp macros that guarantees unit safe > computations before a program runs? Yes this has been done. From what I've seen it is a very nice system. Where it can't make the determination at compile time it generates code for the checks and conversions at runtime. > : Also, they wouldn't have caught the error in hext > : until you ran it anyway. > > Not true as explained above. Your explanation above does not cover the logic error. I don't see right off how modular types catch that. with Text_Io; use Text_Io; procedure Foo is type Hex_Num is mod 16; function Hext (N : Integer) return Hex_Num is begin -- == (1+ (n mod 16)), which is the logic error. return Hex_Num(1 + (N mod Hex_Num'Modulus)); end Hext; begin for I in 0..20 loop Put_Line("Answer is: " & Hex_Num'Image(Hext(i))); end loop; end; $ gnatmake hext.adb ==> gcc -c hext.adb hext.adb:3:11: warning: file name does not match unit name, should be "foo.adb" gnatbind -x hext.ali gnatlink hext.ali [Yeah, I know the file name is bogus, but there are no errors or warnings about the error, not surprising since you can't know there is a bomb here at compile time] $ ./hext Answer is: 1 Answer is: 2 Answer is: 3 Answer is: 4 Answer is: 5 Answer is: 6 Answer is: 7 Answer is: 8 Answer is: 9 Answer is: 10 Answer is: 11 Answer is: 12 Answer is: 13 Answer is: 14 Answer is: 15 raised CONSTRAINT_ERROR : hext.adb:9 $ Same as the Lisp: (deftype hex-num () `(mod 16)) (defun hext (n) (check-type n integer) (let ((result (1+ (mod n 16)))) (check-type result hex-num) result)) ==> hext (dotimes (n 20) (format t "~%(hext ~a) --> ~a" n (hext n))) (hext 0) --> 1 (hext 1) --> 2 (hext 2) --> 3 (hext 3) --> 4 (hext 4) --> 5 (hext 5) --> 6 (hext 6) --> 7 (hext 7) --> 8 (hext 8) --> 9 (hext 9) --> 10 (hext 10) --> 11 (hext 11) --> 12 (hext 12) --> 13 (hext 13) --> 14 (hext 14) --> 15 Error: the value of RESULT is 16, which is not of type HEX-NUM. [condition type: TYPE-ERROR] Restart actions (select using :continue): 0: supply a new value for RESULT. 1: Return to Top Level (an "abort" restart). 2: Abort entirely from this process. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:46 ` jayessay @ 2004-09-09 1:47 ` Georg Bauhaus 2004-09-10 1:01 ` jayessay 2004-09-09 5:38 ` Chad R. Meiners 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-09 1:47 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Yes, and they don't happen at runtime if pre and post are checked : during incremental development. If you don't do this, then you will : likely have problems - just like if you don't get the types right in : static languages. Is it really much more time efficient, if pre and post checking is done by an incrementing human? If so, how much? : Your explanation above does not cover the logic error. I don't see : right off how modular types catch that. See below, there isn't a logic error, only a typo. : with Text_Io; use Text_Io; : : procedure Foo is : : type Hex_Num is mod 16; : : function Hext (N : Integer) return Hex_Num is : begin : -- == (1+ (n mod 16)), which is the logic error. ^^^^^^^^^^^^ not really, see below : return Hex_Num(1 + (N mod Hex_Num'Modulus)); : end Hext; : : begin : for I in 0..20 loop : Put_Line("Answer is: " & Hex_Num'Image(Hext(i))); Put_Line("Answer is: " & Integer'Image(Hext(i))); : end loop; : end; In the Lisp example there was a "typo context". "next" should have been where "hext" was actually typed in the Lisp example. Therefore, an integer number was actually wanted ("next"), not a hex number ("hext"). So there must be an Integer'image reflecting the logic/expectation ("next") not a Hex_Num'image (typo "hext"). The error is caught by the compiler. 15. Put_Line("Answer is: " & Integer'Image(Hext(i))); | >>> expected type "Standard.Integer" >>> found type "Hex_Num" defined at line 4 -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:47 ` Georg Bauhaus @ 2004-09-10 1:01 ` jayessay 2004-09-10 9:28 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-10 1:01 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > > : Yes, and they don't happen at runtime if pre and post are checked > : during incremental development. If you don't do this, then you will > : likely have problems - just like if you don't get the types right in > : static languages. > > Is it really much more time efficient, if pre and post checking is done > by an incrementing human? If so, how much? Generally, yes. For two general reasons: 1. you are always sure of the logic as well as the type consistency 2. You don't have global "system integration" issues as each incremental step subsumes an integration aspect. > : Your explanation above does not cover the logic error. I don't see > : right off how modular types catch that. > > See below, there isn't a logic error, only a typo. No, I'm not talking about the typo in the advance function. I'm talking about the logic error in the Hext function itself! > > : with Text_Io; use Text_Io; > : > : procedure Foo is > : > : type Hex_Num is mod 16; > : > : function Hext (N : Integer) return Hex_Num is > : begin > : -- == (1+ (n mod 16)), which is the logic error. > ^^^^^^^^^^^^ not really, see below > : return Hex_Num(1 + (N mod Hex_Num'Modulus)); > : end Hext; > : > : begin > : for I in 0..20 loop > : Put_Line("Answer is: " & Hex_Num'Image(Hext(i))); > Put_Line("Answer is: " & Integer'Image(Hext(i))); > : end loop; > : end; > > In the Lisp example there was a "typo context". "next" should have > been where "hext" was actually typed in the Lisp example That's not the logic error. The logic error is that Hext is broken due to the incorrect expression at the line noted above. > Therefore, an integer number was actually wanted ("next"), not > a hex number ("hext"). > So there must be an Integer'image reflecting the logic/expectation > ("next") not a Hex_Num'image (typo "hext"). > The error is caught by the compiler. > > 15. Put_Line("Answer is: " & Integer'Image(Hext(i))); > | > >>> expected type "Standard.Integer" > >>> found type "Hex_Num" defined at line 4 No. This would be a different (brain fart) type of error. The logic error is in Hext - it does not correctly compute the residue class defined by Hex_Num!!! This is shown by the Ada RT raising constraint error - even though the compiler didn't (indeed _couldn't_ complain about the definition!!!). /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 1:01 ` jayessay @ 2004-09-10 9:28 ` Georg Bauhaus 2004-09-12 15:59 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-10 9:28 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> jayessay <nospam@foo.com> wrote: :> :> : Yes, and they don't happen at runtime if pre and post are checked :> : during incremental development. If you don't do this, then you will :> : likely have problems - just like if you don't get the types right in :> : static languages. :> :> Is it really much more time efficient, if pre and post checking is done :> by an incrementing human? If so, how much? : : Generally, yes. For two general reasons: 1. you are always sure of : the logic as well as the type consistency Yes, within the limiting conditions of parameter values of a suitable type. : 2. You don't have global : "system integration" issues as each incremental step subsumes an : integration aspect. OK. Similarly. :> : Your explanation above does not cover the logic error. I don't see :> : right off how modular types catch that. :> :> See below, there isn't a logic error, only a typo. : : No, I'm not talking about the typo in the advance function. I'm : talking about the logic error in the Hext function itself! That's your interpretation of the "hext" function as given in the Lisp example. :> In the Lisp example there was a "typo context". "next" should have :> been where "hext" was actually typed in the Lisp example : : That's not the logic error. The logic error is that Hext is broken : due to the incorrect expression at the line noted above. It is broken WRT your interpretation of its undocumented purpose. It is not a broken Lisp function at all and might reflect a specification precisely. It could as well have been (defun hext (n) (+ offset (mod n 16))) (What has made you think otherwise? :-) or even ;; hext: string -> string (defun hext (n) (extract-h-from-oldstyle-german-th-word n)) ;; make Thor from Tor etc. With the same typo leading to the discovery of the error only a run time or test time. :> Therefore, an integer number was actually wanted ("next"), not :> a hex number ("hext"). (In fact at the point of definition of "advance", the programmer will likely have been aware of the "next" function, but not of a "hext" function. The test might have revealed the existence of the "hext" function in the first place. (I do like surprises sometimes, as they also make you see things that you might have missed before :-) Now consider a situation where there are no two similarly named functions in the environment, with similar results, both producing values of the same Lisp number type, and both consuming arguments of the same number types. I think that a static type system like Ada's, if used, will likely catch a logic error at compile time, that is when by mistake one function is used where the other should have been used. This is because a value of a type being in 1 .. 10 will not be compatible with a value of another type's 1 .. 10. The program will not have to be run to find out, at least there is a chance for this to to be found out prior to surprises at run time, even if not every case can be handled by compile time type checking. ; old Rome (defun 1-to-10 (n) (random-even 1 10)) ; ... (defun 1-out-of-10 (n) (test-status parts-of-town n)) (set-on-fire (1-to-10 3)) ; should have been 1-out-of-10 -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 9:28 ` Georg Bauhaus @ 2004-09-12 15:59 ` jayessay 2004-09-13 13:19 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-12 15:59 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Now consider a situation where there are no two similarly named > functions in the environment, with similar results, both producing > values of the same Lisp number type, and both consuming arguments of > the same number types. > > I think that a static type system like Ada's, if used, will > likely catch a logic error at compile time, that is when by mistake > one function is used where the other should have been used. This is at best unlikely as has been demonstrated. Types, type systems, and type consistency offer little to no help with this. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 15:59 ` jayessay @ 2004-09-13 13:19 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 13:19 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> Now consider a situation where there are no two similarly named :> functions in the environment, with similar results, both producing :> values of the same Lisp number type, and both consuming arguments of :> the same number types. :> :> I think that a static type system like Ada's, if used, will :> likely catch a logic error at compile time, that is when by mistake :> one function is used where the other should have been used. : : This is at best unlikely as has been demonstrated. Where? Our arguments have been revolving around an undocumented function, whose purpose has _not_ been the one that has helped you in finding a (wrong) supposed logic error. There was no logic error. The function has had a different purpose than the one you have attributed. This is worse, even if it seems to support you argument. : Types, type : systems, and type consistency offer little to no help with this. Once more, could you be more specific with "little to no" and perhaps apply this to the expression (+ offset (mod n 16))? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:46 ` jayessay 2004-09-09 1:47 ` Georg Bauhaus @ 2004-09-09 5:38 ` Chad R. Meiners 2004-09-10 1:04 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Chad R. Meiners @ 2004-09-09 5:38 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3acw0bl1u.fsf@rigel.goldenthreadtech.com... > with Text_Io; use Text_Io; > > procedure Foo is > > type Hex_Num is mod 16; > > function Hext (N : Integer) return Hex_Num is > begin > -- == (1+ (n mod 16)), which is the logic error. > return Hex_Num(1 + (N mod Hex_Num'Modulus)); > end Hext; However, most Ada programmers would have written it like procedure Foo is type Hex_Num is mod 16; function To_Hex_Num(Item : Integer) return Hex_Num is begin -- This function provides the correct conversion -- for use by all other subroutines. return Hex_Num(Item mod Hex_Num'Modulus); end To_Hex_Num; function Hext (N : Integer) return Hex_Num is begin return 1 + To_Hex_Num(N); -- Note To_Hex_Num(1+N) also works end Hext; ... and avoided the problem altogether. -CRM ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 5:38 ` Chad R. Meiners @ 2004-09-10 1:04 ` jayessay 2004-09-10 21:51 ` Chad R. Meiners 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-10 1:04 UTC (permalink / raw) chad.rmeiners@gmail.com (Chad R. Meiners) writes: > "jayessay" <nospam@foo.com> wrote in message > news:m3acw0bl1u.fsf@rigel.goldenthreadtech.com... > > with Text_Io; use Text_Io; > > > > procedure Foo is > > > > type Hex_Num is mod 16; > > > > function Hext (N : Integer) return Hex_Num is > > begin > > -- == (1+ (n mod 16)), which is the logic error. > > return Hex_Num(1 + (N mod Hex_Num'Modulus)); > > end Hext; > > However, most Ada programmers would have written it like > > procedure Foo is > type Hex_Num is mod 16; > > function To_Hex_Num(Item : Integer) return Hex_Num is > begin -- This function provides the correct conversion > -- for use by all other subroutines. > return Hex_Num(Item mod Hex_Num'Modulus); > end To_Hex_Num; > > function Hext (N : Integer) return Hex_Num is > begin > return 1 + To_Hex_Num(N); -- Note To_Hex_Num(1+N) also works > end Hext; > > ... > > and avoided the problem altogether. All you are saying is that _the programmer_ would have caught the logic error! In this ridiculously simple case, sure. The Lisp programmer would never have brain farted like this in this simple case either!! The point is, the programmer in this case, Georg Bauhaus, _did_ make the error and did not avoid the problem! /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 1:04 ` jayessay @ 2004-09-10 21:51 ` Chad R. Meiners 0 siblings, 0 replies; 387+ messages in thread From: Chad R. Meiners @ 2004-09-10 21:51 UTC (permalink / raw) jayessay <nospam@foo.com> wrote in message news:<m3fz5r9bnv.fsf@rigel.goldenthreadtech.com>... > > All you are saying is that _the programmer_ would have caught the > logic error! No that wasn't what I was saying. I was pointing out how Ada's type system helps programmers to think in a way that avoids these type of logic errors altogether. By taking advantage of the type system, the programmer is less likely to write the code that you posted and more likely to write the code that I posted in the first place. -CRM ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:45 ` jayessay 2004-09-06 17:15 ` Georg Bauhaus @ 2004-09-06 18:47 ` Jean-Marc Bourguet 2004-09-07 15:22 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-06 18:47 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > kevin.cline@gmail.com (Kevin Cline) writes: > > > > > Once you decide to test code before you write it, strong > > > typing loses most of it's value. > > > > Well, I've been told that the earlier you detect an error, > > the easier and the cheaper it was to fix it. > > Absolutely. > > > > Errors detected by strong type checking are found earlier than > > those detected by testing. > > Not if the testing is the sort used in bottom-up dynamic incremental > development. That's perhaps one difference between us: I do mainly maintenance and development of small features in an existing multi-million lines program whose development started more than 15 years ago with complex interactions between the components of the program (some inherent to the problem, some due to lack of forsightness 10 years ago, some due to bad practice...) It has a lisp dialect as extension language and one of the maintenance problem is that some part has been written in it with "bottom-up dynamic incremental development" testing only the cases the developper was thinking about and fail sometimes horribly when faced to the customer interaction. > There you are often testing both the "type constraints" > _and_ logic at the subexpression level up through clause > and finally to function! This is way earlier and faster > than any static type checking. Not in my experience. Our tests takes days to run. And when one of them find a bug that static typing would have found, I'm not happy at all. Because you see, some of the functions are used by other components in way I'm sometimes surprised. Type information is not only used by the compiler, it is also used as documentation by the programmer. And it is the most usefull kind of documentation: the one which is in sync with the code. > It is also more robust as it is checking a lot more over a > far greater set of code paths. I'm sorry, tests check *other things* than type constaints, *not* more things. And then anew: Tests can only proove that something happen, never that it doesn't. Type checking ensure that some constraints are never violated. That's outside the scoop of testing. A+ -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 18:47 ` Jean-Marc Bourguet @ 2004-09-07 15:22 ` jayessay 2004-09-07 15:37 ` Jean-Marc Bourguet ` (3 more replies) 0 siblings, 4 replies; 387+ messages in thread From: jayessay @ 2004-09-07 15:22 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > jayessay <nospam@foo.com> writes: > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > kevin.cline@gmail.com (Kevin Cline) writes: > > > > > > > Once you decide to test code before you write it, strong > > > > typing loses most of it's value. > > > > > > Well, I've been told that the earlier you detect an error, > > > the easier and the cheaper it was to fix it. > > > > Absolutely. > > > > > > > Errors detected by strong type checking are found earlier than > > > those detected by testing. > > > > Not if the testing is the sort used in bottom-up dynamic incremental > > development. > > That's perhaps one difference between us: I do mainly > maintenance and development of small features in an existing > multi-million lines program whose development started more > than 15 years ago with complex interactions between the > components of the program (some inherent to the problem, > some due to lack of forsightness 10 years ago, some due to > bad practice...) > > It has a lisp dialect as extension language and one of the > maintenance problem is that some part has been written in it > with "bottom-up dynamic incremental development" testing > only the cases the developper was thinking about and fail > sometimes horribly when faced to the customer interaction. The problem here is that this application has tried to hack up some lame version of half of Lisp, i.e., it is an example of Greenspun's tenth. It has nothing to do with the issue at hand. > I'm sorry, tests check *other things* than type constaints, > *not* more things. Not the sort I'm talking about using the techniques described. > Tests can only proove that something happen, never that it doesn't. Proving things above the fairly simple level in software falls victim to the halting problem. The specifications (even very good ones) are typically not rigorous enough to _prove_ any conformance either. There are, of course, exceptions. I'm not tring to convince anyone to use dynamic typing and languages here. I'm just trying to ensure that lurkers and others here are getting some goofy incorrect view of what they are and how they work. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:22 ` jayessay @ 2004-09-07 15:37 ` Jean-Marc Bourguet 2004-09-07 17:01 ` jayessay 2004-09-07 15:58 ` jayessay ` (2 subsequent siblings) 3 siblings, 1 reply; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-07 15:37 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: [...] > The problem here is that this application has tried to hack up some > lame version of half of Lisp, The extension language I wrote about was a scheme with some OO extensions and then others. Not a full CL but not something I'd call a "lame version of half of Lisp." [...] > > I'm sorry, tests check *other things* than type constaints, *not* > > more things. > > Not the sort I'm talking about using the techniques described. > > > > Tests can only proove that something happen, never that it doesn't. > > Proving things above the fairly simple level in software falls victim > to the halting problem. Do you really mean what you wrote. If so, I'd suggest you to look a little more to formal proof systems. That's not because the full problem can not be solved that no usefull sub-problem can. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:37 ` Jean-Marc Bourguet @ 2004-09-07 17:01 ` jayessay 2004-09-07 17:56 ` Jean-Marc Bourguet 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-07 17:01 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > jayessay <nospam@foo.com> writes: > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > [...] > > The problem here is that this application has tried to hack up some > > lame version of half of Lisp, > > The extension language I wrote about was a scheme with some OO > extensions and then others. Not a full CL but not something I'd call > a "lame version of half of Lisp." I can't determine this from the above. > > Proving things above the fairly simple level in software falls victim > > to the halting problem. > > Do you really mean what you wrote. If so, I'd suggest you to look a > little more to formal proof systems. That's not because the full > problem can not be solved that no usefull sub-problem can. Never said that nothing can be proved. Nor that nothing useful can be. FWIW my fomal background is mathematical logic and foundations. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 17:01 ` jayessay @ 2004-09-07 17:56 ` Jean-Marc Bourguet 2004-09-07 18:29 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-07 17:56 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > jayessay <nospam@foo.com> writes: > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > [...] > > > The problem here is that this application has tried to hack up some > > > lame version of half of Lisp, > > > > The extension language I wrote about was a scheme with > > some OO extensions and then others. Not a full CL but > > not something I'd call a "lame version of half of Lisp." > > I can't determine this from the above. I know that info was not available without doing some hunt and inference work. But why did you assume that it was lame and dismissed my points as not related to the issue at hand? Do you still think my points are not related to the issue at hand? Why? > > > Proving things above the fairly simple level in > > > software falls victim to the halting problem. > > > > Do you really mean what you wrote. If so, I'd suggest > > you to look a little more to formal proof systems. > > That's not because the full problem can not be solved > > that no usefull sub-problem can. > > Never said that nothing can be proved. Nor that nothing > useful can be. Reading the quote above, I understood that nothing not fairly simple can be proved. That's not my experience. Some quite complex invariants can be proved true with static type checking. More complex one can be proved by more powerfull static checker (some of which are able to do type inference BTW). Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 17:56 ` Jean-Marc Bourguet @ 2004-09-07 18:29 ` jayessay 2004-09-07 19:03 ` Jean-Marc Bourguet 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-07 18:29 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > jayessay <nospam@foo.com> writes: > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > jayessay <nospam@foo.com> writes: > > > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > [...] > > > > The problem here is that this application has tried to hack up some > > > > lame version of half of Lisp, > > > > > > The extension language I wrote about was a scheme with > > > some OO extensions and then others. Not a full CL but > > > not something I'd call a "lame version of half of Lisp." > > > > I can't determine this from the above. > > I know that info was not available without doing some hunt > and inference work. But why did you assume that it was lame > and dismissed my points as not related to the issue at hand? > > Do you still think my points are not related to the issue at > hand? Why? The information still suggests that this is indeed a hack on of some subset of a Lisp into the application. What is not clear is whether this was hacked up by the developers of the application or whether they found something (in the public domain or elsewhere) which was some partial hack up which they then included. The former is a classic Greenspuns's tenth, the latter is a variant. > > > > Proving things above the fairly simple level in > > > > software falls victim to the halting problem. > > > > > > Do you really mean what you wrote. If so, I'd suggest > > > you to look a little more to formal proof systems. > > > That's not because the full problem can not be solved > > > that no usefull sub-problem can. > > > > Never said that nothing can be proved. Nor that nothing > > useful can be. > > Reading the quote above, I understood that nothing not > fairly simple can be proved. That's not my experience. > Some quite complex invariants can be proved true with static > type checking. More complex one can be proved by more > powerfull static checker (some of which are able to do type > inference BTW). Yes, formal static typists (in the mold of Hindley and Milner and the type system they independently discovered and which is basically at the heart of any current implementation of a formal type system) can indeed prove some useful even interesting things. What they cannot prove (except in "fairly simple cases") is anything like program correctness. This is largely due to the fact that "correctness" here is a vague concept. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 18:29 ` jayessay @ 2004-09-07 19:03 ` Jean-Marc Bourguet 2004-09-07 21:12 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-07 19:03 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > jayessay <nospam@foo.com> writes: > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > > > jayessay <nospam@foo.com> writes: > > > > > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > [...] > > > > > The problem here is that this application has tried to hack up some > > > > > lame version of half of Lisp, > > > > > > > > The extension language I wrote about was a scheme with > > > > some OO extensions and then others. Not a full CL but > > > > not something I'd call a "lame version of half of Lisp." > > > > > > I can't determine this from the above. > > > > I know that info was not available without doing some hunt > > and inference work. But why did you assume that it was lame > > and dismissed my points as not related to the issue at hand? > > > > Do you still think my points are not related to the issue at > > hand? Why? > > The information still suggests that this is indeed a hack > on of some subset of a Lisp into the application. What is > not clear is whether this was hacked up by the developers > of the application or whether they found something (in the > public domain or elsewhere) which was some partial hack up > which they then included. The former is a classic > Greenspuns's tenth, the latter is a variant. Do you think emacs is a case of case of Greenspuns's tenth? The program I'm speaking about is very similar to emacs in architecture. But the problems I was speaking about could also occur in any program in CL of comparable size and complexity. Modify some middle or low level function and break one of its user which didn't respect one of its pre-condition in a way which was harmless with the previous implementation. Where is the problem? In the new code? It respect the documented interface. And testing can only show the problem in big, slow integration tests. In the client code? Well no testing could show the problem when it was written. > > > > > Proving things above the fairly simple level in > > > > > software falls victim to the halting problem. > > > > > > > > Do you really mean what you wrote. If so, I'd suggest > > > > you to look a little more to formal proof systems. > > > > That's not because the full problem can not be solved > > > > that no usefull sub-problem can. > > > > > > Never said that nothing can be proved. Nor that nothing > > > useful can be. > > > > Reading the quote above, I understood that nothing not > > fairly simple can be proved. That's not my experience. > > Some quite complex invariants can be proved true with static > > type checking. More complex one can be proved by more > > powerfull static checker (some of which are able to do type > > inference BTW). > > Yes, formal static typists (in the mold of Hindley and > Milner and the type system they independently discovered > and which is basically at the heart of any current > implementation of a formal type system) can indeed prove > some useful even interesting things. What they cannot > prove (except in "fairly simple cases") is anything like > program correctness. This is largely due to the fact that > "correctness" here is a vague concept. Agreed, program correctness is too vague. You can try to find equivalence with a formal description, but then you have to proove that that description is correct. At time it can be more conveniant but currently it looks to me like more a niche thing. Most of the bugs I've to track are due to breaking invariants. Especially thoose stated no where invariant or with a formulation no more in sync with the code. Those formal systems can proove invariants and using them to do so would be usefull. But I know of no mainstream system with that available. You can use type system to state and verify invariants. And that's something available now. And it is usefull. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 19:03 ` Jean-Marc Bourguet @ 2004-09-07 21:12 ` jayessay 2004-09-08 8:12 ` Jean-Marc Bourguet 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-07 21:12 UTC (permalink / raw) Jean-Marc Bourguet <jm@bourguet.org> writes: > jayessay <nospam@foo.com> writes: > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > jayessay <nospam@foo.com> writes: > > > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > > > > > jayessay <nospam@foo.com> writes: > > > > > > > > > > > Jean-Marc Bourguet <jm@bourguet.org> writes: > > > > > [...] > > > > > > The problem here is that this application has tried to hack up some > > > > > > lame version of half of Lisp, > > > > > > > > > > The extension language I wrote about was a scheme with > > > > > some OO extensions and then others. Not a full CL but > > > > > not something I'd call a "lame version of half of Lisp." > > > > > > > > I can't determine this from the above. > > > > > > I know that info was not available without doing some hunt > > > and inference work. But why did you assume that it was lame > > > and dismissed my points as not related to the issue at hand? > > > > > > Do you still think my points are not related to the issue at > > > hand? Why? > > > > The information still suggests that this is indeed a hack > > on of some subset of a Lisp into the application. What is > > not clear is whether this was hacked up by the developers > > of the application or whether they found something (in the > > public domain or elsewhere) which was some partial hack up > > which they then included. The former is a classic > > Greenspuns's tenth, the latter is a variant. > > Do you think emacs is a case of case of Greenspuns's tenth? > The program I'm speaking about is very similar to emacs in > architecture. Presumably you mean Elisp. No it is not, it is just a well known _broken_ Lisp. > But the problems I was speaking about could also occur in > any program in CL of comparable size and complexity. Modify > some middle or low level function and break one of its user > which didn't respect one of its pre-condition in a way which > was harmless with the previous implementation. You are making a change to the preconditions so that the new ones are no longer a subclass of the former. Therefore all callers will need to be checked. Note, the preconditions (the new or the original) may not even be definable in terms of any type system. > Where is the problem? In the new code? It respect the > documented interface. And testing can only show the problem > in big, slow integration tests. In the client code? Well > no testing could show the problem when it was written. Or big extremely slow compiles which may not catch this either. This sort of problem is beyond language issues (see Ariane 5...) > > Yes, formal static typists (in the mold of Hindley and > > Milner and the type system they independently discovered > > and which is basically at the heart of any current > > implementation of a formal type system) can indeed prove > > some useful even interesting things. What they cannot > > prove (except in "fairly simple cases") is anything like > > program correctness. This is largely due to the fact that > > "correctness" here is a vague concept. > > Agreed, program correctness is too vague. You can try to > find equivalence with a formal description, but then you > have to proove that that description is correct. Exactly - and off you go down the rabbit hole. > At time it can be more conveniant but currently it looks to me like > more a niche thing. I agree. > Most of the bugs I've to track are due to breaking invariants. > Especially thoose stated no where invariant or with a formulation no > more in sync with the code. > > Those formal systems can proove invariants and using them to do so > would be usefull. But I know of no mainstream system with that > available. I think this is largely due to the fact that these things pretty much require 1) no side effects 2) no procedural descriptions. The real world (tm) OTOH, is largely made up of things that have both of these... > You can use type system to state and verify invariants. And that's > something available now. And it is usefull. No one said it wasn't. I merely claim that dynamic system can do this and more. Obviously you don't believe me. That's OK. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 21:12 ` jayessay @ 2004-09-08 8:12 ` Jean-Marc Bourguet 0 siblings, 0 replies; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-08 8:12 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > Jean-Marc Bourguet <jm@bourguet.org> writes: > > But the problems I was speaking about could also occur in > > any program in CL of comparable size and complexity. Modify > > some middle or low level function and break one of its user > > which didn't respect one of its pre-condition in a way which > > was harmless with the previous implementation. > > You are making a change to the preconditions so that the new ones > are no longer a subclass of the former. Therefore all callers will > need to be checked. The pre-conditions where documented and I simply started to make use of one of them. That's the whole difference between coding to an interface and coding to an implementation. Testing doesn't help in the former case. > Note, the preconditions (the new or the original) may not even be > definable in terms of any type system. In the case I was thinking about, they where. [...] > > You can use type system to state and verify invariants. And > > that's something available now. And it is usefull. > > No one said it wasn't. I merely claim that dynamic system can do > this and more. Obviously you don't believe me. That's OK. Testing can show that the problem happen, it can show that the problem doesn't happen in the tested cases, it can't show that the problem never happen. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:22 ` jayessay 2004-09-07 15:37 ` Jean-Marc Bourguet @ 2004-09-07 15:58 ` jayessay 2004-09-07 22:34 ` Björn Persson 2004-09-08 23:28 ` Randy Brukardt 3 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-07 15:58 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > I'm not tring to convince anyone to use dynamic typing and languages > here. I'm just trying to ensure that lurkers and others here are NOT > getting some goofy incorrect view of what they are and how they work. More brain farts... /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:22 ` jayessay 2004-09-07 15:37 ` Jean-Marc Bourguet 2004-09-07 15:58 ` jayessay @ 2004-09-07 22:34 ` Björn Persson 2004-09-08 16:28 ` jayessay 2004-09-08 23:28 ` Randy Brukardt 3 siblings, 1 reply; 387+ messages in thread From: Björn Persson @ 2004-09-07 22:34 UTC (permalink / raw) jayessay wrote: > I'm not tring to convince anyone to use dynamic typing and languages > here. I'm just trying to ensure that lurkers and others here are not > getting some goofy incorrect view of what they are and how they work. Lurking in this thread I note once again that zealots occur not only in the Ada camp, because this Jayessay guy is obviously a Lisp zealot who's firmly convinced that anything that isn't Common Lisp is broken. But I suspect that that isn't quite the view you're trying to ensure that I get. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 22:34 ` Björn Persson @ 2004-09-08 16:28 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-08 16:28 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> writes: > jayessay wrote: > > > I'm not tring to convince anyone to use dynamic typing and languages > > here. I'm just trying to ensure that lurkers and others here are not > > getting some goofy incorrect view of what they are and how they work. > > Lurking in this thread I note once again that zealots occur not only > in the Ada camp, because this Jayessay guy is obviously a Lisp zealot > who's firmly convinced that anything that isn't Common Lisp is broken. No, Common Lisp is broken as well... /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:22 ` jayessay ` (2 preceding siblings ...) 2004-09-07 22:34 ` Björn Persson @ 2004-09-08 23:28 ` Randy Brukardt 3 siblings, 0 replies; 387+ messages in thread From: Randy Brukardt @ 2004-09-08 23:28 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3brgidrzb.fsf@rigel.goldenthreadtech.com... ... > Proving things above the fairly simple level in software falls victim > to the halting problem. The specifications (even very good ones) are > typically not rigorous enough to _prove_ any conformance either. > There are, of course, exceptions. The SPARK people claim to have had good luck in proving Ada software doesn't have run-time errors and meets its specifications. See www.sparkada.com. I'd expect that writing the specifications would be interesting. But it would at least seem a useful technique to eliminate errors in smaller subprograms, so that testing can be focused on the whole system (where you have a much better chance of doing it in a reproducible fashion). After all, creating good reusable tests is expensive, no matter what they're testing (and non-reusable tests are close to worthless). Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 4:36 ` Kevin Cline 2004-09-05 16:13 ` Richard Riehle 2004-09-05 17:28 ` Jean-Marc Bourguet @ 2004-09-05 21:01 ` Jeffrey Carter 2004-09-06 2:17 ` stephane richard 2004-09-06 21:12 ` jayessay 3 siblings, 1 reply; 387+ messages in thread From: Jeffrey Carter @ 2004-09-05 21:01 UTC (permalink / raw) Kevin Cline wrote: > I've come to the same conclusion. Once you decide to test code before > you write it, strong typing loses most of it's value. On the other > hand, if I'm working on code without a good set of automated tests, > then strong typing is a very nice thing to have. For software of typical complexity, testing sufficient to prove the absence of errors takes longer than the allowable schedule for any project I've ever worked on. Testing in the real world cannot be counted on to find all errors. Since testing cannot be counted on to catch all errors, anything else that finds errors may catch errors that testing will miss. There is a synergy between the Ada features that find errors during compilation (of which strong typing is only one) and testing. It is a documented fact that errors cost less to fix the earlier they are found, so errors found during compilation save money compared to those found during testing. The cost of fixing an error is proportional to the time spent making the correction, so errors found during compilation take less time to fix than those found during testing. If time to market is a concern, using a language that finds more errors during compilation will decrease the time to deployment. The facts do not support a claim that testing is as time or cost efficient as detecting errors during compilation. -- Jeff Carter "To Err is human, to really screw up, you need C++!" St�phane Richard 63 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 21:01 ` Jeffrey Carter @ 2004-09-06 2:17 ` stephane richard 0 siblings, 0 replies; 387+ messages in thread From: stephane richard @ 2004-09-06 2:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 323 bytes --] "Jeffrey Carter" <spam@spam.com> wrote in message news:u8L_c.8238$w%6.5607@newsread1.news.pas.earthlink.net... > -- > Jeff Carter > "To Err is human, to really screw up, you need C++!" > St�phane Richard > 63 > I see my quote is going places ;-). St�phane Richard "Ada World" webmaster http://www.adaworld.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 4:36 ` Kevin Cline ` (2 preceding siblings ...) 2004-09-05 21:01 ` Jeffrey Carter @ 2004-09-06 21:12 ` jayessay 2004-09-07 8:23 ` Dmitry A. Kazakov 3 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-06 21:12 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > jayessay wrote > > "Richard Riehle" <adaworks@earthlink.net> writes: > > > > Also, logic errors (what most > > people would consider significantly more negative) are far rarer. > > > > There turn out to be various reasons for this, but two worth > > mentioning are the sort of bottom up style of programming as described > > by Paul Graham (a kind of agile/extreme programming) and the ability > > to move Lisp to the expressive level of the application domain. > > > > In any application/system of any significance these two go hand in > > hand. The second is achieved by crafting a constrained narrowly > > focused domain specific language _within_ Lisp, which allows the > > programmer to then work at the level of the domain, _both_ > > syntactically as well as semantically. This is why Lisp macros > > (please don't confuse with any other kind of macro you've come across > > before) are such a big deal. > > > > Now, admittedly, creating these is not something your typical code > > monkey is going to grok. This is one of the big reasons why Lisp will > > never be as "popular" as something like Java. But then your typical > > code monkey isn't going to be building your core internal application > > api either. Once you've built this though, even a code monkey will be > > a lot more productive and produce much more clean and robust code. > > > > > For example, a Common Lisp programmer rarely agnonizes over such > > > silliness as constructors, copy constructors, overloading assignment > > > operators, friends, and all the hideous little details that > > > characterize so much of C++ programming. > > I'm skeptical. In any language, data structures will require > initialization to reach the empty state. Just to be clear, I didn't say that last bit, Richard Riehle did. But you've mixed it in with my comments so it is unclear of what you are skeptical - everything quoted above or just the R.R. bit. It's also worth noting that if you substituted "Ada" for "C++" there would not be a substantive change to the bit. Anyway, other than "constructors" none of the stuff in R.R.'s quote is remotely the concern of a developer using Common Lisp. > You still have to write the code, it just has a different name. > Instead of MyThing(int mobys, ...) you have (defun > make-my-thing(mobys ...). Strictly speaking, this is usually simply not true. The normal case by far is one where this code is generated for you from a specification and it is sufficient. There are cases where this will need to be overridden or otherwise enhanced, but those are "outlying" cases. > Instead of a copy constructor, you have (defun > clone-my-thing(thing) ...). This sort of thing is _extremely_ rare, because you don't use or need "copy" semantics. You just do _not_ make copies of things unless there is some _domain_ level reason for it. [Aside: fyi, in such cases where this makes sense it is _much_ more likely that you'd be using defmethod for this sort of thing]. > And if you open files or lock mutexes or consume any other limited > resource, you are going to have to ensure they are released by > writing the equivalent of a destructor. Macros eliminate this sort of "boiler plate" code. These are nothing at all like a destructor. Most other uses of "destructors" typically revolve around "memory management" which obviously is pretty irrelevant in Common Lisp. A typical example here would be with-open-file. You simply do not need to be concerned with the maintenance of the file/os resource, etc. It is handled for you and guranteed to be cleaned up when leaving scope whether by normal or exceptional flow. Same with locks: ;;; Serialize access, lock for update, guarantee unlock on exception, ;;; and unlock/commit on success ;;; (with-protected-resource (get-database :medline-journals) (foo it) (bar it)) > When done well, C++ programming does not get mired in hideous little > details. But like most programming, it is rarely done well. And the > more popular a language, the lower the performance of the average > practitioner. Lots of people learned C++ and Java because that's what > the market demanded. So there is lots of horrible C++ code and Java > code. Mostly agree with this (though C++ does force you to deal with a lot of extraneous grime). > People learn LISP because they love programming. Not all LISP > programmers are geniuses, but almost all are well above the mean. I think you are basically correct in this also. BTW, "LISP" is basically never used anymore except by some as a shorthand for "a Lisp" or "Lisp like language", i.e., as a term for a certain class of languages. > ... > > 1. Which from experience would typically be in the range of 250K-500K > > lines of equivalent Ada/C++/Eiffel/etc. An order of magnitude is not > > hyperbole here even though most uninitiated developers will raise > > their eyebrows or roll their eyes. > > This I know to be true, although again it's not fair to compare the > C++ code from an average programmer to the LISP code from an expert. > An expert C++ programmer can reduce the line count of typical code > by 60% or more. I'm instantiating "LISP" here with Common Lisp. I'm not talking about code monkey C++/Ada/Eiffel vs Guru Lisp. The mentioned one to two orders of magnitude of typical gain holds for expert code vs expert code. > In either language, experts will refactor until a new > domain-specific language appears. I agree that experts will refactor no matter what. However, there is no way to create a domain specific _language_ _within_ C++/Ada/Eiffel/etc. I'm talking about where the the syntax as well as the semantics is just as transparently and cleanly integrated in the language as any core aspect. Where there is no bolt on interpreter needed, no hacking away trying to kludge up something with yacc/lex types of tools. And where the result supports the expression of the application code naturally and cleanly in the terms and processes of the target domain. You just can't do this with things like C++/Ada/Eiffel/etc. You can't even do this with stuff like Smalltalk, Python, or even Dylan. The key to this was succinctly captured by John Foderaro: "Lisp is a programmable programming language". /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 21:12 ` jayessay @ 2004-09-07 8:23 ` Dmitry A. Kazakov 2004-09-07 15:25 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-07 8:23 UTC (permalink / raw) On 06 Sep 2004 17:12:54 -0400, jayessay wrote: >> And if you open files or lock mutexes or consume any other limited >> resource, you are going to have to ensure they are released by >> writing the equivalent of a destructor. > > Macros eliminate this sort of "boiler plate" code. These are nothing > at all like a destructor. Most other uses of "destructors" typically > revolve around "memory management" which obviously is pretty > irrelevant in Common Lisp. > > A typical example here would be with-open-file. You simply do not > need to be concerned with the maintenance of the file/os resource, > etc. It is handled for you and guranteed to be cleaned up when > leaving scope whether by normal or exceptional flow. > > Same with locks: > > ;;; Serialize access, lock for update, guarantee unlock on exception, > ;;; and unlock/commit on success > ;;; > (with-protected-resource (get-database :medline-journals) > (foo it) > (bar it)) That's because LISP is not truly dynamic. In a really dynamic language the scopes should be regarded as superfluous as type information, they just bind programmer's fantasy and creativity. Bad enough, the nasty compiler might guess your intention (to lock something). What is worse is that the code maintainer could do it too! Garbage collectors solve this. My favorite language is MS-DOS: format C: /q solves everything. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 8:23 ` Dmitry A. Kazakov @ 2004-09-07 15:25 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-07 15:25 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On 06 Sep 2004 17:12:54 -0400, jayessay wrote: > > >> And if you open files or lock mutexes or consume any other limited > >> resource, you are going to have to ensure they are released by > >> writing the equivalent of a destructor. > > > > Macros eliminate this sort of "boiler plate" code. These are nothing > > at all like a destructor. Most other uses of "destructors" typically > > revolve around "memory management" which obviously is pretty > > irrelevant in Common Lisp. > > > > A typical example here would be with-open-file. You simply do not > > need to be concerned with the maintenance of the file/os resource, > > etc. It is handled for you and guranteed to be cleaned up when > > leaving scope whether by normal or exceptional flow. > > > > Same with locks: > > > > ;;; Serialize access, lock for update, guarantee unlock on exception, > > ;;; and unlock/commit on success > > ;;; > > (with-protected-resource (get-database :medline-journals) > > (foo it) > > (bar it)) > > That's because LISP is not truly dynamic. In a really dynamic language the > scopes should be regarded as superfluous as type information, they just > bind programmer's fantasy and creativity. Bad enough, the nasty compiler > might guess your intention (to lock something). What is worse is that the > code maintainer could do it too! Garbage collectors solve this. My favorite > language is MS-DOS: format C: /q solves everything. Whatever floats your boat, bro... /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 16:43 ` jayessay 2004-09-05 4:36 ` Kevin Cline @ 2004-09-05 18:28 ` Larry Kilgallen [not found] ` <e749549b.0409042036.5d4822a2@posting.googlOrganization: LJK Software <vpblkhspuA9F@eisner.encompasserve.org> 2004-09-06 7:49 ` Ole-Hjalmar Kristensen 3 siblings, 0 replies; 387+ messages in thread From: Larry Kilgallen @ 2004-09-05 18:28 UTC (permalink / raw) In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard Riehle" <adaworks@earthlink.net> writes: > No one argues that testing is unimportant. > No language can protect us, at compile time, from every possible > error. But assuming perfect testing, finding the errors during compilation rather than in testing saves me time, and time is money. ^ permalink raw reply [flat|nested] 387+ messages in thread
[parent not found: <e749549b.0409042036.5d4822a2@posting.googlOrganization: LJK Software <vpblkhspuA9F@eisner.encompasserve.org>]
* Re: ADA Popularity Discussion Request [not found] ` <e749549b.0409042036.5d4822a2@posting.googlOrganization: LJK Software <vpblkhspuA9F@eisner.encompasserve.org> @ 2004-09-05 22:49 ` Kevin Cline 2004-09-06 16:39 ` jayessay ` (3 more replies) 0 siblings, 4 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-05 22:49 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>... > In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard Riehle" <adaworks@earthlink.net> writes: > > > No one argues that testing is unimportant. > > > No language can protect us, at compile time, from every possible > > error. > > But assuming perfect testing, finding the errors during compilation > rather than in testing saves me time, and time is money. I thought so too, until I tried incremental test-first development. Retesting a unit after adding a few lines of code means that type mismatches are caught immediately with or without strong typing. But it goes faster if you don't have to compile and link every iteration. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 22:49 ` Kevin Cline @ 2004-09-06 16:39 ` jayessay 2004-09-07 22:01 ` Lionel Draghi 2004-09-09 0:13 ` Randy Brukardt 2004-09-06 21:01 ` Stephen Leake ` (2 subsequent siblings) 3 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-06 16:39 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message > > "Richard Riehle" <adaworks@earthlink.net> writes: > > > > > No one argues that testing is unimportant. > > > > > No language can protect us, at compile time, from every possible > > > error. > > > > But assuming perfect testing, finding the errors during compilation > > rather than in testing saves me time, and time is money. > > I thought so too, until I tried incremental test-first development. > Retesting a unit after adding a few lines of code means that type > mismatches are caught immediately with or without strong typing. But > it goes faster if you don't have to compile and link every iteration. Exactly. Actually this sort of development will save you much more time and money than you could ever hope for from typical static typing. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:39 ` jayessay @ 2004-09-07 22:01 ` Lionel Draghi 2004-09-08 8:52 ` Ole-Hjalmar Kristensen 2004-09-09 1:08 ` Kevin Cline 2004-09-09 0:13 ` Randy Brukardt 1 sibling, 2 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-07 22:01 UTC (permalink / raw) jayessay wrote: ... > Exactly. Actually this sort of development will save you much more > time and money than you could ever hope for from typical static typing. How could this be? With powerful typing you write code. Without, you write as much code and much more tests. Let's compare: A : function Random_Index return Integer; -- return's a value between 1 and 10 B : type Index is range 1 .. 10; function Random_Index return Index; If considering code and comments, both are of the same length. On the other hand, in the A version, I need to check the return value on each call. Moreover, if the B Random_Index try to return 11, it will raise Constraint_Error, whatever is the test. If the A version try to return 11 it may be in some other test where you din't check Ramdom_Index result, and you may not notice it. So, not only strong typing save you time and money, but it just do a better job (not to mention possible compiler optimization and preventing the discrepancy risk between comments and code). PS : actually the difference may be even bigger : static code analysis tool may prove that B is correct, in which case you don't even need to test it, and not beeing able to do the same with A because of the missing semantic. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 22:01 ` Lionel Draghi @ 2004-09-08 8:52 ` Ole-Hjalmar Kristensen 2004-09-08 10:20 ` Georg Bauhaus ` (2 more replies) 2004-09-09 1:08 ` Kevin Cline 1 sibling, 3 replies; 387+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-08 8:52 UTC (permalink / raw) >>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: LD> jayessay wrote: LD> ... >> Exactly. Actually this sort of development will save you much more >> time and money than you could ever hope for from typical static typing. LD> How could this be? LD> With powerful typing you write code. LD> Without, you write as much code and much more tests. You are missing the point. He is not arguing against strong typing, but against *static* typing. <snip> -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 8:52 ` Ole-Hjalmar Kristensen @ 2004-09-08 10:20 ` Georg Bauhaus 2004-09-08 12:01 ` Dmitry A. Kazakov 2004-09-08 16:08 ` jayessay 2 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-08 10:20 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: :>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: : : LD> jayessay wrote: : LD> ... : >> Exactly. Actually this sort of development will save you much more : >> time and money than you could ever hope for from typical static typing. : : LD> How could this be? : LD> With powerful typing you write code. : LD> Without, you write as much code and much more tests. : : You are missing the point. He is not arguing against strong typing, : but against *static* typing. I don't think so. For type checking to become effective with strong but dynamic checking, the program (or expression) will have to be run. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 8:52 ` Ole-Hjalmar Kristensen 2004-09-08 10:20 ` Georg Bauhaus @ 2004-09-08 12:01 ` Dmitry A. Kazakov 2004-09-08 16:26 ` jayessay 2004-09-08 19:46 ` Alexander E. Kopilovich 2004-09-08 16:08 ` jayessay 2 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-08 12:01 UTC (permalink / raw) On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > LD> jayessay wrote: > LD> ... > >> Exactly. Actually this sort of development will save you much more > >> time and money than you could ever hope for from typical static typing. > > LD> How could this be? > LD> With powerful typing you write code. > LD> Without, you write as much code and much more tests. > > You are missing the point. He is not arguing against strong typing, > but against *static* typing. Apparently, but when consistently pursued that kind of argumentation inevitable leads to arguing against any typing, especially against ADT. The philosophy behind is that types are random artifacts of the program, rather than the basis of software design. When the program is not thought in terms of types, there is nothing to check, either statically or dynamically. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 12:01 ` Dmitry A. Kazakov @ 2004-09-08 16:26 ` jayessay 2004-09-08 19:12 ` Dmitry A. Kazakov 2004-09-08 21:17 ` Lionel Draghi 2004-09-08 19:46 ` Alexander E. Kopilovich 1 sibling, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-08 16:26 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: > > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > > > LD> jayessay wrote: > > LD> ... > > >> Exactly. Actually this sort of development will save you much more > > >> time and money than you could ever hope for from typical static typing. > > > > LD> How could this be? > > LD> With powerful typing you write code. > > LD> Without, you write as much code and much more tests. > > > > You are missing the point. He is not arguing against strong typing, > > but against *static* typing. You, Ole, are on target. Dmitry, you need some misconceptions cleared up. > Apparently, but when consistently pursued that kind of argumentation > inevitable leads to arguing against any typing, especially against > ADT. No, it does not. This is simply and clearly incorrect. > The philosophy behind is that types are random artifacts of the > program, No, this is also incorrect. The real difference is that with dynamic typing _values_ have types _not_ variables. Since _variables_ don't even exist at runtime, your type information is largely gone at runtime in static systems. In dynamically typed system you can never have something like Unchecked_Conversion, because the type information is actually with the value at all times. You can convert, but this always creates a _new_ value. > rather than the basis of software design. When the program > is not thought in terms of types, there is nothing to check, either > statically or dynamically. This is wrong on two counts: First, types are indeed part of program design in dynamic languages. In some respects they are even more important than in static languages as they exist at _all_ times: compile load (link) and run. They are _always_ checked _all_ the time. If you want to say "Ooo! this has a performance hit", fine, but with current systems any such checks are basically in the noise. OTOH, you can annotate a dynamic program with static type information and/or use type inference to remove this issue from most cases. Second, types are _not_ the only thing to check in a program. There are many aspects that are not and even cannot be described by types. This should be obvious or else you would never have the need to ever write any functions/procedures. Checking the correctness of algorithms is every bit as important as type consistency. I'm pretty sure that you (anyone) will agree with this once brought to your attention. I read this newsgroup mostly as a lurker these days. I used to be a static typist, advocated it and thought Ada was a pretty good informal type system. I'm not arguing that anyone here should stop using Ada (or C++ or Haskell or whatever static language floats your boat). I'm simply trying to correct a lot of misinformation here about (Common) Lisp, "extreme/agile/incremental" development, and dynamically typed languages in general. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 16:26 ` jayessay @ 2004-09-08 19:12 ` Dmitry A. Kazakov 2004-09-08 21:02 ` Björn Persson ` (2 more replies) 2004-09-08 21:17 ` Lionel Draghi 1 sibling, 3 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-08 19:12 UTC (permalink / raw) On 08 Sep 2004 12:26:54 -0400, jayessay wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> The philosophy behind is that types are random artifacts of the >> program, > > No, this is also incorrect. The real difference is that with dynamic > typing _values_ have types _not_ variables. Since _variables_ don't > even exist at runtime, your type information is largely gone at > runtime in static systems. I suppose you are talking about polymorphic objects. They still have *a* type. It is what Ada calls "class". So what is your point: 1. That statically typed languages cannot express polymorphism? This is plainly wrong. 2. That all polymorphic values should be considered of same type ANY? This is also wrong. > In dynamically typed system you can never > have something like Unchecked_Conversion, because the type information > is actually with the value at all times. You can convert, but this > always creates a _new_ value. As Unchecked_Conversion does. And I still do not see your point. You have accepted that types exist. So you are talking about type information, excellent. Where is then any difference between static and dynamic typing? There is *no* one. From this perspective, dynamically typed systems are subset of statical ones. This is important to understand. This is also the reason why "truly dynamic" people sooner or later start to argue against types. Because, take a static language, derive everything from same base, and you will have the case, where the type information would be as useless (at compile time) as in a dynamically typed language. Static typing does not make type information unavailable. It makes it in some cases a-priory known. Note that to argue against type is not a crime. On the contrary, it is interesting to speculate whether an alternative approach to our view on software design were possible. The only problem is that modern dynamically typed languages do not offer that alternative. They are still typed, badly typed, if you want. (:-)) >> rather than the basis of software design. When the program >> is not thought in terms of types, there is nothing to check, either >> statically or dynamically. > > This is wrong on two counts: > > First, types are indeed part of program design in dynamic languages. > In some respects they are even more important than in static languages > as they exist at _all_ times: compile load (link) and run. They are > _always_ checked _all_ the time. If you want to say "Ooo! this has a > performance hit", fine, but with current systems any such checks are > basically in the noise. OTOH, you can annotate a dynamic program with > static type information and/or use type inference to remove this issue > from most cases. Fine, types exist. Then you also have to accept that types need to be documented in some way. The next step is that the documentation language should be a part of the programming language. And the final step, if that is a part of the language, why the compiler should be prevented from checking where it can? Again, having accepted types you cannot argue that to check them earlier is worse than to check them later. You can only say that static checks, when imposed, would limit you in using this and that *concrete* programming pattern. And anyway, there are others very useful patterns nicely working with static checks. So what is the point? > Second, types are _not_ the only thing to check in a program. There > are many aspects that are not and even cannot be described by types. > This should be obvious or else you would never have the need to ever > write any functions/procedures. Checking the correctness of > algorithms is every bit as important as type consistency. I'm pretty > sure that you (anyone) will agree with this once brought to your > attention. Yes. Under nothing to check I meant types. But you are not proposing to get rid of them... -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:12 ` Dmitry A. Kazakov @ 2004-09-08 21:02 ` Björn Persson 2004-09-08 23:31 ` jayessay 2004-09-08 23:02 ` Alexander E. Kopilovich 2004-09-08 23:23 ` jayessay 2 siblings, 1 reply; 387+ messages in thread From: Björn Persson @ 2004-09-08 21:02 UTC (permalink / raw) Dmitry A. Kazakov wrote: > From this > perspective, dynamically typed systems are subset of statical ones. This is > important to understand. This is also the reason why "truly dynamic" people > sooner or later start to argue against types. Because, take a static > language, derive everything from same base, and you will have the case, > where the type information would be as useless (at compile time) as in a > dynamically typed language. Static typing does not make type information > unavailable. It makes it in some cases a-priory known. That's an interesting point. In Java, all classes are derived from Object. Yet I find type information useful in Java. But if all parameters of all methods were declared as Object, then it would start to look like a dynamically typed language. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 21:02 ` Björn Persson @ 2004-09-08 23:31 ` jayessay 2004-09-09 16:00 ` Björn Persson 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-08 23:31 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> writes: > Dmitry A. Kazakov wrote: > > > From this > > perspective, dynamically typed systems are subset of statical ones. No. You are confusing dynamically typed with _UN_typed. > > This is > > important to understand. This is also the reason why "truly dynamic" people > > sooner or later start to argue against types. None that I know. If you look at what "truly dynamic" people are saying over on c.l.l, c.l.python, c.l.smalltalk, etc. you would know just how wrong you are. > > Because, take a static > > language, derive everything from same base, and you will have the case, > > where the type information would be as useless (at compile time) as in a > > dynamically typed language. Static typing does not make type information > > unavailable. It makes it in some cases a-priory known. > > That's an interesting point. In Java, all classes are derived from > Object. Yet I find type information useful in Java. But if all > parameters of all methods were declared as Object, then it would start > to look like a dynamically typed language. Egads, no! It would begin to look _UN_typed! Please try to get a grip on this. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 23:31 ` jayessay @ 2004-09-09 16:00 ` Björn Persson 0 siblings, 0 replies; 387+ messages in thread From: Björn Persson @ 2004-09-09 16:00 UTC (permalink / raw) jayessay wrote: > Björn Persson <spam-away@nowhere.nil> writes: > >>Dmitry A. Kazakov wrote: >> >>>Because, take a static >>>language, derive everything from same base, and you will have the case, >>>where the type information would be as useless (at compile time) as in a >>>dynamically typed language. Static typing does not make type information >>>unavailable. It makes it in some cases a-priory known. >> >>That's an interesting point. In Java, all classes are derived from >>Object. Yet I find type information useful in Java. But if all >>parameters of all methods were declared as Object, then it would start >>to look like a dynamically typed language. > > Egads, no! It would begin to look _UN_typed! Please try to get a > grip on this. class Superclass { Object One; } class Subclass extends Superclass { Object Two; } class Other_Class {} class Proof { void A_Method(Object Thing) { System.out.println("This object's type is \"" + Thing.getClass().getName() +"\"."); System.out.println("Accessing \"One\"."); ((Superclass)Thing).One = new Other_Class(); if(Thing instanceof Subclass) { System.out.println("Accessing \"Two\"."); ((Subclass)Thing).Two = new Other_Class(); } } public static void main(String[] Param) { Object Super = new Superclass(); Object Sub = new Subclass(); Object Other = new Other_Class(); Object Demo = new Proof(); ((Proof)Demo).A_Method(Super); ((Proof)Demo).A_Method(Sub); ((Proof)Demo).A_Method(Other); } } $ javac Proof.java $ java Proof This object's type is "Superclass". Accessing "One". This object's type is "Subclass". Accessing "One". Accessing "Two". This object's type is "Other_Class". Accessing "One". Exception in thread "main" java.lang.ClassCastException at Proof.A_Method(Proof.java:7) at Proof.main(Proof.java:22) Note how everything is declared as Object. Note how the type of each object can still be determined. Note how Java refuses to turn an Other_Class object into a Superclass object. Do you consider this untyped? If so, please state exactly how you define "untyped", so we can start speaking the same language. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:12 ` Dmitry A. Kazakov 2004-09-08 21:02 ` Björn Persson @ 2004-09-08 23:02 ` Alexander E. Kopilovich 2004-09-08 23:23 ` jayessay 2 siblings, 0 replies; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-09-08 23:02 UTC (permalink / raw) To: comp.lang.ada Dmitry A. Kazakov wrote: > Where is then any > difference between static and dynamic typing? There is *no* one. From this > perspective, dynamically typed systems are subset of statical ones. Just as any manifold (from differential topology) - like sphere... or even better - like Klein's bottle - is a subset (sub-manifold) of Euclidean space of higher dimension (this isn't too obvious, but Whitney theorem stands for this). But topologists very often are considering manifolds without immersing them into appropriate Euclidean space - and they do that for good reasons. Yes, you always can consider dynamically typed system as a subsystem of some statically typed system, but the latter generally will be substantially heavier (in terms of precise description, full understanding and resources needed for its maintenance). Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:12 ` Dmitry A. Kazakov 2004-09-08 21:02 ` Björn Persson 2004-09-08 23:02 ` Alexander E. Kopilovich @ 2004-09-08 23:23 ` jayessay 2004-09-09 9:12 ` Dmitry A. Kazakov 2 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-08 23:23 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On 08 Sep 2004 12:26:54 -0400, jayessay wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > > > >> The philosophy behind is that types are random artifacts of the > >> program, > > > > No, this is also incorrect. The real difference is that with dynamic > > typing _values_ have types _not_ variables. Since _variables_ don't > > even exist at runtime, your type information is largely gone at > > runtime in static systems. > > I suppose you are talking about polymorphic objects. No, I'm not. Simply put variable don't exist at runtime. I'm talking about every value having its type with it. > 1. That statically typed languages cannot express polymorphism? This is > plainly wrong. This is irrelevant as again, the type information is basically gone. You have certain limited RTTI abilities, but that is not the same. > 2. That all polymorphic values should be considered of same type ANY? This > is also wrong. No, this is irrelevant. > As Unchecked_Conversion does. I guess i've forgotten this (never really used it much). So, when 13.9(5) says an instance of this returns a value whose "representation is the same as that of the source, how is that functionally different from a cast? I realize that can make a differnce at compile time, but where's the runtime difference? Especially as there's no type at runtime. > is a part of the language, why the compiler should be prevented from > checking where it can? It's _not_ prevented - it isn't _required_ to! > Again, having accepted types you cannot argue that to check them earlier is > worse than to check them later. If you think I'm arguing that, you really haven't understood. I'm not saying checking them "earlier" is somehow bad, I'm saying it is largely irrelevant in practice with dynamic typing because any type inconsistency is caught during development anyway! /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 23:23 ` jayessay @ 2004-09-09 9:12 ` Dmitry A. Kazakov 2004-09-10 1:16 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-09 9:12 UTC (permalink / raw) On 08 Sep 2004 19:23:40 -0400, jayessay wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On 08 Sep 2004 12:26:54 -0400, jayessay wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> The philosophy behind is that types are random artifacts of the >>>> program, >>> >>> No, this is also incorrect. The real difference is that with dynamic >>> typing _values_ have types _not_ variables. Since _variables_ don't >>> even exist at runtime, your type information is largely gone at >>> runtime in static systems. >> >> I suppose you are talking about polymorphic objects. > > No, I'm not. Simply put variable don't exist at runtime. I'm talking > about every value having its type with it. But that's exactly what a [dynamically] polymorphic object is. Its value (a class-wide value in Ada terms) carries the type tag with it. The type tag determines the specific type. Note that this specific type is not the type of the object. T and T'Class are different types in Ada. Note also that there is still room for static checks here. Toy'Class and Gun'Class are statically different types. So Baby.Take (Gun) will be a compile error. >> 1. That statically typed languages cannot express polymorphism? This is >> plainly wrong. > > This is irrelevant as again, the type information is basically gone. > You have certain limited RTTI abilities, but that is not the same. Should it mean that dynamic polymorphism is not powerful enough for the tasks ...., which ones? Note that nobody says that ADT theory in its present state is complete. So to argue against its concrete implementations in concrete statically typed languages would be rather wasting time. Because everybody will agree that there are [many] problems. So your argument should go beyond that. Namely: no static analysis of types in any its form can be fundamentally useful. Here we go again.... >> 2. That all polymorphic values should be considered of same type ANY? This >> is also wrong. > > No, this is irrelevant. Really? But then if you have different bases like Toy and Gun, you can use this type information to *statically* ensure that no type of guns can be ever given to a child. >> As Unchecked_Conversion does. > > I guess i've forgotten this (never really used it much). So, when > 13.9(5) says an instance of this returns a value whose "representation > is the same as that of the source, ARM then continues to the list of conditions to be satisfied to make the above true. In other cases the result might be quite different. For example when you convert between a general access and pool specific access types. Former are probably fat pointers, latter could be tiny integers, depending on the compiler, of course. > how is that functionally different from a cast? It is a cast. > I realize that can make a differnce at compile time, but > where's the runtime difference? Especially as there's no type at > runtime. How so? Types do exist at run-time. Consider it as if the *unused* type information were optimized out. >> is a part of the language, why the compiler should be prevented from >> checking where it can? > > It's _not_ prevented - it isn't _required_ to! That's silly. Why not to require to check what could be checked? Compare with your beloved tests. You can test, but not required to. Any difference? No one, except that types as a concept have reached the level of formality where they can be integrated into the language to support static analysis. Which only means that the tests related to types and their relationships are performed by the compiler. Pre- and post-conditions is another example of tests which can be partially automated. The rest, TDD etc has not reached that level. It is no more than a mere informal advise of good programming practice. As such it by no means can supersede static analysis. >> Again, having accepted types you cannot argue that to check them earlier is >> worse than to check them later. > > If you think I'm arguing that, you really haven't understood. I'm not > saying checking them "earlier" is somehow bad, I'm saying it is > largely irrelevant in practice with dynamic typing because any type > inconsistency is caught during development anyway! "Any type inconsistency caught anyway" is either too strong to be true or else it just means that there are no interesting types to check for consistency. The latter returns us back to the starting point. Are you using types in your software design? -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 9:12 ` Dmitry A. Kazakov @ 2004-09-10 1:16 ` jayessay 2004-09-10 15:06 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-10 1:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On 08 Sep 2004 19:23:40 -0400, jayessay wrote: > > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > > > >> On 08 Sep 2004 12:26:54 -0400, jayessay wrote: > >> > >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >>> > >>>> The philosophy behind is that types are random artifacts of the > >>>> program, > >>> > >>> No, this is also incorrect. The real difference is that with dynamic > >>> typing _values_ have types _not_ variables. Since _variables_ don't > >>> even exist at runtime, your type information is largely gone at > >>> runtime in static systems. > >> > >> I suppose you are talking about polymorphic objects. > > > > No, I'm not. Simply put variable don't exist at runtime. I'm talking > > about every value having its type with it. > > But that's exactly what a [dynamically] polymorphic object is. No, this is just wrong. > >> 2. That all polymorphic values should be considered of same type ANY? This > >> is also wrong. > > > > No, this is irrelevant. > > Really? Yes, really. > >> As Unchecked_Conversion does. > > > > I guess i've forgotten this (never really used it much). So, when > > 13.9(5) says an instance of this returns a value whose "representation > > is the same as that of the source, > > ARM then continues to the list of conditions to be satisfied to make the > above true. > > In other cases the result might be quite different. For example when you > convert between a general access and pool specific access types. Former are > probably fat pointers, latter could be tiny integers, depending on the > compiler, of course. > > > how is that functionally different from a cast? > > It is a cast. You're contradicting your own explanation. By your own comments above it is (at least sometimes) _not_ a cast. > How so? Types do exist at run-time. Consider it as if the *unused* type > information were optimized out. No they do not. If they did you could create them, query them, change them, assign them to variables, etc. Now, you and I both know you can't do any of this with Ada types at runtime. > > It's _not_ prevented - it isn't _required_ to! > > That's silly. Why not to require to check what could be checked? Because it breaks many things in dynamic systems, that's why. Sorry, but it is your comment that is "silly", not the dynamic type system. > > If you think I'm arguing that, you really haven't understood. I'm not > > saying checking them "earlier" is somehow bad, I'm saying it is > > largely irrelevant in practice with dynamic typing because any type > > inconsistency is caught during development anyway! > > "Any type inconsistency caught anyway" is either too strong to be true or > else it just means that there are no interesting types to check for > consistency. You are just plain wrong, but if you have some vested interest in believing that, fine. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 1:16 ` jayessay @ 2004-09-10 15:06 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-10 15:06 UTC (permalink / raw) On 09 Sep 2004 21:16:24 -0400, jayessay wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On 08 Sep 2004 19:23:40 -0400, jayessay wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> On 08 Sep 2004 12:26:54 -0400, jayessay wrote: >>>> >>> No, I'm not. Simply put variable don't exist at runtime. I'm talking >>> about every value having its type with it. >> >> But that's exactly what a [dynamically] polymorphic object is. > > No, this is just wrong. ARM 3.9(3) reads: "An object of a tagged type has an associated (run-time) tag that identifies the specific tagged type used to create the object originally. The tag of an operand of a class-wide tagged type TοΏ½Class controls which subprogram body is to be executed when a primitive subprogram of type T is applied to the operand (see 3.9.2); using a tag to control which body to execute is called dispatching." >>>> As Unchecked_Conversion does. >>> >>> I guess i've forgotten this (never really used it much). So, when >>> 13.9(5) says an instance of this returns a value whose "representation >>> is the same as that of the source, >> >> ARM then continues to the list of conditions to be satisfied to make the >> above true. >> >> In other cases the result might be quite different. For example when you >> convert between a general access and pool specific access types. Former are >> probably fat pointers, latter could be tiny integers, depending on the >> compiler, of course. >> >>> how is that functionally different from a cast? >> >> It is a cast. > > You're contradicting your own explanation. By your own comments above > it is (at least sometimes) _not_ a cast. It depends on what you understand under "cast". Anyway, what should prove [in-]existence of casts? >> How so? Types do exist at run-time. Consider it as if the *unused* type >> information were optimized out. > > No they do not. This is plainly wrong. Statically known information remains known at run time. This is what the word "static" means. > If they did you could create them, query them, change > them, assign them to variables, etc. This has nothing to do with the issue, but also wrong. > Now, you and I both know you > can't do any of this with Ada types at runtime. Again wrong: 1. Dynamic type creation in Ada: procedure Foo (First, Last : Integer) is type Dynamic_Array is array (Integer range First..Last) of Integer; begin ... end Foo; 2. Type querying in Ada: procedure Baz (Object : X'Class) is begin Put_Line ("My type is:" & External_Tag (Object'Tag)); end Baz; 3. Changing types in Ada. Types can be dynamically constrained in Ada. AFAIK, types will be dynamically extensible in the coming release of Ada standard. 4. Type variables. True, Ada does not have types as the first-class objects. So you cannot put type in a variable. For this one should have types types. >>> It's _not_ prevented - it isn't _required_ to! >> >> That's silly. Why not to require to check what could be checked? > > Because it breaks many things in dynamic systems, that's why. It breaks nothing, re-read it carefully: "to check what *could* be checked". Nobody claims that *all* types have to be checked statically. This would exclude dynamic polymorphism. Again, why not to check what can be checked? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 16:26 ` jayessay 2004-09-08 19:12 ` Dmitry A. Kazakov @ 2004-09-08 21:17 ` Lionel Draghi 2004-09-10 0:47 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Lionel Draghi @ 2004-09-08 21:17 UTC (permalink / raw) jayessay wrote: ... > First, types are indeed part of program design in dynamic languages. > In some respects they are even more important than in static languages > as they exist at _all_ times: compile load (link) and run. They are > _always_ checked _all_ the time. If you want to say "Ooo! this has a > performance hit", fine, but with current systems any such checks are > basically in the noise. OTOH, you can annotate a dynamic program with > static type information and/or use type inference to remove this issue > from most cases. Jon, I am trying my best to understand you without knowing Lisp, but I don't. This is the second time you explain this, but you are to abstract for me. My point is that with static typing, most type related problems are caught at compil time, before any execution. Know, you say here that it is possible to write annotation to reach the same confort level in Lisp. Could you explain me how is this supposed to save time and money? .... > I'm simply trying to correct a lot of misinformation here about > (Common) Lisp, > "extreme/agile/incremental" development, and dynamically typed > languages in general. Correct me if I am wrong, but you stated that "Actually this sort of development will save you much more time and money than you could ever hope for from typical static typing." And this is misinformation: *OK*, Agile methods may save you money (althrough there is no silver bullet and some people reading this news group possibly have more effective development process, for exemple using formal proof and much less testing), *BUT*, static typing is still unbeatable, with or without test-fist practice, as I illustrate in another message. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 21:17 ` Lionel Draghi @ 2004-09-10 0:47 ` jayessay 2004-09-10 17:40 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-10 0:47 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > jayessay wrote: > ... > > First, types are indeed part of program design in dynamic languages. > > In some respects they are even more important than in static languages > > as they exist at _all_ times: compile load (link) and run. They are > > _always_ checked _all_ the time. If you want to say "Ooo! this has a > > performance hit", fine, but with current systems any such checks are > > basically in the noise. OTOH, you can annotate a dynamic program with > > static type information and/or use type inference to remove this issue > > from most cases. > > Jon, > > I am trying my best to understand you without knowing Lisp, but I > don't. This is the second time you explain this, but you are to > abstract for me. I'm not sure which part you are having trouble with. Let's try this (admittedly somewhat handwavy, but intended to help get the ideas): To a reasonable first approximation: What is typed? Static: Variables and expressions (including literals and variables) Dynamic: Values (the things you think of as "in a variable" or as the result of the evaluation of an expression) Where/when is the "type"? Static: In the compiler's symbol table and semantic analyzer; exists during compilation. Types do not exist at runtime. To some extent they are still around at link time in C++ in order for template instantiation to work. Important: Types are _not_ first class objects. Dynamic: In values; exists whenever a value exists - compiletime, load/link time, and runtime. Important: Types _are_ first class objects, i.e., there are _values_ which are _types_. The types of these value types are meta types. You can walk as far up the "logic ladder" as you want with this. "Ontologically" there is no difference (they have the same fundamental status) between these kinds of values and any other, e.g., integers, class instances, etc. You can bind them, query them, create them, if (as in Common Lisp) you have a meta object protocol (MOP) you can even _change_ them and _alter_ the behavior of the type system. There is a lot more here. What is checked? Static: Variables (containers) conform to expressions Dynamic: Values conform to operations (functions operators, etc.) When are things checked? Static: Mostly at compile time (though there are important exceptions) Examples: (Ada) x := a; The type of variable A is checked to conform with the type of variable X, so that X is assured that whatever the _value_ in A during runtime, it should be a member of the type of X (conform to it). x := a + b; the types of A & B are used to select a set of + operator candidates whose result types are then checked against the type of X to determine the unique operation (if it exists) to use. Generally, there is a good deal of copying of values going on at runtime. Variables exist only at compile time (though in C++ there is some level of existence through link), they are transformed to simply locations with enough space to hold values of the variables type (as determined at compile time)[2]. Dynamic: Mostly at runtime (though there are some useful exceptions). Examples: (Common Lisp) (let ((x a)) ...) the value _bound_ by (named by) A is _bound_ to X, so that X is also a _name_ for it within the scope of the let. Unless specifically requested, there are no type checks being made in these cases since there is no need for it - since a variable is just a binding (name) for a value it can be used to name any value. No copying is ever done. You can change or add a name to a value without opening a new scope by means of setf, e.g., (setf x a) (let ((x (+ a b))) ...) the standard + operation is generic (this is more analogous to an Ada function of a class wide type, than to generics). The dispatch mechanism checks the types of A and B and either raises an exception if there is no possible match or performs the operation[2]. If the operation is performed, the resulting value is _bound_ to X within the scope of the let. Values are never copied. Variables typically do not exist at runtime, with the important exception of dynamic variables (full symbols). Variables are basically transformed into locations that reference values. Is type consistency enforeced (is it type safe)? Static: Mostly. Casts, certain unchecked conversions, overlays can all subvert this. Dynamic: Yes, values cannot be interpreted as any type other than what they are. > My point is that with static typing, most type related problems are > caught at compil time, before any execution. > Know, you say here that it is possible to write annotation to reach > the same confort level in Lisp. > Could you explain me how is this supposed to save time and money? It is the extreme flexibility and interactive nature of the development with continual checking that is the big time saver and bug eliminator (both type and logic). The type annotation you can do does not save you any development time (it actually costs time - just like with static typing), it can save you runtime cycles by allowing the compiler to perform more optimizations. The really key thing here is that you develop by testing _everything_ in a very well scoped and limited unit at each incremental stage. I realize this is hard to get a grip on unless you've done it - especially coming from a global static type kind of mind set. > Correct me if I am wrong, but you stated that > "Actually this sort of development will save you much more > time and money than you could ever hope for from typical static typing." > > And this is misinformation: I don't think it is misinformation, but upon reading it again it could well be inaccurate. Misinformation is when you state a falsehood as fact about something you know nothing about. For example, "dynamic typing means no typing", "dynamic typing is unsafe", "lisp is interpreted". The above is inaccurate in that for all I know for some instantiation of "you", that instance will _not_ save anything using this sort of development. I know it has been true for me and many others I know. > *BUT*, static typing is still unbeatable, with or without test-fist > practice, as I illustrate in another message. In general I'm long past believing this. Even the Haskellers, MLers, etc. don't have good enough arguments or data to support the claims. I do believe that in certain niches this can indeed be true. /Jon Notes 1. As noted in the preface this is only a first order approximation. For example, in Ada, there may well be some extra stuff (e.g., dope vectors) beyond simply a location for things like unconstrained arrays. 2. This is _not_ like a "polymorphic" dispatch, that is the domain of methods, and generic functions nor an overloading. Generic functions are a proper superset of standard class based "object oriented" polymorphism. -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 0:47 ` jayessay @ 2004-09-10 17:40 ` Dmitry A. Kazakov 2004-09-12 16:02 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-10 17:40 UTC (permalink / raw) On 09 Sep 2004 20:47:54 -0400, jayessay wrote: > Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > >> jayessay wrote: >> ... >>> First, types are indeed part of program design in dynamic languages. >>> In some respects they are even more important than in static languages >>> as they exist at _all_ times: compile load (link) and run. They are >>> _always_ checked _all_ the time. If you want to say "Ooo! this has a >>> performance hit", fine, but with current systems any such checks are >>> basically in the noise. OTOH, you can annotate a dynamic program with >>> static type information and/or use type inference to remove this issue >>> from most cases. >> >> Jon, >> >> I am trying my best to understand you without knowing Lisp, but I >> don't. This is the second time you explain this, but you are to >> abstract for me. > > I'm not sure which part you are having trouble with. Let's try this > (admittedly somewhat handwavy, but intended to help get the ideas): > > To a reasonable first approximation: > > What is typed? > > Static: Variables and expressions (including literals and variables) Come on, values are untyped? > Dynamic: Values (the things you think of as "in a variable" or as the > result of the evaluation of an expression) > Where/when is the "type"? > > Static: In the compiler's symbol table and semantic analyzer; exists > during compilation. Types do not exist at runtime. To some > extent they are still around at link time in C++ in order for > template instantiation to work. This is wrong. Types exist at run-time and there are operations on types at run-time. In Ada there are view conversions. It is possible to create objects of *unknown* at compile time types. See S'Class'Input attribute for further information. > Important: Types are _not_ first class objects. This was a design choice of Ada. This is not a property of statically typed languages. One can well introduce types of types and have types as their values. Static typing only means that objects of statically known types are checked against this constraint (contract). > Dynamic: In values; exists whenever a value exists - compiletime, > load/link time, and runtime. > > Important: Types _are_ first class objects, i.e., there are > _values_ which are _types_. The types of these value types > are meta types. You contradict yourself. When types are first class objects then types types should be plain types and so, also be first class objects. Whether a feasible type system can be built if everything is a first class object is questionable. Probably one will have problems with Russel's paradox or else some objects will be inconstructible / have undecidable types etc. > You can walk as far up the "logic ladder" as > you want with this. This is another [IMO better] way, where there are firewalls between values (first class objects), types (second class objects), types types (third class objects) etc. Anyway both alternatives have nothing to do with static analysis. When the contract of an object of any class is statically known, it should be checked. The contract of a constant is to have a known value. This is why 2+2 is known to be 4 prior run-time. At least my pocket calculator tells so. (:-)) > "Ontologically" there is no difference (they have the same > fundamental status) between these kinds of values and any > other, e.g., integers, class instances, etc. You can bind > them, query them, create them, if (as in Common Lisp) you have > a meta object protocol (MOP) you can even _change_ them and > _alter_ the behavior of the type system. There is a lot more > here. Is meta object protocol an object? What is the type of the protocol? And finally, is meta object protocol checked? Statically? > What is checked? > > Static: Variables (containers) conform to expressions It is the contracts that are checked. Type checks is to narrow definition of what is checked. > Dynamic: Values conform to operations (functions operators, etc.) Same as above. > When are things checked? > > Static: Mostly at compile time (though there are important exceptions) > > Examples: (Ada) > > x := a; The type of variable A is checked to conform > with the type of variable X, so that X is assured that > whatever the _value_ in A during runtime, it should be a > member of the type of X (conform to it). Wrong, assignement in Ada may raise Constraint_Error at run-time. > x := a + b; the types of A & B are used to select a set of + > operator candidates whose result types are then checked > against the type of X to determine the unique operation (if it > exists) to use. It depends. With multiple dispatch it is the type of x, of a and of b to determine the operations + and :=. Anyway, in Ada if a and b are class-wide, dispatching to + might fail at *run* time. > Generally, there is a good deal of copying of values going on > at runtime. Variables exist only at compile time (though in > C++ there is some level of existence through link), they are > transformed to simply locations with enough space to hold > values of the variables type (as determined at compile > time)[2]. Your theory is wrong: declare X : T'Class := Read_It_From_File (Stream); -- The size of X is unknown till run time > Dynamic: Mostly at runtime (though there are some useful exceptions). > > Examples: (Common Lisp) > > (let ((x a)) ...) the value _bound_ by (named by) A is _bound_ > to X, so that X is also a _name_ for it within the scope of > the let. Unless specifically requested, there are no type > checks being made in these cases since there is no need for it > - since a variable is just a binding (name) for a value it can > be used to name any value. No copying is ever done. You can > change or add a name to a value without opening a new scope by > means of setf, e.g., (setf x a) declare X : T'Class renames Get_It; -- No copying, no specific type known > (let ((x (+ a b))) ...) the standard + operation is generic > (this is more analogous to an Ada function of a class wide > type, than to generics). The dispatch mechanism checks the > types of A and B and either raises an exception if there is no > possible match or performs the operation[2]. No different from Ada's way of dispatching on multiple parameters. BTW, it is actually a drawback of Ada that mutiple dispatch is limited to the cases where types have same tag. > If the operation > is performed, the resulting value is _bound_ to X within the > scope of the let. > > Values are never copied. Variables typically do not exist at > runtime, with the important exception of dynamic variables > (full symbols). Variables are basically transformed into > locations that reference values. This is Lisp's problem. In Ada the programmer has a choice whether the objects should have a by-value or by-reference semantics. Clearly, if you want to put objects in a register, you will be in trouble with Lisp... > Is type consistency enforeced (is it type safe)? > > Static: Mostly. Casts, certain unchecked conversions, overlays can > all subvert this. Unchecked conversion subverts nothing. It is as legal as any other operation. It has the parameter profile, which is *checked*. It takes a value of a distinct type and returns the result of another distinct type. Note, types of the parameter profile tell nothing about the operation semantics. So unchecked conversion is as good as any other. It is not compiler's business to check program semantics. > Dynamic: Yes, values cannot be interpreted as any type other than what > they are. It is again Lisp's problems. Unchecked conversion have their place regardless time and place types are checked. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 17:40 ` Dmitry A. Kazakov @ 2004-09-12 16:02 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-12 16:02 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On 09 Sep 2004 20:47:54 -0400, jayessay wrote: > > > Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > > >> jayessay wrote: > >> ... > >>> First, types are indeed part of program design in dynamic languages. > >>> In some respects they are even more important than in static languages > >>> as they exist at _all_ times: compile load (link) and run. They are > >>> _always_ checked _all_ the time. If you want to say "Ooo! this has a > >>> performance hit", fine, but with current systems any such checks are > >>> basically in the noise. OTOH, you can annotate a dynamic program with > >>> static type information and/or use type inference to remove this issue > >>> from most cases. > >> > >> Jon, > >> > >> I am trying my best to understand you without knowing Lisp, but I > >> don't. This is the second time you explain this, but you are to > >> abstract for me. > > > > I'm not sure which part you are having trouble with. Let's try this > > (admittedly somewhat handwavy, but intended to help get the ideas): > > > > To a reasonable first approximation: > > > > What is typed? > > > > Static: Variables and expressions (including literals and variables) > > Come on, values are untyped? <and a lot more that is not worth bothering with> You are hopeless /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 12:01 ` Dmitry A. Kazakov 2004-09-08 16:26 ` jayessay @ 2004-09-08 19:46 ` Alexander E. Kopilovich 2004-09-09 7:57 ` Dmitry A. Kazakov 2004-09-10 0:53 ` jayessay 1 sibling, 2 replies; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-09-08 19:46 UTC (permalink / raw) To: comp.lang.ada Dmitry A. Kazakov wrote: > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: > > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > > > LD> jayessay wrote: > > LD> ... > > >> Exactly. Actually this sort of development will save you much more > > >> time and money than you could ever hope for from typical static typing. > > > > LD> How could this be? > > LD> With powerful typing you write code. > > LD> Without, you write as much code and much more tests. > > > > You are missing the point. He is not arguing against strong typing, > > but against *static* typing. > > Apparently, but when consistently pursued that kind of argumentation > inevitable leads to arguing against any typing, especially against ADT. The > philosophy behind is that types are random artifacts of the program, rather > than the basis of software design. No, the philosophy behind this is that there is no need for type systems to be always of mainframe kind - comprehensive, complex, requiring distinguished and rare experts for their creation, future development and general maintenance; that there can be custom type systems - with lesser scope, that is, not so universally applicable or useful, but bringing significant advantages in some particular domains and which really can be succesfully created and controlled at reasonable (more common and therefore more accessible) level of expertise. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:46 ` Alexander E. Kopilovich @ 2004-09-09 7:57 ` Dmitry A. Kazakov 2004-09-10 0:53 ` jayessay 1 sibling, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-09 7:57 UTC (permalink / raw) On Wed, 8 Sep 2004 23:46:44 +0400 (MSD), Alexander E. Kopilovich wrote: > Dmitry A. Kazakov wrote: > >> On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: >> >>>>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: >>> >>> LD> jayessay wrote: >>> LD> ... >>> >> Exactly. Actually this sort of development will save you much more >>> >> time and money than you could ever hope for from typical static typing. >>> >>> LD> How could this be? >>> LD> With powerful typing you write code. >>> LD> Without, you write as much code and much more tests. >>> >>> You are missing the point. He is not arguing against strong typing, >>> but against *static* typing. >> >> Apparently, but when consistently pursued that kind of argumentation >> inevitable leads to arguing against any typing, especially against ADT. The >> philosophy behind is that types are random artifacts of the program, rather >> than the basis of software design. > > No, the philosophy behind this is that there is no need for type systems to be > always of mainframe kind - comprehensive, complex, requiring distinguished and > rare experts for their creation, future development and general maintenance; > that there can be custom type systems - with lesser scope, that is, not so > universally applicable or useful, but bringing significant advantages in some > particular domains and which really can be succesfully created and controlled > at reasonable (more common and therefore more accessible) level of expertise. Compare it with: there is no need is universal programming languages - comprehensive, complex etc ... write your own every time you get a new contract. Back in 70's people probably believed in that, largely because the languages were undeveloped. 30 years later, why a custom type system cannot be built on the top of a universal one? P.S. Re-read your answer, isn't it against types? Sure? (:-)) P.P.S. Comprehensive etc type system costs nothing when static. Maintenance etc will be compier guys business! (:-)) -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 19:46 ` Alexander E. Kopilovich 2004-09-09 7:57 ` Dmitry A. Kazakov @ 2004-09-10 0:53 ` jayessay 2004-09-11 19:52 ` Alexander E. Kopilovich 1 sibling, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-10 0:53 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes: > Dmitry A. Kazakov wrote: > > > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: > > > > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > > ... > > > LD> How could this be? > > > LD> With powerful typing you write code. > > > LD> Without, you write as much code and much more tests. > > > > > > You are missing the point. He is not arguing against strong typing, > > > but against *static* typing. > > > > Apparently, but when consistently pursued that kind of argumentation > > inevitable leads to arguing against any typing, especially against ADT. The > > philosophy behind is that types are random artifacts of the program, rather > > than the basis of software design. > > No, the philosophy behind this is that there is no need for type > systems to be always of mainframe kind - comprehensive, complex, > requiring distinguished and rare experts for their creation, future > development and general maintenance I submit that for good or ill (I believe good) the Common Lisp type system is an example of this sort of characterization. http://www.lispworks.com/reference/HyperSpec/Body/04_.htm /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 0:53 ` jayessay @ 2004-09-11 19:52 ` Alexander E. Kopilovich 2004-09-12 16:36 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-09-11 19:52 UTC (permalink / raw) To: comp.lang.ada jayessay wrote: > "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes: > > > Dmitry A. Kazakov wrote: > > > > > On 08 Sep 2004 10:52:05 +0200, Ole-Hjalmar Kristensen wrote: > > > > > > >>>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > > > ... > > > > LD> How could this be? > > > > LD> With powerful typing you write code. > > > > LD> Without, you write as much code and much more tests. > > > > > > > > You are missing the point. He is not arguing against strong typing, > > > > but against *static* typing. > > > > > > Apparently, but when consistently pursued that kind of argumentation > > > inevitable leads to arguing against any typing, especially against ADT. The > > > philosophy behind is that types are random artifacts of the program, rather > > > than the basis of software design. > > > > No, the philosophy behind this is that there is no need for type > > systems to be always of mainframe kind - comprehensive, complex, > > requiring distinguished and rare experts for their creation, future > > development and general maintenance > > I submit that for good or ill (I believe good) the Common Lisp type > system is an example of this sort of characterization. This is certainly OK (and perhaps even necessary) for a general platform, on which various more simple and specifically targeted languages can be built. Development of such domain-specific languages surely require good expertise, but not so advanced and rare as it is needed for development/maintenance of the platform itself. I suppose that you meant languages of that kind in the following passage from your previous message here in comp.lang.ada : (Message-Id: <m3656vfgmf.fsf@rigel.goldenthreadtech.com> Date: 03 Sep 2004 12:43:04 -0400) | ... The second is achieved by crafting a constrained narrowly | focused domain specific language _within_ Lisp, which allows the | programmer to then work at the level of the domain, _both_ | syntactically as well as semantically. This is why Lisp macros | (please don't confuse with any other kind of macro you've come across | before) are such a big deal. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 19:52 ` Alexander E. Kopilovich @ 2004-09-12 16:36 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-12 16:36 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> writes: > jayessay wrote: > > > I submit that for good or ill (I believe good) the Common Lisp type > > system is an example of this sort of characterization. > > This is certainly OK (and perhaps even necessary) for a general > platform, on which various more simple and specifically targeted > languages can be built. Development of such domain-specific > languages surely require good expertise, but not so advanced and > rare as it is needed for development/maintenance of the platform > itself. Yes, I agree with this analysis. > I suppose that you meant languages of that kind in the following > passage from your previous message here in comp.lang.ada : > > (Message-Id: <m3656vfgmf.fsf@rigel.goldenthreadtech.com> > Date: 03 Sep 2004 12:43:04 -0400) > > | ... The second is achieved by crafting a constrained narrowly > | focused domain specific language _within_ Lisp, which allows the > | programmer to then work at the level of the domain, _both_ > | syntactically as well as semantically. This is why Lisp macros > | (please don't confuse with any other kind of macro you've come across > | before) are such a big deal. Generally speaking, yes. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 8:52 ` Ole-Hjalmar Kristensen 2004-09-08 10:20 ` Georg Bauhaus 2004-09-08 12:01 ` Dmitry A. Kazakov @ 2004-09-08 16:08 ` jayessay 2004-09-08 17:29 ` Richard Riehle 2 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-08 16:08 UTC (permalink / raw) Ole-Hjalmar Kristensen writes: > >>>>> "LD" == Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > > LD> jayessay wrote: > LD> ... > >> Exactly. Actually this sort of development will save you much more > >> time and money than you could ever hope for from typical static typing. > > LD> How could this be? > LD> With powerful typing you write code. > LD> Without, you write as much code and much more tests. > > You are missing the point. He is not arguing against strong typing, > but against *static* typing. Yes, you are correct. Dynamic typing is every bit (and in some ways more) strong as static typing. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 16:08 ` jayessay @ 2004-09-08 17:29 ` Richard Riehle 2004-09-08 23:01 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-09-08 17:29 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3n000bv64.fsf@rigel.goldenthreadtech.com... > Yes, you are correct. Dynamic typing is every bit (and in some ways > more) strong as static typing. > There are many kinds of strength. I am wondering whether you are intellectually honest enough to state the weaknesses as well as the strengths of the Lisp approach. For example, in the world of physical engineering, we must acknowledge that steel is endowed with greater tensile strength than concrete, whereas concrete is characterized by greater compression strength. This knowledge leads to designs that combine the corresponding strengths of both concrete and steel in the creation of reinforced concrete beams. There are, admittedly, many benefits from the Lisp dynamic typing model, under some circumstances. There are many disadvantages, under other circumstances, to the static typing model of Ada, C++, and others. Since Ada is more type safe than those others, those disadvantages sometimes are more pronounced. However, there are definite benefits to the static typing model, when it is used intelligently, and those often outweigh the disadvantages. Where do you see the disadvantages of the Lisp dynamic typing approach? Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 17:29 ` Richard Riehle @ 2004-09-08 23:01 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-08 23:01 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > "jayessay" <nospam@foo.com> wrote in message > news:m3n000bv64.fsf@rigel.goldenthreadtech.com... > > > Yes, you are correct. Dynamic typing is every bit (and in some ways > > more) strong as static typing. > > > There are many kinds of strength. The kind I believe that people intend in this context involves the notions of "consistency" and adherence to various "constraints". > I am wondering whether > you are intellectually honest enough to state the weaknesses > as well as the strengths of the Lisp approach. Presumably you mean ^^^^ "dynamic typing" here as that is the context of this subsubthread (which would include many others than Lisp). The weakness in this context is obvious: if you use a _formal_ static type system and your problem can be stated completely in it, you can indeed _prove_ with automated methods various useful properties from the source code. > There are, admittedly, many benefits from the Lisp dynamic > typing model, under some circumstances. There are many > disadvantages, under other circumstances, to the static > typing model of Ada, C++, and others. Since Ada is more > type safe than those others, those disadvantages sometimes > are more pronounced. However, there are definite benefits > to the static typing model, when it is used intelligently, and > those often outweigh the disadvantages. [Aside: I believe that formal type systems like those of Haskell, OCAML, et.al. are much more potent than the informal ones of Ada, C++, Java, etc. Would you agree with this? I ask because one would think that a static typist would want to use the best version of that kind of system available which is not what is available in Ada/Eiffel/... so there must be some other more important reason for using these than the typing they provide] > Where do you see the disadvantages of the Lisp dynamic > typing approach? Compared to Hindley-Milner type systems (as in Haskell, etc.), using type inference, with dynamic typing you lose the ability to prove certain interesting invariants and other properties automatically from the source code. You can augment some dynamic systems with static analysis which can get you some of this (a lot?) of this. But, frankly, I don't know enough about these efforts as I haven't looked at them in enough detail. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 22:01 ` Lionel Draghi 2004-09-08 8:52 ` Ole-Hjalmar Kristensen @ 2004-09-09 1:08 ` Kevin Cline 2004-09-09 1:35 ` Ed Falis ` (2 more replies) 1 sibling, 3 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-09 1:08 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<413e2fbd$0$30586$626a14ce@news.free.fr>... > jayessay wrote: > ... > > Exactly. Actually this sort of development will save you much more > > time and money than you could ever hope for from typical static typing. > > How could this be? > With powerful typing you write code. > Without, you write as much code and much more tests. I code test-first, and the amount of test code is relatively independent of the language. > > Let's compare: > > A : > function Random_Index return Integer; > -- return's a value between 1 and 10 > > B : > type Index is range 1 .. 10; > function Random_Index return Index; > > If considering code and comments, both are of the same length. The first version leaves me wondering if the comment is correct. The second version leaves me wondering if it sometimes throws Constraint_Error. There's no way to verify that A always returns a value from 1 to 10 or to verify that B never throws Constraint_Error without inspecting the function body. I'm also wondering what happens when you write Random_Index + Random_Index ? Or Random_Index * Random_Index ? > On the other hand, in the A version, I need to check the return value on > each call. That's silly. You have to trust functions to satisfy their postconditions. Even in Ada relatively few post-conditions can be handled by type checks. Would you check after every call to Create_Linked_List to make sure that you got an empty list? And then check after every call to Insert_At_Head to make sure that the list hadn't somehow become circular? If you want bounded types in C++ it's easy enough to write a template class: template <int lower_bound, int upper_bound> class bounded { private: int _value; public: operator int { return _value; } explicit bounded(int value): _value(value) { if (value < lower_bound || value > upper_bound) { throw(...); } operator=(int value) { *this = bounded(value); } } } Then your function is: bounded<1,10> random_index() {...} If the spirit moves you, you can even write: template <int lb2, int ub2> bounded<lower_bound+lb2, upper_bound + ub2> operator+(bounded<lb2, ub2> b2) { return _value + b2.value; } Now adding bounded<1,10> to bounded<0,5> gives a result of the proper type: bounded<1,15>. In LISP-y languages, you would just write something like: (defun random-index () (bound 1 10 ... ) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:08 ` Kevin Cline @ 2004-09-09 1:35 ` Ed Falis 2004-09-09 20:11 ` Lionel Draghi 2004-09-09 3:01 ` Georg Bauhaus 2004-09-09 19:58 ` Lionel Draghi 2 siblings, 1 reply; 387+ messages in thread From: Ed Falis @ 2004-09-09 1:35 UTC (permalink / raw) I agree to a good extent with Kevin. I tend to use test-first, assertions (or DbC if available) and static typing to complement each other. And they do. - Ed ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:35 ` Ed Falis @ 2004-09-09 20:11 ` Lionel Draghi 2004-09-11 0:04 ` Kevin Cline 2004-09-12 16:20 ` jayessay 0 siblings, 2 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-09 20:11 UTC (permalink / raw) Ed Falis wrote: > I agree to a good extent with Kevin. I tend to use test-first, > assertions (or DbC if available) and static typing to complement each > other. And they do. Is it really your opinion, Kevin? If yes, I am pleased to see that we fully agree ;-) And you Jon? OK, I suppose it's because of my poor english that I thought you where underestimating type usefulness :-) -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 20:11 ` Lionel Draghi @ 2004-09-11 0:04 ` Kevin Cline 2004-09-11 1:10 ` Ed Falis 2004-09-12 16:20 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-11 0:04 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<4140b906$0$29447$636a15ce@news.free.fr>... > Ed Falis wrote: > > I agree to a good extent with Kevin. I tend to use test-first, > > assertions (or DbC if available) and static typing to complement each > > other. And they do. > > Is it really your opinion, Kevin? I use static typing to do as much as it can do. I'm currently coding in C# and am frustrated because collections are not type-safe so one is constantly downcasting. You have to pay for strong typing without getting the full benefit. In C++ I could go for months without writing any dynamic cast. I used to value it highly, but have recently changed my opinion and value the ability to rapidly switch between coding and testing more highly. > OK, I suppose it's because of my poor english that I thought you where > underestimating type usefulness :-) It's useful, but as implemented in Ada, and to almost the same extent as implemented in C++, it's also expensive. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 0:04 ` Kevin Cline @ 2004-09-11 1:10 ` Ed Falis 0 siblings, 0 replies; 387+ messages in thread From: Ed Falis @ 2004-09-11 1:10 UTC (permalink / raw) On 10 Sep 2004 17:04:39 -0700, Kevin Cline <kevin.cline@gmail.com> wrote: > Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message > news:<4140b906$0$29447$636a15ce@news.free.fr>... >> Ed Falis wrote: >> > I agree to a good extent with Kevin. I tend to use test-first, >> > assertions (or DbC if available) and static typing to complement each >> > other. And they do. >> >> Is it really your opinion, Kevin? Please understand that my first sentence and second were distinct. I did not mean to imply that the second had anything to do with Kevin's preferences other than to validate the use of test-first design as part of my personal approach. - Ed ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 20:11 ` Lionel Draghi 2004-09-11 0:04 ` Kevin Cline @ 2004-09-12 16:20 ` jayessay 2004-09-12 23:25 ` Lionel Draghi ` (2 more replies) 1 sibling, 3 replies; 387+ messages in thread From: jayessay @ 2004-09-12 16:20 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > Ed Falis wrote: > > I agree to a good extent with Kevin. I tend to use test-first, > > assertions (or DbC if available) and static typing to complement > > each other. And they do. > > Is it really your opinion, Kevin? > If yes, I am pleased to see that we fully agree ;-) > > And you Jon? Not exactly, because I don't use much static typing anymore. It just doesn't offer much because it is largely dependent on having all requirements set in concrete (which they almost never are). Have a look at this: http://martinfowler.com/articles/newMethodology.html I think you and many others in this group will get a lot of insight from this article. It is not a perfect description but it has some advantages for this context: 1. It is written by someone who has been there and done that in both the traditional development cycle and some agile methods 2. It is written by someone for whom most people in this group probably have at least some respect. Personally, I think the sort of "agile" method I've been mentioning here is in many ways analogous to developing a theory in mathematics than what happens in "engineering". There is a lot of creative "noodling" that goes into this buttressed by very high levels of rigor, with a very bottom up approach where each definition, proposition, lemma and theorem are incrementally determined and tightly integrated. There are of course many differences, but it at least indicates the very different mind set. > OK, I suppose it's because of my poor english that I thought you > where underestimating type usefulness :-) Not type usefulness, most everyone agrees types are useful, even necessary. It is _static_ typing that is of questionable usefulness in any domain that doesn't have clear, well defined requirements (which is to say the vast majority of cases). /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:20 ` jayessay @ 2004-09-12 23:25 ` Lionel Draghi 2004-09-13 10:13 ` Georg Bauhaus 2004-09-15 2:15 ` Alexander E. Kopilovich 2 siblings, 0 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-12 23:25 UTC (permalink / raw) jayessay wrote: ... >>>I agree to a good extent with Kevin. I tend to use test-first, >>>assertions (or DbC if available) and static typing to complement >>>each other. And they do. >> >>Is it really your opinion, Kevin? ... >>And you Jon? > Not exactly, because I don't use much static typing anymore. It just > doesn't offer much because it is largely dependent on having all > requirements set in concrete (which they almost never are). We have several thousand types comming from norm or standard that are perfectly stable. (I am in the communication field). But anyway that's not important: 1 - lot's of type just come from the design, not directly from requirements. So YOU are in charge of defining those. 2 - not having the range or other details is not an excuse no to create a specific type, as I illustrated in another mail. > Have a look at this: > http://martinfowler.com/articles/newMethodology.html I will. ... > > Not type usefulness, most everyone agrees types are useful, even > necessary. It is _static_ typing that is of questionable usefulness > in any domain that doesn't have clear, well defined requirements > (which is to say the vast majority of cases). Questionable, yes, always. But we clearly won't agree on the answer, so I suppose it's time for me to leave this thread. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:20 ` jayessay 2004-09-12 23:25 ` Lionel Draghi @ 2004-09-13 10:13 ` Georg Bauhaus 2004-09-13 21:29 ` jayessay 2004-09-15 2:15 ` Alexander E. Kopilovich 2 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 10:13 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : It is _static_ typing that is of questionable usefulness : in any domain that doesn't have clear, well defined requirements I wish you had stated this so very clearly much earlier. :-) : (which is to say the vast majority of cases). Is it the vast majority of cases involving actual money where there are no well defined requirements? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 10:13 ` Georg Bauhaus @ 2004-09-13 21:29 ` jayessay 2004-09-14 9:15 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-13 21:29 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > > : It is _static_ typing that is of questionable usefulness > : in any domain that doesn't have clear, well defined requirements > > I wish you had stated this so very clearly much earlier. :-) I did. Several times. Perhaps you missed those? > : (which is to say the vast majority of cases). > > Is it the vast majority of cases involving actual money where > there are no well defined requirements? Yes. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 21:29 ` jayessay @ 2004-09-14 9:15 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-14 9:15 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> jayessay <nospam@foo.com> wrote: :> :> : It is _static_ typing that is of questionable usefulness :> : in any domain that doesn't have clear, well defined requirements :> :> I wish you had stated this so very clearly much earlier. :-) : : I did. Several times. Perhaps you missed those? I must have missed them. ... Yes, you mention specifications lacking rigor. OK. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:20 ` jayessay 2004-09-12 23:25 ` Lionel Draghi 2004-09-13 10:13 ` Georg Bauhaus @ 2004-09-15 2:15 ` Alexander E. Kopilovich 2 siblings, 0 replies; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-09-15 2:15 UTC (permalink / raw) To: comp.lang.ada jayessay wrote: > ... I don't use much static typing anymore. It just > doesn't offer much because it is largely dependent on having all >requirements set in concrete (which they almost never are). > >Have a look at this: > >http://martinfowler.com/articles/newMethodology.html Well, personally I have no need to look at any article for acknowledging that in very many (probably majority of) software works the requirements are neither comprehensive nor stable - I know that too well. But your claim - that this is almost always so - is severe exaggeration; there are enough software works where where all requirements are (or at least presumed to be) indeed set in concrete. And Ada language was and is targetted primarily at the domains where the latter is generally true. > Personally, I think the sort of "agile" method I've been mentioning > here is in many ways analogous to developing a theory in mathematics > than what happens in "engineering". There is a lot of creative > "noodling" that goes into this buttressed by very high levels of > rigor, with a very bottom up approach where each definition, > proposition, lemma and theorem are incrementally determined and > tightly integrated. There are of course many differences, but it at > least indicates the very different mind set. I'm just wondering why do you think that this mind set can be successful in long run, when it is adopted without understanding and adoption of rigid requirements and limitations, which are associated with it in mathematics. Apart from that rather subjective notion of mind set, please note that there are two highly important aspects of the difference - *scheduled* reliability and associated immediate risks. All that widely acknowledged reliability of mathematical theories can't be achieved quickly - it is a long way for a theorem to be accepted as proved - that involves many checks by many persons and enough years to wait for a possible discovery of a hidden gap in the proof. Real-world projects these times are usually constrained by economy and competition and therefore can neither wait so much nor allow extensive public reviews. (Note, that besides of really firmly established theories, mathematics - and especially applied mathematics - has also so-called "methods", which quite often aren't reliable - sometimes they lead to a success, but in other cases they fail - and there may be no known way to predict what will happen in a particular case without trying the method... or going into specifics of the case to significant depth, and then using explicit or implicit references to previous experience. No wonder that those generally unreliable, but sometimes effective methods often can be developed much faster that solid theories.) Then, creative imagination do not face immediate real-word risks; therefore one can try to rely upon too fresh proof of some theorem (or upon too bold interpretation) and see what can be built atop of it. If your risks are low - just waste of some time, waste of some (not too much) money - then you may run as a creative programmer; but if your risks are high - immediate loss of lives, severe breach of security, strong and massive negative impact on environment, etc. - then your must run as responsible engineer, strictly limiting immediate impact of your creative imagination. And as usual, there are grey zones - where either both risks and possible gains are substantial or where taking risk in one aspect of the whole matter may significantly decrease risk associated with other aspects. Some would call this a gambling, others would call this a balancing. > Not type usefulness, most everyone agrees types are useful, even > necessary. It is _static_ typing that is of questionable usefulness > in any domain that doesn't have clear, well defined requirements > (which is to say the vast majority of cases). I think that after that rather prolonged arguing about usefulness of dynamic vs. static typing using "field performance" kind of arguments, it is time to try to describe the difference between them in some more general terms. First, for static typing, let's repeat that "Ada is for problem space". That means, that description of problem space is considered as primary strategic goal for Ada language. Static typing is natural thing for such a description - a typed variable is a natural instance of a coordinate in that space. So, the discussion is actually about whether it is generally good to strive for (precise) description of problem space. But what is an alternative? If static typing provides us means for description of problem state, then what does dynamic typing provide? I guess that dynamic typing provides description of "event space", that is, a particular stage of the whole process, on whatever level of the latter. In this sense, with dynamic typing, the variables represent a kind of local coordinates along the process's trajectory (at the process's current state). It also seems to me that there must be some duality between these two kinds of typing; perhaps the pair of universal objects from category theory - product and coproduct (which are dual to each other) - somehow relates to that comparison (where product stands for static typing, and coproduct stands for dynamic typing). Then, static typing, with its capabilities for descrpiption of whole problem state, promotes analytical approach, while dynamic typing, with its concentration on local events (on various levels), promotes synthetic approach. So, if a challenge is the most significant aspect of the job then dynamic typing may bring noticeable advantages; but from the crash investigator's viewpoint, dynamic typing is a horrible thing, and the stricter is static typing - the better: strict static typing will not eliminate crashes, but it will make investigation task much easier (note, that an investigator often must not only discover what causes the crash, but also make someone responsible). Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:08 ` Kevin Cline 2004-09-09 1:35 ` Ed Falis @ 2004-09-09 3:01 ` Georg Bauhaus 2004-09-10 23:56 ` Kevin Cline 2004-09-09 19:58 ` Lionel Draghi 2 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-09 3:01 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : If you want bounded types in C++ it's easy enough to write a template : class: True, but it is not quite the same thing, is it? You can write bounded types in C. Yet, they don't become C language types, with ISO definded semantics beyond what you'd expect for any user defined type. Does the C++ standard directly address the behavior of handwritten bounded numbers? How many lines of template code will it take to get the effect of type A is array(Some_Index_Type) of Foo;? #include <assert.h> struct _bint { long v; int up, lo; }; typedef struct _bint bint; // int with bounds checking static inline void throw_C_overflow() { assert(0); } bint range_checked(bint val) { if (val.lo > val.v || val.v > val.up) throw_C_overflow(); return val; } bint make_bound(int lower, int upper, int val) { return range_checked((bint){ .v = val, .up = upper, .lo = lower }); } bint multiply(bint a, bint b, bint res) { return range_checked((bint){ .v = a.v * b.v, .lo = res.lo, .up = res.up }); } void set(bint* old, int new) { (*old).v = new; range_checked(*old); } int main() { bint x = make_bound(1, 10, 3); // set(&x, 14); // try this to see the effect return multiply(x, x, x).v; } : In LISP-y languages, you would just write something like: : (defun random-index () (bound 1 10 ... ) OTOneH people complain that large C programs mimic half of Lisp. (C being a compiled language with little support for anything.) OTOtherH people suggest that Ada features be implemented in Lisp. (Ada being just a compiled language with a few nice features.) Adjust for C++ and other combinations. Now what? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 3:01 ` Georg Bauhaus @ 2004-09-10 23:56 ` Kevin Cline 2004-09-11 9:50 ` Martin Krischik ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-10 23:56 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : If you want bounded types in C++ it's easy enough to write a template > : class: > > True, but it is not quite the same thing, is it? You can write bounded > types in C. Yet, they don't become C language types, with ISO definded > semantics beyond what you'd expect for any user defined type. The Ada designers evidently thought arrays were really really important, because they provided elaborate language facilities to support array-based programming. The C language designers instead created a small but useful language. Stroustrup didn't spend much effort on arrays, perhaps because he didn't think they were so important. Instead he tried to make it easy to define and use new types as easily as one could use the fundamental types. > Does the C++ standard directly address the behavior of handwritten > bounded numbers? How many lines of template code will it take > to get the effect of > > type A is array(Some_Index_Type) of Foo;? I don't know. It could be done in C++ if Some_Index_Type had the right properties. But as a practical matter, no one seems to care, at least no one in the C++ community. I very rarely have any need or use for a statically sized array. Even if I did want a static array with non-integer indexing, unless it's really important to shave 100 nanoseconds from the lookup time, a map will do just as well, and that's the canonical solution in both C++ and Perl. > #include <assert.h> > > struct _bint { > long v; > int up, lo; > }; This is quite ugly, not to mention inefficient. But I would never advocate use of C for writing an application of any size. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 23:56 ` Kevin Cline @ 2004-09-11 9:50 ` Martin Krischik 2004-09-11 18:09 ` Benjamin Ketcham ` (4 more replies) 2004-09-11 9:59 ` Pascal Obry 2004-09-11 11:44 ` Georg Bauhaus 2 siblings, 5 replies; 387+ messages in thread From: Martin Krischik @ 2004-09-11 9:50 UTC (permalink / raw) Kevin Cline wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message > news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>... >> Kevin Cline <kevin.cline@gmail.com> wrote: >> : If you want bounded types in C++ it's easy enough to write a template >> : class: >> >> True, but it is not quite the same thing, is it? You can write bounded >> types in C. Yet, they don't become C language types, with ISO definded >> semantics beyond what you'd expect for any user defined type. > > The Ada designers evidently thought arrays were really really > important, because they provided elaborate language facilities to > support array-based programming. The C language designers instead > created a small but useful language. K&C was not at all usefull. Almost imediatly "lint" appeared to save you from all the pitfalls C hat. Of corse C has become more usefull But as a result it is not small anymore. The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read. And I am not aware of any compiler which supports the standard in full. > Stroustrup didn't spend much > effort on arrays, perhaps because he didn't think they were so > important. Since I do own the ISO/IEC 9899:1999 I have one to swallow for your (6.7.5.2, Page 117): extern int n; extern int m; void fcompat (void) { int a[n][6][m]; And next page it becomes even cooler: void fvla (int m; int C[m][m]); void fvla (int m; int C[m][m]); { typedef int VLA[m][m]; ... int D[m]; It looks like the C comunity have finaly found out that K&R and Stroustrup have bee wrong and arrays with bounds are important after all. > Instead he tried to make it easy to define and use new > types as easily as one could use the fundamental types. > >> Does the C++ standard directly address the behavior of handwritten >> bounded numbers? How many lines of template code will it take >> to get the effect of >> >> type A is array(Some_Index_Type) of Foo;? > > I don't know. But I do: >wc --lines AdaArray.C AdaArray.H 95 AdaArray.C 467 AdaArray.H 562 insgesamt With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:50 ` Martin Krischik @ 2004-09-11 18:09 ` Benjamin Ketcham 2004-09-11 18:33 ` Georg Bauhaus ` (3 more replies) 2004-09-13 0:48 ` Larry Kilgallen ` (3 subsequent siblings) 4 siblings, 4 replies; 387+ messages in thread From: Benjamin Ketcham @ 2004-09-11 18:09 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote: > >> support array-based programming. The C language designers instead >> created a small but useful language. > > K&C was not at all usefull. Almost imediatly "lint" appeared to save you > from all the pitfalls C hat. K&R C can be criticized on many grounds, but "useful" is not a valid one, IMO. The original C was one of the most "useful" languages we've seen. Witness its rapid spread through academia, and later, industry. Despite all the pitfalls, it was a small and efficient language, which meant easy portability to new platforms as they arose. Along with Unix (also full of pitfalls of course), the language quickly became the first choice for systems programming on almost any CPU: a position it continues to hold today. > Of corse C has become more usefull But as a result it is not small anymore. > The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read. > And I am not aware of any compiler which supports the standard in full. The fact that C99 has not caught on would seem to indicate that the market considers it *less* useful, not more! The de facto industry standard is "C90 plus the common extensions", and there it remains. I guess the C programmers didn't want their language to go down the path of the "RM". Or, they just don't see it as necessary (niche areas like numerical computation being exceptions). "Robust", "type-safe", etc., are not the same thing as "useful". C has many failings, but ya gotta give it credit, it's pretty darn useful. "Better" languages like Ada can only dream of being found so "useful" by a majority of the computing market. Is there an Ada compiler for the Palm Pilot? --Benjamin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 18:09 ` Benjamin Ketcham @ 2004-09-11 18:33 ` Georg Bauhaus 2004-09-12 6:00 ` Benjamin Ketcham 2004-09-12 17:41 ` Martin Krischik 2004-09-12 0:51 ` Larry Kilgallen ` (2 subsequent siblings) 3 siblings, 2 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-11 18:33 UTC (permalink / raw) Benjamin Ketcham <bketcham@drizzle.com> wrote: : : The fact that C99 has not caught on would seem to indicate that : the market considers it *less* useful, not more! The de facto : industry standard is "C90 plus the common extensions", and there it : remains. I guess the C programmers didn't want their language to : go down the path of the "RM". Or, they just don't see it as : necessary (niche areas like numerical computation being exceptions). Maybe C99 is as yet unknown to many C programmers? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 18:33 ` Georg Bauhaus @ 2004-09-12 6:00 ` Benjamin Ketcham 2004-09-12 17:45 ` Martin Krischik 2004-09-12 17:41 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Benjamin Ketcham @ 2004-09-12 6:00 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > Benjamin Ketcham <bketcham@drizzle.com> wrote: > : > : The fact that C99 has not caught on would seem to indicate that > : the market considers it *less* useful, not more! The de facto > : industry standard is "C90 plus the common extensions", and there it > : remains. I guess the C programmers didn't want their language to > : go down the path of the "RM". Or, they just don't see it as > : necessary (niche areas like numerical computation being exceptions). > > Maybe C99 is as yet unknown to many C programmers? Well, I can't speak for the "unwashed masses" of C/C++/Win32 programmers; I wouldn't expect my own experience to necessarily be the same. But *I* am certainly aware of C99; and personally, I haven't met any C programmers who are not aware of C99. With me, it is a conscious choice to remain compatible with C90 wherever possible: i.e., the same considerations that often lead me to choose C over C++ (or Ada). If I *need* the C99 features, then I can try to find a compiler. But frankly, I don't need any of the new features, most of the time, nice though some of them are (or *would be* if anyone implemented them!). The main C99 features that are of general utility, such as "long long", have been available as extensions (though not all implementations are compatible with the C99 syntax). Same for niceties like intermixed declarations and statements, //-comments, etc.. I personally don't need flexible arrays enough to want to break C90 portability, and while the integer types and numerics have been greatly improved and regularized in C99, again I am already used to living without this. C90 is turning out to be a hard act to follow! Just writing a new standard, even a clearly improved standard with the seal of approval of a respected industry organization, doesn't seem to be enough to make people clamour to switch. I don't think many people are using C90 merely because they haven't heard of C99 yet. It's the *compiler vendors* who haven't heard of it... --Benjamin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 6:00 ` Benjamin Ketcham @ 2004-09-12 17:45 ` Martin Krischik 0 siblings, 0 replies; 387+ messages in thread From: Martin Krischik @ 2004-09-12 17:45 UTC (permalink / raw) Benjamin Ketcham wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: >> Benjamin Ketcham <bketcham@drizzle.com> wrote: >> : >> : The fact that C99 has not caught on would seem to indicate that >> : the market considers it *less* useful, not more! The de facto >> : industry standard is "C90 plus the common extensions", and there it >> : remains. I guess the C programmers didn't want their language to >> : go down the path of the "RM". Or, they just don't see it as >> : necessary (niche areas like numerical computation being exceptions). >> >> Maybe C99 is as yet unknown to many C programmers? > > Well, I can't speak for the "unwashed masses" of C/C++/Win32 programmers; > I wouldn't expect my own experience to necessarily be the same. But *I* > am certainly aware of C99; and personally, I haven't met any C programmers > who are not aware of C99. Being aware is one thing, but do they actually know what is inside? With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 18:33 ` Georg Bauhaus 2004-09-12 6:00 ` Benjamin Ketcham @ 2004-09-12 17:41 ` Martin Krischik 2004-09-13 0:30 ` Hyman Rosen 2004-09-13 6:06 ` Kevin Cline 1 sibling, 2 replies; 387+ messages in thread From: Martin Krischik @ 2004-09-12 17:41 UTC (permalink / raw) Georg Bauhaus wrote: > Benjamin Ketcham <bketcham@drizzle.com> wrote: > : > : The fact that C99 has not caught on would seem to indicate that > : the market considers it *less* useful, not more! The de facto > : industry standard is "C90 plus the common extensions", and there it > : remains. I guess the C programmers didn't want their language to > : go down the path of the "RM". Or, they just don't see it as > : necessary (niche areas like numerical computation being exceptions). > > Maybe C99 is as yet unknown to many C programmers? True. I am the only person I know of who spend the $18 to actually buy the standart (both C and C++). I also not aware of anyone who own a pirate copy. I know of a company who has several hundreds of programmers who owns a fully licensed network copy of both the C and C++ standart accesable to everybody there. I have has contracts for 8 years with that company - I know of no one who read only one page of the any of the standarts. The hole mentality of C/C++ programmers is just different. They spend so much time with the a debugger they don't have time to read standards. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 17:41 ` Martin Krischik @ 2004-09-13 0:30 ` Hyman Rosen 2004-09-13 6:06 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 0:30 UTC (permalink / raw) Martin Krischik wrote: > The hole mentality of C/C++ programmers is just different. They spend so > much time with the a debugger they don't have time to read standards. It will probably not surprise you that I own the C and C++ standards, including the 2003 revision of the latter, and refer to them constantly. By the way, did you know that the C++ standard contains a hidden limerick? Look at 14.7.3/7. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 17:41 ` Martin Krischik 2004-09-13 0:30 ` Hyman Rosen @ 2004-09-13 6:06 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-13 6:06 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1153993.mxNGp3fqa3@linux1.krischik.com>... > The hole mentality of C/C++ programmers is just different. They spend so > much time with the a debugger they don't have time to read standards. I have read the C++ standard almost entirely. But it's true, aficionados of niche languages are better read than the average developer. Average developers learn about one language in school, usually the most popular language of the time. Then they find a position working in that language, and don't learn another until forced to by the market. Great developers know a lot of languages, and pick one appropriate for the job. Still, not many of them seem to be picking Ada. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 18:09 ` Benjamin Ketcham 2004-09-11 18:33 ` Georg Bauhaus @ 2004-09-12 0:51 ` Larry Kilgallen 2004-09-12 6:05 ` Benjamin Ketcham ` (2 more replies) 2004-09-12 13:02 ` Larry Kilgallen [not found] ` <zi1oZiVz9I4A@eisner.encoOrganization: LJK Software <UHjU2NulgeUs@eisner.encompasserve.org> 3 siblings, 3 replies; 387+ messages in thread From: Larry Kilgallen @ 2004-09-12 0:51 UTC (permalink / raw) In article <1094926196.802462@yasure>, Benjamin Ketcham <bketcham@drizzle.com> writes: > K&R C can be criticized on many grounds, but "useful" is not > a valid one, IMO. The original C was one of the most "useful" > languages we've seen. Witness its rapid spread through > academia, That was because of the low cost of the Unix/C combination to academia. > and later, industry. That was because of the supply of academia-trained people accustomed to C. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 0:51 ` Larry Kilgallen @ 2004-09-12 6:05 ` Benjamin Ketcham 2004-09-12 7:52 ` Pascal Obry 2004-09-12 17:17 ` Marius Amado Alves 2 siblings, 0 replies; 387+ messages in thread From: Benjamin Ketcham @ 2004-09-12 6:05 UTC (permalink / raw) Larry Kilgallen <Kilgallen@spamcop.net> wrote: > In article <1094926196.802462@yasure>, Benjamin Ketcham <bketcham@drizzle.com> writes: > >> K&R C can be criticized on many grounds, but "useful" is not >> a valid one, IMO. The original C was one of the most "useful" >> languages we've seen. Witness its rapid spread through >> academia, > > That was because of the low cost of the Unix/C combination to academia. Yes, exactly. Nothing makes a tool useful like *accessibility*. Low cost plus source code equals accessible. >> and later, industry. > > That was because of the supply of academia-trained people accustomed to C. Absolutely. Ye olde positive feedback, aka snowball effect (as opposed to SNOBOL). Tools that are more useful, get used more, therefore more people end up knowing how to use them, and of course a large user base only makes the tool... yes, more useful. OK, I think the horse is dead. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 0:51 ` Larry Kilgallen 2004-09-12 6:05 ` Benjamin Ketcham @ 2004-09-12 7:52 ` Pascal Obry 2004-09-12 17:17 ` Marius Amado Alves 2 siblings, 0 replies; 387+ messages in thread From: Pascal Obry @ 2004-09-12 7:52 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > That was because of the low cost of the Unix/C combination to academia. Wasn't this also because it was quite better than the assembler ? Was there many other choices ? Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 0:51 ` Larry Kilgallen 2004-09-12 6:05 ` Benjamin Ketcham 2004-09-12 7:52 ` Pascal Obry @ 2004-09-12 17:17 ` Marius Amado Alves 2 siblings, 0 replies; 387+ messages in thread From: Marius Amado Alves @ 2004-09-12 17:17 UTC (permalink / raw) To: comp.lang.ada >>K&R C can be criticized on many grounds, but "useful" is not >>a valid one, IMO. The original C was one of the most "useful" >>languages we've seen. Witness its rapid spread through >>academia, > > That was because of the low cost of the Unix/C combination to academia. FWIW, I believe the main factor of C success was (is) the simplicity of its semantics. It equates the machine. For this reason--and this alone--I find C actually very pedagogical. It's very easy to understand C given knowledge of the computer architecture, and vice-versa--and both ways at the same time. And C does not get in the way. (A hand grenade, I know.) /* I remember reading K&R as a tutorial, and loving it, and finding it superior to the few languages I had used (BASIC, Clipper...) and learnt (COBOL) before. This was in the early 1980's. I had no idea of the existence of Ada (or Algol, or Simula, but I knew Pascal, and Prolog) then. There was no Internet. And I was not in any University (not that I believe this would have helped much). If had been thrown Ada in front of me by then I'd probably be a different person today. So I adopted C in the early 1980's, used it professionally, and experienced many problems (no surprise here now). Until I was indeed acquainted with Ada 95 in the mid 1990's, in a postgraduation at FCTUNL. I tried it and experienced orders of magnitude decrease in debbugging time. And increase in correcteness, reliability, etc. So now I'm married to Ada, but C was my first love. */ ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 18:09 ` Benjamin Ketcham 2004-09-11 18:33 ` Georg Bauhaus 2004-09-12 0:51 ` Larry Kilgallen @ 2004-09-12 13:02 ` Larry Kilgallen 2004-09-12 19:05 ` Alexander E. Kopilovich [not found] ` <zi1oZiVz9I4A@eisner.encoOrganization: LJK Software <UHjU2NulgeUs@eisner.encompasserve.org> 3 siblings, 1 reply; 387+ messages in thread From: Larry Kilgallen @ 2004-09-12 13:02 UTC (permalink / raw) In article <u656j9b5t.fsf@obry.org>, Pascal Obry <pascal@obry.org> writes: > > Kilgallen@SpamCop.net (Larry Kilgallen) writes: > >> That was because of the low cost of the Unix/C combination to academia. > > Wasn't this also because it was quite better than the assembler ? Was there > many other choices ? There were _many_ other languages. What distinguished C was economic, drawn not out of generosity but out of US Federal restrictions on the activities of AT&T subsidiary Bell Labs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 13:02 ` Larry Kilgallen @ 2004-09-12 19:05 ` Alexander E. Kopilovich 0 siblings, 0 replies; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-09-12 19:05 UTC (permalink / raw) To: comp.lang.ada Larry Kilgallen wrote: > >> That was because of the low cost of the Unix/C combination to academia. > > > > Wasn't this also because it was quite better than the assembler ? Was there > > many other choices ? > > There were _many_ other languages. What distinguished C was economic, > drawn not out of generosity but out of US Federal restrictions on the > activities of AT&T subsidiary Bell Labs. Well, this explains why many common hindrances weren't applied to C. But this isn't enough for success of such a scale. Some powerful drive, some important internal qualities are necessary for that. And I think, that being far from a fan of C (I really never liked it, although I was forced to use it along with C++ - in last decade perhaps more than any other programming language), I still see those important internal qualities of C. There are two of them: 1) fundamentally sound abstract model, around which the language is built - finite automata; 2) very good balance between various aspects of a practical programming language, including careful placement of the underlying abstract model under the hood of a set of (flavors of) already familiar (to the programming community) constructs; no one of those aspects reached perfection in C, but that was (and is) the balance that determines success for massive and diverse use of general-purpose programming language. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
[parent not found: <zi1oZiVz9I4A@eisner.encoOrganization: LJK Software <UHjU2NulgeUs@eisner.encompasserve.org>]
* Re: ADA Popularity Discussion Request [not found] ` <zi1oZiVz9I4A@eisner.encoOrganization: LJK Software <UHjU2NulgeUs@eisner.encompasserve.org> @ 2004-09-12 21:21 ` Marin David Condic 2004-09-13 7:42 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-09-12 21:21 UTC (permalink / raw) A lesson that ought not go lost on those who wish Ada greater success. Even a flawed and imperfect language can have great success if the economics are right. There may be droves of Ada-haters or Ada-ignorers out there, but if Ada has overwhelming economic advantage, the bean-counters will "tune them up" and get them to "think right" on the subject. So we ought to pay a little less attention to Ada's technical superiority and more to making it economically superior. MDC Larry Kilgallen wrote: > > There were _many_ other languages. What distinguished C was economic, > drawn not out of generosity but out of US Federal restrictions on the > activities of AT&T subsidiary Bell Labs. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 21:21 ` Marin David Condic @ 2004-09-13 7:42 ` Dmitry A. Kazakov 2004-09-15 20:45 ` Marin David Condic 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-13 7:42 UTC (permalink / raw) On Sun, 12 Sep 2004 21:21:16 GMT, Marin David Condic wrote: > A lesson that ought not go lost on those who wish Ada greater success. > Even a flawed and imperfect language can have great success if the > economics are right. But what is the goal, perfection or commercial success? Does one exclude other? Something should be badly wrong with our world, if so... > There may be droves of Ada-haters or Ada-ignorers > out there, but if Ada has overwhelming economic advantage, the > bean-counters will "tune them up" and get them to "think right" on the > subject. So we ought to pay a little less attention to Ada's technical > superiority and more to making it economically superior. Would you like such language? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 7:42 ` Dmitry A. Kazakov @ 2004-09-15 20:45 ` Marin David Condic 2004-09-16 8:03 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Marin David Condic @ 2004-09-15 20:45 UTC (permalink / raw) Where did I say it had to be one way or the other? Is the premise that only lousy products can be commercial successes? I disagree with that. What I suggest is that Ada enthusiasts attempt to understand the *economics* of programming languages and make Ada more attractive from an *economic* perspective. MDC Dmitry A. Kazakov wrote: > On Sun, 12 Sep 2004 21:21:16 GMT, Marin David Condic wrote: > > >>A lesson that ought not go lost on those who wish Ada greater success. >>Even a flawed and imperfect language can have great success if the >>economics are right. > > > But what is the goal, perfection or commercial success? > Does one exclude other? > Something should be badly wrong with our world, if so... > > >>There may be droves of Ada-haters or Ada-ignorers >>out there, but if Ada has overwhelming economic advantage, the >>bean-counters will "tune them up" and get them to "think right" on the >>subject. So we ought to pay a little less attention to Ada's technical >>superiority and more to making it economically superior. > > > Would you like such language? (:-)) > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 20:45 ` Marin David Condic @ 2004-09-16 8:03 ` Dmitry A. Kazakov 2004-09-16 18:45 ` Pascal Obry 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-16 8:03 UTC (permalink / raw) On Wed, 15 Sep 2004 20:45:42 GMT, Marin David Condic wrote: > Where did I say it had to be one way or the other? You didn't. But I have an impression that it is the law of supply and demand. > Is the premise that > only lousy products can be commercial successes? It seems much so. Or better to say, that quality of any kind plays very little role. > I disagree with that. Yes, to keep on use Ada one should indeed disagree... (:-)) > What I suggest is that Ada enthusiasts attempt to understand the > *economics* of programming languages and make Ada more attractive from > an *economic* perspective. You are right. The problem is that all our understanding seems to fall under either: a) everything is perfect we just need $2**10 for an Ada promotion campaign. b) everything is better than perfect, we just need to rewrite STL, AWS, MS-Word in Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 8:03 ` Dmitry A. Kazakov @ 2004-09-16 18:45 ` Pascal Obry 2004-09-17 7:29 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Pascal Obry @ 2004-09-16 18:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > You are right. The problem is that all our understanding seems to fall > under either: a) everything is perfect we just need $2**10 for an Ada > promotion campaign. b) everything is better than perfect, we just need to > rewrite STL, AWS, MS-Word in Ada. Rewrite AWS in Ada ??? I think you meant something else! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 18:45 ` Pascal Obry @ 2004-09-17 7:29 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-17 7:29 UTC (permalink / raw) On 16 Sep 2004 20:45:58 +0200, Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> You are right. The problem is that all our understanding seems to fall >> under either: a) everything is perfect we just need $2**10 for an Ada >> promotion campaign. b) everything is better than perfect, we just need to >> rewrite STL, AWS, MS-Word in Ada. > > Rewrite AWS in Ada ??? I think you meant something else! Amazon Web Services. Should I say GPS? But never mind! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:50 ` Martin Krischik 2004-09-11 18:09 ` Benjamin Ketcham @ 2004-09-13 0:48 ` Larry Kilgallen 2004-09-13 14:25 ` Marius Amado Alves 2004-09-13 5:56 ` Kevin Cline ` (2 subsequent siblings) 4 siblings, 1 reply; 387+ messages in thread From: Larry Kilgallen @ 2004-09-13 0:48 UTC (permalink / raw) In article <mailman.16.1095009448.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes: > >>>K&R C can be criticized on many grounds, but "useful" is not >>>a valid one, IMO. The original C was one of the most "useful" >>>languages we've seen. Witness its rapid spread through >>>academia, >> >> That was because of the low cost of the Unix/C combination to academia. > > FWIW, I believe the main factor of C success was (is) the simplicity of > its semantics. It is certainly no simpler than Bliss, but much more popular. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 0:48 ` Larry Kilgallen @ 2004-09-13 14:25 ` Marius Amado Alves 0 siblings, 0 replies; 387+ messages in thread From: Marius Amado Alves @ 2004-09-13 14:25 UTC (permalink / raw) To: comp.lang.ada >>FWIW, I believe the main factor of C success was (is) the simplicity of >>its semantics. > > It is certainly no simpler than Bliss, but much more popular. C is simpler. At least with respect to compilation. In the success of C vs. Bliss, price also played a role. But I suspect this was tied to the difficulty of making a compiler. (Bliss high, C low.) Ada also suffered from this. Ada 83 at least. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:50 ` Martin Krischik 2004-09-11 18:09 ` Benjamin Ketcham 2004-09-13 0:48 ` Larry Kilgallen @ 2004-09-13 5:56 ` Kevin Cline 2004-09-13 11:49 ` Georg Bauhaus 2004-09-13 14:58 ` Larry Kilgallen [not found] ` <mailman.16.1095009448.390.comp.lang.ada@ada-france.Organization: LJK Software <7+giGppWCdX3@eisner.encompasserve.org> 4 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-13 5:56 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1371289.WCcgO7lass@linux1.krischik.com>... > Kevin Cline wrote: > > > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message > > news:<choh37$8i9$1@a1-hrz.uni-duisburg.de>... > >> Kevin Cline <kevin.cline@gmail.com> wrote: > >> : If you want bounded types in C++ it's easy enough to write a template > >> : class: > >> > >> True, but it is not quite the same thing, is it? You can write bounded > >> types in C. Yet, they don't become C language types, with ISO definded > >> semantics beyond what you'd expect for any user defined type. > > > > The Ada designers evidently thought arrays were really really > > important, because they provided elaborate language facilities to > > support array-based programming. The C language designers instead > > created a small but useful language. > > K&C was not at all usefull. It was far from perfect, but a huge fraction of the applications in use today were written in C. There can be no question that C was useful. > Almost imediatly "lint" appeared to save you > from all the pitfalls C hat. So what? That's like complaining that grep is flawed because it doesn't paginate its output. K&R did not set out to design the ultimate programming language. They designed a language that was useful to their team. AFAIK, C was basically designed to replace PDP-11 assembly language. It did that pretty well, and facilitated the development of the first portable operating system. Then some other people came along and decided that they would like to program in C too, and got the compiler from AT&T. > > Of corse C has become more usefull But as a result it is not small anymore. > The ISO/IEC 9899:1999 is just as big as the RM but mor difficult to read. > And I am not aware of any compiler which supports the standard in full. > > > > Stroustrup didn't spend much > > effort on arrays, perhaps because he didn't think they were so > > important. > > Since I do own the ISO/IEC 9899:1999 I have one to swallow for your > (6.7.5.2, Page 117): > > extern int n; > extern int m; > void fcompat (void) > { > int a[n][6][m]; > > And next page it becomes even cooler: > > void fvla (int m; int C[m][m]); > > void fvla (int m; int C[m][m]); > { > typedef int VLA[m][m]; > ... > int D[m]; > > It looks like the C comunity have finaly found out that K&R and Stroustrup > have bee wrong and arrays with bounds are important after all. I don't program in C anymore, so I haven't paid much attention to the 1999 standard. Almost certainly K&R left out that feature because it means that the offset to local variables in the stack frame is no longer a compile-time constant. > > > Instead he tried to make it easy to define and use new > > types as easily as one could use the fundamental types. > > > >> Does the C++ standard directly address the behavior of handwritten > >> bounded numbers? How many lines of template code will it take > >> to get the effect of > >> > >> type A is array(Some_Index_Type) of Foo;? > > > > I don't know. > > But I do: > > >wc --lines AdaArray.C AdaArray.H > 95 AdaArray.C > 467 AdaArray.H > 562 insgesamt Great. Now, if I ever want an Ada-style array for C++, I know what to look for. I don't care if a feature is built into the compiler or comes from library code. That was a conscious decision by the C++ community -- don't put something in the language if writing a class will do just as well. I expect that most of Ada's features could be implemented as C++ library code. But what do I do when I need the power of C++ templates in Ada? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 5:56 ` Kevin Cline @ 2004-09-13 11:49 ` Georg Bauhaus 2004-09-13 13:30 ` Hyman Rosen ` (2 more replies) 0 siblings, 3 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 11:49 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : I expect that most of Ada's features could be implemented as C++ : library code. Are you saying that one should compare the benefits of ISO standardised languages and feature semantics by referring to which features could be implemented in libraries? What if the Ada fans start talking about what is possible with ASIS (which might render C++ template computing a poor thing)? : But what do I do when I need the power of C++ templates in Ada? It seems that now that the power of C++ templates has been discovered, hardly anyone can live without this power. One might ask how programming problems have been solved in C++ when there was no bag of template tricks? OTOH, given the quality of error messages that compilers issue for template code, why not employ a Lisp style processor that in addition to delivering C++ code also displays error messages that do not need template error message code analysis? :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 11:49 ` Georg Bauhaus @ 2004-09-13 13:30 ` Hyman Rosen 2004-09-14 17:14 ` Kevin Cline 2004-09-14 17:29 ` Kevin Cline 2 siblings, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 13:30 UTC (permalink / raw) Georg Bauhaus wrote: > One might ask how programming problems have been solved in C++ > when there was no bag of template tricks? One way was the old header "generic.h" which was a poor-man's template mechanism, using the preprocessor to interpolate type names into code. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 11:49 ` Georg Bauhaus 2004-09-13 13:30 ` Hyman Rosen @ 2004-09-14 17:14 ` Kevin Cline 2004-09-14 17:29 ` Kevin Cline 2 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-14 17:14 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci41fg$2ge$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > It seems that now that the power of C++ templates has been discovered, > hardly anyone can live without this power. One might ask how programming > problems have been solved in C++ when there was no bag of template > tricks? Templates appeared pretty early in C++, and solved a lot of problems that used to be solved in C with preprocessor macros. Template specialization and template member functions came later. > OTOH, given the quality of error messages that compilers issue for > template code, why not employ a Lisp style processor that in addition > to delivering C++ code also displays error messages that do not need > template error message code analysis? :-) This is indeed a serious problem, and people are working on it. I don't think it's particular to C++ templates. Any interesting facility that generates code will have the same issues to some degree. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 11:49 ` Georg Bauhaus 2004-09-13 13:30 ` Hyman Rosen 2004-09-14 17:14 ` Kevin Cline @ 2004-09-14 17:29 ` Kevin Cline 2 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-14 17:29 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci41fg$2ge$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : I expect that most of Ada's features could be implemented as C++ > : library code. > > Are you saying that one should compare the benefits of ISO > standardised languages and feature semantics by referring to which > features could be implemented in libraries? What if the Ada fans > start talking about what is possible with ASIS (which might render > C++ template computing a poor thing)? They should do that. It might make Ada more popular. I found what appears to be the ASIS home page at http://www. gnat.com/addons_asis.php. It mentions using ASIS to support run-time type reflection, but says nothing about using ASIS for generative programming. That seems like a stretch for ASIS, it is basically a hookable Ada parser, but to get better support for generative programming you'll need to extend the language somehow. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:50 ` Martin Krischik ` (2 preceding siblings ...) 2004-09-13 5:56 ` Kevin Cline @ 2004-09-13 14:58 ` Larry Kilgallen 2004-09-13 16:01 ` Marius Amado Alves [not found] ` <mailman.16.1095009448.390.comp.lang.ada@ada-france.Organization: LJK Software <7+giGppWCdX3@eisner.encompasserve.org> 4 siblings, 1 reply; 387+ messages in thread From: Larry Kilgallen @ 2004-09-13 14:58 UTC (permalink / raw) In article <mailman.24.1095085542.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes: >>>FWIW, I believe the main factor of C success was (is) the simplicity of >>>its semantics. >> >> It is certainly no simpler than Bliss, but much more popular. > > C is simpler. At least with respect to compilation. Presuming you mean simplicity of compiler design, that is irrelevant to the belief statement, which was "simplicity of its semantics". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 14:58 ` Larry Kilgallen @ 2004-09-13 16:01 ` Marius Amado Alves 0 siblings, 0 replies; 387+ messages in thread From: Marius Amado Alves @ 2004-09-13 16:01 UTC (permalink / raw) To: comp.lang.ada >>>>FWIW, I believe the main factor of C success was (is) the simplicity of >>>>its semantics. >>>It is certainly no simpler than Bliss, but much more popular. >>C is simpler. At least with respect to compilation. > Presuming you mean simplicity of compiler design, that is irrelevant > to the belief statement, which was "simplicity of its semantics". I meant what I said, simplicity of its semantics. Which has multiple effects. Cognitive, which I discussed in first place. But clearly it has also consequences on compiler development--and pricing. Which I discussed secondly, simply because it occurred to me while investigating whether Bliss was as simple as C, as (incorrectly) stated. ^ permalink raw reply [flat|nested] 387+ messages in thread
[parent not found: <mailman.16.1095009448.390.comp.lang.ada@ada-france.Organization: LJK Software <7+giGppWCdX3@eisner.encompasserve.org>]
* Re: ADA Popularity Discussion Request [not found] ` <mailman.16.1095009448.390.comp.lang.ada@ada-france.Organization: LJK Software <7+giGppWCdX3@eisner.encompasserve.org> @ 2004-09-14 20:17 ` David Gay 0 siblings, 0 replies; 387+ messages in thread From: David Gay @ 2004-09-14 20:17 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) writes: > In article <mailman.24.1095085542.390.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes: > >>>FWIW, I believe the main factor of C success was (is) the simplicity of > >>>its semantics. > >> > >> It is certainly no simpler than Bliss, but much more popular. > > > > C is simpler. At least with respect to compilation. > > Presuming you mean simplicity of compiler design, that is irrelevant > to the belief statement, which was "simplicity of its semantics". I disagree completely. Without any other information, I would always assume that a language with simpler semantics would have a simpler compiler. Hence, a simpler compiler is a reasonable indicator of simpler semantics. This is, of course, not a direct link, as some semantic concepts might be harder to implement on actual hardware, but claiming there is no link is clearly wrong. -- David Gay dgay@acm.org ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 23:56 ` Kevin Cline 2004-09-11 9:50 ` Martin Krischik @ 2004-09-11 9:59 ` Pascal Obry 2004-09-12 5:32 ` Hyman Rosen 2004-09-14 16:28 ` Kevin Cline 2004-09-11 11:44 ` Georg Bauhaus 2 siblings, 2 replies; 387+ messages in thread From: Pascal Obry @ 2004-09-11 9:59 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > > Does the C++ standard directly address the behavior of handwritten > > bounded numbers? How many lines of template code will it take > > to get the effect of > > > > type A is array(Some_Index_Type) of Foo;? > > I don't know. It could be done in C++ if Some_Index_Type had the > right properties. But as a practical matter, no one seems to care, at > least no one in the C++ community. I very rarely have any need or use > for a statically sized array. That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,-- and so on... Look at some real world C/C++ code handling strings ! For memory, a string in Ada is: type String is array (Positive range <>) of Character; And you can do something like: function Some_Value return String is begin return "..."; end Some_Value; S1 : constant String := "a long string"; S2 : constant String := "this is definitly " & S1 & Some_Value; S3 : constant String := S1 (S1'First + 2 .. S1'First + 5); Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:59 ` Pascal Obry @ 2004-09-12 5:32 ` Hyman Rosen 2004-09-12 7:19 ` Pascal Obry 2004-09-12 7:50 ` Pascal Obry 2004-09-14 16:28 ` Kevin Cline 1 sibling, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-12 5:32 UTC (permalink / raw) Pascal Obry wrote: > That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,-- > and so on... Look at some real world C/C++ code handling strings ! > > For memory, a string in Ada is: > > type String is array (Positive range <>) of Character; > > And you can do something like: > > function Some_Value return String is > begin > return "..."; > end Some_Value; > > S1 : constant String := "a long string"; > S2 : constant String := "this is definitly " & S1 & Some_Value; > > S3 : constant String := S1 (S1'First + 2 .. S1'First + 5); I'm puzzled. Your Ada code translates line-for-line into C++: #include <string> std::string sv() { return "..."; } int main() { std::string const s1("a long string"); std::string const s2("this is definitly " + s1 + sv()); std::string const s3(s1.begin() + 2, s1.begin() + 5 + 1); } Granted that the C++ code is using the equivalent of Ada's unbounded_string, I'd hardly call this a nightmare. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 5:32 ` Hyman Rosen @ 2004-09-12 7:19 ` Pascal Obry 2004-09-13 0:43 ` Hyman Rosen 2004-09-12 7:50 ` Pascal Obry 1 sibling, 1 reply; 387+ messages in thread From: Pascal Obry @ 2004-09-12 7:19 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > > For memory, a string in Ada is: > > type String is array (Positive range <>) of Character; > > And you can do something like: > > function Some_Value return String is > > begin > > return "..."; > > end Some_Value; > > S1 : constant String := "a long string"; > > S2 : constant String := "this is definitly " & S1 & Some_Value; > > S3 : constant String := S1 (S1'First + 2 .. S1'First + 5); > > I'm puzzled. Your Ada code translates line-for-line into C++: That's wrong ! You are using a class/library. We are speaking of the language here ! I find stange that people have a lot of problem separating both. It is true that even in assembler we can build a library to work with string... After all everything is translated into assembler! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 7:19 ` Pascal Obry @ 2004-09-13 0:43 ` Hyman Rosen 2004-09-13 16:40 ` Pascal Obry 0 siblings, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 0:43 UTC (permalink / raw) Pascal Obry wrote: > That's wrong ! You are using a class/library. We are speaking of the > language here ! std::string is part of C++. You said "working with strings in C/C++ is a nightmare...Look at some real world C/C++ code handling strings". I demonstrated that your standard Ada code translates directly into standard C++ code. Now that you see this, you are trying to manipulate your original statements so as to avoid the uncomfortable truth. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 0:43 ` Hyman Rosen @ 2004-09-13 16:40 ` Pascal Obry 2004-09-13 21:19 ` Hyman Rosen 0 siblings, 1 reply; 387+ messages in thread From: Pascal Obry @ 2004-09-13 16:40 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > you are trying to manipulate your original > statements so as to avoid the uncomfortable truth. Certainly not but if you feel like having the final word ! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 16:40 ` Pascal Obry @ 2004-09-13 21:19 ` Hyman Rosen 2004-09-13 21:36 ` Hyman Rosen 2004-09-14 17:27 ` Pascal Obry 0 siblings, 2 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 21:19 UTC (permalink / raw) Pascal Obry wrote: > Certainly not but if you feel like having the final word ! Oops, you're right, I apologize. The context was about arrays in Ada vs. C. It's still meaningful though, that you're code did translate so directly to C++. And Ada users always have trouble with ragged arrays of strings, precisely because of the way arrays work in Ada. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 21:19 ` Hyman Rosen @ 2004-09-13 21:36 ` Hyman Rosen 2004-09-14 17:27 ` Pascal Obry 1 sibling, 0 replies; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 21:36 UTC (permalink / raw) Hyman Rosen wrote: > you're Sigh. "Your", of course. I'm groggy from my root canal pain meds. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 21:19 ` Hyman Rosen 2004-09-13 21:36 ` Hyman Rosen @ 2004-09-14 17:27 ` Pascal Obry 1 sibling, 0 replies; 387+ messages in thread From: Pascal Obry @ 2004-09-14 17:27 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > you're code did translate so directly to C++. And Ada > users always have trouble with ragged arrays of strings, That's right and this is I hope something that will be part of a future standard. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 5:32 ` Hyman Rosen 2004-09-12 7:19 ` Pascal Obry @ 2004-09-12 7:50 ` Pascal Obry 2004-09-12 23:59 ` Brian May 2004-09-13 0:45 ` Hyman Rosen 1 sibling, 2 replies; 387+ messages in thread From: Pascal Obry @ 2004-09-12 7:50 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Granted that the C++ code is using the equivalent of Ada's unbounded_string, And is quite different beast than : type String is array (Positive range <>) of Character; > I'd hardly call this a nightmare. You can't have C++ strings object everyware. A lot of function are built using char* in the spec. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 7:50 ` Pascal Obry @ 2004-09-12 23:59 ` Brian May 2004-09-13 0:45 ` Hyman Rosen 1 sibling, 0 replies; 387+ messages in thread From: Brian May @ 2004-09-12 23:59 UTC (permalink / raw) >>>>> "Pascal" == Pascal Obry <pascal@obry.org> writes: Pascal> You can't have C++ strings object everyware. A lot of Pascal> function are built using char* in the spec. You can always use the string::c_str() function... Actually, I don't know what overheads, if any, that might impose. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 7:50 ` Pascal Obry 2004-09-12 23:59 ` Brian May @ 2004-09-13 0:45 ` Hyman Rosen 2004-09-13 6:19 ` Dale Stanbrough 1 sibling, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 0:45 UTC (permalink / raw) Pascal Obry wrote: > You can't have C++ strings object everyware. A lot of function are built using > char* in the spec. In which case you do your work in std::string or std::stringstream and then obtain a char * from the object and use it. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 0:45 ` Hyman Rosen @ 2004-09-13 6:19 ` Dale Stanbrough 2004-09-13 7:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Dale Stanbrough @ 2004-09-13 6:19 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote: > Pascal Obry wrote: > > You can't have C++ strings object everyware. A lot of function are built > > using > > char* in the spec. > > In which case you do your work in std::string or std::stringstream and then > obtain a char * from the object and use it. Also ACT have equipped a child package of Unbounded_String to return a pointer to the underlying string. This makes C++ and Ada look more alike. Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 6:19 ` Dale Stanbrough @ 2004-09-13 7:50 ` Dmitry A. Kazakov 2004-09-13 13:35 ` Hyman Rosen 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-13 7:50 UTC (permalink / raw) On Mon, 13 Sep 2004 06:19:03 GMT, Dale Stanbrough wrote: > Hyman Rosen <hyrosen@mail.com> wrote: > >> Pascal Obry wrote: >>> You can't have C++ strings object everyware. A lot of function are built >>> using >>> char* in the spec. >> >> In which case you do your work in std::string or std::stringstream and then >> obtain a char * from the object and use it. > > Also ACT have equipped a child package of Unbounded_String to return > a pointer to the underlying string. This makes C++ and Ada look more > alike. ...in their incorrectness -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 7:50 ` Dmitry A. Kazakov @ 2004-09-13 13:35 ` Hyman Rosen 2004-09-13 15:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 13:35 UTC (permalink / raw) Dmitry A. Kazakov wrote: > ...in their incorrectness That's a silly comment. If you must deal with interfaces which take const char *, then using a pointer from a string is a perfectly reasonable approach, letting you use the string mechanisms until the last moment where you actually invoke the interface. It may not be the ideal design that you would choose if starting from scratch, but it is not "incorrect". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 13:35 ` Hyman Rosen @ 2004-09-13 15:39 ` Dmitry A. Kazakov 2004-09-13 15:51 ` Hyman Rosen 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-13 15:39 UTC (permalink / raw) On Mon, 13 Sep 2004 09:35:21 -0400, Hyman Rosen wrote: > Dmitry A. Kazakov wrote: >> ...in their incorrectness > > That's a silly comment. If you must deal with interfaces > which take const char *, then using a pointer from a string > is a perfectly reasonable approach, letting you use the > string mechanisms until the last moment where you actually > invoke the interface. There should be no char* (pointers) at all, that's for C++. For Ada, all string types should be related types. > It may not be the ideal design that > you would choose if starting from scratch, but it is not > "incorrect". OK, I take this word back. Read it as "utter imperfectness"! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 15:39 ` Dmitry A. Kazakov @ 2004-09-13 15:51 ` Hyman Rosen 2004-09-14 8:32 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Hyman Rosen @ 2004-09-13 15:51 UTC (permalink / raw) Dmitry A. Kazakov wrote: > There should be no char* (pointers) at all, that's for C++. For Ada, all > string types should be related types. I assume that the pointer thing in Ada was added so that Ada code could more easily access C/C++ interfaces which want char *. You might still want pointers in Ada so you can do ragged string arrays, like the C char *x[] = { "1", "12", "123" }; ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 15:51 ` Hyman Rosen @ 2004-09-14 8:32 ` Dmitry A. Kazakov 2004-09-14 9:07 ` Georg Bauhaus 2004-09-14 20:35 ` Pascal Obry 0 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-14 8:32 UTC (permalink / raw) On Mon, 13 Sep 2004 11:51:05 -0400, Hyman Rosen wrote: > Dmitry A. Kazakov wrote: >> There should be no char* (pointers) at all, that's for C++. For Ada, all >> string types should be related types. > > I assume that the pointer thing in Ada was added so that Ada code could > more easily access C/C++ interfaces which want char *. Then that should be Interfaces.C.Strings.chars_ptr. I suppose that the intention was a kind of ersatz to To_String. > You might still > want pointers in Ada so you can do ragged string arrays, like the C > char *x[] = { "1", "12", "123" }; This is why I wrote about incorrectness. IF Ada's strings were designed as a set of related types, then "..." literals could be ones of/convertible to Unbounded_String and so an initialized ragged array would be no problem, instead of horrific: type Ragged is array (Integer range <>) of Unbounded_String; X : constant Ragged := ( To_Unbounded_String ("1"), To_Unbounded_String ("12"), To_Unbounded_String ("13") ); Pascal's lessons still to be learned. Bounds, whatever static, bound or dynamic should not be a part of the string type! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 8:32 ` Dmitry A. Kazakov @ 2004-09-14 9:07 ` Georg Bauhaus 2004-09-14 14:04 ` Dmitry A. Kazakov 2004-09-16 4:29 ` Kevin Cline 2004-09-14 20:35 ` Pascal Obry 1 sibling, 2 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-14 9:07 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : This is why I wrote about incorrectness. IF Ada's strings were designed as : a set of related types, then "..." literals could be ones of/convertible to : Unbounded_String and so an initialized ragged array would be no problem, : instead of horrific: : : type Ragged is array (Integer range <>) of Unbounded_String; : X : constant Ragged := : ( To_Unbounded_String ("1"), : To_Unbounded_String ("12"), : To_Unbounded_String ("13") : ); Is it really a good idea to sprinkle source code with unnamed string values? (No matter in what language.) If all of them are isolated in some module(s), where's the problem. Is it an aesthetical problem to have to use Ada's verbosity with strings? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 9:07 ` Georg Bauhaus @ 2004-09-14 14:04 ` Dmitry A. Kazakov 2004-09-14 15:57 ` Georg Bauhaus 2004-09-16 4:29 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-14 14:04 UTC (permalink / raw) On Tue, 14 Sep 2004 09:07:18 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: This is why I wrote about incorrectness. IF Ada's strings were designed as >: a set of related types, then "..." literals could be ones of/convertible to >: Unbounded_String and so an initialized ragged array would be no problem, >: instead of horrific: >: >: type Ragged is array (Integer range <>) of Unbounded_String; >: X : constant Ragged := >: ( To_Unbounded_String ("1"), >: To_Unbounded_String ("12"), >: To_Unbounded_String ("13") >: ); > > Is it really a good idea to sprinkle source code with unnamed > string values? It is a bad idea (provided that these values do not represent themselves.) There is no difference to numeric literals with that respect. Yes, magic constants are bad, but that by no means imply that universal integer should to be removed and for each custom integer type we should write X : My_Int := My_Int (1); > (No matter in what language.) If all of them are > isolated in some module(s), where's the problem. The problem is a geometric explosion of interfaces in cases like: procedure Connect (DB : in out Data_Base; Server, Name, Password : String); Now you have 3 string parameters each of them can separately be: String, Wide_String, Unbounded.Unbounded_String, Wide_Unbounded.Unbounded_String. For the user point of view, what is the difference between String and Unbounded_String to require explicit conversions between them? Isn't it an implementation detail? > Is it an > aesthetical problem to have to use Ada's verbosity with strings? With strings it becomes compelling. The problem is fundamental, Ada's support of interface implementation is very rudimental. You cannot define the interface of abstract characters and then the interface of an abstract array of abstract characters. String, Unbounded_String, Wide_String etc are just implementations of that interface. They should be just subtypes of a Universal_String. And what will we do when Wide_Wide_String come? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 14:04 ` Dmitry A. Kazakov @ 2004-09-14 15:57 ` Georg Bauhaus 2004-09-15 8:29 ` Dmitry A. Kazakov 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-14 15:57 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :> (No matter in what language.) If all of them are :> isolated in some module(s), where's the problem. : : The problem is a geometric explosion of interfaces in cases like: : : procedure Connect : (DB : in out Data_Base; Server, Name, Password : String); This is very much a procedure doing I/O. You cannot expect this to work at an abstract level without hiding the outside world, can you? And on the other hand, you have to serve the outside world what it is expecting. If you use String values for the network database connection credentials, what will be the interpretation of of a Character value with 'pos > 127? UTF-8? ISO-8859-1? Are you connecting to DB2 on a mainframe? To what extent is switching back and forth between Standard.String and (Un)Bounded strings a problem? Where does it happen? Locally? At I/O boundaries? If you store strings in one internal representation in your program how many parameter profile variants will there be? Would you also want a polymorhpic number type with automagic conversion? : For the user point of view, what is the difference between String and : Unbounded_String to require explicit conversions between them? Isn't it an : implementation detail? The difference is the same as the difference between an array of fixed size and a list. I guess that humans are more accustomed to character lists than to something_else lists. Have you recently read any complaints about fixed size arrays of something_else in Ada? :> Is it an :> aesthetical problem to have to use Ada's verbosity with strings? : : With strings it becomes compelling. The problem is fundamental, Ada's : support of interface implementation is very rudimental. You cannot define : the interface of abstract characters and then the interface of an abstract : array of abstract characters. Where would these abstract interfaces be useful? Do you want to code convenient string conversion automagic to overcome notions of what an array of characters is, in Ada? :-) : And what will we do when Wide_Wide_String come? Use it. When string memory and 32 bit instructions instead of 8 bit instructions is no concern, use it everywhere. :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 15:57 ` Georg Bauhaus @ 2004-09-15 8:29 ` Dmitry A. Kazakov 2004-09-15 9:30 ` Martin Dowie 2004-09-15 10:14 ` Martin Krischik 0 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-15 8:29 UTC (permalink / raw) On Tue, 14 Sep 2004 15:57:21 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >:> (No matter in what language.) If all of them are >:> isolated in some module(s), where's the problem. >: >: The problem is a geometric explosion of interfaces in cases like: >: >: procedure Connect >: (DB : in out Data_Base; Server, Name, Password : String); > > This is very much a procedure doing I/O. You cannot expect this to > work at an abstract level without hiding the outside world, can > you? And on the other hand, you have to serve the outside world > what it is expecting. If you use String values for the network > database connection credentials, what will be the interpretation > of of a Character value with 'pos > 127? UTF-8? ISO-8859-1? Are > you connecting to DB2 on a mainframe? Constraint_Error, if the data base cannot UNICODE. It is no different from: procedure Foo (X : Positive); ... Foo (-1); Positive is a subtype of Integer. Integer is a "subtype" of Universal_Integer. Conversion from the base to its subtype may raise Constraint_Error. Wide_Character and Character are related in exactly same manner as Integer and Positive. > To what extent is switching back and forth between Standard.String > and (Un)Bounded strings a problem? Where does it happen? Locally? > At I/O boundaries? If you store strings in one internal representation > in your program how many parameter profile variants will there be? Look at Ada.Strings it is an example of how it explodes. Now consider, that some day Ada will have a comprehensive library for building GUIs, text processing, interfacing data bases etc. Should this library use: String, Unbounded_String, Wide_String ...? Should it be generic, parametrized by a string type. Which is BTW impossible too, because even at the level of generics the least common ancestor of all Ada string types is "type Duno is private"; So you have to specify all methods you might need in the library a formal parameters! > Would you also want a polymorhpic number type with automagic > conversion? It *IS* polymorphic. All numeric literals are overloaded [=statically polymorphic.] But you probably meant other thing, which I will answer. It seems that you are mixing types and subtypes. [IMO Ada's syntax of extensible [tagged] types is quite misleading in that respect. They are in fact subtypes, not distinct types.] Different predefined string types should be subtypes, not unrelated types. It is exactly the same case as Integer, Positive and Natural. That by no means prevents us from creating distinct string types when we need it. Compare: type My_Int is new Integer; -- This a new type X : My_Int := Positive'(1); -- This an error! Y : Integer := Positive'(1); -- This is OK! Strings should work in exactly same way: type My_String is new Unbounded_String; -- This a new type X : My_String := String'("A"); -- This is illegal Y : Unbounded_String := String'("A"); -- This should be legal >: For the user point of view, what is the difference between String and >: Unbounded_String to require explicit conversions between them? Isn't it an >: implementation detail? > > The difference is the same as the difference between an array > of fixed size and a list. I guess that humans are more accustomed > to character lists than to something_else lists. Have you recently > read any complaints about fixed size arrays of something_else in > Ada? But all that is irrelevant for a user. What is important to him is the interface: I can get an element by index, I can get a slice, I can concatenate etc. How the compiler/library does the trick is interesting only out of curiosity or when the performance is a big issue. >:> Is it an >:> aesthetical problem to have to use Ada's verbosity with strings? >: >: With strings it becomes compelling. The problem is fundamental, Ada's >: support of interface implementation is very rudimental. You cannot define >: the interface of abstract characters and then the interface of an abstract >: array of abstract characters. > > Where would these abstract interfaces be useful? For developing class-wide/generic libraries. > Do you want to code convenient string conversion automagic to overcome > notions of what an array of characters is, in Ada? :-) Yes. It is a way to have it. Type conversions A->B applied automatically, promote B as subtype of A. I do not propose to do it in that chaotic PL/1 or limited C++ way. It should be Ada's way. >: And what will we do when Wide_Wide_String come? > > Use it. When string memory and 32 bit instructions instead of > 8 bit instructions is no concern, use it everywhere. :-) I do not want rain forests to disappear because of a need to print a dozen copies of ARM 2050! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 8:29 ` Dmitry A. Kazakov @ 2004-09-15 9:30 ` Martin Dowie 2004-09-15 10:05 ` Dmitry A. Kazakov 2004-09-15 10:14 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Martin Dowie @ 2004-09-15 9:30 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Positive is a subtype of Integer. Integer is a "subtype" of > Universal_Integer. Conversion from the base to its subtype may raise > Constraint_Error. Wide_Character and Character are related in exactly > same manner as Integer and Positive. Why do you say that? Positive is defined in package "Standard" as a subtype. Wide_Character and Character are defined in package "Standard" as difference "type"-s. -- Martin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 9:30 ` Martin Dowie @ 2004-09-15 10:05 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-15 10:05 UTC (permalink / raw) On Wed, 15 Sep 2004 10:30:00 +0100, Martin Dowie wrote: > Dmitry A. Kazakov wrote: >> Positive is a subtype of Integer. Integer is a "subtype" of >> Universal_Integer. Conversion from the base to its subtype may raise >> Constraint_Error. Wide_Character and Character are related in exactly >> same manner as Integer and Positive. > > Why do you say that? Positive is defined in package "Standard" as a subtype. > Wide_Character and Character are defined in package "Standard" as difference > "type"-s. Yes, that is my point. It is illogical that they are declared as unrelated types. One should be a subtype of another. Semantically there is no difference. Clearly there is a huge technical difference, because Ada 83 requires same representations for S, T and T'Base. Once this limitation lifted it will be possible either to extend Character enumeration to Wide_Character, or to constrain Wide_Character to Character, keeping their T'Size different. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 8:29 ` Dmitry A. Kazakov 2004-09-15 9:30 ` Martin Dowie @ 2004-09-15 10:14 ` Martin Krischik 2004-09-15 12:50 ` Dmitry A. Kazakov 1 sibling, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-09-15 10:14 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Should it be generic, parametrized by a > string type. Which is BTW impossible too, because even at the level of > generics the least common ancestor of all Ada string types is "type Duno > is private"; I think you have not worked enough with generics. generic type Character_Type is (<>); type String_Type is array (Positive range <>) of Character_Type; package Some_Generic_String_Operations But there is a problem of course: Unbounded_String is not a generic instantiation. It really should have been: package Unbounded_String is new Generic_Unbounded_String ( Character_Type => Character, String_Type => String); package Wide_Unbounded_String is new Generic_Unbounded_String ( Character_Type => Wide_Character, String_Type => Wide_String); And sadly it is to late for that. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 10:14 ` Martin Krischik @ 2004-09-15 12:50 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-15 12:50 UTC (permalink / raw) On Wed, 15 Sep 2004 12:14:31 +0200, Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> Should it be generic, parametrized by a >> string type. Which is BTW impossible too, because even at the level of >> generics the least common ancestor of all Ada string types is "type Duno >> is private"; > > I think you have not worked enough with generics. > > generic > > type Character_Type is (<>); > > type String_Type is array (Positive range <>) of Character_Type; > > package Some_Generic_String_Operations > > But there is a problem of course: Unbounded_String is not a generic > instantiation. It really should have been: > > package Unbounded_String > is new Generic_Unbounded_String ( > Character_Type => Character, > String_Type => String); > > package Wide_Unbounded_String > is new Generic_Unbounded_String ( > Character_Type => Wide_Character, > String_Type => Wide_String); They couldn't do it, because of ranges/slices/attributes. They are not first class citizens, alas. Then it could be: generic -- This is not Ada! type Index_Type is (<>); type Index_Range_Type is range of Index_Type; type Element_Type is private; type Array_Type is array (Index_Type range Index_Range_Type) of Element_Type; package Abstract_Array is ... Anyway, an equivalent, but more straightforward way is just to make Unbounded_String matching type String_Type is array (Positive range <>) of Character_Type; Once, you solved the problem of wired slices and attributes, the rest will be easy. > And sadly it is to late for that. Not at all. Solve the above and add supertypes. That will do the trick. You create a common array ancestor *afterwards* and everybody is happy. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 9:07 ` Georg Bauhaus 2004-09-14 14:04 ` Dmitry A. Kazakov @ 2004-09-16 4:29 ` Kevin Cline 2004-09-16 7:38 ` Martin Krischik 2004-09-16 8:01 ` Jean-Pierre Rosen 1 sibling, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-16 4:29 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ci6cc6$9br$2@a1-hrz.uni-duisburg.de>... > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > : This is why I wrote about incorrectness. IF Ada's strings were designed as > : a set of related types, then "..." literals could be ones of/convertible to > : Unbounded_String and so an initialized ragged array would be no problem, > : instead of horrific: > : > : type Ragged is array (Integer range <>) of Unbounded_String; > : X : constant Ragged := > : ( To_Unbounded_String ("1"), > : To_Unbounded_String ("12"), > : To_Unbounded_String ("13") > : ); > > Is it really a good idea to sprinkle source code with unnamed > string values? (No matter in what language.) If all of them are > isolated in some module(s), where's the problem. Is it an > aesthetical problem to have to use Ada's verbosity with strings? It is a bit of a problem. Just like natural language composition, there's a fine line between too brief, too verbose, and just right. In the table above, the interesting parts are X and "1", "12", and "123". The three repetitions of To_Unbounded_String take up most of the text while saying nothing of interest, and could be left out if Ada supported implicit conversions at all. Perhaps Ada's prohibition of implicit conversions was a reaction to the problems they caused in FORTRAN and C programming. No doubt that FORTRAN and C got implicit conversions mostly wrong, but that doesn't mean that they are always bad. It's pretty obvious what it means to convert "1" to an unbounded string. BTW, the code above will also use memory inefficiently since there will be two copies of each string, one constant and one unbounded. C++ is as bad or worse if you want to initialize a vector<std::string>, but is better if you are OK with: char const * const x[] = { "1", "12", "123" }; ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 4:29 ` Kevin Cline @ 2004-09-16 7:38 ` Martin Krischik 2004-09-16 18:45 ` Georg Bauhaus 2004-09-16 8:01 ` Jean-Pierre Rosen 1 sibling, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-09-16 7:38 UTC (permalink / raw) Kevin Cline wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message > news:<ci6cc6$9br$2@a1-hrz.uni-duisburg.de>... >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> : This is why I wrote about incorrectness. IF Ada's strings were designed >> : as a set of related types, then "..." literals could be ones >> : of/convertible to Unbounded_String and so an initialized ragged array >> : would be no problem, instead of horrific: >> : >> : type Ragged is array (Integer range <>) of Unbounded_String; >> : X : constant Ragged := >> : ( To_Unbounded_String ("1"), >> : To_Unbounded_String ("12"), >> : To_Unbounded_String ("13") >> : ); >> >> Is it really a good idea to sprinkle source code with unnamed >> string values? (No matter in what language.) If all of them are >> isolated in some module(s), where's the problem. Is it an >> aesthetical problem to have to use Ada's verbosity with strings? > BTW, the code above will also use memory inefficiently since there > will be two copies of each string, one constant and one unbounded. Now that you say it: True. Mind you, if space is a problem, you can always do it the C way: String_1 : aliased String = "1"; String_12 : aliased String = "12"; String_13 : aliased String = "13"; type String_Access is access all String; type Ragged is array (Integer range <>) of String_Access; X : constant Ragged := ( String_1'Access, String_12'Access, String_13'Access ); Of corse, it does not win a price with being compact code - but it does work with contrained records as well. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 7:38 ` Martin Krischik @ 2004-09-16 18:45 ` Georg Bauhaus 2004-09-17 5:58 ` Martin Krischik 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-16 18:45 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote: : Now that you say it: True. Mind you, if space is a problem, you can always : do it the C way: : : String_1 : aliased String = "1"; : String_12 : aliased String = "12"; : String_13 : aliased String = "13"; : : type String_Access is access all String; : type Ragged is array (Integer range <>) of String_Access; : X : constant Ragged := : ( String_1'Access, : String_12'Access, : String_13'Access : ); for constants, X: constant Ragged := ( new String'("1"), ... does just as well, the allocations are performed by the compiler, not at run time :-) -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 18:45 ` Georg Bauhaus @ 2004-09-17 5:58 ` Martin Krischik 2004-09-18 16:44 ` Georg Bauhaus 2004-09-20 20:41 ` Randy Brukardt 0 siblings, 2 replies; 387+ messages in thread From: Martin Krischik @ 2004-09-17 5:58 UTC (permalink / raw) Georg Bauhaus wrote: > Martin Krischik <krischik@users.sourceforge.net> wrote: > > : Now that you say it: True. Mind you, if space is a problem, you can > : always do it the C way: > : > : String_1 : aliased String = "1"; > : String_12 : aliased String = "12"; > : String_13 : aliased String = "13"; > : > : type String_Access is access all String; > : type Ragged is array (Integer range <>) of String_Access; > : X : constant Ragged := > : ( String_1'Access, > : String_12'Access, > : String_13'Access > : ); > > for constants, > > X: constant Ragged := > ( new String'("1"), > ... > > does just as well, the allocations are performed by the compiler, > not at run time :-) Really! I did not know that! Where does it say in the RM - or is a compiler dependent optimisation. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-17 5:58 ` Martin Krischik @ 2004-09-18 16:44 ` Georg Bauhaus 2004-09-19 11:22 ` Simon Wright 2004-09-20 20:41 ` Randy Brukardt 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-18 16:44 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote: :> for constants, :> :> X: constant Ragged := :> ( new String'("1"), :> ... :> :> does just as well, the allocations are performed by the compiler, :> not at run time :-) : : Really! I did not know that! Where does it say in the RM - or is a compiler : dependent optimisation. I've found it to be true, and it looks like compatible with "evaluation of an allocator" and elaboration (control, preelaborate?). I don't know whether there is a sentence addressing this directly, maybe the experts can tell? Both ObjectAda and GNAT do this. I don't know whether it is at all possible to intruct ObjectAda not to "preallocate" constant string pointers. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-18 16:44 ` Georg Bauhaus @ 2004-09-19 11:22 ` Simon Wright 2004-09-19 12:22 ` Georg Bauhaus 2004-09-20 7:36 ` Martin Krischik 0 siblings, 2 replies; 387+ messages in thread From: Simon Wright @ 2004-09-19 11:22 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Martin Krischik <krischik@users.sourceforge.net> wrote: > :> for constants, > :> > :> X: constant Ragged := > :> ( new String'("1"), > :> ... > :> > :> does just as well, the allocations are performed by the compiler, > :> not at run time :-) > : > : Really! I did not know that! Where does it say in the RM - or is a compiler > : dependent optimisation. > > I've found it to be true, and it looks like compatible with > "evaluation of an allocator" and elaboration (control, preelaborate?). > I don't know whether there is a sentence addressing this directly, > maybe the experts can tell? > > Both ObjectAda and GNAT do this. I don't know whether it is at > all possible to intruct ObjectAda not to "preallocate" constant > string pointers. This code package New_String is type String_P is access all String; S : constant String_P := new String'("foo!"); end New_String; with 5.02a1, x86 generates code including [...] new_string___elabs: [...] call __gnat_malloc I think you may be remembering package New_String is type String_P is access constant String; Foo : aliased constant String := "foo!"; S : constant String_P := Foo'Access; end New_String; which generates (in its entirety) with -O2 .file "new_string.ads" .globl new_string_E .data .type new_string_E,@object .size new_string_E,1 new_string_E: .byte 0 .globl new_string__foo .align 4 .type new_string__foo,@object .size new_string__foo,12 new_string__foo: .long 1 .long 4 .ascii "foo!" .globl new_string__s .align 8 .type new_string__s,@object .size new_string__s,8 new_string__s: .long new_string__foo+8 .long new_string__foo .ident "GCC: (GNU) 3.2.3" -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-19 11:22 ` Simon Wright @ 2004-09-19 12:22 ` Georg Bauhaus 2004-09-19 18:04 ` Simon Wright 2004-09-20 7:36 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-19 12:22 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> Both ObjectAda and GNAT do this. I don't know whether it is at :> all possible to intruct ObjectAda not to "preallocate" constant :> string pointers. : : This code : : package New_String is : : type String_P is access all String; : S : constant String_P := new String'("foo!"); : : end New_String; If the pointers are to constant strings (I should have stressed this) there is no call to __gnat_malloc. As is type String_P is access constant String; S : constant String_P := new String'("foo!"); -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-19 12:22 ` Georg Bauhaus @ 2004-09-19 18:04 ` Simon Wright 0 siblings, 0 replies; 387+ messages in thread From: Simon Wright @ 2004-09-19 18:04 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > If the pointers are to constant strings (I should have stressed > this) there is no call to __gnat_malloc. As is > > type String_P is access constant String; > S : constant String_P := new String'("foo!"); Wow! Thanks for that! -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-19 11:22 ` Simon Wright 2004-09-19 12:22 ` Georg Bauhaus @ 2004-09-20 7:36 ` Martin Krischik 1 sibling, 0 replies; 387+ messages in thread From: Martin Krischik @ 2004-09-20 7:36 UTC (permalink / raw) Simon Wright wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > >> Martin Krischik <krischik@users.sourceforge.net> wrote: >> :> for constants, >> :> >> :> X: constant Ragged := >> :> ( new String'("1"), >> :> ... >> :> >> :> does just as well, the allocations are performed by the compiler, >> :> not at run time :-) >> : >> : Really! I did not know that! Where does it say in the RM - or is a >> : compiler dependent optimisation. >> >> I've found it to be true, and it looks like compatible with >> "evaluation of an allocator" and elaboration (control, preelaborate?). >> I don't know whether there is a sentence addressing this directly, >> maybe the experts can tell? >> >> Both ObjectAda and GNAT do this. I don't know whether it is at >> all possible to intruct ObjectAda not to "preallocate" constant >> string pointers. > > This code > > package New_String is > > type String_P is access all String; Should it be not "access constant String". With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-17 5:58 ` Martin Krischik 2004-09-18 16:44 ` Georg Bauhaus @ 2004-09-20 20:41 ` Randy Brukardt 2004-09-21 8:11 ` Martin Krischik 1 sibling, 1 reply; 387+ messages in thread From: Randy Brukardt @ 2004-09-20 20:41 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:2177491.OlAk1RxoCA@linux1.krischik.com... > Georg Bauhaus wrote: > > > Martin Krischik <krischik@users.sourceforge.net> wrote: > > > > : Now that you say it: True. Mind you, if space is a problem, you can > > : always do it the C way: > > : > > : String_1 : aliased String = "1"; > > : String_12 : aliased String = "12"; > > : String_13 : aliased String = "13"; > > : > > : type String_Access is access all String; > > : type Ragged is array (Integer range <>) of String_Access; > > : X : constant Ragged := > > : ( String_1'Access, > > : String_12'Access, > > : String_13'Access > > : ); > > > > for constants, > > > > X: constant Ragged := > > ( new String'("1"), > > ... > > > > does just as well, the allocations are performed by the compiler, > > not at run time :-) > > Really! I did not know that! Where does it say in the RM - or is a compiler > dependent optimisation. The standard really couldn't say it; we only define the semantics of the operation, not the exact code that it uses. That said, there was an intention by the Ada 95 design team that this be done, and I think that there is an AARM note to that effect. So it isn't surprises that implementers would make this optimization. (We didn't do it in Janus/Ada, simply because it didn't seem worth the work -- we hadn't seen any real usage of it. If customers had asked for it, we would have done it, of course.) Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-20 20:41 ` Randy Brukardt @ 2004-09-21 8:11 ` Martin Krischik 2004-09-22 20:51 ` Simon Wright 0 siblings, 1 reply; 387+ messages in thread From: Martin Krischik @ 2004-09-21 8:11 UTC (permalink / raw) Randy Brukardt wrote: > "Martin Krischik" <krischik@users.sourceforge.net> wrote in message > news:2177491.OlAk1RxoCA@linux1.krischik.com... >> Georg Bauhaus wrote: >> >> > Martin Krischik <krischik@users.sourceforge.net> wrote: >> > >> > : Now that you say it: True. Mind you, if space is a problem, you can >> > : always do it the C way: >> > : >> > : String_1 : aliased String = "1"; >> > : String_12 : aliased String = "12"; >> > : String_13 : aliased String = "13"; >> > : >> > : type String_Access is access all String; >> > : type Ragged is array (Integer range <>) of String_Access; >> > : X : constant Ragged := >> > : ( String_1'Access, >> > : String_12'Access, >> > : String_13'Access >> > : ); >> > >> > for constants, >> > >> > X: constant Ragged := >> > ( new String'("1"), >> > ... >> > >> > does just as well, the allocations are performed by the compiler, >> > not at run time :-) >> >> Really! I did not know that! Where does it say in the RM - or is a > compiler >> dependent optimisation. > > The standard really couldn't say it; we only define the semantics of the > operation, not the exact code that it uses. That said, there was an > intention by the Ada 95 design team that this be done, Well it is quite hidden. I did a query at ada-comments I got the following very short answer: ----- See 13.11(24): 24. A default (implementation-provided) storage pool for an access-to-constant type should not have overhead to support deallocation of individual objects. ----- Without the query I would neither found nor understand that chapter. Only now I see that if no deallocation is needed than allocation isn't needed either and the "new" can be optimised away. > and I think that > there is an AARM note to that effect. The AARM is even more difficult to read. > So it isn't surprises that > implementers would make this optimization. (We didn't do it in Janus/Ada, > simply because it didn't seem worth the work -- we hadn't seen any real > usage of it. If customers had asked for it, we would have done it, of > course.) It just might be that customers haven't asked for it because customers have not understand what 13.11(24) actually means. It makes ragged arrays just as easy as in C - if I had only known before. You With Rergards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-21 8:11 ` Martin Krischik @ 2004-09-22 20:51 ` Simon Wright 0 siblings, 0 replies; 387+ messages in thread From: Simon Wright @ 2004-09-22 20:51 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: > See 13.11(24): > > 24. A default (implementation-provided) storage pool for an > access-to-constant type should not have overhead to support > deallocation of individual objects. I am always moaning at requirements that specify a mechanism rather than an intention. I don't see why the fact that a type is access-to-constant should eliminate the need for deallocation. There is clearly a difference between P : Constant_String_Access := new String'("p"); and Q : constant Constant_String_Access := new String'("q"); (well, to me anyway). The AARM says 24.a Ramification: Unchecked_Deallocation is not defined for such types. If the access-to-constant type is library-level, then no deallocation (other than at partition completion) will ever be necessary, so if the size needed by an allocator of the type is known at link-time, then the allocation should be performed statically. If, in addition, the initial value of the designated object is known at compile time, the object can be allocated to read-only memory. so the allocation part is there if you look, and that's the major part here. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-16 4:29 ` Kevin Cline 2004-09-16 7:38 ` Martin Krischik @ 2004-09-16 8:01 ` Jean-Pierre Rosen 1 sibling, 0 replies; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-09-16 8:01 UTC (permalink / raw) Kevin Cline a écrit : > It is a bit of a problem. Just like natural language composition, > there's a fine line between too brief, too verbose, and just right. > In the table above, the interesting parts are X and "1", "12", and > "123". The three repetitions of To_Unbounded_String take up most of > the text while saying nothing of interest, and could be left out if > Ada supported implicit conversions at all. Perhaps Ada's prohibition > of implicit conversions was a reaction to the problems they caused in > FORTRAN and C programming. No doubt that FORTRAN and C got implicit > conversions mostly wrong, but that doesn't mean that they are always > bad. It's pretty obvious what it means to convert "1" to an unbounded > string. > True, and that's precisely why the unary "+" is defined (and redefinable) in the language. It provides a convenient way to make conversion functions that are not totally hidden, but do not take too much visibility in the text. At least, that's what I remember Ichbiah used to justify "+". -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 8:32 ` Dmitry A. Kazakov 2004-09-14 9:07 ` Georg Bauhaus @ 2004-09-14 20:35 ` Pascal Obry 2004-09-15 8:29 ` Dmitry A. Kazakov 1 sibling, 1 reply; 387+ messages in thread From: Pascal Obry @ 2004-09-14 20:35 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > type Ragged is array (Integer range <>) of Unbounded_String; > X : constant Ragged := > ( To_Unbounded_String ("1"), > To_Unbounded_String ("12"), > To_Unbounded_String ("13") > ); But of course this would be : function "+" (Str : in String) return Unbounded_String renames To_Unbounded_String; X : constant Ragged := (+"1", +"12", +"13"); I did not say that it is perfect, but yet far better than your example :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 20:35 ` Pascal Obry @ 2004-09-15 8:29 ` Dmitry A. Kazakov 2004-09-16 18:43 ` Pascal Obry 0 siblings, 1 reply; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-15 8:29 UTC (permalink / raw) On 14 Sep 2004 22:35:14 +0200, Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> type Ragged is array (Integer range <>) of Unbounded_String; >> X : constant Ragged := >> ( To_Unbounded_String ("1"), >> To_Unbounded_String ("12"), >> To_Unbounded_String ("13") >> ); > > But of course this would be : > > function "+" (Str : in String) > return Unbounded_String > renames To_Unbounded_String; > > X : constant Ragged := (+"1", +"12", +"13"); > > I did not say that it is perfect, but yet far better than your example :) It is disgusting! (:-)) What goal this "solution" achieves? To save keystrokes? Is it Ada or C++? (:-)) P.S. what would be -"1"? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-15 8:29 ` Dmitry A. Kazakov @ 2004-09-16 18:43 ` Pascal Obry 0 siblings, 0 replies; 387+ messages in thread From: Pascal Obry @ 2004-09-16 18:43 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > > But of course this would be : > > > > function "+" (Str : in String) > > return Unbounded_String > > renames To_Unbounded_String; > > > > X : constant Ragged := (+"1", +"12", +"13"); > > > > I did not say that it is perfect, but yet far better than your example :) > > It is disgusting! (:-)) I know there is a smiley :) But nevertheless... > What goal this "solution" achieves? To save keystrokes? No not only. In this case it makes the code easier to read IMHO. I have (and found this in other piece of code too) often used: function "+" (Str : in String) return Unbounded_String renames To_Unbounded_String; function "-" (Str : in Unbounded_String) return String renames To_String; > Is it Ada or C++? (:-)) Renamings ? Ada definitly :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 9:59 ` Pascal Obry 2004-09-12 5:32 ` Hyman Rosen @ 2004-09-14 16:28 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-14 16:28 UTC (permalink / raw) Pascal Obry <pascal@obry.org> wrote in message news:<uy8jhjfcq.fsf@obry.org>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > > Does the C++ standard directly address the behavior of handwritten > > > bounded numbers? How many lines of template code will it take > > > to get the effect of > > > > > > type A is array(Some_Index_Type) of Foo;? > > > > I don't know. It could be done in C++ if Some_Index_Type had the > > right properties. But as a practical matter, no one seems to care, at > > least no one in the C++ community. I very rarely have any need or use > > for a statically sized array. > > That's why working with strings in C/C++ is a nightmare! strcpy/strcat,++,-- > and so on... Look at some real world C/C++ code handling strings ! > > For memory, a string in Ada is: > > type String is array (Positive range <>) of Character; > > And you can do something like: > > function Some_Value return String is > begin > return "..."; > end Some_Value; > > S1 : constant String := "a long string"; > S2 : constant String := "this is definitly " & S1 & Some_Value; > > S3 : constant String := S1 (S1'First + 2 .. S1'First + 5); > > Pascal. Yes, but that can get really inefficient when you need to build up a string from multiple parts and don't know the final length. You keep returning intermediate strings by value and what should be O(n) code becomes O(n^2). I suppose one could first collect all the parts and then join them, but that's a convoluted way to write string handling code. C++: std::string some_value() { return "..."; } std::string s1("a long string"); std::string s2("this is definitely " + s1 + some_value()); std::string s3(s1.substring(2, 3)); ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-10 23:56 ` Kevin Cline 2004-09-11 9:50 ` Martin Krischik 2004-09-11 9:59 ` Pascal Obry @ 2004-09-11 11:44 ` Georg Bauhaus 2004-09-14 16:50 ` Kevin Cline 2 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-11 11:44 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : I don't know. It could be done in C++ if Some_Index_Type had the : right properties. But as a practical matter, no one seems to care, at : least no one in the C++ community. Could it be an effect of tradition? If C++ had not inherited C arrays, maybe arrays (including dynamically sized) were used more frequently? I guess vector is used for array computation, then? : I very rarely have any need or use : for a statically sized array. If you need _dynamically_ sized arrays you still can have subtypes with bounds determined at run time. I think this can be important. (C99 now has some of it.) Declare the subtypes locally as index types, ranges based on runtime values. Declare dynamically or statically sized arrays in blocks, in functions, wherever. Create corresponding arrays on the stack or on the heap, assign the results ... type Vec is array (Positive range <>) of Natural; -- base type of all "vectors" counting from 1 function make(limit: Positive; init: Natural := 0) return Vec -- a dynamically sized `Vec`, all values set to `init` is subtype Index is Positive range Positive'first .. limit; subtype A is Vec(Index); begin return A'(others => init); end make; x: Vec := make(5); pragma assert(x'first = 1 and x'last = 5); -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 11:44 ` Georg Bauhaus @ 2004-09-14 16:50 ` Kevin Cline 2004-09-14 17:32 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-14 16:50 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chuofo$o96$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > > : I don't know. It could be done in C++ if Some_Index_Type had the > : right properties. But as a practical matter, no one seems to care, at > : least no one in the C++ community. > > Could it be an effect of tradition? If C++ had not inherited C arrays, > maybe arrays (including dynamically sized) were used more frequently? > I guess vector is used for array computation, then? I'm not sure what you mean by "array computation". For mathematical vectors and matrices with dot product and matrix multiplication you would want a template based library, and such libraries do exist. C++ is an excellent language for writing such a library, because template functions can instantiate new types automatically, e.g. template <int M, N, P> matrix<M,P> operator*(const matrix<M,N>& lhs, conat matrix<N,P>& rhs) {...} template <int M> vec<M> trace(const matrix<M,M>& m) { ... } template <int M,N> matrix<M,N> outer_product(const vec<M>& v1, const vec<N>& v2) { ... } Now I can write code like this: matrix<3,5> func(const matrix<3,5>& m1, const matrix<5,3>& m2) { return outer_product(trace(m1*m2), trace(m2*m1)); } You could do the same in Ada, but first you would have to explicitly instantiate the five functions. That gets old really fast. This ground is covered extensively in Scientific and Engineering C++ : An Introduction with Advanced Techniques and Examples by John J. Barton, Lee R. Nackman. > > : I very rarely have any need or use > : for a statically sized array. > > If you need _dynamically_ sized arrays you still can have subtypes with > bounds determined at run time. I think this can be important. (C99 now > has some of it.) Declare the subtypes locally as index types, ranges > based on runtime values. Declare dynamically or statically sized arrays > in blocks, in functions, wherever. Create corresponding arrays on the > stack or on the heap, assign the results ... > > > type Vec is array (Positive range <>) of Natural; > -- base type of all "vectors" counting from 1 > > function make(limit: Positive; init: Natural := 0) return Vec > -- a dynamically sized `Vec`, all values set to `init` > is > subtype Index is Positive range Positive'first .. limit; > subtype A is Vec(Index); > begin > return A'(others => init); > end make; > > x: Vec := make(5); But even though X has a run-time determined size, its size is now fixed. I can neither add or remove elements without creating an entirely new vector. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 16:50 ` Kevin Cline @ 2004-09-14 17:32 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-14 17:32 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : C++ : is an excellent language for writing such a library, No doubt. : because template : functions can instantiate new types automatically, e.g. But that is not the only reason that C++ is an excellent language for writing such a library? : template <int M, N, P> : matrix<M,P> operator*(const matrix<M,N>& lhs, conat matrix<N,P>& : rhs) {...} Note that all the instantiations appear to be there in order to have bounded arrays. I think. It might be an advantage that the ranges are known to match; I guess this is different from what Ada's gives you when the compiler cannot find out at compile time: "Note that errors such as when bounds of arrays do not match raise Constraint_Error by analogy with built-in array operations." (from the AI mentioned below.) : You could do the same in Ada, but first you would have to explicitly : instantiate the five functions. That gets old really fast. I might not have to do the same thing, because Ada arrays and matrices tend to come with their bounds determined when a matrix object is declared and assigned. :-) The latest on Vector and Matrix ops for Ada 200Y is available in http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT?rev=1.17 : This ground is covered extensively in Scientific and Engineering C++ : : An Introduction with Advanced Techniques and Examples by John J. : Barton, Lee R. Nackman. Thanks for the pointer. :> : I very rarely have any need or use :> : for a statically sized array. :> x: Vec := make(5); : : But even though X has a run-time determined size, its size is now : fixed. I can neither add or remove elements without creating an : entirely new vector. Sure. That's a property of the built in arrays. They are not flex arrays. Would you want to change the size of a matrix, too? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:08 ` Kevin Cline 2004-09-09 1:35 ` Ed Falis 2004-09-09 3:01 ` Georg Bauhaus @ 2004-09-09 19:58 ` Lionel Draghi 2004-09-11 0:07 ` Kevin Cline 2 siblings, 1 reply; 387+ messages in thread From: Lionel Draghi @ 2004-09-09 19:58 UTC (permalink / raw) Kevin Cline wrote: ... > I code test-first, and the amount of test code is relatively > independent of the language. OK, because in test-first you write typical use-cases narrowed to the tested component. Tested features are the same whatever is the language. ... > The first version leaves me wondering if the comment is correct. > The second version leaves me wondering if it sometimes throws > Constraint_Error. There's no way to verify that A always returns a > value from 1 to 10 or to verify that B never throws Constraint_Error > without inspecting the function body. I was not discussing about code correctness (althrough the typed version correctness is easier to proof with static analisys tools). The big difference is that the typed version will raise the default obvious as soon as possible, the other not. To reach the same behaviour without typing, you need to do more work. > I'm also wondering what happens when you write Random_Index + > Random_Index ? > Or Random_Index * Random_Index ? Yet another advantage of typing: you wonder about problems that also exist without typing I was not aware of this advantage :-) >>On the other hand, in the A version, I need to check the return value on >>each call. > That's silly. In my simple example, yes. It's much simpler to put some assertion in the code. But once more, there is more code to write without typing. > You have to trust functions to satisfy their > postconditions. I trust the code generated by the compiler to check an assertion or a range, I trust a formal tool that certifies to me that returned value will always be in range, but I don't trust a comment. > Even in Ada relatively few post-conditions can be > handled by type checks. But whatever is the proportion, why would you renonce to this advantage? Typing has no cost, no drawback, only advantages. So, why should we discuss on what typing can't do? Anyway, I enter in this thread because of the claim that typing has much less value than test-first. I still wait for any illustration of this claim. (and I feel that I will wait for a long time) -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 19:58 ` Lionel Draghi @ 2004-09-11 0:07 ` Kevin Cline 2004-09-11 12:06 ` Georg Bauhaus 2004-09-12 16:30 ` jayessay 0 siblings, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-11 0:07 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote in message news:<4140b5cc$0$17701$626a14ce@news.free.fr>... > Kevin Cline wrote: > ... > > I code test-first, and the amount of test code is relatively > > independent of the language. > OK, because in test-first you write typical use-cases > narrowed to the tested component. Tested features are the same whatever > is the language. > > ... > > The first version leaves me wondering if the comment is correct. > > The second version leaves me wondering if it sometimes throws > > Constraint_Error. There's no way to verify that A always returns a > > value from 1 to 10 or to verify that B never throws Constraint_Error > > without inspecting the function body. > I was not discussing about code correctness (althrough the typed version > correctness is easier to proof with static analisys tools). > > The big difference is that the typed version will raise the default > obvious as soon as possible, the other not. To reach the same behaviour > without typing, you need to do more work. > > > I'm also wondering what happens when you write Random_Index + > > Random_Index ? > > Or Random_Index * Random_Index ? > Yet another advantage of typing: you wonder about problems that also > exist without typing > I was not aware of this advantage :-) > > >>On the other hand, in the A version, I need to check the return value on > >>each call. > > > That's silly. > In my simple example, yes. It's much simpler to put some assertion in > the code. > But once more, there is more code to write without typing. > > > You have to trust functions to satisfy their > > postconditions. > I trust the code generated by the compiler to check an assertion or a > range, I trust a formal tool that certifies to me that returned value > will always be in range, but I don't trust a comment. > > > Even in Ada relatively few post-conditions can be > > handled by type checks. > But whatever is the proportion, why would you renonce to this advantage? > Typing has no cost, no drawback, only advantages. So, why should we > discuss on what typing can't do? Explicit static typing ala Ada and C++ definitely has a cost, because it makes the code longer, and also makes it more brittle. Often I don't really care what type a variable has as long as it is the same type as the value it takes. But with explicit typing a simple type change can ripple through the application forcing the change of many other functions. Simply changing the return type of a commonly used function from single precision to double precision may require every call of that function to be changed. That takes time that could be better spent on higher level pursuits. Besides the additional time to write all those declarations and keep them synchronized with the bodies and keep all the callers synchronized, there is the time lost waiting for compilation and linking, and worse the loss in concentration when developers go off surfing the web waiting for the compile to finish. > Anyway, I enter in this thread because of the claim that typing has much > less value than test-first. > I still wait for any illustration of this claim. > > (and I feel that I will wait for a long time) I don't think you will wait all that long. Test-first development is no longer a radical idea. Increasing numbers of serious software development shops, like SABRE, are getting good results from test-first development. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 0:07 ` Kevin Cline @ 2004-09-11 12:06 ` Georg Bauhaus 2004-09-12 16:33 ` jayessay 2004-09-13 6:58 ` Kevin Cline 2004-09-12 16:30 ` jayessay 1 sibling, 2 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-11 12:06 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Explicit static typing ala Ada and C++ definitely has a cost, Yes. (And you get something in return, too?) : because it makes the code longer, Sometimes I prefer a few explicit words to brevity when brevity would hide things away. : and also makes it more brittle. Hm. Brittle? Your example could be a design issue. In Ada you could have written generic type FPT is digits <>; function compute(x, y: FPT) return FPT; or generic type FPT is digits <>; package Computations is ... I'm confident that changing the floating point type might not have required adjusting a lot of calls? Related to making changes to parameter profiles, subtype declaractions and type declarations offer at least one choice: - use (possibly constraining) subtypes where you expect slight changes to the range of values passed. (Use T'base type parameters if a function needs to be more general.) - use types where the domain objects are different, or where things should be handled separately in code. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 12:06 ` Georg Bauhaus @ 2004-09-12 16:33 ` jayessay 2004-09-13 12:43 ` Georg Bauhaus 2004-09-13 6:58 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-12 16:33 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Kevin Cline <kevin.cline@gmail.com> wrote: > > : Explicit static typing ala Ada and C++ definitely has a cost, > > Yes. (And you get something in return, too?) In most domains, the answer is "not much". The cost is _way_ more than the ROI. > : because it makes the code longer, > > Sometimes I prefer a few explicit words to brevity when brevity would > hide things away. > > : and also makes it more brittle. > > Hm. Brittle? Your example could be a design issue. In Ada you could have > written Open your mind a bit more - don't concentrate on the particular example and think about what it would mean to have the sort of flexibility to track changing requirements (indeed to realize new requirements) that Kevin is talking about. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:33 ` jayessay @ 2004-09-13 12:43 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 12:43 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> Kevin Cline <kevin.cline@gmail.com> wrote: :> :> : Explicit static typing ala Ada and C++ definitely has a cost, :> :> Yes. (And you get something in return, too?) : : In most domains, the answer is "not much". The cost is _way_ more : than the ROI. I know I'm nagging, but still, could you be a bit more specific about what you mean by "most domains", and "not much"? :> Hm. Brittle? Your example could be a design issue. In Ada you could have :> written : : Open your mind a bit more - don't concentrate on the particular : example and think about what it would mean to have the sort of : flexibility to track changing requirements (indeed to realize new : requirements) that Kevin is talking about. (Could you give a typical example of the kind of change in requirements you have in mind?) I did, and I agree that requirements pattern matching can be written more quickly by writing melleable interfaces, and making ad hoc changes at every level of a system, tested. I don't see how adding static type checking makes a program brittle. Type mismatches may break the compilation run, sure. But is a program therefore brittle? When in the example type Direction is (North, East, South, West); the requirements change, and now we have type Direction is (North, East, South, West, Up, Down); then refactoring can be guided by static type analysis pointing out missing cases for example (in ML terms: exhaustive pattern matching finds definitions which need to be extended to match the new requirements, absent wildcards). Now ideally there is no need to test whether all values in the type Direction are handled in functions (etc.) with an argument of type Direction. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 12:06 ` Georg Bauhaus 2004-09-12 16:33 ` jayessay @ 2004-09-13 6:58 ` Kevin Cline 2004-09-13 13:06 ` Georg Bauhaus 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-13 6:58 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<chupnc$9t1$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > > : Explicit static typing ala Ada and C++ definitely has a cost, > > Yes. (And you get something in return, too?) > > : because it makes the code longer, > > Sometimes I prefer a few explicit words to brevity when brevity would > hide things away. > > : and also makes it more brittle. > > Hm. Brittle? Your example could be a design issue. > In Ada you could have > written > > generic > type FPT is digits <>; > function compute(x, y: FPT) return FPT; > > or > > generic > type FPT is digits <>; > package Computations is ... Yes, you could have, if you had thought of it before your team wrote 100,000 lines of code. But we're not omniprescient. Sometimes requirements change, and sometimes we make mistakes. This flexibility also comes with a cost -- it makes the code harder to read. Everyone knows what digits<> means, but the first time we see FPT we'll have to go look it up. Should we also create a type for discrete inventory quantity, or just use integer? Well, it's possible that we could need to go to 64 bits, but right now we don't have enough memory to expand them all to 64 bits, so better create a IQTY type. And so it goes... soon you have dozens or hundreds of data types, and no one knows what they all mean, and the code is obscured by type conversions. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-13 6:58 ` Kevin Cline @ 2004-09-13 13:06 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 13:06 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: :> generic :> type FPT is digits <>; :> package Computations is ... : : Yes, you could have, if you had thought of it before your team wrote : 100,000 lines of code. OK, if the code has not used proper types right from the start and there will be no corrections, there is little you can do but write adequate code. : But we're not omniprescient. Sure. This is why things can be described in fairly abstract terms. This does *not* mean chosing a concrete type for their representation. If I know "we will be computing with floating point values", I won't blindly chose one concrete predefined floating point type unless there is good reason to do so. In particular when it costs next to nothing to provide for possible changes in the type by making the corresponding module a parameterized module. : This : flexibility also comes with a cost -- it makes the code harder to : read. Everyone knows what digits<> means, but the first time we see : FPT we'll have to go look it up. As a Client, you won't have to use the name "FPT", see below. : Should we also create a type for : discrete inventory quantity, or just use integer? Well, it's possible : that we could need to go to 64 bits, but right now we don't have : enough memory to expand them all to 64 bits, so better create a IQTY : type. And so it goes... soon you have dozens or hundreds of data : types, and no one knows what they all mean, and the code is obscured : by type conversions. So that's it :-) You want the illusion of knowing the type. :-) And to look at the details by trial and error testing? Given the information present in digits<>, conceptually, and leaving it at that, of course will give you lots of opportunities for additional testing :-) :-) FPT is of course a name chosen for the sake of this example, not to be used in real programs to denote a particulat floating point type. The name does _not_ appear outside the floating point module. In package ... is new Stone_Carving_Drawings (Float_Type => ...); it is pretty clear what Float_Type => ... stands for, isn't it? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 0:07 ` Kevin Cline 2004-09-11 12:06 ` Georg Bauhaus @ 2004-09-12 16:30 ` jayessay 2004-09-12 22:55 ` Lionel Draghi ` (2 more replies) 1 sibling, 3 replies; 387+ messages in thread From: jayessay @ 2004-09-12 16:30 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Explicit static typing ala Ada and C++ definitely has a cost, because > it makes the code longer, and also makes it more brittle. The truth of this is really really hard to over emphasize. > Often I don't really care what type a variable has as long as it is > the same type as the value it takes. But with explicit typing a > simple type change can ripple through the application forcing the > change of many other functions. Simply changing the return type of > a commonly used function from single precision to double precision > may require every call of that function to be changed. That takes > time that could be better spent on higher level pursuits. Good description of a serious problem with static typing. > Besides the additional time to write all those declarations and keep > them synchronized with the bodies and keep all the callers > synchronized, there is the time lost waiting for compilation and > linking, and worse the loss in concentration when developers go off > surfing the web waiting for the compile to finish. More very good points. Productivity, as well as robustness and _usefulness_ of the result, generally (in my experience) skyrockets after moving to dynamic systems and agile methods. > > Anyway, I enter in this thread because of the claim that typing has much > > less value than test-first. It is _static_ typing that has much less value, not typing! > > I still wait for any illustration of this claim. > > > > (and I feel that I will wait for a long time) > > I don't think you will wait all that long. Test-first development is > no longer a radical idea. Increasing numbers of serious software > development shops, like SABRE, are getting good results from > test-first development. Agreed. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:30 ` jayessay @ 2004-09-12 22:55 ` Lionel Draghi 2004-09-12 23:08 ` Lionel Draghi 2004-09-13 13:08 ` Georg Bauhaus 2 siblings, 0 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-12 22:55 UTC (permalink / raw) ... >>>Anyway, I enter in this thread because of the claim that typing has much >>>less value than test-first. > It is _static_ typing that has much less value, not typing! >>>I still wait for any illustration of this claim. >>>(and I feel that I will wait for a long time) >> >>I don't think you will wait all that long. Test-first development is >>no longer a radical idea. Increasing numbers of serious software >>development shops, like SABRE, are getting good results from >>test-first development. > > Agreed. With what? This is not at all related to my point. I am not waiting for whatever about XP development, not even success stories, because we already have this at work. I am waiting for any point explaining how Agile methods raise static typing more or less obsolete. There is no relation between those: you could have raise all your points before XP creation, all this thread is just a (usual) discussion about typing. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:30 ` jayessay 2004-09-12 22:55 ` Lionel Draghi @ 2004-09-12 23:08 ` Lionel Draghi 2004-09-13 2:37 ` John B. Matthews 2004-09-13 21:28 ` jayessay 2004-09-13 13:08 ` Georg Bauhaus 2 siblings, 2 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-12 23:08 UTC (permalink / raw) jayessay wrote: ... >> Often I don't really care what type a variable has as long as it is >>the same type as the value it takes. But with explicit typing a >>simple type change can ripple through the application forcing the >>change of many other functions. Simply changing the return type of >>a commonly used function from single precision to double precision >>may require every call of that function to be changed. That takes >>time that could be better spent on higher level pursuits. > Good description of a serious problem with static typing. Serious problem? 1 - if your float is a custom type, the type and related operators are typically declared in the same package : changing it is trivial. 2 - if you are using predifined type: too bad, but you can't comply about strong typing if you are not using it the right way. Your serious problem seems really anecdotal to me. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 23:08 ` Lionel Draghi @ 2004-09-13 2:37 ` John B. Matthews 2004-09-13 21:28 ` jayessay 1 sibling, 0 replies; 387+ messages in thread From: John B. Matthews @ 2004-09-13 2:37 UTC (permalink / raw) In article <4144d6da$0$17714$626a14ce@news.free.fr>, Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> wrote: > jayessay wrote: > ... > >> Often I don't really care what type a variable has as long as it is > >>the same type as the value it takes. But with explicit typing a > >>simple type change can ripple through the application forcing the > >>change of many other functions. Simply changing the return type of > >>a commonly used function from single precision to double precision > >>may require every call of that function to be changed. That takes > >>time that could be better spent on higher level pursuits. > > > Good description of a serious problem with static typing. > > Serious problem? > 1 - if your float is a custom type, the type and related operators are > typically declared in the same package : changing it is trivial. > 2 - if you are using predifined type: too bad, but you can't comply > about strong typing if you are not using it the right way. > > Your serious problem seems really anecdotal to me. Indeed, if such a change is required, the compiler will reliably lead me to every affected part of the code--and no other. I consider this an advantage. John ---- jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 23:08 ` Lionel Draghi 2004-09-13 2:37 ` John B. Matthews @ 2004-09-13 21:28 ` jayessay 1 sibling, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-13 21:28 UTC (permalink / raw) Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes: > Your serious problem seems really anecdotal to me. Frankly, wrt software development, that is really all you ever have. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:30 ` jayessay 2004-09-12 22:55 ` Lionel Draghi 2004-09-12 23:08 ` Lionel Draghi @ 2004-09-13 13:08 ` Georg Bauhaus 2 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-13 13:08 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : :> Often I don't really care what type a variable has as long as it is :> the same type as the value it takes. But with explicit typing a :> simple type change can ripple through the application forcing the :> change of many other functions. Simply changing the return type of :> a commonly used function from single precision to double precision :> may require every call of that function to be changed. That takes :> time that could be better spent on higher level pursuits. : : Good description of a serious problem with static typing. Good description of a serious problem with inflexible static typing. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:39 ` jayessay 2004-09-07 22:01 ` Lionel Draghi @ 2004-09-09 0:13 ` Randy Brukardt 2004-09-11 0:23 ` Kevin Cline 2004-09-12 16:22 ` jayessay 1 sibling, 2 replies; 387+ messages in thread From: Randy Brukardt @ 2004-09-09 0:13 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com... > kevin.cline@gmail.com (Kevin Cline) writes: ... > > I thought so too, until I tried incremental test-first development. > > Retesting a unit after adding a few lines of code means that type > > mismatches are caught immediately with or without strong typing. But > > it goes faster if you don't have to compile and link every iteration. > > Exactly. Actually this sort of development will save you much more > time and money than you could ever hope for from typical static typing. This seems like complete nonsense to me. (I'll admit that I've read other people making similar claims). The reason is that writing a good subprogram test takes on average 10 times as much code as is in the subprogram itself. That's because of the need to set up the needed global state for the preconditions, and the need to test all of the possible permutations of input. Making the test reusable and automatible adds even more effort. The best way to save time and money is to avoid the need to do that testing in the first place. We do that with Ada's strong compile-time and run-time checking, combined with occassional invariant assertions. And then we do extensive, repeatable system-level testing to find any logic errors. Our experience is that true logic errors (those that doesn't show up as compile-time or run-time checks) are very rare, probably less than 1% of all errors. (I'm omitting interfacing errors from this summary, because there you lose all benefits of Ada or for that matter any type system, even one as weak as C's. No language is going to help you there, but the real world is always going to insist on it...) If I had a stronger need for correctness, I'd move to something like SPARK, and do *all* of the checking at compile-time; I certainly wouldn't write more tests. Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 0:13 ` Randy Brukardt @ 2004-09-11 0:23 ` Kevin Cline 2004-09-14 0:17 ` Randy Brukardt 2004-09-12 16:22 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-11 0:23 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<2L-dnRmP6qOePaLcRVn-ug@megapath.net>... > "jayessay" <nospam@foo.com> wrote in message > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com... > > kevin.cline@gmail.com (Kevin Cline) writes: > ... > > > I thought so too, until I tried incremental test-first development. > > > Retesting a unit after adding a few lines of code means that type > > > mismatches are caught immediately with or without strong typing. But > > > it goes faster if you don't have to compile and link every iteration. > > > > Exactly. Actually this sort of development will save you much more > > time and money than you could ever hope for from typical static typing. > > This seems like complete nonsense to me. (I'll admit that I've read other > people making similar claims). The reason is that writing a good subprogram > test takes on average 10 times as much code as is in the subprogram itself. > That's because of the need to set up the needed global state for the > preconditions, and the need to test all of the possible permutations of > input. Making the test reusable and automatible adds even more effort. A 10:1 ratio of test code to production code seems extremely high. Keeping subprograms small will reduce the number of permutations of input that must be tested. It's much easier to test five ten-line subprograms taking one input each than to test one fifty-line subprogram taking five inputs. It's also much easier to maintain the five ten-line subprograms, and easier to demonstrate code correctness. Another benefit of unit-level testing is that in the absence of any other documentation, the tests at least demonstrate correct use of the unit. > The best way to save time and money is to avoid the need to do that testing > in the first place. We do that with Ada's strong compile-time and run-time > checking, combined with occassional invariant assertions. And then we do > extensive, repeatable system-level testing to find any logic errors. I do not like having only system-level testing because it makes changes either risky or expensive, and inhibits refactoring. It drives developers to stick with the first code that passes tests, and inhibits extraction of duplicated code because of the cost of retesting. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-11 0:23 ` Kevin Cline @ 2004-09-14 0:17 ` Randy Brukardt 0 siblings, 0 replies; 387+ messages in thread From: Randy Brukardt @ 2004-09-14 0:17 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409101623.73cdaf9b@posting.google.com... > "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<2L-dnRmP6qOePaLcRVn-ug@megapath.net>... ... > > This seems like complete nonsense to me. (I'll admit that I've read other > > people making similar claims). The reason is that writing a good subprogram > > test takes on average 10 times as much code as is in the subprogram itself. > > > That's because of the need to set up the needed global state for the > > preconditions, and the need to test all of the possible permutations of > > input. Making the test reusable and automatible adds even more effort. > > A 10:1 ratio of test code to production code seems extremely high. > Keeping subprograms small will reduce the number of permutations of > input that must be tested. It's much easier to test five ten-line > subprograms taking one input each than to test one fifty-line > subprogram taking five inputs. The size of the subprogram is irrelevant. In real systems, there is a lot of state associated with any particular operation. You have to set up all of that state in order to have a useful, repeatable test. For instance, in the Janus/Ada compiler, we have lots of short query functions. But you have to have a complete symboltable in order to use them - otherwise their preconditions would be violated and the test results would tell you nothing. > It's also much easier to maintain the five ten-line subprograms, and > easier to demonstrate code correctness. While I don't doubt that, it's rare that you can write anything useful in 10 lines of readable code. (Sure, you can cram lots of code into that space, especially in languages like Lisp or Perl; but is there any chance to fix it when a problem is discovered in a few months? Not if the code isn't readable.) > Another benefit of unit-level testing is that in the absence of any > other documentation, the tests at least demonstrate correct use of the unit. Yes, that's the main reason that we even bothered with many of the tests we wrote for Claw. (They also served to verify that the Microsoft documentation was accurate, a real dicey proposition in 1997.) > > The best way to save time and money is to avoid the need to do that testing > > in the first place. We do that with Ada's strong compile-time and run-time > > checking, combined with occassional invariant assertions. And then we do > > extensive, repeatable system-level testing to find any logic errors. > > I do not like having only system-level testing because it makes > changes either risky or expensive, and inhibits refactoring. It > drives developers to stick with the first code that passes tests, and > inhibits extraction of duplicated code because of the cost of > retesting. Changes certainly aren't risky in Ada, and a majority aren't expensive, either. Refactoring (indeed, any sort of restructuring) is a complete waste of effort unless it is tied to a clear end-user benefit. We used to do lots of that, but it mainly made us (the programmers) feel good, and it did nothing to make the product better in many of the cases. Your last sentence seems to go against agile - test-driven - methods -- once the tests pass, you're done! There's no reason to mess with the code further. Moreover, there is little cost to retesting, because the tests are all automated and run pretty much after every change. Testing is not very worthwhile in my view if you can't rerun it frequently to verify that nothing has changed. Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 0:13 ` Randy Brukardt 2004-09-11 0:23 ` Kevin Cline @ 2004-09-12 16:22 ` jayessay 2004-09-14 0:49 ` Randy Brukardt 1 sibling, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-12 16:22 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "jayessay" <nospam@foo.com> wrote in message > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com... > > kevin.cline@gmail.com (Kevin Cline) writes: > ... > > > I thought so too, until I tried incremental test-first development. > > > Retesting a unit after adding a few lines of code means that type > > > mismatches are caught immediately with or without strong typing. But > > > it goes faster if you don't have to compile and link every iteration. > > > > Exactly. Actually this sort of development will save you much more > > time and money than you could ever hope for from typical static typing. > > This seems like complete nonsense to me. (I'll admit that I've read other > people making similar claims). Have a look at this: http://martinfowler.com/articles/newMethodology.html and I think you will have a somewhat better idea of what this is about. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-12 16:22 ` jayessay @ 2004-09-14 0:49 ` Randy Brukardt 2004-09-14 14:28 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Randy Brukardt @ 2004-09-14 0:49 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3sm9n8nk2.fsf@rigel.goldenthreadtech.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > "jayessay" <nospam@foo.com> wrote in message > > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com... > > > kevin.cline@gmail.com (Kevin Cline) writes: > > ... > > > > I thought so too, until I tried incremental test-first development. > > > > Retesting a unit after adding a few lines of code means that type > > > > mismatches are caught immediately with or without strong typing. But > > > > it goes faster if you don't have to compile and link every iteration. > > > > > > Exactly. Actually this sort of development will save you much more > > > time and money than you could ever hope for from typical static typing. > > > > This seems like complete nonsense to me. (I'll admit that I've read other > > people making similar claims). > > Have a look at this: > > http://martinfowler.com/articles/newMethodology.html > > and I think you will have a somewhat better idea of what this is > about. "Access to this site timed-out". Doesn't bode well for the quality of the software... :-) Seriously, I'm always very skeptical of "methodologies", because they primarily seem geared toward selling books and consulting to clueless management types. There's usually a few obvious truths sprinkled around to make them more palatable. For a test-first scheme to have any hope of success, you have to have programmers that are very disciplined, that actually take the time to test every path of every subprogram. I doubt that there are many such people - I *know* I am not such a person. (The reason that I've always used Ada exclusively is that the Ada compiler catches the vast majority of my mistakes; without Ada, I simply could not work in this field, because the computers would not survive many long debugging sessions.) Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 0:49 ` Randy Brukardt @ 2004-09-14 14:28 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-14 14:28 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "jayessay" <nospam@foo.com> wrote in message > news:m3sm9n8nk2.fsf@rigel.goldenthreadtech.com... > > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > > > "jayessay" <nospam@foo.com> wrote in message > > > news:m3wtz7e4hd.fsf@rigel.goldenthreadtech.com... > > > > kevin.cline@gmail.com (Kevin Cline) writes: > > > ... > > > > > I thought so too, until I tried incremental test-first development. > > > > > Retesting a unit after adding a few lines of code means that type > > > > > mismatches are caught immediately with or without strong typing. > But > > > > > it goes faster if you don't have to compile and link every > iteration. > > > > > > > > Exactly. Actually this sort of development will save you much more > > > > time and money than you could ever hope for from typical static > typing. > > > > > > This seems like complete nonsense to me. (I'll admit that I've read > other > > > people making similar claims). > > > > Have a look at this: > > > > http://martinfowler.com/articles/newMethodology.html > > > > and I think you will have a somewhat better idea of what this is > > about. > > "Access to this site timed-out". Comes up instantly for me, from different machines on different nets. > Doesn't bode well for the quality of the software... :-) Looks like simple html to me, ("hand written"), and using Apache. Maybe the broken stuff is on your side. > Seriously, I'm always very skeptical of "methodologies", because > they primarily seem geared toward selling books and consulting to > clueless management types. There's usually a few obvious truths > sprinkled around to make them more palatable. Agreed, absolutely. The nice thing about the above is that it is not much about any "methodology", but merely an overview of why something like "agile" techniques are (re)gaining interest. > For a test-first scheme to have any hope of success, you have to have As I pointed out elsewhere, I think a much better way of thinking about the kind of incremental development I was discussing is that of developing a theory in mathematics. I typically spend 0 time in debugging sessions. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 22:49 ` Kevin Cline 2004-09-06 16:39 ` jayessay @ 2004-09-06 21:01 ` Stephen Leake 2004-09-13 6:23 ` Kevin Cline 2004-09-07 2:16 ` Richard Riehle 2004-09-07 22:37 ` Lionel Draghi 3 siblings, 1 reply; 387+ messages in thread From: Stephen Leake @ 2004-09-06 21:01 UTC (permalink / raw) To: comp.lang.ada kevin.cline@gmail.com (Kevin Cline) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>... > > In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard Riehle" <adaworks@earthlink.net> writes: > > > > > No one argues that testing is unimportant. > > > > > No language can protect us, at compile time, from every possible > > > error. > > > > But assuming perfect testing, finding the errors during compilation > > rather than in testing saves me time, and time is money. > > I thought so too, until I tried incremental test-first development. > Retesting a unit after adding a few lines of code means that type > mismatches are caught immediately with or without strong typing. But > it goes faster if you don't have to compile and link every iteration. Hmm. I practice "test first" and incremental code/test. But I don't write tests that duplicate what the compiler is already testing; that would certainly be a waste of my time! It takes me much longer to write and test code in C than in Ada. I suppose Haskell or something might be even better, but I'm waiting for an ISO standard language that I can buy support for. -- -- Stephe ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 21:01 ` Stephen Leake @ 2004-09-13 6:23 ` Kevin Cline 0 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-13 6:23 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.50.1094504533.31213.comp.lang.ada@ada-france.org>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>... > > > In article <iWG_c.8033$w%6.3982@newsread1.news.pas.earthlink.net>, "Richard Riehle" <adaworks@earthlink.net> writes: > > > > > > > No one argues that testing is unimportant. > > > > > No language can protect us, at compile time, from every possible > > > > error. > > > > > > But assuming perfect testing, finding the errors during compilation > > > rather than in testing saves me time, and time is money. > > > > I thought so too, until I tried incremental test-first development. > > Retesting a unit after adding a few lines of code means that type > > mismatches are caught immediately with or without strong typing. But > > it goes faster if you don't have to compile and link every iteration. > > Hmm. I practice "test first" and incremental code/test. But I don't > write tests that duplicate what the compiler is already testing; that > would certainly be a waste of my time! > > It takes me much longer to write and test code in C than in Ada. No surprise. C is a much lower-level language than Ada. Have you ever tried C++? > I > suppose Haskell or something might be even better, but I'm waiting for > an ISO standard language that I can buy support for. I don't think there's as much value in ISO standards as there once was. When there were two dozen CPU families in use, and compiler writing was an arcane and expensive art, ISO standards helped keep developers and users from getting locked in to one particular hardware vendor. Today, with open-source compilers and languages, de facto standard languages like Perl are just as good. If you want control, then I would think you would be better off with an open-source language and compiler, like C++/gcc or Ada/gnat or Perl. I would rather have something I can fix myself or hire someone to fix than be at the mercy of a monopoly supplier. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 22:49 ` Kevin Cline 2004-09-06 16:39 ` jayessay 2004-09-06 21:01 ` Stephen Leake @ 2004-09-07 2:16 ` Richard Riehle 2004-09-07 3:57 ` Benjamin Ketcham ` (2 more replies) 2004-09-07 22:37 ` Lionel Draghi 3 siblings, 3 replies; 387+ messages in thread From: Richard Riehle @ 2004-09-07 2:16 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409051449.574ec9ce@posting.google.com... > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<vpblkhspuA9F@eisner.encompasserve.org>... > > But assuming perfect testing, finding the errors during compilation > > rather than in testing saves me time, and time is money. > > I thought so too, until I tried incremental test-first development. > Retesting a unit after adding a few lines of code means that type > mismatches are caught immediately with or without strong typing. But > it goes faster if you don't have to compile and link every iteration. > This assumes that we are concerned only with type mismatches. In Ada, we expect the compiler to provide a great deal more than that. For small software systems, frequent testing can often be sufficient. As the size of the software increases, and complexity of that software grows, we must engage all the tools available and use them appropriately to ensure the correctness of our design. Also, in large software systems, it is not possible to test every path, every possible value of a variable, and every potential timing problem. How does one test for a race condition? Does that test guarantee no race condition can occur? This is not a type checking issue, but it is a design issue where the type model can be one of many factors in reasoning about the stability of the design. How does one test for a runaway pointer or dangling reference? Again, this is not strictly a type issue, except that Ada's overall set of rules, including the type rules, provide some tools for reasoning about this intelligently. Finally, testing can only test for what we know needs to be tested. We must design for the unexpected, even as we test for the expected. It is impossible to test for the unexpected. The Ada type model includes both the compile-time checking and the run-time checking. The rest of Ada provides a wide range of compile-time checks. Those who fail to understand this should stay away from building software that requires a high degree of dependability. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 2:16 ` Richard Riehle @ 2004-09-07 3:57 ` Benjamin Ketcham 2004-09-07 16:42 ` Richard Riehle 2004-09-07 7:46 ` Jean-Pierre Rosen 2004-09-14 20:14 ` Kevin Cline 2 siblings, 1 reply; 387+ messages in thread From: Benjamin Ketcham @ 2004-09-07 3:57 UTC (permalink / raw) Richard Riehle <adaworks@earthlink.net> wrote: > > Finally, testing can only test for what we know needs to be tested. We > must design for the unexpected, even as we test for the expected. It is > impossible to test for the unexpected. While I agree with the overall point here, I keep seeing this assertion, here made with especially great conviction: "it is impossible to test for the unexpected". As with many absolute statements, it is not technically correct, although it expresses a valid general truth. Consider the method of kernel testing where system calls are invoked with random arguments; this kind of test often turns up "unexpected" problems. I recall that early in the days of Windows NT, this kind of approach uncovered bugs that led to complete system hangs (I'd hope they have fixed such things by now, and that MS themselves make sure they are the first to find such things by trying such tests in-house before releasing new kernels; thankfully I don't have to use NT or whatever it's called now, so I don't know). Same goes for UIs; some kinds of testing involve sending random UI events at a program until it crashes or does something incorrect. Sure, it's generally not possible to test *every* possible state of large software, but this doesn't mean that testing *many* states, particularly states that might not be "expected", by feeding it random data, is not a valid, important, and sometimes fruitful approach. --Benjamin ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 3:57 ` Benjamin Ketcham @ 2004-09-07 16:42 ` Richard Riehle 2004-09-07 20:51 ` jayessay 2004-09-09 2:52 ` Kevin Cline 0 siblings, 2 replies; 387+ messages in thread From: Richard Riehle @ 2004-09-07 16:42 UTC (permalink / raw) "Benjamin Ketcham" <bketcham@drizzle.com> wrote in message news:1094529422.982635@yasure... > Richard Riehle <adaworks@earthlink.net> wrote: > > > > Finally, testing can only test for what we know needs to be tested. We > > must design for the unexpected, even as we test for the expected. It is > > impossible to test for the unexpected. > > While I agree with the overall point here, I keep seeing this > assertion, here made with especially great conviction: "it is > impossible to test for the unexpected". As with many absolute > statements, it is not technically correct, although it expresses > a valid general truth. Consider the method of kernel testing > where system calls are invoked with random arguments; this kind > of test often turns up "unexpected" problems. Yes, Benjamin, I may have been a little too over the top in my use of the word, "impossible." I too have seen test plans and test scripts that randomly traverse that entire universe of possibilities to make sure that none of the unwanted combinations of keyboard entries (or other data sources) are allowed to pass at run-time. One of the benefits of assertions (DbC) is that one can simply declare a range of unacceptable conditions as part of the design and be assured that those conditions will not be permitted to occur. Even so, whether programming with assertions, or using a test-driven approach, one needs to be a little careful about depending too much on the tests or the assertions. Moreover, a well-designed program must be about more than simple correctness, even as hard as that is. Much has been said, in this forum, about the wonders of test-driven design in dynamically-typed languages as a benefit to on-going change in a program. In other forums that deal with this topic, advocates of TDD include refactoring as one of the mechanisms of choice. No reasonable person will deny that, under some circumstances and for some kinds of software, these are acceptable models of development. We are always compelled to ask about the limits of any tool, method, or style. To answer, "There are no limits," is to consign oneself in the league of the naive. Static typing, design by contract, and other static methods are certainly limited in what they can accomplish. So too, we must recognize the limits of the dynamic approach. As we examine those limits, for both approaches, we are required to also examine the trade-offs and risks associated with them. Is one approach more dependable for a given domain than the other approach? Is one more economical than the other for the context in which it will be used? This kind of inquiry is not unlike any other engineering exercise. We are in pursuit of a predictable outcome, an outcome that satisfies a defined set of requirements. Whether those requirements are specified as the tests themselves (as in TDD), or embedded within the assertions (as in DbC), in the type definitions and associated methods, or some combination, the goal is the same. Engineering is concerned with design. Engineeering prefers, as much as possible, settled knowledge rather than a continual test-debug model. We try to get the design as close to correct early, even testing parts of it along the way as we build it. However, testing every aspect of the design is not always possible. In particular, as the deployed design is required to deal with the real world, it must be able to adapt itself to the unexpected. Let me give you an example. In am system I know something about, one with a large number of components, a programmer included a routine that had a built-in constraint (not a type constraint), in the form of an if ... end if statement. The constraint was cleverly written and the language in use was not strongly typed, so the programmer could use long (as in long integer) as a reasonable data type for his algorithmic mischief. I say mischief because that was what it was, a small time-bomb intended to crash the program long after he resigned and went on to another job. No amount of testing would have caught this. He was clever enough to see to that. The design was not type safe, so the result from his routine could be easily passed to some other routine as a parameter. You many argue to the contrary, but the test scripts (well-designed) did not catch the error. When it occurred, the system failed, and no one knew why until a considerable amount of analysis was performed. Experienced software designers could easily relate many more such stories. Engineering history is full of them. Knowing that, in the world of physical engineering, where we are constrained by physics and can measure everything down to very fine tolerances, and still make disastrous mistakes, how do we justify any approach to software engineering that limits us to a single approach to creating dependable software? This question is especially important with the increased use of software in safety-critical systems. Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast, or their ilk will persuade the designers of flight avionics to begin using those languages. It is bad enough that some of them have chosen to use C and C++. We need to, as always, select the right tool for the job at hand. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 16:42 ` Richard Riehle @ 2004-09-07 20:51 ` jayessay 2004-09-07 22:21 ` Mark Lorenzen 2004-09-08 10:29 ` Georg Bauhaus 2004-09-09 2:52 ` Kevin Cline 1 sibling, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-07 20:51 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > One of the benefits of assertions (DbC) is that one can simply > declare a range of unacceptable conditions as part of the design > and be assured that those conditions will not be permitted to > occur. There is nothing about this that is incompatible with dynamic typing. If you wanted you could implement the whole Eiffel Dbc thing (and then some) as a set of macros using CLOS within Common Lisp. As I recall now, someone actually did this (I will try to find it). > Moreover, a well-designed program must be about more than simple > correctness, even as hard as that is. Agreed (if for no other reason than what "correctness" means is typically vague - even in very well designed and specified systems.) > In particular, as the deployed design is required to deal with the > real world, it must be able to adapt itself to the unexpected. This is a particularly apropos aspect of systems built with dynamic systems. Evolvable and adaptable are key descriptors. > Let me give you an example. In am system I know something about, > one with a large number of components, a programmer included a > routine that had a built-in constraint (not a type constraint), in > the form of an if ... end if statement. The constraint was cleverly > written and the language in use was not strongly typed, so the Just to be clear "not strongly typed" and "not type safe" have nothing to do with dynamically typed. > but the test scripts (well-designed) did not catch the error. When > it occurred, the system failed, and no one knew why until a > considerable amount of analysis was performed. Also, just for clarity, are you saying you believe static typing would have made a difference here? You can dream up plausible scenarios where it might have but equally plausible scenarios it wouldn't have. I actually think dynamic typing would be significantly more efficacious here (if not any more than static typing in prevention, then certainly in immediately pinpointing the problem). > Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast, > or their ilk will persuade the designers of flight avionics to begin > using those languages. I'm not advocating this - mostly because I don't think this domain needs the kind of flexibility and expressiveness that comes from Lisp. This stuff belongs to a very well bounded and concretely defined domain. > It is bad enough that some of them have chosen to use C and C++. We > need to, as always, select the right tool for the job at hand. This, OTOH is just implicitly cast FUD, presumably intended to imply that something like Common Lisp would not "work well" here. I will absolutely make the claim that such an offering would be every bit as robust and "correct" as anything fielded. It is likely it would also be rather more maintainable. Maybe you are simply saying that the resources available here are still just too small to make this a viable option. I'm sure there are still a lot of things out there with just a few kilobytes available. Then again, Garmine has some pretty impressive boxes and last I looked Avidyne was still using WindozeNT/2000(!!!) as its base. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 20:51 ` jayessay @ 2004-09-07 22:21 ` Mark Lorenzen 2004-09-08 5:26 ` Richard Riehle 2004-09-08 15:36 ` jayessay 2004-09-08 10:29 ` Georg Bauhaus 1 sibling, 2 replies; 387+ messages in thread From: Mark Lorenzen @ 2004-09-07 22:21 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > "Richard Riehle" <adaworks@earthlink.net> writes: > > > One of the benefits of assertions (DbC) is that one can simply > > declare a range of unacceptable conditions as part of the design > > and be assured that those conditions will not be permitted to > > occur. > > There is nothing about this that is incompatible with dynamic typing. > If you wanted you could implement the whole Eiffel Dbc thing (and then > some) as a set of macros using CLOS within Common Lisp. As I recall > now, someone actually did this (I will try to find it). > > > > Moreover, a well-designed program must be about more than simple > > correctness, even as hard as that is. > > Agreed (if for no other reason than what "correctness" means is > typically vague - even in very well designed and specified systems.) > > > > In particular, as the deployed design is required to deal with the > > real world, it must be able to adapt itself to the unexpected. > > This is a particularly apropos aspect of systems built with dynamic > systems. Evolvable and adaptable are key descriptors. > > > > Let me give you an example. In am system I know something about, > > one with a large number of components, a programmer included a > > routine that had a built-in constraint (not a type constraint), in > > the form of an if ... end if statement. The constraint was cleverly > > written and the language in use was not strongly typed, so the > > Just to be clear "not strongly typed" and "not type safe" have nothing > to do with dynamically typed. > > > > but the test scripts (well-designed) did not catch the error. When > > it occurred, the system failed, and no one knew why until a > > considerable amount of analysis was performed. > > Also, just for clarity, are you saying you believe static typing would > have made a difference here? You can dream up plausible scenarios > where it might have but equally plausible scenarios it wouldn't have. > I actually think dynamic typing would be significantly more > efficacious here (if not any more than static typing in prevention, > then certainly in immediately pinpointing the problem). > > > > Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast, > > or their ilk will persuade the designers of flight avionics to begin > > using those languages. > > I'm not advocating this - mostly because I don't think this domain > needs the kind of flexibility and expressiveness that comes from Lisp. > This stuff belongs to a very well bounded and concretely defined > domain. > > > > It is bad enough that some of them have chosen to use C and C++. We > > need to, as always, select the right tool for the job at hand. > > This, OTOH is just implicitly cast FUD, presumably intended to imply > that something like Common Lisp would not "work well" here. I will > absolutely make the claim that such an offering would be every bit as > robust and "correct" as anything fielded. It is likely it would also > be rather more maintainable. More maintainable? The pieces of LISP code you have shown so far are even less readable than French. It does not communicate any information about the problem domain to the reader, it is just a clever hack used to save some keystrokes. Why oh why do they continue to teach LISP in the US? They should teach ML instead. > > Maybe you are simply saying that the resources available here are > still just too small to make this a viable option. I'm sure there are > still a lot of things out there with just a few kilobytes available. > Then again, Garmine has some pretty impressive boxes and last I looked > Avidyne was still using WindozeNT/2000(!!!) as its base. > > > /Jon > > -- > 'j' - a n t h o n y at romeo/charley/november com Regards, - Mark Lorenzen ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 22:21 ` Mark Lorenzen @ 2004-09-08 5:26 ` Richard Riehle 2004-09-08 6:56 ` Mark Lorenzen 2004-09-08 15:36 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Richard Riehle @ 2004-09-08 5:26 UTC (permalink / raw) "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk... > > Why oh why do they continue to teach LISP in the US? They should teach > ML instead. > Lisp continues to be a useful tool for many kinds of applications. It is, however, important that we understand the limits of each our tools. We must recognize that Lisp has its virtues, but also know when to choose a toolset more appropriate for the problem at hand. Ada developers, those with a lot of experience in developing software, understand that they must sometimes combine code from some other language model in their programs. Fortunately, one of the significant virtues of Ada is its friendliness to other languages -- something we cannot acknowledge about many other popular languages. Also, I would be more inclined to choose CAML or OCAML than ML at this time in the development of the ML family. Do you have a reason for eschewing OCAML in favor of ML? Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 5:26 ` Richard Riehle @ 2004-09-08 6:56 ` Mark Lorenzen 2004-09-08 15:56 ` jayessay 0 siblings, 1 reply; 387+ messages in thread From: Mark Lorenzen @ 2004-09-08 6:56 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message > news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk... > > > > Why oh why do they continue to teach LISP in the US? They should teach > > ML instead. > > > Lisp continues to be a useful tool for many kinds of applications. > It is, however, important that we understand the limits of each > our tools. We must recognize that Lisp has its virtues, but also > know when to choose a toolset more appropriate for the problem > at hand. Ada developers, those with a lot of experience in > developing software, understand that they must sometimes > combine code from some other language model in their > programs. Fortunately, one of the significant virtues of > Ada is its friendliness to other languages -- something we > cannot acknowledge about many other popular languages. I agree, it is just that I think Lisp is a "strange" language to use in a programming class. > > Also, I would be more inclined to choose CAML or > OCAML than ML at this time in the development of the ML > family. Do you have a reason for eschewing OCAML in > favor of ML? I do not have a special reason. We used ML in my first programming class back at university, and I still think that it is one of the most elegant programming languages I have ever encountered. I used it for nearly all my projects including my thesis. It is an excellent tool for learning programming and especially if data types are emphasized from day 1 on, which they should, in order to give the students a feeling of the difference between math and CS. One of my colleagues calls my a type-Fascist. I take it as a compliment. I do not know enough about OCAML, but maybe it would be a good tool to learn both applicative, imperative and object oriented programming using the same language. > > Richard Riehle - Mark Lorenzen ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 6:56 ` Mark Lorenzen @ 2004-09-08 15:56 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-08 15:56 UTC (permalink / raw) Mark Lorenzen <mark.lorenzen@ofir.dk> writes: > "Richard Riehle" <adaworks@earthlink.net> writes: > > > "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message > > news:m3vfep90v7.fsf@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk... > > > > > > Why oh why do they continue to teach LISP in the US? They should teach > > > ML instead. > > > > > Lisp continues to be a useful tool for many kinds of applications. > > It is, however, important that we understand the limits of each > > our tools. We must recognize that Lisp has its virtues, but also > > know when to choose a toolset more appropriate for the problem > > at hand. Ada developers, those with a lot of experience in > > developing software, understand that they must sometimes > > combine code from some other language model in their > > programs. Fortunately, one of the significant virtues of > > Ada is its friendliness to other languages -- something we > > cannot acknowledge about many other popular languages. > > I agree, it is just that I think Lisp is a "strange" language to use > in a programming class. Now there is an insightful remark... /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 22:21 ` Mark Lorenzen 2004-09-08 5:26 ` Richard Riehle @ 2004-09-08 15:36 ` jayessay 2004-09-08 15:37 ` Jean-Marc Bourguet 1 sibling, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-08 15:36 UTC (permalink / raw) Mark Lorenzen <mark.lorenzen@ofir.dk> writes: > jayessay <nospam@foo.com> writes: > > This, OTOH is just implicitly cast FUD, presumably intended to imply > > that something like Common Lisp would not "work well" here. I will > > absolutely make the claim that such an offering would be every bit as > > robust and "correct" as anything fielded. It is likely it would also > > be rather more maintainable. > > More maintainable? Yes, but I don't expect you to realize this as you clearly haven't used the concepts behind it. > The pieces of LISP code you have shown so far are even less readable > than French. Wow. I wonder what French speakers would say. > It does not communicate any information about the problem domain to > the reader, it is just a clever hack used to save some keystrokes. Snippets _have_ no domain except the vague one of "example for discussion". Sheesh! Give a snippet out of context in _any_ thing and it won't communicate anything about any "domain". > Why oh why do they continue to teach LISP in the US? They should > teach ML instead. In general, neither is taught. As for ML, why choose that?? Haskell would be a better choice if you are a formal static type fanatic. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 15:36 ` jayessay @ 2004-09-08 15:37 ` Jean-Marc Bourguet 0 siblings, 0 replies; 387+ messages in thread From: Jean-Marc Bourguet @ 2004-09-08 15:37 UTC (permalink / raw) jayessay <nospam@foo.com> writes: > > The pieces of LISP code you have shown so far are even less readable > > than French. > > Wow. I wonder what French speakers would say. We (those who can read at least) obviously agree. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 20:51 ` jayessay 2004-09-07 22:21 ` Mark Lorenzen @ 2004-09-08 10:29 ` Georg Bauhaus 2004-09-08 16:04 ` jayessay 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-08 10:29 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : If you wanted you could implement the whole Eiffel Dbc thing (and then : some) as a set of macros using CLOS within Common Lisp. As I recall : now, someone actually did this (I will try to find it). Whether you can implement static DbC in CLOS is the more intereisting question. Compare to SPARK. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 10:29 ` Georg Bauhaus @ 2004-09-08 16:04 ` jayessay 0 siblings, 0 replies; 387+ messages in thread From: jayessay @ 2004-09-08 16:04 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > > : If you wanted you could implement the whole Eiffel Dbc thing (and then > : some) as a set of macros using CLOS within Common Lisp. As I recall > : now, someone actually did this (I will try to find it). > > Whether you can implement static DbC in CLOS is the more intereisting > question. Compare to SPARK. Yes, that is exactly the idea. You would create a set of macros to allow a natural expression for this. Macros do all their work at compile time. Macros are "just" functions which are code transformers - you have the entire power of Lisp available and can write complete compilers (lex -> syntax -> ast -> semantic analysis -> optimization -> code generation) and have the result integrated transparently with the rest of the language. ACL2 is another example of this sort thing. It is an applicative system with type inference and theorem proving used by Motorola, AMD, Rockwell Collins, et.al. for modeling and proving properties of commercial microprocessors. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 16:42 ` Richard Riehle 2004-09-07 20:51 ` jayessay @ 2004-09-09 2:52 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-09-09 2:52 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<_xl%c.431$xA1.301@newsread3.news.pas.earthlink.net>... > Much has been said, in this forum, about the wonders of test-driven > design in dynamically-typed languages as a benefit to on-going change > in a program. The original question was "Why isn't Ada more popular?" For general non-safety critical applications, there is now some question whether the benefits of static typing outweigh the cost. For the class of applications you are interested in, I would want to use a language that allowed me to most easily prove program correctness. But a relatively small number of programmers write those applications. > Engineering is concerned with design. Engineeering prefers, as much as > possible, settled knowledge rather than a continual test-debug model. > We try to get the design as close to correct early, even testing parts of > it along the way as we build it. However, testing every aspect of the > design is not always possible. In particular, as the deployed design > is required to deal with the real world, it must be able to adapt itself > to the unexpected. > > Let me give you an example. In am system I know something about, > one with a large number of components, a programmer included a > routine that had a built-in constraint (not a type constraint), in the > form of an if ... end if statement. The constraint was cleverly > written and the language in use was not strongly typed, so the > programmer could use long (as in long integer) as a reasonable > data type for his algorithmic mischief. I say mischief because > that was what it was, a small time-bomb intended to crash the > program long after he resigned and went on to another job. It might be possible to build a system to fail-safe in one component or another, but there is no software defense against buggy code, whether introduced deliberately or inadvertently. Even if the function returned a value in range it could have been written to return an incorrect value for certain inputs. For a great many applications, crashing is preferable to incorrect output. > No amount of testing would have caught this. No, but an inspection could have and should have. > Experienced software designers could easily relate many more > such stories. I don't have much experience with sabotaging programmers, but have a lot of experience with code that is just wrong. Some of it was Ada code. I found out that it is extremely difficult to write code and then test it, although coverage analysis helps. I've found that writing tests and then coding to meet them works better. At least you are forced to think very clearly about exactly what it is you are trying to do before you start doing it, and you have a clear indication of when you are done. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 2:16 ` Richard Riehle 2004-09-07 3:57 ` Benjamin Ketcham @ 2004-09-07 7:46 ` Jean-Pierre Rosen 2004-09-14 20:14 ` Kevin Cline 2 siblings, 0 replies; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-09-07 7:46 UTC (permalink / raw) Richard Riehle a écrit : > Finally, testing can only test for what we know needs to be tested. We > must design for the unexpected, even as we test for the expected. As the saying goes: "Once you've taken care of the unexpected, consider the unexpected unexpected" Exceptions forever! -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 2:16 ` Richard Riehle 2004-09-07 3:57 ` Benjamin Ketcham 2004-09-07 7:46 ` Jean-Pierre Rosen @ 2004-09-14 20:14 ` Kevin Cline 2004-09-20 21:45 ` Lurker 2 siblings, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-09-14 20:14 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<vS8%c.69$xA1.4@newsread3.news.pas.earthlink.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0409051449.574ec9ce@posting.google.com... > > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message > news:<vpblkhspuA9F@eisner.encompasserve.org>... > > > > But assuming perfect testing, finding the errors during compilation > > > rather than in testing saves me time, and time is money. > > > > I thought so too, until I tried incremental test-first development. > > Retesting a unit after adding a few lines of code means that type > > mismatches are caught immediately with or without strong typing. But > > it goes faster if you don't have to compile and link every iteration. > > > This assumes that we are concerned only with type mismatches. In > Ada, we expect the compiler to provide a great deal more than that. > > For small software systems, frequent testing can often be sufficient. As > the size of the software increases, and complexity of that software grows, > we must engage all the tools available and use them appropriately to > ensure the correctness of our design. Also, in large software systems, > it is not possible to test every path, every possible value of a variable, > and every potential timing problem. > > How does one test for a race condition? I don't test for race conditions. I try to isolate code potentially subject to race conditions or deadlocks to a small program unit, and then, if necessary, prove it correct. > Does that test guarantee > no race condition can occur? > This is not a type checking issue, but > it is a design issue where the type model can be one of many factors > in reasoning about the stability of the design. > > How does one test for a runaway pointer or dangling reference? I don't test for these. As a general rule, I don't write code that would make them possible. When I do have to write unsafe code, then I encapsulate it tightly so that the code is either obviously correct or can be verified correct in short order. > Again, > this is not strictly a type issue, except that Ada's overall set of rules, > including the type rules, provide some tools for reasoning about this > intelligently. Working safely with dynamically allocated objects in Ada-83 means using unhecked_allocation and deallocation, which reqired almost as much diligence as using malloc/free in C. Then C++ appeared with constructors and destructors and auto_ptr, and memory management got a lot easier. Then Ada-95 added controlled types, but by then C++ had huge mindshare. > Finally, testing can only test for what we know needs to be tested. We > must design for the unexpected, even as we test for the expected. It is > impossible to test for the unexpected. The Ada type model includes > both the compile-time checking and the run-time checking. The rest > of Ada provides a wide range of compile-time checks. > > Those who fail to understand this should stay away from building software > that requires a high degree of dependability. What do you mean by the unexpected? It seems that everything that could happen to software can be anticipated, except for total failure of the underlying execution engine. Or do you mean unexpected exceptions or incorrect values returned by unexpected software errors? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-14 20:14 ` Kevin Cline @ 2004-09-20 21:45 ` Lurker 0 siblings, 0 replies; 387+ messages in thread From: Lurker @ 2004-09-20 21:45 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409141214.215492cf@posting.google.com... > "Richard Riehle" <adaworks@earthlink.net> wrote in message news:<vS8%c.69$xA1.4@newsread3.news.pas.earthlink.net>... > > How does one test for a race condition? > > I don't test for race conditions. > > How does one test for a runaway pointer or dangling reference? > > I don't test for these. So you don't test for two major sources of errors? > As a general rule, I don't write code that > would make them possible. Good. But since you don't use testing to achieve that you must be using something else, right? ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-05 22:49 ` Kevin Cline ` (2 preceding siblings ...) 2004-09-07 2:16 ` Richard Riehle @ 2004-09-07 22:37 ` Lionel Draghi 3 siblings, 0 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-07 22:37 UTC (permalink / raw) Kevin Cline wrote: ... > Retesting a unit after adding a few lines of code means that type > mismatches are caught immediately with or without strong typing. With strong typing, you will catch it at code compilation. Without, you will maybe catch it at test execution. The former seems much more "immediate" than the later to me. > But it goes faster if you don't have to compile and link every iteration. So, use strong typing. Not only will save a lot of useless tests compilation, but also test writing. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-03 16:43 ` jayessay ` (2 preceding siblings ...) [not found] ` <e749549b.0409042036.5d4822a2@posting.googlOrganization: LJK Software <vpblkhspuA9F@eisner.encompasserve.org> @ 2004-09-06 7:49 ` Ole-Hjalmar Kristensen 2004-09-06 16:36 ` jayessay 3 siblings, 1 reply; 387+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-06 7:49 UTC (permalink / raw) >>>>> "j" == jayessay <nospam@foo.com> writes: j> "Richard Riehle" <adaworks@earthlink.net> writes: >> "jayessay" <nospam@foo.com> wrote in message >> news:m3isb2ey3w.fsf@rigel.goldenthreadtech.com... >> > "Richard Riehle" <adaworks@earthlink.net> writes: >> > j> ... >> Ada and Eiffel are designed with more compile-time checking capabilities >> than Smalltalk. j> Static typing is largely overrated - even Hindley-Milner type systems j> such as in Haskell or ML (which are significantly more potent than the j> type systems of Eiffel or Ada). The whole thing sounds great in j> theory and you can make some pretty plausible arguments for its j> efficacy, but it just doesn't make much difference in practice. j> I used to be a real advocate of this stuff and made those arguments j> myself (both here and elsewhere). It (static typing) was one of the j> things I was unsure about losing when I switched to Common Lisp (aka j> Lisp in this message) for all my major work 7 years ago. So, I kept a j> log of all the errors that I knew would have been caught by compile j> time type checking. I don't rigorously follow this practice anymore, j> but as I recall there were only 15 or so in 50K "lines" of Lisp [1]. j> Furthermore, all but a couple of these were caught immediately on j> first testing of function in question. No such errors ever manefested j> themselves in production code. Yes, I know the typical rebuttal here j> is "Yet!". In theory that's true, but the evidence at this point j> suggests it is extremely unlikely. Also, logic errors (what most j> people would consider significantly more negative) are far rarer. j> There turn out to be various reasons for this, but two worth j> mentioning are the sort of bottom up style of programming as described j> by Paul Graham (a kind of agile/extreme programming) and the ability j> to move Lisp to the expressive level of the application domain. j> In any application/system of any significance these two go hand in j> hand. The second is achieved by crafting a constrained narrowly j> focused domain specific language _within_ Lisp, which allows the j> programmer to then work at the level of the domain, _both_ j> syntactically as well as semantically. This is why Lisp macros j> (please don't confuse with any other kind of macro you've come across j> before) are such a big deal. j> Now, admittedly, creating these is not something your typical code j> monkey is going to grok. This is one of the big reasons why Lisp will j> never be as "popular" as something like Java. But then your typical j> code monkey isn't going to be building your core internal application j> api either. Once you've built this though, even a code monkey will be j> a lot more productive and produce much more clean and robust code. I do not consider myself a Lisp programmer, but I have programmed enough Lisp to conclude that you probably are correct that the ability to create a constrained narrowly focused domain specific language within Lisp could very well outweigh the advantages of static typing. But for the last years I have been mainly working with soft real time, multi-threaded systems. I am aware of the existence of real-time garbage collectors, but what about multi-threading? Common Lisp used to be pretty weak in this respect, has this changed? <snip> -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 7:49 ` Ole-Hjalmar Kristensen @ 2004-09-06 16:36 ` jayessay 2004-09-06 17:32 ` Georg Bauhaus 2004-09-07 22:18 ` Lionel Draghi 0 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-06 16:36 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> writes: > >>>>> "j" == jayessay <nospam@foo.com> writes: > > j> In any application/system of any significance these two go hand in > j> hand. The second is achieved by crafting a constrained narrowly > j> focused domain specific language _within_ Lisp, which allows the > j> programmer to then work at the level of the domain, _both_ > j> syntactically as well as semantically. This is why Lisp macros > j> (please don't confuse with any other kind of macro you've come across > j> before) are such a big deal. > > j> Now, admittedly, creating these is not something your typical code > j> monkey is going to grok. This is one of the big reasons why Lisp will > j> never be as "popular" as something like Java. But then your typical > j> code monkey isn't going to be building your core internal application > j> api either. Once you've built this though, even a code monkey will be > j> a lot more productive and produce much more clean and robust code. > > I do not consider myself a Lisp programmer, but I have programmed > enough Lisp to conclude that you probably are correct that the ability > to create a constrained narrowly focused domain specific language > within Lisp could very well outweigh the advantages of static typing. If you've been there, you know this. Actually, the incremental bottom up development with _continual_ testing of almost every code snippet is a significant advance above static typing. In this sort of development you are typically _extensively testing even partial expressions or single clauses_ (well below the level of a function) and at each increment of accretion testing that until you have a function at which point it is tested. The upshot is you have a stunning level of code path coverage - not just for type checks, but logic checks as well. Since you are not saddled with the typical write-try-to-compile-rewrite-compile-try-to-link-rewrite-... finally try to test something cycle this can be done _extremely_ efficiently and timely. You will catch errors _much faster_ than compile time checking - you are checking the correctness of code paths through most every singl path possible. You don't wait to build tests at the higher levels with input cases which you "hope/believe" will exercise "most" of these paths. This is also why _logic_ errors are also far rarer. > But for the last years I have been mainly working with soft real time, > multi-threaded systems. I am aware of the existence of real-time > garbage collectors, but what about multi-threading? Common Lisp used > to be pretty weak in this respect, has this changed? Multi-threading has actually always been available. All the implementations provide an MP facility modeled on the Lisp Machine's - they are not 100% the same as this is a "industry standard" and not yet in the ANSI standard, but they are very very close. So moving code from one to another is actually very easy. I have used multi-threading in basically all my work for years now and don't even think much of it anymore. In many ways, multi-threading is far simpler and more robust in Common Lisp than most anything else for a variety of reasons. Two big ones: 1) you can build your own tasking model and _embed it within the language_ for the type of tasking you will be using. So your code will be succinct, clean and _natural_. 2) Dynamic variables are simply amazing for reducing the much of the programming complexity of multi-threaded applications to nearly that of single-threaded. As for real-time GC, it depends on what you mean by "soft real time". If this really just means something like "it should run fast" or "I can't have any pauses" or some such, then any good modern generational GC will be more than sufficient. I've only had to tune the GC in a couple of really _huge_ application cases. Generally, such modern GCs will never use up more than a fraction of a _one_ percent of the runtime and will typically out perform manual heap management by quite a bit. If you really mean guaranteed response and runtimes, you may well need to roll your own, use a form of manual management, or maybe this case just isn't a good fit for Common Lisp. There are some bare metal Schemes out there that might work. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:36 ` jayessay @ 2004-09-06 17:32 ` Georg Bauhaus 2004-09-07 13:48 ` jayessay 2004-09-07 22:18 ` Lionel Draghi 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-06 17:32 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> : writes: : :> >>>>> "j" == jayessay <nospam@foo.com> writes: :> :> j> In any application/system of any significance these two go hand in :> j> hand. The second is achieved by crafting a constrained narrowly :> j> focused domain specific language _within_ Lisp, which allows the :> j> programmer to then work at the level of the domain, _both_ :> j> syntactically as well as semantically. This is why Lisp macros :> j> (please don't confuse with any other kind of macro you've come across :> j> before) are such a big deal. :> :> j> Now, admittedly, creating these is not something your typical code :> j> monkey is going to grok. This is one of the big reasons why Lisp will :> j> never be as "popular" as something like Java. But then your typical :> j> code monkey isn't going to be building your core internal application :> j> api either. Once you've built this though, even a code monkey will be :> j> a lot more productive and produce much more clean and robust code. :> :> I do not consider myself a Lisp programmer, but I have programmed :> enough Lisp to conclude that you probably are correct that the ability :> to create a constrained narrowly focused domain specific language :> within Lisp could very well outweigh the advantages of static typing. : : If you've been there, you know this. Actually, the incremental bottom : up development with _continual_ testing of almost every code snippet : is a significant advance above static typing. I do these little steps all the time, _with_ static type checks, documenting my expectations in lots of small test-programs. But why do you assume that static typing replaces the need to test every corner of the software? : In this sort of : development you are typically _extensively testing even partial : expressions or single clauses_ (well below the level of a function) : and at each increment of accretion testing that until you have a : function at which point it is tested. Yes, tested... : The upshot is you have a : stunning level of code path coverage - not just for type checks, but : logic checks as well. But the "incremental testing fans" do not assume that testing many cases will give them type coverage? Likewise, I guess they know that the set of paths tested and the set of paths taken at runtime may have little overlap in unwelcome cases (given some types are large)? -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 17:32 ` Georg Bauhaus @ 2004-09-07 13:48 ` jayessay 2004-09-07 15:13 ` Georg Bauhaus 2004-09-09 1:02 ` Randy Brukardt 0 siblings, 2 replies; 387+ messages in thread From: jayessay @ 2004-09-07 13:48 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com> ... > :> > :> I do not consider myself a Lisp programmer, but I have programmed > :> enough Lisp to conclude that you probably are correct that the ability > :> to create a constrained narrowly focused domain specific language > :> within Lisp could very well outweigh the advantages of static typing. > : > : If you've been there, you know this. Actually, the incremental bottom > : up development with _continual_ testing of almost every code snippet > : is a significant advance above static typing. > > I do these little steps all the time, _with_ static type checks, > documenting my expectations in lots of small test-programs. You can't. Because the sort of snippets I'm discussing are not even legal programs in things like C++/Ada/Eiffel/etc. How do you do stuff like this: ;; Does the log reader return the correct forms for a log file (alice:read-unanswered-log "../alice-unanswered.log") You can simply ask Lisp to try this and see the results ;; Is the format properly formed for output to a client bin widget (with-open-bin (:bin-id 1440691622 :session-number 12) (put-bin (alice:read-unanswered-log "./alice-unanswered.log"))) Same here - but this will also go over to a connected client and you can see if all that protocol is correctly working. (set-of-names (the-objects-in-bin 1440691622)) Just get a pretty printed output of the internal structure of the client widget content. Doing this in Ada/C++/Eiffel would require setting up a fairly big procedure/function with all sorts of withs or imports and instantiations, etc just to get to the one line out of hundred or so that you want to test. The whole idea is a complete non starter. Or how about: (with-protected-resource *main-database* (let ((broken-bits (ensure-consistent-state it))) (when broken-bits (pprint-db-items broken-bits)))) Here, you'd need to set up a couple of tasks and probably a protected object plus more boiler plate. You simply cannot do this sort of thing in stactic languages. You shouldn't be bothered by this because you are claiming static type checks are worth the price of losing this sort of thing. > But why do you assume that static typing replaces the need to test > every corner of the software? I don't. Obviously it doesn't. No one believes that it does. You are hacking at a strawman. > But the "incremental testing fans" do not assume that testing many > cases will give them type coverage? There is no assumption. First dynamic typing is as strong (robust) as static typing. Second, testing many cases is irrelevant. Testing _outside_ the expected envelope is key. Once you have accounted for this you are set to go. As you evolve the functionality input producing erroneous results (type or logic) is caught futher and further up the chain. At each point you account for this and continue. > Likewise, I guess they know that the set of paths tested and the set > of paths taken at runtime may have little overlap in unwelcome cases > (given some types are large)? See above. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 13:48 ` jayessay @ 2004-09-07 15:13 ` Georg Bauhaus 2004-09-07 15:54 ` jayessay 2004-09-09 1:02 ` Randy Brukardt 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-07 15:13 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> jayessay <nospam@foo.com> wrote: :> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com> : ... :> :> :> :> I do not consider myself a Lisp programmer, but I have programmed :> :> enough Lisp to conclude that you probably are correct that the ability :> :> to create a constrained narrowly focused domain specific language :> :> within Lisp could very well outweigh the advantages of static typing. :> : :> : If you've been there, you know this. Actually, the incremental bottom :> : up development with _continual_ testing of almost every code snippet :> : is a significant advance above static typing. :> :> I do these little steps all the time, _with_ static type checks, :> documenting my expectations in lots of small test-programs. : : You can't. Because the sort of snippets I'm discussing are not even : legal programs in things like C++/Ada/Eiffel/etc. : : How do you do stuff like this: : : ;; Does the log reader return the correct forms for a log file : (alice:read-unanswered-log "../alice-unanswered.log") with Alice; procedure test is begin Alice.read_unanswered_log("../alice-unanswered.log"); end test; : Doing this in Ada/C++/Eiffel would require setting up a fairly big : procedure/function with all sorts of withs or imports and : instantiations, etc just to get to the one line out of hundred or so : that you want to test. Huh? The fact that you have a big, hopefully tested and checked library/system full of convenient things in CL may be a plus if you can use it. If I have a big Ada library, I expect to use it as an Ada library. Ada is explicit and verbose. You get something in return. : The whole idea is a complete non starter. Not for me. A can live with some typing on the keyboard. If I want to do incremental try-out programming, I know where to get it. (Lisps, Smalltalk, ...) : Or how about: : : (with-protected-resource *main-database* : (let ((broken-bits (ensure-consistent-state it))) : (when broken-bits : (pprint-db-items broken-bits)))) : : : Here, you'd need to set up a couple of tasks and probably a protected : object plus more boiler plate. Here, someone has provided a set of identifiers implicitly setting up a couple of task and some such I guess. How much time has it taken to define all this using testing and run-time type checking, when you compare to the time needed to do the "same" thing with static type checks on? Seems a more interesting question. The possibility to do amazing things in Lisp is beside the point I think. : You simply cannot do this sort of thing in stactic languages. You : shouldn't be bothered by this because you are claiming static type : checks are worth the price of losing this sort of thing. Why should static type checking be in the way of every dynamic thing? True, sometimes being explicit about everything using types can be combersome plus Lisp has EVAL and macros, adding power... :> But why do you assume that static typing replaces the need to test :> every corner of the software? : : I don't. Obviously it doesn't. No one believes that it does. You : are hacking at a strawman. From what you were saying (sounding like static type checks are a waste of time) I thought it wasn't obvious. :> But the "incremental testing fans" do not assume that testing many :> cases will give them type coverage? : : There is no assumption. First dynamic typing is as strong (robust) as : static typing. At run-time only ... Or at try-out time, maybe? : Second, testing many cases is irrelevant. Testing : _outside_ the expected envelope is key. A type defines an envelope, known to both the compiler at compile time and the program at run time, or test time. So you have at least told your readers where outside is. Testing inside is important as well, because unless proven you don't know for sure which values are inside and outside, resp.. As someone said somewhere else in this thread, test the unexpected unexpected :-) : Once you have accounted for : this you are set to go. As you evolve the functionality input : producing erroneous results (type or logic) is caught futher and : further up the chain. At each point you account for this and : continue. And the use of types removes some of the need to test a function with arguments that cannot be passed to the function because the compiler has checked. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:13 ` Georg Bauhaus @ 2004-09-07 15:54 ` jayessay 2004-09-08 12:33 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: jayessay @ 2004-09-07 15:54 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > : > :> jayessay <nospam@foo.com> wrote: > :> : Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@.com> > : ... > :> :> > :> :> I do not consider myself a Lisp programmer, but I have programmed > :> :> enough Lisp to conclude that you probably are correct that the ability > :> :> to create a constrained narrowly focused domain specific language > :> :> within Lisp could very well outweigh the advantages of static typing. > :> : > :> : If you've been there, you know this. Actually, the incremental bottom > :> : up development with _continual_ testing of almost every code snippet > :> : is a significant advance above static typing. > :> > :> I do these little steps all the time, _with_ static type checks, > :> documenting my expectations in lots of small test-programs. > : > : You can't. Because the sort of snippets I'm discussing are not even > : legal programs in things like C++/Ada/Eiffel/etc. > : > : How do you do stuff like this: > : > : ;; Does the log reader return the correct forms for a log file > : (alice:read-unanswered-log "../alice-unanswered.log") > > with Alice; > procedure test is > begin > Alice.read_unanswered_log("../alice-unanswered.log"); > end test; This doesn't do you any good because the procedure does not return a value much less print it out in a form showing the internal structure of the result. Plus you still need to compile, link, and then execute (though emacs will help you a lot with that). > : Doing this in Ada/C++/Eiffel would require setting up a fairly big > : procedure/function with all sorts of withs or imports and > : instantiations, etc just to get to the one line out of hundred or so > : that you want to test. > > Huh? The fact that you have a big, hopefully tested and checked > library/system full of convenient things in CL may be a plus if you > can use it. Not just that - you create a sandbox where all this stuff is available for use and testing as you are developing. In particular this is all done incrementally. > If I have a big Ada library, I expect to use it as an Ada > library. Sure, but you don't get this sort of extremely interactive incremental development with the integrated results always available. > : The whole idea is a complete non starter. > > Not for me. A can live with some typing on the keyboard. If I want > to do incremental try-out programming, I know where to get it. > (Lisps, Smalltalk, ...) That's the point - you can't get this with static languages, so the idea is indeed a non starter there. > : Or how about: > : > : (with-protected-resource *main-database* > : (let ((broken-bits (ensure-consistent-state it))) > : (when broken-bits > : (pprint-db-items broken-bits)))) > : > : > : Here, you'd need to set up a couple of tasks and probably a protected > : object plus more boiler plate. > > Here, someone has provided a set of identifiers implicitly setting > up a couple of task and some such I guess. No that is what the with-protected-resource is providing along with the incremental results that you have been accumulating in your sandbox. > How much time has it taken to define all this using testing and > run-time type checking, when you compare to the time needed to do > the "same" thing with static type checks on? Seems a more > interesting question. The point is there is no time needed to set this up for this test as it is already there in your sandbox as the previous bit to which you are incrementally adding. So, basically the correct answer here is 0 time. > : You simply cannot do this sort of thing in stactic languages. You > : shouldn't be bothered by this because you are claiming static type > : checks are worth the price of losing this sort of thing. > > Why should static type checking be in the way of every dynamic > thing? It just is - what difference does the "why" part make? > :> But why do you assume that static typing replaces the need to test > :> every corner of the software? > : > : I don't. Obviously it doesn't. No one believes that it does. You > : are hacking at a strawman. > > From what you were saying (sounding like static type checks are > a waste of time) I thought it wasn't obvious. If what you have available is static type checking then clearly it isn't a waste of time. You basically have the thing backwards: If you have a dynamic language with "extreme programming" abilities then you don't miss static typing as what it covers is a _subset_ of what you get. > :> But the "incremental testing fans" do not assume that testing many > :> cases will give them type coverage? > : > : There is no assumption. First dynamic typing is as strong (robust) as > : static typing. > > At run-time only ... Or at try-out time, maybe? If I take "try-out time" to mean development time, the answer is both. > : Second, testing many cases is irrelevant. Testing > : _outside_ the expected envelope is key. > > A type defines an envelope, known to both the compiler at > compile time and the program at run time, or test time. The "both" here is typically not true in static languages. The reason should be clear: a type in static typing applies to _variables_ (it is supposed to define/constrain the kind of value a variable (including parameters and results) can "hold". Variables don't actually exist at runtime. So, no the program typically has no information about types at runtime in a static language. This is what so called RTTI is intended for in the very limited scope it provides. In a dynamic language, _values_ have types, variables are just binding locations, i.e., names which can be used to identify a potential value. Hence, full type information is available whenever there are values - either compile, load, or runtime. > : Once you have accounted for > : this you are set to go. As you evolve the functionality input > : producing erroneous results (type or logic) is caught futher and > : further up the chain. At each point you account for this and > : continue. > > And the use of types removes some of the need to test a function > with arguments that cannot be passed to the function because the > compiler has checked. I agree that is the "theory", but in practice with a dynamic system and interactive incremental development it doesn't actually matter as the types are checked anyway at the time you are checking logic. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 15:54 ` jayessay @ 2004-09-08 12:33 ` Georg Bauhaus 2004-09-08 13:17 ` Georg Bauhaus 0 siblings, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-09-08 12:33 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> : How do you do stuff like this: :> : :> : ;; Does the log reader return the correct forms for a log file :> : (alice:read-unanswered-log "../alice-unanswered.log") :> :> with Alice; :> procedure test is :> begin :> Alice.read_unanswered_log("../alice-unanswered.log"); :> end test; : : This doesn't do you any good because the procedure does not return a : value much less print it out in a form showing the internal structure : of the result. Plus you still need to compile, link, and then execute : (though emacs will help you a lot with that). Ah, wait, I was just showing what I would do in Ada provided I had your alice:-stuff. As someone has already been mention in another posting, how am I supposed to know that alice:read-unanswered-log is a function that returns a value different from the empty list? It could return a truth value as the comment above it reads as a question, "Does ...". How do you know that read_unanswered_log in my package Alice doesn't print out a dump? All this is beside the point as it talks about libraries. :> If I have a big Ada library, I expect to use it as an Ada :> library. : : Sure, but you don't get this sort of extremely interactive incremental : development with the integrated results always available. What's the measure for "extremely interactive"? Sure, writing tests is more work than typing testing expressions into a REPL. Hopefully the testing exppressions are saved and documented as regression test? I'd be courious about a comparison using empirical data for a program of at least a year of programming done by three or more persons and a few years of operation. :> If I want :> to do incremental try-out programming, I know where to get it. :> (Lisps, Smalltalk, ...) : : That's the point - you can't get this with static languages, so the : idea is indeed a non starter there. I can get something sufficiently similar for the purpose of writing a number of programs. And I know that in many cases the compiler has saved me time and reduced anger, and has been helpful in finding errors. :> Here, someone has provided a set of identifiers implicitly setting :> up a couple of task and some such I guess. : : No that is what the with-protected-resource is providing along with : the incremental results that you have been accumulating in your : sandbox. Right, incrementing takes time and testing, doesn't it? : The point is there is no time needed to set this up for this test as : it is already there in your sandbox as the previous bit to which you : are incrementally adding. There is no sandbox without someone having developed the things needed to build sandboxes. This takes time /= 0. :> Why should static type checking be in the way of every dynamic :> thing? : : It just is - what difference does the "why" part make? "It just is" is not a convincing answer. As a SNOBOL4 fan, I know that typed values and the ability to look at everything and to have the compiler at hand in a running program can work miracles, also miracles of program complexity a.k.a. cleverness. But saying that static type checks are in the way of every dynamic thing sounds like denying any kind of dynamics in a language like Ada (in a Humpty Dumpty style?). You cannot change executable pieces at runtime in a typical Ada implementation AFAIK. But with O-O classes of types operations are chosen at runtime. Is this not dynamic? :> : Second, testing many cases is irrelevant. Testing :> : _outside_ the expected envelope is key. :> :> A type defines an envelope, known to both the compiler at :> compile time and the program at run time, or test time. : : The "both" here is typically not true in static languages. Forgive me to think in terms of Ada. All Ada types do carry some type information, even if limited. Not the same type information that you get in CL, of course. But, with types and with variables - you get bounds, - you get ranges, - You can ask whether a value belongs to the set of values that a type has declared. - you can ask whether some type parameter is a definite type or not. - ... I agree this is not the same as type-of(value). But IIUC you are typically asked, in Ada, to provide functionality for a set of differently typed values not by type inspection and conditionals, but by using interfaces and being explicit about what you do at the outer level. It is still possible though, in particular with O-O types, to look at what subtype we have and base decisions on the result deeply inside some conditional. :> And the use of types removes some of the need to test a function :> with arguments that cannot be passed to the function because the :> compiler has checked. : : I agree that is the "theory", but in practice with a dynamic system : and interactive incremental development it doesn't actually matter as : the types are checked anyway at the time you are checking logic. When I have a type Direction is (North, East, South, West); and then a COND somewhere, case d is when North => bow; when South => spread_arms; when East => awake; when West => relax; end case; There is no need, in theory and practice, to test case coverage, because it is guaranteed by the language rules that the compiler obeys. Likewise, I cannot just add cases for Up and Down somewhere. What would I have to do to have the compiler tell me in CL? If this isn't possible, is there a way to predict the number of test expressions together with the average time each takes to find missing cases in all affected parts of the program? If it is possible, don't you think that it saves lots of time during code checking and in code restructuring as well? When I have type Foo is array (Direction) of Color; and then I create a value (North => Black, South => Yellow, East => Orange, West => Grey) I know this value will have been completely initialised with component values that are allowed for types Foo, Direction, and Color. Again less testing. If Direction is to be changed to include Up and Down as values, both the case distinction and the tuple won't be valid any longer and the compiler will let me know, as it checkes Foo-dependent things in the transitive closure of all units depending on the unit where Foo is defined. I find this rather practical, for example because it can guide the "refactoring" process without a need to run the tests mentioned above. The mechanism isn't fool proof, for example when `others` is used, but it saves time because a computer program (the compiler) points to code that will or might have to be changed when Foo changes. I think you will recognise this in ML pattern matching, too. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-08 12:33 ` Georg Bauhaus @ 2004-09-08 13:17 ` Georg Bauhaus 0 siblings, 0 replies; 387+ messages in thread From: Georg Bauhaus @ 2004-09-08 13:17 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: : Forgive me to think in terms of Ada. All Ada types do carry some type ^^^^^ Er, that shouldn't have been "types" of course. -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-07 13:48 ` jayessay 2004-09-07 15:13 ` Georg Bauhaus @ 2004-09-09 1:02 ` Randy Brukardt 2004-09-09 9:15 ` Dmitry A. Kazakov 1 sibling, 1 reply; 387+ messages in thread From: Randy Brukardt @ 2004-09-09 1:02 UTC (permalink / raw) "jayessay" <nospam@foo.com> wrote in message news:m3k6v6dwbn.fsf@rigel.goldenthreadtech.com... ... > You can't. Because the sort of snippets I'm discussing are not even > legal programs in things like C++/Ada/Eiffel/etc. > > How do you do stuff like this: > > ;; Does the log reader return the correct forms for a log file > (alice:read-unanswered-log "../alice-unanswered.log") > > You can simply ask Lisp to try this and see the results > > ;; Is the format properly formed for output to a client bin widget > (with-open-bin (:bin-id 1440691622 :session-number 12) > (put-bin (alice:read-unanswered-log "./alice-unanswered.log"))) > > Same here - but this will also go over to a connected client and you > can see if all that protocol is correctly working. Cute, but close to useless in my view. A test that doesn't have the results included in it (and preferably is automated to return Pass/Fail), or that isn't saved for future use, is just wasted effort. When the function in question is updated a year from now, you'll either have to recreate the entire set of tests, or simply forget the testing -- and either way you'll end up wasting a lot of time. Moreover, this sort of stuff is fine for simple functions, but it doesn't scale to subsystems, where there are many paths and options to test. And it is at the subsystem level where virtually all logic errors occur - it's hard to make a mistake in a three line function! >> But why do you assume that static typing replaces the need to test >> every corner of the software? > I don't. Obviously it doesn't. No one believes that it does. You > are hacking at a strawman. OK, let *me* hack at the strawman. The goal of programming languages ought to be to eliminate the need for testing. This is not a goal that is likely to be achievable, but the closer that we can come, the better. On low-criticality systems like the Trash Finder spam filter, I don't even bother to test updates anymore. I simply load it onto the mail server and check the logs occassionally for problems. I can do this because I have confidence in the design of the program that it will log any faults and save the offending message for testing any fix needed. I consider testing a last resort to use when you can't find any better way to insure the correctness of your software. Of course, in practice, you do have to use that last resort for time to time. Randy. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-09 1:02 ` Randy Brukardt @ 2004-09-09 9:15 ` Dmitry A. Kazakov 0 siblings, 0 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-09-09 9:15 UTC (permalink / raw) On Wed, 8 Sep 2004 20:02:36 -0500, Randy Brukardt wrote: > OK, let *me* hack at the strawman. The goal of programming languages ought > to be to eliminate the need for testing. This is not a goal that is likely > to be achievable, but the closer that we can come, the better. Hear here! -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-09-06 16:36 ` jayessay 2004-09-06 17:32 ` Georg Bauhaus @ 2004-09-07 22:18 ` Lionel Draghi 1 sibling, 0 replies; 387+ messages in thread From: Lionel Draghi @ 2004-09-07 22:18 UTC (permalink / raw) jayessay wrote: ... > Actually, the incremental bottom > up development with _continual_ testing of almost every code snippet > is a significant advance above static typing. > In this sort of > development you are typically _extensively testing even partial > expressions or single clauses_ (well below the level of a function) > and at each increment of accretion testing that until you have a > function at which point it is tested. In this sort of development, you typically *don't* do any extensive testing. You more often just test typical use-cases. Doing extensive testing will certainly not be done with an informal method. For extensive testing, you need some coverage tools, and this is obviously not specific to Agile methods. If you really want to increase your productivity, just try to avoid testing by using formal proof or static analysis tools. And once more here, strong typing will be your best friend. -- Lionel Draghi ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 10:20 ` Georg Bauhaus 2004-08-28 10:30 ` Adrian Knoth @ 2004-08-28 14:45 ` User Name 2004-08-28 20:02 ` Alexander E. Kopilovich 2 siblings, 0 replies; 387+ messages in thread From: User Name @ 2004-08-28 14:45 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > (For example, Robert Axelrodt (The Complexity of Cooperation, 1997, > Princeton University Press) ... quotes ... > But what will people who know these languages say about the > comments? That Robert Axelrodt is clearly an incompetent in this area and should not be taken seriously by anyone with even the slightest clue. It's telling that he uses "FORTRAN" and "LISP", neither of which is correct. Lisp hasn't been LISP for over 20 years. Also, in this sort of context simply using "Lisp" is bogus, as there is no language named Lisp. Actually, that's probably been true for over 20 years as well. And, ANSI standard Common Lisp, the primary Lisp language currently in use, is every bit an industrial strength general purpose programming language as the typically cited, yet far more pedestrian, C++, Java, etc. > "If a friend or coworker is available to answer questions about > Pascal, for example, pick Pascal..." This is so absolutely ridiculous as to evoke embarassment for the author. > "C++ was chosen as the foundation for the Java programming language" This is just nonsense and simply false. > "If you are fairly sure that you will be doing programming for some > time and want to start with a language that you can grow with, then > C or C++ is the best choice." Complete garbage. It may not even be the best advice at this point if you substitute "can make money with" for "can grow with". > http://pscs.physics.lsa.umich.edu/Software/ComplexCoop.html, Anyone who uses Pascal for GA is a complete idiot. /Jon -- 'jay' - a n t h o n y at romeo/november/charley com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-28 10:20 ` Georg Bauhaus 2004-08-28 10:30 ` Adrian Knoth 2004-08-28 14:45 ` User Name @ 2004-08-28 20:02 ` Alexander E. Kopilovich 2 siblings, 0 replies; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-08-28 20:02 UTC (permalink / raw) To: comp.lang.ada Georg Bauhaus wrote: > Quite a few people I've met didn't like Ada because of they have > seen it as associated with the political, military, and industrial > organisations mentioned in Richard Riehle's posting. Indeed, > if computer languages and compilers do not care about the purpose > of a program, people do. (This is a reason why I'm somewhat uncomfortable > using Ada, sometimes. The military and the weapon makers seem to > be so close... ;-) As far as I know, many programmers (and even many software engineers) do not care much abour military use of their software, but they do care much about the psychological issues, which immediately surround their everyday's work. And this is exactly the reputation of the military and the weapon makers regarding those matters, which tells to many programmers that they better should not come too near to those areas. These people generally aren't pacifists at all, but they guess that it will be hard and unpleasant for them to maintain compatibility with military procedural logic and military customer's habits - and they do not feel necessary to put themselves into that environment in peace time. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 21:48 ` Kevin Cline 2004-08-28 5:02 ` Richard Riehle 2004-08-28 10:20 ` Georg Bauhaus @ 2004-08-30 12:20 ` Jano 2 siblings, 0 replies; 387+ messages in thread From: Jano @ 2004-08-30 12:20 UTC (permalink / raw) Kevin Cline wrote: > Are there any CS programs that have chosen Ada as their core language? Yes, at least in Spain. > I rarely meet recent graduates with any exposure to Ada at all. For > better or worse, (worse in my opinion), most CS departments seem to > have settled on Java. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 16:39 ` Kevin Cline 2004-08-20 17:41 ` Richard Riehle @ 2004-08-20 19:50 ` Jeffrey Carter 2004-08-26 20:42 ` Kevin Cline 2004-08-26 21:52 ` Kevin Cline 1 sibling, 2 replies; 387+ messages in thread From: Jeffrey Carter @ 2004-08-20 19:50 UTC (permalink / raw) Kevin Cline wrote: > I think the very existence of limited types is a fundamental flaw in > Ada. The ability to create types for which there are no operations except those defined by the developer is essential for creating useful abstractions. Since the creation of useful abstractions is the hallmark of software engineering, it is not surprising that Ada is the language of choice for the 2% of developers who are software engineers, and disliked by the 98% who are coders and should not be allowed to design software of any importance. > It doesn't matter to me that weak programmers can theoretically make a > mess in C++. What matters is the amount of effort required for a good > programmer to produce sound code, and Ada is simply not competitive > for most applications. It is the ease with which even very good developers make messes in C++ that has led to the decline in its popularity, and many are looking at Java, C#, and Ada for a better alternative. -- Jeff Carter "Ditto, you provincial putz?" Blazing Saddles 86 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 19:50 ` Jeffrey Carter @ 2004-08-26 20:42 ` Kevin Cline 2004-08-27 1:22 ` Jeffrey Carter 2004-08-26 21:52 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Kevin Cline @ 2004-08-26 20:42 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote in message news:<4CsVc.28876$9Y6.4063@newsread1.news.pas.earthlink.net>... > Kevin Cline wrote: > > > I think the very existence of limited types is a fundamental flaw in > > Ada. > > The ability to create types for which there are no operations except > those defined by the developer is essential for creating useful > abstractions. Since the creation of useful abstractions is the hallmark > of software engineering, it is not surprising that Ada is the language > of choice for the 2% of developers who are software engineers, and > disliked by the 98% who are coders and should not be allowed to design > software of any importance. It's unfortunate to see this circular ad-hominem argument is repeated over and over again in this newsgroup. "I am a good programmer. I like Ada. Therefore all good programmers should like Ada. Programmers who don't like Ada must be poor programmers." And even the first assertion is doubtful. No progress can come from this argument. Better to notice that a lot of very good programmers have rejected Ada, and figure out why. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-26 20:42 ` Kevin Cline @ 2004-08-27 1:22 ` Jeffrey Carter 2004-08-27 15:22 ` Kevin Cline 0 siblings, 1 reply; 387+ messages in thread From: Jeffrey Carter @ 2004-08-27 1:22 UTC (permalink / raw) Kevin Cline wrote: > It's unfortunate to see this circular ad-hominem argument is repeated > over and over again in this newsgroup. "I am a good programmer. I > like Ada. Therefore all good programmers should like Ada. > Programmers who don't like Ada must be poor programmers." And even > the first assertion is doubtful. > > No progress can come from this argument. Better to notice that a lot > of very good programmers have rejected Ada, and figure out why. No progress can come when a statement of facts (2% of developers are software engineers) is treated as an attack. (There are plenty of "good programmers" who are not software engineers.) If someone sees himself in the facts and doesn't like what he sees, that does not qualify as an attack. It has been known for at least 3 decades that a very small proportion of developers are orders of magnitude more effective than the rest. The common characteristics of these effective developers include avoiding unnecessary complexity, creating usable abstractions, and putting much more effort into pre-code activites. In my 29 years of professional software-development experience, I have found that only about 2% of developers fall into this category. I have also found that about 2% of developers like Ada and dislike the C family of languages, and the other 98% have the opposite opinion. That there is significant overlap between software engineers and those who like Ada is not surprising. I call the 2% of effective software developers software engineers, and the other 98%, coders. What we have in software development is a failure to distinguish between these 2 groups. Allowing coders to design software and make language choices is the same as allowing construction workers to design bridges and decide what construction materials to use. We would not be surprised to have bridges that failed as often as software does. -- Jeff Carter "My legs are gray, my ears are gnarled, my eyes are old and bent." Monty Python's Life of Brian 81 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 1:22 ` Jeffrey Carter @ 2004-08-27 15:22 ` Kevin Cline 2004-08-27 16:26 ` Georg Bauhaus 2004-08-27 18:08 ` Jeffrey Carter 0 siblings, 2 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-27 15:22 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote in message news:<M1wXc.14455$3O3.2233@newsread2.news.pas.earthlink.net>... > Kevin Cline wrote: > > > It's unfortunate to see this circular ad-hominem argument is repeated > > over and over again in this newsgroup. "I am a good programmer. I > > like Ada. Therefore all good programmers should like Ada. > > Programmers who don't like Ada must be poor programmers." And even > > the first assertion is doubtful. > > > > No progress can come from this argument. Better to notice that a lot > > of very good programmers have rejected Ada, and figure out why. > > No progress can come when a statement of facts (2% of developers are > software engineers) is treated as an attack. (There are plenty of "good > programmers" who are not software engineers.) If someone sees himself in > the facts and doesn't like what he sees, that does not qualify as an attack. > > It has been known for at least 3 decades that a very small proportion of > developers are orders of magnitude more effective than the rest. The > common characteristics of these effective developers include avoiding > unnecessary complexity, creating usable abstractions, and putting much > more effort into pre-code activites. The efficacy of much pre-code activity is debatable. Many organizations have had great success with more agile methods of minimal up-front design followed by test-driven development and continuous refactoring. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 15:22 ` Kevin Cline @ 2004-08-27 16:26 ` Georg Bauhaus 2004-08-30 19:08 ` Kevin Cline 2004-08-27 18:08 ` Jeffrey Carter 1 sibling, 1 reply; 387+ messages in thread From: Georg Bauhaus @ 2004-08-27 16:26 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : The efficacy of much pre-code activity is debatable. Many : organizations have had great success with more agile methods of : minimal up-front design followed by test-driven development and : continuous refactoring. Yes and even some tricks can be helpful to get something going. But how can "refactoring" be done well without quite some thinking and planning, that is without something that happens before coding? Isn't "refactoring" sometimes a redesign of the modular structure of some software? I wouldn't call this activity "coding". -- Georg ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 16:26 ` Georg Bauhaus @ 2004-08-30 19:08 ` Kevin Cline 0 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-30 19:08 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cgnnc9$au4$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > > : The efficacy of much pre-code activity is debatable. Many > : organizations have had great success with more agile methods of > : minimal up-front design followed by test-driven development and > : continuous refactoring. > > Yes and even some tricks can be helpful to get something going. > But how can "refactoring" be done well without quite some thinking > and planning, that is without something that happens before coding? > Isn't "refactoring" sometimes a redesign of the modular structure of > some software? I wouldn't call this activity "coding". Most refactoring is local -- observing common code in two methods and collecting it into a new method. But sometimes, indeed, one sees that larger structural improvements would be beneficial. Following agile methods, you never undertake a gross rewrite of working software. Instead you make incremental changes to the code, testing after each change, until the desired new structure is achieved. It takes a bit of practice to learn how to get large changes done incrementally, but it can be done. So you design a little, code a little, and test a little until it's done. Rarely is there "quite some thinking and planning". I find that designing for a long time without coding, or coding for a long time without testing is like trying to driver a car while only looking at the road once every fifteen seconds. You tend to spend a lot of time getting back on the road. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 15:22 ` Kevin Cline 2004-08-27 16:26 ` Georg Bauhaus @ 2004-08-27 18:08 ` Jeffrey Carter 2004-08-28 14:05 ` Kevin Cline 1 sibling, 1 reply; 387+ messages in thread From: Jeffrey Carter @ 2004-08-27 18:08 UTC (permalink / raw) Kevin Cline wrote: > The efficacy of much pre-code activity is debatable. Many > organizations have had great success with more agile methods of > minimal up-front design followed by test-driven development and > continuous refactoring. The success of agile methods is debatable. Much of agile methods is simply a rehash of the rapid prototyping spiral methods of the 1970s intended to elicit requirements, and those are excellent methods when requirements are unclear. The main difference between those methods and agile methods is that the latter eliminates the final iteration of the spiral methods, in which the now well defined requirements are used to create a design, which is then implementated, possibly reusing some of the code from the prototypes. Whether this is a success depends upon the definition of success. If success is measured in cost to initial deployment, or when you can charge your customers more to fix errors, it probably is a success. When success is based on the reliability and correctness of the software, or the total lifecycle cost of the software, the success of agile methods is unproven. -- Jeff Carter "Have you gone berserk? Can't you see that that man is a ni?" Blazing Saddles 38 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-27 18:08 ` Jeffrey Carter @ 2004-08-28 14:05 ` Kevin Cline 0 siblings, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-28 14:05 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote in message news:<aMKXc.203$8d1.94@newsread2.news.pas.earthlink.net>... > Kevin Cline wrote: > > > The efficacy of much pre-code activity is debatable. Many > > organizations have had great success with more agile methods of > > minimal up-front design followed by test-driven development and > > continuous refactoring. > > The success of agile methods is debatable. Much of agile methods is > simply a rehash of the rapid prototyping spiral methods of the 1970s > intended to elicit requirements, and those are excellent methods when > requirements are unclear. The main difference between those methods and > agile methods is that the latter eliminates the final iteration of the > spiral methods, in which the now well defined requirements are used to > create a design, which is then implementated, possibly reusing some of > the code from the prototypes. I think the main ideas of agile development are test-driven development, and continuous refactoring of code. Neither was a key practice in 1970s style rapid prototyping methods. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 19:50 ` Jeffrey Carter 2004-08-26 20:42 ` Kevin Cline @ 2004-08-26 21:52 ` Kevin Cline 1 sibling, 0 replies; 387+ messages in thread From: Kevin Cline @ 2004-08-26 21:52 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote in message news:<4CsVc.28876$9Y6.4063@newsread1.news.pas.earthlink.net>... > Kevin Cline wrote: > > > I think the very existence of limited types is a fundamental flaw in > > Ada. > > The ability to create types for which there are no operations except > those defined by the developer is essential for creating useful > abstractions. Since the creation of useful abstractions is the hallmark > of software engineering, it is not surprising that Ada is the language > of choice for the 2% of developers who are software engineers, and > disliked by the 98% who are coders and should not be allowed to design > software of any importance. > > > It doesn't matter to me that weak programmers can theoretically make a > > mess in C++. What matters is the amount of effort required for a good > > programmer to produce sound code, and Ada is simply not competitive > > for most applications. > > It is the ease with which even very good developers make messes in C++ > that has led to the decline in its popularity, and many are looking at > Java, C#, and Ada for a better alternative. I suppose we have different definitions of "very good". I see the same developers who made messes in C++ making messes in C# and Java. The only difference in C# and Java is that the mess is not so obvious. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 0:30 ` Richard Riehle 2004-08-18 1:29 ` Björn Persson 2004-08-20 16:39 ` Kevin Cline @ 2004-08-20 17:53 ` Alexander E. Kopilovich 2004-08-21 1:34 ` Richard Riehle 2 siblings, 1 reply; 387+ messages in thread From: Alexander E. Kopilovich @ 2004-08-20 17:53 UTC (permalink / raw) To: comp.lang.ada Richard Riehle wrote: > There are a few simple underlying ideas in the language. One > of them is type safety, and that has never been beyond the > comprehension of any programmer. The idea that seems to > have been difficult to grasp, even by many who consider themselves > sophisticated software developers, is the separation of scope > and visibility. Chapter Eight of the ALRM is rarely read by > anyone, it seems. Certainly so. It was said many times (here in c.l.a. and elsewhere) by the most authoritative Ada experts that ALRM is NOT intended for use by regular software developer but it is for Ada experts (mostly by Ada compiler writers). And in many places it is indeed difficult to read - because information is not strictly localised - you can never be sure that there is no important bit of related information somewhere, in some distant place of the ALRM. Actually, a reader of ALRM can't be sure of any broad statement if s/he did not study the ALRM comprehensively - and naturally, almost no one except professional Ada experts can afford that. The idea of type safety is easy because it is an abstract idea, Ada did not invent (or even modify) but just employs it. In other words, this idea is easy for a programmer because it comes not from ALRM, and actually not from Ada -;) . But the separation of visibility and scope, which you mentioned, never was formulated as a clear abstract idea, it is closely associated with Ada - and therefore there is no affordable way to understand it properly as a separate idea. > The benefits of the visibility rules needs to be given emphasis. Those > rules are among the most powerful benefits of Ada, even though > some programmers continue to see them as a nuisance. Then what prevents you (or someone else) from explaining this idea - first in some abstract form and then showing how this abstract idea is employed in Ada language? Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-20 17:53 ` Alexander E. Kopilovich @ 2004-08-21 1:34 ` Richard Riehle 0 siblings, 0 replies; 387+ messages in thread From: Richard Riehle @ 2004-08-21 1:34 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:mailman.7.1093024431.28011.comp.lang.ada@ada-france.org... > Richard Riehle wrote: > > > The benefits of the visibility rules needs to be given emphasis. Those > > rules are among the most powerful benefits of Ada, even though > > some programmers continue to see them as a nuisance. > Then what prevents you (or someone else) from explaining this idea - first > in some abstract form and then showing how this abstract idea is employed in > Ada language? > Nothing prevents us from explaining this idea except the fact that it is so unique, so language specific. When I am in the classroom setting, I do place a lot of emphasis on this aspect of the language. I focus on its benefits rather than what some see as its liabilities. I frequently used to myself annoyed with the property of physics we call gravity. Each time I try to defy it, I am sorely disappointed. After a few years of living under its restrictions, I began to discover its virtues. In the case of separation of scope and visibility, I have come to appreciate the virtues of that feature. I have learned to use it to good advantage. In many cases, those who have learned Ada under my tutelage have learned the same appreciation, and some have even become excellent software designers because of, not in spite of this language capability. Richard Riehle ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 23:54 ` Kevin Cline 2004-08-18 0:30 ` Richard Riehle @ 2004-08-18 0:37 ` Jeffrey Carter 2004-08-18 1:53 ` Steve 2004-08-18 8:58 ` Dmitry A. Kazakov 3 siblings, 0 replies; 387+ messages in thread From: Jeffrey Carter @ 2004-08-18 0:37 UTC (permalink / raw) Kevin Cline wrote: > > I don't your guru got it quite right. Ada failed because most > programmers who tried it found Ada programming to be relative less > productive than programming in other available languages. Ada never > attracted a large enough base of motivated users to develop the > libraries and IDEs that would make it easy to use. Even with > available public domain compilers, almost no one is choosing to > program in Ada. Where there is hard data available, rather than biased opinion such as this, they consistently show that Ada projects reach delivery with half the cost of similar projects in "popular" languages such as C. I doubt if most people agree that more productive means more expensive. -- Jeff Carter "C's solution to this [variable-sized arrays] has real problems, and people who are complaining about safety definitely have a point." Dennis Ritchie 25 ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 23:54 ` Kevin Cline 2004-08-18 0:30 ` Richard Riehle 2004-08-18 0:37 ` Jeffrey Carter @ 2004-08-18 1:53 ` Steve 2004-08-18 8:58 ` Dmitry A. Kazakov 3 siblings, 0 replies; 387+ messages in thread From: Steve @ 2004-08-18 1:53 UTC (permalink / raw) The demise of Ada has been greatly exaggerated. As I see it, with the increasing concern regarding software security and reliability Ada is just about to come of age... Steve (The Duck) ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-17 23:54 ` Kevin Cline ` (2 preceding siblings ...) 2004-08-18 1:53 ` Steve @ 2004-08-18 8:58 ` Dmitry A. Kazakov 2004-08-18 10:04 ` Jean-Pierre Rosen 2004-08-18 10:32 ` Björn Persson 3 siblings, 2 replies; 387+ messages in thread From: Dmitry A. Kazakov @ 2004-08-18 8:58 UTC (permalink / raw) On 17 Aug 2004 16:54:18 -0700, Kevin Cline wrote: > I don't your guru got it quite right. Ada failed because most > programmers who tried it found Ada programming to be relative less > productive than programming in other available languages. I do not think so. When I started to work with Ada I found it more productive than FORTRAN, PL/1 or C (the most popular languages that time, around me. Well there were also unpopular Algol 60, awful COBOL, dreadful Forth, half-baked Pascal and nice, but unavailable Modula) I believe that Ada 83 came too early and looked too far ahead, so it failed to solve many of the problems it tried to. These problems (with ADT, concurrency, checkability) are not solved in either language until now. > Ada never > attracted a large enough base of motivated users to develop the > libraries and IDEs that would make it easy to use. That time there were no user movements we observe now. That Borland chose Pascal and not Ada was rather a coincident (probably they wanted not to be bound by any standard, making a product for what was seen as a "play station".) I also suspect that GNU people chose C just because they didn't trust in their ability to create a quality compiler in an observable period of time and get it working on small machines. > In a nutshell, Ada is not popular because most people who have tried > it didn't like it. I think that they rather didn't try it at all. I believe you overestimate people's desire to try languages. My guess is that 50% of people just stay with the first language they finished the first real project. 40% remain by the second language. The criteria of selecting first two languages are not in Ada's favor: 1. What I was taught 2. What is used around me 3. Current hype -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 8:58 ` Dmitry A. Kazakov @ 2004-08-18 10:04 ` Jean-Pierre Rosen 2004-08-18 17:55 ` Ludovic Brenta 2004-08-25 18:26 ` John Kern 2004-08-18 10:32 ` Björn Persson 1 sibling, 2 replies; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-08-18 10:04 UTC (permalink / raw) > That time there were no user movements we observe now. That Borland > chose > Pascal and not Ada was rather a coincident (probably they wanted not > to be > bound by any standard, making a product for what was seen as a "play > station".) Historical note: Borland did consider making an Ada compiler at some point, but gave up when they discovered they couldn't make a Borland Ada "better" than regular Ada. The team they hired at that time tried to continue the project by themselves (they asked me to participate), but it never came out. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 10:04 ` Jean-Pierre Rosen @ 2004-08-18 17:55 ` Ludovic Brenta 2004-08-18 17:58 ` Ed Falis 2004-08-19 7:41 ` Jean-Pierre Rosen 2004-08-25 18:26 ` John Kern 1 sibling, 2 replies; 387+ messages in thread From: Ludovic Brenta @ 2004-08-18 17:55 UTC (permalink / raw) Jean-Pierre Rosen writes: > Historical note: > Borland did consider making an Ada compiler at some point, but gave up > when they discovered they couldn't make a Borland Ada "better" than > regular Ada. > > The team they hired at that time tried to continue the project by > themselves (they asked me to participate), but it never came out. That's interesting. Even back then before "standard" was a buzzword, they understood that standards are meant to benefit the users by making vendors interchangeable. They did not want to be interchangeable; they wanted their customers to be captive. This is the same line of thought that brought proprietary software about a few years earlier. Back in 1989, I used to respect Borland for the quality of their compilers. But now, in hindsight, what you said changed my perspective. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 17:55 ` Ludovic Brenta @ 2004-08-18 17:58 ` Ed Falis 2004-08-19 7:41 ` Jean-Pierre Rosen 1 sibling, 0 replies; 387+ messages in thread From: Ed Falis @ 2004-08-18 17:58 UTC (permalink / raw) On Wed, 18 Aug 2004 19:55:04 +0200, Ludovic Brenta <ludovic.brenta@insalien.org> wrote: > Back in 1989, I used to respect Borland for the quality of their > compilers. But now, in hindsight, what you said changed my > perspective. But that was the flavor of the times. And one's stance on intellectual property is distinct from the quality of one's products. So, your respect for their technical achievements was not wasted. - Ed -- "When I was a kid, I wanted to grow up to be a wise man. Somehow, I just turned out to be a wise guy". ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 17:55 ` Ludovic Brenta 2004-08-18 17:58 ` Ed Falis @ 2004-08-19 7:41 ` Jean-Pierre Rosen 2004-08-19 14:36 ` Larry Kilgallen 1 sibling, 1 reply; 387+ messages in thread From: Jean-Pierre Rosen @ 2004-08-19 7:41 UTC (permalink / raw) Ludovic Brenta a écrit : > Back in 1989, I used to respect Borland for the quality of their > compilers. But now, in hindsight, what you said changed my > perspective. > Nothing new here. Borland never obeyed by the standards. Turbo Pascal always had "extensions". And I remember playing with Turbo Prolog that was conformant to no other Prolog of the time. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-19 7:41 ` Jean-Pierre Rosen @ 2004-08-19 14:36 ` Larry Kilgallen 2004-08-30 14:00 ` Jacob Sparre Andersen 0 siblings, 1 reply; 387+ messages in thread From: Larry Kilgallen @ 2004-08-19 14:36 UTC (permalink / raw) In article <ril1gc.5g7.ln@skymaster>, Jean-Pierre Rosen <rosen@adalog.fr> writes: > Ludovic Brenta a =E9crit : > >> Back in 1989, I used to respect Borland for the quality of their >> compilers. But now, in hindsight, what you said changed my >> perspective. >>=20 > Nothing new here. Borland never obeyed by the standards. Turbo Pascal=20 > always had "extensions". And I remember playing with Turbo Prolog that=20 > was conformant to no other Prolog of the time. For the Pascal case, _every_ Pascal seemed to have extensions, since real world applications have greater needs than the original teaching mission of Pascal. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-19 14:36 ` Larry Kilgallen @ 2004-08-30 14:00 ` Jacob Sparre Andersen 2004-08-30 15:27 ` Martin Krischik 0 siblings, 1 reply; 387+ messages in thread From: Jacob Sparre Andersen @ 2004-08-30 14:00 UTC (permalink / raw) Larry Kilgallen wrote: > For the Pascal case, _every_ Pascal seemed to have extensions, since > real world applications have greater needs than the original > teaching mission of Pascal. Yes. But I was quite disappointed when I noticed that Borland didn't even implement all of Pascal in their "Pascal" compiler. The one thing I still can remember was missing is returning record types from functions. Jacob -- �I like it when the support group complains that they have insufficient data on mean time to repair bugs in Ada software.� -- Robert I. Eachus ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-30 14:00 ` Jacob Sparre Andersen @ 2004-08-30 15:27 ` Martin Krischik 0 siblings, 0 replies; 387+ messages in thread From: Martin Krischik @ 2004-08-30 15:27 UTC (permalink / raw) Jacob Sparre Andersen wrote: > Larry Kilgallen wrote: > >> For the Pascal case, _every_ Pascal seemed to have extensions, since >> real world applications have greater needs than the original >> teaching mission of Pascal. > > Yes. > > But I was quite disappointed when I noticed that Borland didn't even > implement all of Pascal in their "Pascal" compiler. The one thing I > still can remember was missing is returning record types from > functions. The full ISO standart also has indefinate arrays with some kind of 'first and 'last mechanism. Isn't there in TurboPascal either. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 10:04 ` Jean-Pierre Rosen 2004-08-18 17:55 ` Ludovic Brenta @ 2004-08-25 18:26 ` John Kern 1 sibling, 0 replies; 387+ messages in thread From: John Kern @ 2004-08-25 18:26 UTC (permalink / raw) Jean-Pierre Rosen <rosen@adalog.fr> wrote in message > Historical note: > Borland did consider making an Ada compiler at some point, but gave up > when they discovered they couldn't make a Borland Ada "better" than > regular Ada. > The way I remember it, Borland wanted wanted to do a Turbo Ada, but were prevented from using the copywrighted(?) name Ada unless the product passed the validation suites, and they were not prepared to implement full tasking capabilities in a $99 compiler. ^ permalink raw reply [flat|nested] 387+ messages in thread
* Re: ADA Popularity Discussion Request 2004-08-18 8:58 ` Dmitry A. Kazakov 2004-08-18 10:04 ` Jean-Pierre Rosen @ 2004-08-18 10:32 ` Björn Persson 1 sibling, 0 replies; 387+ messages in thread From: Björn Persson @ 2004-08-18 10:32 UTC (permalink / raw) Dmitry A. Kazakov wrote: > That Borland chose > Pascal and not Ada was rather a coincident (probably they wanted not to be > bound by any standard, making a product for what was seen as a "play > station".) You're saying they seriously considered writing "Turbo Ada" instead of Turbo Pascal? That's interesting. Do you have any sources? > I also suspect that GNU people chose C just because they didn't > trust in their ability to create a quality compiler in an observable period > of time and get it working on small machines. I've always thought they didn't really choose a language; they wanted to clone Unix, and Unix was associated with C. But what do I know? -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 387+ messages in thread
end of thread, other threads:[~2004-09-22 20:51 UTC | newest] Thread overview: 387+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-01 12:18 ADA Popularity Discussion Request Lionel.DRAGHI -- strict thread matches above, loose matches on Subject: below -- 2004-08-31 17:58 Lionel.DRAGHI 2004-09-01 7:21 ` Ole-Hjalmar Kristensen 2004-08-26 2:08 Robert C. Leif 2004-08-11 13:56 Chris Humphries 2004-08-11 14:14 ` Hyman Rosen 2004-08-11 15:39 ` sk 2004-08-11 15:54 ` Marc A. Criley 2004-08-12 4:54 ` Larry Kilgallen 2004-08-13 2:29 ` Brian May 2004-08-13 5:27 ` Ada " Puckdropper 2004-08-21 3:41 ` ADA " Wes Groleau 2004-08-26 21:11 ` Warren W. Gay VE3WWG 2004-08-27 10:30 ` Georg Bauhaus 2004-08-31 16:34 ` Warren W. Gay VE3WWG 2004-08-31 17:48 ` Georg Bauhaus 2004-09-01 16:58 ` Warren W. Gay VE3WWG 2004-09-10 23:12 ` Kevin Cline 2004-09-12 16:50 ` jayessay 2004-08-11 15:45 ` Jerry Petrey 2004-08-11 15:55 ` Hyman Rosen 2004-08-11 16:54 ` Georg Bauhaus 2004-08-11 17:14 ` Nick Roberts 2004-08-11 18:00 ` Hyman Rosen 2004-08-12 11:48 ` Marin David Condic 2004-08-26 8:07 ` Adrian Hoe 2004-08-26 11:52 ` Marin David Condic 2004-08-27 8:10 ` Adrian Hoe 2004-08-27 14:37 ` Ed Falis 2004-08-27 17:52 ` Richard Riehle 2004-08-27 18:20 ` Hyman Rosen 2004-08-27 22:45 ` Wes Groleau 2004-09-03 6:48 ` Adrian Hoe 2004-09-03 12:14 ` stephane richard 2004-09-03 17:33 ` Björn Persson 2004-08-11 18:58 ` fabio de francesco 2004-08-12 0:05 ` Larry Elmore 2004-08-12 12:29 ` Adam Ruth 2004-08-13 6:55 ` Wojtek Narczynski 2004-08-12 22:41 ` Richard Riehle 2004-08-12 23:20 ` Ed Falis 2004-08-13 0:37 ` Nick Roberts 2004-08-13 1:22 ` Ed Falis 2004-08-13 7:01 ` Richard Riehle 2004-08-13 2:55 ` Matt Morgan 2004-08-14 7:26 ` j [not found] ` <fvavh0lmv0644gn5dt45sbj574t3ivqhlt@4ax.com> 2004-08-15 21:26 ` Nick Roberts 2004-08-16 1:02 ` Richard Riehle 2004-08-16 21:09 ` Keith H Duggar 2004-08-16 22:24 ` Ludovic Brenta 2004-08-16 22:30 ` Ed Falis 2004-08-17 6:13 ` Keith H Duggar 2004-08-17 20:13 ` Ludovic Brenta 2004-08-16 22:26 ` Ed Falis 2004-08-17 6:28 ` Keith H Duggar 2004-08-17 13:30 ` Ed Falis 2004-08-17 13:38 ` Martin Dowie 2004-08-18 3:30 ` Dale Stanbrough 2004-08-17 7:50 ` Dmitry A. Kazakov [not found] ` <mfb4i09d5kqk8fjdfmrj62kgmooftf1ma8@4ax.com> 2004-08-18 8:58 ` Dmitry A. Kazakov 2004-08-26 5:22 ` Dave Thompson 2004-08-26 8:06 ` Dale Stanbrough 2004-08-26 13:37 ` Martin Krischik 2004-08-26 8:14 ` Dmitry A. Kazakov 2004-08-26 17:28 ` Hyman Rosen 2004-08-17 10:58 ` Marin David Condic 2004-08-17 11:33 ` Martin Dowie 2004-08-17 11:59 ` Marin David Condic 2004-08-17 12:49 ` Martin Dowie 2004-08-17 13:07 ` Marin David Condic 2004-08-19 14:53 ` Martin Dowie 2004-08-17 12:33 ` Georg Bauhaus 2004-08-17 12:54 ` Marin David Condic 2004-08-26 1:27 ` Randy Brukardt 2004-08-26 11:49 ` Marin David Condic 2004-08-17 12:58 ` Martin Dowie 2004-08-17 13:06 ` Martin Dowie 2004-08-17 23:54 ` Kevin Cline 2004-08-18 0:30 ` Richard Riehle 2004-08-18 1:29 ` Björn Persson 2004-08-20 16:39 ` Kevin Cline 2004-08-20 17:41 ` Richard Riehle 2004-08-21 23:23 ` fabio de francesco 2004-08-22 7:16 ` fabio de francesco 2004-08-22 9:44 ` Richard Riehle 2004-08-23 0:18 ` fabio de francesco 2004-08-23 3:44 ` Wes Groleau 2004-08-26 21:36 ` Kevin Cline 2004-08-27 11:39 ` Georg Bauhaus 2004-08-29 15:08 ` jayessay 2004-08-30 19:59 ` Kevin Cline 2004-09-02 14:26 ` jayessay 2004-08-30 20:21 ` Kevin Cline 2004-08-23 15:23 ` Richard Riehle 2004-08-26 21:08 ` Kevin Cline 2004-08-27 5:23 ` Wes Groleau 2004-08-27 17:29 ` Kevin Cline 2004-08-27 22:50 ` Wes Groleau 2004-08-27 11:45 ` Georg Bauhaus 2004-08-27 18:22 ` Kevin Cline 2004-08-27 19:14 ` Hyman Rosen 2004-08-28 14:17 ` Kevin Cline 2004-08-28 18:07 ` Georg Bauhaus 2004-08-29 16:14 ` jayessay 2004-08-30 17:30 ` Hyman Rosen 2004-08-27 21:42 ` Kevin Cline 2004-08-29 6:22 ` Martin Krischik 2004-08-31 7:25 ` Kevin Cline 2004-08-31 9:37 ` Jean-Pierre Rosen 2004-08-31 10:54 ` Martin Dowie 2004-08-31 12:42 ` Hyman Rosen 2004-08-31 13:22 ` Hyman Rosen 2004-08-31 16:02 ` Georg Bauhaus 2004-08-31 17:29 ` Jean-Pierre Rosen 2004-08-31 20:17 ` Hyman Rosen 2004-09-01 7:08 ` Jean-Pierre Rosen 2004-09-01 12:25 ` Georg Bauhaus 2004-09-01 14:27 ` Jean-Pierre Rosen 2004-09-01 20:21 ` Georg Bauhaus 2004-09-02 7:59 ` Martin Krischik 2004-09-02 13:33 ` Hyman Rosen 2004-09-02 14:38 ` Jean-Pierre Rosen 2004-09-02 15:33 ` Hyman Rosen 2004-09-02 16:32 ` Martin Krischik 2004-09-02 18:50 ` Hyman Rosen 2004-08-31 9:57 ` Dmitry A. Kazakov 2004-08-31 11:51 ` Martin Krischik 2004-09-02 19:10 ` Simon Wright 2004-09-12 11:02 ` Anders Gidenstam 2004-09-12 13:47 ` Simon Wright 2004-09-12 15:20 ` Anders Gidenstam 2004-09-12 16:36 ` Simon Wright 2004-09-12 18:33 ` Anders Gidenstam 2004-08-29 15:13 ` jayessay 2004-08-29 16:34 ` Richard Riehle 2004-08-23 17:27 ` Dmitry A. Kazakov 2004-08-23 18:59 ` Georg Bauhaus 2004-08-24 7:07 ` Dmitry A. Kazakov 2004-08-23 22:20 ` Richard Riehle 2004-08-24 7:07 ` Dmitry A. Kazakov 2004-08-26 21:22 ` Kevin Cline 2004-08-26 20:32 ` Kevin Cline 2004-08-27 11:53 ` Georg Bauhaus 2004-08-27 21:48 ` Kevin Cline 2004-08-28 5:02 ` Richard Riehle 2004-08-30 19:16 ` Kevin Cline 2004-08-31 12:16 ` Georg Bauhaus 2004-09-03 15:25 ` Kevin Cline 2004-09-03 18:51 ` Georg Bauhaus 2004-09-05 3:59 ` Kevin Cline 2004-08-28 10:20 ` Georg Bauhaus 2004-08-28 10:30 ` Adrian Knoth 2004-08-28 11:23 ` Georg Bauhaus 2004-08-28 12:28 ` Ludovic Brenta 2004-08-28 16:45 ` Richard Riehle 2004-08-29 15:57 ` jayessay 2004-08-29 16:47 ` Richard Riehle 2004-09-03 16:43 ` jayessay 2004-09-05 4:36 ` Kevin Cline 2004-09-05 16:13 ` Richard Riehle 2004-09-05 17:28 ` Jean-Marc Bourguet 2004-09-06 16:45 ` jayessay 2004-09-06 17:15 ` Georg Bauhaus 2004-09-07 15:13 ` jayessay 2004-09-07 15:57 ` jayessay 2004-09-07 15:57 ` Georg Bauhaus 2004-09-07 18:20 ` jayessay 2004-09-08 10:40 ` Georg Bauhaus 2004-09-08 19:46 ` jayessay 2004-09-09 1:47 ` Georg Bauhaus 2004-09-10 1:01 ` jayessay 2004-09-10 9:28 ` Georg Bauhaus 2004-09-12 15:59 ` jayessay 2004-09-13 13:19 ` Georg Bauhaus 2004-09-09 5:38 ` Chad R. Meiners 2004-09-10 1:04 ` jayessay 2004-09-10 21:51 ` Chad R. Meiners 2004-09-06 18:47 ` Jean-Marc Bourguet 2004-09-07 15:22 ` jayessay 2004-09-07 15:37 ` Jean-Marc Bourguet 2004-09-07 17:01 ` jayessay 2004-09-07 17:56 ` Jean-Marc Bourguet 2004-09-07 18:29 ` jayessay 2004-09-07 19:03 ` Jean-Marc Bourguet 2004-09-07 21:12 ` jayessay 2004-09-08 8:12 ` Jean-Marc Bourguet 2004-09-07 15:58 ` jayessay 2004-09-07 22:34 ` Björn Persson 2004-09-08 16:28 ` jayessay 2004-09-08 23:28 ` Randy Brukardt 2004-09-05 21:01 ` Jeffrey Carter 2004-09-06 2:17 ` stephane richard 2004-09-06 21:12 ` jayessay 2004-09-07 8:23 ` Dmitry A. Kazakov 2004-09-07 15:25 ` jayessay 2004-09-05 18:28 ` Larry Kilgallen [not found] ` <e749549b.0409042036.5d4822a2@posting.googlOrganization: LJK Software <vpblkhspuA9F@eisner.encompasserve.org> 2004-09-05 22:49 ` Kevin Cline 2004-09-06 16:39 ` jayessay 2004-09-07 22:01 ` Lionel Draghi 2004-09-08 8:52 ` Ole-Hjalmar Kristensen 2004-09-08 10:20 ` Georg Bauhaus 2004-09-08 12:01 ` Dmitry A. Kazakov 2004-09-08 16:26 ` jayessay 2004-09-08 19:12 ` Dmitry A. Kazakov 2004-09-08 21:02 ` Björn Persson 2004-09-08 23:31 ` jayessay 2004-09-09 16:00 ` Björn Persson 2004-09-08 23:02 ` Alexander E. Kopilovich 2004-09-08 23:23 ` jayessay 2004-09-09 9:12 ` Dmitry A. Kazakov 2004-09-10 1:16 ` jayessay 2004-09-10 15:06 ` Dmitry A. Kazakov 2004-09-08 21:17 ` Lionel Draghi 2004-09-10 0:47 ` jayessay 2004-09-10 17:40 ` Dmitry A. Kazakov 2004-09-12 16:02 ` jayessay 2004-09-08 19:46 ` Alexander E. Kopilovich 2004-09-09 7:57 ` Dmitry A. Kazakov 2004-09-10 0:53 ` jayessay 2004-09-11 19:52 ` Alexander E. Kopilovich 2004-09-12 16:36 ` jayessay 2004-09-08 16:08 ` jayessay 2004-09-08 17:29 ` Richard Riehle 2004-09-08 23:01 ` jayessay 2004-09-09 1:08 ` Kevin Cline 2004-09-09 1:35 ` Ed Falis 2004-09-09 20:11 ` Lionel Draghi 2004-09-11 0:04 ` Kevin Cline 2004-09-11 1:10 ` Ed Falis 2004-09-12 16:20 ` jayessay 2004-09-12 23:25 ` Lionel Draghi 2004-09-13 10:13 ` Georg Bauhaus 2004-09-13 21:29 ` jayessay 2004-09-14 9:15 ` Georg Bauhaus 2004-09-15 2:15 ` Alexander E. Kopilovich 2004-09-09 3:01 ` Georg Bauhaus 2004-09-10 23:56 ` Kevin Cline 2004-09-11 9:50 ` Martin Krischik 2004-09-11 18:09 ` Benjamin Ketcham 2004-09-11 18:33 ` Georg Bauhaus 2004-09-12 6:00 ` Benjamin Ketcham 2004-09-12 17:45 ` Martin Krischik 2004-09-12 17:41 ` Martin Krischik 2004-09-13 0:30 ` Hyman Rosen 2004-09-13 6:06 ` Kevin Cline 2004-09-12 0:51 ` Larry Kilgallen 2004-09-12 6:05 ` Benjamin Ketcham 2004-09-12 7:52 ` Pascal Obry 2004-09-12 17:17 ` Marius Amado Alves 2004-09-12 13:02 ` Larry Kilgallen 2004-09-12 19:05 ` Alexander E. Kopilovich [not found] ` <zi1oZiVz9I4A@eisner.encoOrganization: LJK Software <UHjU2NulgeUs@eisner.encompasserve.org> 2004-09-12 21:21 ` Marin David Condic 2004-09-13 7:42 ` Dmitry A. Kazakov 2004-09-15 20:45 ` Marin David Condic 2004-09-16 8:03 ` Dmitry A. Kazakov 2004-09-16 18:45 ` Pascal Obry 2004-09-17 7:29 ` Dmitry A. Kazakov 2004-09-13 0:48 ` Larry Kilgallen 2004-09-13 14:25 ` Marius Amado Alves 2004-09-13 5:56 ` Kevin Cline 2004-09-13 11:49 ` Georg Bauhaus 2004-09-13 13:30 ` Hyman Rosen 2004-09-14 17:14 ` Kevin Cline 2004-09-14 17:29 ` Kevin Cline 2004-09-13 14:58 ` Larry Kilgallen 2004-09-13 16:01 ` Marius Amado Alves [not found] ` <mailman.16.1095009448.390.comp.lang.ada@ada-france.Organization: LJK Software <7+giGppWCdX3@eisner.encompasserve.org> 2004-09-14 20:17 ` David Gay 2004-09-11 9:59 ` Pascal Obry 2004-09-12 5:32 ` Hyman Rosen 2004-09-12 7:19 ` Pascal Obry 2004-09-13 0:43 ` Hyman Rosen 2004-09-13 16:40 ` Pascal Obry 2004-09-13 21:19 ` Hyman Rosen 2004-09-13 21:36 ` Hyman Rosen 2004-09-14 17:27 ` Pascal Obry 2004-09-12 7:50 ` Pascal Obry 2004-09-12 23:59 ` Brian May 2004-09-13 0:45 ` Hyman Rosen 2004-09-13 6:19 ` Dale Stanbrough 2004-09-13 7:50 ` Dmitry A. Kazakov 2004-09-13 13:35 ` Hyman Rosen 2004-09-13 15:39 ` Dmitry A. Kazakov 2004-09-13 15:51 ` Hyman Rosen 2004-09-14 8:32 ` Dmitry A. Kazakov 2004-09-14 9:07 ` Georg Bauhaus 2004-09-14 14:04 ` Dmitry A. Kazakov 2004-09-14 15:57 ` Georg Bauhaus 2004-09-15 8:29 ` Dmitry A. Kazakov 2004-09-15 9:30 ` Martin Dowie 2004-09-15 10:05 ` Dmitry A. Kazakov 2004-09-15 10:14 ` Martin Krischik 2004-09-15 12:50 ` Dmitry A. Kazakov 2004-09-16 4:29 ` Kevin Cline 2004-09-16 7:38 ` Martin Krischik 2004-09-16 18:45 ` Georg Bauhaus 2004-09-17 5:58 ` Martin Krischik 2004-09-18 16:44 ` Georg Bauhaus 2004-09-19 11:22 ` Simon Wright 2004-09-19 12:22 ` Georg Bauhaus 2004-09-19 18:04 ` Simon Wright 2004-09-20 7:36 ` Martin Krischik 2004-09-20 20:41 ` Randy Brukardt 2004-09-21 8:11 ` Martin Krischik 2004-09-22 20:51 ` Simon Wright 2004-09-16 8:01 ` Jean-Pierre Rosen 2004-09-14 20:35 ` Pascal Obry 2004-09-15 8:29 ` Dmitry A. Kazakov 2004-09-16 18:43 ` Pascal Obry 2004-09-14 16:28 ` Kevin Cline 2004-09-11 11:44 ` Georg Bauhaus 2004-09-14 16:50 ` Kevin Cline 2004-09-14 17:32 ` Georg Bauhaus 2004-09-09 19:58 ` Lionel Draghi 2004-09-11 0:07 ` Kevin Cline 2004-09-11 12:06 ` Georg Bauhaus 2004-09-12 16:33 ` jayessay 2004-09-13 12:43 ` Georg Bauhaus 2004-09-13 6:58 ` Kevin Cline 2004-09-13 13:06 ` Georg Bauhaus 2004-09-12 16:30 ` jayessay 2004-09-12 22:55 ` Lionel Draghi 2004-09-12 23:08 ` Lionel Draghi 2004-09-13 2:37 ` John B. Matthews 2004-09-13 21:28 ` jayessay 2004-09-13 13:08 ` Georg Bauhaus 2004-09-09 0:13 ` Randy Brukardt 2004-09-11 0:23 ` Kevin Cline 2004-09-14 0:17 ` Randy Brukardt 2004-09-12 16:22 ` jayessay 2004-09-14 0:49 ` Randy Brukardt 2004-09-14 14:28 ` jayessay 2004-09-06 21:01 ` Stephen Leake 2004-09-13 6:23 ` Kevin Cline 2004-09-07 2:16 ` Richard Riehle 2004-09-07 3:57 ` Benjamin Ketcham 2004-09-07 16:42 ` Richard Riehle 2004-09-07 20:51 ` jayessay 2004-09-07 22:21 ` Mark Lorenzen 2004-09-08 5:26 ` Richard Riehle 2004-09-08 6:56 ` Mark Lorenzen 2004-09-08 15:56 ` jayessay 2004-09-08 15:36 ` jayessay 2004-09-08 15:37 ` Jean-Marc Bourguet 2004-09-08 10:29 ` Georg Bauhaus 2004-09-08 16:04 ` jayessay 2004-09-09 2:52 ` Kevin Cline 2004-09-07 7:46 ` Jean-Pierre Rosen 2004-09-14 20:14 ` Kevin Cline 2004-09-20 21:45 ` Lurker 2004-09-07 22:37 ` Lionel Draghi 2004-09-06 7:49 ` Ole-Hjalmar Kristensen 2004-09-06 16:36 ` jayessay 2004-09-06 17:32 ` Georg Bauhaus 2004-09-07 13:48 ` jayessay 2004-09-07 15:13 ` Georg Bauhaus 2004-09-07 15:54 ` jayessay 2004-09-08 12:33 ` Georg Bauhaus 2004-09-08 13:17 ` Georg Bauhaus 2004-09-09 1:02 ` Randy Brukardt 2004-09-09 9:15 ` Dmitry A. Kazakov 2004-09-07 22:18 ` Lionel Draghi 2004-08-28 14:45 ` User Name 2004-08-28 20:02 ` Alexander E. Kopilovich 2004-08-30 12:20 ` Jano 2004-08-20 19:50 ` Jeffrey Carter 2004-08-26 20:42 ` Kevin Cline 2004-08-27 1:22 ` Jeffrey Carter 2004-08-27 15:22 ` Kevin Cline 2004-08-27 16:26 ` Georg Bauhaus 2004-08-30 19:08 ` Kevin Cline 2004-08-27 18:08 ` Jeffrey Carter 2004-08-28 14:05 ` Kevin Cline 2004-08-26 21:52 ` Kevin Cline 2004-08-20 17:53 ` Alexander E. Kopilovich 2004-08-21 1:34 ` Richard Riehle 2004-08-18 0:37 ` Jeffrey Carter 2004-08-18 1:53 ` Steve 2004-08-18 8:58 ` Dmitry A. Kazakov 2004-08-18 10:04 ` Jean-Pierre Rosen 2004-08-18 17:55 ` Ludovic Brenta 2004-08-18 17:58 ` Ed Falis 2004-08-19 7:41 ` Jean-Pierre Rosen 2004-08-19 14:36 ` Larry Kilgallen 2004-08-30 14:00 ` Jacob Sparre Andersen 2004-08-30 15:27 ` Martin Krischik 2004-08-25 18:26 ` John Kern 2004-08-18 10:32 ` Björn Persson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox