* Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) @ 2004-09-22 0:21 Kevin Cline 2004-09-22 2:16 ` Pylinius ` (8 more replies) 0 siblings, 9 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-22 0:21 UTC (permalink / raw) As promised in the Ada popularity thread, I have taken one of the Charles examples and reimplemented it in C++. I used only the standard C++ language and libraries. The Ada/CHARLES main program body is 118 (non-blank) lines of code, plus an additional 40 lines of instantiations in eight other specification files, for a total of 158 lines and 9 files. The C++ implementation is 76 (non-blank) lines of code in a single file. For grins, I also wrote the program in Perl. That took 14 lines. Summary: Ada/Charles 158 lines, 9 files C++ 76 lines Perl 14 lines You can compare the implementations at http://www.geocities.com/kc0a/wordcount.html ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline @ 2004-09-22 2:16 ` Pylinius 2004-09-22 8:50 ` Björn Persson ` (7 subsequent siblings) 8 siblings, 0 replies; 229+ messages in thread From: Pylinius @ 2004-09-22 2:16 UTC (permalink / raw) Kevin Cline wrote: > As promised in the Ada popularity thread, I have taken one of the > Charles examples and reimplemented it in C++. I used only the > standard C++ language and libraries. The Ada/CHARLES main program > body is 118 (non-blank) lines of code, plus an additional 40 lines of > instantiations in eight other specification files, for a total of 158 > lines and 9 files. The C++ implementation is 76 (non-blank) lines of > code in a single file. For grins, I also wrote the program in Perl. > That took 14 lines. > > Summary: > > Ada/Charles 158 lines, 9 files > C++ 76 lines > Perl 14 lines > > You can compare the implementations at > http://www.geocities.com/kc0a/wordcount.html > -- 11 lines + 1 comment line, which is the one you are reading, duh with Gnat.Problems_For_High_Schoolers; with Text_IO; use Text_IO; procedure Main is begin loop Put_Line(Gnat.Problems_For_High_Schoolers.Word_Count_Concordance); end loop; exception when Gnat.Problems_For_High_Schoolers.End_Error => null; end; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline 2004-09-22 2:16 ` Pylinius @ 2004-09-22 8:50 ` Björn Persson 2004-09-22 13:38 ` Benjamin Ketcham 2004-09-23 8:51 ` Kevin Cline 2004-09-22 15:27 ` James Alan Farrell ` (6 subsequent siblings) 8 siblings, 2 replies; 229+ messages in thread From: Björn Persson @ 2004-09-22 8:50 UTC (permalink / raw) Kevin Cline wrote: > Ada/Charles 158 lines, 9 files > C++ 76 lines > Perl 14 lines Neat. Now let's take three identical persons who haven't seen this program before, give them one version each, and see how long it takes them to understand it. In other words: What matters is how easy the program is to read and maintain. The line count is interesting only to the extent that it affects the readability. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 8:50 ` Björn Persson @ 2004-09-22 13:38 ` Benjamin Ketcham 2004-09-22 14:07 ` Hyman Rosen ` (3 more replies) 2004-09-23 8:51 ` Kevin Cline 1 sibling, 4 replies; 229+ messages in thread From: Benjamin Ketcham @ 2004-09-22 13:38 UTC (permalink / raw) Bj?rn Persson <spam-away@nowhere.nil> wrote: > Kevin Cline wrote: > >> Ada/Charles 158 lines, 9 files >> C++ 76 lines >> Perl 14 lines > > Neat. Now let's take three identical persons who haven't seen this > program before, give them one version each, and see how long it takes > them to understand it. > > In other words: What matters is how easy the program is to read and > maintain. The line count is interesting only to the extent that it > affects the readability. Well, the line count affects readability rather profoundly, in this example! Not being an expert in any of the languages concerned, I can take a more objective view of readability perhaps; and I can say that if I had to figure out and maintain any of these programs, the one that easily fits in entirety on an 80x24 screen wins my approval. I.e., this might not scale to larger projects: I'm not at all sure I'd rather read a 1400-line Perl program than a 7600-line C++ program or a 15800-line Ada program. Actually, "none of the above" sounds most appealing. OTOH, it does not appear that the three programs actually implement the same spec. E.g., error messages are different (and missing in the Perl version), and if I'm not mistaken the Perl version reads input from stdin, the other two take a file argument -- or is while(<>) in Perl smart/twisted enough to read from a filename in argv[] if present, else stdin? I certainly recall that it has extensively overloaded behaviour. Anyway, this is not even a vaguely fair test until all three actually have the same behaviour in detail. --Benjamin ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 13:38 ` Benjamin Ketcham @ 2004-09-22 14:07 ` Hyman Rosen 2004-09-22 15:16 ` Cesar Rabak ` (2 subsequent siblings) 3 siblings, 0 replies; 229+ messages in thread From: Hyman Rosen @ 2004-09-22 14:07 UTC (permalink / raw) Benjamin Ketcham wrote: > or is while(<>) in Perl smart/twisted enough > to read from a filename in argv[] if present, else stdin? Yes. In fact, it reads all the files specified on the command line and stdin if there are none. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 13:38 ` Benjamin Ketcham 2004-09-22 14:07 ` Hyman Rosen @ 2004-09-22 15:16 ` Cesar Rabak 2004-09-23 8:22 ` Kevin Cline 2004-09-23 10:52 ` Anders Wirzenius 3 siblings, 0 replies; 229+ messages in thread From: Cesar Rabak @ 2004-09-22 15:16 UTC (permalink / raw) Benjamin Ketcham escreveu: > Bj?rn Persson <spam-away@nowhere.nil> wrote: > >>Kevin Cline wrote: >> >> >>>Ada/Charles 158 lines, 9 files >>>C++ 76 lines >>>Perl 14 lines >> >>Neat. Now let's take three identical persons who haven't seen this >>program before, give them one version each, and see how long it takes >>them to understand it. >> >>In other words: What matters is how easy the program is to read and >>maintain. The line count is interesting only to the extent that it >>affects the readability. > > > Well, the line count affects readability rather profoundly, in > this example! Not being an expert in any of the languages > concerned, I can take a more objective view of readability > perhaps; and I can say that if I had to figure out and maintain > any of these programs, the one that easily fits in entirety > on an 80x24 screen wins my approval. I.e., this > might not scale to larger projects: I'm not at all sure I'd > rather read a 1400-line Perl program than a 7600-line C++ > program or a 15800-line Ada program. Actually, "none of the > above" sounds most appealing. I was wondering this. Thanks for this report Benjamin! > > OTOH, it does not appear that the three programs actually > implement the same spec. E.g., error messages are different > (and missing in the Perl version), and if I'm not mistaken > the Perl version reads input from stdin, the other two take > a file argument -- or is while(<>) in Perl smart/twisted enough > to read from a filename in argv[] if present, else stdin? I > certainly recall that it has extensively overloaded behaviour. > Anyway, this is not even a vaguely fair test until all three > actually have the same behaviour in detail. I second this. And for a quick and dirty comparison we have to figure out some (unique for all implementations) test suite, so we can check the overall behaviour (not only performance). -- Cesar Rabak > > --Benjamin > ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 13:38 ` Benjamin Ketcham 2004-09-22 14:07 ` Hyman Rosen 2004-09-22 15:16 ` Cesar Rabak @ 2004-09-23 8:22 ` Kevin Cline 2004-09-23 10:52 ` Anders Wirzenius 3 siblings, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 8:22 UTC (permalink / raw) Benjamin Ketcham <bketcham@drizzle.com> wrote in message news:<1095860313.176522@yasure>... > Bj?rn Persson <spam-away@nowhere.nil> wrote: > > Kevin Cline wrote: > > > >> Ada/Charles 158 lines, 9 files > >> C++ 76 lines > >> Perl 14 lines > > > > Neat. Now let's take three identical persons who haven't seen this > > program before, give them one version each, and see how long it takes > > them to understand it. > > > > In other words: What matters is how easy the program is to read and > > maintain. The line count is interesting only to the extent that it > > affects the readability. > > Well, the line count affects readability rather profoundly, in > this example! Not being an expert in any of the languages > concerned, I can take a more objective view of readability > perhaps; and I can say that if I had to figure out and maintain > any of these programs, the one that easily fits in entirety > on an 80x24 screen wins my approval. I.e., this > might not scale to larger projects: I'm not at all sure I'd > rather read a 1400-line Perl program than a 7600-line C++ > program or a 15800-line Ada program. Actually, "none of the > above" sounds most appealing. > > OTOH, it does not appear that the three programs actually > implement the same spec. E.g., error messages are different > (and missing in the Perl version), and if I'm not mistaken > the Perl version reads input from stdin, the other two take > a file argument -- or is while(<>) in Perl smart/twisted enough > to read from a filename in argv[] if present, else stdin? I > certainly recall that it has extensively overloaded behaviour. > Anyway, this is not even a vaguely fair test until all three > actually have the same behaviour in detail. I didn't actually run the Ada program, but I did run the C++ and Perl code. As I mentioned in the message, the Perl program does not give the same error messages, but in some sense it is more powerful than the Ada and C++ programs, because it works like a standard Unix filter, either reading from standard input or from the files specified on the command line. A more serious effort would take another few lines to at least handle the -h switch. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 13:38 ` Benjamin Ketcham ` (2 preceding siblings ...) 2004-09-23 8:22 ` Kevin Cline @ 2004-09-23 10:52 ` Anders Wirzenius 2004-09-23 10:54 ` stephane richard ` (2 more replies) 3 siblings, 3 replies; 229+ messages in thread From: Anders Wirzenius @ 2004-09-23 10:52 UTC (permalink / raw) Benjamin Ketcham <bketcham@drizzle.com> writes: > > Well, the line count affects readability rather profoundly, in > this example! Not being an expert in any of the languages > concerned, I can take a more objective view of readability > perhaps; and I can say that if I had to figure out and maintain > any of these programs, the one that easily fits in entirety > on an 80x24 screen wins my approval. I.e., this > might not scale to larger projects: I'm not at all sure I'd > rather read a 1400-line Perl program than a 7600-line C++ > program or a 15800-line Ada program. Actually, "none of the > above" sounds most appealing. > Anyone else than I missing the good old days with printouts from line printers with continuous paper? Anders ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 10:52 ` Anders Wirzenius @ 2004-09-23 10:54 ` stephane richard 2004-09-23 11:17 ` Jean-Pierre Rosen 2004-09-23 11:47 ` Marius Amado Alves 2 siblings, 0 replies; 229+ messages in thread From: stephane richard @ 2004-09-23 10:54 UTC (permalink / raw) "Anders Wirzenius" <anders@no.email.thanks.invalid> wrote in message news:uu0tpi7em.fsf@no.email.thanks.invalid... > Benjamin Ketcham <bketcham@drizzle.com> writes: >> >> Well, the line count affects readability rather profoundly, in >> this example! Not being an expert in any of the languages >> concerned, I can take a more objective view of readability >> perhaps; and I can say that if I had to figure out and maintain >> any of these programs, the one that easily fits in entirety >> on an 80x24 screen wins my approval. I.e., this >> might not scale to larger projects: I'm not at all sure I'd >> rather read a 1400-line Perl program than a 7600-line C++ >> program or a 15800-line Ada program. Actually, "none of the >> above" sounds most appealing. >> > > Anyone else than I missing the good old days with printouts > from line printers with continuous paper? > > Anders Yep, I miss that :-). Along with green and amber monochrome monitors that when turned on, you could shut down the heating in the house and open the your windows...in January no less ;-). ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 10:52 ` Anders Wirzenius 2004-09-23 10:54 ` stephane richard @ 2004-09-23 11:17 ` Jean-Pierre Rosen 2004-09-23 11:47 ` Marius Amado Alves 2 siblings, 0 replies; 229+ messages in thread From: Jean-Pierre Rosen @ 2004-09-23 11:17 UTC (permalink / raw) Anders Wirzenius a écrit : > Anyone else than I missing the good old days with printouts > from line printers with continuous paper? > When you were allowed only one compilation run a day? Then, you had to be careful about missing semi-colons :-) -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 10:52 ` Anders Wirzenius 2004-09-23 10:54 ` stephane richard 2004-09-23 11:17 ` Jean-Pierre Rosen @ 2004-09-23 11:47 ` Marius Amado Alves 2004-09-23 13:34 ` Anders Wirzenius 2004-09-23 17:19 ` Cesar Rabak 2 siblings, 2 replies; 229+ messages in thread From: Marius Amado Alves @ 2004-09-23 11:47 UTC (permalink / raw) Cc: comp.lang.ada > Anyone else than I missing the good old days with printouts > from line printers with continuous paper? This interests me, because I'm researching knowledge media, how the medium constraints influence habits and effectivness of reading, what levels of knowledge organization are influenced by technology... You mean the "page principle" (fit a function inside a page or less) is totally technology-driven (and hence not a principle)? Not a rough measure of some cognitive absolute? Thanks. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:47 ` Marius Amado Alves @ 2004-09-23 13:34 ` Anders Wirzenius 2004-09-23 16:53 ` Warren W. Gay VE3WWG 2004-09-23 18:30 ` Kevin Cline 2004-09-23 17:19 ` Cesar Rabak 1 sibling, 2 replies; 229+ messages in thread From: Anders Wirzenius @ 2004-09-23 13:34 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> writes: > > Anyone else than I missing the good old days with printouts from > > line printers with continuous paper? > > This interests me, because I'm researching knowledge media, how the > medium constraints influence habits and effectivness of reading, what > levels of knowledge organization are influenced by technology... You > mean the "page principle" (fit a function inside a page or less) is > totally technology-driven (and hence not a principle)? Not a rough > measure of some cognitive absolute? Thanks. I mean the easiness to "turn pages" using a finger under the left edge of the paper strip. My English is not good enough to explain that more detailed. I think everyone who have experienced the line printer paper strips knows what I mean. Back in the "good old days" I worked on a system with hundreds of code (Fortran subroutine) files up to some thousand lines. We kept all code as a library of printed paper strips and it was very fast to go to the files and find whatever information you might have needed from the code. That even if we had the excellent editor (don't remember the name anymore) on our VAX machines. Perhaps you may obtain something similar using a text editor with bookmarks, but I have never reached that level of usage. I have compared the screen_scrolling versus flip_through_paper to a situation where you read your newspaper (at least A3 size) looking at the text through a frame of size A5 (or smaller). You are not allowed to move your eyes outside the frame. If you don't want to jump to another place in the text by moving the frame and your eyes simultaneously, jumping to a new place is done in three steps: First step one or two steps back (scroll out), then move your frame to a new place (move cursor), and then step back closer (scroll in). After which you may continue to read (through the frame, of course). Yes, I think it is technology driven. Why are printed newspapers still popular even if a lot of people have a permanent, uninterrupted Internet connection and are able to rapidly move even between several electronic newspapers? I remember having read somewhere that 2 or 3 centuries back many writing desks had an inclination which made the reader look at the text perpendicular to the paper. Later the desks have been tilted so that we read the text from an angle less than 90 degrees. And feel obviously more comfortable with it. Now our computer screens are tilted to the 90 degrees. :) Anders ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 13:34 ` Anders Wirzenius @ 2004-09-23 16:53 ` Warren W. Gay VE3WWG 2004-09-23 18:30 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Warren W. Gay VE3WWG @ 2004-09-23 16:53 UTC (permalink / raw) Anders Wirzenius wrote: > Marius Amado Alves <amado.alves@netcabo.pt> writes: >>>Anyone else than I missing the good old days with printouts from >>>line printers with continuous paper? >> >>This interests me, because I'm researching knowledge media, how the >>medium constraints influence habits and effectivness of reading, what >>levels of knowledge organization are influenced by technology... You >>mean the "page principle" (fit a function inside a page or less) is >>totally technology-driven (and hence not a principle)? Not a rough >>measure of some cognitive absolute? Thanks. > > I mean the easiness to "turn pages" using a finger under the left > edge of the paper strip. My English is not good enough to explain > that more detailed. I think everyone who have experienced the > line printer paper strips knows what I mean. Another reason that "method" worked so well, was that it supported the high resolution pen graphics (pencil or pen, even highliters). Notes and scribbles, even doodles often helped the thought process in more complicated cases. If you went further, and kept prior listings in a filing cabinet (as one place I worked at did), then you had the benefits of other notes, scribbles and alas, even sometimes diagrams! People usually won't make the same effort in electronic forms -- so this is lacking today. > Perhaps you may obtain something similar using a text editor > with bookmarks, but I have never reached that level of usage. They don't support the "high resolution graphics" and diagrams ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 13:34 ` Anders Wirzenius 2004-09-23 16:53 ` Warren W. Gay VE3WWG @ 2004-09-23 18:30 ` Kevin Cline 2004-09-23 19:00 ` Marius Amado Alves 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-23 18:30 UTC (permalink / raw) Anders Wirzenius <anders@no.email.thanks.invalid> wrote in message news:<upt4dhzxu.fsf@no.email.thanks.invalid>... > Why are printed newspapers still popular even if a lot of > people have a permanent, uninterrupted Internet connection > and are able to rapidly move even between several > electronic newspapers? Because a newspaper is a set of unrelated articles, and we read the articles from beginning to end. And we don't have to edit the newspaper, just read it. Newspaper writers and editors universally do their work on a computer screen. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:30 ` Kevin Cline @ 2004-09-23 19:00 ` Marius Amado Alves 2004-09-24 6:04 ` [OT]Screen ergonomics, was " Anders Wirzenius 2004-09-26 7:22 ` Kevin Cline 0 siblings, 2 replies; 229+ messages in thread From: Marius Amado Alves @ 2004-09-23 19:00 UTC (permalink / raw) To: comp.lang.ada >>Why are printed newspapers still popular even if a lot of >>people have a permanent, uninterrupted Internet connection >>and are able to rapidly move even between several >>electronic newspapers? > > Because a newspaper is a set of unrelated articles, and we read the > articles from beginning to end. And we don't have to edit the > newspaper, just read it. Newspaper writers and editors universally do > their work on a computer screen. I don't understand this explanation. My answer would be along these lines. On a big paper sheet there are different content items, or different parts of some content. You have to locate a part, focus on it, to read it. Same goes for the whole (printed) newspaper. On a small screen only one part fits. The others are away. So what is different is how the user locates parts. With a printed paper you only have to turn your eyes or head to look at a different part. And you can even move a sheet up/down/left/right so the part under inspection stays more aligned with the eyes. You cannot do that with a small screen. Maybe with an eyetracking system you can simulate that, but I doubt it will work as well. ^ permalink raw reply [flat|nested] 229+ messages in thread
* [OT]Screen ergonomics, was Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:00 ` Marius Amado Alves @ 2004-09-24 6:04 ` Anders Wirzenius 2004-09-26 7:22 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Anders Wirzenius @ 2004-09-24 6:04 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> writes: > >> Why are printed newspapers still popular even if a lot of people > >> have a permanent, uninterrupted Internet connection and are able to > >> rapidly move even between several electronic newspapers? > > Because a newspaper is a set of unrelated articles, and we read the > > articles from beginning to end. And we don't have to edit the > > newspaper, just read it. Newspaper writers and editors universally do > > their work on a computer screen. > > I don't understand this explanation. > > My answer would be along these lines. On a big paper sheet there are > different content items, or different parts of some content. You have > to locate a part, focus on it, to read it. Same goes for the whole > (printed) newspaper. On a small screen only one part fits. The others > are away. So what is different is how the user locates parts. With a > printed paper you only have to turn your eyes or head to look at a > different part. And you can even move a sheet up/down/left/right so > the part under inspection stays more aligned with the eyes. You cannot > do that with a small screen. Maybe with an eyetracking system you can > simulate that, but I doubt it will work as well. This is exactly what I tried to explain in the metaphor about the reading a newspaper through a frame. Anders ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:00 ` Marius Amado Alves 2004-09-24 6:04 ` [OT]Screen ergonomics, was " Anders Wirzenius @ 2004-09-26 7:22 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-26 7:22 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> wrote in message news:<mailman.73.1095966095.390.comp.lang.ada@ada-france.org>... > >>Why are printed newspapers still popular even if a lot of > >>people have a permanent, uninterrupted Internet connection > >>and are able to rapidly move even between several > >>electronic newspapers? > > > > Because a newspaper is a set of unrelated articles, and we read the > > articles from beginning to end. And we don't have to edit the > > newspaper, just read it. Newspaper writers and editors universally do > > their work on a computer screen. > > I don't understand this explanation. > > My answer would be along these lines. On a big paper sheet there are > different content items, or different parts of some content. You have to > locate a part, focus on it, to read it. Same goes for the whole > (printed) newspaper. On a small screen only one part fits. The others > are away. So what is different is how the user locates parts. With a > printed paper you only have to turn your eyes or head to look at a > different part. And you can even move a sheet up/down/left/right so the > part under inspection stays more aligned with the eyes. You cannot do > that with a small screen. Maybe with an eyetracking system you can > simulate that, but I doubt it will work as well. That explains why it's easier to read linear text from a printed page. Programs aren't linear text -- they have a complex structure, and aren't read from beginning to end. That is why most programmers prefer to work with code via a screen editor. It's been a long time since I've seen a programmer work from listings. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:47 ` Marius Amado Alves 2004-09-23 13:34 ` Anders Wirzenius @ 2004-09-23 17:19 ` Cesar Rabak 1 sibling, 0 replies; 229+ messages in thread From: Cesar Rabak @ 2004-09-23 17:19 UTC (permalink / raw) Marius Amado Alves escreveu: >> Anyone else than I missing the good old days with printouts from line >> printers with continuous paper? > > > This interests me, because I'm researching knowledge media, how the > medium constraints influence habits and effectivness of reading, what > levels of knowledge organization are influenced by technology... You > mean the "page principle" (fit a function inside a page or less) is > totally technology-driven (and hence not a principle)? Not a rough > measure of some cognitive absolute? Thanks. > Probably. For other realms, a 'comfortable' size would be an A3 or A2 sheet with some graphical representation, or a maquette with no more than (say) one square meter. You probably will pass at in your research why the distance we find comfortable for talking to other persons has to be no less than a meter so we can see the whole face of the other person. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 8:50 ` Björn Persson 2004-09-22 13:38 ` Benjamin Ketcham @ 2004-09-23 8:51 ` Kevin Cline 2004-09-23 11:01 ` Georg Bauhaus ` (3 more replies) 1 sibling, 4 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 8:51 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<11b4d.3849$d5.30042@newsb.telia.net>... > Kevin Cline wrote: > > > Ada/Charles 158 lines, 9 files > > C++ 76 lines > > Perl 14 lines > > Neat. Now let's take three identical persons who haven't seen this > program before, give them one version each, and see how long it takes > them to understand it. > In other words: What matters is how easy the program is to read and > maintain. I quite agree, and on that score the Perl code wins hands down. Anyone with a couple of months of Perl experience could understand the Perl program in about two minutes, and a halfway decent Perl programmer should be able to write that code in about ten minutes. It took me a bit longer because I had forgotten how to call sort and had to look it up. It's pretty hard to make the case that this Ada code: procedure Insert (Word : String) is I : Wordcount_Maps.Iterator_Type; B : Boolean; type Element_Access is access all Wordcount_Maps.Element_Subtype; for Element_Access'Storage_Size use 0; function To_Access is new Wordcount_Maps.Generic_Element (Element_Access); begin -- Insert Insert (Map, To_Lower (Word), 0, I, B); declare E : Wordcount_Maps.Element_Subtype renames To_Access (I).all; begin E := E + 1; end; end Insert; is easier to understand than the corresponding C++ code: ++concordance[word]; or the corresponding Perl code: ++$count{$word}; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 8:51 ` Kevin Cline @ 2004-09-23 11:01 ` Georg Bauhaus 2004-09-23 15:59 ` Matthew Heaney 2004-09-23 16:38 ` Kevin Cline 2004-09-23 19:10 ` jayessay ` (2 subsequent siblings) 3 siblings, 2 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-23 11:01 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : begin -- Insert : Insert (Map, To_Lower (Word), 0, I, B); : declare E : Wordcount_Maps.Element_Subtype renames To_Access : (I).all; : begin : E := E + 1; : end; : end Insert; Is the intention to first store a 0 with word, and then to increment the value stored at word? : is easier to understand than the corresponding C++ code: : ++concordance[word]; Although this will require that you know how to separate the queries and commands in this abbreviation. If you are not used to how ++ and [] work in the context of maps, will this still be easy to understand? AFAIK, [] does more than one thing behind the scenes. ++ is known to be difficult to understand in that it is not clear what ++ is referring to. Here, it is not incrementing the concordance, although the operator is placed immediately before the identifier. IIRC, the K&R book talks about (), ++, *, -> at length. I guess there is a reaseon. For me this is similar to saying the APL is easy to read, which is true if you know APL. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:01 ` Georg Bauhaus @ 2004-09-23 15:59 ` Matthew Heaney 2004-09-23 16:38 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-23 15:59 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ciuadu$t8o$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : begin -- Insert > : Insert (Map, To_Lower (Word), 0, I, B); > : declare E : Wordcount_Maps.Element_Subtype renames To_Access > : (I).all; > : begin > : E := E + 1; > : end; > : end Insert; > > Is the intention to first store a 0 with word, and then > to increment the value stored at word? Yes. That's exactly how the index operator works in C++ (which is deliberate). This is the most efficient technique, since the search is performed only one time. Note that in the AI-302 API, you use a slightly different technique: declare procedure Increment_Count (W : in String; N : in out Natural) is begin N := N + 1; end; begin Update_Element (C, Increment_Count'Access); end; See the link in my previous post to the Ada 2005 version of wordcount.adb at the tigris site. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:01 ` Georg Bauhaus 2004-09-23 15:59 ` Matthew Heaney @ 2004-09-23 16:38 ` Kevin Cline 2004-09-24 2:47 ` Matthew Heaney 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-23 16:38 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<ciuadu$t8o$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : begin -- Insert > : Insert (Map, To_Lower (Word), 0, I, B); > : declare E : Wordcount_Maps.Element_Subtype renames To_Access > : (I).all; > : begin > : E := E + 1; > : end; > : end Insert; > > Is the intention to first store a 0 with word, and then > to increment the value stored at word? My understanding is that Insert will insert a new key/value pair into the map if no entry exists for the given key, and outputs the iterator I pointing to the key/value pair for the given key. > > : is easier to understand than the corresponding C++ code: > : ++concordance[word]; > > Although this will require that you know how to separate the > queries and commands in this abbreviation. If you are not used > to how ++ and [] work in the context of maps, will this still be > easy to understand? The only question is whether the [] operator will create an entry if none exists. Thirty seconds with the reference will confirm that it does, and I would expect a professional programmer to be able to remember that. > AFAIK, [] does more than one thing behind the scenes. > ++ is known to be difficult to understand in that it > is not clear what ++ is referring to. Now are you claiming that C++ is hard to read because one has to learn the operator precedence rules? > Here, it is not incrementing > the concordance, although the operator is placed immediately before > the identifier. IIRC, the K&R book talks about (), ++, *, -> at > length. I guess there is a reaseon. > > For me this is similar to saying the APL is easy to read, which > is true if you know APL. Presumably anyone undertaking to program in APL will at some point come to know APL. You seem to be arguing that a tool is poor because it's use is not immediately obvious to the untrained. The effectiveness of a tool has to be judged by comparing the productivity of workers skilled with that tool. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 16:38 ` Kevin Cline @ 2004-09-24 2:47 ` Matthew Heaney 2004-09-24 13:43 ` Hyman Rosen 2004-09-26 7:08 ` Kevin Cline 0 siblings, 2 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 2:47 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > > Is the intention to first store a 0 with word, and then > > to increment the value stored at word? > > My understanding is that Insert will insert a new key/value pair into > the map if no entry exists for the given key, and outputs the iterator > I pointing to the key/value pair for the given key. Yes. This behavior is identical to the C++ statements: typedef std::map<std::string, int> wcmap_t; wcmap_t wcmap; typedef wcmap_t::iterator iter_t; typedef std::pair<iter_t, bool> status_t; const status_t status = wcmap.insert(std::make_pair(word, 0)); const iter_t i = status.first; ++i->second; > > Although this will require that you know how to separate the queries > > and commands in this abbreviation. If you are not used to how ++ and > > [] work in the context of maps, will this still be easy to > > understand? > > The only question is whether the [] operator will create an entry if > none exists. Thirty seconds with the reference will confirm that it > does, and I would expect a professional programmer to be able to > remember that. Yes, the index operator creates an element with its default value, if the requested key isn't already in the map. Note, however, that the index operator isn't completely benign. In fact, the index operator for map gets its own entry in Effective STL. One thing programmers sometimes do is: some_map[some_key] = x; The issue here is that the element associated with some_key gets constructed using its default ctor, and then the object is immediately assigned the value of x. But it's more efficient to use the copy ctor, but to do that you need to use the insert member function as above. The other issue with the index operator is that if you use a (string) literal as the key, then it's possible to misspell the value, and create a new key accidently. That being said, for this particular problem, the index operator is very convenient, and entirely appropriate. > > AFAIK, [] does more than one thing behind the scenes. > > ++ is known to be difficult to understand in that it > > is not clear what ++ is referring to. > > Now are you claiming that C++ is hard to read because one has to learn > the operator precedence rules? The rule in C and C++ is that postfix operators have a higher precedence than prefix operators. This is the only rule that makes sense, for example: struct S { int i; }; S s = { 0 }; ++s.i; In this case, the operator is the "dot" operator (which isn't user-definable). Actually, I would have used a pointer instead: S* ps = &s; ++ps->i; The arrow operator is postfix, so it has higher precedence than ++ (which is prefix), so the expression above increments i, not ps. In the statement: ++wcmap[word]; the index operator is postfix, so that happens first. It either returns the element whose key is "word", or constructs a new element using the default ctor for the type, which in this case (type int) initializes the element to the value 0. That last bit might be confusing, since you don't normally think of built-in types as having a constructor. However, type int does have a ctor, so for example: int i; //garbage int j = int::int(); //0 The existence of a default ctor for type int is why the index operator works safely. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 2:47 ` Matthew Heaney @ 2004-09-24 13:43 ` Hyman Rosen 2004-09-24 17:47 ` Mark Lorenzen 2004-09-25 14:09 ` Martin Krischik 2004-09-26 7:08 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Hyman Rosen @ 2004-09-24 13:43 UTC (permalink / raw) Matthew Heaney wrote: > Note, however, that the index operator isn't completely benign. In > fact, the index operator for map gets its own entry in Effective STL. One of the really annoying features of this operator is that due to its behavior of creating the element if not already present, there is no const version of the operator, and so you cannot use the natural indexing syntax on a const map. There have been many requests for a const version that throws an exception if the element is not present, but you know how language standardization committees are. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 13:43 ` Hyman Rosen @ 2004-09-24 17:47 ` Mark Lorenzen 2004-09-24 18:16 ` Matthew Heaney 2004-09-25 14:09 ` Martin Krischik 1 sibling, 1 reply; 229+ messages in thread From: Mark Lorenzen @ 2004-09-24 17:47 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Matthew Heaney wrote: > > Note, however, that the index operator isn't completely benign. In > > fact, the index operator for map gets its own entry in Effective STL. > > One of the really annoying features of this operator is that due to > its behavior of creating the element if not already present, there is > no const version of the operator, and so you cannot use the natural > indexing syntax on a const map. Absolutely. I actually just learned this today while reading the STL reference manual a bit more carefully than just browsing it, and I was surprised about this fact. > > There have been many requests for a const version that throws an > exception if the element is not present, but you know how language > standardization committees are. Which is why I am a bit worried that AI 302 only defines the minimal set of operations. Regards, - Mark Lorenzen ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 17:47 ` Mark Lorenzen @ 2004-09-24 18:16 ` Matthew Heaney 2004-09-29 19:29 ` Mark Lorenzen 0 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 18:16 UTC (permalink / raw) "Mark Lorenzen" <mark.lorenzen@ofir.dk> wrote in message news:m3acvfblun.fsf@0x50a5b1a2.boanxx18.adsl-dhcp.tele.dk... > Hyman Rosen <hyrosen@mail.com> writes: > > > There have been many requests for a const version that throws an > > exception if the element is not present, but you know how language > > standardization committees are. > > Which is why I am a bit worried that AI 302 only defines the minimal > set of operations. Hmmm... There is no direct equivalent to the index operator in the STL map in AI-302, so it's not as if AI-302 is "missing" the const version of that operator, since it doesn't have that operator at all. (The 5-parameter Insert operation provides the same functionality, but not the same syntax, as the index operator.) What operations would you like AI-302 to provide, that you think are missing? It would help the designers of that library if you could be more specific. Otherwise we can't help you. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 18:16 ` Matthew Heaney @ 2004-09-29 19:29 ` Mark Lorenzen 2004-09-29 22:44 ` Matthew Heaney 0 siblings, 1 reply; 229+ messages in thread From: Mark Lorenzen @ 2004-09-29 19:29 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> writes: > What operations would you like AI-302 to provide, that you think are > missing? It would help the designers of that library if you could be more > specific. Otherwise we can't help you. After having thought about this a bit, I would say that an equivalent of C++s function classes is missing. If function classes were introduced, we could build pretty powerful algorithms traversing the different containers and f.ex. implement an infinite list (also called lazy list) container. Right now the containers only allow for a procedure to process the elements of a container. Regards, - Mark Lorenzen ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 19:29 ` Mark Lorenzen @ 2004-09-29 22:44 ` Matthew Heaney 0 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 22:44 UTC (permalink / raw) Mark Lorenzen <mark.lorenzen@ofir.dk> writes: > After having thought about this a bit, I would say that an equivalent > of C++s function classes is missing. > > If function classes were introduced, we could build pretty powerful > algorithms traversing the different containers and f.ex. implement an > infinite list (also called lazy list) container. Right now the > containers only allow for a procedure to process the elements of a > container. Well, you can do that using the procedure, and depositing a result somewhere prior to returning. For example, in the wordcount example, you need to compute a predicate function on map cursors: Sort_Vector : declare function "<" (L, R : Wordcount_Maps.Cursor) return Boolean is Result : Boolean; procedure Query_L (LK : String; LN : Natural) is procedure Query_R (RK : String; RN : Natural) is begin if LN > RN then Result := True; elsif LN < RN then Result := False; else Result := Ada.Strings.Less_Case_Insensitive (LK, RK); end if; end Query_R; begin Query_Element (R, Query_R'Access); end; begin Query_Element (L, Query_L'Access); return Result; end; procedure Sort is new Wordcount_Vectors.Generic_Sort; begin Sort (V); end Sort_Vector; This does everything the a "function class" would do in C++. The ARG is currently discussing whether to allow functions to return anonymous access types, which would allow us to write the predicate as: function "<" (L, R : Wordcount_Maps.Cursor) return Boolean is Result : Boolean; LN : Natural renames Query_Element (L).all; LN : Natural renames Query_Element (R).all; begin if LN > RN then return True; end if; if LN < RN then return False; end if; declare LK : String renames Query_Key (L).all; RK : String renames Query_Key (R).all; begin return Ada.Strings.Less_Case_Insensitive (LK, RK); end; end "<"; Please give me a specific, concrete example of something you can do in C++, that you believe cannot be done using the AI-302 container library. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 13:43 ` Hyman Rosen 2004-09-24 17:47 ` Mark Lorenzen @ 2004-09-25 14:09 ` Martin Krischik 1 sibling, 0 replies; 229+ messages in thread From: Martin Krischik @ 2004-09-25 14:09 UTC (permalink / raw) Hyman Rosen wrote: > Matthew Heaney wrote: >> Note, however, that the index operator isn't completely benign. In >> fact, the index operator for map gets its own entry in Effective STL. > > One of the really annoying features of this operator is that due to > its behavior of creating the element if not already present, there is > no const version of the operator, and so you cannot use the natural > indexing syntax on a const map. But the other option is just as bad: the operator [] from std::vector does not create new objects, hence you can't use operator [] to fill a vector. I just change from std::vector <...> to a std::map<int,...> for that very reason. So more I work with the STL so more I bloody hate it. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 2:47 ` Matthew Heaney 2004-09-24 13:43 ` Hyman Rosen @ 2004-09-26 7:08 ` Kevin Cline 2004-09-26 15:13 ` Matthew Heaney 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 7:08 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uk6ukb74c.fsf@earthlink.net>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > > > Is the intention to first store a 0 with word, and then > > > to increment the value stored at word? > > > > My understanding is that Insert will insert a new key/value pair into > > the map if no entry exists for the given key, and outputs the iterator > > I pointing to the key/value pair for the given key. > > Yes. This behavior is identical to the C++ statements: > > typedef std::map<std::string, int> wcmap_t; > > wcmap_t wcmap; > > typedef wcmap_t::iterator iter_t; > typedef std::pair<iter_t, bool> status_t; > > const status_t status = wcmap.insert(std::make_pair(word, 0)); > const iter_t i = status.first; > ++i->second; > > > > > Although this will require that you know how to separate the queries > > > and commands in this abbreviation. If you are not used to how ++ and > > > [] work in the context of maps, will this still be easy to > > > understand? > > > > The only question is whether the [] operator will create an entry if > > none exists. Thirty seconds with the reference will confirm that it > > does, and I would expect a professional programmer to be able to > > remember that. > > Yes, the index operator creates an element with its default value, if > the requested key isn't already in the map. > > Note, however, that the index operator isn't completely benign. In > fact, the index operator for map gets its own entry in Effective STL. > > One thing programmers sometimes do is: > > some_map[some_key] = x; > > The issue here is that the element associated with some_key gets > constructed using its default ctor, and then the object is immediately > assigned the value of x. But it's more efficient to use the copy ctor, > but to do that you need to use the insert member function as above. > > The other issue with the index operator is that if you use a (string) > literal as the key, then it's possible to misspell the value, and create > a new key accidently. > > That being said, for this particular problem, the index operator is very > convenient, and entirely appropriate. > > > > > AFAIK, [] does more than one thing behind the scenes. > > > ++ is known to be difficult to understand in that it > > > is not clear what ++ is referring to. > > > > Now are you claiming that C++ is hard to read because one has to learn > > the operator precedence rules? > > The rule in C and C++ is that postfix operators have a higher precedence > than prefix operators. This is the only rule that makes sense, for > example: > > struct S { int i; }; > > S s = { 0 }; > > ++s.i; > > In this case, the operator is the "dot" operator (which isn't > user-definable). > > Actually, I would have used a pointer instead: > > S* ps = &s; > ++ps->i; Most C++ programmers would not. Modern practice is to avoid naked pointers when possible, which for me is almost all the time. Pointers are needed only for low -level programming, like building a new type of container. The rest of the time you can use auto_ptr or some other smart pointer type. Anyway, the arrow and dot operators have the same precedence, so I don't see why you would prefer ++ps->i to ++s.i. I find ++ps->i to be more confusing, since a pointer can be incremented, so it would be possible to read (++ps)->i. A reference can not be incremented, so there is only one reasonable interpretation of ++s.i. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 7:08 ` Kevin Cline @ 2004-09-26 15:13 ` Matthew Heaney 0 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-26 15:13 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message > news:<uk6ukb74c.fsf@earthlink.net>... > > > > Actually, I would have used a pointer instead: > > > > S* ps = &s; > > ++ps->i; > > Most C++ programmers would not. That was a typo. I meant "could" not "would", and meant to say: "As another example of precedence rules, I could have used a pointer instead of a dot." You obviously wouldn't want to declare a pointer to a locally declared struct just to increment one of its members... ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 8:51 ` Kevin Cline 2004-09-23 11:01 ` Georg Bauhaus @ 2004-09-23 19:10 ` jayessay 2004-09-23 21:13 ` Adam Ruth 2004-09-23 23:05 ` Brian May 2004-09-24 0:19 ` Stephen Leake 3 siblings, 1 reply; 229+ messages in thread From: jayessay @ 2004-09-23 19:10 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Bj�rn Persson <spam-away@nowhere.nil> > > Kevin Cline wrote: > > > > > Ada/Charles 158 lines, 9 files > > > C++ 76 lines > > > Perl 14 lines > > > > Neat. Now let's take three identical persons who haven't seen this > > program before, give them one version each, and see how long it takes > > them to understand it. > > In other words: What matters is how easy the program is to read and > > maintain. Here is a quick hack Common Lisp version. It is 11 "lines". You could get rid of a couple more (defun word-count (file-spec &key (wordpat (compile-pattern "[A-Za-z]+"))) (let ((words->count (make-hash-table :test #'equal :size 10007))) (with-open-file (in file-spec :direction :input) (loop for line = (read-line in nil nil) while line do (replace-match :source line :target wordpat :every-occurance t :replacement #'(lambda (word) (incf (gethash word words->count 0)) "")))) (format t "~{~A~^~%~}" (subseq (sort (all (w c) :in words->count) #'> :key #'second) 0 10)))) This also does all the checking of the C++ and Ada versions as well. > I quite agree, and on that score the Perl code wins hands down. I don't much like Perl (too much line noise), but I still think you are right here. It took just a glance at the Perl to know what the basic "spec" was (including just printing the top ten). OTOH, I think the above Lisp is significantly more readable than any of them as it is both short and very descriptive. > It's pretty hard to make the case that this Ada code: > > procedure Insert (Word : String) is > I : Wordcount_Maps.Iterator_Type; > B : Boolean; > type Element_Access is access all Wordcount_Maps.Element_Subtype; > > for Element_Access'Storage_Size use 0; > > function To_Access is new Wordcount_Maps.Generic_Element > (Element_Access); > > begin -- Insert > Insert (Map, To_Lower (Word), 0, I, B); > declare E : Wordcount_Maps.Element_Subtype renames To_Access > (I).all; > begin > E := E + 1; > end; > end Insert; > > is easier to understand than the corresponding C++ code: > ++concordance[word]; > > or the corresponding Perl code: > ++$count{$word}; Or the non library, out of the box Lisp: (incf (gethash word words->count 0)) What's more, it will be at least as fast as the C++ or Ada. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:10 ` jayessay @ 2004-09-23 21:13 ` Adam Ruth 2004-09-27 2:12 ` Keith H Duggar 0 siblings, 1 reply; 229+ messages in thread From: Adam Ruth @ 2004-09-23 21:13 UTC (permalink / raw) In article <m365647qdv.fsf@rigel.goldenthreadtech.com>, jayessay <nospam@foo.com> wrote: > kevin.cline@gmail.com (Kevin Cline) writes: > > Here is a quick hack Common Lisp version. It is 11 "lines". You > could get rid of a couple more > > (defun word-count (file-spec &key (wordpat (compile-pattern "[A-Za-z]+"))) > (let ((words->count (make-hash-table :test #'equal :size 10007))) > (with-open-file (in file-spec :direction :input) > (loop for line = (read-line in nil nil) > while line > do (replace-match > :source line :target wordpat :every-occurance t > :replacement #'(lambda (word) > (incf (gethash word words->count 0)) "")))) > (format t "~{~A~^~%~}" > (subseq (sort (all (w c) :in words->count) #'> :key #'second) 0 10)))) > I've come to this thread late, so I'm not completely sure about the exact specs of the code, but here's my take on a Python version. It comes in at a svelt 10 lines, and I think it's quite readable. I'm sure I'm missing something though. import sys words = {} for line in sys.stdin.readlines(): for word in line.split(): words[word] = words.get(word, 0) + 1 words = [[x[1], x[0]] for x in words.items()] words.sort() words.reverse() for word in words[:10]: print word[0], word[1] -- Adam Ruth adamruth at mac dot com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 21:13 ` Adam Ruth @ 2004-09-27 2:12 ` Keith H Duggar 2004-09-27 14:21 ` Adam Ruth 0 siblings, 1 reply; 229+ messages in thread From: Keith H Duggar @ 2004-09-27 2:12 UTC (permalink / raw) > I've come to this thread late, so I'm not completely sure about the > exact specs of the code, but here's my take on a Python version. It > comes in at a svelt 10 lines, and I think it's quite readable. I'm sure > I'm missing something though. > > import sys > > words = {} > for line in sys.stdin.readlines(): > for word in line.split(): > words[word] = words.get(word, 0) + 1 > > words = [[x[1], x[0]] for x in words.items()] > words.sort() > words.reverse() > > for word in words[:10]: > print word[0], word[1] Sweet. Python get's my vote for most readable in this case. The "for ... in ..." construct is very nice. It saves a lot of time and a lot of error prone indexing code. Thanks for posting it. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 2:12 ` Keith H Duggar @ 2004-09-27 14:21 ` Adam Ruth 2004-09-27 14:51 ` Chris Humphries 2004-09-27 20:34 ` Kevin Cline 0 siblings, 2 replies; 229+ messages in thread From: Adam Ruth @ 2004-09-27 14:21 UTC (permalink / raw) In article <b47de02.0409261812.659a923b@posting.google.com>, duggar@mit.edu (Keith H Duggar) wrote: > > I've come to this thread late, so I'm not completely sure about the > > exact specs of the code, but here's my take on a Python version. It > > comes in at a svelt 10 lines, and I think it's quite readable. I'm sure > > I'm missing something though. > > > > import sys > > > > words = {} > > for line in sys.stdin.readlines(): > > for word in line.split(): > > words[word] = words.get(word, 0) + 1 > > > > words = [[x[1], x[0]] for x in words.items()] > > words.sort() > > words.reverse() > > > > for word in words[:10]: > > print word[0], word[1] > > Sweet. Python get's my vote for most readable in this case. > The "for ... in ..." construct is very nice. It saves a lot > of time and a lot of error prone indexing code. Thanks for > posting it. Python and Ada tie for my favorite languages (with Lisp coming in a close second). Which I use, depends on the task at hand. Ada and Python seem to have similar philosophies, though on opposite sides of the spectrum. Python's designer had as an explicit goal: "There should only be one obvious way to do anything". Some think that that stifles creativity, but I disagree. It frees the programmer in my mind. While I'm not sure about the Ada designer, it seems that a similar philosophy was in play. That's a very "engineering" type of thought, as opposed to a "hacker" type of thought. That's actually my biggest problem with Perl. Its designer had as a goal that there should be as may ways to accomplish things as there are programmers. Great if you're just a hacker having fun, terrible if you're someone maintaining Perl code. I think that has more to do with Perl's unreadability than the syntax. I've never met a "great" Perl programmer (read, Perl hacker), who wasn't completely confused by their own two month old code. I've seen those same programmers be able to digest 20,000 line Python programs in an afternoon. I've not got nearly as much experience with Ada, but I can't see it being much different in that regard. -- Adam Ruth adamruth at mac dot com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:21 ` Adam Ruth @ 2004-09-27 14:51 ` Chris Humphries 2004-09-27 17:10 ` Adam Ruth 2004-09-27 20:16 ` Keith H Duggar 2004-09-27 20:34 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Chris Humphries @ 2004-09-27 14:51 UTC (permalink / raw) Adam Ruth wrote: > In article <b47de02.0409261812.659a923b@posting.google.com>, > duggar@mit.edu (Keith H Duggar) wrote: > > >>>I've come to this thread late, so I'm not completely sure about the >>>exact specs of the code, but here's my take on a Python version. It >>>comes in at a svelt 10 lines, and I think it's quite readable. I'm sure >>>I'm missing something though. >>> >>>import sys >>> >>>words = {} >>>for line in sys.stdin.readlines(): >>> for word in line.split(): >>> words[word] = words.get(word, 0) + 1 >>> >>>words = [[x[1], x[0]] for x in words.items()] >>>words.sort() >>>words.reverse() >>> >>>for word in words[:10]: >>> print word[0], word[1] >> >>Sweet. Python get's my vote for most readable in this case. >>The "for ... in ..." construct is very nice. It saves a lot >>of time and a lot of error prone indexing code. Thanks for >>posting it. > > > > Python and Ada tie for my favorite languages (with Lisp coming in a > close second). Which I use, depends on the task at hand. Ada and > Python seem to have similar philosophies, though on opposite sides of > the spectrum. Python's designer had as an explicit goal: > > "There should only be one obvious way to do anything". > > Some think that that stifles creativity, but I disagree. It frees the > programmer in my mind. While I'm not sure about the Ada designer, it > seems that a similar philosophy was in play. That's a very > "engineering" type of thought, as opposed to a "hacker" type of thought. > > That's actually my biggest problem with Perl. Its designer had as a > goal that there should be as may ways to accomplish things as there are > programmers. Great if you're just a hacker having fun, terrible if > you're someone maintaining Perl code. I think that has more to do with > Perl's unreadability than the syntax. I've never met a "great" Perl > programmer (read, Perl hacker), who wasn't completely confused by their > own two month old code. I've seen those same programmers be able to > digest 20,000 line Python programs in an afternoon. I've not got nearly > as much experience with Ada, but I can't see it being much different in > that regard. > That is not completely fair. It depends on the programmer as well. Having good documentation (including comments) as well as defined coding standards should make the code readable in any language, perl, python. Understanding the syntax of the language helps in both cases. If I know the syntax, and language, I can read any language the same. True that python by nature is easy to read, but it is unfair pit it against some perl code itself. I have seen python code that is hard to understand at a glance and perl code that is easy to understand at a glance :) I would like to see a perl programmer go over 20,000 lines of python, such as Zope and understand what is going on. Even for experienced python programmers or any programmer for that matter, that is a lot of code to read. Plus in a proper environment, there should be documentation somewhere before hand that defines what the purpose of the code us, use cases and even a explanation of what is going on from the mouth of the designers and programmers. That makes looking at code much easier, whatever the language... Even though the geeks in us would rather just look at the code first :) Perl gets a bad rap, just because there are 12341234 ways to do one thing, that doesn't make the language bad. I believe that Perl gets a bad rap from bad programmers/designers and thus bad code. The language is really a moot point if the foundation doesn't exist, or being built as you build. All things being equal, Ada is nice to have, yet Perl is no better off than Python in many respects, unless you talk about OO features and such. Perl 6 should be interesting (even though it may be vaporware for a few more years, heh). Only reason I could see why the argument of reading the language of Python over Perl would be better is if there was no documentation and you had no idea how it worked before opening up your editors and browsing files. Then the weak link isn't the language, but the software development team. Though it is easier to blame a language and take it from ourselves. Sure language syntax for readability is very nice to have, but it should not negate the need for proper documentation and standards :) Note: I am not attacking you bud, just pointing out something that is frustrating :) PS: I have done a ton of work with Python, and specifically Zope, even a Zope 3 sprint in NYC. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:51 ` Chris Humphries @ 2004-09-27 17:10 ` Adam Ruth 2004-09-27 20:16 ` Keith H Duggar 1 sibling, 0 replies; 229+ messages in thread From: Adam Ruth @ 2004-09-27 17:10 UTC (permalink / raw) In article <415828D5.8030905@unixfu.net>, Chris Humphries <chris@unixfu.net> wrote: > Adam Ruth wrote: > > In article <b47de02.0409261812.659a923b@posting.google.com>, > > duggar@mit.edu (Keith H Duggar) wrote: > > Python and Ada tie for my favorite languages (with Lisp coming in a > > close second). Which I use, depends on the task at hand. Ada and > > Python seem to have similar philosophies, though on opposite sides of > > the spectrum. Python's designer had as an explicit goal: > > > > "There should only be one obvious way to do anything". > > > > Some think that that stifles creativity, but I disagree. It frees the > > programmer in my mind. While I'm not sure about the Ada designer, it > > seems that a similar philosophy was in play. That's a very > > "engineering" type of thought, as opposed to a "hacker" type of thought. > > > > That's actually my biggest problem with Perl. Its designer had as a > > goal that there should be as may ways to accomplish things as there are > > programmers. Great if you're just a hacker having fun, terrible if > > you're someone maintaining Perl code. I think that has more to do with > > Perl's unreadability than the syntax. I've never met a "great" Perl > > programmer (read, Perl hacker), who wasn't completely confused by their > > own two month old code. I've seen those same programmers be able to > > digest 20,000 line Python programs in an afternoon. I've not got nearly > > as much experience with Ada, but I can't see it being much different in > > that regard. > > > > That is not completely fair. It depends on the programmer as well. > Having good documentation (including comments) as well as defined > coding standards should make the code readable in any language, > perl, python. Understanding the syntax of the language helps in > both cases. If I know the syntax, and language, I can read any > language the same. That's why I said: > > I've never met a "great" Perl > > programmer (read, Perl hacker), who wasn't completely confused by their > > own two month old code. I'm not talking about well disciplined engineers here. But when it comes to languages, some make bad programmers worse. Perl is one of those languages. Perl also tends to attract and encourage "hacker" style programming and bad practices. That's not to say it has a monopoly, I've seen a bunch of crappy unreadable Python code in my time. Why make life harder for yourself? That's what I ask myself when it comes to language choices. I pick a language that makes it easier to make better code. No language makes it truly impossible to write good code, but some do make it more difficult. Of course, no language makes it impossible to NOT write bad code. > > Perl gets a bad rap, just because there are 12341234 ways to do one > thing, that doesn't make the language bad. I disagree (in the sense of the topic, that being maintainability). No matter how good a programmer you are in Perl, another programmer will find it more difficult to follow your logic if they're used to doing things other ways. It's one more thing for them to process as they read your code. The fewer things that they need to understand as they read your code, the faster they will read it. > I believe that Perl gets > a bad rap from bad programmers/designers and thus bad code. The language > is really a moot point if the foundation doesn't exist, or being built > as you build. Agree completely. But I think the bad rap exists for a reason. I think that the ratio of bad/good code is higher in Perl than Python. Perl seems to encourage bad programming practices. > > All things being equal, Ada is nice to have, yet Perl is no better off > than Python in many respects, unless you talk about OO features and > such. Perl 6 should be interesting (even though it may be vaporware for > a few more years, heh). > > Only reason I could see why the argument of reading the language of > Python over Perl would be better is if there was no documentation and > you had no idea how it worked before opening up your editors and > browsing files. Then the weak link isn't the language, but the software > development team. Though it is easier to blame a language and take it > from ourselves. But that's reality. You rarely have control of those that came before you. Wouldn't you rather that they used a good language over a bad one? You'd certainly rather they used a good practice over a bad one. > > Sure language syntax for readability is very nice to have, but it should > not negate the need for proper documentation and standards :) Could not agree with you more! > > Note: I am not attacking you bud, just pointing out something that is > frustrating :) Understood. I'm not attacking you either. I'm attacking all the bad programmers who made code I need to maintain! > > PS: I have done a ton of work with Python, and specifically Zope, even a > Zope 3 sprint in NYC. Never worked with Zope, it looks interesting, but never really fit in with any of my requirements. -- Adam Ruth adamruth at mac dot com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:51 ` Chris Humphries 2004-09-27 17:10 ` Adam Ruth @ 2004-09-27 20:16 ` Keith H Duggar 2004-09-27 21:15 ` Chris Humphries 1 sibling, 1 reply; 229+ messages in thread From: Keith H Duggar @ 2004-09-27 20:16 UTC (permalink / raw) > That is not completely fair. It depends on the programmer as well. > Having good documentation (including comments) as well as defined > coding standards should make the code readable in any language, Any language? No amount of commenting will make Brain F*** or Whitespace readable. That is, the comments may be readable, the code will not be. And that is an important distinction, we are discussing (I think) the readability of CODE not the readability of comments. > perl, python. Understanding the syntax of the language helps in > both cases. If I know the syntax, and language, I can read any > language the same. Again as counter examples take BF and Whitespace. These are of course extreme examples but the valid point is that language absolutely affects readability. > True that python by nature is easy to read, but it is unfair pit > it against some perl code itself. I have seen python code that is > hard to understand at a glance and perl code that is easy to understand > at a glance :) I think understandability and readability are really quite different. For example, I am able to read the following English snip from your post > All things being equal, Ada is nice to have, yet Perl is no better off > than Python in many respects, unless you talk about OO features and > such. Perl 6 should be interesting (even though it may be vaporware for > a few more years, heh). but I do not understand it all. In other words, I find English highly readable yet many English "programs" such as the one above make no sense to me whatever. > Only reason I could see why the argument of reading the language of > Python over Perl would be better is if there was no documentation and > you had no idea how it worked before opening up your editors and For me, an ideally readable language would be as self-documenting as possible. Comments should just be gravy, summaries, or notices of something tricky or difficult to understand (not read). > Sure language syntax for readability is very nice to have, but it should > not negate the need for proper documentation and standards :) Hmm, it seems you are now contradicting your general sentiment and your earlier specific statement that > coding standards should make the code readable in any language, Do you or do you not believe that syntax affects readability? ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 20:16 ` Keith H Duggar @ 2004-09-27 21:15 ` Chris Humphries 2004-09-28 4:46 ` Keith H Duggar 0 siblings, 1 reply; 229+ messages in thread From: Chris Humphries @ 2004-09-27 21:15 UTC (permalink / raw) Not to make this a flame war, but it seems that you have never been in a professional software engineering environment that involved work on your part other than grunt code writing. Even someone that has been doing grunt code work for a long project would understand what I am saying. Hopefully it is was just communication errors on my part. :) Keith H Duggar wrote: >>That is not completely fair. It depends on the programmer as well. >>Having good documentation (including comments) as well as defined >>coding standards should make the code readable in any language, > > > Any language? No amount of commenting will make Brain F*** or > Whitespace readable. That is, the comments may be readable, > the code will not be. And that is an important distinction, > we are discussing (I think) the readability of CODE not the > readability of comments. > If Ada is about Software Engineering, then software documents and software code go hand in hand. Something that a college student probably has not experienced or learned yet. > >>perl, python. Understanding the syntax of the language helps in >>both cases. If I know the syntax, and language, I can read any >>language the same. > > > Again as counter examples take BF and Whitespace. These are > of course extreme examples but the valid point is that language > absolutely affects readability. > Well, lets exclude those languages as I, for one, do not know of any real production use of them or anyone that actually uses them outside of fun and tinkering. I was talking about languages you come across in reality, such as Perl, Python, C, C++. I understand the point of readability, but you should understand that any good software engineering process should include documentation, use cases, and other things that are related to the software and is not actual software code. The coding part is generally the easy part if the documentation and design are done properly. > >>True that python by nature is easy to read, but it is unfair pit >>it against some perl code itself. I have seen python code that is >>hard to understand at a glance and perl code that is easy to understand >>at a glance :) > > > I think understandability and readability are really quite > different. For example, I am able to read the following > English snip from your post > > >>All things being equal, Ada is nice to have, yet Perl is no better off >>than Python in many respects, unless you talk about OO features and >>such. Perl 6 should be interesting (even though it may be vaporware for >>a few more years, heh). > > > but I do not understand it all. In other words, I find > English highly readable yet many English "programs" such as > the one above make no sense to me whatever. > > >>Only reason I could see why the argument of reading the language of >>Python over Perl would be better is if there was no documentation and >>you had no idea how it worked before opening up your editors and > > > For me, an ideally readable language would be as self-documenting > as possible. Comments should just be gravy, summaries, or > notices of something tricky or difficult to understand (not read). > > >>Sure language syntax for readability is very nice to have, but it should >>not negate the need for proper documentation and standards :) > > > Hmm, it seems you are now contradicting your general > sentiment and your earlier specific statement that > The point was, which you totally missed, is that software design and other documentation define what the program is, how it works, breakdown flow and define in/outs, and other things. The code should just be an implementation or "reality" of the documentation. When I say "documentation", I mean documentation that exists outside the code itself. > >>coding standards should make the code readable in any language, > > > Do you or do you not believe that syntax affects readability? Of course I do, and thankful for it. When I say coding standards, I mean a predefined way of how code is to look, naming conventions, comments (and how they are to be, ie name, params descriptions, etc) and is a strict structure that is done. Many languages try to take care of this step for you, because honestly we do not live in a perfect world, and many companies/firms do not have this in place, so languages like Ada and Python help in this, as many [style] syntax structure is defined as part of the language syntax itself. The readability of the code seems more important relative to the lack of documentation. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 21:15 ` Chris Humphries @ 2004-09-28 4:46 ` Keith H Duggar 0 siblings, 0 replies; 229+ messages in thread From: Keith H Duggar @ 2004-09-28 4:46 UTC (permalink / raw) > Not to make this a flame war, but it seems that you have never > been in a professional software engineering environment that > involved work on your part other than grunt code writing. Hmm, are you sure you aren't projecting your own shortcomings onto me? Juding from this post and your others you come across to me as someone who just recently read a book about software engineering and now considers himself an authority. > Even > someone that has been doing grunt code work for a long project > would understand what I am saying. If you are refering to the snip I quoted in saying I didn't understand, I said so because the ENGLISH was vague and imprecise. If you are referring to your point of "documentation is very important" I have never disputed that and few if any here would. What I said was that it was off topic in the sense that the thread was talking about READABILITY of CODE not understandbility nor the readability of comments and documentation. Finally, judging from another of your posts where you wrote > Many young/inexperienced programmers do not even see why this is > important, as their code works, and generally they are done with it > then and there. In the real world, and in my job, most of the time > is spend updating code. Good times are when I get to design something > new, most the time is spent doing grunt work. you, if anyone, seem to fall squarely in the inexperienced (with respect to software design) grunt hacker group. More importantly, ad hominem has no place here so I would suggest that you reframe from it. Especially if you are trying to avoid flame. Better to focus on specific concrete responses. > Hopefully it is was just communication errors on my part. :) I believe it was. Also, I believe you strayed a little from the issue of readability of CODE into the issue of documentation and design. > documents and software code go hand in hand. Something > that a college student probably has not experienced or > learned yet. *smirks* You should try college sometime, you might actually learn some software engineering. And don't let the email fool you, I haven't been a "college" student in many years. And again, ad hominem has no useful place here. That is something that many people never learn in a lifetime. > > Again as counter examples take BF and Whitespace. These are > > of course extreme examples but the valid point is that language > > absolutely affects readability. > > > > Well, lets exclude those languages as I, for one, do not know of > any real production use of them or anyone that actually uses them > outside of fun and tinkering. I was talking about languages you > come across in reality, such as Perl, Python, C, C++. Then you should not exaggerate by saying "all". Further, they were simply counter examples to the extreme point that "syntax does not affect readability" which you seemed to be arguing. > I understand the point of readability, but you should understand > that any good software engineering process should include documentation, > use cases, and other things that are related to the software and > is not actual software code. The coding part is generally the easy > part if the documentation and design are done properly. I'm glad you understand the point of readability. And, I never claimed that documentation etc are unimportant. That is somewhat obvious to me and a point that I for one have never denied. > The code > should just be an implementation or "reality" of the documentation. The "should just be" is obviously not true. Machine language is "just an implementation" yet there are obvious reasons we don't write in it. What code "should be" depends on who you ask. Many argue it should serve as documentation, specification, implementation, a design language, etc to varying degrees. The extreme view that it "should just be implementation" is just that, extreme. > When I say "documentation", I mean documentation that exists > outside the code itself. Isn't this thread about the readability of CODE not not the readability of documentation? > > Do you or do you not believe that syntax affects readability? > > Of course I do, and thankful for it. Ok, then case closed. Syntax can affect readbility. And as I stated previously I found the Python syntax the most readable for this particular example. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:21 ` Adam Ruth 2004-09-27 14:51 ` Chris Humphries @ 2004-09-27 20:34 ` Kevin Cline 2004-09-27 21:15 ` Adam Ruth 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-27 20:34 UTC (permalink / raw) Adam Ruth <adam.ruth@mac.com> wrote in message news:<adam.ruth-CEAF21.08210127092004@localhost>... > In article <b47de02.0409261812.659a923b@posting.google.com>, > duggar@mit.edu (Keith H Duggar) wrote: > > > > I've come to this thread late, so I'm not completely sure about the > > > exact specs of the code, but here's my take on a Python version. It > > > comes in at a svelt 10 lines, and I think it's quite readable. I'm sure > > > I'm missing something though. > > > > > > import sys > > > > > > words = {} > > > for line in sys.stdin.readlines(): > > > for word in line.split(): > > > words[word] = words.get(word, 0) + 1 > > > > > > words = [[x[1], x[0]] for x in words.items()] > > > words.sort() > > > words.reverse() > > > > > > for word in words[:10]: > > > print word[0], word[1] > > > > Sweet. Python get's my vote for most readable in this case. > > The "for ... in ..." construct is very nice. It saves a lot > > of time and a lot of error prone indexing code. Thanks for > > posting it. > > > Python and Ada tie for my favorite languages (with Lisp coming in a > close second). Which I use, depends on the task at hand. Ada and > Python seem to have similar philosophies, though on opposite sides of > the spectrum. Python's designer had as an explicit goal: > > "There should only be one obvious way to do anything". > > Some think that that stifles creativity, but I disagree. It frees the > programmer in my mind. While I'm not sure about the Ada designer, it > seems that a similar philosophy was in play. That's a very > "engineering" type of thought, as opposed to a "hacker" type of thought. > > That's actually my biggest problem with Perl. Its designer had as a > goal that there should be as may ways to accomplish things as there are > programmers. That was not so much a goal as property that emerged as the language grew. Features were added to make it convenient to do some things, or to improve code readability, /without worrying about feature overlap. So you can say either if (!condition) { statement; } or unless (condition) { statement; } or statement unless (condition); Or you can say either foreach $element (list) { do something; } or map { something } (list); Having more than one way to do things makes it easier to write readable code. And also easier to write unreadable code. > Great if you're just a hacker having fun, terrible if > you're someone maintaining Perl code. Really not so terrible. > I think that has more to do with Perl's unreadability than the syntax. I've > never met a "great" Perl > programmer (read, Perl hacker), who wasn't completely confused by their > own two month old code. Then you've never met a great Perl programmer. The great programmers I've known can write crystal-clear code in almost any language, with very little need for explanatory comments beyond class and function descriptions. I've read a lot of CPAN modules and found most of them pretty clear. But there are some very high-level PERL modules that allow one to do a lot with a little code, and it takes a little effort to learn what those modules do. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 20:34 ` Kevin Cline @ 2004-09-27 21:15 ` Adam Ruth 0 siblings, 0 replies; 229+ messages in thread From: Adam Ruth @ 2004-09-27 21:15 UTC (permalink / raw) In article <e749549b.0409271234.1c2b4b92@posting.google.com>, kevin.cline@gmail.com (Kevin Cline) wrote: > Adam Ruth <adam.ruth@mac.com> wrote in message > news:<adam.ruth-CEAF21.08210127092004@localhost>... > > In article <b47de02.0409261812.659a923b@posting.google.com>, > > duggar@mit.edu (Keith H Duggar) wrote: > > I think that has more to do with Perl's unreadability than the syntax. > > I've > > never met a "great" Perl > > programmer (read, Perl hacker), who wasn't completely confused by their > > own two month old code. > > Then you've never met a great Perl programmer. The great programmers > I've known can write crystal-clear code in almost any language, with > very little need for explanatory comments beyond class and function > descriptions. Not so, I've met plenty of great Perl programmers. It's not them I was referring to. I was referring to "great" Perl programmers, or Perl hackers in reality. People with no sense of engineering. I mustn't have made that clear enough... and I wasn't even writing in Perl! > > I've read a lot of CPAN modules and found most of them pretty clear. > But there are some very high-level PERL modules that allow one to do a > lot with a little code, and it takes a little effort to learn what > those modules do. -- Adam Ruth adamruth at mac dot com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 8:51 ` Kevin Cline 2004-09-23 11:01 ` Georg Bauhaus 2004-09-23 19:10 ` jayessay @ 2004-09-23 23:05 ` Brian May 2004-09-24 3:06 ` Matthew Heaney 2004-09-24 3:52 ` Randy Brukardt 2004-09-24 0:19 ` Stephen Leake 3 siblings, 2 replies; 229+ messages in thread From: Brian May @ 2004-09-23 23:05 UTC (permalink / raw) >>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes: Kevin> It's pretty hard to make the case that this Ada code: Kevin> procedure Insert (Word : String) is Kevin> I : Wordcount_Maps.Iterator_Type; Kevin> B : Boolean; Kevin> type Element_Access is access all Wordcount_Maps.Element_Subtype; Kevin> for Element_Access'Storage_Size use 0; Kevin> function To_Access is new Wordcount_Maps.Generic_Element Kevin> (Element_Access); Kevin> begin -- Insert Kevin> Insert (Map, To_Lower (Word), 0, I, B); Kevin> declare E : Wordcount_Maps.Element_Subtype renames To_Access Kevin> (I).all; Kevin> begin Kevin> E := E + 1; Kevin> end; Kevin> end Insert; The following code (or something like it), I believe (not tested), should reduce the line count (and complexity) of the above: procedure Insert (Word : String) is I : Wordcount_Maps.Iterator_Type; B : Boolean; begin -- Insert Insert (Map, To_Lower (Word), 0, I, B); Replace_Element(I, Element(I) + 1); end Insert; -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 23:05 ` Brian May @ 2004-09-24 3:06 ` Matthew Heaney 2004-09-24 3:52 ` Randy Brukardt 1 sibling, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 3:06 UTC (permalink / raw) Brian May <bam@snoopy.apana.org.au> writes: > The following code (or something like it), I believe (not tested), > should reduce the line count (and complexity) of the above: > > procedure Insert (Word : String) is > I : Wordcount_Maps.Iterator_Type; > B : Boolean; > > begin -- Insert > Insert (Map, To_Lower (Word), 0, I, B); > Replace_Element(I, Element(I) + 1); > end Insert; Yes, that's true, but the point of the original example was to show how to modify the element in-place, as you do for C++. Clearly, in the case of an object of type Integer, you don't really need to modify the object in place, and your solution above is perfectly adequate (and simpler too). Support for in-place modification is really provided for composition of containers. So for example, if you have a container whose elements are another container, then you need in-place modification to manipulate the (container) element. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 23:05 ` Brian May 2004-09-24 3:06 ` Matthew Heaney @ 2004-09-24 3:52 ` Randy Brukardt 2004-09-24 5:15 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 229+ messages in thread From: Randy Brukardt @ 2004-09-24 3:52 UTC (permalink / raw) "Brian May" <bam@snoopy.apana.org.au> wrote in message news:sa4ekks60xf.fsf@snoopy.apana.org.au... ... > The following code (or something like it), I believe (not tested), > should reduce the line count (and complexity) of the above: > > procedure Insert (Word : String) is > I : Wordcount_Maps.Iterator_Type; > B : Boolean; > > begin -- Insert > Insert (Map, To_Lower (Word), 0, I, B); > Replace_Element(I, Element(I) + 1); > end Insert; I was going to post something similar, as update-in-place is a premature optimization in this case. As far as I can tell, all this thread proves is that it would be nice if Ada allowed redefinition of some of the operations (as opposed to operators) like "in" and "()". And that the overriding concern for safety in Ada makes code a bit longer. The latter is why there aren't implicit instantiations, and why there isn't a routine like: function Modify_Element (Item : in Cursor) return access Element_Type; (Humm, the other reason was that 3.6(11) caused trouble -- but that's been repealed. I wonder if that decision should be revisited??) Randy. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 3:52 ` Randy Brukardt @ 2004-09-24 5:15 ` Matthew Heaney 2004-09-24 19:12 ` Kevin Cline 2004-09-26 17:10 ` jayessay 2 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 5:15 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > I was going to post something similar, as update-in-place is a > premature optimization in this case. Actually, I just finished the indefinite ordered maps, and realized that Replace_Element deallocates the old element and reallocates a new element. So you could make a good case that Update_Element is the better choice here. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 3:52 ` Randy Brukardt 2004-09-24 5:15 ` Matthew Heaney @ 2004-09-24 19:12 ` Kevin Cline 2004-09-24 20:54 ` Randy Brukardt 2004-09-27 13:22 ` Chris Humphries 2004-09-26 17:10 ` jayessay 2 siblings, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-24 19:12 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<mOednXIrZJxIBM7cRVn-uQ@megapath.net>... > "Brian May" <bam@snoopy.apana.org.au> wrote in message > news:sa4ekks60xf.fsf@snoopy.apana.org.au... > ... > > The following code (or something like it), I believe (not tested), > > should reduce the line count (and complexity) of the above: > > > > procedure Insert (Word : String) is > > I : Wordcount_Maps.Iterator_Type; > > B : Boolean; > > > > begin -- Insert > > Insert (Map, To_Lower (Word), 0, I, B); > > Replace_Element(I, Element(I) + 1); > > end Insert; > > I was going to post something similar, as update-in-place is a premature > optimization in this case. > > As far as I can tell, all this thread proves is that it would be nice if Ada > allowed redefinition of some of the operations (as opposed to operators) > like "in" and "()". And that the overriding concern for safety in Ada makes > code a bit longer. Again, the original question was "Why isn't Ada more popular?" The answer I am giving is that most programmers don't have such an overriding concern for safety that they are willing to write twice as much code to get the additional safety. > The latter is why there aren't implicit instantiations, > and why there isn't a routine like: > > function Modify_Element (Item : in Cursor) return access Element_Type; Ok, although it's not readily apparent to me why implicit instantiations are inherently unsafe. Nor do I believe reference expressions like concordance[word] are inherently unsafe. Storing the reference in a variable that may outlive the referent is unsafe, but I don't see why this is different from Ada access types. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 19:12 ` Kevin Cline @ 2004-09-24 20:54 ` Randy Brukardt 2004-09-24 21:23 ` Matthew Heaney 2004-09-27 13:22 ` Chris Humphries 1 sibling, 1 reply; 229+ messages in thread From: Randy Brukardt @ 2004-09-24 20:54 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409241112.44f4bc85@posting.google.com... ... > Ok, although it's not readily apparent to me why implicit > instantiations are inherently unsafe. Nor do I believe reference > expressions like > concordance[word] > are inherently unsafe. Storing the reference in a variable that may > outlive the referent is unsafe, but I don't see why this is different > from Ada access types. It isn't different than Ada access types, that's the point. Access types are inherently unsafe and should be avoided when possible. (But not to go overboard, of course.) That's an important design issue when designing reusable libraries. My personal rule is that such libraries should not contain access types of any kind in their specification unless they are doing something that requires dynamic management of objects. (That's rather rare.) In Ada, there is no need to use access types to get OOP or to get objects sized at runtime -- those uses are common in other languages. Ada goes to fairly great lengths to try to avoid dangling pointers (the dreaded accessibility rules), so access types in Ada are a bit safer than those in some other languages. But that doesn't make them safe by any means. In this particular case, the access would have roughly the same erroneous use rules as a cursor does, which wouldn't be that awful. But it wouldn't be a very good example of Ada design, because the library would return an access to a data structure that is managed by other code -- which cannot know whether any accesses remain -- so it would be impossible to be safe. (I'm intending an implementation of the containers library that will try to detect dangling cursors, so there will be little chance of building buggy code with it.) Randy. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 20:54 ` Randy Brukardt @ 2004-09-24 21:23 ` Matthew Heaney 0 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 21:23 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:sOudnSKh7rXbFMncRVn-jg@megapath.net... > > (I'm intending an implementation of the containers library that will try to > detect dangling cursors, so there will be little chance of building buggy > code with it.) Actually, I had wanted to build something similar for AI-302, once the work on the reference implementation settles down. There are after-market STLs like that, and it wouldn't be hard to build a debug-version of AI-302 for Ada. All you'd need to do to detect dangling cursors is to implement type Cursor as a private derivation from Controlled, and then add a reference count to the internal storage node. If that element (node) is deleted, then you could inspect the reference count to see if it's non-zero. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 19:12 ` Kevin Cline 2004-09-24 20:54 ` Randy Brukardt @ 2004-09-27 13:22 ` Chris Humphries 2004-09-27 13:45 ` Chris Humphries 2004-09-27 21:31 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Chris Humphries @ 2004-09-27 13:22 UTC (permalink / raw) Kevin Cline wrote: > > Again, the original question was "Why isn't Ada more popular?" > > The answer I am giving is that most programmers don't have such an > overriding concern for safety that they are willing to write twice as > much code to get the additional safety. > (whoa, what a thread this has become!) Thanks, and good answer. Since then asking that question, I have learned a lot more about Ada. John Barnes' book, "Programming in Ada 96, 2nd Edition" helped tremendously. A very good book. It is now nice to understand just what Ada _is_, and not just another programming language, but more an attempting at progressing software engineering. I also think I understand why Ada is not more popular. Though I am very thankful for open source, and feel very strongly about about it, something bad has grown out of it: bad programmers and programs. Most open source projects seem to have no formal software development process. There is more an attitude of "shut up and hack", which typically goes by whatever they get features to do from, which may be from whatever they want, if there is a TODO list, then you are lucky. There is usually no goals or anything actually defined, no use cases (I would put money on most do not even know what one is, and if they did, what they would use it for), no unit tests or any automated framework for making sure the code does as designed (which brings me to my next one), no design documentation or even a design process. Many young/inexperienced programmers do not even see why this is important, as their code works, and generally they are done with it then and there. In the real world, and in my job, most of the time is spend updating code. Good times are when I get to design something new, most the time is spent doing grunt work. In a time when most programs are written by having a 1-2 thought process of 1) i want my program to do this and 2) type-type-run-repeat, such languages that allow you to do this easier are more popular, such as php and perl. Granted, I do code perl for some of the legacy projects here (no I am not a web developer, heh), and if standards are in place, perl code can be very readable and understandable. Coding standards are nice, yet seem to be rarely used. Again, sorry to start a thread that went off on a 400+ post tangent, yet now I understand. If anyone new to Ada, yet not to programming is reading this, I strongly recommend getting "Programming in Ada 95, 2nd Edition" by John Barnes. Thanks c.l.ada! -Chris ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 13:22 ` Chris Humphries @ 2004-09-27 13:45 ` Chris Humphries 2004-09-27 21:31 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Chris Humphries @ 2004-09-27 13:45 UTC (permalink / raw) I apologize, first thing in the morning on a monday without any caffeine :) Type-o's exist in places, heh. Chris Humphries wrote: > Kevin Cline wrote: > >> >> Again, the original question was "Why isn't Ada more popular?" >> The answer I am giving is that most programmers don't have such an >> overriding concern for safety that they are willing to write twice as >> much code to get the additional safety. >> > > (whoa, what a thread this has become!) > > Thanks, and good answer. Since then asking that question, I have > learned a lot more about Ada. John Barnes' book, "Programming in > Ada 96, 2nd Edition" helped tremendously. A very good book. It is > now nice to understand just what Ada _is_, and not just another > programming language, but more an attempting at progressing software > engineering. > > I also think I understand why Ada is not more popular. Though I > am very thankful for open source, and feel very strongly about about > it, something bad has grown out of it: bad programmers and programs. > Most open source projects seem to have no formal software development > process. There is more an attitude of "shut up and hack", which > typically goes by whatever they get features to do from, which may > be from whatever they want, if there is a TODO list, then you are > lucky. There is usually no goals or anything actually defined, no > use cases (I would put money on most do not even know what one is, > and if they did, what they would use it for), no unit tests or any > automated framework for making sure the code does as designed (which > brings me to my next one), no design documentation or even a design > process. > > Many young/inexperienced programmers do not even see why this is > important, as their code works, and generally they are done with it > then and there. In the real world, and in my job, most of the time > is spend updating code. Good times are when I get to design something > new, most the time is spent doing grunt work. > > In a time when most programs are written by having a 1-2 thought > process of 1) i want my program to do this and 2) type-type-run-repeat, > such languages that allow you to do this easier are more popular, such > as php and perl. > > Granted, I do code perl for some of the legacy projects here (no I am > not a web developer, heh), and if standards are in place, perl code can > be very readable and understandable. Coding standards are nice, yet > seem to be rarely used. > > Again, sorry to start a thread that went off on a 400+ post tangent, > yet now I understand. > > If anyone new to Ada, yet not to programming is reading this, I strongly > recommend getting "Programming in Ada 95, 2nd Edition" by John Barnes. > > Thanks c.l.ada! > > -Chris ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 13:22 ` Chris Humphries 2004-09-27 13:45 ` Chris Humphries @ 2004-09-27 21:31 ` Kevin Cline 2004-09-27 23:51 ` Brian May 2004-09-28 12:21 ` Chris Humphries 1 sibling, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-27 21:31 UTC (permalink / raw) Chris Humphries <chris@unixfu.net> wrote in message news:<415813FE.9090803@unixfu.net>... > Kevin Cline wrote: > > > > Again, the original question was "Why isn't Ada more popular?" > > > > The answer I am giving is that most programmers don't have such an > > overriding concern for safety that they are willing to write twice as > > much code to get the additional safety. > > > > (whoa, what a thread this has become!) > > Thanks, and good answer. Since then asking that question, I have > learned a lot more about Ada. John Barnes' book, "Programming in > Ada 96, 2nd Edition" helped tremendously. A very good book. It is > now nice to understand just what Ada _is_, and not just another > programming language, but more an attempting at progressing software > engineering. > > I also think I understand why Ada is not more popular. Though I > am very thankful for open source, and feel very strongly about about > it, something bad has grown out of it: bad programmers and programs. Bad programmers didn't come from open source. There have always been bad programmers, and there always will be. Just as it is with music and writing and film and art, 90% of all programming sucks. > Most open source projects seem to have no formal software development > process... > Many young/inexperienced programmers do not even see why this is > important, as their code works, and generally they are done with it > then and there. This is also true for a surprising number of old and experienced programmers. > In the real world, and in my job, most of the time > is spend updating code. Good times are when I get to design something > new, most the time is spent doing grunt work. This situation is common, but not inevitable. On a good project, design is a continuous process. Unfortunately, most programs reach the point where any change is so risky that developers spend all their time trying to figure out how to squeeze in a new feature without breaking the existing features. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 21:31 ` Kevin Cline @ 2004-09-27 23:51 ` Brian May 2004-09-28 12:21 ` Chris Humphries 1 sibling, 0 replies; 229+ messages in thread From: Brian May @ 2004-09-27 23:51 UTC (permalink / raw) >>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes: Kevin> Bad programmers didn't come from open source. There have Kevin> always been bad programmers, and there always will be. Kevin> Just as it is with music and writing and film and art, 90% Kevin> of all programming sucks. I know of commercial programs that are developed (designed, implemented, and tested) very badly just as I know of open source projects that appear to be handled very well. Commercial projects can be put under pressure to cut corners, e.g. because management sees a formal software development process as an academic exercise that is a complete waste of time "in the real world"(TM), despite protests from programmers. The same management see software development as a tedious and unreliable process, and don't make the connection that the lack of a proper development process could be leading to the difficulties. They often give solutions (that may be inadequate) rather then requirements, turning the task of programming into a guessing game. Open source developers aren't under these pressures, and have more scope for doing the right thing. (this isn't to imply that all open source projects are developed correctly; some are bad too; this doesn't imply all commercial projects are developed badly either). -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 21:31 ` Kevin Cline 2004-09-27 23:51 ` Brian May @ 2004-09-28 12:21 ` Chris Humphries 1 sibling, 0 replies; 229+ messages in thread From: Chris Humphries @ 2004-09-28 12:21 UTC (permalink / raw) Kevin Cline wrote: > Chris Humphries <chris@unixfu.net> wrote in message news:<415813FE.9090803@unixfu.net>... > >>Kevin Cline wrote: >> >>>Again, the original question was "Why isn't Ada more popular?" >>> >>>The answer I am giving is that most programmers don't have such an >>>overriding concern for safety that they are willing to write twice as >>>much code to get the additional safety. >>> >> >>(whoa, what a thread this has become!) >> >>Thanks, and good answer. Since then asking that question, I have >>learned a lot more about Ada. John Barnes' book, "Programming in >>Ada 96, 2nd Edition" helped tremendously. A very good book. It is >>now nice to understand just what Ada _is_, and not just another >>programming language, but more an attempting at progressing software >>engineering. >> >>I also think I understand why Ada is not more popular. Though I >>am very thankful for open source, and feel very strongly about about >>it, something bad has grown out of it: bad programmers and programs. > > > Bad programmers didn't come from open source. There have always been > bad programmers, and there always will be. Just as it is with music > and writing and film and art, 90% of all programming sucks. > I didn't mean that, I apologize for the communication error. I meant that the general open source development community and environment doesn't generally have a software development process other than run and see if it does what you think, then repeat. Though the *Unit classes are spreading out and becoming more popular, though you can usually tell that they have more formal development standards in place, such as the Mono (http://mono-project.com which is backed by Novell) and Zope (http://zope.org which is backed by the Zope Corporation http://zope.com) projects. I did not mean to imply that all open source is bad, sure there are bad projects everywhere (closed and open source). > >>Most open source projects seem to have no formal software development >>process... >>Many young/inexperienced programmers do not even see why this is >>important, as their code works, and generally they are done with it >>then and there. > > > This is also true for a surprising number of old and experienced > programmers. > > >>In the real world, and in my job, most of the time >>is spend updating code. Good times are when I get to design something >>new, most the time is spent doing grunt work. > > > This situation is common, but not inevitable. On a good project, > design is a continuous process. Unfortunately, most programs reach > the point where any change is so risky that developers spend all their > time trying to figure out how to squeeze in a new feature without > breaking the existing features. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 3:52 ` Randy Brukardt 2004-09-24 5:15 ` Matthew Heaney 2004-09-24 19:12 ` Kevin Cline @ 2004-09-26 17:10 ` jayessay 2004-09-26 20:00 ` Georg Bauhaus 2 siblings, 1 reply; 229+ messages in thread From: jayessay @ 2004-09-26 17:10 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > As far as I can tell, all this thread proves is that it would be nice if Ada > allowed redefinition of some of the operations (as opposed to operators) > like "in" and "()". And that the overriding concern for safety in Ada makes > code a bit longer. I don't think this thread "proves" anything. Also there is nothing in this thread to indicate in any sense that an "overiding concern for safety" should make code longer. Certainly there is nothing in any of the Ada given that is more checked or "safe" than in the Lisp examples. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 17:10 ` jayessay @ 2004-09-26 20:00 ` Georg Bauhaus 2004-09-27 14:45 ` jayessay 0 siblings, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-09-26 20:00 UTC (permalink / raw) jayessay <nospam@foo.com> wrote: : I don't think this thread "proves" anything. Also there is nothing in : this thread to indicate in any sense that an "overiding concern for : safety" should make code longer. Certainly there is nothing in any of : the Ada given that is more checked or "safe" than in the Lisp examples. I also don't think that this thread "proves" anything. Certainly it doesn't "prove" that static type checking doesn't add to safety. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 20:00 ` Georg Bauhaus @ 2004-09-27 14:45 ` jayessay 0 siblings, 0 replies; 229+ messages in thread From: jayessay @ 2004-09-27 14:45 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > jayessay <nospam@foo.com> wrote: > > : I don't think this thread "proves" anything. Also there is nothing in > : this thread to indicate in any sense that an "overiding concern for > : safety" should make code longer. Certainly there is nothing in any of > : the Ada given that is more checked or "safe" than in the Lisp examples. > > I also don't think that this thread "proves" anything. Certainly it > doesn't "prove" that static type checking doesn't add to safety. Nor that it does. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 8:51 ` Kevin Cline ` (2 preceding siblings ...) 2004-09-23 23:05 ` Brian May @ 2004-09-24 0:19 ` Stephen Leake 2004-09-24 14:54 ` Cesar Rabak 3 siblings, 1 reply; 229+ messages in thread From: Stephen Leake @ 2004-09-24 0:19 UTC (permalink / raw) To: comp.lang.ada kevin.cline@gmail.com (Kevin Cline) writes: > It's pretty hard to make the case that this Ada code: > > procedure Insert (Word : String) is > I : Wordcount_Maps.Iterator_Type; > B : Boolean; > type Element_Access is access all Wordcount_Maps.Element_Subtype; > > for Element_Access'Storage_Size use 0; > > function To_Access is new Wordcount_Maps.Generic_Element > (Element_Access); > > begin -- Insert > Insert (Map, To_Lower (Word), 0, I, B); > declare E : Wordcount_Maps.Element_Subtype renames To_Access > (I).all; > begin > E := E + 1; > end; > end Insert; > > is easier to understand than the corresponding C++ code: > ++concordance[word]; > > or the corresponding Perl code: > ++$count{$word}; You're kidding, right? All I need to do for the Ada code is add: procedure "+" (Word : in String) renames Insert; and the final user code is: +Word; -- -- Stephe ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 0:19 ` Stephen Leake @ 2004-09-24 14:54 ` Cesar Rabak 0 siblings, 0 replies; 229+ messages in thread From: Cesar Rabak @ 2004-09-24 14:54 UTC (permalink / raw) Stephen Leake escreveu: > kevin.cline@gmail.com (Kevin Cline) writes: > > >>It's pretty hard to make the case that this Ada code: >> >> procedure Insert (Word : String) is >> I : Wordcount_Maps.Iterator_Type; >> B : Boolean; >> type Element_Access is access all Wordcount_Maps.Element_Subtype; >> >> for Element_Access'Storage_Size use 0; >> >> function To_Access is new Wordcount_Maps.Generic_Element >>(Element_Access); >> >> begin -- Insert >> Insert (Map, To_Lower (Word), 0, I, B); >> declare E : Wordcount_Maps.Element_Subtype renames To_Access >>(I).all; >> begin >> E := E + 1; >> end; >> end Insert; >> >>is easier to understand than the corresponding C++ code: >> ++concordance[word]; >> >>or the corresponding Perl code: >> ++$count{$word}; > > > You're kidding, right? All I need to do for the Ada code is add: > > procedure "+" (Word : in String) renames Insert; > > and the final user code is: > > +Word; > Stephen, I think the point Kevin is trying to make� is that "++$count{$word};" is already built in the Perl language, whereas "procedure "+" (Word : in String) renames Insert;" requires we _implement_ Insert as above. -- Cesar Rabak [1] I'm not completely agreeing, but would like to put that in another thread. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline 2004-09-22 2:16 ` Pylinius 2004-09-22 8:50 ` Björn Persson @ 2004-09-22 15:27 ` James Alan Farrell 2004-09-22 21:24 ` Simon Wright 2004-09-23 9:00 ` Kevin Cline 2004-09-22 21:05 ` Georg Bauhaus ` (5 subsequent siblings) 8 siblings, 2 replies; 229+ messages in thread From: James Alan Farrell @ 2004-09-22 15:27 UTC (permalink / raw) On 21 Sep 2004 17:21:38 -0700, kevin.cline@gmail.com (Kevin Cline) wrote: >As promised in the Ada popularity thread, I have taken one of the >Charles examples and reimplemented it in C++. I used only the >standard C++ language and libraries. The Ada/CHARLES main program >body is 118 (non-blank) lines of code, plus an additional 40 lines of >instantiations in eight other specification files, for a total of 158 >lines and 9 files. The C++ implementation is 76 (non-blank) lines of >code in a single file. For grins, I also wrote the program in Perl. >That took 14 lines. > >Summary: > >Ada/Charles 158 lines, 9 files >C++ 76 lines >Perl 14 lines > >You can compare the implementations at >http://www.geocities.com/kc0a/wordcount.html Just have to put my $0.02 in on this: Does this prove that perl is the best language? If so, perhaps we should all switch our avionics projects over to perl. Must be it will be easier to code and maintain, safer to fly, and run just as fast. The things that make a language a "good" language are many and complex, and are different in different circumstances. If I need a small utility that compares lines in different text files, I find perl much easier than Ada. On the other hand, if I have a very large project that must always perform "correctly", I've not found a language that can beat Ada. But then I've never used Eiffel. James Alan Farrell ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 15:27 ` James Alan Farrell @ 2004-09-22 21:24 ` Simon Wright 2004-09-23 0:03 ` Brian May ` (2 more replies) 2004-09-23 9:00 ` Kevin Cline 1 sibling, 3 replies; 229+ messages in thread From: Simon Wright @ 2004-09-22 21:24 UTC (permalink / raw) James Alan Farrell <anonymous@anonymous.com> writes: > The things that make a language a "good" language are many and > complex, and are different in different circumstances. If I need a > small utility that compares lines in different text files, I find > perl much easier than Ada. On the other hand, if I have a very > large project that must always perform "correctly", I've not found a > language that can beat Ada. Even I would accept that Ada may just not be the best language in the world for text processing! We needed a program to remove the private part of a package spec; the winner was the one-line sed script you can select off the Wiki and paste into an xterm. And there's the Ada line counter (which includes semicolons in comments and strings but is still useful): $ tr -cd ';' <bcwords.ada | wc -c (by the way, that shows that the Booch Components version of the word counter comes in at 123 lines). As you say, there's a boundary somewhere between those and the missile guidance system where the choices change. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 21:24 ` Simon Wright @ 2004-09-23 0:03 ` Brian May 2004-09-23 9:17 ` Kevin Cline 2004-09-23 0:44 ` Jeffrey Carter 2004-09-23 8:15 ` Martin Krischik 2 siblings, 1 reply; 229+ messages in thread From: Brian May @ 2004-09-23 0:03 UTC (permalink / raw) >>>>> "Simon" == Simon Wright <simon@pushface.org> writes: Simon> James Alan Farrell <anonymous@anonymous.com> writes: >> The things that make a language a "good" language are many and >> complex, and are different in different circumstances. If I >> need a small utility that compares lines in different text >> files, I find perl much easier than Ada. On the other hand, if >> I have a very large project that must always perform >> "correctly", I've not found a language that can beat Ada. Simon> Even I would accept that Ada may just not be the best Simon> language in the world for text processing! Perl has high level primitive for: * <> operator * built in $hash{$index} * split function C++ * doesn't have the <> operator so the files have to be opened manually. * uses std::map instead of $hash{$index} which is more verbose for extra type checking. * requires both word_list (std::list) and word_map (std::map), I am guessing this is because it is not possible to have an ordered std::map. (as distinct from the perl solution). * doesn't have the split operator, so needs a get_word function. ADA * doesn't have the <> operator so files have to be opened manually. * the insert function seems complicated, not convinced this is required (maybe it is). * has a find_token function which somewhat simplifies the C++ code for get_word, but not quite as simple as the perl code. * has more overhead because of increased type checking. In the Ada case, putting almost everything in one big huge, ugly, function doesn't help readability (maybe this is a bit extreme, but one of my university lecturers insisted that no function/procedure/subroutine/whatever-you-call-it should be longer then a page). I would say this is a good example of why programming in Ada does not necessarily mean excellent code. If I were writing this, I would try splitting along similar lines as the perl code, e.g.: (disclaimer: not tested; syntax may not be exactly correct; still you should get the general idea). with Input; with Word; with Word_Map; with Ada.Text_IO. procedure Wordcount is Line : String; Word : String; n : Integer := 0; begin while Input.More do Word.Set_Line(Input.Get_Line); while Word.More do Word_Map.Add_Word(Word.Get_Word); Word.Next; end while; Input.Next; end while; Word_Map.sort; while Word_Map.More and n <= 10 then Put(Word_Map.Get_Word); Put(' '); Put(Word_Map.Get_Count, Width => 0); New_Line; Word_Map.Next; n := n + 1; end; end Wordcount; I think something like this could be just as readable as the perl code (you might argue that it is more readable), even though there are extra packages required that I haven't considered, and the total line count is likely to be higher. Sure, some of the packages could also be more generic and/or task safe (e.g. no objects or iterators used), but a generic solution wasn't required so I didn't bother. Also it is perhaps worth noting that while the perl code seems simple now, if the specifications were to incrementally change, the resultant code may not be so simple. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 0:03 ` Brian May @ 2004-09-23 9:17 ` Kevin Cline 0 siblings, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 9:17 UTC (permalink / raw) Brian May <bam@snoopy.apana.org.au> wrote in message news:<sa41xgtam2g.fsf@snoopy.apana.org.au>... > >>>>> "Simon" == Simon Wright <simon@pushface.org> writes: > > Simon> James Alan Farrell <anonymous@anonymous.com> writes: > >> The things that make a language a "good" language are many and > >> complex, and are different in different circumstances. If I > >> need a small utility that compares lines in different text > >> files, I find perl much easier than Ada. On the other hand, if > >> I have a very large project that must always perform > >> "correctly", I've not found a language that can beat Ada. > > Simon> Even I would accept that Ada may just not be the best > Simon> language in the world for text processing! > > Perl has high level primitive for: > > * <> operator > > * built in $hash{$index} > > * split function > > C++ > > * doesn't have the <> operator so the files have to be opened manually. > > * uses std::map instead of $hash{$index} which is more verbose for extra > type checking. The map has to be declared, but then you can simply say map[key]. > > * requires both word_list (std::list) and word_map (std::map), I am > guessing this is because it is not possible to have an ordered > std::map. (as distinct from the perl solution). Actually, the map keys are ordered, but the program prints the words in order from most to least frequent, so you need to resort on the map values. > > * doesn't have the split operator, so needs a get_word function. That was the most painful part. I spent a while trying to figure out if it could be done using the >> operator by modifying the definition of whitespace, but gave up. That part of the library could be improved. Alternatively, I could have used boost::regex and saved a dozen lines or so. > ADA > > * doesn't have the <> operator so files have to be opened manually. > > * the insert function seems complicated, not convinced this is > required (maybe it is). > > * has a find_token function which somewhat simplifies the C++ code for > get_word, but not quite as simple as the perl code. No, because strings are manipulated as arrays instead of simple types. Instead of simply returning a string, find_token returns indices into a character array. Handling strings as array slices is extremely awkward. It's hard to write, and hard to read. And it's error-prone. Ada will protect you from buffer overruns, but it can't protect you from off-by-one errors that misplace a character. String handling in Ada is only a slight improvement over C's strcpy/strcat mess. > > * has more overhead because of increased type checking. > > > In the Ada case, putting almost everything in one big huge, ugly, > function doesn't help readability (maybe this is a bit extreme, but > one of my university lecturers insisted that no > function/procedure/subroutine/whatever-you-call-it should be longer > then a page). He's right, and I think even a page is much too long. I generally try to keep mine at about ten lines or less. When they get bigger than that, I split them into smaller routines. Do this and you will generally find that the total line count will decrease, because those small functions get reused more than you might intially expect. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 21:24 ` Simon Wright 2004-09-23 0:03 ` Brian May @ 2004-09-23 0:44 ` Jeffrey Carter 2004-09-23 11:08 ` Georg Bauhaus 2004-09-23 8:15 ` Martin Krischik 2 siblings, 1 reply; 229+ messages in thread From: Jeffrey Carter @ 2004-09-23 0:44 UTC (permalink / raw) Simon Wright wrote: > > And there's the Ada line counter (which includes semicolons in > comments and strings but is still useful): > > $ tr -cd ';' <bcwords.ada | wc -c I always used grep \; <file> | wc -l IIRC -- Jeff Carter "People called Romanes, they go the house?" Monty Python's Life of Brian 79 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 0:44 ` Jeffrey Carter @ 2004-09-23 11:08 ` Georg Bauhaus 0 siblings, 0 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-23 11:08 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote: :> :> $ tr -cd ';' <bcwords.ada | wc -c : : I always used : : grep \; <file> | wc -l I use grep -c \; <file> -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 21:24 ` Simon Wright 2004-09-23 0:03 ` Brian May 2004-09-23 0:44 ` Jeffrey Carter @ 2004-09-23 8:15 ` Martin Krischik 2004-09-23 16:20 ` Matthew Heaney 2 siblings, 1 reply; 229+ messages in thread From: Martin Krischik @ 2004-09-23 8:15 UTC (permalink / raw) Simon Wright wrote: > James Alan Farrell <anonymous@anonymous.com> writes: > $ tr -cd ';' <bcwords.ada | wc -c > > (by the way, that shows that the Booch Components version of the word > counter comes in at 123 lines). Which shows that the "1 instantiation only" argument of Charles and Ada.Containers is misguided. So think I stick with the Booch Components even after Ada 2005. When we at it: I still have the "indefinite extension" within AdaCL. Howabout joining them? With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 8:15 ` Martin Krischik @ 2004-09-23 16:20 ` Matthew Heaney 2004-09-23 19:23 ` Simon Wright 2004-09-24 7:19 ` Martin Krischik 0 siblings, 2 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-23 16:20 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1777528.JKnUEYTOM6@linux1.krischik.com>... > > Which shows that the "1 instantiation only" argument of Charles and > Ada.Containers is misguided. So think I stick with the Booch Components > even after Ada 2005. I haven't seen Simon's wordcount code in a while (probably not since Simon and I met in Vienna), but I suspect we're comparing apples and oranges here. Simon probably used the BC set, which stores each element with a count. In Charles and AI-302, the container model is a little different, and you would use a map instead, with the word as the map key and the frequency count as the map element. So it would not surprise me if the wordcount problem has slightly fewer lines of code using the BC set than using the AI-302 map, since in the former case you're using what is essentially a special purpose container. Someone needs to make a feature-by-feature comparison of Simon's BC solution and the AI-302 solution I just posted. (I don't have time right now since I'm too busy incorporating the Madison changes.) Note that the example I posted does a lot of extra stuff to illustrate API features, extra stuff that isn't strictly necessary to solve the wordcount problem. If the unnecessary stuff were removed, then the comparison between BC and AI-302 solutions would be more realistic. > When we at it: I still have the "indefinite extension" within AdaCL. > Howabout joining them? All the containers in AI-302 have variants that support indefinite keys and indefinite elements. (All of the containers are now publicly taggged, too.) If AI-302 doesn't meet your needs, then you need to let us know. Please peruse the a-c*.ad[sb] sources at the tigris website. (Note that I'm still incorporating changes from the most recent ARG meeting.) -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 16:20 ` Matthew Heaney @ 2004-09-23 19:23 ` Simon Wright 2004-09-24 7:19 ` Martin Krischik 1 sibling, 0 replies; 229+ messages in thread From: Simon Wright @ 2004-09-23 19:23 UTC (permalink / raw) mheaney@on2.com (Matthew Heaney) writes: > Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1777528.JKnUEYTOM6@linux1.krischik.com>... > > > > Which shows that the "1 instantiation only" argument of Charles and > > Ada.Containers is misguided. So think I stick with the Booch Components > > even after Ada 2005. > > I haven't seen Simon's wordcount code in a while (probably not since > Simon and I met in Vienna), but I suspect we're comparing apples and > oranges here. > > Simon probably used the BC set, which stores each element with a > count. In Charles and AI-302, the container model is a little > different, and you would use a map instead, with the word as the map > key and the frequency count as the map element. Bag, actually; designed precisely for counting things (that compare "="). Not (IME) a solution to any problems I actually have in real life! If you didn't have Bags, the Map scheme is just as good (and is how the BC bag is implemented under the hood). > So it would not surprise me if the wordcount problem has slightly > fewer lines of code using the BC set than using the AI-302 map, since > in the former case you're using what is essentially a special purpose > container. > > Someone needs to make a feature-by-feature comparison of Simon's BC > solution and the AI-302 solution I just posted. Only if they really care! -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 16:20 ` Matthew Heaney 2004-09-23 19:23 ` Simon Wright @ 2004-09-24 7:19 ` Martin Krischik 2004-09-24 16:31 ` Matthew Heaney 2004-09-24 19:24 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Martin Krischik @ 2004-09-24 7:19 UTC (permalink / raw) Matthew Heaney wrote: > If AI-302 doesn't meet your needs, then you need to let us know. > Please peruse the a-c*.ad[sb] sources at the tigris website.ᅵᅵ(Note > that I'm still incorporating changes from the most recent ARG > meeting.) I have got my most important baby (indefinite types). And I don't want to confuse the ARG. I fully agree that we need a container library inside the standart. However it would be sad if Ada.Containers would kill off all other container libraries. Just like the STL did. Im am sill looking at IBM OCL thinking how much more practical it was. std::string might me academicly correct but IString was a lot more usefull in day to day live with all the asInt (), asUnsigned (), asAnythingYouEverNeed() methods. Somtimes I am toying with the idea of recreating IString - in Ada with exports for C and C++ so I have handy in any language I use. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 7:19 ` Martin Krischik @ 2004-09-24 16:31 ` Matthew Heaney 2004-09-24 19:24 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 16:31 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:3673998.bj16mkkOu2@linux1.krischik.com... > > I have got my most important baby (indefinite types). And I don't want to > confuse the ARG. I fully agree that we need a container library inside the > standard. Well, we might be slow but we don't confuse that easily. 8^) Seriously, if you have a comment on the API, it would be helpful to let us know. We have added most of the features people have asked for. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 7:19 ` Martin Krischik 2004-09-24 16:31 ` Matthew Heaney @ 2004-09-24 19:24 ` Kevin Cline 2004-09-25 14:04 ` Martin Krischik 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-24 19:24 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<3673998.bj16mkkOu2@linux1.krischik.com>... > Matthew Heaney wrote: > > > If AI-302 doesn't meet your needs, then you need to let us know. > > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note > > that I'm still incorporating changes from the most recent ARG > > meeting.) > > I have got my most important baby (indefinite types). And I don't want to > confuse the ARG. I fully agree that we need a container library inside the > standart. > > However it would be sad if Ada.Containers would kill off all other container > libraries. Just like the STL did. I think the STL killed off all the other container libraries because the STL container/algorithm separation is an extremely powerful design that dominates all older container library designs. Certainly STL programming is much cleaner and easeir than programming with the once popular RogueWave containers. The STL also has the advantage that it is relatively easy to write new containers that will work with the STL algorithms, so that even though new containers are written, they all look like STL containers. > Im am sill looking at IBM OCL thinking > how much more practical it was. std::string might me academicly correct but > IString was a lot more usefull in day to day live with all the asInt (), > asUnsigned (), asAnythingYouEverNeed() methods. The problem with that design is that it isn't readily extensible to accomodate user-defined types, and it makes generic programming very difficult. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 19:24 ` Kevin Cline @ 2004-09-25 14:04 ` Martin Krischik 2004-09-26 10:36 ` Robert Kawulak 2004-09-27 22:22 ` Kevin Cline 0 siblings, 2 replies; 229+ messages in thread From: Martin Krischik @ 2004-09-25 14:04 UTC (permalink / raw) Kevin Cline wrote: > Martin Krischik <krischik@users.sourceforge.net> wrote in message > news:<3673998.bj16mkkOu2@linux1.krischik.com>... >> Matthew Heaney wrote: >> >> > If AI-302 doesn't meet your needs, then you need to let us know. >> > Please peruse the a-c*.ad[sb] sources at the tigris website.ᅵᅵ(Note >> > that I'm still incorporating changes from the most recent ARG >> > meeting.) >> >> I have got my most important baby (indefinite types). And I don't want to >> confuse the ARG. I fully agree that we need a container library inside >> the standart. >> >> However it would be sad if Ada.Containers would kill off all other >> container libraries. Just like the STL did. > > I think the STL killed off all the other container libraries because > the STL container/algorithm separation is an extremely powerful design > that dominates all older container library designs. Certainly STL > programming is much cleaner and easeir than programming with the once > popular RogueWave containers. The STL also has the advantage that it > is relatively easy to write new containers that will work with the STL > algorithms, so that even though new containers are written, they all > look like STL containers. No Library is perfect, but the "I which I had" list for the STL is much larger then for container out of IBM's OCL. The OCL was not designed for academic correctness bit but for usability. >> Im am sill looking at IBM OCL thinking >> how much more practical it was. std::string might me academicly correct >> but IString was a lot more usefull in day to day live with all the asInt >> (), asUnsigned (), asAnythingYouEverNeed() methods. > > The problem with that design is that it isn't readily extensible to > accomodate user-defined types, and it makes generic programming very > difficult. In 99.99% of all cases I don't need strings on user defined types. I need base_string<char>. I can see that I one day might need base_string<wchar_t>, but I have not until now. They made all that funky design which I just never need. And for that: int string::asInt(); throw (bad_value); and explicit string::string (int value) throw(); are missing. Two functions I am missing on daily basis. Sure, I am an experienced programmer, I can do that myself - but a proper library should have all the function one need on a daily basis. And they could have had both: class string: public: base_string<char> { public: int string::asInt() throw (bad_value); explicit string (int value) throw(); } Would have been so easy, so usefull but it would not have been a template. The "all is template" religion got in there way. And just for the record: atio is a C function - you need the overhead of convertion the std::string into a char* and std::strstream seem quite heavy weight for just a simple task of convertion a string from and to an int. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-25 14:04 ` Martin Krischik @ 2004-09-26 10:36 ` Robert Kawulak 2004-09-26 15:35 ` Martin Krischik 2004-09-27 22:22 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-26 10:36 UTC (permalink / raw) Hi! (Sorry for mixing quotations of your post, it was easier for me to respond this way). > In 99.99% of all cases I don't need strings on user defined types. I need > base_string<char>. I can see that I one day might need > base_string<wchar_t>, but I have not until now. They made all that funky > design which I just never need. And the best thing is that if you don't need it, you don't have to use it. Yet still there is this 0.01% of cases when this approach is extremely useful because of its flexibility. E.g. when you want a class of case-insensitive strings - you just reuse the basic string template like this: //class defining character traits class my_char_traits: public std::char_traits<char> { //here you just redefine simple comparison //functions like eq() to be case-insensitive }; //case-insensitive string class typedef std::basic_string<char, my_char_traits> cis_string; > Would have been so easy, so usefull but it would not have been a template. > The "all is template" religion got in there way. Actually you might not even know that std::string is a typedef of template instantiation and still use it as if nothing had happened. And compare this example to creating completely new string class just because you want this small difference in behaviour - and you have an explanation for making everything a template. :-) Similar results could be achieved using polymorphysm, but the "template religion" has got one great advantage - all the binding is done during compilation, and moreover many functions are inlined (!) - this allows a performance during runtime other approaches couldn't have... > And for that: > > int > string::asInt(); > throw (bad_value); > > and > > explicit > string::string (int value) > throw(); > > are missing. Two functions I am missing on daily basis. Sure, I am an > experienced programmer, I can do that myself - but a proper library should > have all the function one need on a daily basis. std::string doesn't have int conversion functions, because it's not its job to do this. Maybe you don't see the whole idea of the design of C++ standard library. It's goal is to divide responsibility for diffrent features between separate parts of library - that's where it's flexibility and extensibility comes from. > And just for the record: atio is a C function - you need the overhead of > convertion the std::string into a char* and std::strstream seem quite > heavy > weight for just a simple task of convertion a string from and to an int. Actually, the overhead of conversion is virtually none (at least in Stlport implementation). You just call std::string::c_str() which just returns a pointer to the data, and which is also inlined. If you need string-to-int conversion and vice-versa, then it's the job of std::stringstream (std::strstream is obsolete...) - there's a very easy way to do this: /********************************************/ #include <string> using std::string; #include <sstream> typedef std::ostringstream oss; typedef std::istringstream iss; int i = 4; string MyString("2"); //step-by-step: void f() { //instead of std::string::fromInt(int) oss MyOutputStream; MyOutputStream << i; MyString = MyOutputStream.str(); //instead of std::string::toInt() iss MyInputStream; MyInputStream.str(MyString); MyInputStream >> i; } //f() //same things as one-liners: void g() { MyString = static_cast<oss &>(oss() << i).str(); iss(MyString) >> i; } //g() //you may also define two simple functions to do this for you: inline string ToString(int i) { return static_cast<oss &>(oss() << i).str(); } //ToString() inline int ToInt(const string & s) { int i; iss(s) >> i; return i; } //ToInt() void h() { //couldn't be simplier ;-) MyString = ToString(i); i = ToInt(MyString); } //h() /********************************************/ Most compilers will optimise away the initialisations etc., so in this case you don't have to worry about the overhead. But if you really can't live without this ability in the string class, then nothing stands on a way to extend std::string with these two functions using inheritance (note, however, that you will also have to re-implement constructors you want to use. Constructor inheritance is not a part of standard C++ yet). C++ is not that evil, you just have to switch your mind to a different way of thinking to understand it well... ;-) It *is* difficult, but once you feel it, it gives you a lot of abilities. Please don't understand me wrong - I don't claim I'm some kind of C++ guru, and the following is just my general opinion, not an answer for your particular post. Why I think many people think of C++ as so dangerous and letting you easily shoot your foot is that unfortunately not many people know it as well as they should to use it properly. I mean C++ is not a "toy language" - if you want something easy, use Java. But be prepared for many limitations and restrictions (which are there for your own good, but if you exactly know what you are doing, they are inconvenient). I also don't say C++ is better than Ada - it depends on how a programmer is familiar with those languages and how effectively can write good, safe programs using them. Of course C++ forces to learn more to write such programs, but in turn provides you with much more flexibility and usefulness. Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 10:36 ` Robert Kawulak @ 2004-09-26 15:35 ` Martin Krischik 2004-09-28 17:46 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Martin Krischik @ 2004-09-26 15:35 UTC (permalink / raw) Hi, Robert Kawulak wrote: > >> In 99.99% of all cases I don't need strings on user defined types. I need >> base_string<char>. I can see that I one day might need >> base_string<wchar_t>, but I have not until now. They made all that funky >> design which I just never need. > > And the best thing is that if you don't need it, you don't have to use > it. Yet still there is this 0.01% of cases when this approach is extremely > useful because of its flexibility. E.g. when you want a class of > case-insensitive strings - you just reuse the basic string template like > this: > //class defining character traits > class my_char_traits: public std::char_traits<char> > { > //here you just redefine simple comparison > //functions like eq() to be case-insensitive > }; > > //case-insensitive string class > typedef std::basic_string<char, my_char_traits> cis_string; > >> Would have been so easy, so usefull but it would not have been a >> template. The "all is template" religion got in there way. > > Actually you might not even know that std::string is a typedef of > template instantiation and still use it as if nothing had happened. I know that. And I was wondering why. >> And just for the record: atio is a C function - you need the overhead of >> convertion the std::string into a char* and std::strstream seem quite >> heavy >> weight for just a simple task of convertion a string from and to an int. > > Actually, the overhead of conversion is virtually none (at least in > Stlport implementation). You just call std::string::c_str() which just > returns a pointer to the data, and which is also inlined. From what I read about std::string strings do not need to be '\0' terminated and std::string::c_str() will add a terminator if needed. Thats unlike std::string::data() which does not add a '\0'. Well on the other side std::string::c_str() is const. This all leaves me wonder how actually works. And if I ever need to work again if I had a Euro for every call where std::string::data() and std::string::c_str() have been mixed up. > If you need string-to-int conversion and vice-versa, then it's the job > of std::stringstream (std::strstream is obsolete...) - there's a very easy > way to do this: Interesting. I did not know that. Well tomorrow I look if Microsoft does know as well. > /********************************************/ > > #include <string> > using std::string; > > #include <sstream> > typedef std::ostringstream oss; > typedef std::istringstream iss; > > int i = 4; > string MyString("2"); > > > > //step-by-step: > > void f() { > > //instead of std::string::fromInt(int) > oss MyOutputStream; > MyOutputStream << i; > MyString = MyOutputStream.str(); > > //instead of std::string::toInt() > iss MyInputStream; > MyInputStream.str(MyString); > MyInputStream >> i; > > } //f() Well, nice. But are you shure you don't leak memory here. I remember there was something about ownership and the str() function. > //same things as one-liners: Please DON'T. This is comp.lang.ada after all. Three liners are quite OK. > C++ is not that evil, you just have to switch your mind to a different > way of thinking to understand it well... ;-) It *is* difficult, but once > you feel it, it gives you a lot of abilities. Please don't understand me > wrong - I don't claim I'm some kind of C++ guru, and the following is just > my general opinion, not an answer for your particular post. Why I think > many people think of C++ as so dangerous and letting you easily shoot your > foot is that unfortunately not many people know it as well as they should > to use it properly. Well I use C++ for 15 years now. And now I am here at c.l.a. Don't you think there is a reason for that? I think I never ever get use to the fact that the following one liner is not an error - and usually only reported at highest warning level. static unsigned Wrong = -1; Not only that you can shoot yourself in the foot with C++ (You can do that with Ada as well) but the weapon is allways loaded (that is, cannot be unloaded), has no safety lever, and the trigger is allwas taut. And of corse it is a snipers hair trigger going off at the slightest touch. So no matter how experienced you are, you are allways in danger of shooting your food of. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 15:35 ` Martin Krischik @ 2004-09-28 17:46 ` Robert Kawulak 2004-09-29 7:49 ` Martin Krischik 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-28 17:46 UTC (permalink / raw) Hi, >>> And just for the record: atio is a C function - you need the overhead of >>> convertion the std::string into a char* and std::strstream seem quite >>> heavy >>> weight for just a simple task of convertion a string from and to an int. >> >> Actually, the overhead of conversion is virtually none (at least in >> Stlport implementation). You just call std::string::c_str() which just >> returns a pointer to the data, and which is also inlined. > > From what I read about std::string strings do not need to be '\0' > terminated > and std::string::c_str() will add a terminator if needed. Thats unlike > std::string::data() which does not add a '\0'. Yup, you're absolutely right. But Stlport implementation always stores '\0' at the end, so std::string::c_str() boils down to returning a pointer. On the other hand, the GCC implementation writes terminating '\0' every time this function is called. However, this is still constant complexity and a little overhead contrary to what many people suspect - that converting std::string to char * requires copying whole the contents of the string to some temporary buffer. > Well on the other side > std::string::c_str() is const. c_str() may modify the data even despite being const if the data is declared with mutable specifier. And that's how it's done in GCC. > This all leaves me wonder how actually works. And if I ever need to work > again if I had a Euro for every call where std::string::data() and > std::string::c_str() have been mixed up. At the beginning I was also confusing the two. But since I've read the documentation carefully, I always remember the difference... ;-) >> void f() { >> >> //instead of std::string::fromInt(int) >> oss MyOutputStream; >> MyOutputStream << i; >> MyString = MyOutputStream.str(); >> >> //instead of std::string::toInt() >> iss MyInputStream; >> MyInputStream.str(MyString); >> MyInputStream >> i; >> >> } //f() > > Well, nice. But are you shure you don't leak memory here. I remember there > was something about ownership and the str() function. I don't know which place exactly you mean, but I'm pretty sure it all works as supossed. Strings, streams and all other objects of std library classes take care for their storage themselves - a user doesn't have to worry about this. Coud you be more specific? >> //same things as one-liners: > > Please DON'T. This is comp.lang.ada after all. Three liners are quite OK. OK, I promise this won't happen anymore! ;-) > Not only that you can shoot yourself in the foot with C++ (You can do that > with Ada as well) but the weapon is allways loaded (that is, cannot be > unloaded), has no safety lever, and the trigger is allwas taut. And of > corse it is a snipers hair trigger going off at the slightest touch. > > So no matter how experienced you are, you are allways in danger of > shooting > your food of. I can't agree with that at all. In C++ there is almost always an alternative. You may use std::vector<> instead of arrays, std::auto_ptr<> instead of naked pointers etc. But still you have a choice - if you really need to have a total low-level control on your program, you may have it. Otherwise use higher abstraction-level utilities. What you say might be eventually true for C, but not for C++. And the difference between the two is enormous, unfortunately many people think C and C++ is the same... Best regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 17:46 ` Robert Kawulak @ 2004-09-29 7:49 ` Martin Krischik 2004-09-29 12:01 ` Xenos 2004-09-29 18:16 ` Robert Kawulak 0 siblings, 2 replies; 229+ messages in thread From: Martin Krischik @ 2004-09-29 7:49 UTC (permalink / raw) Robert Kawulak wrote: > Hi, > >>>> And just for the record: atio is a C function - you need the overhead >>>> of convertion the std::strivalidto a char* and std::strstream seem >>>> quite heavy >>>> weight for just a simple task of convertion a string from and to an >>>> int. >>> >>> Actually, the overhead of conversion is virtually none (at least in >>> Stlport implementation). You just call std::string::c_str() which just >>> returns a pointer to the data, and which is also inlined. >> >> From what I read about std::string strings do not need to be '\0' >> terminated >> and std::string::c_str() will add a terminator if needed. Thats unlike >> std::string::data() which does not add a '\0'. > > Yup, you're absolutely right. But Stlport implementation always stores > '\0' at the end, so std::string::c_str() boils down to returning a > pointer. On the other hand, the GCC implementation writes terminating '\0' > every time this function is called. However, this is still constant > complexity and a little overhead contrary to what many people suspect - > that converting std::string to char * requires copying whole the contents > of the string to some temporary buffer. But that means that the strings need "capacity () - size () >= 1" so that there is allways one spare byte for the '\0'. >> Well on the other side >> std::string::c_str() is const. > > c_str() may modify the data even despite being const if the data is > declared with mutable specifier. And that's how it's done in GCC. I was thinking about "capacity () - size () == 0" - then c_str() would need to resize. Doesn't happen in your implementation - but is this valid for all. >> This all leaves me wonder how actually works. And if I ever need to work >> again if I had a Euro for every call where std::string::data() and >> std::string::c_str() have been mixed up. > At the beginning I was also confusing the two. But since I've read the > documentation carefully, I always remember the difference... ;-) >>> void f() { >>> >>> //instead of std::string::fromInt(int) >>> oss MyOutputStream; >>> MyOutputStream << i; >>> MyString = MyOutputStream.str(); >>> >>> //instead of std::string::toInt() >>> iss MyInputStream; >>> MyInputStream.str(MyString); >>> MyInputStream >> i; >>> >>> } //f() >> >> Well, nice. But are you shure you don't leak memory here. I remember >> there was something about ownership and the str() function. > I don't know which place exactly you mean, but I'm pretty sure it all > works as supossed. Strings, streams and all other objects of std library > classes take care for their storage themselves - a user doesn't have to > worry about this. Coud you be more specific? I might me mistaken with the old strstream. >>> //same things as one-liners: >> >> Please DON'T. This is comp.lang.ada after all. Three liners are quite OK. > OK, I promise this won't happen anymore! ;-) >> Not only that you can shoot yourself in the foot with C++ (You can do >> that with Ada as well) but the weapon is allways loaded (that is, cannot >> be unloaded), has no safety lever, and the trigger is allwas taut. And of >> corse it is a snipers hair trigger going off at the slightest touch. >> >> So no matter how experienced you are, you are allways in danger of >> shooting >> your food of. > I can't agree with that at all. In C++ there is almost always an > alternative. You may use std::vector<> instead of arrays, std::auto_ptr<> > instead of naked pointers etc. But still you have a choice - if you really > need to have a total low-level control on your program, you may have it. > Otherwise use higher abstraction-level utilities. What you say might be > eventually true for C, but not for C++. And the difference between the two > is enormous, unfortunately many people think C and C++ is the same... Not quite true. I did have to make Ada::Range<class type, type First, type Last> myself. Actually, I still have to make it. My Current implementation is for the old standart (as in Ada::IntegerRange<int First, int Last>). C++ has protection against buffer overruns - but the new JPEC Viruses work integer overurns. And there is no: typedef explicit int My_Int. And that means that typedef Ada :: Range <int, 1, 12> US_Hours; typedef Ada :: Range <int, 1, 12> Month; are the same for C++. But there are not in real live. And if I use: class US_Hours Ada :: Range <int, 1, 12> {}; class Month Ada :: Range <int, 1, 12> {}; I loose the constructors. So there is still something to be improved. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 7:49 ` Martin Krischik @ 2004-09-29 12:01 ` Xenos 2004-09-29 18:16 ` Robert Kawulak 1 sibling, 0 replies; 229+ messages in thread From: Xenos @ 2004-09-29 12:01 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:3060085.UHp9MgIIe7@linux1.krischik.com... > typedef explicit int My_Int. > > And that means that > > typedef Ada :: Range <int, 1, 12> US_Hours; > typedef Ada :: Range <int, 1, 12> Month; This problem can be overcome by adding a "unique class" to your template if you want them to be distinuished: class default_class {}; template Range<class T, T lo, T hi, class U = default_class> class Range; Now if you need the range to be a new type: class hours_range {}; class month_range; typedef Range<int, 1, 12, hours_range> Hours; typedef Range<int, 1, 12, month_range> Month; They are now unique classes. > > are the same for C++. But there are not in real live. And if I use: > > class US_Hours Ada :: Range <int, 1, 12> {}; > class Month Ada :: Range <int, 1, 12> {}; > > I loose the constructors. So there is still something to be improved. Not true! You cannot use initializer lists if the class has a constructor. This is where Ada and C++ differ. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 7:49 ` Martin Krischik 2004-09-29 12:01 ` Xenos @ 2004-09-29 18:16 ` Robert Kawulak 2004-09-30 15:55 ` Martin Krischik 1 sibling, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-29 18:16 UTC (permalink / raw) Hi all, >> Yup, you're absolutely right. But Stlport implementation always stores >> '\0' at the end, so std::string::c_str() boils down to returning a >> pointer. On the other hand, the GCC implementation writes terminating >> '\0' >> every time this function is called. However, this is still constant >> complexity and a little overhead contrary to what many people suspect - >> that converting std::string to char * requires copying whole the contents >> of the string to some temporary buffer. > > But that means that the strings need "capacity () - size () >= 1" so that > there is allways one spare byte for the '\0'. Well, in those particular implementations yes, but AFAIK it's not imposed by the standard. > I was thinking about "capacity () - size () == 0" - then c_str() would > need > to resize. Doesn't happen in your implementation - but is this valid for > all. As said above, it's not. An implementation can choose freely, but I suspect that vast majority use "capacity () - size () >= 1" due to efficiency - after all this one extra byte doesn't cost a lot compared to creating new buffer for whole the string and copying it in case of a call to c_str(). >> I can't agree with that at all. In C++ there is almost always an >> alternative. You may use std::vector<> instead of arrays, std::auto_ptr<> >> instead of naked pointers etc. But still you have a choice - if you >> really >> need to have a total low-level control on your program, you may have it. >> Otherwise use higher abstraction-level utilities. What you say might be >> eventually true for C, but not for C++. And the difference between the >> two >> is enormous, unfortunately many people think C and C++ is the same... > > Not quite true. I did have to make Ada::Range<class type, type First, type > Last> myself. Actually, I still have to make it. My Current implementation > is for the old standart (as in Ada::IntegerRange<int First, int Last>). > C++ > has protection against buffer overruns - but the new JPEC Viruses work > integer overurns. That one is indeed missing in the standard (that's why I've used 'almost' above ;-) and you have to make it on your own (fortunately it's a trivial task, and you do it only once and then reuse). > And there is no: > > typedef explicit int My_Int. > > And that means that > > typedef Ada :: Range <int, 1, 12> US_Hours; > typedef Ada :: Range <int, 1, 12> Month; > > are the same for C++. But there are not in real live. And if I use: > > class US_Hours Ada :: Range <int, 1, 12> {}; > class Month Ada :: Range <int, 1, 12> {}; > > I loose the constructors. So there is still something to be improved. That's all very true what you say and it IS going to be improved - there are already papers submitted to the C++ standarisation commettee concerning strongly-typed typedefs. Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 18:16 ` Robert Kawulak @ 2004-09-30 15:55 ` Martin Krischik 0 siblings, 0 replies; 229+ messages in thread From: Martin Krischik @ 2004-09-30 15:55 UTC (permalink / raw) Robert Kawulak wrote: >> But that means that the strings need "capacity () - size () >= 1" so that >> there is allways one spare byte for the '\0'. > > Well, in those particular implementations yes, but AFAIK it's not imposed > by the standard. > >> I was thinking about "capacity () - size () == 0" - then c_str() would >> need >> to resize. Doesn't happen in your implementation - but is this valid for >> all. > > As said above, it's not. An implementation can choose freely, but I > suspect that vast majority use "capacity () - size () >= 1" due to > efficiency - after all this one extra byte doesn't cost a lot compared to > creating new buffer for whole the string and copying it in case of a call > to c_str(). Well, since all book I have read state that the pointer is valid until a "non const method" is called there are only two possible implementations left: The "capacity () - size () >= 1" and the "spare buffer/pointer" solution which would keep spearate buffers and/or pointers for different representations. But maybe there are exotic solutions as well. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-25 14:04 ` Martin Krischik 2004-09-26 10:36 ` Robert Kawulak @ 2004-09-27 22:22 ` Kevin Cline 2004-09-28 7:51 ` Martin Krischik 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-27 22:22 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1700922.2nPlMsa4Ny@linux1.krischik.com>... > Kevin Cline wrote: > > > Martin Krischik <krischik@users.sourceforge.net> wrote in message > > news:<3673998.bj16mkkOu2@linux1.krischik.com>... > >> Matthew Heaney wrote: > >> > >> > If AI-302 doesn't meet your needs, then you need to let us know. > >> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note > >> > that I'm still incorporating changes from the most recent ARG > >> > meeting.) > >> > >> I have got my most important baby (indefinite types). And I don't want to > >> confuse the ARG. I fully agree that we need a container library inside > >> the standart. > >> > >> However it would be sad if Ada.Containers would kill off all other > >> container libraries. Just like the STL did. > > > > I think the STL killed off all the other container libraries because > > the STL container/algorithm separation is an extremely powerful design > > that dominates all older container library designs. Certainly STL > > programming is much cleaner and easeir than programming with the once > > popular RogueWave containers. The STL also has the advantage that it > > is relatively easy to write new containers that will work with the STL > > algorithms, so that even though new containers are written, they all > > look like STL containers. > > No Library is perfect, but the "I which I had" list for the STL is much > larger then for container out of IBM's OCL. The OCL was not designed for > academic correctness bit but for usability. > > >> Im am sill looking at IBM OCL thinking > >> how much more practical it was. std::string might me academicly correct > >> but IString was a lot more usefull in day to day live with all the asInt > >> (), asUnsigned (), asAnythingYouEverNeed() methods. > > > > The problem with that design is that it isn't readily extensible to > > accomodate user-defined types, and it makes generic programming very > > difficult. > > In 99.99% of all cases I don't need strings on user defined types. I need > base_string<char>. I can see that I one day might need > base_string<wchar_t>, but I have not until now. They made all that funky > design which I just never need. That wasn't the sort of extensibility I was thinking of. I was referring to the inextensibility of the series of member functions asInt(), asUnsigned(), etc. Collections of functions with names varying according to the return type inhibit template programming. If you want to be able to conveniently extract values from a string, you can write this template function: template <class T> T parse(std::string s) { T result; stringstream strm(s); strm >> result; if (!strm) throw( /* something */ ); return result; } and then you can write: std::string s("10"); int i = parse<int>(s); I agree that this is not as obvious as it should be. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 22:22 ` Kevin Cline @ 2004-09-28 7:51 ` Martin Krischik 2004-09-29 3:04 ` Kevin Cline 0 siblings, 1 reply; 229+ messages in thread From: Martin Krischik @ 2004-09-28 7:51 UTC (permalink / raw) Kevin Cline wrote: > Martin Krischik <krischik@users.sourceforge.net> wrote in message > news:<1700922.2nPlMsa4Ny@linux1.krischik.com>... >> Kevin Cline wrote: >> >> > Martin Krischik <krischik@users.sourceforge.net> wrote in message >> > news:<3673998.bj16mkkOu2@linux1.krischik.com>... >> >> Matthew Heaney wrote: >> >> >> >> > If AI-302 doesn't meet your needs, then you need to let us know. >> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.ᅵᅵ(Note >> >> > that I'm still incorporating changes from the most recent ARG >> >> > meeting.) >> >> >> >> I have got my most important baby (indefinite types). And I don't want >> >> to confuse the ARG. I fully agree that we need a container library >> >> inside the standart. >> >> >> >> However it would be sad if Ada.Containers would kill off all other >> >> container libraries. Just like the STL did. >> > >> > I think the STL killed off all the other container libraries because >> > the STL container/algorithm separation is an extremely powerful design >> > that dominates all older container library designs. Certainly STL >> > programming is much cleaner and easeir than programming with the once >> > popular RogueWave containers. The STL also has the advantage that it >> > is relatively easy to write new containers that will work with the STL >> > algorithms, so that even though new containers are written, they all >> > look like STL containers. >> >> No Library is perfect, but the "I which I had" list for the STL is much >> larger then for container out of IBM's OCL. The OCL was not designed for >> academic correctness bit but for usability. >> >> >> Im am sill looking at IBM OCL thinking >> >> how much more practical it was. std::string might me academicly >> >> correct but IString was a lot more usefull in day to day live with all >> >> the asInt (), asUnsigned (), asAnythingYouEverNeed() methods. >> > >> > The problem with that design is that it isn't readily extensible to >> > accomodate user-defined types, and it makes generic programming very >> > difficult. >> >> In 99.99% of all cases I don't need strings on user defined types. I need >> base_string<char>. I can see that I one day might need >> base_string<wchar_t>, but I have not until now. They made all that funky >> design which I just never need. > > That wasn't the sort of extensibility I was thinking of. I was > referring to > the inextensibility of the series of member functions asInt(), > asUnsigned(), etc. Collections of functions with names varying > according to the return type inhibit template programming. If you > want to be able to conveniently extract values from a string, you can > write this template function: > > template <class T> T parse(std::string s) thow (something) > { > T result; > stringstream strm(s); > strm >> result; > if (!strm) throw( /* something */ ); > return result; > } > > and then you can write: > std::string s("10"); > int i = parse<int>(s); This is indeed cool. And it tells me that my code is missing a throw. I wonder how many programmers still use C's itoa for the job. And of those who do use stringstream how many forgot to check the result. > I agree that this is not as obvious as it should be. It should be part of the standart. The algorithm section contains all sorts of search, sort, stack and whatever else algorithm - but no string parsers. Stack algorithms are < 10 lines as well. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 7:51 ` Martin Krischik @ 2004-09-29 3:04 ` Kevin Cline 2004-09-29 6:03 ` Dale Stanbrough ` (2 more replies) 0 siblings, 3 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-29 3:04 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1636756.M7hCqjsVMv@linux1.krischik.com>... > Kevin Cline wrote: > > > Martin Krischik <krischik@users.sourceforge.net> wrote in message > > news:<1700922.2nPlMsa4Ny@linux1.krischik.com>... > >> Kevin Cline wrote: > >> > >> > Martin Krischik <krischik@users.sourceforge.net> wrote in message > >> > news:<3673998.bj16mkkOu2@linux1.krischik.com>... > >> >> Matthew Heaney wrote: > >> >> > >> >> > If AI-302 doesn't meet your needs, then you need to let us know. > >> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note > >> >> > that I'm still incorporating changes from the most recent ARG > >> >> > meeting.) > >> >> > >> >> I have got my most important baby (indefinite types). And I don't want > >> >> to confuse the ARG. I fully agree that we need a container library > >> >> inside the standart. > >> >> > >> >> However it would be sad if Ada.Containers would kill off all other > >> >> container libraries. Just like the STL did. > >> > > >> > I think the STL killed off all the other container libraries because > >> > the STL container/algorithm separation is an extremely powerful design > >> > that dominates all older container library designs. Certainly STL > >> > programming is much cleaner and easeir than programming with the once > >> > popular RogueWave containers. The STL also has the advantage that it > >> > is relatively easy to write new containers that will work with the STL > >> > algorithms, so that even though new containers are written, they all > >> > look like STL containers. > >> > >> No Library is perfect, but the "I which I had" list for the STL is much > >> larger then for container out of IBM's OCL. The OCL was not designed for > >> academic correctness bit but for usability. > >> > >> >> Im am sill looking at IBM OCL thinking > >> >> how much more practical it was. std::string might me academicly > >> >> correct but IString was a lot more usefull in day to day live with all > >> >> the asInt (), asUnsigned (), asAnythingYouEverNeed() methods. > >> > > >> > The problem with that design is that it isn't readily extensible to > >> > accomodate user-defined types, and it makes generic programming very > >> > difficult. > >> > >> In 99.99% of all cases I don't need strings on user defined types. I need > >> base_string<char>. I can see that I one day might need > >> base_string<wchar_t>, but I have not until now. They made all that funky > >> design which I just never need. > > > > That wasn't the sort of extensibility I was thinking of. I was > > referring to > > the inextensibility of the series of member functions asInt(), > > asUnsigned(), etc. Collections of functions with names varying > > according to the return type inhibit template programming. If you > > want to be able to conveniently extract values from a string, you can > > write this template function: > > > > template <class T> T parse(std::string s) > > thow (something) > > > { > > T result; > > stringstream strm(s); > > strm >> result; > > if (!strm) throw( /* something */ ); > > return result; > > } > > > > and then you can write: > > std::string s("10"); > > int i = parse<int>(s); > > This is indeed cool. And it tells me that my code is missing a throw. Yes, and if you define a new type, say MyType, then you just have to implement: istream& operator>>(istream& i, MyType& mt) { ...; return i; } and then you can write: MyType mt = parse<MyType>(s); Since the input and output for all types is handled identically, generic programming is easy. I once wrote a small set of template classes to map relational database columns to object fields, like this: struct Person { SocialSecurityNumber ssn; Date birthDate; std::string firstName; ... } DatabaseMap<Person> personMap; personMap .insert("PERSON", "SSN", &Person::ssn) .insert("PERSON", "DOB", &Person::dateOfBirth) .insert("PERSON", "FIRST", &Person::firstName) ...; personMap.Insert(someone); databaseCursor = // some query //; personMap.Read(databaseCursor, someone); someone.firstName = "Fred"; personMap.Update(someone); ... This would have been completely unwieldy in Ada for two reasons: 1. There would have been dozens of complex instantiations of insert. 2. AFAIK, Ada does not support pointer-to-record member so it would have been necessary to somehow wrap each record member with a function. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:04 ` Kevin Cline @ 2004-09-29 6:03 ` Dale Stanbrough 2004-09-29 13:31 ` Georg Bauhaus 2004-09-29 13:46 ` Matthew Heaney 2 siblings, 0 replies; 229+ messages in thread From: Dale Stanbrough @ 2004-09-29 6:03 UTC (permalink / raw) Kevin Cline wrote: > 2. AFAIK, Ada does not support pointer-to-record member so it would > have been necessary to somehow wrap each record member with a > function. You can take the address of a field in a record. I'm not sure what it means if you have a representation clause for the record though. If you do Gnat says... gcc -c fred.adb fred.adb:19:10: warning: taking address of object not aligned on storage unit so at least one compiler tells you there is danger. Presumably once you have the address, the pointer knows nothing about the special alignment of the object. What happens in the C world in similar circumstances? Dale The following compile with gnat v3.3... with system; use system; procedure Fred is type R is record a : integer; b : character; end record; A : System.Address; rec : R; begin A := rec.a'address; end; with system; use system; procedure Fred is type R is record a : integer; b : boolean; end record; for R use record A at 0 range 0..31; b at 4 range 3..3; end record; A : System.Address; rec : R; begin A := rec.b'address; end; -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:04 ` Kevin Cline 2004-09-29 6:03 ` Dale Stanbrough @ 2004-09-29 13:31 ` Georg Bauhaus 2004-09-29 13:46 ` Matthew Heaney 2 siblings, 0 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-29 13:31 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : 2. AFAIK, Ada does not support pointer-to-record member It does, but you have to tell your readers that a record component is aliased. (And you have to specify the kind of pointer you want, that is, read only, or update pointers.) -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:04 ` Kevin Cline 2004-09-29 6:03 ` Dale Stanbrough 2004-09-29 13:31 ` Georg Bauhaus @ 2004-09-29 13:46 ` Matthew Heaney 2004-09-30 3:42 ` Kevin Cline 2 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 13:46 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > 2. AFAIK, Ada does not support pointer-to-record member so it would > have been necessary to somehow wrap each record member with a > function. Declare the record component as aliased. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 13:46 ` Matthew Heaney @ 2004-09-30 3:42 ` Kevin Cline 2004-09-30 7:54 ` Dale Stanbrough ` (2 more replies) 0 siblings, 3 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-30 3:42 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<ufz51rs1l.fsf@earthlink.net>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > 2. AFAIK, Ada does not support pointer-to-record member so it would > > have been necessary to somehow wrap each record member with a > > function. > > Declare the record component as aliased. There seems to be some confusion between creating a pointer to a particular member of a particular record, and the C++ pointer to member type. In C++: struct X { int a; int b; }; X x1 = { 3, 5 }; X x2 = { 4, 6 }; int X::*ptm = &X::a; ASSERT(x1->*ptm == 3); ASSERT(x2->*ptm == 4); ptm = &X::b; ASSERT(x1->*ptm == 5); ASSERT(x2->*ptm == 6); The availability of pointers to members makes it possible to concisely express the mapping between the a data member and the "A" column of a database table. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 3:42 ` Kevin Cline @ 2004-09-30 7:54 ` Dale Stanbrough 2004-09-30 16:50 ` Matthew Heaney 2004-09-30 19:01 ` Björn Persson 2 siblings, 0 replies; 229+ messages in thread From: Dale Stanbrough @ 2004-09-30 7:54 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) wrote: > There seems to be some confusion between creating a pointer to a > particular member of a particular record, and the C++ pointer to > member type. Indeed. > ASSERT(x1->*ptm == 3); > ASSERT(x2->*ptm == 4); > > ptm = &X::b; > > ASSERT(x1->*ptm == 5); > ASSERT(x2->*ptm == 6); > > The availability of pointers to members makes it possible to concisely > express the mapping between the a data member and the "A" column of a > database table. Ada can't do this directly. You can get the starting bit position of a field, and could convert this into a byte/word offset and add it to a pointer. Using the attribute 'First_Bit you can find the number of bits offset into a record, but only for an object, not a type. This means that you couldn't easily create a generic to do this without creating an object first. Does anyone know why this was restricted to objects only? Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 3:42 ` Kevin Cline 2004-09-30 7:54 ` Dale Stanbrough @ 2004-09-30 16:50 ` Matthew Heaney 2004-10-01 0:04 ` Kevin Cline 2004-09-30 19:01 ` Björn Persson 2 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-30 16:50 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409291942.5790386d@posting.google.com... > > There seems to be some confusion between creating a pointer to a > particular member of a particular record, and the C++ pointer to > member type. > > In C++: [snip] There seems to be some confusion between creating an offset to a record component, and simply using an Ada function pointer: In Ada: declare type T is record A, B : Integer; end record; function A (O : T) return Integer is begin return O.A; end; function B (O : T) return Integer is begin return O.B; end; type Query_Type is access function (O : T) return Integer; Query : Query_Type := A'Access; O1 : T := (3, 5); O2 : T := (4, 6); begin pragma Assert (Query (O1) = 3); pragma Assert (Query (O2) = 4); Query := B'Access; pragma Assert (Query (O1) = 5); pragma Assert (Query (O2) = 6); end; > The availability of pointers to members makes it possible to concisely > express the mapping between the a data member and the "A" column of a > database table. The availability of pointers to local functions makes it possible to concisely express the mapping between the A record component and the "A" column of a database table. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 16:50 ` Matthew Heaney @ 2004-10-01 0:04 ` Kevin Cline 2004-10-01 12:25 ` Georg Bauhaus 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-10-01 0:04 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:<415c36c0$0$91010$39cecf19@news.twtelecom.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0409291942.5790386d@posting.google.com... > > > > There seems to be some confusion between creating a pointer to a > > particular member of a particular record, and the C++ pointer to > > member type. > > > > In C++: > [snip] > > There seems to be some confusion between creating an offset to a record > component, and simply using an Ada function pointer: > > In Ada: > > declare > type T is record > A, B : Integer; > end record; > > function A (O : T) return Integer is > begin > return O.A; > end; > > function B (O : T) return Integer is > begin > return O.B; > end; > > type Query_Type is access function (O : T) return Integer; > > Query : Query_Type := A'Access; > > O1 : T := (3, 5); > O2 : T := (4, 6); > > begin > > pragma Assert (Query (O1) = 3); > pragma Assert (Query (O2) = 4); > > Query := B'Access; > > pragma Assert (Query (O1) = 5); > pragma Assert (Query (O2) = 6); > > end; > > > > > The availability of pointers to members makes it possible to concisely > > express the mapping between the a data member and the "A" column of a > > database table. > > The availability of pointers to local functions makes it possible to > concisely express the mapping between the A record component and the "A" > column of a database table. I don't personally consider this to be particularly concise. There were two lines C++ code, one to declare the data member: int a; and one to create the table entry: db.insert("PERSON.SSN", &Person::ssn). There are at least six lines of Ada code: the member declaration, a function to access the data member, the instantiation of the insert function for members of that type, and finally the call of the instantiated function. Not much of a savings over simply writing separate create, read, and update functions for the record type. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-01 0:04 ` Kevin Cline @ 2004-10-01 12:25 ` Georg Bauhaus 2004-10-02 7:35 ` K 0 siblings, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-10-01 12:25 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Not much of a savings over simply writing : separate create, read, and update functions for the record type. Why are you so keen on savings? -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-01 12:25 ` Georg Bauhaus @ 2004-10-02 7:35 ` K 2004-10-02 10:00 ` Brian May ` (2 more replies) 0 siblings, 3 replies; 229+ messages in thread From: K @ 2004-10-02 7:35 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cjjib1$kdq$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : Not much of a savings over simply writing > : separate create, read, and update functions for the record type. > > Why are you so keen on savings? Because it makes an enormous difference in the cost of developing and maintaining code. It's much easier to write and maintain a table like this: dbmap<Order> order_map; order_map.insert("ORDER.NUMBER", &Order::number) .insert("ORDER.CUSTOMER", &Order::customer_number) .insert("ORDER.ACCEPTED", &Order::acceptance_date) .insert("ORDER.PROMISED", &Order::promised_ship_date) ... and then be able to write: Order order; order_map.read(dbreader, order); order.promised_ship_date = ship_date(order.line_items); order_map.update(dbconnection, order); than to maintain code like this: read_order(DatabaseReader& reader, Order& order) { order.number = reader["ORDER.NUMBER"]; order.customer_number = reader["ORDER.CUSTOMER"]; order.acceptance_date = parse<Date>(reader["ORDER.ACCEPTED"]); ... } update_order(DatabaseConnection& connection, Order& order) { writer["ORDER.NUMBER"] = order.number; writer["ORDER.CUSTOMER"] = ...; } create_order(...) { // more of the same } Maybe you're happy keeping three copies of essentially the same code carefully synchronized. I'm not. I prefer to squeeze out as much redundancy as possible so that changes need be made in only one place. That is one of the key practices that separates expert programmers from average programmers. The average programmer gets a requirement to add two new fields to a record, and has to carefully update three separate functions. Except that once in a while he misses one and the functions are out of sync, and an hour is lost tracking the problem. The expert simply has to add two members to the record definition, then add two entries to the map, with almost no way to go wrong. Basically, if you know what code is going to say without reading it, then the code is redundant, and should be rewritten to eliminate the redundancy. I have found this to be easier in C++ than in Ada. Admittedly, C++ template programming could be easier. Most programmers would be incapable of writing the dbmap class and the associated infrastructure. But once written, all programmers would be able to use the dbmap class. In a reflective language this sort of mapping is relatively simple and should be within the abilities of most developers. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 7:35 ` K @ 2004-10-02 10:00 ` Brian May 2004-10-02 20:39 ` Kevin Cline 2004-10-02 13:40 ` Matthew Heaney 2004-10-02 23:33 ` Randy Brukardt 2 siblings, 1 reply; 229+ messages in thread From: Brian May @ 2004-10-02 10:00 UTC (permalink / raw) >>>>> "K" == K <slatyb@yahoo.com> writes: K> dbmap<Order> order_map; K> order_map.insert("ORDER.NUMBER", &Order::number) K> .insert("ORDER.CUSTOMER", &Order::customer_number) K> .insert("ORDER.ACCEPTED", &Order::acceptance_date) K> .insert("ORDER.PROMISED", &Order::promised_ship_date) K> ... K> and then be able to write: K> Order order; K> order_map.read(dbreader, order); K> order.promised_ship_date = ship_date(order.line_items); K> order_map.update(dbconnection, order); Hmmmm... Thinking aloud: One approach that might work, at least for some applications: declare type Index_Type is (Number, Customer_Number, Acceptance_Date, Promised_Ship_Date, ...); begin insert(Order_Map, Number); insert(Order_Map, Customer_Number); insert(Order_Map, Acceptance_Date); insert(Order_Map, Promised_Ship_Date); ... end; ... declare type Order is array (Index_Type) of ???? begin Read(Order_Map, dbreader, Order); Order(Promised_Ship_Date) := ship_date(order.line_items); Update(Order_Map,dbconnection, Order); ... end; (not tested; syntax may not be exactly correct) The obvious problem with this is that all values need be the same type. I am not sure if your code has this limitation or not. Perhaps you could solve this with using a tagged type and inheritance. I have a vague feeling this won't work; you can't have an array of unconstrained types... -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 10:00 ` Brian May @ 2004-10-02 20:39 ` Kevin Cline 2004-10-03 2:17 ` Brian May 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-10-02 20:39 UTC (permalink / raw) Brian May <bam@snoopy.apana.org.au> wrote in message news:<sa4wty9a196.fsf@snoopy.apana.org.au>... > >>>>> "K" == K <slatyb@yahoo.com> writes: > > K> dbmap<Order> order_map; > > K> order_map.insert("ORDER.NUMBER", &Order::number) > K> .insert("ORDER.CUSTOMER", &Order::customer_number) > K> .insert("ORDER.ACCEPTED", &Order::acceptance_date) > K> .insert("ORDER.PROMISED", &Order::promised_ship_date) > K> ... > > K> and then be able to write: > > K> Order order; > K> order_map.read(dbreader, order); > K> order.promised_ship_date = ship_date(order.line_items); > K> order_map.update(dbconnection, order); > > Hmmmm... Thinking aloud: One approach that might work, at least for > some applications: > > declare > type Index_Type is (Number, Customer_Number, Acceptance_Date, > Promised_Ship_Date, ...); > begin > insert(Order_Map, Number); > insert(Order_Map, Customer_Number); > insert(Order_Map, Acceptance_Date); > insert(Order_Map, Promised_Ship_Date); Sorry, I didn't make it clear that not all thes data members are integers. The dates have Date type, and other members will be strings or other user-defined types. > ... > end; > > (not tested; syntax may not be exactly correct) > > The obvious problem with this is that all values need be the same > type. I am not sure if your code has this limitation or not. No, it doesn't. That's the point. The insert function is a template member function with a declaration like this: template <class RecordType> class DatabaseMap { vector<ColumnMap> entries; ... template <class MemberType> DatabaseMap& insert(Column c, MemberType RecordType::*member_pointer) { entries.push_back(new ColumnMemberMap<RecordType, MemberType> (c, member_pointer)); return this; } } Matt has suggested ways this can be done in Ada, but it requires to create a function for every data member to be mapped, and additionally you will have to instantiate the insert function for each different member type. That is so much work that it destroys the value of the technique. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 20:39 ` Kevin Cline @ 2004-10-03 2:17 ` Brian May 0 siblings, 0 replies; 229+ messages in thread From: Brian May @ 2004-10-03 2:17 UTC (permalink / raw) >>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes: Kevin> template <class RecordType> Kevin> class DatabaseMap Kevin> { Kevin> vector<ColumnMap> entries; Kevin> ... Kevin> template <class MemberType> Kevin> DatabaseMap& insert(Column c, MemberType Kevin> RecordType::*member_pointer) Kevin> { Kevin> entries.push_back(new ColumnMemberMap<RecordType, MemberType> Kevin> (c, member_pointer)); Kevin> return this; Kevin> } Kevin> } Ok. So thinking out aloud, if I got this correct, your example of: dbmap<Order> order_map; order_map.insert("ORDER.NUMBER", &Order::number) .insert("ORDER.CUSTOMER", &Order::customer_number) .insert("ORDER.ACCEPTED", &Order::acceptance_date) .insert("ORDER.PROMISED", &Order::promised_ship_date) ... Would be equivalent to: vector<ColumnMap> entries; entries[0] := new ColumnMemberMap<order_map, MyInteger>("ORDER.NUMBER",i &Order::number) entries[1] := new ColumnMemberMap<order_map, MyInteger>("ORDER.CUSTOMER",i &Order::customer_number); entries[2] := new ColumnMemberMap<order_map, MyInteger>("ORDER.ACCEPT",i &Order::acceptance_date); entries[3] := new ColumnMemberMap<order_map, MyDate>("ORDER.PROMISED",i &Order::promised_ship_date); vector<ColumnMap> entries; What is the relationship between ColumnMemberMap and ColumnMap? I might assume: typedef ColumnType *ColumnMap; /* ColumnMap points to ColumnType */ class ColumnType { }; template <class RecordType, class MemberType> class ColumnMemberMap : XYZ { ColumnMemberMap(Column c, MemberType RecordType::*member_pointer) { ... } }; If so, I think this could be done in Ada (yes, this is messy, it has gone through several revisions, it could be tidied up): declare -- holds the data type Column_Type is tagged private; type Column_Access is access all Column_Type'Class; generic type Member_Type is private; package Members type Column_Type is new Column_Type with private; procedure Set(Column : Column_Type, Member : Member_Type); function Get(Column : Column_Type) return Member_Type; private ... end Members; ... -- function to retrieve the data package Integer_Members is new Members(MyInteger); package Date_Members is new Members(MyDate); -- returns new Integer_Members.Column_Type if Integer -- returns new Date_Members.Column_Type if Date -- etc function Get(dbreader : dbreader_type; C : Unbounded_String) return Column_Access; ... type Index_Type is (Number, Customer_Number, Acceptance_Date, Promised_Ship_Date, ...); type Order_Map_Type is array (Index_Type) of Unbounded_String; type Order_Type is array (Index_Type) of Column_Access; Order_Map : Order_Map_Type; Order : Order; begin Order_Map := ( Number => +"ORDER.NUMBER", Customer_Number => +"ORDER.CUSTOMER", Acceptance_Date => +"ORDER.ACCEPTANCE", Promised_Ship_Date => +"ORDER.PROMISED", ... ); for I in Order_Map'Range loop declare C : constant Unbounded_String := Order_Map(I); D : constant Column_Access := Get(dbreader,C); begin Order(I) := D; end; end loop; end; In a real application, I would split this out into other functions, like you have. Presumably "Get" would already be defined and the one function would get an access type to any type. This might not be what you anticipated, but my imagination is running out right now. The only disadvantage I can immediately see is that setting/retrieving values would require some sort of (perhaps ugly) cast, also meaning run-time type checks would be used, not compile-time type checks (unless you have a per field conversion function, which would increase complexity). Disclaimer: NOT TESTED!!! Hopefully this makes some sort of sense, other then proving me insane ;-) -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 7:35 ` K 2004-10-02 10:00 ` Brian May @ 2004-10-02 13:40 ` Matthew Heaney 2004-10-02 23:33 ` Randy Brukardt 2 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-10-02 13:40 UTC (permalink / raw) slatyb@yahoo.com (K) writes: > Because it makes an enormous difference in the cost of developing and > maintaining code. It's much easier to write and maintain a table like > this: > > dbmap<Order> order_map; > > order_map.insert("ORDER.NUMBER", &Order::number) > .insert("ORDER.CUSTOMER", &Order::customer_number) > .insert("ORDER.ACCEPTED", &Order::acceptance_date) > .insert("ORDER.PROMISED", &Order::promised_ship_date) > ... procedure Insert (Map : in out Map_T; Key : in String; Process : not null access function (Order : access Order_T) return Integer); declare M : Map_T; begin M.Insert ("ORDER.NUMBER", Number'Access); M.Insert ("ORDER.CUSTOMER", Customer_Number'Access); ... ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 7:35 ` K 2004-10-02 10:00 ` Brian May 2004-10-02 13:40 ` Matthew Heaney @ 2004-10-02 23:33 ` Randy Brukardt 2004-10-03 12:47 ` Stephen Leake 2 siblings, 1 reply; 229+ messages in thread From: Randy Brukardt @ 2004-10-02 23:33 UTC (permalink / raw) "K" <slatyb@yahoo.com> wrote in message news:4c2ec8a8.0410012335.dcf9001@posting.google.com... ... > than to maintain code like this: > > read_order(DatabaseReader& reader, Order& order) > { > order.number = reader["ORDER.NUMBER"]; > order.customer_number = reader["ORDER.CUSTOMER"]; > order.acceptance_date = parse<Date>(reader["ORDER.ACCEPTED"]); > ... > } It's orthogonal to your original point, but Ada contains features to make it impossible to forget to modify some section of code when components are added. That mitigates any needed duplication to some extent. procedure Read_Order (Reader : DatabaseReader_Type; Order : in out Order_Type) is begin Order := (Number => Reader("Order.Number"), Customer_Number => Reader("Order.Customer"), ...); end Read_Order; If a component is added to Order, the compiler will complain if this aggregate is not updated. I'd probably use an enumeration type to map the names of the fields in order to bring completeness checking to that side of the equation as well. But I admit that I still can't figure out what it is that this "pointer to member" does that is different than taking an access of a component. The only thing that Ada doesn't have here is an equivalent to "void", which is of course about safety - all access types have to have a designated type. Randy. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 23:33 ` Randy Brukardt @ 2004-10-03 12:47 ` Stephen Leake 0 siblings, 0 replies; 229+ messages in thread From: Stephen Leake @ 2004-10-03 12:47 UTC (permalink / raw) To: comp.lang.ada "Randy Brukardt" <randy@rrsoftware.com> writes: > But I admit that I still can't figure out what it is that this "pointer to > member" does that is different than taking an access of a component. The > only thing that Ada doesn't have here is an equivalent to "void", which is > of course about safety - all access types have to have a designated type. >From the example posted, it appears a "pointer to member" is an offset from the start of the record, rather than an absolute pointer. So, in psuedo-Ada : type A_Type is record A : Integer; B : Integer; end record; type A_Component_Access_Type is access component A_Type; Access_B : A_Component_Access_Type := A_Type.B'Component_Access; -- Note that 'Component_Access takes a _type_, not an _Object_. D : A_Type := (1, 2); E : A_Type := (3, 4); F : Integer := D.Access_B.all; G : Integer := E.Access_B.all; Now F = 2 and G = 4. Of course, this is the same as: F : Integer := D.B; G : Integer := E.B; But if the names are long and complex, the pointer to member might be a good optimization (like a renames). I'm not clear on exactly how that would work. I don't see how it relates to database fields. -- -- Stephe ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 3:42 ` Kevin Cline 2004-09-30 7:54 ` Dale Stanbrough 2004-09-30 16:50 ` Matthew Heaney @ 2004-09-30 19:01 ` Björn Persson 2004-09-30 23:54 ` Kevin Cline 2 siblings, 1 reply; 229+ messages in thread From: Björn Persson @ 2004-09-30 19:01 UTC (permalink / raw) Kevin Cline wrote: > In C++: procedure Demo is > struct X > { > int a; > int b; > }; type X_Index is (A, B); type X is array(X_index) of Integer; > X x1 = { 3, 5 }; > X x2 = { 4, 6 }; X1 : X := (3, 5); X2 : X := (4, 6); > int X::*ptm = &X::a; PTM : X_Index := A; begin > ASSERT(x1->*ptm == 3); > ASSERT(x2->*ptm == 4); pragma Assert(X1(PTM) = 3); pragma Assert(X2(PTM) = 4); > ptm = &X::b; PTM := B; > ASSERT(x1->*ptm == 5); > ASSERT(x2->*ptm == 6); pragma Assert(X1(PTM) = 5); pragma Assert(X2(PTM) = 6); end Demo; -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 19:01 ` Björn Persson @ 2004-09-30 23:54 ` Kevin Cline 2004-10-01 16:11 ` Björn Persson 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-30 23:54 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<yKY6d.4590$d5.36128@newsb.telia.net>... > Kevin Cline wrote: > > > In C++: > > procedure Demo is > > > struct X > > { > > int a; > > int b; > > }; > > type X Index is (A, B); > type X is array(X index) of Integer; Looks like I should have written: struct X { int a; int b; float c; std::string d; } ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 23:54 ` Kevin Cline @ 2004-10-01 16:11 ` Björn Persson 2004-10-02 6:48 ` K 0 siblings, 1 reply; 229+ messages in thread From: Björn Persson @ 2004-10-01 16:11 UTC (permalink / raw) Kevin Cline wrote: > Looks like I should have written: > > struct X > { > int a; > int b; > float c; > std::string d; > } :-) I thought you'd counter with that. So now you have a structure with two integers, a float and a string, and you need to set a variable such that the one or the other integer is selected depending on the variable. That makes it seem like there is some kind of relation between the integers; a relation that isn't there with the float or the string. So it seems natural to group the integers together: with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; procedure Demo is type AB_Index is (A, B); type AB_Type is array(AB_Index) of Integer; type X is record AB : AB_Type; C : Float; D : Unbounded_String; end record; X1 : X := ((3, 5), 1.2, To_Unbounded_String("Apes")); X2 : X := ((4, 6), 7.8, To_Unbounded_String("Beeps")); PTM : AB_Index := A; begin pragma Assert(X1.AB(PTM) = 3); pragma Assert(X2.AB(PTM) = 4); PTM := B; pragma Assert(X1.AB(PTM) = 5); pragma Assert(X2.AB(PTM) = 6); end Demo; -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-01 16:11 ` Björn Persson @ 2004-10-02 6:48 ` K 2004-10-02 10:41 ` Björn Persson ` (2 more replies) 0 siblings, 3 replies; 229+ messages in thread From: K @ 2004-10-02 6:48 UTC (permalink / raw) Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<pkf7d.4649$d5.36957@newsb.telia.net>... > Kevin Cline wrote: > > > Looks like I should have written: > > > > struct X > > { > > int a; > > int b; > > float c; > > std::string d; > > } > > :-) I thought you'd counter with that. So now you have a structure with > two integers, a float and a string, and you need to set a variable such > that the one or the other integer is selected depending on the variable. No, I think that you are missing the whole point, which is to represent a relationship between the members of the structure and columns in a database. This is pretty easy with the C++ pointer-to-member construct, but Ada lacks that construct so you have to instead wrap the data members with a function so you can store an access-to-function. But it's worse, since you will need two functions, one to read the datum and one to set it. > That makes it seem like there is some kind of relation between the > integers; There isn't. > a relation that isn't there with the float or the string. So > it seems natural to group the integers together It's not. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 6:48 ` K @ 2004-10-02 10:41 ` Björn Persson 2004-10-02 13:32 ` Matthew Heaney 2004-10-04 9:02 ` Ole-Hjalmar Kristensen 2 siblings, 0 replies; 229+ messages in thread From: Björn Persson @ 2004-10-02 10:41 UTC (permalink / raw) K wrote: > No, I think that you are missing the whole point, which is to > represent a relationship between the members of the structure and > columns in a database. Kevin Cline posted a code example in C++. I showed how the example could be translated to Ada despite Ada's lack of pointer-to-member types. That's all. That example had nothing to do with databases, so I suppose it failed to show the point. -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 6:48 ` K 2004-10-02 10:41 ` Björn Persson @ 2004-10-02 13:32 ` Matthew Heaney 2004-10-04 9:02 ` Ole-Hjalmar Kristensen 2 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-10-02 13:32 UTC (permalink / raw) slatyb@yahoo.com (K) writes: > This is pretty easy with the C++ pointer-to-member construct, but Ada > lacks that construct so you have to instead wrap the data members with > a function so you can store an access-to-function. But it's worse, > since you will need two functions, one to read the datum and one to > set it. You're still confused: function A (O : access T) return Integer_Access; --Ada95 O : aliased T; N : Integer; begin A (O'Access).all := 42; N := A (O'Access).all; end; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-02 6:48 ` K 2004-10-02 10:41 ` Björn Persson 2004-10-02 13:32 ` Matthew Heaney @ 2004-10-04 9:02 ` Ole-Hjalmar Kristensen 2 siblings, 0 replies; 229+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-10-04 9:02 UTC (permalink / raw) >>>>> "K" == K <slatyb@yahoo.com> writes: K> Bj�rn Persson <spam-away@nowhere.nil> wrote in message news:<pkf7d.4649$d5.36957@newsb.telia.net>... >> Kevin Cline wrote: >> >> > Looks like I should have written: >> > >> > struct X >> > { >> > int a; >> > int b; >> > float c; >> > std::string d; >> > } >> >> :-) I thought you'd counter with that. So now you have a structure with >> two integers, a float and a string, and you need to set a variable such >> that the one or the other integer is selected depending on the variable. K> No, I think that you are missing the whole point, which is to K> represent a relationship between the members of the structure and K> columns in a database. K> This is pretty easy with the C++ pointer-to-member construct, but Ada K> lacks that construct so you have to instead wrap the data members with K> a function so you can store an access-to-function. But it's worse, K> since you will need two functions, one to read the datum and one to K> set it. A plain pointer works just fine for binding data members to columns in a database, so you don't need the special pointer-to-member construct in this case. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 15:27 ` James Alan Farrell 2004-09-22 21:24 ` Simon Wright @ 2004-09-23 9:00 ` Kevin Cline 2004-09-23 11:27 ` Ole-Hjalmar Kristensen 2004-09-23 19:42 ` Alexander E. Kopilovich 1 sibling, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 9:00 UTC (permalink / raw) James Alan Farrell <anonymous@anonymous.com> wrote in message news:<g563l0llm9trvjcn9n9ao4vit704b43kqm@4ax.com>... > On 21 Sep 2004 17:21:38 -0700, kevin.cline@gmail.com (Kevin Cline) > wrote: > > >As promised in the Ada popularity thread, I have taken one of the > >Charles examples and reimplemented it in C++. I used only the > >standard C++ language and libraries. The Ada/CHARLES main program > >body is 118 (non-blank) lines of code, plus an additional 40 lines of > >instantiations in eight other specification files, for a total of 158 > >lines and 9 files. The C++ implementation is 76 (non-blank) lines of > >code in a single file. For grins, I also wrote the program in Perl. > >That took 14 lines. > > > >Summary: > > > >Ada/Charles 158 lines, 9 files > >C++ 76 lines > >Perl 14 lines > > > >You can compare the implementations at > >http://www.geocities.com/kc0a/wordcount.html > > Just have to put my $0.02 in on this: > > Does this prove that perl is the best language? If so, perhaps we > should all switch our avionics projects over to perl. Must be it will > be easier to code and maintain, safer to fly, and run just as fast. It doesn't prove that Perl is the best language for every job. But the original thread was about Ada popularity. Relatively few people write avionics code, or any safety-critical software. I do think that a lot of projects currently being written in C++, Java, or C# could be done much more cheaply and effectively in Perl or a similar language. > > The things that make a language a "good" language are many and > complex, and are different in different circumstances. If I need a > small utility that compares lines in different text files, I find perl > much easier than Ada. On the other hand, if I have a very large > project that must always perform "correctly", I've not found a > language that can beat Ada. But large projects in Ada or C++ or Java or C# might be small or medium-sized projects in a higher-level language. If you have a project that must always perform "correctly", then you better prove it correct. Strong typing can help, but is not absolutely necessary to that effort. For the rest of us, the most important thing is to get tested code done quickly. I don't know about you, but I can write and test 14 lines of code a whole lot faster than I can write and test 80 or 160. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 9:00 ` Kevin Cline @ 2004-09-23 11:27 ` Ole-Hjalmar Kristensen 2004-09-23 19:11 ` Kevin Cline 2004-09-23 19:30 ` jayessay 2004-09-23 19:42 ` Alexander E. Kopilovich 1 sibling, 2 replies; 229+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-23 11:27 UTC (permalink / raw) >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes: <snip> >> >> Does this prove that perl is the best language? If so, perhaps we >> should all switch our avionics projects over to perl. Must be it will >> be easier to code and maintain, safer to fly, and run just as fast. KC> It doesn't prove that Perl is the best language for every job. But KC> the original thread was about Ada popularity. Relatively few people KC> write avionics code, or any safety-critical software. I do think that KC> a lot of projects currently being written in C++, Java, or C# could be KC> done much more cheaply and effectively in Perl or a similar language. >> >> The things that make a language a "good" language are many and >> complex, and are different in different circumstances. If I need a >> small utility that compares lines in different text files, I find perl >> much easier than Ada. On the other hand, if I have a very large >> project that must always perform "correctly", I've not found a >> language that can beat Ada. KC> But large projects in Ada or C++ or Java or C# might be small or KC> medium-sized projects in a higher-level language. Maybe. It depends on how large the projcet is, and how good you are to create reusable components/abstractions within the project, and how good a fit your problem is to the facilites provided by the "higher-level" language. KC> If you have a project that must always perform "correctly", then you KC> better prove it correct. Strong typing can help, but is not KC> absolutely necessary to that effort. KC> For the rest of us, the most important thing is to get tested code KC> done quickly. I don't know about you, but I can write and test 14 KC> lines of code a whole lot faster than I can write and test 80 or 160. I usually find that my ability to create programs is limited by my thought process, not my typing speed :-) -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:27 ` Ole-Hjalmar Kristensen @ 2004-09-23 19:11 ` Kevin Cline 2004-09-23 21:01 ` Alexander E. Kopilovich ` (3 more replies) 2004-09-23 19:30 ` jayessay 1 sibling, 4 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 19:11 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrd60dusx0.fsf@sun.com>... > >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes: > > <snip> > > >> > >> Does this prove that perl is the best language? If so, perhaps we > >> should all switch our avionics projects over to perl. Must be it will > >> be easier to code and maintain, safer to fly, and run just as fast. > > KC> It doesn't prove that Perl is the best language for every job. But > KC> the original thread was about Ada popularity. Relatively few people > KC> write avionics code, or any safety-critical software. I do think that > KC> a lot of projects currently being written in C++, Java, or C# could be > KC> done much more cheaply and effectively in Perl or a similar language. > > >> > >> The things that make a language a "good" language are many and > >> complex, and are different in different circumstances. If I need a > >> small utility that compares lines in different text files, I find perl > >> much easier than Ada. On the other hand, if I have a very large > >> project that must always perform "correctly", I've not found a > >> language that can beat Ada. > > KC> But large projects in Ada or C++ or Java or C# might be small or > KC> medium-sized projects in a higher-level language. > > Maybe. It depends on how large the projcet is, and how good you are to > create reusable components/abstractions within the project, and how > good a fit your problem is to the facilites provided by the > "higher-level" language. > > KC> If you have a project that must always perform "correctly", then you > KC> better prove it correct. Strong typing can help, but is not > KC> absolutely necessary to that effort. > > KC> For the rest of us, the most important thing is to get tested code > KC> done quickly. I don't know about you, but I can write and test 14 > KC> lines of code a whole lot faster than I can write and test 80 or 160. > > I usually find that my ability to create programs is limited by my > thought process, not my typing speed :- Mine too. For the Perl program, the thought process was limited to this: read input: while (<>) split into sequences of alphabetic characters: foreach my $word (split (/[a-zA-Z]+/)) count words: ++$count{$word} sort words by frequency: sort { $map{$a} <=> $map{$b} ) keys %count print first 10: $n = 0; foreach ( ... ) { print ...; last if ++$n >= 10; } The only bits that required much thought at all were figuring out the right comparison function for sorting (I looked at an example), and getting the loop exit right. The rest was written nearly instantaneously. Are you really claiming that you can think of: procedure Insert (Word : in String) is procedure Increment_Count (K : in String; N : in out Natural) is pragma Warnings (Off, K); begin N := N + 1; end Increment_Count; C : Wordcount_Maps.Cursor; B : Boolean; begin -- Insert Insert (M, Word, 0, C, B); Update_Element (C, Increment_Count'Access); end Insert; As quickly as I can think of: ++concordance[word] or ++$count{$word} ? Multiply this 1000 times for a medium to large program and I think Ada really suffer from unnecessary verbosity. It's reasonable to claim that Ada is better than C++ for safety-critical embedded programming, but if you really want to understand why Ada is not more popular for desktop applications I think the evidence is here. The real question I have is why Perl and similar high-level languages are not more popular. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:11 ` Kevin Cline @ 2004-09-23 21:01 ` Alexander E. Kopilovich 2004-09-26 6:53 ` Kevin Cline 2004-09-23 21:54 ` Eric Jacoboni ` (2 subsequent siblings) 3 siblings, 1 reply; 229+ messages in thread From: Alexander E. Kopilovich @ 2004-09-23 21:01 UTC (permalink / raw) To: comp.lang.ada Kevin Cline wrote: > The real question I have is why Perl and > similar high-level languages are not more popular. Perl has its own great competitor - Visual Basic (and to some degree Delphi and some others, which also provide nice buttons and other GUI components) - just as Ada has C++ and to some degree Java. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 21:01 ` Alexander E. Kopilovich @ 2004-09-26 6:53 ` Kevin Cline 2004-09-26 15:29 ` Alexander E. Kopilovich 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 6:53 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:<mailman.76.1095975168.390.comp.lang.ada@ada-france.org>... > Kevin Cline wrote: > > > The real question I have is why Perl and > > similar high-level languages are not more popular. > Perl has its own great competitor - Visual Basic (and to some degree Delphi > and some others, which also provide nice buttons and other GUI components) I have written a lot of Perl and some Visual Basic, and Visual Basic is not much of a competitor to Perl. Perl is fully reflexive and quite extensible, although some of the extension mechanisms are a bit arcane. By comparison with Perl, Visual Basic is completely inextensible. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 6:53 ` Kevin Cline @ 2004-09-26 15:29 ` Alexander E. Kopilovich 0 siblings, 0 replies; 229+ messages in thread From: Alexander E. Kopilovich @ 2004-09-26 15:29 UTC (permalink / raw) To: comp.lang.ada Kevin Cline wrote: > > > The real question I have is why Perl and > > > similar high-level languages are not more popular. > > Perl has its own great competitor - Visual Basic (and to some degree Delphi > > and some others, which also provide nice buttons and other GUI components) > > I have written a lot of Perl and some Visual Basic, and Visual Basic > is not much of a competitor to Perl. Well, Visual Basic is not much a competitor to Perl for you - according to your tasks/skills/tastes, but for too many software developers the situation is opposite. > Perl is fully reflexive and > quite extensible, although some of the extension mechanisms are a bit > arcane. By comparison with Perl, Visual Basic is completely > inextensible. You are certainly either joking or confusing a software development tool with its verbal language core. Unlike Perl, Visual Basic is designed for dealing with end-user behaviour, not just with data streams. And in this direction it is much more extensible than Perl. You may note, that even an early Visual Basic VBX stands for Visual Basic eXtension (although it must be programmed in C/C++) and now ActiveX can be easily created with Visual Basic itself). And there is a sea of various VBX/OCX/ActiveX for public use - commercial, shareware and freeware. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:11 ` Kevin Cline 2004-09-23 21:01 ` Alexander E. Kopilovich @ 2004-09-23 21:54 ` Eric Jacoboni 2004-09-24 9:44 ` Ole-Hjalmar Kristensen 2004-09-24 9:50 ` Georg Bauhaus 3 siblings, 0 replies; 229+ messages in thread From: Eric Jacoboni @ 2004-09-23 21:54 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: I > The real question I have is why Perl and similar high-level > languages are not more popular. But Perl /is/ very popular... Ask a sys or a network admin, for example. That's only a matter of programming domain -- �ric Jacoboni, n� il y a 1399419904 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:11 ` Kevin Cline 2004-09-23 21:01 ` Alexander E. Kopilovich 2004-09-23 21:54 ` Eric Jacoboni @ 2004-09-24 9:44 ` Ole-Hjalmar Kristensen 2004-09-24 9:50 ` Georg Bauhaus 3 siblings, 0 replies; 229+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-24 9:44 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbrd60dusx0.fsf@sun.com>... > > >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes: > > <snip> > > I usually find that my ability to create programs is limited by my > > thought process, not my typing speed :- > > Mine too. For the Perl program, the thought process was limited to > this: > > read input: while (<>) > > split into sequences of alphabetic characters: > foreach my $word (split (/[a-zA-Z]+/)) > > count words: ++$count{$word} > > sort words by frequency: sort { $map{$a} <=> $map{$b} ) keys %count > > print first 10: $n = 0; foreach ( ... ) { print ...; last if ++$n >= > 10; } > > The only bits that required much thought at all were figuring out the > right comparison function for sorting (I looked at an example), and > getting the loop exit right. The rest was written nearly > instantaneously. > > Are you really claiming that you can think of: > > procedure Insert (Word : in String) is > > procedure Increment_Count > (K : in String; > N : in out Natural) is > > pragma Warnings (Off, K); > begin > N := N + 1; > end Increment_Count; > > C : Wordcount_Maps.Cursor; > B : Boolean; > > begin -- Insert > Insert (M, Word, 0, C, B); > Update_Element (C, Increment_Count'Access); > end Insert; > > As quickly as I can think of: > ++concordance[word] > or > ++$count{$word} ? > No, not at all. But I usually write programs where the logic tends to be a bit more complicated, and where the instantiation of templates/generics and similar boiler plate is not dominating. > Multiply this 1000 times for a medium to large program and I think Ada > really suffer from unnecessary verbosity. > > It's reasonable to claim that Ada is better than C++ for > safety-critical embedded programming, but if you really want to > understand why Ada is not more popular for desktop applications I > think the evidence is here. The real question I have is why Perl and > similar high-level languages are not more popular. If I wanted something more high-level I would use Lisp, not Perl. Now consider the following implementation of a polygon clipper (an old test program I had lying around to test the relative speed of a recursive and non-recursive version of essentially the same polygon clipper) Do you really believe this program had been any more readable or easy to program in C++ or Perl? with Vector; use Vector; -- Contains basic vector and plane stuff -- Pipelined Sutherland-Hodgson type polygon clipper -- Pipeline implemented by recursive calls procedure Sutherland is -- Polygon container type Vertex_Array is array(Integer range <>) of Vector3; -- Stage in pipeline type Stage is record Pl : Plane; -- Clipping plane S : Vector3; -- Start point F : Boolean := true; -- First visit? Closing : Vector3; -- Closing point end record; -- 6 planes for frustum clipping Stages : array(1..6) of Stage; procedure Reset_Stages is begin for I in Stages'Range loop Stages(I).F := True; end loop; end Reset_Stages; -- Test if vertex is inside plane function Inside(Test_Vertex : Vector3; clip : Integer) return Boolean is begin return Inside(Test_Vertex, Stages(Clip).Pl); end Inside; -- Return intersect of vector from S to P with plane function Intersect(S : Vector3; P : Vector3; Clip : Integer ) return Vector3 is begin return Intersect(S,P,Stages(Clip).Pl); end Intersect; -- Output vertex to next stage of clipper procedure Output_Point(Clip_Stage : Integer; P : Vector3); -- Clip vertex to plane given by Clip_Stage procedure Clip_Vertex(Clip_Stage : Integer; P : Vector3) is Clipped_P : Vector3; begin -- Initialize start if first time if Stages(Clip_Stage).F then Stages(Clip_Stage).S := P; Stages(Clip_Stage).Closing := P; Stages(Clip_Stage).F := False; else if Inside(P,Clip_Stage) then if Inside(Stages(Clip_Stage).S,Clip_Stage) then Output_Point(Clip_Stage,P); else Clipped_P := Intersect(Stages(Clip_Stage).S,P,Clip_Stage); Output_Point(Clip_Stage,Clipped_P); Output_Point(Clip_Stage,P); end if; else if Inside(Stages(Clip_Stage).S,Clip_Stage) then Clipped_P := Intersect(Stages(Clip_Stage).S,P,Clip_Stage); Output_Point(Clip_Stage,Clipped_P); end if; end if; Stages(Clip_Stage).S := P; end if; end Clip_Vertex; -- Output vertex to next stage of clipper procedure Output_Point(Clip_Stage : Integer; P : Vector3) is begin if Clip_Stage >= Stages'Last then null; else Clip_Vertex(Clip_Stage + 1, P); end if; end Output_Point; procedure Empty_Pipeline is begin for I in Stages'Range loop if not Stages(I).F then Clip_Vertex(I,Stages(I).Closing); end if; end loop; end Empty_Pipeline; -- Clip polygon by clipping each vertex in turn procedure Clip_Poly(In_Poly : Vertex_Array) Is begin for I in In_Poly'Range loop Clip_Vertex(Stages'First,In_Poly(I)); end loop; Empty_Pipeline; end Clip_Poly; procedure Init_Stages is begin Reset_Stages; -- Front Stages(1).Pl := Create_Plane((0.0,0.0,0.0), (100.0,0.0,0.0), (100.0,0.0,100.0)); -- Back Stages(2).Pl := Create_Plane((100.0,100.0,0.0), (0.0,100.0,0.0), (0.0,100.0,100.0)); -- Left Stages(3).Pl := Create_Plane((0.0,100.0,0.0), (0.0,0.0,0.0), (0.0,0.0,100.0)); -- Right Stages(4).Pl := Create_Plane((100.0,0.0,0.0), (100.0,100.0,0.0), (100.0,100.0,100.0)); -- Bottom Stages(5).Pl := Create_Plane((0.0,0.0,0.0), (0.0,100.0,0.0), (100.0,100.0,0.0)); -- Top Stages(6).Pl := Create_Plane((0.0,0.0,100.0), (100.0,0.0,100.0), (100.0,100.0,100.0)); end Init_Stages; Test_Poly : Vertex_Array(1..3) := ((0.0,0.0,1.0), (150.0,200.0,1.0), (200.0,150.0,1.0)); begin Init_Stages; for I in 1..100000 loop Clip_Poly(Test_Poly); Reset_Stages; end loop; end Sutherland; -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:11 ` Kevin Cline ` (2 preceding siblings ...) 2004-09-24 9:44 ` Ole-Hjalmar Kristensen @ 2004-09-24 9:50 ` Georg Bauhaus 2004-09-24 13:47 ` Matthew Heaney ` (2 more replies) 3 siblings, 3 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-24 9:50 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : Are you really claiming that you can think of: : : procedure Insert (Word : in String) is : : procedure Increment_Count : (K : in String; : N : in out Natural) is : : pragma Warnings (Off, K); : begin : N := N + 1; : end Increment_Count; : : C : Wordcount_Maps.Cursor; : B : Boolean; : : begin -- Insert : Insert (M, Word, 0, C, B); : Update_Element (C, Increment_Count'Access); : end Insert; : : As quickly as I can think of: : ++concordance[word] : or : ++$count{$word} ? Isn't the comparison at different levels? AI 302 is to be minimal, I think, in that every convenient operation can be built from thingies present in Ada.Containers. : Multiply this 1000 times for a medium to large program and I think Ada : really suffer from unnecessary verbosity. Are you saying that Ada programmers automatically don't make reusable procudures and instead will repeat a procedure with the effect of ++ all over the place? -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 9:50 ` Georg Bauhaus @ 2004-09-24 13:47 ` Matthew Heaney 2004-09-24 14:14 ` Dmitry A. Kazakov 2004-09-24 16:28 ` Kevin Cline 2004-09-26 6:32 ` Kevin Cline 2 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 13:47 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Kevin Cline <kevin.cline@gmail.com> wrote: [body of Insert snipped] > : ++concordance[word] > : or > : ++$count{$word} ? > > Isn't the comparison at different levels? AI 302 is to be minimal, I > think, in that every convenient operation can be built from thingies > present in Ada.Containers. Yes, that's exactly right. Which is why the comparison above should really be: Insert (Word); or ++concordance[word] or ++$count{$word} Comparing the one-line C++ and Perl statements to the body of the Insert subprogram defeats the purpose of writing the subprogam! And the reason why we have to write the subpgram is because Ada doesn't give you any direct way of returning a reference to variable view from a function, as C++ does. But even so, in Ada you can modify objets in place (in AI-302 by using a downward closure -- which C++ doesn't have). That's what really matters, not the syntax. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 13:47 ` Matthew Heaney @ 2004-09-24 14:14 ` Dmitry A. Kazakov 2004-09-25 14:17 ` Martin Krischik 2004-09-26 7:17 ` Kevin Cline 0 siblings, 2 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-24 14:14 UTC (permalink / raw) On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote: > And the reason why we have to write the subpgram is because Ada doesn't > give you any direct way of returning a reference to variable view from a > function, as C++ does. But even so, in Ada you can modify objets in > place (in AI-302 by using a downward closure -- which C++ doesn't have). > That's what really matters, not the syntax. Syntax does not matter. What matters is an ability to express an idea in the syntax you want. To me, the most natural syntax for modifying an array element is A(I) := B; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 14:14 ` Dmitry A. Kazakov @ 2004-09-25 14:17 ` Martin Krischik 2004-09-27 8:12 ` Dmitry A. Kazakov 2004-09-26 7:17 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Martin Krischik @ 2004-09-25 14:17 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote: > >> And the reason why we have to write the subpgram is because Ada doesn't >> give you any direct way of returning a reference to variable view from a >> function, as C++ does. But even so, in Ada you can modify objets in >> place (in AI-302 by using a downward closure -- which C++ doesn't have). >> That's what really matters, not the syntax. > > Syntax does not matter. What matters is an ability to express an idea in > the syntax you want. To me, the most natural syntax for modifying an array > element is A(I) := B; True. But only if it works. I just had some fun reading the fineprint from std::vector::operator [] (can not insert new elements - and at least the MS version crashes deep inside library code when you try) and std::map::operator [] (no const version). If it does not work as expected I rather live without and use an Insert () which then does work as expected. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-25 14:17 ` Martin Krischik @ 2004-09-27 8:12 ` Dmitry A. Kazakov 2004-09-27 12:59 ` Georg Bauhaus 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 8:12 UTC (permalink / raw) On Sat, 25 Sep 2004 16:17:34 +0200, Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote: >> >>> And the reason why we have to write the subpgram is because Ada doesn't >>> give you any direct way of returning a reference to variable view from a >>> function, as C++ does. But even so, in Ada you can modify objets in >>> place (in AI-302 by using a downward closure -- which C++ doesn't have). >>> That's what really matters, not the syntax. >> >> Syntax does not matter. What matters is an ability to express an idea in >> the syntax you want. To me, the most natural syntax for modifying an array >> element is A(I) := B; > > True. But only if it works. I just had some fun reading the fineprint from > std::vector::operator [] (can not insert new elements - and at least the MS > version crashes deep inside library code when you try) and > std::map::operator [] (no const version). If it does not work as expected I > rather live without and use an Insert () which then does work as expected. Insert is another story. Whether array indexing should be used for inserting new elements is questionable. Anyway, Ada lacks abstract arrays, abstract indices and many other things, including an ability to return a safe referential cursor as Matthew has pointed, essential for building a safe, intuitive container library. Also in my deep opinion that library should not be generic. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 8:12 ` Dmitry A. Kazakov @ 2004-09-27 12:59 ` Georg Bauhaus 2004-09-27 13:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-09-27 12:59 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : Insert is another story. Whether array indexing should be used for : inserting new elements is questionable. Anyway, Ada lacks abstract arrays, : abstract indices and many other things, In this sense Ada doesn't have anything abstract, does it? -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 12:59 ` Georg Bauhaus @ 2004-09-27 13:53 ` Dmitry A. Kazakov 0 siblings, 0 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 13:53 UTC (permalink / raw) On Mon, 27 Sep 2004 12:59:02 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: Insert is another story. Whether array indexing should be used for >: inserting new elements is questionable. Anyway, Ada lacks abstract arrays, >: abstract indices and many other things, > > In this sense Ada doesn't have anything abstract, does it? You cannot: package Foo is type String is array (Integer range <>) of Character is private; ... private type String is new Ada.Finalization.Controlled with ... An abstract array is something that can be indexed. It means that it has a definite set of abstract primitive operations like "()", ":=", 'First, 'Last etc to be implemented. The way an implementation does it is no matter, so in my hypothetical example, a string is implemented by a controlled type. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 14:14 ` Dmitry A. Kazakov 2004-09-25 14:17 ` Martin Krischik @ 2004-09-26 7:17 ` Kevin Cline 2004-09-27 8:19 ` Dmitry A. Kazakov 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 7:17 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<13bv1aau5q9ht.1fr6ixcdql72.dlg@40tude.net>... > On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote: > > > And the reason why we have to write the subpgram is because Ada doesn't > > give you any direct way of returning a reference to variable view from a > > function, as C++ does. But even so, in Ada you can modify objets in > > place (in AI-302 by using a downward closure -- which C++ doesn't have). > > That's what really matters, not the syntax. > > Syntax does not matter. What matters is an ability to express an idea in > the syntax you want. To me, the most natural syntax for modifying an array > element is A(I) := B; This is how I develop C++ code. I start programming at a high-level, writing code in the syntax I want to use. Then I write the code to support the syntax. This works pretty well until I want to do something like overload ".". So far I haven't thought of doing that, but after messing with boost::lambda, I can see why one would. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 7:17 ` Kevin Cline @ 2004-09-27 8:19 ` Dmitry A. Kazakov 2004-09-27 13:03 ` Georg Bauhaus 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 8:19 UTC (permalink / raw) On 26 Sep 2004 00:17:13 -0700, Kevin Cline wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<13bv1aau5q9ht.1fr6ixcdql72.dlg@40tude.net>... >> On Fri, 24 Sep 2004 13:47:52 GMT, Matthew Heaney wrote: >> >>> And the reason why we have to write the subpgram is because Ada doesn't >>> give you any direct way of returning a reference to variable view from a >>> function, as C++ does. But even so, in Ada you can modify objets in >>> place (in AI-302 by using a downward closure -- which C++ doesn't have). >>> That's what really matters, not the syntax. >> >> Syntax does not matter. What matters is an ability to express an idea in >> the syntax you want. To me, the most natural syntax for modifying an array >> element is A(I) := B; > > This is how I develop C++ code. I start programming at a high-level, > writing code in the syntax I want to use. Then I write the code to > support the syntax. This works pretty well until I want to do > something like overload ".". I wished Ada had abstract record types. In some sense it has an embryo of that for protected types: protected type Object is function Member return A_Type; end Object; But it cannot be abstract, it is read-only etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 8:19 ` Dmitry A. Kazakov @ 2004-09-27 13:03 ` Georg Bauhaus 2004-09-27 14:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-09-27 13:03 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : I wished Ada had abstract record types. Perhaps you could use a word like meta-types or type classes, or type types. Ada does have abstract record types in any Ada sense, I'm sure you know this well. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 13:03 ` Georg Bauhaus @ 2004-09-27 14:00 ` Dmitry A. Kazakov 0 siblings, 0 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 14:00 UTC (permalink / raw) On Mon, 27 Sep 2004 13:03:11 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: I wished Ada had abstract record types. > > Perhaps you could use a word like meta-types or type classes, > or type types. Maybe > Ada does have abstract record types in any Ada sense, I'm sure > you know this well. Yes, you mean an abstract type which is occasionally a record type. What I meant was records as abstract interfaces. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 9:50 ` Georg Bauhaus 2004-09-24 13:47 ` Matthew Heaney @ 2004-09-24 16:28 ` Kevin Cline 2004-09-24 17:45 ` Georg Bauhaus 2004-09-24 20:14 ` Matthew Heaney 2004-09-26 6:32 ` Kevin Cline 2 siblings, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-24 16:28 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cj0qlt$qkh$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : Are you really claiming that you can think of: > : > : procedure Insert (Word : in String) is > : > : procedure Increment_Count > : (K : in String; > : N : in out Natural) is > : > : pragma Warnings (Off, K); > : begin > : N := N + 1; > : end Increment_Count; > : > : C : Wordcount_Maps.Cursor; > : B : Boolean; > : > : begin -- Insert > : Insert (M, Word, 0, C, B); > : Update_Element (C, Increment_Count'Access); > : end Insert; > : > : As quickly as I can think of: > : ++concordance[word] > : or > : ++$count{$word} ? > > Isn't the comparison at different levels? AI 302 is to be minimal, I think, > in that every convenient operation can be built from thingies present in > Ada.Containers. > > > : Multiply this 1000 times for a medium to large program and I think Ada > : really suffer from unnecessary verbosity. > > Are you saying that Ada programmers automatically don't make reusable > procudures and instead will repeat a procedure with the effect of ++ all > over the place? The insert procedure is not reusable. It is specific to Wordcount_Maps. To be reusable it would have to be made generic, and then it would have to be instantiated before it could be used. In C++ you can write ++concordance[word] because of two features present in C++ that are missing in Ada. C++ allows the indexing operator [] to be overridden, so that concordance[key] can be assigned a meaning. Also, C++ has reference types, so that concordance[key] can return a modifiable reference to the value, which can be incremented. Together, these functions allow user-defined types in C++ to be as convenient to use as the built-in array type. I think I made a fair comparison. A claim was made that Ada/CHARLES was essentially equivalent to the C++ STL. I took an example program written by the author of Ada/CHARLES and rewrote it in C++ and Perl. The C++ code was less than half as long, and the Perl code one-tenth as long. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 16:28 ` Kevin Cline @ 2004-09-24 17:45 ` Georg Bauhaus 2004-09-24 20:14 ` Matthew Heaney 1 sibling, 0 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-24 17:45 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: :> Are you saying that Ada programmers automatically don't make reusable :> procudures and instead will repeat a procedure with the effect of ++ all :> over the place? : : The insert procedure is not reusable. It is specific to : Wordcount_Maps. OK. But Insert is not the effect of ++, which is what is had been thinking about. : I took an example program : written by the author of Ada/CHARLES and rewrote it in C++ and Perl. : The C++ code was less than half as long, and the Perl code one-tenth : as long. Well, if it besides the reference issue all boils down to "shorter code is better", Ada is verbose, then I think I can stay with some verbosity. There are far too many neat idioms to remember once I have to use more than one or two languages every other day. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 16:28 ` Kevin Cline 2004-09-24 17:45 ` Georg Bauhaus @ 2004-09-24 20:14 ` Matthew Heaney 2004-09-24 20:10 ` Frank J. Lhota 2004-09-26 7:13 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 20:14 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409240828.53001e66@posting.google.com... > > In C++ you can write ++concordance[word] because of two features > present in C++ that are missing in Ada. C++ allows the indexing > operator [] to be overridden, so that concordance[key] can be assigned > a meaning. Also, C++ has reference types, so that concordance[key] > can return a modifiable reference to the value, which can be > incremented. Together, these functions allow user-defined types in > C++ to be as convenient to use as the built-in array type. Note that (as Randy alluded to) there's still a chance the ARG will add something like reference types to Ada. It would be declared something like: function Update_Element (Container : in Map; Key : in Key_Type) return access Element_Type; Then you could say: Update_Element (M, K).all := 42; In our wordcount example you'd have to say: declare N : Natural renames Update_Element (M, K).all; begin N := N + 1; end; Note that it would possible to get the automatic insertion behavior too, by passing the container as an access parameter: function Update_Element (Container : access Map; Key : in Key_Type) return access Element_Type; and then say: declare N : Natural renames Update_Element (M'Access, K).all; begin N := N + 1; end; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 20:14 ` Matthew Heaney @ 2004-09-24 20:10 ` Frank J. Lhota 2004-09-27 8:29 ` Dmitry A. Kazakov 2004-09-26 7:13 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Frank J. Lhota @ 2004-09-24 20:10 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:41547dae$0$91007$39cecf19@news.twtelecom.net... > Note that (as Randy alluded to) there's still a chance the ARG will add > something like reference types to Ada. It would be declared something > like: > > function Update_Element > (Container : in Map; > Key : in Key_Type) return access Element_Type; > > Then you could say: > > Update_Element (M, K).all := 42; I still like the idea of adding "()" and "():=" operators to Ada. Then you could say: M(K) := 42; This is clearer, and it makes absolutely no assertions as to how containers represent their elements. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 20:10 ` Frank J. Lhota @ 2004-09-27 8:29 ` Dmitry A. Kazakov 0 siblings, 0 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 8:29 UTC (permalink / raw) On Fri, 24 Sep 2004 20:10:36 GMT, Frank J. Lhota wrote: > "Matthew Heaney" <mheaney@on2.com> wrote in message > news:41547dae$0$91007$39cecf19@news.twtelecom.net... >> Note that (as Randy alluded to) there's still a chance the ARG will add >> something like reference types to Ada. It would be declared something >> like: >> >> function Update_Element >> (Container : in Map; >> Key : in Key_Type) return access Element_Type; >> >> Then you could say: >> >> Update_Element (M, K).all := 42; > > I still like the idea of adding "()" and "():=" operators to Ada. "():=" could be problematic in Y(I).Foo(Baz):=Bar. I think it should better be an in-place "()" and ":=". > Then you could say: > > M(K) := 42; > > This is clearer, and it makes absolutely no assertions as to how containers > represent their elements. Yes. And I agree with Randy Brukardt, that a library should avoid using access types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 20:14 ` Matthew Heaney 2004-09-24 20:10 ` Frank J. Lhota @ 2004-09-26 7:13 ` Kevin Cline 2004-09-26 15:15 ` Matthew Heaney 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 7:13 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:<41547dae$0$91007$39cecf19@news.twtelecom.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0409240828.53001e66@posting.google.com... > > > > In C++ you can write ++concordance[word] because of two features > > present in C++ that are missing in Ada. C++ allows the indexing > > operator [] to be overridden, so that concordance[key] can be assigned > > a meaning. Also, C++ has reference types, so that concordance[key] > > can return a modifiable reference to the value, which can be > > incremented. Together, these functions allow user-defined types in > > C++ to be as convenient to use as the built-in array type. > > Note that (as Randy alluded to) there's still a chance the ARG will add > something like reference types to Ada. It would be declared something like: > > function Update_Element > (Container : in Map; > Key : in Key_Type) return access Element_Type; > > Then you could say: > > Update_Element (M, K).all := 42; > > In our wordcount example you'd have to say: > > declare > N : Natural renames Update_Element (M, K).all; > begin > N := N + 1; > end; > > Note that it would possible to get the automatic insertion behavior too, by > passing the container as an access parameter: > > function Update_Element > (Container : access Map; > Key : in Key_Type) return access Element_Type; > > and then say: > > declare > N : Natural renames Update_Element (M'Access, K).all; > begin > N := N + 1; > end; One of the most frustrating things I found in Ada programming was the inability to make user-defined types work like the built-in types. Given A: array (1..10) of integer; then the expression A(5) is a modifiable reference to the fifth element of A. After experience with C++ it was amazingly frustrating to learn that there was no way I could define My_Container so that I could write: C: My_Container ; C(5) := 7; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 7:13 ` Kevin Cline @ 2004-09-26 15:15 ` Matthew Heaney 2004-09-27 14:31 ` Kevin Cline 0 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-26 15:15 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > > One of the most frustrating things I found in Ada programming was the > inability to make user-defined types work like the built-in types. > Given > > A: array (1..10) of integer; > > then the expression A(5) is a modifiable reference to the fifth > element of A. > > After experience with C++ it was amazingly frustrating to learn that > there was no way I could define My_Container so that I could write: > > C: My_Container ; > > C(5) := 7; Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: Replace_Element (C, Index => 5, By => 7); ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 15:15 ` Matthew Heaney @ 2004-09-27 14:31 ` Kevin Cline 2004-09-27 15:05 ` Dmitry A. Kazakov 2004-09-27 16:21 ` Matthew Heaney 0 siblings, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-27 14:31 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > > > One of the most frustrating things I found in Ada programming was the > > inability to make user-defined types work like the built-in types. > > Given > > > > A: array (1..10) of integer; > > > > then the expression A(5) is a modifiable reference to the fifth > > element of A. > > > > After experience with C++ it was amazingly frustrating to learn that > > there was no way I could define My_Container so that I could write: > > > > C: My_Container ; > > > > C(5) := 7; > > > Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: > > Replace_Element (C, Index => 5, By => 7); I think this was a major error in the language design. As a result it very tedious to write a generic that will work with both predefined and user-defined types. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:31 ` Kevin Cline @ 2004-09-27 15:05 ` Dmitry A. Kazakov 2004-09-28 4:22 ` Kevin Cline 2004-09-28 17:21 ` Robert Kawulak 2004-09-27 16:21 ` Matthew Heaney 1 sibling, 2 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-27 15:05 UTC (permalink / raw) On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote: > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>... >> kevin.cline@gmail.com (Kevin Cline) writes: >> >>> One of the most frustrating things I found in Ada programming was the >>> inability to make user-defined types work like the built-in types. >>> Given >>> >>> A: array (1..10) of integer; >>> >>> then the expression A(5) is a modifiable reference to the fifth >>> element of A. >>> >>> After experience with C++ it was amazingly frustrating to learn that >>> there was no way I could define My_Container so that I could write: >>> >>> C: My_Container ; >>> >>> C(5) := 7; >> >> Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: >> >> Replace_Element (C, Index => 5, By => 7); > > I think this was a major error in the language design. It was not an error, in the sense that no irreparable damage was done. It seems that the issue was just put aside for better times. Ada has a rich infrastructure supporting array types and their index types. So to reshape Ada's arrays out of abstract "array interfaces" one need to take all that presently hard-wired infrastructure with. Note that C++ does not solve the problem, because it has no arrays. So it allows you to define [] and leaves you alone with that. It is not the Ada's way (TM). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 15:05 ` Dmitry A. Kazakov @ 2004-09-28 4:22 ` Kevin Cline 2004-09-28 8:20 ` Dmitry A. Kazakov 2004-09-28 17:21 ` Robert Kawulak 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-28 4:22 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net>... > On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote: > > > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>... > >> kevin.cline@gmail.com (Kevin Cline) writes: > >> > >>> One of the most frustrating things I found in Ada programming was the > >>> inability to make user-defined types work like the built-in types. > >>> Given > >>> > >>> A: array (1..10) of integer; > >>> > >>> then the expression A(5) is a modifiable reference to the fifth > >>> element of A. > >>> > >>> After experience with C++ it was amazingly frustrating to learn that > >>> there was no way I could define My_Container so that I could write: > >>> > >>> C: My_Container ; > >>> > >>> C(5) := 7; > >> > >> Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: > >> > >> Replace_Element (C, Index => 5, By => 7); > > > > I think this was a major error in the language design. > > It was not an error, in the sense that no irreparable damage was done. It > seems that the issue was just put aside for better times. Ada has a rich > infrastructure supporting array types and their index types. So to reshape > Ada's arrays out of abstract "array interfaces" one need to take all that > presently hard-wired infrastructure with. Note that C++ does not solve the > problem, because it has no arrays. So it allows you to define [] and leaves > you alone with that. It is not the Ada's way (TM). C++ solves the problem very nicely, it just wasn't solved once and for all by the language designer or by the standard committee. It's not necessary for C++ to have a sophisticated built-in array class because it is relatively easy to build any sort of array you like. So we have std::vector and boost::array, and if you need a sparse array or any other sort you can build that too and they will all work with the standard algorithms and you can switch out one for another with little effort. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 4:22 ` Kevin Cline @ 2004-09-28 8:20 ` Dmitry A. Kazakov 2004-09-28 23:26 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-28 8:20 UTC (permalink / raw) On 27 Sep 2004 21:22:03 -0700, Kevin Cline wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<1g2d9xmnita9f.5ecju0eftkqw$.dlg@40tude.net>... >> On 27 Sep 2004 07:31:44 -0700, Kevin Cline wrote: >> >>> Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>... >>>> kevin.cline@gmail.com (Kevin Cline) writes: >>>> >>>>> One of the most frustrating things I found in Ada programming was the >>>>> inability to make user-defined types work like the built-in types. >>>>> Given >>>>> >>>>> A: array (1..10) of integer; >>>>> >>>>> then the expression A(5) is a modifiable reference to the fifth >>>>> element of A. >>>>> >>>>> After experience with C++ it was amazingly frustrating to learn that >>>>> there was no way I could define My_Container so that I could write: >>>>> >>>>> C: My_Container ; >>>>> >>>>> C(5) := 7; >>>> >>>> Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: >>>> >>>> Replace_Element (C, Index => 5, By => 7); >>> >>> I think this was a major error in the language design. >> >> It was not an error, in the sense that no irreparable damage was done. It >> seems that the issue was just put aside for better times. Ada has a rich >> infrastructure supporting array types and their index types. So to reshape >> Ada's arrays out of abstract "array interfaces" one need to take all that >> presently hard-wired infrastructure with. Note that C++ does not solve the >> problem, because it has no arrays. So it allows you to define [] and leaves >> you alone with that. It is not the Ada's way (TM). > > C++ solves the problem very nicely, it just wasn't solved once and for > all by the language designer or by the standard committee. It's not > necessary for C++ to have a sophisticated built-in array class because > it is relatively easy to build any sort of array you like. ... which won't be an implementation of that sophisticated *non-existing* class. That's the point. > So we have > std::vector and boost::array, and if you need a sparse array or any > other sort you can build that too and they will all work with the > standard algorithms and you can switch out one for another with little > effort. First, that all will be templates, I do not want them, generics are inherently bad. For instance, it is impossible to have generic programming on containers of containers. You cannot have a list of items of "array" types that are different instantiations. Because see above, you have no that common abstract predecessor. That "arrays" are not arrays, we are just fooling ourselves. Secondly it is not checked whether the thing you are implementing *is* an array which *will* work with all that standard algorithms. You never know before you instantiate. Ideologically, it is stone age, not the Ada's way, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 8:20 ` Dmitry A. Kazakov @ 2004-09-28 23:26 ` Robert Kawulak 2004-09-29 12:19 ` Dmitry A. Kazakov 2004-09-29 15:44 ` Matthew Heaney 0 siblings, 2 replies; 229+ messages in thread From: Robert Kawulak @ 2004-09-28 23:26 UTC (permalink / raw) Hi, > First, that all will be templates, I do not want them, generics are > inherently bad. For instance, it is impossible to have generic programming > on containers of containers. You cannot have a list of items of "array" > types that are different instantiations. I don't know about Ada, but in C++ you can, and such "templates nesting" is even the recommended way to have multi-dimensional vectors: typedef vector< vector < vector <int> > > vector_int_3D; > Secondly it is not checked whether the thing you are implementing *is* an > array which *will* work with all that standard algorithms. You never know > before you instantiate. > Ideologically, it is stone age, not the Ada's way, > IMO. C++ templates are not checked only when instantiated. Every template body is parsed, whether it's instantiated anywhere or not (this is why there is the typename keyword). That's as to grammar correctness. And if you mean semantics, I don't thing Ada compiler will check them for you as well... You also have to write some program using generic instantiations to test whether they work as you expect them to do. Best regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 23:26 ` Robert Kawulak @ 2004-09-29 12:19 ` Dmitry A. Kazakov 2004-09-30 18:52 ` Robert Kawulak 2004-09-29 15:44 ` Matthew Heaney 1 sibling, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-29 12:19 UTC (permalink / raw) On Wed, 29 Sep 2004 01:26:39 +0200, Robert Kawulak wrote: >> First, that all will be templates, I do not want them, generics are >> inherently bad. For instance, it is impossible to have generic programming >> on containers of containers. You cannot have a list of items of "array" >> types that are different instantiations. > > I don't know about Ada, but in C++ you can, and such "templates nesting" > is even the recommended way to have multi-dimensional vectors: > > typedef vector< vector < vector <int> > > vector_int_3D; It is another thing. What I meant is that you cannot have a vector containing elements of vector<int>, vector<unsigned>, vector<long> etc. vector<A> and vector<B> are unrelated types even if A is a descendant of B or related to B. What do you want from a macro extension? (:-)) >> Secondly it is not checked whether the thing you are implementing *is* an >> array which *will* work with all that standard algorithms. You never know >> before you instantiate. >> Ideologically, it is stone age, not the Ada's way, >> IMO. > > C++ templates are not checked only when instantiated. Every template > body is parsed, whether it's instantiated anywhere or not (this is why there > is the typename keyword). > That's as to grammar correctness. And if you mean semantics, I don't > thing Ada compiler will check them for you as well... You also have to write > some program using generic instantiations to test whether they work as you > expect them to do. No, Ada generics have contracts. It means that when you write: generic type X is private; procedure Foo (Object : in out X); it is not same as template <class X> void Foo (X& Object); because then you cannot refer Baz defined on X in Foo. Baz is not in the contract. So you need not to write any test, the Foo will not compile. You have to add Baz to the contract: generic type X is private; with procedure Baz (Object : in out X); procedure Foo (Object : in out X); Similarly with arrays: generic type Index is ... type Element is ... type Vector is array (Index range <>) of Element; procedure Foo (Container : in out Vector); Vector here is an array not because it has ()-operation, but because it conforms to the array interface. When you write an implementation of Foo you can rely on this and only this, nothing else. It is far away from C++ ideology of templates. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 12:19 ` Dmitry A. Kazakov @ 2004-09-30 18:52 ` Robert Kawulak 2004-10-01 7:55 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-30 18:52 UTC (permalink / raw) Hi there! > What I meant is that you cannot have a vector > containing elements of vector<int>, vector<unsigned>, vector<long> etc. > vector<A> and vector<B> are unrelated types even if A is a descendant of B > or related to B. What do you want from a macro extension? (:-)) Whoops! So in my answer for Matthew Heaney's post I've misunderstood you again :-/ But yes, it *is* possible to have such vector, similarly to my example in mentioned answer (of course the code would need a few changes, it could be even simplier). But I'm wondering what in the world would you need such a vector for? ;-) > No, Ada generics have contracts. I see. But you can also have contracts for template parameters in C++. They aren't a core language construct like in Ada (and their use is a little bit less simple), but because of this they can be much more flexible. For details, have a look at boost::concept_check and boost::type_traits (http://www.boost.org). Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-30 18:52 ` Robert Kawulak @ 2004-10-01 7:55 ` Dmitry A. Kazakov 2004-10-03 19:35 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-01 7:55 UTC (permalink / raw) On Thu, 30 Sep 2004 20:52:21 +0200, Robert Kawulak wrote: >> What I meant is that you cannot have a vector >> containing elements of vector<int>, vector<unsigned>, vector<long> etc. >> vector<A> and vector<B> are unrelated types even if A is a descendant of B >> or related to B. What do you want from a macro extension? (:-)) > > Whoops! So in my answer for Matthew Heaney's post I've misunderstood you > again :-/ > But yes, it *is* possible to have such vector, similarly to my example > in mentioned answer (of course the code would need a few changes, it could > be even simplier). But I'm wondering what in the world would you need such a > vector for? ;-) It is no matter. The problem is fundamental, if vector<A> and vector<B> as types have nothing in common, then it is difficult to write a program which can work with both. It is all about generic programming. That is not necessarily programming using generics or templates, that is programming with *sets* of types. Array types is an example of such set, "vector<>" is another. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-01 7:55 ` Dmitry A. Kazakov @ 2004-10-03 19:35 ` Robert Kawulak 2004-10-04 10:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-03 19:35 UTC (permalink / raw) Hi, > The problem is fundamental, if vector<A> and vector<B> as > types have nothing in common, then it is difficult to write a program > which can work with both. It is all about generic programming. But I'm still trying to figure out what problems does this entail (and why, in this respect, Ada arrays could be better than all array types in C++, which is what this discussion was about). My understanding is that vector<A> and vector<B> (or Ada arrays of elements of these types) *must* be different types because A and B are different types. Of course they've got some common properties and methods independent on the type of held elements like the number of elements, but I don't see any difficulties connected with this - all vector classes have the same interface, so it's easy to write a code that copes with vectors of elements of different types. Could you clarify this (or at least give some links concerning generic programming issues you are writing about)? Thanks. Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-03 19:35 ` Robert Kawulak @ 2004-10-04 10:24 ` Dmitry A. Kazakov 2004-10-06 17:28 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-04 10:24 UTC (permalink / raw) On Sun, 3 Oct 2004 21:35:22 +0200, Robert Kawulak wrote: >> The problem is fundamental, if vector<A> and vector<B> as >> types have nothing in common, then it is difficult to write a program >> which can work with both. It is all about generic programming. > > But I'm still trying to figure out what problems does this entail (and > why, in this respect, Ada arrays could be better than all array types in > C++, which is what this discussion was about). I didn't say that Ada get it solved. I think that Ada is on the right way there, while C++ moves in the opposite direction. > My understanding is that > vector<A> and vector<B> (or Ada arrays of elements of these types) *must* be > different types because A and B are different types. They need not to be. To be honest, in Ada you cannot put a constraint on array's element type, but you can do it for the index type. For the discussion, there is no much difference what to constrain/derive from. When you use a template, say: <int From_Index, int To_Index, class Element>, then different values of From_Index, To_Index constitute different types of instances. It is unacceptable. This was solved in Ada 83. It has a notion of array type which can be constrained (the set of all possible constraints gives that desired ARRAY types set): type String is array (Integer range <>) of Character; subtype Subrange is Integer range 1..20; subtype Substring is String (Subrange); -- String and Substring are related types. You can program for Substring -- in terms of String. Yes, Ada does not have it for array elements. You cannot derive from the element type and get the array of derived elements a subtype of the array of element. Neither you can dispatch on subtypes etc. But if you have arrays you could fix it some day... > Of course they've got > some common properties and methods independent on the type of held elements > like the number of elements, but I don't see any difficulties connected with > this - all vector classes have the same interface, This "same interface" is not a language object. It is a fiction, which cannot be described in language terms independently on its implementation. So you physically unable to program in terms of this interface. It simply does not exist. What can you do with vector<>? Operator[] defined on it is not a function. It is a template function. You cannot call it outside of another template. That template must in turn have the vector's element type as a parameter etc. > so it's easy to write a code that copes with vectors of > elements of different types. Really? Write code which reads from the stream a type X (from some defined, but large set of types) and then returns empty vector<X>. > Could you clarify this (or at least give some links concerning generic > programming issues you are writing about)? Stepanov? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-04 10:24 ` Dmitry A. Kazakov @ 2004-10-06 17:28 ` Robert Kawulak 2004-10-07 8:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-06 17:28 UTC (permalink / raw) Hi, > This "same interface" is not a language object. It is a fiction, which > cannot be described in language terms independently on its implementation. > So you physically unable to program in terms of this interface. It simply > does not exist. It's not a fiction, it's a kind of agreement. The language doesn't see this interface directly, but you can use it. And if you try to violate it in a place where conformance to this interface is crucial, your program won't compile. > What can you do with vector<>? Operator[] defined on it is > not a function. It is a template function. Function template, you mean ;-) > You cannot call it outside of > another template. That template must in turn have the vector's element > type > as a parameter etc. So what? You just make a template instead of a function and the job is done. In all the places you call this template function, a compiler generates appropriate function from your template looking at the type of it's arguments, and that's it. >> so it's easy to write a code that copes with vectors of >> elements of different types. > > Really? Write code which reads from the stream a type X (from some > defined, > but large set of types) and then returns empty vector<X>. Of course this can be done (Turing complete... ;-), but this is a very different kind of problem, isn't it? It's just like reading a type X and returning an object of type X. I don't think this would be much simpler if std::vector<> was implemented as runtime-polymorphic, not using generics. Of course there's the need to create a runtime-polymorphic wrapper class for std::vector<>, but the problem of choosing the appropriate type from a large set given this type's name as a string is the same in both cases. Besides can you do this better in Ada than in C++? (Or it wasn't your point to compare C++ with Ada in this respect, just to compare runtime vs. static polymorphism?) > Stepanov? (:-)) Could you give some references (links, book titles...)? I became curious (but it doesn't mean you've already convinced me ;-). With regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-06 17:28 ` Robert Kawulak @ 2004-10-07 8:24 ` Dmitry A. Kazakov 2004-10-10 21:09 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-07 8:24 UTC (permalink / raw) On Wed, 6 Oct 2004 19:28:31 +0200, Robert Kawulak wrote: >> This "same interface" is not a language object. It is a fiction, which >> cannot be described in language terms independently on its implementation. >> So you physically unable to program in terms of this interface. It simply >> does not exist. > > It's not a fiction, it's a kind of agreement. The language doesn't see > this interface directly, but you can use it. And if you try to violate it in > a place where conformance to this interface is crucial, your program won't > compile. Yes. For *you*, it is not a fiction, because you know its semantics. The problem is how you communicate your personal percept of semantics to other people. It is what a language all about... >> What can you do with vector<>? Operator[] defined on it is >> not a function. It is a template function. > > Function template, you mean ;-) R-r-right! (:-)) >> You cannot call it outside of >> another template. That template must in turn have the vector's element >> type as a parameter etc. > > So what? You just make a template instead of a function and the job is > done. In all the places you call this template function, a compiler > generates appropriate function from your template looking at the type of > it's arguments, and that's it. But this is what I meant. Templates constitute a meta-language. That is inherently bad, provided there is a way to solve the problem within the native language (maintaining a reasonable level of expressiveness). This argument will stand even if templates became run-time things, which are not, making the solution even worse. BTW, Stepanov's point against OO and dynamic polymorphism was that he could not do generic programming with it. I believe he was wrong. >>> so it's easy to write a code that copes with vectors of >>> elements of different types. >> >> Really? Write code which reads from the stream a type X (from some >> defined, but large set of types) and then returns empty vector<X>. > > Of course this can be done (Turing complete... ;-), but this is a very > different kind of problem, isn't it? It's just like reading a type X and > returning an object of type X. Yes. The problem is that 1) it happens at run-time, 2) you have to name the result type. > I don't think this would be much simpler if > std::vector<> was implemented as runtime-polymorphic, not using generics. Of > course there's the need to create a runtime-polymorphic wrapper class for > std::vector<>, but the problem of choosing the appropriate type from a large > set given this type's name as a string is the same in both cases. Besides > can you do this better in Ada than in C++? Yes, the infrastructure is ready. Ada has S'Class'Input attribute (ARM 13.13.2) which represents a factory pattern. Basically it reads the type tag from stream and then dispatches to an appropriate constructor, which is *guaranteed* to exist. The result is a class-wide object. Unfortunately it works only with tagged types, which do not include "true" arrays. But nothing prevents us from making arrays tagged, if I only could convince Ada community that this is necessary (:-)). > (Or it wasn't your point to > compare C++ with Ada in this respect, just to compare runtime vs. static > polymorphism?) Both. >> Stepanov? (:-)) > > Could you give some references (links, book titles...)? http://www.sgi.com/tech/stl/drdobbs-interview.html http://c2.com/cgi/wiki?GenericProgramming > I became curious (but it doesn't mean you've already convinced me ;-). You are not the only one, whom I cannot convince... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-07 8:24 ` Dmitry A. Kazakov @ 2004-10-10 21:09 ` Robert Kawulak 2004-10-11 8:08 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-10 21:09 UTC (permalink / raw) Hi, >>> This "same interface" is not a language object. It is a fiction, which >>> cannot be described in language terms independently on its >>> implementation. >>> So you physically unable to program in terms of this interface. It >>> simply >>> does not exist. >> >> It's not a fiction, it's a kind of agreement. The language doesn't see >> this interface directly, but you can use it. And if you try to violate it >> in >> a place where conformance to this interface is crucial, your program >> won't >> compile. > > Yes. For *you*, it is not a fiction, because you know its semantics. The > problem is how you communicate your personal percept of semantics to other > people. It is what a language all about... Similarily, I could say that Ada has no classes. Of course it has packages, tagged records etc. but no true classes with true methods. Classes in Ada are just as fictious as interfaces in C++ template metalanguage, yet it doesn't mean you can't use OOP in Ada (and interfaces for templates in C++). > Templates constitute a meta-language. That is > inherently bad, provided there is a way to solve the problem within the > native language (maintaining a reasonable level of expressiveness). I'm afraid that our discussion will never reach its conclusion ;-) The reason is our opposite approach to templates and using them to implement containers. Of course everything that is done using templates may be as well done without them (although not always so easily). The point is that in many cases they simplify the design and, what is crucial for C++, they provide containers with efficiency. There's no need for dynamic binding, wrappers and those ugly downcasts :-P. Statically and dynamically polymorphic containers are just two different points of view, two different philosophies. It's nearly impossible to objectively say which one is the proper, for it depends on what is important to you. Both approaches have pros and cons (as we both tried to show in all our posts) and both aren't ideal in all cases. I think C++ chose the templates approach because it's closer to C++'s 'spirit' (don't pay for what you don't use, make built-in and UDTs the same etc). For contrary, Java has taken the opposite approach. And you are forced to use dynamic dispatching and downcasting, which doesn't sound attractive to me (at least you don't need wrappers, because Java object hierarchy is single-rooted). Anyway, I promise to have a look at the links you've provided (thanks), I'm sure I'll learn something new. > Ada has S'Class'Input attribute (ARM > 13.13.2) which represents a factory pattern. Basically it reads the type > tag from stream and then dispatches to an appropriate constructor, which > is > *guaranteed* to exist. The result is a class-wide object. Good to know ;-) Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-10 21:09 ` Robert Kawulak @ 2004-10-11 8:08 ` Dmitry A. Kazakov 2004-10-15 9:34 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-11 8:08 UTC (permalink / raw) On Sun, 10 Oct 2004 23:09:24 +0200, Robert Kawulak wrote: >> Yes. For *you*, it is not a fiction, because you know its semantics. The >> problem is how you communicate your personal percept of semantics to other >> people. It is what a language all about... > > Similarily, I could say that Ada has no classes. Of course it has > packages, tagged records etc. but no true classes with true methods. Classes > in Ada are just as fictious as interfaces in C++ template metalanguage, yet > it doesn't mean you can't use OOP in Ada (and interfaces for templates in > C++). Yes, Ada does not have OO-ish classes. Whatever is usually meant under OO "class" is either rubbish or just another name for type. Ada's classes (T'Class) are type closures. >> Templates constitute a meta-language. That is >> inherently bad, provided there is a way to solve the problem within the >> native language (maintaining a reasonable level of expressiveness). > > I'm afraid that our discussion will never reach its conclusion ;-) The > reason is our opposite approach to templates and using them to implement > containers. Of course everything that is done using templates may be as well > done without them (although not always so easily). The point is that in many > cases they simplify the design and, what is crucial for C++, they provide > containers with efficiency. There is a broader picture. Consider parametrization in general, as a tool for generic programming. The generic algorithms are represented as operations defined on the sets of types. Sets of types are obtained by varying the parameter or parameters. In this view C++ templates where the parameter is a string containing either name of a type or an integer literal is just a tiny stain on the face of the universe! (:-)) There are other, more structured and controllable ways of parametrization. For example, 1) we all know built-in unconstrained arrays in languages like Ada. They are parametrized by index bounds. 2) Ada 83 introduced type discriminants and subtyping based on constraining discriminants. 3) OO languages provide dynamically polymorphic types, were the specific type(s) plays the role of the varying parameter (type tag, vtable etc). > There's no need for dynamic binding, wrappers > and those ugly downcasts :-P. Statically and dynamically polymorphic > containers are just two different points of view, two different > philosophies. They are not so different, see above. > It's nearly impossible to objectively say which one is the > proper, for it depends on what is important to you. Both approaches have > pros and cons (as we both tried to show in all our posts) and both aren't > ideal in all cases. I think C++ chose the templates approach because it's > closer to C++'s 'spirit' (don't pay for what you don't use, make built-in > and UDTs the same etc). I think #define is even more in C++'s spirit. Note also how simple and effective it is! (:-)) > For contrary, Java has taken the opposite approach. > And you are forced to use dynamic dispatching and downcasting, which doesn't > sound attractive to me (at least you don't need wrappers, because Java > object hierarchy is single-rooted). Need of donwcasting just highlights language design faults. There are also, similar cases in Ada, alas. Yes, ADT in its present state is unsuitable for building a decent container library. But that does not mean that it never be... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-11 8:08 ` Dmitry A. Kazakov @ 2004-10-15 9:34 ` Robert Kawulak 2004-10-15 16:58 ` Martin Krischik 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-15 9:34 UTC (permalink / raw) Hi, > I think #define is even more in C++'s spirit. Note also how simple and > effective it is! (:-)) I don't think so, many people (including Bjarne S.) were actually considering removal of preprocessor from C++ quite seriously... Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-15 9:34 ` Robert Kawulak @ 2004-10-15 16:58 ` Martin Krischik 0 siblings, 0 replies; 229+ messages in thread From: Martin Krischik @ 2004-10-15 16:58 UTC (permalink / raw) Robert Kawulak wrote: > Hi, > >> I think #define is even more in C++'s spirit. Note also how simple and >> effective it is! (:-)) > > I don't think so, many people (including Bjarne S.) were actually > considering removal of preprocessor from C++ quite seriously... Sad that they did not. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 23:26 ` Robert Kawulak 2004-09-29 12:19 ` Dmitry A. Kazakov @ 2004-09-29 15:44 ` Matthew Heaney 2004-09-30 18:27 ` Robert Kawulak 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 15:44 UTC (permalink / raw) "Robert Kawulak" <tigrisek@interia.pl> wrote in message news:cje1hj$jkh$1@nemesis.news.tpi.pl... > > I don't know about Ada, but in C++ you can, and such "templates nesting" > is even the recommended way to have multi-dimensional vectors: > > typedef vector< vector < vector <int> > > vector_int_3D; Typically, you'd use a 3-dimensional array: type Array_Type is array (Positive range <>, Positive range <>, Positive range <>) of Integer; Of course, you can pass the type made available via an instantiation of a generic package as the actual type of some other instantiation. The container libraray for Ada 2005 (see AI-302) was specially designed to allow a container as the element of another container. So you could say: package IV is new Ada.Containers.Vectors (Positive, Integer); package IVV is new A.C.V (Positive, IV.Vector); package IVVV is new A.C.V (Positive, IVV.Vector); You'd probably want to declare a local wrapper function to give you a nice syntax for selecting an element: V : IVVV.Vector; function E (I, J, K : Positive) return Integer is ...; begin N := E (1, 2, 3); ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 15:44 ` Matthew Heaney @ 2004-09-30 18:27 ` Robert Kawulak 0 siblings, 0 replies; 229+ messages in thread From: Robert Kawulak @ 2004-09-30 18:27 UTC (permalink / raw) Hi, >> I don't know about Ada, but in C++ you can, and such "templates > nesting" [...] > Of course, you can pass the type made available via an instantiation of a > generic package as the actual type of some other instantiation. The > container libraray for Ada 2005 (see AI-302) was specially designed to > allow a container as the element of another container. Thanks for clarification. So returning to what Dmitry has written: Dmitry > For instance, it is impossible to have generic programming Dmitry > on containers of containers. You cannot have a list of items of Dmitry > "array" types that are different instantiations. Because see above, Dmitry > you have no that common abstract predecessor. That "arrays" are not Dmitry > arrays, we are just fooling ourselves. I think I see now what Dmitry was trying to say: you cannot have a list of "arrays" such that one its element will be of type std::vector<int>, the other of std::valarray<int> and so on. Do I understand you well, Dmitry? If yes, then I admit: it can't be done directly. But it *doesn't* mean it's impossible! Have a look at this: /*************************************************/ #include <cstddef> using std::size_t; #include <list> using std::list; #include <vector> using std::vector; #include <map> using std::map; // STEP 1: // Helper template for getting element // and index type of an array type. ArrayTraits // is meant to be specialised for any concrete // array type. template<typename ArrayT> struct ArrayTraits { typedef ArrayT ArrayType; }; // struct ArrayTraits<> // Specialisation for std::vector<> template<typename ElementT> struct ArrayTraits< vector<ElementT> > { typedef typename vector<ElementT> ArrayType; typedef typename ArrayType::value_type ElementType; typedef typename ArrayType::size_type IndexType; }; // struct ArrayTraits< vector<ElementT> > // Specialisation for std::map<> template<typename ElementT, typename IndexT> struct ArrayTraits< map<IndexT, ElementT> > { typedef typename map<IndexT, ElementT> ArrayType; typedef typename ArrayType::mapped_type ElementType; typedef typename ArrayType::key_type IndexType; }; // struct ArrayTraits< map<IndexT, ElementT> > // Specialisation for C-style arrays template<typename ElementT> struct ArrayTraits<ElementT[]> { typedef ElementT ArrayType[]; typedef ElementT ElementType; typedef size_t IndexType; }; // struct ArrayTraits<ElementT[]> // STEP 2: // Abstract base class for the wrapper of any // array type (here we assume that array type // is any type having [] operator) template<typename ElementType, typename IndexType> struct ArrayWrapperBase { virtual ElementType & operator [] (const IndexType & ) = 0; // ...Possibly some other array-specific operations... virtual ~ArrayWrapperBase() {} }; // struct ArrayWrapperBase<> // STEP 3: // The wrapper class template template<typename ArrayType> struct ArrayWrapper: public ArrayWrapperBase< typename ArrayTraits<ArrayType>::ElementType, typename ArrayTraits<ArrayType>::IndexType > { typedef typename ArrayTraits<ArrayType>::ElementType ElementType; typedef typename ArrayTraits<ArrayType>::IndexType IndexType; ArrayType & mArray; // reference to actual array object ArrayWrapper(ArrayType & A): mArray(A) {} ElementType & operator [] (const IndexType & i) { return mArray[i]; }; }; // struct ArrayWrapper<> // STEP 4: // Use! int main() { vector<int> AVector(10); ArrayWrapper< vector<int> > WrappedVector(AVector); map<size_t, int> AMap; ArrayWrapper< map<size_t, int> > WrappedMap(AMap); int AnArray[10]; ArrayWrapper< int[] > WrappedArray(AnArray); typedef list<ArrayWrapperBase<int, size_t> *> ListOfArrays; ListOfArrays MyList; // list of arrays of any kind holding ints // creme de la creme: MyList.push_back(&WrappedVector); MyList.push_back(&WrappedMap); MyList.push_back(&WrappedArray); // the three instructions are equivalent: AVector[7] = 27182; WrappedVector[7] = 27182; (*MyList.front())[7] = 27182; // setting 5-th element of every array to 31415: for(ListOfArrays::iterator i = MyList.begin(); i != MyList.end(); i++) (**i)[4] = 31415; } // main() /*************************************************/ Long and complicated? Indeed. But on the other hand I have never heard of anybody who needed this. Yet it's possible ;-). Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 15:05 ` Dmitry A. Kazakov 2004-09-28 4:22 ` Kevin Cline @ 2004-09-28 17:21 ` Robert Kawulak 2004-09-29 1:38 ` Georg Bauhaus 2004-09-29 8:08 ` Dmitry A. Kazakov 1 sibling, 2 replies; 229+ messages in thread From: Robert Kawulak @ 2004-09-28 17:21 UTC (permalink / raw) Hi, > Note that C++ does not solve the > problem, because it has no arrays. What exactly do you mean by that? I suppose it's some kind of metaphore... Of course C++ has got arrays inherited from C which are the core language construct, and std::vector<> which is safe and dynamic-sized version of an array. > So it allows you to define [] and leaves > you alone with that. It is not the Ada's way (TM). Again I don't see your point here... As to the C++(R) std::vector<>, there is operator [] defined. Best regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 17:21 ` Robert Kawulak @ 2004-09-29 1:38 ` Georg Bauhaus 2004-09-29 18:08 ` Robert Kawulak 2004-09-29 8:08 ` Dmitry A. Kazakov 1 sibling, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-09-29 1:38 UTC (permalink / raw) Robert Kawulak <tigrisek@interia.pl> wrote: : : Of course C++ has got arrays inherited from C which are the core language : construct, Prior to C99, functions had no means to know how many floats there were in the "array" argument: float foo(float a[]); The article "Array Variables" by Dijkstra might be interesting. As an addition in Ada, you can specify the type, and therefore the range, of discrete values that can be used as index values. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 1:38 ` Georg Bauhaus @ 2004-09-29 18:08 ` Robert Kawulak 2004-09-30 18:30 ` Georg Bauhaus 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-29 18:08 UTC (permalink / raw) Hi, > : Of course C++ has got arrays inherited from C which are the core > language > : construct, > > Prior to C99, functions had no means to know how many > floats there were in the "array" argument: > > float foo(float a[]); And that's where the second part of the quoted sentence applies: "and std::vector<> (...)". In C++, C-style arrays are really meant to be used mostly for "low-level of abstraction" coding. And the recommended way to solve your problem is: float foo(float a[], size_t a_size); But please don't tell me this is ugly and error-prone etc. It *is*, that's why there are std::vector<> and std::valarray<>. Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 18:08 ` Robert Kawulak @ 2004-09-30 18:30 ` Georg Bauhaus 0 siblings, 0 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-30 18:30 UTC (permalink / raw) Robert Kawulak <tigrisek@interia.pl> wrote: : : And the recommended way to : solve your problem is: : : float foo(float a[], size_t a_size); I don't have a problem, as I can use either languages that do have arrays, or languages that have libraries providing array like data types. :-) Only, C++ has not inherited arrays, that's because C doesn't have arrays in some sense. -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 17:21 ` Robert Kawulak 2004-09-29 1:38 ` Georg Bauhaus @ 2004-09-29 8:08 ` Dmitry A. Kazakov 2004-09-29 18:11 ` Robert Kawulak 1 sibling, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-29 8:08 UTC (permalink / raw) On Tue, 28 Sep 2004 19:21:04 +0200, Robert Kawulak wrote: >> Note that C++ does not solve the >> problem, because it has no arrays. > > What exactly do you mean by that? I suppose it's some kind of metaphore... > > Of course C++ has got arrays inherited from C which are the core language > construct, and std::vector<> which is safe and dynamic-sized version of an > array. Pointers are not arrays. >> So it allows you to define [] and leaves >> you alone with that. It is not the Ada's way (TM). > > Again I don't see your point here... As to the C++(R) std::vector<>, there > is operator [] defined. An ability to index is just one of many array properties. The whole list is very large. Provocatively, I would claim that an instance of std::vector is not an array. For a type to be an array means that the language has some kind of array interface defined and thus it can check a type against that interface to verify whether the type implements the interface. There is no such thing in C++. You can claim that the template std::vector defines such array, but then what would you do with My_Template_Array designed independently on std::vector? It will not be an array then! BTW, Ada's Unbounded_String is *not* an array, alas. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 8:08 ` Dmitry A. Kazakov @ 2004-09-29 18:11 ` Robert Kawulak 2004-09-30 8:57 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-09-29 18:11 UTC (permalink / raw) Hi, >>> Note that C++ does not solve the >>> problem, because it has no arrays. [...] >> Of course C++ has got arrays inherited from C which are the core language >> construct [...] > Pointers are not arrays. Ah, now I see what you meant! ;-) >>> So it allows you to define [] and leaves >>> you alone with that. It is not the Ada's way (TM). >> >> Again I don't see your point here... As to the C++(R) std::vector<>, >> there >> is operator [] defined. > > An ability to index is just one of many array properties. The whole list > is > very large. As well as the list of methods and operators and other members of std::vector<>... What particular thing are you missing there? > Provocatively, ;-P > I would claim that an instance of std::vector is not an > array. For a type to be an array means that the language has some kind of > array interface defined and thus it can check a type against that > interface > to verify whether the type implements the interface. There is no such > thing > in C++. There is - C arrays. But the definition you wrote shows that you still think the Ada way (TM) - in C++ (R) built-in types and user-defined types are treated the same way. Why you think that it is necessary for the core language to know what is an array and what isn't? In Ada, you can't use anything else than built-in array exactly as an array. In C++ you can. > You can claim that the template std::vector defines such array, > but > then what would you do with My_Template_Array designed independently on > std::vector? It will not be an array then! The Ada way, again - who says there can be one and only one type representing an array? In C++you have C arrays, std::vector<>, std::valarray<> and even std::string - and all these can be treated in uniform way as arrays. > BTW, Ada's Unbounded_String is *not* an array, alas. Fortunately std::string might be considered as a container, which you may use like std::vector<char> in most cases. ;-) Best regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 18:11 ` Robert Kawulak @ 2004-09-30 8:57 ` Dmitry A. Kazakov [not found] ` <cji06f$17a$2@atlantis.news.tpi.pl> 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-09-30 8:57 UTC (permalink / raw) On Wed, 29 Sep 2004 20:11:46 +0200, Robert Kawulak wrote: >>>> So it allows you to define [] and leaves >>>> you alone with that. It is not the Ada's way (TM). >>> >>> Again I don't see your point here... As to the C++(R) std::vector<>, >>> there >>> is operator [] defined. >> >> An ability to index is just one of many array properties. The whole list >> is very large. > > As well as the list of methods and operators and other members of > std::vector<>... What particular thing are you missing there? Slices (subarrays), ranges (index subsets), aggregates (literal values), looping (automatic iterators), stack allocated arrays ... >> Provocatively, > > ;-P > >> I would claim that an instance of std::vector is not an >> array. For a type to be an array means that the language has some kind of >> array interface defined and thus it can check a type against that >> interface >> to verify whether the type implements the interface. There is no such >> thing >> in C++. > > There is - C arrays. But the definition you wrote shows that you still think > the Ada way (TM) - in C++ (R) built-in types and user-defined types are > treated the same way. Types yes, array types not. That's the point not any type is array type. You are arguing in terms of types, try to go one step up. Array types is a set of types. > Why you think that it is necessary for the core > language to know what is an array and what isn't? In Ada, you can't use > anything else than built-in array exactly as an array. In C++ you can. You get me wrong. I do not argue in favor of built-in arrays. I argue for an ability to have abstract array interfaces either user-defined or built-in, no matter. C++ does not have them and its template mechanism does not help here (*). Ada has them built-in, but does not allow to implement an array by, say, a record type. >> You can claim that the template std::vector defines such array, >> but then what would you do with My_Template_Array designed independently on >> std::vector? It will not be an array then! > > The Ada way, again - who says there can be one and only one type > representing an array? In C++you have C arrays, std::vector<>, > std::valarray<> and even std::string - and all these can be treated in > uniform way as arrays. You mean operator[] here. As I said before, it is not enough. >> BTW, Ada's Unbounded_String is *not* an array, alas. > > Fortunately std::string might be considered as a container, which you may > use like std::vector<char> in most cases. ;-) Can you use it *as* std::vector<char>? No, they are two different *unrelated* types. Same as in Ada, where Unbounded_String can be used *like*, but not *as* String. ------------ (*) The meta-language of C++ templates is untyped. So you cannot define a set of types "Array_Containers" and require its instance (an array) as a template parameter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
[parent not found: <cji06f$17a$2@atlantis.news.tpi.pl>]
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) [not found] ` <cji06f$17a$2@atlantis.news.tpi.pl> @ 2004-10-01 8:58 ` Dmitry A. Kazakov 2004-10-03 19:53 ` Robert Kawulak 2004-10-01 13:02 ` Robert Kawulak 2004-10-28 10:26 ` Larry Kilgallen 2 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-01 8:58 UTC (permalink / raw) On Fri, 1 Oct 2004 00:06:34 +0200, Robert Kawulak wrote: >>>> An ability to index is just one of many array properties. The whole list >>>> is very large. >>> As well as the list of methods and operators and other members of >>> std::vector<>... What particular thing are you missing there? > >> Slices (subarrays), ranges (index subsets), > > std::slice_array<>, std::gslice_array<>, std::indirect_array<>, > std::mask_array<> (all used with std::valarray<>) > > The std::valarray<> class has more limitations on the held type than > std::vector<>, but it is designed to be very efficient for such operations. In Ada slices are ad-hoc anonymous types, it is how that should be. Because if you want to work with array slices in a subprogram, you definitely do not want to pass all necessary helper types down there. In Ada you just write A(10..I) and the job is done. In C++ there is no mechanism to get related types out of objects and other types (except pointers T* and references T&). [Yes you can get this in C++, I believe you, it is all Turing complete after all! (:-))] >> looping (automatic iterators), > > std::for_each algorithm and the like... (especially useful with > boost::lambda) In Ada: for Index in A'Range loop ... end loop; Here the iterator type and its constraint are constructed out of the object. Feel the difference! >>> Why you think that it is necessary for the core >>> language to know what is an array and what isn't? In Ada, you can't use >>> anything else than built-in array exactly as an array. In C++ you can. >> You get me wrong. I do not argue in favor of built-in arrays. I argue for >> an ability to have abstract array interfaces either user-defined or >> built-in, no matter. C++ does not have them and its template mechanism >> does >> not help here (*). Ada has them built-in, but does not allow to implement >> an array by, say, a record type. > > I see your point. When designing containers in std library, its creators had > two possibilities to choose from: > 1. Make all the containers polymorphic, > 2. Make all the containers use consequent naming of members and make all the > algorithms templated. > They have choosen 2, because it's far more efficient (no virtual calls, many > bindings resolved at compile time and even inlined) and far more flexible. Far less flexible you mean. 2 is called statically polymorphic, while 1 is just polymorphic. Clearly 2 is a part of 1. Nothing prevents the compiler to remove dispatch if the target is statically known. > This is why C++ has no abstract interface. Instead, counterpart functions in > all the containers are named in a uniform way, and this is their > "interface", but in the terms of template metaprogramming. Right. Their fault is that these interfaces though exist, are anonymous and uncheckable. In Ada they are named and checkable. This is why C++'s template interfaces are untyped. Ada's generic interfaces are typed, but do not have any ADT. It is like FORTRAN-IV against Algol contest in 2004. (:-)) >> Can you use it *as* std::vector<char>? No, they are two different >> *unrelated* types. Same as in Ada, where Unbounded_String can be used >> *like*, but not *as* String. > > But this is where the "template metaprogramming" stuff applies - you can't > use it directly as string, but you can make a template metafunction which in > turn can take vector<char> or string or something else as its metaargument. > And in this metafunction you may use them in the same manner - this is what > I meant. No you cannot, when you have to mix them. If your program needs both vector<char> and string (to copy a part of one into another) then you have to parametrize it twice with two types. Now consider what happens if there are 100 different, yet related types? [To continue the analogy, I'am trying to convince a FORTRAN-IV programmer that there could be something beyond REAL*4 and REAL*8. (:-))] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-01 8:58 ` Dmitry A. Kazakov @ 2004-10-03 19:53 ` Robert Kawulak 2004-10-04 10:15 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-03 19:53 UTC (permalink / raw) Hi, > In Ada slices are ad-hoc anonymous types, it is how that should be. > Because > if you want to work with array slices in a subprogram, you definitely do > not want to pass all necessary helper types down there. In Ada you just > write A(10..I) and the job is done. In C++ you may write std::vector(V.begin + 9, V.begin() + I) and this is also anonymous object which is subvector of another vector V. Or you can pass only iterators and the job is done better, because there's no copying of elements and you can operate on any container, not only on a vector. > [Yes you can get this in C++, I believe you, it is all Turing complete > after all! (:-))] :))) >> std::for_each algorithm and the like... (especially useful with >> boost::lambda) > > In Ada: > > for Index in A'Range loop > ... > end loop; > > Here the iterator type and its constraint are constructed out of the > object. Feel the difference! The only case where Ada is less verbose than C++ ;-) But on the other hand you cannot do this with a list, a map, a deque, nor you can do the following so concisely: std::vector V(10); // Apply SomeFunction to elements [4, 9] in reverse order: std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction); For instance (using boost::lambda) print those elements: // Print elements [4, 9] in reverse order: std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1); Feel the difference! ;-) >> I see your point. When designing containers in std library, its creators >> had >> two possibilities to choose from: >> 1. Make all the containers polymorphic, >> 2. Make all the containers use consequent naming of members and make all >> the >> algorithms templated. >> They have choosen 2, because it's far more efficient (no virtual calls, >> many >> bindings resolved at compile time and even inlined) and far more >> flexible. > > Far less flexible you mean. C++ doesn't have a single-rooted object hierarchy. So if containers weren't templates, they'd have to contain elements of some abstract class, call it CElement. Now, if you want to have a container of elements of some class not derived from CElement or even a container of int, then you'd have to make some wrapper classes - this would cost you a lot of time to make it work with the library. So in this case runtime polymorphism doesn't seem to me to be more flexible than the template solution... > No you cannot, when you have to mix them. If your program needs both > vector<char> and string (to copy a part of one into another) then you have > to parametrize it twice with two types. Now consider what happens if there > are 100 different, yet related types? Nothing happens. ;-) If you have a function template copying elements of one container into another, then it'll work fine even for 100 container types, as long as they use the same interface. Can you specify what do you mean when saying 'mix them'? > [To continue the analogy, I'am trying to convince a FORTRAN-IV programmer > that there could be something beyond REAL*4 and REAL*8. (:-))] I feel the same ;-). But of course the point is not to fight and win, but to learn something. I've already learned a few things from this discussion :). Best regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-03 19:53 ` Robert Kawulak @ 2004-10-04 10:15 ` Dmitry A. Kazakov 2004-10-04 12:16 ` Matthew Heaney 2004-10-06 17:20 ` Robert Kawulak 0 siblings, 2 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-04 10:15 UTC (permalink / raw) On Sun, 3 Oct 2004 21:53:32 +0200, Robert Kawulak wrote: >>> std::for_each algorithm and the like... (especially useful with >>> boost::lambda) >> >> In Ada: >> >> for Index in A'Range loop >> ... >> end loop; >> >> Here the iterator type and its constraint are constructed out of the >> object. Feel the difference! > > The only case where Ada is less verbose than C++ ;-) But on the other > hand you cannot do this with a list, a map, a deque, It is because they are not arrays. But why an ordered list should not implement an array interface? In my view it should, making the above legal for lists. > nor you can do the following so concisely: > > std::vector V(10); > > // Apply SomeFunction to elements [4, 9] in reverse order: > std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction); for Index in reverse V'First + 4..V'Last loop SomeFunction (V (Index)); -- Better to place its body here, if short end loop; > For instance (using boost::lambda) print those elements: > > // Print elements [4, 9] in reverse order: > std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1); > > Feel the difference! ;-) I do! I hate implicit iterators, I prefer loops where possible. Especially, because exit conditions, nested iterations, exception handling become visible. [ Ranting: 40 years spent in developing readable, safe, well-structured language constructs, only to replace them with nested function calls a la Lisp? ] >>> I see your point. When designing containers in std library, its creators >>> had >>> two possibilities to choose from: >>> 1. Make all the containers polymorphic, >>> 2. Make all the containers use consequent naming of members and make all >>> the >>> algorithms templated. >>> They have choosen 2, because it's far more efficient (no virtual calls, >>> many >>> bindings resolved at compile time and even inlined) and far more >>> flexible. >> >> Far less flexible you mean. > > C++ doesn't have a single-rooted object hierarchy. So if containers > weren't templates, they'd have to contain elements of some abstract class, > call it CElement. Now, if you want to have a container of elements of some > class not derived from CElement or even a container of int, then you'd have > to make some wrapper classes - this would cost you a lot of time to make it > work with the library. Yes, unless: 1. (for new types) language supports multiple interface inheritance. C++ does, Ada 2005 will. 2. (for existing types) language supports supertyping. If it does, then creating a wrapper will be a matter of one or two code lines. You create a helper type which is both a subtype of CElement and a supertype of int. > So in this case runtime polymorphism doesn't seem to > me to be more flexible than the template solution... Formally it is more flexible and powerful. The problem is that OO languages like C++ and Ada are much too much concentrated on generics, which are a dead end IMO, instead of investing more efforts in better ADT. >> No you cannot, when you have to mix them. If your program needs both >> vector<char> and string (to copy a part of one into another) then you have >> to parametrize it twice with two types. Now consider what happens if there >> are 100 different, yet related types? > > Nothing happens. ;-) If you have a function template copying elements of > one container into another, then it'll work fine even for 100 container > types, as long as they use the same interface. Which interface you mean? string is an instance of another template. It is not vector<>, and there is no way to make it conform to vector<>, because there is no such thing as "vector interface". > Can you specify what do you mean when saying 'mix them'? All cases were: template <class A, class B> Foo (vector <A>& X, vector <B>& Y) { ... Do_Something (X [I], Y [J]); ... } cannot be replaced with: template <class A> Foo (vector <A>& X, vector <A>& Y) { ... Do_Something (X [I], Y [J]); ... } Technically, you have to factor vector<> out of vector<A>, vector<B>, etc. When you do, that will be the ARRAY. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-04 10:15 ` Dmitry A. Kazakov @ 2004-10-04 12:16 ` Matthew Heaney 2004-10-04 13:21 ` Dmitry A. Kazakov 2004-10-06 17:20 ` Robert Kawulak 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-10-04 12:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > It is because they are not arrays. But why an ordered list should not > implement an array interface? In my view it should, making the above > legal for lists. Stop obsessing about syntax. If you want a consistent interface for containers, you have that in AI-302 (but of course it's not an "array" interface): procedure Op (Container : <container's type>) is C : Cursor := First (Container); begin while Has_Element (C) loop Process (C); --or Process (Element (C)) Next (C); end loop; end Op; Actually, if you intend on iterating over all the elements in a container, the passive iterator is preferred: procedure Op (Container : <containers's type> is begin Container.Iterate (Process'Access); end; If you have an array type, then you can give it a container-like interface for the purpose of binding an array object to a generic algorithm. I showed how to do this in an earlier post. > I do! I hate implicit iterators, I prefer loops where > possible. Especially, because exit conditions, nested iterations, > exception handling become visible. If you intend on traversing every element in the container, then use a passive iterator. It's more efficient, and less error-prone. If you have exit conditions, then go ahead and use an active-iterator style loop. > [ Ranting: 40 years spent in developing readable, safe, well-structured > language constructs, only to replace them with nested function calls a la > Lisp? ] This is a specious comparison. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-04 12:16 ` Matthew Heaney @ 2004-10-04 13:21 ` Dmitry A. Kazakov 0 siblings, 0 replies; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-04 13:21 UTC (permalink / raw) On Mon, 04 Oct 2004 12:16:58 GMT, Matthew Heaney wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> It is because they are not arrays. But why an ordered list should not >> implement an array interface? In my view it should, making the above >> legal for lists. > > Stop obsessing about syntax. Aha, but semantically that all is just a Turing machine. So yes, I am obsessed with syntax. (:-)) > If you want a consistent interface for > containers, you have that in AI-302 (but of course it's not an "array" > interface): > > procedure Op (Container : <container's type>) is > C : Cursor := First (Container); > begin > while Has_Element (C) loop > Process (C); --or Process (Element (C)) > Next (C); > end loop; > end Op; > > Actually, if you intend on iterating over all the elements in a > container, the passive iterator is preferred: > > procedure Op (Container : <containers's type> is > begin > Container.Iterate (Process'Access); > end; > > If you have an array type, then you can give it a container-like > interface for the purpose of binding an array object to a generic > algorithm. I showed how to do this in an earlier post. This is what I think the wrong way is - to use Ada's arrays like STL containers, instead of the reverse. You will probably agree that iteration is a fundamental programming pattern. As such, it IMO deserves a separate language construct rather than being hidden in a subroutine call. >> I do! I hate implicit iterators, I prefer loops where >> possible. Especially, because exit conditions, nested iterations, >> exception handling become visible. > > If you intend on traversing every element in the container, then use a > passive iterator. It's more efficient, and less error-prone. > > If you have exit conditions, then go ahead and use an active-iterator > style loop. Just compare: declare C : Cursor := First (Container); begin while Has_Element (C) loop Process (Element (C)); Next (C); end loop; end; with for C in Container'Range loop Process (Container (C)); end loop; You have to know about Cursor, First, Has_Element, Element and Next only to call Process on each element of a container! [ Don't even try to tell me that First is like 'First etc. Because, being obsessed with syntax, I will reply that then it should be named 'First! (:-)) ] >> [ Ranting: 40 years spent in developing readable, safe, well-structured >> language constructs, only to replace them with nested function calls a la >> Lisp? ] > > This is a specious comparison. I tried hard... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-04 10:15 ` Dmitry A. Kazakov 2004-10-04 12:16 ` Matthew Heaney @ 2004-10-06 17:20 ` Robert Kawulak 2004-10-07 10:08 ` Dmitry A. Kazakov 1 sibling, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-06 17:20 UTC (permalink / raw) Hi, > But why an ordered list should not > implement an array interface? In my view it should, making the above legal > for lists. I think this is a wrong way - list is not a kind of array to implement its interface. But both list and vector are *containers*, and they both have the common container interface - and that's why std::for_each and other std lib algorithms work on any conatiner (be it std::list, std::vector, C-style array or a user-defined type). >> nor you can do the following so concisely: >> >> std::vector V(10); >> >> // Apply SomeFunction to elements [4, 9] in reverse order: >> std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction); > > for Index in reverse V'First + 4..V'Last loop > SomeFunction (V (Index)); -- Better to place its body here, if short > end loop; Sorry, my mistake. :-P I didn't know about this... > [ Ranting: 40 years spent in developing readable, safe, well-structured > language constructs, only to replace them with nested function calls a la > Lisp? ] ;-) >>> Far less flexible you mean. >> >> C++ doesn't have a single-rooted object hierarchy. So if containers >> weren't templates, they'd have to contain elements of some abstract >> class, >> call it CElement. Now, if you want to have a container of elements of >> some >> class not derived from CElement or even a container of int, then you'd >> have >> to make some wrapper classes - this would cost you a lot of time to make >> it >> work with the library. > > Yes, unless: > > 1. (for new types) language supports multiple interface inheritance. C++ > does, Ada 2005 will. 'elements of some class -=#not#=- derived from CElement' - I meant if you can derive, then there's no problem. > 2. (for existing types) language supports supertyping. If it does, then > creating a wrapper will be a matter of one or two code lines. You create a > helper type which is both a subtype of CElement and a supertype of int. And you see, that's the point. I wrote: 'to make it work', and it's not as easy as it seems. In order to work with container algorithms and cooperate with other containers, your wrapper should also implement wrappers for wrapped type's iterators with wrappers for wrapped type's iterators' functions... Doesn't look to me like 'a matter of one or two code lines' ;-) >> If you have a function template copying elements of >> one container into another, then it'll work fine even for 100 container >> types, as long as they use the same interface. > > Which interface you mean? string is an instance of another template. It is > not vector<>, and there is no way to make it conform to vector<>, because > there is no such thing as "vector interface". *container* interface. String is not exactly a vector, but might be treated similarily to one because of it's container-like interface. >> Can you specify what do you mean when saying 'mix them'? > > All cases were: > > template <class A, class B> Foo (vector <A>& X, vector <B>& Y) > { > ... > Do_Something (X [I], Y [J]); > ... > } > > cannot be replaced with: > > template <class A> Foo (vector <A>& X, vector <A>& Y) > { > ... > Do_Something (X [I], Y [J]); > ... > } Wouldn't this do? template <class A, class B> Foo (A & X, B & Y) { ... Do_Something (X [I], Y [J]); ... } Regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-06 17:20 ` Robert Kawulak @ 2004-10-07 10:08 ` Dmitry A. Kazakov 2004-10-10 22:21 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-07 10:08 UTC (permalink / raw) On Wed, 6 Oct 2004 19:20:29 +0200, Robert Kawulak wrote: >> But why an ordered list should not >> implement an array interface? In my view it should, making the above legal >> for lists. > > I think this is a wrong way - list is not a kind of array to implement its > interface. But both list and vector are *containers*, and they both have the > common container interface - and that's why std::for_each and other std lib > algorithms work on any conatiner (be it std::list, std::vector, C-style > array or a user-defined type). In my view, array is a container and container is an abstract array. Iterators should be introduced as index types, subdivided into ordered and unordered ones. For ordered index types you can have ranges. From index types you can build tuples, which depending on whether indices are ordered or not, should allow subranges, projections (diagonals etc). Upon tuples and element types one can build arrays. Subtyping of array types should allow constraining/deriving of both index and element types. >>>> Far less flexible you mean. >>> >>> C++ doesn't have a single-rooted object hierarchy. So if containers >>> weren't templates, they'd have to contain elements of some abstract >>> class, >>> call it CElement. Now, if you want to have a container of elements of >>> some >>> class not derived from CElement or even a container of int, then you'd >>> have >>> to make some wrapper classes - this would cost you a lot of time to make >>> it >>> work with the library. >> >> Yes, unless: >> >> 1. (for new types) language supports multiple interface inheritance. C++ >> does, Ada 2005 will. > > 'elements of some class -=#not#=- derived from CElement' - I meant if you > can derive, then there's no problem. Yes, but differently to C++ in Ada that would cover almost 90% of all cases. The reason is that in Ada we routinely clone/derive predefined types: type Velocity is new Float; -- Clone type Velocity_Array is array ... of Velocity; If we do it anyway, then it costs nothing to add a clause requiring Velocity to implement, say, Comparable. Moreover, the predefined Float type should be Comparable anyway! >> 2. (for existing types) language supports supertyping. If it does, then >> creating a wrapper will be a matter of one or two code lines. You create a >> helper type which is both a subtype of CElement and a supertype of int. > > And you see, that's the point. I wrote: 'to make it work', and it's > not as easy as it seems. In order to work with container algorithms and > cooperate with other containers, your wrapper should also implement wrappers > for wrapped type's iterators with wrappers for wrapped type's iterators' > functions... Doesn't look to me like 'a matter of one or two code lines' ;-) It is not different from the generic way. Your element should have some operations. In C++ it is checked upon inlining. In Ada it is checked upon instantiation. With my proposal it will be checked when you create a wrapper. The only difference is in the place and time. >>> If you have a function template copying elements of >>> one container into another, then it'll work fine even for 100 container >>> types, as long as they use the same interface. >> >> Which interface you mean? string is an instance of another template. It is >> not vector<>, and there is no way to make it conform to vector<>, because >> there is no such thing as "vector interface". > > *container* interface. String is not exactly a vector, but might be > treated similarily to one because of it's container-like interface. 1. Who and how guaranties that? 2. You cannot have a conform to the interface object without specifying its concrete type. The rest follows from that. >>> Can you specify what do you mean when saying 'mix them'? >> >> All cases were: >> >> template <class A, class B> Foo (vector <A>& X, vector <B>& Y) >> { >> ... >> Do_Something (X [I], Y [J]); >> ... >> } >> >> cannot be replaced with: >> >> template <class A> Foo (vector <A>& X, vector <A>& Y) >> { >> ... >> Do_Something (X [I], Y [J]); >> ... >> } > > Wouldn't this do? > > template <class A, class B> Foo (A & X, B & Y) > { > ... > Do_Something (X [I], Y [J]); > ... > } Where is any difference? You still have to specify both class A and class B in the template parameter profile. Whereas the elements types are of little interest for Foo. The contract of Foo is: 1. Foo takes two arrays as parameters. 2.a Nothing is said whether indices or elements types are related. 2.c They are members of some type set 2.c.1 They have a common ancestor = the set is dynamically polymorphic 2.c.1.a One is a subtype of another 2.c.2 The set is generic = statically polymorphic ---- [ 2.c is equivalent, in my view, to requiring arrays to be from some set of types narrower than just ARRAY. If the language allows to specify ARRAY, then it will be also no problem to define its constrained subsets. ] 2.d They are same types With templates you can reasonable implement only 2.d. Of course, one could extend templates to support some sophisticated type pattern matching mechanism, add constraints on formal types etc. IMO, that would be wasting of time. I believe that inheritance is a much more clearer and safer way of defining type sets than loose parametrization. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-07 10:08 ` Dmitry A. Kazakov @ 2004-10-10 22:21 ` Robert Kawulak 2004-10-11 8:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-10 22:21 UTC (permalink / raw) Hi, > In my view, array is a container and container is an abstract array. > Iterators should be introduced as index types In my view it's not. Not every container has semantics of an array (random access to every element and efficient insertions at the end of an array), although every array may have semantics of container. I think that for this reason containers shouldn't be all treated as abstract arrays, because this could be misleading. After all the reason for diversity of container types is their certain operations' efficiency difference. > Iterators should be introduced as index types, subdivided into ordered and > unordered ones. But aren't all iterators already ordered? Otherwise they couldn't iterate... > For ordered index types you can have ranges. Can't you have them with iterators? >>> 1. (for new types) language supports multiple interface inheritance. C++ >>> does, Ada 2005 will. >> >> 'elements of some class -=#not#=- derived from CElement' - I meant if >> you >> can derive, then there's no problem. > > Yes, but differently to C++ in Ada that would cover almost 90% of all > cases. This comparison seems to me a bit unfair. Don't you think that if C++ would use polymorphic containers, then its type system would also be adjusted to cover 90% of all cases? >> And you see, that's the point. I wrote: 'to make it work', and it's >> not as easy as it seems. In order to work with container algorithms and >> cooperate with other containers, your wrapper should also implement >> wrappers >> for wrapped type's iterators with wrappers for wrapped type's iterators' >> functions... Doesn't look to me like 'a matter of one or two code lines' >> ;-) Ah, sorry - I've mistaken making a wrapper for elements for making a wrapper for containers here... Never mind ;-) > In C++ it is checked upon inlining. In Ada it is checked upon > instantiation. With my proposal it will be checked when you create a > wrapper. The only difference is in the place and time. What do you mean by 'inlining' here? C++ templates are also instantiated, either explicitly or implicitly (in a place you use it). >> template <class A, class B> Foo (A & X, B & Y) >> { >> ... >> Do_Something (X [I], Y [J]); >> ... >> } [...] > The contract of Foo is: > > 1. Foo takes two arrays as parameters. As long as we don't come to a common conclusion what an array is, this is meaningless... > 2.a Nothing is said whether indices or elements types are related. Isn't that true here? With regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-10 22:21 ` Robert Kawulak @ 2004-10-11 8:46 ` Dmitry A. Kazakov 2004-10-15 9:25 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-11 8:46 UTC (permalink / raw) On Mon, 11 Oct 2004 00:21:06 +0200, Robert Kawulak wrote: >> In my view, array is a container and container is an abstract array. >> Iterators should be introduced as index types > > In my view it's not. Not every container has semantics of an array > (random access to every element and efficient insertions at the end of an > array), although every array may have semantics of container. This is a property of the index type, I believe. If your index (iterator) has only the operation 'Succ, and no 'Pred then the array built upon it will become a stream, this in turn will allow an implementation, which does not provide random access. And note that my point regards views and only. A container may have other, non-array, views. Its array view might be strict read-only etc. I want to separate interface and implementation, you know. > I think that > for this reason containers shouldn't be all treated as abstract arrays, > because this could be misleading. After all the reason for diversity of > container types is their certain operations' efficiency difference. > >> Iterators should be introduced as index types, subdivided into ordered and >> unordered ones. > > But aren't all iterators already ordered? Otherwise they couldn't > iterate... Not necessarily. You can have weaker orders. Consider multidimensional arrays, trees and graphs. However, yes, "index" or "pointer" would be a more precise word than "iterator". >> For ordered index types you can have ranges. > > Can't you have them with iterators? Only if the container defines a corresponding helper type. In my view it should be the reverse. If a type is an ordered index then its contract is to have ranges and all operations on them. >>>> 1. (for new types) language supports multiple interface inheritance. C++ >>>> does, Ada 2005 will. >>> >>> 'elements of some class -=#not#=- derived from CElement' - I meant if >>> you >>> can derive, then there's no problem. >> >> Yes, but differently to C++ in Ada that would cover almost 90% of all >> cases. > > This comparison seems to me a bit unfair. Don't you think that if C++ > would use polymorphic containers, then its type system would also be > adjusted to cover 90% of all cases? C++ is beyond hope, anyway. C++ OO model is in my view irreparably corrupt. And I do not much care how #defines called templates will evolve. It is not my business! (:-)) >> In C++ it is checked upon inlining. In Ada it is checked upon >> instantiation. With my proposal it will be checked when you create a >> wrapper. The only difference is in the place and time. > > What do you mean by 'inlining' here? C++ templates are also > instantiated, either explicitly or implicitly (in a place you use it). I prefer "inline" because C++ instantiation may fail due to errors in the template body. That is because C++ templates are in fact macros. When and if, C++ will switch to a contract model, then I will call it instantiation. >>> template <class A, class B> Foo (A & X, B & Y) >>> { >>> ... >>> Do_Something (X [I], Y [J]); >>> ... >>> } > [...] >> The contract of Foo is: >> >> 1. Foo takes two arrays as parameters. > > As long as we don't come to a common conclusion what an array is, this > is meaningless... But we don't need that, because in a contract model, array is just an interface of a set of types with some operations defined. This eliminates any philosophical question about where all arrays go when you turn the computer off! (:-)) We just define the operations we consider to be useful and call it array. Then anything declared to implement that interface will be an instance of the array. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-11 8:46 ` Dmitry A. Kazakov @ 2004-10-15 9:25 ` Robert Kawulak 2004-10-15 11:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 229+ messages in thread From: Robert Kawulak @ 2004-10-15 9:25 UTC (permalink / raw) Hi, >>> In C++ it is checked upon inlining. In Ada it is checked upon >>> instantiation. With my proposal it will be checked when you create a >>> wrapper. The only difference is in the place and time. >> >> What do you mean by 'inlining' here? C++ templates are also >> instantiated, either explicitly or implicitly (in a place you use it). > > I prefer "inline" because C++ instantiation may fail due to errors in the > template body. That is because C++ templates are in fact macros. When and > if, C++ will switch to a contract model, then I will call it > instantiation. Still I don't get it - what's wrong in that "C++ instantiation may fail due to errors in the template body"? Why shouldn't it fail? (Actually compilation may fail even when there's no instantiation, because templates bodies are always parsed, templates are not only ^C^V or #define as you say ;-) And what would this "contract model" change? Nota bene, you can have contracts with templates - if you use some inappropriate type as template's parameter, it won't compile, and you can strenghten contracts using boost::concept_check and boost::type_traits mentioned before in this discussion. Regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-15 9:25 ` Robert Kawulak @ 2004-10-15 11:56 ` Dmitry A. Kazakov 2004-10-20 20:06 ` Robert Kawulak 0 siblings, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-15 11:56 UTC (permalink / raw) On Fri, 15 Oct 2004 11:25:03 +0200, Robert Kawulak wrote: >>>> In C++ it is checked upon inlining. In Ada it is checked upon >>>> instantiation. With my proposal it will be checked when you create a >>>> wrapper. The only difference is in the place and time. >>> >>> What do you mean by 'inlining' here? C++ templates are also >>> instantiated, either explicitly or implicitly (in a place you use it). >> >> I prefer "inline" because C++ instantiation may fail due to errors in the >> template body. That is because C++ templates are in fact macros. When and >> if, C++ will switch to a contract model, then I will call it >> instantiation. > > Still I don't get it - what's wrong in that "C++ instantiation may fail > due to errors in the template body"? Why shouldn't it fail? (Actually > compilation may fail even when there's no instantiation, because templates > bodies are always parsed, templates are not only ^C^V or #define as you say > ;-) #define is also parsed! In compiled languages "parsed" is far less than "compiled" and the results of these two actions are much different too. The margin is not absolute of course, but parsed template body is closer to parsed #define body than to a compiled true body. > And what would this "contract model" change? Nota bene, you can have > contracts with templates - if you use some inappropriate type as template's > parameter, it won't compile, Neither a macro expansion of #define would. Contracts are 1) imposed on both sides, 2) checked *prior* the contracting parties engage each other. > and you can strenghten contracts using > boost::concept_check and boost::type_traits mentioned before in this > discussion. It is still not a contract. You consider only the case when the macro/template parameter does not fulfill the requirements of the macro/template body, and ones of the expansion context. As long as these requirements are not formulated, but are a subject of investigation of the body (=implementation), it is not a contract. What if the *implementation* does not fulfill the contract, while the parameter does? How can you judge without explicit contract specification? And finally, when you manage to have true contracts for templates. What would be the gain? Your templates with contracts would be just like Ada generics. As a meta-language they would have types (=classes of parameters) but no user-defined ones (no ADT). Sorry, but it is early 70s of programming languages! Why do we need a meta-language with no ADT, for a language with ADT? There should be damn good reason for that, or? (Turing does not count! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-15 11:56 ` Dmitry A. Kazakov @ 2004-10-20 20:06 ` Robert Kawulak 2004-10-21 2:51 ` Kevin Cline 2004-10-21 8:39 ` Dmitry A. Kazakov 0 siblings, 2 replies; 229+ messages in thread From: Robert Kawulak @ 2004-10-20 20:06 UTC (permalink / raw) Hi, > #define is also parsed! In compiled languages "parsed" is far less than > "compiled" and the results of these two actions are much different too. OK, by saying 'parsed' I meant 'compiled'... Don't catch me in my words! ;-) > The > margin is not absolute of course, but parsed template body is closer to > parsed #define body than to a compiled true body. Templates are not so close to #defines. Using the 'export', keyword their implementation may be *compiled* in only one translation unit, and you may use them anywhere given only their declarations - just like ordinary functions and objects (well, at least in theory, because there are not so many compilers supporting 'export' yet... But I hope this will change soon). > What if the *implementation* > does not fulfill the contract, while the parameter does? Ah, I see (at last ;-) what's your point. But is it really necessary to check if the *implementation* is contract-conformant? If it's not contract-conformant, then you get a compile-time error anytime you try to use it, the only difference I see is that such an error is detected only during instantiation. I know it'd be nice if the implementation would be checked for contract-conformance during compilation (parsing, whatever ;-), but OTOH I don't see not doing this such an issue... Regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-20 20:06 ` Robert Kawulak @ 2004-10-21 2:51 ` Kevin Cline 2004-10-21 8:39 ` Dmitry A. Kazakov 1 sibling, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-10-21 2:51 UTC (permalink / raw) "Robert Kawulak" <tigrisek@interia.pl> wrote in message news:<cl6gok$q0e$1@nemesis.news.tpi.pl>... > Hi, > > > #define is also parsed! In compiled languages "parsed" is far less than > > "compiled" and the results of these two actions are much different too. > > OK, by saying 'parsed' I meant 'compiled'... Don't catch me in my > words! ;-) > > > The > > margin is not absolute of course, but parsed template body is closer to > > parsed #define body than to a compiled true body. > > Templates are not so close to #defines. Using the 'export', keyword their > implementation may be *compiled* in only one translation unit, and you may > use them anywhere given only their declarations - just like ordinary > functions and objects (well, at least in theory, because there are not so > many compilers supporting 'export' yet... But I hope this will change soon). > > > What if the *implementation* > > does not fulfill the contract, while the parameter does? > > Ah, I see (at last ;-) what's your point. But is it really necessary to > check if the *implementation* is contract-conformant? If it's not > contract-conformant, then you get a compile-time error anytime you try to > use it, the only difference I see is that such an error is detected only > during instantiation. I know it'd be nice if the implementation would be > checked for contract-conformance during compilation (parsing, whatever ;-), > but OTOH I don't see not doing this such an issue... Actually, this wouldn't be so nice. As it is, member functions are instantiated individually, so we can write: template <class T> class Container { typedef ... const_iterator; void write(ostream& out) const { for (const_iterator i ... ) { out << *i; } } } and still be able to instantiate Container<X> even if operator<<(ostream&, X) is not defined. There is no error unless we call Container<X>::write. Of course, modern C++ experts would assert that functions like write should be free functions and not class member functions. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-20 20:06 ` Robert Kawulak 2004-10-21 2:51 ` Kevin Cline @ 2004-10-21 8:39 ` Dmitry A. Kazakov 2004-10-27 21:41 ` Robert Kawulak 1 sibling, 1 reply; 229+ messages in thread From: Dmitry A. Kazakov @ 2004-10-21 8:39 UTC (permalink / raw) On Wed, 20 Oct 2004 22:06:28 +0200, Robert Kawulak wrote: >> What if the *implementation* >> does not fulfill the contract, while the parameter does? > > Ah, I see (at last ;-) what's your point. But is it really necessary to > check if the *implementation* is contract-conformant? If it's not > contract-conformant, then you get a compile-time error anytime you try to > use it, the only difference I see is that such an error is detected only > during instantiation. But software design, at least with Ada, is not about detecting errors. That would be debugging. (:-)) The advantage of contracts is in knowledge. With templates when you instantiate and get an error, you cannot judge who was wrong, contract is the code of laws to judge. [Provided that you have a gift of deciphering template error messages, which tend to be longer than the source code!] > I know it'd be nice if the implementation would be > checked for contract-conformance during compilation (parsing, whatever ;-), > but OTOH I don't see not doing this such an issue... Kevin Cline in other post gave an excellent example of how awful it is. His example shows that a template developer have to write extensive tests to detect errors which, otherwise, would be routinely detected by any compiler. In his view it is an advantage that no error will be detected until write is used. In my view it is a fallacy. If write is declared in Container, then it is a contract, is it? Then if an instantiation with some T makes its use impossible, then the contract is violated. On the other hand, if that instantiation is right and there is no need in write for a Container, then it is Container which violates the implied contract by placing there write. This or that way, the result is same. A contract model works only if it does not leak. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-10-21 8:39 ` Dmitry A. Kazakov @ 2004-10-27 21:41 ` Robert Kawulak 0 siblings, 0 replies; 229+ messages in thread From: Robert Kawulak @ 2004-10-27 21:41 UTC (permalink / raw) Hi, > But software design, at least with Ada, is not about detecting errors. > That would be debugging. (:-)) Would you like your compiler not to find errors then? (Just kidding... ;-) Regards, Robert ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) [not found] ` <cji06f$17a$2@atlantis.news.tpi.pl> 2004-10-01 8:58 ` Dmitry A. Kazakov @ 2004-10-01 13:02 ` Robert Kawulak 2004-10-28 10:26 ` Larry Kilgallen 2 siblings, 0 replies; 229+ messages in thread From: Robert Kawulak @ 2004-10-01 13:02 UTC (permalink / raw) > But this is where the "template metaprogramming" stuff applies - you can't > use it directly as string, but you can make a template metafunction which in > turn can take vector<char> or string or something else as its metaargument. Sorry, I didn't express myself in the strict terms - I meant just tempate function, not "template metafunction", with ordinary parameters, not "metaargments". That is not what exactly template metaprogramming is about, sorry for the confusion. (I was writing that post late at night... ;-) Regards, Robert Kawulak ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) [not found] ` <cji06f$17a$2@atlantis.news.tpi.pl> 2004-10-01 8:58 ` Dmitry A. Kazakov 2004-10-01 13:02 ` Robert Kawulak @ 2004-10-28 10:26 ` Larry Kilgallen 2 siblings, 0 replies; 229+ messages in thread From: Larry Kilgallen @ 2004-10-28 10:26 UTC (permalink / raw) In article <clp51f$729$2@nemesis.news.tpi.pl>, "Robert Kawulak" <tigrisek@interia.pl> writes: > Hi, > >> But software design, at least with Ada, is not about detecting errors. >> That would be debugging. (:-)) > > Would you like your compiler not to find errors then? (Just kidding... ;-) I would like my compiler not to find errors. I just want my compiler to be _capable_ of finding errors, on the distant chance there were any. So far the compilers are doing better at finding errors than I am at making the chance be distant. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 14:31 ` Kevin Cline 2004-09-27 15:05 ` Dmitry A. Kazakov @ 2004-09-27 16:21 ` Matthew Heaney 2004-09-28 2:47 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-27 16:21 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409270631.2bf81ccf@posting.google.com... > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uekkpt07s.fsf@earthlink.net>... > > kevin.cline@gmail.com (Kevin Cline) writes: > > > > Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have to say: > > > > Replace_Element (C, Index => 5, By => 7); > > I think this was a major error in the language design. As a result it > very tedious to write a generic that will work with both predefined > and user-defined types. All you need to do is write the generic in terms of (AI-302) container operations, and then use locally declared subprograms to make the array (say) work with the generic algorithm. The "tedium" only applies when using a generic on an array instead of a container. For example: generic type Cursor is private; with function Next (C : Cursor) return Cursor is <>; with procedure Replace_Element (C : Cursor; By : ET) is <>; with function Has_Element (C : Cursor) return Boolean is <>; procedure Generic_Op (C : Cursor); To use this with a container type, there's nothing you need to do except instantiate the generic algorithm. To make this work with an array, all you need to do is: procedure Op (A : in out Array_Type) is procedure Replace_Element (I : Index_Type; E : ET) is begin A (I) := E; end; function Has_Element (I : IT) return Boolean is begin return I in A'Range; end; procedure Algorithm is new Generic_Algorithm (Index_Type, Index_Type'Succ); begin Algorithm (A'First); end Op; Note that here the "cursor" is just the discrete array index subtype. The T'Succ attribute is used as the generic actual for the Next generic formal. Your problem is that you're still thinking in C++ terms. C++ works by making containers look like built-in types. That's different from Ada, which (as demonstrated above) makes the built-in type look like a container. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-27 16:21 ` Matthew Heaney @ 2004-09-28 2:47 ` Kevin Cline 2004-09-28 4:03 ` Brian May 2004-09-28 4:46 ` Matthew Heaney 0 siblings, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-28 2:47 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>... > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0409270631.2bf81ccf@posting.google.com... > > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message > news:<uekkpt07s.fsf@earthlink.net>... > > > kevin.cline@gmail.com (Kevin Cline) writes: > > > > > > Indeed, you cannot do this. In AI-302 (and in Ada.Strings.*), you have > to say: > > > > > > Replace_Element (C, Index => 5, By => 7); > > > > I think this was a major error in the language design. As a result it > > very tedious to write a generic that will work with both predefined > > and user-defined types. > > All you need to do is write the generic in terms of (AI-302) container > operations, and then use locally declared subprograms to make the array > (say) work with the generic algorithm. The "tedium" only applies when using > a generic on an array instead of a container. > > For example: > > generic > type Cursor is private; > with function Next (C : Cursor) return Cursor is <>; > with procedure Replace_Element (C : Cursor; By : ET) is <>; > with function Has_Element (C : Cursor) return Boolean is <>; > procedure Generic_Op (C : Cursor); > > To use this with a container type, there's nothing you need to do except > instantiate the generic algorithm. > > To make this work with an array, all you need to do is: > > procedure Op (A : in out Array_Type) is > > procedure Replace_Element (I : Index_Type; E : ET) is > begin > A (I) := E; > end; > > function Has_Element (I : IT) return Boolean is > begin > return I in A'Range; > end; > > procedure Algorithm is > new Generic_Algorithm (Index_Type, Index_Type'Succ); > > begin > Algorithm (A'First); > end Op; > > Note that here the "cursor" is just the discrete array index subtype. The > T'Succ attribute is used as the generic actual for the Next generic formal. > > Your problem is that you're still thinking in C++ terms. No doubt. > C++ works by > making containers look like built-in types. That's different from Ada, > which (as demonstrated above) makes the built-in type look like a container. Ok, but shouldn't that code be generic? The code above works for only one algorithm on one particular array type. I think that "different from Ada" here is significantly better. Lots of existing C and C++ code that works on arrays that can be trivially modified to work on any array-like class, but existing Ada array code has to be rewritten in every detail to work on a user-defined container. And the results of that rewrite aren't pretty. For example, suppose you want to multiply sparse matrices. Instead of the natural: P(I,K) := A(I,J) * B(J,K) you'll end up with something like: SET_ELEMENT(P, I, K, ELEMENT(A, I, J) * ELEMENT(B, J, K)) ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 2:47 ` Kevin Cline @ 2004-09-28 4:03 ` Brian May 2004-09-28 4:46 ` Matthew Heaney 1 sibling, 0 replies; 229+ messages in thread From: Brian May @ 2004-09-28 4:03 UTC (permalink / raw) >>>>> "Kevin" == Kevin Cline <kevin.cline@gmail.com> writes: Kevin> SET_ELEMENT(P, I, K, ELEMENT(A, I, J) * ELEMENT(B, J, K)) This doesn't answer the point you made, however, personally I would write the above as: Result := ELEMENT(A, I, J) * ELEMENT(B, J, K); SET_ELEMENT(P, I, K, Result); IMHO this is slightly simpler then the initial version. -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 2:47 ` Kevin Cline 2004-09-28 4:03 ` Brian May @ 2004-09-28 4:46 ` Matthew Heaney 2004-09-29 3:14 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-28 4:46 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > "Matthew Heaney" <mheaney@on2.com> wrote in message > news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>... > > > C++ works by making containers look like built-in types. That's > > different from Ada, which (as demonstrated above) makes the built-in > > type look like a container. > > Ok, but shouldn't that code be generic? The code above works for only > one algorithm on one particular array type. You're still confused. The local subprograms are analogous to STL binders and function objects. The generic part is Generic_Op. The rest is just glue. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-28 4:46 ` Matthew Heaney @ 2004-09-29 3:14 ` Kevin Cline 2004-09-29 3:50 ` Matthew Heaney 2004-09-29 13:44 ` Matthew Heaney 0 siblings, 2 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-29 3:14 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<u7jqeubqg.fsf@earthlink.net>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > "Matthew Heaney" <mheaney@on2.com> wrote in message > > news:<41583b4c$0$74190$39cecf19@news.twtelecom.net>... > > > > > C++ works by making containers look like built-in types. That's > > > different from Ada, which (as demonstrated above) makes the built-in > > > type look like a container. > > > > Ok, but shouldn't that code be generic? The code above works for only > > one algorithm on one particular array type. > > You're still confused. The local subprograms are analogous to STL > binders and function objects. The generic part is Generic_Op. The rest > is just glue. But 14 lines of glue for every different array type that I want to use with Generic_Op? That's the sort of repetition that turned me away from Ada in the first place. I like languages where I can say what I want, and only have to say it once. I don't like languages where I have to cut and paste endless variations of boilerplate code. For that reason I like C++ and Perl and LISP and don't like Ada and Java and C#. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:14 ` Kevin Cline @ 2004-09-29 3:50 ` Matthew Heaney 2004-09-29 3:52 ` Matthew Heaney 2004-09-29 13:44 ` Matthew Heaney 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 3:50 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message > news:<u7jqeubqg.fsf@earthlink.net>... > > > > You're still confused. The local subprograms are analogous to STL > > binders and function objects. The generic part is Generic_Op. The rest > > is just glue. > > But 14 lines of glue for every different array type that I want to use > with Generic_Op? That's the sort of repetition that turned me away > from Ada in the first place. You're still confused. The "unnecessary code" typically includes up-level references to entities in the enclosing scope, e.g. procedure Op (C : CT) is Sum : Integer'Base := 0; procedure Add_E_To_Sum (E : Natural) is begin Sum := Sum + E; end; begin C.Iterate (Sum'Access); ... --do something with Sum end Op; > I like languages where I can say what I want, and only have to say it > once. I don't like languages where I have to cut and paste endless > variations of boilerplate code. For that reason I like C++ and Perl > and LISP and don't like Ada and Java and C#. That's just swell. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:50 ` Matthew Heaney @ 2004-09-29 3:52 ` Matthew Heaney 0 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 3:52 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> writes: Oops! That should be: > procedure Op (C : CT) is > > Sum : Integer'Base := 0; > > procedure Add_E_To_Sum (E : Natural) is > begin > Sum := Sum + E; > end; > > begin > > C.Iterate (Add_E_To_Sum'Access); > > ... --do something with Sum > > end Op; ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-29 3:14 ` Kevin Cline 2004-09-29 3:50 ` Matthew Heaney @ 2004-09-29 13:44 ` Matthew Heaney 1 sibling, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-29 13:44 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Matthew Heaney <matthewjheaney@earthlink.net> wrote in message > news:<u7jqeubqg.fsf@earthlink.net>... > > > > You're still confused. The local subprograms are analogous to STL > > binders and function objects. The generic part is Generic_Op. The > > rest is just glue. > > But 14 lines of glue for every different array type that I want to use > with Generic_Op? That's the sort of repetition that turned me away > from Ada in the first place. I like languages where I can say what I > want, and only have to say it once. I don't like languages where I > have to cut and paste endless variations of boilerplate code. For > that reason I like C++ and Perl and LISP and don't like Ada and Java > and C#. I should have pointed out that there's nothing that precludes this in Ada. It's exactly analogous to template specializations in C++. I gave an example of a Generic_Op that works with a container interface, and then made that work with an array. But of course, we could have hidden this glue code behind a specialization of the algorithm for array types: generic type Cursor is private; ... procedure Generic_Op (...); generic type IT is (<>); type ET is private; type Array_T is array (IT) of ET; ... procedure Generic_Op_Constrained_Array (...); generic type IT is (<>); type ET is private; type Array_T is array (IT range <>) of ET; ... procedure Generic_Op_Unconstrained_Array (...); generic type IT is (<>); with procedure Swap (I, J : IT) is <>; ... procedure Generic_Op_Anonymous_Array (...); generic type IT is (<>); type ET (<>) is limited private; type Array_T is array (IT range <>) of access ET; ... procedure Generic_Op_Array_Access_Component (...); You get the idea. This is no different from the C++ technique of specializing a generic algorithm on the type. I said in my previous post that the local subprograms often make up-level references to the enclosing scope. Another example of that is if I declare an anonymous array object: declare A : array (1 .. N) of access Shape'Class; begin Pretend Generic_Op is a sort algorithm. In order to sort this array object, I need to use the most general specialization for arrays (it's the one listed above that accepts a Swap procedure), because I don't have an array type to use as the generic actual. Something like: declare A : array (1 .. N) of access Shape'Class; begin ... Sort_A: declare function Less (I, J : Positive) return Boolean is begin return A (I) < A (J); --or whatever end; procedure Swap (I, J : Positive) is SI : Shape'Class renames A (I).all'Access; begin A (I) := A (J); A (J) := SI; end; procedure Sort is new Generic_Sort_Anonymous_Array (Positive); begin Sort (A'First, A'Last); end Sort_A; ... end; Here the local subprograms provide the glue to bind a pure algorithm to an actual object. The generic is named Generic_Sort_Anonymous_Array, but really that algorithm works for any array-like thing that uses a discrete index to refer to elements. You could use it to sort a vector or deque, for example. This example was motivated by the ai302/examples/shapes example, which was inspired by the example in Musser (who was himself inspired by the same example in Strustroup). -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 9:50 ` Georg Bauhaus 2004-09-24 13:47 ` Matthew Heaney 2004-09-24 16:28 ` Kevin Cline @ 2004-09-26 6:32 ` Kevin Cline 2004-09-26 15:05 ` Matthew Heaney 2 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 6:32 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cj0qlt$qkh$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : Are you really claiming that you can think of: > : > : procedure Insert (Word : in String) is > : > : procedure Increment_Count > : (K : in String; > : N : in out Natural) is > : > : pragma Warnings (Off, K); > : begin > : N := N + 1; > : end Increment_Count; > : > : C : Wordcount_Maps.Cursor; > : B : Boolean; > : > : begin -- Insert > : Insert (M, Word, 0, C, B); > : Update_Element (C, Increment_Count'Access); > : end Insert; > : > : As quickly as I can think of: > : ++concordance[word] > : or > : ++$count{$word} ? > > Isn't the comparison at different levels? AI 302 is to be minimal, I think, > in that every convenient operation can be built from thingies present in > Ada.Containers. > > > : Multiply this 1000 times for a medium to large program and I think Ada > : really suffer from unnecessary verbosity. > > Are you saying that Ada programmers automatically don't make reusable > procudures and instead will repeat a procedure with the effect of ++ all > over the place? Well, if C++ had no operator++ it would be easy enough to write: template <class T> T preincrement(T& value) { value = value + 1; return value; } You could write a generic function in Ada, except that it couldn't return a value, and you would have to instantiate it for every type you wanted to increment. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 6:32 ` Kevin Cline @ 2004-09-26 15:05 ` Matthew Heaney 2004-09-27 14:35 ` Kevin Cline 0 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-26 15:05 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > Well, if C++ had no operator++ it would be easy enough to write: > template <class T> T preincrement(T& value) > { > value = value + 1; > return value; > } Shouldn't preincrement return T&, not T? template <class T> T& preincrement(T& value) { value = value + 1; return value; } As you wrote it, the function will invoke the copy ctor for T, and return a copy of value. (But maybe that's what you wanted.) ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 15:05 ` Matthew Heaney @ 2004-09-27 14:35 ` Kevin Cline 0 siblings, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-27 14:35 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<umzzdt0p6.fsf@earthlink.net>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > Well, if C++ had no operator++ it would be easy enough to write: > > template <class T> T preincrement(T& value) > > { > > value = value + 1; > > return value; > > } > > Shouldn't preincrement return T&, not T? Yes, it should. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:27 ` Ole-Hjalmar Kristensen 2004-09-23 19:11 ` Kevin Cline @ 2004-09-23 19:30 ` jayessay 1 sibling, 0 replies; 229+ messages in thread From: jayessay @ 2004-09-23 19:30 UTC (permalink / raw) Ole-Hjalmar Kristensen > >>>>> "KC" == Kevin Cline <kevin.cline@gmail.com> writes: > > <snip> > > >> > >> Does this prove that perl is the best language? If so, perhaps we > >> should all switch our avionics projects over to perl. Must be it will > >> be easier to code and maintain, safer to fly, and run just as fast. > > KC> It doesn't prove that Perl is the best language for every job. But > KC> the original thread was about Ada popularity. Relatively few people > KC> write avionics code, or any safety-critical software. I do think that > KC> a lot of projects currently being written in C++, Java, or C# could be > KC> done much more cheaply and effectively in Perl or a similar language. > > >> > >> The things that make a language a "good" language are many and > >> complex, and are different in different circumstances. If I need a > >> small utility that compares lines in different text files, I find perl > >> much easier than Ada. On the other hand, if I have a very large > >> project that must always perform "correctly", I've not found a > >> language that can beat Ada. > > KC> But large projects in Ada or C++ or Java or C# might be small or > KC> medium-sized projects in a higher-level language. I have found this to be _very_ true. > Maybe. It depends on how large the projcet is, and how good you are > to create reusable components/abstractions within the project, Not really, as that should be true no matter what language you use. > and how good a fit your problem is to the facilites provided by the > "higher-level" language. This is key. The robustness, maintainability, evolvability, and "correctness" of a program is directly and closely related to how close its expression is to the language of the problem domain. In the case of Lisp, this is where the "Lisp is a programmable programming language" comes in. You can always create a (possibly hierarchical set of) domain specific language that directly supports the most natural, clean, and direct means of expressing the definitions and process within the domain. People often talk of "hoisting the language up to the level of the domain". It used to be (and I suppose in many places still is the case) that people thought this sort of thing could be done with components and component libraries. But this is an error. No library (no matter how good it is - and most are very poor) will ever have the level of expressiveness as even a decent (let alone good) domain specific language. > KC> If you have a project that must always perform "correctly", then you > KC> better prove it correct. Strong typing can help, but is not > KC> absolutely necessary to that effort. > > KC> For the rest of us, the most important thing is to get tested code > KC> done quickly. I don't know about you, but I can write and test 14 > KC> lines of code a whole lot faster than I can write and test 80 or 160. > > I usually find that my ability to create programs is limited by my > thought process, not my typing speed :-) He's not refering to the same limitation, and he's right. /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 9:00 ` Kevin Cline 2004-09-23 11:27 ` Ole-Hjalmar Kristensen @ 2004-09-23 19:42 ` Alexander E. Kopilovich 1 sibling, 0 replies; 229+ messages in thread From: Alexander E. Kopilovich @ 2004-09-23 19:42 UTC (permalink / raw) To: comp.lang.ada Kevin Cline wrote: > But the original thread was about Ada popularity. Implicitly, among programmers/software engineers and perhaps software-related managers, I suppose. But this isn't the only possible audience for popularity, even for programming languages. > Relatively few people write avionics code, Just as relatively few people fly airplanes as airline or military pilots or pilots for other services. But quite enough people depend on that flying and its safety and effectiveness. Even in avaiation world there are different kinds of popularity - for example, both Boeing and Cessna are certainly quite popular. And probably much more people fly Cessnas, but does it mean that Cessna is generally more popular than Boeing? > But large projects in Ada or C++ or Java or C# might be small or > medium-sized projects in a higher-level language. Don't you know that a plane cannot fly before the weight of its documentation exceeds its own weight? -:) Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (2 preceding siblings ...) 2004-09-22 15:27 ` James Alan Farrell @ 2004-09-22 21:05 ` Georg Bauhaus 2004-09-23 9:20 ` Kevin Cline 2004-09-23 6:24 ` Matthew Heaney ` (4 subsequent siblings) 8 siblings, 1 reply; 229+ messages in thread From: Georg Bauhaus @ 2004-09-22 21:05 UTC (permalink / raw) Kevin Cline <kevin.cline@gmail.com> wrote: : : Summary: : : Ada/Charles 158 lines, 9 files If you want, you can place all units in one file. The compilers can handle this. Will the compilation process profit from splitting C++ sources into files, in general? -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 21:05 ` Georg Bauhaus @ 2004-09-23 9:20 ` Kevin Cline 2004-09-23 16:58 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-23 9:20 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cisper$e5u$1@a1-hrz.uni-duisburg.de>... > Kevin Cline <kevin.cline@gmail.com> wrote: > : > : Summary: > : > : Ada/Charles 158 lines, 9 files > > If you want, you can place all units in one file. The compilers > can handle this. I was pretty sure that all those instantiations could go into the body. > Will the compilation process profit from splitting > C++ sources into files, in general? No, it will get slower, in general, because opening files is about the slowest part of compilation. The only reason to split code into multiple files is to ease maintenance. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 9:20 ` Kevin Cline @ 2004-09-23 16:58 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 229+ messages in thread From: Warren W. Gay VE3WWG @ 2004-09-23 16:58 UTC (permalink / raw) Kevin Cline wrote: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cisper$e5u$1@a1-hrz.uni-duisburg.de>... >>Kevin Cline <kevin.cline@gmail.com> wrote: ... >>Will the compilation process profit from splitting >>C++ sources into files, in general? > > No, it will get slower, in general, because opening files is about the > slowest part of compilation. The only reason to split code into > multiple files is to ease maintenance. Not just open overhead, but each separate compile requires re-digesting all the #include files that must be repeated for each unit. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (3 preceding siblings ...) 2004-09-22 21:05 ` Georg Bauhaus @ 2004-09-23 6:24 ` Matthew Heaney 2004-09-23 11:23 ` Jeff C r e e.m 2004-09-23 18:24 ` Kevin Cline 2004-09-23 17:12 ` Dan Andreatta ` (3 subsequent siblings) 8 siblings, 2 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-23 6:24 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>... > > You can compare the implementations at > http://www.geocities.com/kc0a/wordcount.html See also the latest version of the wordcount example, that compiles against the Madison release of the AI-302 API: http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/ This should give you some idea of how things will work in Ada 2005. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 6:24 ` Matthew Heaney @ 2004-09-23 11:23 ` Jeff C r e e.m 2004-09-23 11:35 ` Georg Bauhaus 2004-09-23 18:30 ` Matthew Heaney 2004-09-23 18:24 ` Kevin Cline 1 sibling, 2 replies; 229+ messages in thread From: Jeff C r e e.m @ 2004-09-23 11:23 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> wrote in message news:1ec946d1.0409222224.6d86e038@posting.google.com... > kevin.cline@gmail.com (Kevin Cline) wrote in message > news:<e749549b.0409211621.6f3d3723@posting.google.com>... >> >> You can compare the implementations at >> http://www.geocities.com/kc0a/wordcount.html > > See also the latest version of the wordcount example, that compiles > against the Madison release of the AI-302 API: > > http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/ > > This should give you some idea of how things will work in Ada 2005. > > -Matt I took a quick look. What possible reason is there to procedeed all of those nested subprogram bodies by the specifications For example. (See inline comment below) Populate_Vector : declare -- -- As written, this line as absolutely no purpose -- procedure Append_To_V (C : Wordcount_Maps.Cursor); procedure Append_To_V (C : Wordcount_Maps.Cursor) is begin Append (V, C); end Append_To_V; N : constant Count_Type := Length (M); begin if Capacity (V) < N then Ensure_Capacity (V, N); end if; Iterate (M, Append_To_V'Access); end Populate_Vector; In the complete example that style represents 5 lines of code that add nothing to the program semantics or to the program readability. Of course it is early in the morning so perhaps I am missing something obvious. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:23 ` Jeff C r e e.m @ 2004-09-23 11:35 ` Georg Bauhaus 2004-09-23 17:05 ` Pascal Obry 2004-09-23 17:07 ` Pascal Obry 2004-09-23 18:30 ` Matthew Heaney 1 sibling, 2 replies; 229+ messages in thread From: Georg Bauhaus @ 2004-09-23 11:35 UTC (permalink / raw) Jeff C r e e.m <jcreem@yahoo.com> wrote: : : Populate_Vector : : declare : -- : -- As written, this line as absolutely no purpose : -- : procedure Append_To_V (C : Wordcount_Maps.Cursor); I find these lines useful as head lines. You can place a short comment below them. Then the implementation, which follows the commenting paragraph, is less disrupted. : procedure Append_To_V (C : Wordcount_Maps.Cursor) is : begin : Append (V, C); : end Append_To_V; : : N : constant Count_Type := Length (M); : begin : if Capacity (V) < N then : Ensure_Capacity (V, N); : end if; : : Iterate (M, Append_To_V'Access); : end Populate_Vector; -- Georg ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:35 ` Georg Bauhaus @ 2004-09-23 17:05 ` Pascal Obry 2004-09-23 17:07 ` Pascal Obry 1 sibling, 0 replies; 229+ messages in thread From: Pascal Obry @ 2004-09-23 17:05 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Jeff C r e e.m <jcreem@yahoo.com> wrote: > : > : Populate_Vector : > : declare > : -- > : -- As written, this line as absolutely no purpose > : -- > : procedure Append_To_V (C : Wordcount_Maps.Cursor); > > I find these lines useful as head lines. You can place a short > comment below them. Then the implementation, which follows > the commenting paragraph, is less disrupted. Exactly and this is the GNAT style (and can be checked using -gnatys). It ensures that all routines that are only in the body have a spec and this is the best place to put a set of comments for this routine. 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] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:35 ` Georg Bauhaus 2004-09-23 17:05 ` Pascal Obry @ 2004-09-23 17:07 ` Pascal Obry 1 sibling, 0 replies; 229+ messages in thread From: Pascal Obry @ 2004-09-23 17:07 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > I find these lines useful as head lines. You can place a short > comment below them. Then the implementation, which follows > the commenting paragraph, is less disrupted. BTW, this is also the style used for AWS. 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] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 11:23 ` Jeff C r e e.m 2004-09-23 11:35 ` Georg Bauhaus @ 2004-09-23 18:30 ` Matthew Heaney 2004-09-23 19:31 ` Simon Wright 1 sibling, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-23 18:30 UTC (permalink / raw) "Jeff C r e e.m" <jcreem@yahoo.com> wrote in message news:<Kmy4d.243234$mD.161573@attbi_s02>... > > I took a quick look. What possible reason is there to procedeed all of those > nested subprogram bodies by the specifications [snip] > Of course it is early in the morning so perhaps I am missing something > obvious. They add nothing. I was using the -gnatg option, and -gnatg requires forward declarations of all subprograms. That was a mistake. I only need to use -gnatg to compile the ada.* units, not wordcount.adb. I'll fix that tonight. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:30 ` Matthew Heaney @ 2004-09-23 19:31 ` Simon Wright 2004-09-24 0:09 ` Stephen Leake 0 siblings, 1 reply; 229+ messages in thread From: Simon Wright @ 2004-09-23 19:31 UTC (permalink / raw) mheaney@on2.com (Matthew Heaney) writes: > "Jeff C r e e.m" <jcreem@yahoo.com> wrote in message news:<Kmy4d.243234$mD.161573@attbi_s02>... > > > > I took a quick look. What possible reason is there to procedeed > > all of those nested subprogram bodies by the specifications > > > Of course it is early in the morning so perhaps I am missing something > > obvious. > > > They add nothing. I was using the -gnatg option, and -gnatg requires > forward declarations of all subprograms. > > That was a mistake. I only need to use -gnatg to compile the ada.* > units, not wordcount.adb. I find that GNAT's style checking helps me a lot; and it's much easier to say -gnaty than -gnaty3abcefhiklmprt, which is the standard set less -gnats (check separate specs). A shame that you can't say -gnatyS to turn the feature off, as in -gnatw ... -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:31 ` Simon Wright @ 2004-09-24 0:09 ` Stephen Leake 2004-09-25 10:41 ` Simon Wright 0 siblings, 1 reply; 229+ messages in thread From: Stephen Leake @ 2004-09-24 0:09 UTC (permalink / raw) To: comp.lang.ada Simon Wright <simon@pushface.org> writes: > I find that GNAT's style checking helps me a lot; and it's much easier > to say -gnaty than -gnaty3abcefhiklmprt, which is the standard set > less -gnats (check separate specs). A shame that you can't say -gnatyS > to turn the feature off, as in -gnatw ... I also use GNAT's style checking, but I don't like the default -gnaty (80 columns is too small, for one thing). So I have a standard project file that specifies the options I like: -- Standard settings for all of Stephe's Ada projects. project Standard_Common is for Source_Dirs use (); type GNAT_Version_Type is ("5.02a1", "5.02a", "5.01a", "3.16a1", "3.15p"); GNAT_Version : GNAT_Version_Type := External ("GNAT_VERSION"); type OS_Version_Type is ("Windows_XP", "Windows_98", "Windows_2000", "Lynx_4.0"); OS_Version : OS_Version_Type := External ("OS_VERSION"); package Compiler is System_Case_Style_Checks := "n"; Space_Style_Checks := "t"; Base_Style_Checks := "-gnaty3abefhiklM120pr"; Style_Checks := Base_Style_Checks & System_Case_Style_Checks & Space_Style_Checks; Non_Spacing_Style_Checks := Base_Style_Checks & System_Case_Style_Checks; -- For GNAT 3.15, don't warn about elaboration order (gnatwL, -- off by default in 3.16). -- -- -gnatVa causes some inline procedures to be non-inlineable; -- suppress that warning with -gnatwP. Base_Debug_Switches := -- Switches we always use ("-g", "-O0", "-gnatf", "-gnato", "-gnatwa", "-gnatwL", "-gnatVa", "-gnatwP", "-fstack-check"); Debug_Switches := Base_Debug_Switches & -- Switches we need to suppress sometimes ("-gnata", "-gnatwe"); Release_Switches := ("-g", "-O3", "-gnatn", "-gnatf", "-gnatwa", "-gnatwL"); -- The project file syntax does not let us set a variable in a -- case statement. So we set the Default_Switches attribute to -- contain the version-dependent switches. This is then -- accessible in child project files via 'Default_Switches. case GNAT_Version is when "5.01a" => -- WORKAROUND: GNAT 5.01a optimization bug; -- -fno-strict-aliasing avoids it. However, -- -fno-strict-aliasing is not defined in earlier GNAT -- versions. This switch is only needed for release builds -- (when optimization is enabled), but does not hurt in -- debug/test builds. Specifying it in both avoids splitting -- this file in two. for Default_Switches ("Ada") use ("-fno-strict-aliasing"); when "5.02a1" | "5.02a" | "3.16a1" | "3.15p" => end case; end Compiler; -- In project files, normally use this: -- package Compiler is -- for Default_Switches ("Ada") use Standard_Common.Compiler'Default_Switches ("Ada") & -- Standard_Common.Compiler.Base_Release_Switches & -- Standard_Common.Compiler.Style_Checks; -- end Compiler; package Binder is case OS_Version is when "Windows_98" => when "Windows_2000" | "Lynx_4.0" | "Windows_XP" => for Default_Switches ("Ada") use ("-E"); end case; Debug_Configuration_Pragmas := "Normalize_Scalars"; end Binder; -- In project files, normally use this: -- package Binder is -- for Default_Switches ("Ada") use Standard_Common.Binder'Default_Switches ("Ada"); -- end Binder; end Standard_Common; Hmm. That file is bigger than I remembered :). But it holds everything I've learned about running gnatmake. -- -- Stephe ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 0:09 ` Stephen Leake @ 2004-09-25 10:41 ` Simon Wright 0 siblings, 0 replies; 229+ messages in thread From: Simon Wright @ 2004-09-25 10:41 UTC (permalink / raw) Wow! That will take some time to digest .. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 6:24 ` Matthew Heaney 2004-09-23 11:23 ` Jeff C r e e.m @ 2004-09-23 18:24 ` Kevin Cline 1 sibling, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-23 18:24 UTC (permalink / raw) mheaney@on2.com (Matthew Heaney) wrote in message news:<1ec946d1.0409222224.6d86e038@posting.google.com>... > kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>... > > > > You can compare the implementations at > > http://www.geocities.com/kc0a/wordcount.html > > See also the latest version of the wordcount example, that compiles > against the Madison release of the AI-302 API: > > http://charles.tigris.org/source/browse/charles/src/ai302/examples/wordcount/ > > This should give you some idea of how things will work in Ada 2005. Ok, but the new code is longer than the old code. There are 150 non-blank lines in the main body, and an additional 19 lines of code in two instantiation specifications, for a total of 179 lines of code. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (4 preceding siblings ...) 2004-09-23 6:24 ` Matthew Heaney @ 2004-09-23 17:12 ` Dan Andreatta 2004-09-23 18:10 ` Pascal Obry 2004-09-23 22:34 ` Randy Brukardt ` (2 subsequent siblings) 8 siblings, 1 reply; 229+ messages in thread From: Dan Andreatta @ 2004-09-23 17:12 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) wrote in message news:<e749549b.0409211621.6f3d3723@posting.google.com>... > As promised in the Ada popularity thread, I have taken one of the > Charles examples and reimplemented it in C++. I used only the > standard C++ language and libraries. The Ada/CHARLES main program > body is 118 (non-blank) lines of code, plus an additional 40 lines of > instantiations in eight other specification files, for a total of 158 > lines and 9 files. The C++ implementation is 76 (non-blank) lines of > code in a single file. For grins, I also wrote the program in Perl. > That took 14 lines. > > Summary: > > Ada/Charles 158 lines, 9 files > C++ 76 lines > Perl 14 lines > > You can compare the implementations at > http://www.geocities.com/kc0a/wordcount.html And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. module Main where import Data.FiniteMap import Data.List import System import Char count_words :: [String] -> [(String, Integer)] count_words ws = sortBy comp $ fmToList $ addListToFM_C (+) emptyFM ws' where comp (_,n) (_,m) = compare m n ws' = zip ws [1,1..] main = do args <- getArgs f <- readFile (args!!0) putStr $ show $ take 10 $ count_words (map (map toLower) $ words f) ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 17:12 ` Dan Andreatta @ 2004-09-23 18:10 ` Pascal Obry 2004-09-23 19:21 ` Eric Jacoboni ` (4 more replies) 0 siblings, 5 replies; 229+ messages in thread From: Pascal Obry @ 2004-09-23 18:10 UTC (permalink / raw) andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. And it is just unreadable ! I just can't understand how this is supposed to work! 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] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:10 ` Pascal Obry @ 2004-09-23 19:21 ` Eric Jacoboni 2004-09-23 19:31 ` Ed Falis 2004-09-24 20:09 ` Kevin Cline 2004-09-23 19:24 ` Eric Jacoboni ` (3 subsequent siblings) 4 siblings, 2 replies; 229+ messages in thread From: Eric Jacoboni @ 2004-09-23 19:21 UTC (permalink / raw) Pascal Obry <pascal@obry.org> writes: > And it is just unreadable ! I just can't understand how this is supposed > to work! Agree... What about Ruby ? Much more readable than perl/python, imho. Its inventor claims to be inspired by Ada and Eiffel syntaxes. (i've don't find the equivalent of the perl <> construct, hence the opening of files given at the command line). I've don't managed to reduce the number of lines (it could be done...). count = Hash.new(0) ARGV.each do |a_filename| # for each filename given as argument.. File::open(a_filename) do |lines| # open it lines.each_line do |line| # for each of its lines... for word in line.split (/[^A-Za-z]+/) # get each word count[word.downcase] += 1 # update this word count end # for end # lines.each_line end # File::open end # ARGV.each sorted_count = count.sort do |pair_1, pair_2| # for each (key,value) pair pair_2[1] <=> pair_1[1] # compare their values end nb = 0 sorted_count.each do |word, nb_occ| # print the first 10 results print word, ' -> ', nb_occ, "\n" nb += 1 break if nb >= 10 end # count.each -- �ric Jacoboni, n� il y a 1399410646 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:21 ` Eric Jacoboni @ 2004-09-23 19:31 ` Ed Falis 2004-09-23 19:37 ` Eric Jacoboni 2004-09-24 20:09 ` Kevin Cline 1 sibling, 1 reply; 229+ messages in thread From: Ed Falis @ 2004-09-23 19:31 UTC (permalink / raw) On Thu, 23 Sep 2004 21:21:06 +0200, Eric Jacoboni <jaco@neottia.net> wrote: > What about Ruby ? A lot easier to follow than the perl version (or the lisp version). ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:31 ` Ed Falis @ 2004-09-23 19:37 ` Eric Jacoboni 0 siblings, 0 replies; 229+ messages in thread From: Eric Jacoboni @ 2004-09-23 19:37 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> writes: > A lot easier to follow than the perl version (or the lisp version). And that's why i use it instead of Perl ;) -- �ric Jacoboni, n� il y a 1399412243 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:21 ` Eric Jacoboni 2004-09-23 19:31 ` Ed Falis @ 2004-09-24 20:09 ` Kevin Cline 2004-09-25 0:18 ` Eric Jacoboni 1 sibling, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-24 20:09 UTC (permalink / raw) Eric Jacoboni <jaco@neottia.net> wrote in message news:<m2ekkspza5.fsf@mac.scrogneugneu.org>... > Pascal Obry <pascal@obry.org> writes: > > > And it is just unreadable ! I just can't understand how this is supposed > > to work! > > Agree... > > What about Ruby ? Much more readable than perl/python, imho. The Ruby implementation lines up with the Perl code almost token for token, except that I used the Perl <> operator, and I didn't bother storing the sort result in a variable. I agree that Ruby is slightly more readable than Perl, but I don't know about MUCH more readable. I think the use of %, @, and $ in Perl is not obvious, and the <> operator is pretty magical, but the rest of the code seems straightforward. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 20:09 ` Kevin Cline @ 2004-09-25 0:18 ` Eric Jacoboni 2004-09-26 6:37 ` Kevin Cline 0 siblings, 1 reply; 229+ messages in thread From: Eric Jacoboni @ 2004-09-25 0:18 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > The Ruby implementation lines up with the Perl code almost token for > token, except that I used the Perl <> operator, and I didn't bother > storing the sort result in a variable. Of course, as Ruby is a language of the same high level as Perl. The Perl/Ruby code sticks with the "natural" algorithm to count words... There's no much ways to achieve this problem. The most natural could be "Hey, count the different word of these files" but, unfortunately, it could be done like that (when it will be possible, well, we have to choose another job). > I agree that Ruby is slightly more readable than Perl, but I don't > know about MUCH more readable. I think the use of %, @, and $ in Perl > is not obvious, and the <> operator is pretty magical, but the rest of > the code seems straightforward. For what i know, Ruby code is /always/ more readable than Perl code, for the same level of abstraction. If you can see the difference in this simple example, imagine for scripts of hundred and hundred lines... Readibility, that's my point. Back to Ada, i'm agree with you, your Ada code is not very readable : it's to "heavy", but perhaps because Charles is not adequate here ? I wonder if using such "small" packages as gnat.htable could be more appropriate for this particular example. I'm not fond of always using the same libs for different things. But i admit i don't know Charles very well. -- �ric Jacoboni, n� il y a 1399514759 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-25 0:18 ` Eric Jacoboni @ 2004-09-26 6:37 ` Kevin Cline 2004-09-26 14:57 ` Matthew Heaney 0 siblings, 1 reply; 229+ messages in thread From: Kevin Cline @ 2004-09-26 6:37 UTC (permalink / raw) Eric Jacoboni <jaco@neottia.net> wrote in message news:<m2llezjj4t.fsf@mac.scrogneugneu.org>... > kevin.cline@gmail.com (Kevin Cline) writes: > > > > The Ruby implementation lines up with the Perl code almost token for > > token, except that I used the Perl <> operator, and I didn't bother > > storing the sort result in a variable. > > Of course, as Ruby is a language of the same high level as Perl. The > Perl/Ruby code sticks with the "natural" algorithm to count > words... There's no much ways to achieve this problem. The most natural > could be "Hey, count the different word of these files" but, > unfortunately, it could be done like that (when it will be possible, > well, we have to choose another job). > > > I agree that Ruby is slightly more readable than Perl, but I don't > > know about MUCH more readable. I think the use of %, @, and $ in Perl > > is not obvious, and the <> operator is pretty magical, but the rest of > > the code seems straightforward. > > For what i know, Ruby code is /always/ more readable than Perl code, > for the same level of abstraction. If you can see the difference in > this simple example, imagine for scripts of hundred and hundred > lines... Readibility, that's my point. I don't think it's all that important for code to be readable by someone with little experience in the language. It's nice if nothing else is sacrificed, but programmers don't remain novices for long. That said, I'm not arguing that Perl is better than Ruby. > > Back to Ada, i'm agree with you, your Ada code is not very readable : I'm not the author. The Ada code was written by Matthew Heaney, the author of Charles. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 6:37 ` Kevin Cline @ 2004-09-26 14:57 ` Matthew Heaney 0 siblings, 0 replies; 229+ messages in thread From: Matthew Heaney @ 2004-09-26 14:57 UTC (permalink / raw) kevin.cline@gmail.com (Kevin Cline) writes: > > Back to Ada, i'm agree with you, your Ada code is not very readable : > > I'm not the author. The Ada code was written by Matthew Heaney, the > author of Charles. The ARG is bandying about the idea of allowing functions to return an anonymous access type, something like: function Element (C : Cursor) return not null access Element_Type; This would allow that part of the program that increments the word count to be written like this: declare C : Cursor; B : Boolean; begin Insert (M, Word, 0, C, B); declare N : Natural renames Element (C).all; begin N := N + 1; end; end; Still not as concise as the C++ index and increment operators, but it's less verbose the original example. If we were to write the C++ example using insert(), it would look something like: typedef map_t::iterator iter_t; typedef pair<iter_t, bool> status_t; const status_t status = m.insert(make_pair(word, 0)); const iter_t& iter = status.first; int& n = iter->second; ++n; So now they don't look that much different. In fact, the 5-parameter Insert operation in the AI-302 API is modeled directly on the C++ code fragment above. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:10 ` Pascal Obry 2004-09-23 19:21 ` Eric Jacoboni @ 2004-09-23 19:24 ` Eric Jacoboni 2004-09-23 21:30 ` Eric Jacoboni 2004-09-24 8:26 ` Ole-Hjalmar Kristensen 2004-09-23 22:08 ` Anders Gidenstam ` (2 subsequent siblings) 4 siblings, 2 replies; 229+ messages in thread From: Eric Jacoboni @ 2004-09-23 19:24 UTC (permalink / raw) Pascal Obry <pascal@obry.org> writes: > And it is just unreadable ! I just can't understand how this is supposed > to work! Agree... What about Ruby ? Much more readable than perl/python, imho. Its inventor claims to be inspired by Ada and Eiffel syntaxes. (i've not find the equivalent of the perl <> construct, hence the opening of files given at the command line). I've not managed to reduce the number of lines (it could be done...). count = Hash.new(0) ARGV.each do |a_filename| # for each filename given as argument.. File::open(a_filename) do |lines| # open it lines.each_line do |line| # for each of its lines... for word in line.split (/[^A-Za-z]+/) # get each word count[word.downcase] += 1 # update this word count end # for end # lines.each_line end # File::open end # ARGV.each sorted_count = count.sort do |pair_1, pair_2| # for each (key,value) pair pair_2[1] <=> pair_1[1] # compare their values end nb = 0 sorted_count.each do |word, nb_occ| # print the first 10 results print word, ' -> ', nb_occ, "\n" nb += 1 break if nb >= 10 end # count.each -- �ric Jacoboni, n� il y a 1399410646 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:24 ` Eric Jacoboni @ 2004-09-23 21:30 ` Eric Jacoboni 2004-09-26 11:44 ` Jacob Sparre Andersen 2004-09-26 17:02 ` jayessay 2004-09-24 8:26 ` Ole-Hjalmar Kristensen 1 sibling, 2 replies; 229+ messages in thread From: Eric Jacoboni @ 2004-09-23 21:30 UTC (permalink / raw) Eric Jacoboni <jaco@neottia.net> writes: > What about Ruby ? Much more readable than perl/python, imho. Its > inventor claims to be inspired by Ada and Eiffel syntaxes. (i've not > find the equivalent of the perl <> construct, hence the opening of > files given at the command line). Ok, i've finally found the equivalent of while (<>) construct in Ruby, so the initialisation of the hash is now more concise. By using 'for' instead of iterators, the code is more Ada-ish : for a_file in ARGF do for a_line in a_file do for a_word in a_line.split(/[^A-Za-z]+/) do count[a_word.downcase] += 1 end # for a_word end # for a_line end # for a_file -- �ric Jacoboni, n� il y a 1399418449 secondes ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 21:30 ` Eric Jacoboni @ 2004-09-26 11:44 ` Jacob Sparre Andersen 2004-09-26 17:02 ` jayessay 1 sibling, 0 replies; 229+ messages in thread From: Jacob Sparre Andersen @ 2004-09-26 11:44 UTC (permalink / raw) Eric Jacoboni wrote: > for a_file in ARGF do > for a_line in a_file do > for a_word in a_line.split(/[^A-Za-z]+/) do > count[a_word.downcase] += 1 > end # for a_word > end # for a_line > end # for a_file That's reasonably readable. Probably easier to read than the Bash one-liner that I usually use for this purpose. Maybe it is worthwhile to look a bit at Ruby for text processing. Jacob -- "Any newsgroup where software developers hang out is an Emacs newsgroup." ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 21:30 ` Eric Jacoboni 2004-09-26 11:44 ` Jacob Sparre Andersen @ 2004-09-26 17:02 ` jayessay 1 sibling, 0 replies; 229+ messages in thread From: jayessay @ 2004-09-26 17:02 UTC (permalink / raw) Eric Jacoboni <jaco@neottia.net> writes: > Eric Jacoboni <jaco@neottia.net> writes: > > > What about Ruby ? Much more readable than perl/python, imho. Its > > inventor claims to be inspired by Ada and Eiffel syntaxes. Actually, Ruby is closer to Lisp than either of those. > Ok, i've finally found the equivalent of while (<>) construct in Ruby, > so the initialisation of the hash is now more concise. By using 'for' > instead of iterators, the code is more Ada-ish : > > for a_file in ARGF do > for a_line in a_file do > for a_word in a_line.split(/[^A-Za-z]+/) do > count[a_word.downcase] += 1 > end # for a_word > end # for a_line > end # for a_file (defun word-count-2 (file-spec &key (wordpat (compile-pattern "[A-Za-z]+"))) (let ((count (make-hash-table :test #'equal))) (with-open-file (the-file file-spec :direction :input) (for-each line :in the-file (for-each word :in (split-string wordpat line) (incf (gethash (string-downcase word) count 0))))) (let ((topten (subseq (sort (all (w c) :in count) #'> :key 'second) 0 10))) (for-each pair :in topten (print pair))))) Just curious, do people who had "trouble" with the first version find this one as "clear" as the Ruby? Note: the part that is the same as the above Ruby is just: (with-open-file (the-file file-spec :direction :input) (for-each line :in the-file (for-each word :in (split-string wordpat line) (incf (gethash (string-downcase word) count 0))))) /Jon -- 'j' - a n t h o n y at romeo/charley/november com ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 19:24 ` Eric Jacoboni 2004-09-23 21:30 ` Eric Jacoboni @ 2004-09-24 8:26 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 229+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-24 8:26 UTC (permalink / raw) Awk/shell version, snipped from Emacs info pages: # Print list of word frequencies { $0 = tolower($0) # remove case distinctions gsub(/[^a-z0-9_ \t]/, "", $0) # remove punctuation for (i = 1; i <= NF; i++) freq[$i]++ } END { sort = "sort +1 -nr" for (word in freq) printf "%s\t%d\n", word, freq[word] | sort close(sort) } -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:10 ` Pascal Obry 2004-09-23 19:21 ` Eric Jacoboni 2004-09-23 19:24 ` Eric Jacoboni @ 2004-09-23 22:08 ` Anders Gidenstam 2004-09-24 8:10 ` Ole-Hjalmar Kristensen 2004-09-24 17:40 ` Dan Andreatta 4 siblings, 0 replies; 229+ messages in thread From: Anders Gidenstam @ 2004-09-23 22:08 UTC (permalink / raw) In article <u6564dfge.fsf@obry.org>, Pascal Obry <pascal@obry.org> writes: > > andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > >> And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. > > And it is just unreadable ! I just can't understand how this is supposed > to work! It is not all that horrible once you realize that $ is function application, for example putStr $ show $ take 10 $ count_words (map (map toLower) $ words f) can also be written putStr (show (take 10 (count_words (map (map toLower) (words f))))) Still, I'm not sure Dan's version behaves as expected since it sometimes treats non-alphabetic characters as words. Here is another Haskell version and this time in pure Haskell 98 at the expense of one more line. Enjoy! module Main where import System import List import Char count_words :: [String] -> [(Int, String)] count_words xs = sortBy comp $ init $ foldr count_same [(0, "")] $ sort xs where count_same w1 (y1@(c, w2):ys) = if (w1 == w2) then (c + 1, w1):ys else (1,w1):y1:ys comp (c1, _) (c2, _) = compare c2 c1 main = do args <- getArgs f <- readFile (args!!0) putStr $ concat $ map prettyShow $ take 10 $ count_words $ wordify f where wordify xs = words $ map toLower $ map onlyAlpha xs onlyAlpha x = if isAlpha x then x else ' ' prettyShow (c,w) = w ++ " " ++ show c ++ "\n" Well, I think it is nifty even if you don't :) /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] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:10 ` Pascal Obry ` (2 preceding siblings ...) 2004-09-23 22:08 ` Anders Gidenstam @ 2004-09-24 8:10 ` Ole-Hjalmar Kristensen 2004-09-24 17:43 ` Dan Andreatta 2004-09-24 17:40 ` Dan Andreatta 4 siblings, 1 reply; 229+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-09-24 8:10 UTC (permalink / raw) Pascal Obry <pascal@obry.org> writes: > andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > > > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. > > And it is just unreadable ! I just can't understand how this is supposed > to work! > > Pascal. > Which just shows that any sufficiently advanced technology is indistinguishable from magic :-) > -- > > --|------------------------------------------------------ > --| 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 -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 8:10 ` Ole-Hjalmar Kristensen @ 2004-09-24 17:43 ` Dan Andreatta 0 siblings, 0 replies; 229+ messages in thread From: Dan Andreatta @ 2004-09-24 17:43 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote in message news:<wvbr1xgsnl2u.fsf@ellex06.Norway.Sun.COM>... > Pascal Obry <pascal@obry.org> writes: > > > andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > > > > > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. > > > > And it is just unreadable ! I just can't understand how this is supposed > > to work! > > > > Pascal. > > > > Which just shows that any sufficiently advanced technology is > indistinguishable from magic :-) > Can I take that as a compliment? ;-) (When I was a kid I wanted to be a magician) ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 18:10 ` Pascal Obry ` (3 preceding siblings ...) 2004-09-24 8:10 ` Ole-Hjalmar Kristensen @ 2004-09-24 17:40 ` Dan Andreatta 2004-09-24 18:50 ` Pascal Obry 4 siblings, 1 reply; 229+ messages in thread From: Dan Andreatta @ 2004-09-24 17:40 UTC (permalink / raw) Pascal Obry <pascal@obry.org> wrote in message news:<u6564dfge.fsf@obry.org>... > andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > > > And I write it in Haskell. 14 lines. OK, I cheated, I used GHC libraries. > > And it is just unreadable ! I just can't understand how this is supposed > to work! > > Pascal. I understand. Functional languages require a change in prospective. But also I made unreadable to have a less lines :-). Hope now you find it more readable. Here is slightly rewritten: module Main where import Data.FiniteMap import Data.List import System import Char count_words :: [String] -> [(String, Integer)] count_words ws = wc where comp (_,n) (_,m) = compare m n -- used in sortBy to sort -- the values, not keys ws' = zip ws [1,1..] -- creates a list [("word",1),("word",1)...] -- In functional languages the hash table is substituted with a -- finite map -- emptyFM creates an empty finite map -- addToFM adds an element in the form (key, value) to a -- finite map. If the element already exists, -- it is replaced by the new one. -- addListToFM adds a list of elements, -- [(key, value), (key, value)...] -- addListToFM_C instead applies an operation (e.g. +) between -- the values of the old and new elements with the same key. -- Since every key has value 1, -- we count the number of keys in the list. fm = addListToFM_C (+) emptyFM ws' list = fmToList fm -- Creates a list from the finite map in the -- form [(key,value)], with the keys ordered. wc = sortBy comp list -- sort the list in ascending order -- of the values. -- this to take care of alphanumeric symbols. -- Replace them with spaces. removeSymbol x = if isAlphaNum x then x else ' ' main = do args <- getArgs -- get the command line arguments as -- a list of strings. f <- readFile (args!!0) -- the first one is the one we want. -- And read the whole file and -- return a String let f1 = map (removeSymbol.toLower) f -- convert to lowercase and substitue spaces -- for symbols. For every character, convert -- it to lowercase and remove it if a symbol let f2 = words f1 -- divide the string in a list of strings let wc = count_words f2 let wc10 = take 10 wc -- take only the first ten elements putStrLn ( show wc10 ) -- and print them ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 17:40 ` Dan Andreatta @ 2004-09-24 18:50 ` Pascal Obry 0 siblings, 0 replies; 229+ messages in thread From: Pascal Obry @ 2004-09-24 18:50 UTC (permalink / raw) andreatta@mail.chem.sc.edu (Dan Andreatta) writes: > I understand. Functional languages require a change in prospective. > But also I made unreadable to have a less lines :-). Hope now you find > it more readable. Let's say a very little bit more :) 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] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (5 preceding siblings ...) 2004-09-23 17:12 ` Dan Andreatta @ 2004-09-23 22:34 ` Randy Brukardt 2004-09-23 23:11 ` Dale Stanbrough ` (2 more replies) 2004-09-26 11:09 ` Jacob Sparre Andersen 2004-10-12 5:21 ` Ada Popularity: Comparison of languages Brian May 8 siblings, 3 replies; 229+ messages in thread From: Randy Brukardt @ 2004-09-23 22:34 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0409211621.6f3d3723@posting.google.com... > As promised in the Ada popularity thread, I have taken one of the > Charles examples and reimplemented it in C++. I used only the > standard C++ language and libraries. The Ada/CHARLES main program > body is 118 (non-blank) lines of code, plus an additional 40 lines of > instantiations in eight other specification files, for a total of 158 > lines and 9 files. Why were all of the files needed? For a program of this size, I would have nested the specifications in the body. (One possible reason was the old restriction on nesting of tagged type extensions. Ada 2005 has eliminated this restriction, so that particular issue will go away soon.) Randy. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 22:34 ` Randy Brukardt @ 2004-09-23 23:11 ` Dale Stanbrough 2004-09-24 1:57 ` Matthew Heaney 2004-09-24 0:43 ` Jeffrey Carter 2004-09-24 1:51 ` Matthew Heaney 2 siblings, 1 reply; 229+ messages in thread From: Dale Stanbrough @ 2004-09-23 23:11 UTC (permalink / raw) In article <AMqdnUutfbXY0s7cRVn-vA@megapath.net>, "Randy Brukardt" <randy@rrsoftware.com> wrote: > Why were all of the files needed? For a program of this size, I would have > nested the specifications in the body. (One possible reason was the old > restriction on nesting of tagged type extensions. Ada 2005 has eliminated > this restriction, so that particular issue will go away soon.) > > Randy. Talking about removing restrictions - will Ada 2005 allow for downward closures (I read that the one reason for it's exclusion was a compiler which is no longer with us). Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 23:11 ` Dale Stanbrough @ 2004-09-24 1:57 ` Matthew Heaney 2004-09-24 6:32 ` Dale Stanbrough 0 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 1:57 UTC (permalink / raw) Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes: > Talking about removing restrictions - will Ada 2005 allow for downward > closures (I read that the one reason for it's exclusion was a compiler > which is no longer with us). Yes. The only caveat is that the procedure pointer cannot be copied. AI-302 depends on this new feature. For example, the passive iterator looks like this: procedure Iterate (Container : in CT; Process : not null access procedure (Position : in Cursor)); There are procedures for querying and modifying the element at a position, that look like this: procedure Query_Element (Position : in Cursor; Process : not null access procedure (Element : in Element_Type)); procedure Update_Element (Position : in Cursor; Process : not null access procedure (Element : in out Element_Type)); -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 1:57 ` Matthew Heaney @ 2004-09-24 6:32 ` Dale Stanbrough 2004-09-24 21:01 ` Randy Brukardt 0 siblings, 1 reply; 229+ messages in thread From: Dale Stanbrough @ 2004-09-24 6:32 UTC (permalink / raw) Matthew Heaney wrote: > Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes: > > > Talking about removing restrictions - will Ada 2005 allow for downward > > closures (I read that the one reason for it's exclusion was a compiler > > which is no longer with us). > > Yes. The only caveat is that the procedure pointer cannot be copied. How is this enforced? > AI-302 depends on this new feature. For example, the passive iterator > looks like this: > > procedure Iterate > (Container : in CT; > Process : not null access procedure (Position : in Cursor)); Can you specify a type for the procedure pointer? e.g. type Proc_Ptr is access procedure (Position : in Cursor); procedure Iterate (Container : in CT; Process : not null Proc_Ptr); Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 6:32 ` Dale Stanbrough @ 2004-09-24 21:01 ` Randy Brukardt 0 siblings, 0 replies; 229+ messages in thread From: Randy Brukardt @ 2004-09-24 21:01 UTC (permalink / raw) "Dale Stanbrough" <MrNoSpam@bigpoop.net.au> wrote in message news:MrNoSpam-4FAA69.16322324092004@news-server.bigpond.net.au... > Matthew Heaney wrote: > > > Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes: > > > > > Talking about removing restrictions - will Ada 2005 allow for downward > > > closures (I read that the one reason for it's exclusion was a compiler > > > which is no longer with us). > > > > Yes. The only caveat is that the procedure pointer cannot be copied. > > How is this enforced? Via accessibility. The accessibility of an anonymous access-to-subprogram used as a parameter is infinite, so you can put anything into it (of course), but you are not allowed to convert to another type (unless it too is anonymous access-to-subprogram used as a parameter). > > AI-302 depends on this new feature. For example, the passive iterator > > looks like this: > > > > procedure Iterate > > (Container : in CT; > > Process : not null access procedure (Position : in Cursor)); > > > Can you specify a type for the procedure pointer? > e.g. > > type Proc_Ptr is access procedure (Position : in Cursor); > procedure Iterate > (Container : in CT; > Process : not null Proc_Ptr); You can do that, but you get the Ada 95 accessibility rules. That's necessary as access-to-subprogram is often used to interface to C or other foreign code, and thus those types must be implementable as thin pointers (just a subprogram address for most targets). An anonymous access-to-subprogram used as a parameter will need to be some sort of fat structure including a display or static link (and, for Janus/Ada and other generic sharing implementations, a generic instance descriptor) along with the subprogram address. You can go from thin to fat by creating the needed structures based on the type, but you can't go the other way (because you can't call a nested routine without all the stuff in the structure). ("not null" is optional of course; if you want to be able to pass null for some meaning. I use this sort of structure for debugging logging routines in my spam filter; I pass null to mean "don't log anything". So I'd omit the "not null" in that case.) Randy. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 22:34 ` Randy Brukardt 2004-09-23 23:11 ` Dale Stanbrough @ 2004-09-24 0:43 ` Jeffrey Carter 2004-09-24 1:51 ` Matthew Heaney 2 siblings, 0 replies; 229+ messages in thread From: Jeffrey Carter @ 2004-09-24 0:43 UTC (permalink / raw) Randy Brukardt wrote: > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0409211621.6f3d3723@posting.google.com... > >>As promised in the Ada popularity thread, I have taken one of the >>Charles examples and reimplemented it in C++. I used only the >>standard C++ language and libraries. The Ada/CHARLES main program >>body is 118 (non-blank) lines of code, plus an additional 40 lines of >>instantiations in eight other specification files, for a total of 158 >>lines and 9 files. > > Why were all of the files needed? For a program of this size, I would have > nested the specifications in the body. (One possible reason was the old > restriction on nesting of tagged type extensions. Ada 2005 has eliminated > this restriction, so that particular issue will go away soon.) I have implemented a word counting program in Ada that requires 64 statements in 3 files (the extra files are needed because of the current rules about extending tagged types). This is possible because of the existence of PragmARC.Word_Input. -- Jeff Carter "C++: The power, elegance and simplicity of a hand grenade." Ole-Hjalmar Kristensen 90 ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-23 22:34 ` Randy Brukardt 2004-09-23 23:11 ` Dale Stanbrough 2004-09-24 0:43 ` Jeffrey Carter @ 2004-09-24 1:51 ` Matthew Heaney 2004-09-24 20:21 ` Kevin Cline 2 siblings, 1 reply; 229+ messages in thread From: Matthew Heaney @ 2004-09-24 1:51 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Why were all of the files needed? For a program of this size, I would > have nested the specifications in the body. (One possible reason was > the old restriction on nesting of tagged type extensions. Ada 2005 has > eliminated this restriction, so that particular issue will go away > soon.) Yes, the map instantiation was done at library level. However, Kevin's file count appears to include all of the files in the closure of the program, which means he's counting all the stuff in ada.containers.*. This isn't really fair, since he didn't count all the myriad files in the STL. Once the AI about nested instantiations gets approved, then the actual, correct file count should only be 1. -Matt ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-24 1:51 ` Matthew Heaney @ 2004-09-24 20:21 ` Kevin Cline 0 siblings, 0 replies; 229+ messages in thread From: Kevin Cline @ 2004-09-24 20:21 UTC (permalink / raw) Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<uu0tob9on.fsf@earthlink.net>... > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > Why were all of the files needed? For a program of this size, I would > > have nested the specifications in the body. (One possible reason was > > the old restriction on nesting of tagged type extensions. Ada 2005 has > > eliminated this restriction, so that particular issue will go away > > soon.) > > Yes, the map instantiation was done at library level. > > However, Kevin's file count appears to include all of the files in the > closure of the program, which means he's counting all the stuff in > ada.containers.*. This isn't really fair, since he didn't count all the > myriad files in the STL. I only counted the files in examples/wordcount_vector. The first version I saw had a main body and eight specification files. The current version has a main body and two specification files. ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (6 preceding siblings ...) 2004-09-23 22:34 ` Randy Brukardt @ 2004-09-26 11:09 ` Jacob Sparre Andersen 2004-09-27 13:49 ` Björn Persson 2004-10-12 5:21 ` Ada Popularity: Comparison of languages Brian May 8 siblings, 1 reply; 229+ messages in thread From: Jacob Sparre Andersen @ 2004-09-26 11:09 UTC (permalink / raw) Kevin Cline wrote: > As promised in the Ada popularity thread, I have taken one of the > Charles examples and reimplemented it in C++. I used only the > standard C++ language and libraries. The Ada/CHARLES main program > body is 118 (non-blank) lines of code, plus an additional 40 lines > of instantiations in eight other specification files, for a total of > 158 lines and 9 files. The C++ implementation is 76 (non-blank) > lines of code in a single file. For grins, I also wrote the program > in Perl. That took 14 lines. > > Summary: > > Ada/Charles 158 lines, 9 files > C++ 76 lines > Perl 14 lines If we really have to compete about the shortest implementation, then Bash with GNU tools beats all these languages: tr -c 'A-Za-z' '\n' | grep -v '^$' | sort | uniq -c | sort -nr | head And I suppose that anybody with a minimum of knowledge of Bash and the GNU tools will understand this immediately. But does that tell us that Bash is an excellent tool for controlling nuclear reactors, medical equipment, or just plain bioinformatics software? At most it tells us that if you just want to count words, Bash is probably a better implementation language than Ada, C++ or Perl. Jacob PS: The Bash version is also rather easy to internationalize. Just substitute 'A-Za-z' with '[[:lower:][:upper:]]'. -- LDraw.org Parts Tracker FAQ: http://www.ldraw.org/library/tracker/ref/faq/ ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) 2004-09-26 11:09 ` Jacob Sparre Andersen @ 2004-09-27 13:49 ` Björn Persson 0 siblings, 0 replies; 229+ messages in thread From: Björn Persson @ 2004-09-27 13:49 UTC (permalink / raw) Jacob Sparre Andersen wrote: > But does that tell us that Bash is an excellent tool for controlling > nuclear reactors, medical equipment, or just plain bioinformatics > software? Of course not, but maybe for less life critical applications, particularly text processing applications. ;-) An IDE written in Bash, anyone? ;-) -- Björn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of languages 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline ` (7 preceding siblings ...) 2004-09-26 11:09 ` Jacob Sparre Andersen @ 2004-10-12 5:21 ` Brian May 2004-10-12 11:43 ` Peter Hermann 8 siblings, 1 reply; 229+ messages in thread From: Brian May @ 2004-10-12 5:21 UTC (permalink / raw) Somebody really has ***too*** much time... See <URL:http://www.99-bottles-of-beer.net/>. There are two versions in Ada ;-). -- Brian May <bam@snoopy.apana.org.au> ^ permalink raw reply [flat|nested] 229+ messages in thread
* Re: Ada Popularity: Comparison of languages 2004-10-12 5:21 ` Ada Popularity: Comparison of languages Brian May @ 2004-10-12 11:43 ` Peter Hermann 0 siblings, 0 replies; 229+ messages in thread From: Peter Hermann @ 2004-10-12 11:43 UTC (permalink / raw) Brian May <bam@snoopy.apana.org.au> wrote: > Somebody really has ***too*** much time... > > See <URL:http://www.99-bottles-of-beer.net/>. > > There are two versions in Ada ;-). reload (-: http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html at end :-) -- --Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de --Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen --http://www.csv.ica.uni-stuttgart.de/homes/ph/ --Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 229+ messages in thread
end of thread, other threads:[~2004-10-28 10:26 UTC | newest] Thread overview: 229+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-22 0:21 Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Kevin Cline 2004-09-22 2:16 ` Pylinius 2004-09-22 8:50 ` Björn Persson 2004-09-22 13:38 ` Benjamin Ketcham 2004-09-22 14:07 ` Hyman Rosen 2004-09-22 15:16 ` Cesar Rabak 2004-09-23 8:22 ` Kevin Cline 2004-09-23 10:52 ` Anders Wirzenius 2004-09-23 10:54 ` stephane richard 2004-09-23 11:17 ` Jean-Pierre Rosen 2004-09-23 11:47 ` Marius Amado Alves 2004-09-23 13:34 ` Anders Wirzenius 2004-09-23 16:53 ` Warren W. Gay VE3WWG 2004-09-23 18:30 ` Kevin Cline 2004-09-23 19:00 ` Marius Amado Alves 2004-09-24 6:04 ` [OT]Screen ergonomics, was " Anders Wirzenius 2004-09-26 7:22 ` Kevin Cline 2004-09-23 17:19 ` Cesar Rabak 2004-09-23 8:51 ` Kevin Cline 2004-09-23 11:01 ` Georg Bauhaus 2004-09-23 15:59 ` Matthew Heaney 2004-09-23 16:38 ` Kevin Cline 2004-09-24 2:47 ` Matthew Heaney 2004-09-24 13:43 ` Hyman Rosen 2004-09-24 17:47 ` Mark Lorenzen 2004-09-24 18:16 ` Matthew Heaney 2004-09-29 19:29 ` Mark Lorenzen 2004-09-29 22:44 ` Matthew Heaney 2004-09-25 14:09 ` Martin Krischik 2004-09-26 7:08 ` Kevin Cline 2004-09-26 15:13 ` Matthew Heaney 2004-09-23 19:10 ` jayessay 2004-09-23 21:13 ` Adam Ruth 2004-09-27 2:12 ` Keith H Duggar 2004-09-27 14:21 ` Adam Ruth 2004-09-27 14:51 ` Chris Humphries 2004-09-27 17:10 ` Adam Ruth 2004-09-27 20:16 ` Keith H Duggar 2004-09-27 21:15 ` Chris Humphries 2004-09-28 4:46 ` Keith H Duggar 2004-09-27 20:34 ` Kevin Cline 2004-09-27 21:15 ` Adam Ruth 2004-09-23 23:05 ` Brian May 2004-09-24 3:06 ` Matthew Heaney 2004-09-24 3:52 ` Randy Brukardt 2004-09-24 5:15 ` Matthew Heaney 2004-09-24 19:12 ` Kevin Cline 2004-09-24 20:54 ` Randy Brukardt 2004-09-24 21:23 ` Matthew Heaney 2004-09-27 13:22 ` Chris Humphries 2004-09-27 13:45 ` Chris Humphries 2004-09-27 21:31 ` Kevin Cline 2004-09-27 23:51 ` Brian May 2004-09-28 12:21 ` Chris Humphries 2004-09-26 17:10 ` jayessay 2004-09-26 20:00 ` Georg Bauhaus 2004-09-27 14:45 ` jayessay 2004-09-24 0:19 ` Stephen Leake 2004-09-24 14:54 ` Cesar Rabak 2004-09-22 15:27 ` James Alan Farrell 2004-09-22 21:24 ` Simon Wright 2004-09-23 0:03 ` Brian May 2004-09-23 9:17 ` Kevin Cline 2004-09-23 0:44 ` Jeffrey Carter 2004-09-23 11:08 ` Georg Bauhaus 2004-09-23 8:15 ` Martin Krischik 2004-09-23 16:20 ` Matthew Heaney 2004-09-23 19:23 ` Simon Wright 2004-09-24 7:19 ` Martin Krischik 2004-09-24 16:31 ` Matthew Heaney 2004-09-24 19:24 ` Kevin Cline 2004-09-25 14:04 ` Martin Krischik 2004-09-26 10:36 ` Robert Kawulak 2004-09-26 15:35 ` Martin Krischik 2004-09-28 17:46 ` Robert Kawulak 2004-09-29 7:49 ` Martin Krischik 2004-09-29 12:01 ` Xenos 2004-09-29 18:16 ` Robert Kawulak 2004-09-30 15:55 ` Martin Krischik 2004-09-27 22:22 ` Kevin Cline 2004-09-28 7:51 ` Martin Krischik 2004-09-29 3:04 ` Kevin Cline 2004-09-29 6:03 ` Dale Stanbrough 2004-09-29 13:31 ` Georg Bauhaus 2004-09-29 13:46 ` Matthew Heaney 2004-09-30 3:42 ` Kevin Cline 2004-09-30 7:54 ` Dale Stanbrough 2004-09-30 16:50 ` Matthew Heaney 2004-10-01 0:04 ` Kevin Cline 2004-10-01 12:25 ` Georg Bauhaus 2004-10-02 7:35 ` K 2004-10-02 10:00 ` Brian May 2004-10-02 20:39 ` Kevin Cline 2004-10-03 2:17 ` Brian May 2004-10-02 13:40 ` Matthew Heaney 2004-10-02 23:33 ` Randy Brukardt 2004-10-03 12:47 ` Stephen Leake 2004-09-30 19:01 ` Björn Persson 2004-09-30 23:54 ` Kevin Cline 2004-10-01 16:11 ` Björn Persson 2004-10-02 6:48 ` K 2004-10-02 10:41 ` Björn Persson 2004-10-02 13:32 ` Matthew Heaney 2004-10-04 9:02 ` Ole-Hjalmar Kristensen 2004-09-23 9:00 ` Kevin Cline 2004-09-23 11:27 ` Ole-Hjalmar Kristensen 2004-09-23 19:11 ` Kevin Cline 2004-09-23 21:01 ` Alexander E. Kopilovich 2004-09-26 6:53 ` Kevin Cline 2004-09-26 15:29 ` Alexander E. Kopilovich 2004-09-23 21:54 ` Eric Jacoboni 2004-09-24 9:44 ` Ole-Hjalmar Kristensen 2004-09-24 9:50 ` Georg Bauhaus 2004-09-24 13:47 ` Matthew Heaney 2004-09-24 14:14 ` Dmitry A. Kazakov 2004-09-25 14:17 ` Martin Krischik 2004-09-27 8:12 ` Dmitry A. Kazakov 2004-09-27 12:59 ` Georg Bauhaus 2004-09-27 13:53 ` Dmitry A. Kazakov 2004-09-26 7:17 ` Kevin Cline 2004-09-27 8:19 ` Dmitry A. Kazakov 2004-09-27 13:03 ` Georg Bauhaus 2004-09-27 14:00 ` Dmitry A. Kazakov 2004-09-24 16:28 ` Kevin Cline 2004-09-24 17:45 ` Georg Bauhaus 2004-09-24 20:14 ` Matthew Heaney 2004-09-24 20:10 ` Frank J. Lhota 2004-09-27 8:29 ` Dmitry A. Kazakov 2004-09-26 7:13 ` Kevin Cline 2004-09-26 15:15 ` Matthew Heaney 2004-09-27 14:31 ` Kevin Cline 2004-09-27 15:05 ` Dmitry A. Kazakov 2004-09-28 4:22 ` Kevin Cline 2004-09-28 8:20 ` Dmitry A. Kazakov 2004-09-28 23:26 ` Robert Kawulak 2004-09-29 12:19 ` Dmitry A. Kazakov 2004-09-30 18:52 ` Robert Kawulak 2004-10-01 7:55 ` Dmitry A. Kazakov 2004-10-03 19:35 ` Robert Kawulak 2004-10-04 10:24 ` Dmitry A. Kazakov 2004-10-06 17:28 ` Robert Kawulak 2004-10-07 8:24 ` Dmitry A. Kazakov 2004-10-10 21:09 ` Robert Kawulak 2004-10-11 8:08 ` Dmitry A. Kazakov 2004-10-15 9:34 ` Robert Kawulak 2004-10-15 16:58 ` Martin Krischik 2004-09-29 15:44 ` Matthew Heaney 2004-09-30 18:27 ` Robert Kawulak 2004-09-28 17:21 ` Robert Kawulak 2004-09-29 1:38 ` Georg Bauhaus 2004-09-29 18:08 ` Robert Kawulak 2004-09-30 18:30 ` Georg Bauhaus 2004-09-29 8:08 ` Dmitry A. Kazakov 2004-09-29 18:11 ` Robert Kawulak 2004-09-30 8:57 ` Dmitry A. Kazakov [not found] ` <cji06f$17a$2@atlantis.news.tpi.pl> 2004-10-01 8:58 ` Dmitry A. Kazakov 2004-10-03 19:53 ` Robert Kawulak 2004-10-04 10:15 ` Dmitry A. Kazakov 2004-10-04 12:16 ` Matthew Heaney 2004-10-04 13:21 ` Dmitry A. Kazakov 2004-10-06 17:20 ` Robert Kawulak 2004-10-07 10:08 ` Dmitry A. Kazakov 2004-10-10 22:21 ` Robert Kawulak 2004-10-11 8:46 ` Dmitry A. Kazakov 2004-10-15 9:25 ` Robert Kawulak 2004-10-15 11:56 ` Dmitry A. Kazakov 2004-10-20 20:06 ` Robert Kawulak 2004-10-21 2:51 ` Kevin Cline 2004-10-21 8:39 ` Dmitry A. Kazakov 2004-10-27 21:41 ` Robert Kawulak 2004-10-01 13:02 ` Robert Kawulak 2004-10-28 10:26 ` Larry Kilgallen 2004-09-27 16:21 ` Matthew Heaney 2004-09-28 2:47 ` Kevin Cline 2004-09-28 4:03 ` Brian May 2004-09-28 4:46 ` Matthew Heaney 2004-09-29 3:14 ` Kevin Cline 2004-09-29 3:50 ` Matthew Heaney 2004-09-29 3:52 ` Matthew Heaney 2004-09-29 13:44 ` Matthew Heaney 2004-09-26 6:32 ` Kevin Cline 2004-09-26 15:05 ` Matthew Heaney 2004-09-27 14:35 ` Kevin Cline 2004-09-23 19:30 ` jayessay 2004-09-23 19:42 ` Alexander E. Kopilovich 2004-09-22 21:05 ` Georg Bauhaus 2004-09-23 9:20 ` Kevin Cline 2004-09-23 16:58 ` Warren W. Gay VE3WWG 2004-09-23 6:24 ` Matthew Heaney 2004-09-23 11:23 ` Jeff C r e e.m 2004-09-23 11:35 ` Georg Bauhaus 2004-09-23 17:05 ` Pascal Obry 2004-09-23 17:07 ` Pascal Obry 2004-09-23 18:30 ` Matthew Heaney 2004-09-23 19:31 ` Simon Wright 2004-09-24 0:09 ` Stephen Leake 2004-09-25 10:41 ` Simon Wright 2004-09-23 18:24 ` Kevin Cline 2004-09-23 17:12 ` Dan Andreatta 2004-09-23 18:10 ` Pascal Obry 2004-09-23 19:21 ` Eric Jacoboni 2004-09-23 19:31 ` Ed Falis 2004-09-23 19:37 ` Eric Jacoboni 2004-09-24 20:09 ` Kevin Cline 2004-09-25 0:18 ` Eric Jacoboni 2004-09-26 6:37 ` Kevin Cline 2004-09-26 14:57 ` Matthew Heaney 2004-09-23 19:24 ` Eric Jacoboni 2004-09-23 21:30 ` Eric Jacoboni 2004-09-26 11:44 ` Jacob Sparre Andersen 2004-09-26 17:02 ` jayessay 2004-09-24 8:26 ` Ole-Hjalmar Kristensen 2004-09-23 22:08 ` Anders Gidenstam 2004-09-24 8:10 ` Ole-Hjalmar Kristensen 2004-09-24 17:43 ` Dan Andreatta 2004-09-24 17:40 ` Dan Andreatta 2004-09-24 18:50 ` Pascal Obry 2004-09-23 22:34 ` Randy Brukardt 2004-09-23 23:11 ` Dale Stanbrough 2004-09-24 1:57 ` Matthew Heaney 2004-09-24 6:32 ` Dale Stanbrough 2004-09-24 21:01 ` Randy Brukardt 2004-09-24 0:43 ` Jeffrey Carter 2004-09-24 1:51 ` Matthew Heaney 2004-09-24 20:21 ` Kevin Cline 2004-09-26 11:09 ` Jacob Sparre Andersen 2004-09-27 13:49 ` Björn Persson 2004-10-12 5:21 ` Ada Popularity: Comparison of languages Brian May 2004-10-12 11:43 ` Peter Hermann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox