* Please Help. @ 1997-09-09 0:00 Ken 1997-09-09 0:00 ` Stephen Leake 1997-09-09 0:00 ` Dale Stanbrough 0 siblings, 2 replies; 24+ messages in thread From: Ken @ 1997-09-09 0:00 UTC (permalink / raw) with Text_IO; use Text_IO; Procedure GetName is Name : String(1..12); begin Put("Please enter name : "); Get(Name); end GetName; You probably see the problem now. How would you just Get(Name) with different lengths and compares them. Thank you for your help. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-09 0:00 Please Help Ken @ 1997-09-09 0:00 ` Stephen Leake 1997-09-09 0:00 ` Dale Stanbrough 1 sibling, 0 replies; 24+ messages in thread From: Stephen Leake @ 1997-09-09 0:00 UTC (permalink / raw) Ken wrote: > > with Text_IO; > use Text_IO; > Procedure GetName is > Name : String(1..12); > begin > Put("Please enter name : "); > Get(Name); > end GetName; > > You probably see the problem now. How would you just Get(Name) with > different lengths and compares them. > > Thank you for your help. check out Text_IO.Get_Line: procedure Get_Line(Item : out String; Last : out Natural); This reads an entire line from the input, and tells you how many characters it has. -- - Stephe ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-09 0:00 Please Help Ken 1997-09-09 0:00 ` Stephen Leake @ 1997-09-09 0:00 ` Dale Stanbrough 1997-09-11 0:00 ` Robert Dewar 1 sibling, 1 reply; 24+ messages in thread From: Dale Stanbrough @ 1997-09-09 0:00 UTC (permalink / raw) "with Text_IO; use Text_IO; Procedure GetName is Name : String(1..12); begin Put("Please enter name : "); Get(Name); end GetName; Simple answer: with Text_IO; use Text_IO; Procedure GetName is Name : String(1..12); Last : Natural; begin Put ("Please enter name : "); Get_Line (Name, Last); Put ("Hello "); Put_Line (Name (1..Last)); end GetName; Long answer: If you want to deal with variable length data like this (esp store it in a record) then use an appropriate type, rather than string, e.g. Unbounded_String. with Text_IO; use Text_IO; with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; with Unbounded_IO; use Unbounded_IO; Procedure GetName is Name : Unbounded_String; begin Put ("Please enter name : "); Get_Line (Name); Put ("Hello "); Put_Line (Name); end GetName; (note that Unbounded_IO is a simple package that i wrote). In my experience variable length string handling is one thing that has turned students off Ada a lot. Unbounded_String is a godsend in this respect. It's a pity that a standard I/O package wasn't defined in the standard for this type. Dale ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-09 0:00 ` Dale Stanbrough @ 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Tristan Ludowyk 1997-09-15 0:00 ` Richard A. O'Keefe 0 siblings, 2 replies; 24+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) Dale says <<(note that Unbounded_IO is a simple package that i wrote). In my experience variable length string handling is one thing that has turned students off Ada a lot. Unbounded_String is a godsend in this respect. It's a pity that a standard I/O package wasn't defined in the standard for this type.>> I actually find such claims incredible. I would never introduce Unbounded_String to students till quite late in the class, since this kind of concentration on featurism is exactly what you do NOT want to teach students. Sure you introduce examples of abstractions to teach students, but this is a bad example, because it has too much complexity (particularly the reliance on controlled types). To me, the idea that a student can be turned off because of a lack of some particular feature in a language is like saying that students are turned off chemistry because they have trouble with the analysis of one particular compound. Dale, are you really speaking from experience here? your own perhaps? or from experience teaching. My own experience is that the one thing that turns on or turns off students most is the professor. A bad professor can make Ada a catastrophe from the students point of view, a good one could teach 1401 Autocoder, and the students would be happy. Of course students are not the ones to be able to judge curriculum content in any case. I do think that it is nice for students to be able to write interesting programs without too much fuss, but unbounded strings are hardly a prerequisite to this! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-11 0:00 ` Robert Dewar @ 1997-09-12 0:00 ` Tristan Ludowyk 1997-09-12 0:00 ` Dale Stanbrough 1997-09-12 0:00 ` Robert Dewar 1997-09-15 0:00 ` Richard A. O'Keefe 1 sibling, 2 replies; 24+ messages in thread From: Tristan Ludowyk @ 1997-09-12 0:00 UTC (permalink / raw) Robert Dewar (dewar@merv.cs.nyu.edu) wrote: : Dale says : : <<(note that Unbounded_IO is a simple package that i wrote). In my : experience variable length string handling is one thing that has : turned students off Ada a lot. Unbounded_String is a godsend in : this respect. It's a pity that a standard I/O package wasn't : defined in the standard for this type.>> : : I actually find such claims incredible. I would never introduce : Unbounded_String to students till quite late in the class, since : this kind of concentration on featurism is exactly what you do NOT : want to teach students. Sure you introduce examples of abstractions : to teach students, but this is a bad example, because it has too : much complexity (particularly the reliance on controlled types). As a new Ada programmer and a student of Dale's I feel I should say something here. Firstly, I would say that variable length string handling is something that all students should become accustomed to using the basic string type which teaches the concepts of how a string is stored in memory and basic techniques for getting around these problems. This is how I was taught - it wasn't until I had been using these techniques for 1/2 a year that the concept of Unbounded_Strings was introduced to me. I believe that this is not too "early" since it presents a cleaner way of handling strings, but the student still has the knowledge of how to handle normal strings. Secondly, is it really necessary for the student to understand all the inner workings of the Unbounded_String before they use it in their code? Surely they can safely use them and familiarise themselves without doing any harm to the development of their programming technique. : To me, the idea that a student can be turned off because of a lack of : some particular feature in a language is like saying that students : are turned off chemistry because they have trouble with the analysis : of one particular compound. I do not find this analogy so absurd. For instance a chem. student having slight trouble with their analysis of a compound using a particular method of analysis might try a different method. Either method (language) may have its good and bad points, but for a student to give up on one particular method because of one trivial problem that does not appear in another method would not benefit the student, but I'm sure that the student would opt for the method that makes the task at hand that little bit simpl er. I found handling strings a pain at first, but quickly learnt what was involved. But now I would rather work with Unbounded_Strings for many applications because they provide a solution to some of the shortcomings of String. : Dale, are you really speaking from experience here? your own perhaps? : or from experience teaching. My own experience is that the one thing : that turns on or turns off students most is the professor. A bad : professor can make Ada a catastrophe from the students point of view, : a good one could teach 1401 Autocoder, and the students would be happy. : Of course students are not the ones to be able to judge curriculum : content in any case. I should say that when I began with Ada, I had the attitude that most people have towards Ada. The biggest factor in changing my mind was Dale's approach to both teaching. He has shown me many of the things Ada can do that I was unaware of and I think that most of his other students would agree with what I am saying. Just my opinion as a humble student :) Tristan. -- _/ Tristan Ludowyk \_\_\_\_ _/_/ RMIT Comp.Sys.Eng/Comp.Sci - 1st year ____TTTc____/| \_\_\_ _/_/_/ Email: ludowyk@yallara.cs.rmit.edu.au (_u|||_o_) \| \_\_ _/_/_/_/ "Donkeys live a long time" ^^^ \_ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-12 0:00 ` Tristan Ludowyk @ 1997-09-12 0:00 ` Dale Stanbrough 1997-09-12 0:00 ` Stephen Leake 1997-09-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 24+ messages in thread From: Dale Stanbrough @ 1997-09-12 0:00 UTC (permalink / raw) Robert Dewar writes: "<<(note that Unbounded_IO is a simple package that i wrote). In my experience variable length string handling is one thing that has turned students off Ada a lot. Unbounded_String is a godsend in this respect. It's a pity that a standard I/O package wasn't defined in the standard for this type.>> (This is a little ambiguous. It should say "attempting variable length string handling with type String" (i.e. slices, pointers to strings, discriminated records etc)). "I actually find such claims incredible. I would never introduce Unbounded_String to students till quite late in the class, since this kind of concentration on featurism is exactly what you do NOT want to teach students. Sure you introduce examples of abstractions to teach students, but this is a bad example, because it has too much complexity (particularly the reliance on controlled types)." I don't see how "if you want to process variable length character data, use this type" should be described as featurism. I think it took around 15 minutes to introduce this in the first lecture of 2nd semester. The rest was devoted to the text_io input model, command line arguments, and general new subject stuff. Not a great amount of time. For most students the complexity is completey hidden (only a handful of them even know about controlled types, and _I_ certainly haven't told them). "To me, the idea that a student can be turned off because of a lack of some particular feature in a language is like saying that students are turned off chemistry because they have trouble with the analysis of one particular compound." Students constantly see the C model of strings (bounded length variable length strings) and the associated I/O, and want to know "why can't i do this in Ada?" Well, you can _if_ you include an "no_of_chars" field with your string (yes, i understand about slices - i'm talking about storing values in records and the like). Like it or not, this is what students tell me. UBS's make them happy. "Dale, are you really speaking from experience here? your own perhaps? or from experience teaching. My own experience is that the one thing that turns on or turns off students most is the professor. A bad professor can make Ada a catastrophe from the students point of view, a good one could teach 1401 Autocoder, and the students would be happy. Of course students are not the ones to be able to judge curriculum content in any case." 7 years teaching programming with Ada at the 1st, 2nd and 3rd year level. UBS's make my job easier in this respect, why ignore it? "I do think that it is nice for students to be able to write interesting programs without too much fuss, but unbounded strings are hardly a prerequisite to this!" I reckon i'ld have ~400 students who would disagree with you! :-) Dale ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-12 0:00 ` Dale Stanbrough @ 1997-09-12 0:00 ` Stephen Leake 1997-09-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Stephen Leake @ 1997-09-12 0:00 UTC (permalink / raw) Dale Stanbrough wrote: > > <snip> < > I don't see how > > "if you want to process variable length character data, use > this type" > > should be described as featurism. I think it took around 15 minutes > to introduce this in the first lecture of 2nd semester. The rest > was devoted to the text_io input model, command line arguments, and > general new subject stuff. Not a great amount of time. > For most students the complexity is completey hidden (only a > handful of them even know about controlled types, and _I_ certainly > haven't told them). My problem with this is it leads to the assumption that we don't have to pay any attention to garbage collection, because it magically works. I've run into several C++ programmers whose code blindly fragments the heap, and when I say "must run forever", they have no clue what to do. I hope Ada programmers get better training. Unbounded strings are very nice for beginners. However, they do require some form of garbage collection to be used correctly. I hope that later in the course, this will be pointed out. Which leads me to a question about the GNAT implementation of Unbounded Strings; do they have their own storage pool, and does Free compact the pool? One of these days I'll try to read the source. -- - Stephe ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-12 0:00 ` Stephen Leake @ 1997-09-13 0:00 ` Robert Dewar 1997-09-15 0:00 ` Stephen Leake 0 siblings, 1 reply; 24+ messages in thread From: Robert Dewar @ 1997-09-13 0:00 UTC (permalink / raw) Stephen says <<Unbounded strings are very nice for beginners. However, they do require some form of garbage collection to be used correctly. I hope that later in the course, this will be pointed out. Which leads me to a question about the GNAT implementation of Unbounded Strings; do they have their own storage pool, and does Free compact the pool? One of these days I'll try to read the source.>> When we say that something is "nice for beginners", we are presumably saying that students who want to write programs to do X will find it convenient to use feature Y. But always remember that when we teach computer science, writing programs as excercises is not about writing programs to do X, it is about learning the fundamental concepts, and techniques. The programs we write in class are a *means* to an end, not an end in themselves. This is a very improtant difference. In the world of real life application programming, the point is to create a working program that meets the specifications. When we are teaching the point is to LEARN HOW to create! Things that make it easier to create a program may or may not facilitate learning how to create a program. Note that this distinction is closely related to the issue of how best to help students who ask questions. Very often a student writes a note to CLA saying "I am having trouble doing X", and helpful people assume that since the student is trying to do X, they should help the student do X. But that's wrong, the student is trying to *learn* the skills so that they can do X on their own. Showing them directly how to do X can often be counter-productive. Of course students don't clearly perceive this important distinction, because the achievment of X is how their progress in learning *how* to do X is judged. As to your technical question (gosh, a technical question on CLA, I had forgotten that this could happen :-) GNAT uses controlled types to implement unbounded strings. Using a special garbage collected pool is an interesting idea which we have thought about (and which has been discussed at length in previous CLA threads), but we have not yet followed up this idea. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-13 0:00 ` Robert Dewar @ 1997-09-15 0:00 ` Stephen Leake 1997-09-15 0:00 ` Dale Stanbrough 1997-09-16 0:00 ` Robert Dewar 0 siblings, 2 replies; 24+ messages in thread From: Stephen Leake @ 1997-09-15 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Stephen says > > <<Unbounded strings are very nice for beginners. However, they do require > some form of garbage collection to be used correctly. I hope that later > in the course, this will be pointed out. > > Which leads me to a question about the GNAT implementation of Unbounded > Strings; do they have their own storage pool, and does Free compact the > pool? One of these days I'll try to read the source.>> > > When we say that something is "nice for beginners", we are presumably saying > that students who want to write programs to do X will find it convenient to > use feature Y. But always remember that when we teach computer science, > writing programs as excercises is not about writing programs to do X, it is > about learning the fundamental concepts, and techniques. The programs we write > in class are a *means* to an end, not an end in themselves. This is a very > improtant difference. In the world of real life application programming, the > point is to create a working program that meets the specifications. When we > are teaching the point is to LEARN HOW to create! Excellent point, which I missed. It is definitely more important to learn the fundamentals. On the other hand, if your learning control structures, and you want to print a diagnostic message that is built from several strings, Unbounded_Strings are nice. > As to your technical question (gosh, a technical question on CLA, I had > forgotten that this could happen :-) Glad to oblige :) > GNAT uses controlled types to > implement unbounded strings. Using a special garbage collected pool is > an interesting idea which we have thought about (and which has been discussed > at length in previous CLA threads), but we have not yet followed up this > idea. As I thought. So Dale (if you're still reading :), will you be pointing out that using Unbounded_String does have a big downside? When you get to teaching about dynamic memory allocation and managment, you could point out that they've been doing it all along without thinking about it, just like a lot of professional programmers!. -- - Stephe ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-15 0:00 ` Stephen Leake @ 1997-09-15 0:00 ` Dale Stanbrough 1997-09-16 0:00 ` Robert Dewar 1 sibling, 0 replies; 24+ messages in thread From: Dale Stanbrough @ 1997-09-15 0:00 UTC (permalink / raw) Stephen Leake writes: "As I thought. So Dale (if you're still reading :), will you be pointing out that using Unbounded_String does have a big downside? When you get to teaching about dynamic memory allocation and managment, you could point out that they've been doing it all along without thinking about it, just like a lot of professional programmers!." Stephen, you are presuming that i haven't already talked about it. Yes this is an interesting thing to talk about, i may devote a bit more time to it (should i introduce the concept of finalization, which is yet another programming gizmo?) Dale ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-15 0:00 ` Stephen Leake 1997-09-15 0:00 ` Dale Stanbrough @ 1997-09-16 0:00 ` Robert Dewar 1997-09-17 0:00 ` Stephen Leake 1 sibling, 1 reply; 24+ messages in thread From: Robert Dewar @ 1997-09-16 0:00 UTC (permalink / raw) Stephe said: <<Excellent point, which I missed. It is definitely more important to learn the fundamentals. On the other hand, if your learning control structures, and you want to print a diagnostic message that is built from several strings, Unbounded_Strings are nice.>> What's wrong with Put_Line ("value of x is " & Integer'Image (X) & ....) .. <<As I thought. So Dale (if you're still reading :), will you be pointing out that using Unbounded_String does have a big downside? When you get to teaching about dynamic memory allocation and managment, you could point out that they've been doing it all along without thinking about it, just like a lot of professional programmers!.>> What big downside? What's wrong with using Controlled types here, it is certainly the intended and expected implementation! ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-16 0:00 ` Robert Dewar @ 1997-09-17 0:00 ` Stephen Leake 1997-09-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Stephen Leake @ 1997-09-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Stephe said: > > <<Excellent point, which I missed. It is definitely more important to > learn the fundamentals. On the other hand, if your learning control > structures, and you want to print a diagnostic message that is built > from several strings, Unbounded_Strings are nice.>> > > What's wrong with Put_Line ("value of x is " & Integer'Image (X) & ....) .. Ummm, nothing. I've been doing too much C++ lately, where such things are not available, and I have to use dynamic strings for this purpose. I guess I was thinking of that, not of the One True Way. Sigh. > > <<As I thought. So Dale (if you're still reading :), will you be pointing > out that using Unbounded_String does have a big downside? When you get > to teaching about dynamic memory allocation and managment, you could > point out that they've been doing it all along without thinking about > it, just like a lot of professional programmers!.>> > > What big downside? What's wrong with using Controlled types here, it is > certainly the intended and expected implementation! The downside is heap fragmentation, which will bite you just when it costs the most to fix. Controlled types can guarantee no dangling pointers; they do not guarantee no heap fragmentation. For that you need compacting storage pools (or very careful use of Unbounded_Strings). Is there a requirement in Ada 95 to document whether the Unbounded_Strings implementation is compacting? This would be useful information; I haven't seen it in Annex M for ObjectAda, but I don't believe I've read the whole thing. -- - Stephe ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-17 0:00 ` Stephen Leake @ 1997-09-18 0:00 ` Robert Dewar 1997-09-19 0:00 ` Stephen Leake 0 siblings, 1 reply; 24+ messages in thread From: Robert Dewar @ 1997-09-18 0:00 UTC (permalink / raw) <<The downside is heap fragmentation, which will bite you just when it costs the most to fix. Controlled types can guarantee no dangling pointers; they do not guarantee no heap fragmentation. For that you need compacting storage pools (or very careful use of Unbounded_Strings). Is there a requirement in Ada 95 to document whether the Unbounded_Strings implementation is compacting? This would be useful information; I haven't seen it in Annex M for ObjectAda, but I don't believe I've read the whole thing.>> Well these days on typical machines, fragmentation just translates into poorer performance because of more paging. But compacting may or may not help to reduce paging. It is not a clear call at all There is no requirement for documenting this, since there is no imagination of compacting being an issue. (there is also no requirement to document whether your storage allocator reads the CMOS clock, or takes locks, or makes direct BIOS calls, or allocates more than it needs to, or anything else!) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-18 0:00 ` Robert Dewar @ 1997-09-19 0:00 ` Stephen Leake 1997-09-19 0:00 ` Robert S. White 1997-09-20 0:00 ` Robert Dewar 0 siblings, 2 replies; 24+ messages in thread From: Stephen Leake @ 1997-09-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > > <<The downside is heap fragmentation, which will bite you just when it > costs the most to fix. Controlled types can guarantee no dangling > pointers; they do not guarantee no heap fragmentation. For that you need > compacting storage pools (or very careful use of Unbounded_Strings). > > Is there a requirement in Ada 95 to document whether the > Unbounded_Strings implementation is compacting? This would be useful > information; I haven't seen it in Annex M for ObjectAda, but I don't > believe I've read the whole thing.>> > > Well these days on typical machines, fragmentation just translates into > poorer performance because of more paging. But compacting may or may not > help to reduce paging. It is not a clear call at all Ok, for typical users on hosts with virtual memory. I have seen systems that run under Windows 95 where paging due to non-compacting reduced performance to the point where it was unacceptable. If I do get to a situation like this, I would like to be able to determine whether the run-time library is compacting or not. In the context of an embedded system with (no virtual memory) that has to run forever? Then compacting (or not using dynamic strings) becomes a requirement. > There is no requirement for documenting this, since there is no imagination > of compacting being an issue. (there is also no requirement to document > whether your storage allocator reads the CMOS clock, or takes locks, or > makes direct BIOS calls, or allocates more than it needs to, or anything > else!) I can measure the time it takes to execute my code (that seems to be the primary effect of the other things you list). Measuring how much memory is allocated can be done (to first approximation) by simpler pointer subtraction. But I cannot measure heap fragmentation, at least not without support from the compiler/run-time vendor (a heap display tool). Thus it should be in the documentation, at least for the Real-Time Systems Annex. If I have a reasonable relationship with the compiler vendor, I should be able to get any information I need, without it being part of the Ada standard. But I feel strongly that this issue (compacting dynamic memory) is ignored by too many programmers, so I'd like to raise its visibility. -- - Stephe ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-19 0:00 ` Stephen Leake @ 1997-09-19 0:00 ` Robert S. White 1997-09-20 0:00 ` Robert Dewar 1 sibling, 0 replies; 24+ messages in thread From: Robert S. White @ 1997-09-19 0:00 UTC (permalink / raw) In article <3422BE2E.62B1@gsfc.nasa.gov>, Stephen.Leake@gsfc.nasa.gov says... > But I feel strongly that this issue (compacting dynamic >memory) is ignored by too many programmers, so I'd like to raise its >visibility. It is virtually outlawed by embedded software systems where high performance, reliability, and real time deadlines are critical. Use of the data heap or any other dynamic memory usage is one of the code inspection checklist items we always check. The Ada83 & operator for strings used to get/(bite) us in the 80's with some compilers. Functions returning complicated records (which are not inlined) also tend to cause problems with the heap memory deallocation when using multiple tasks. Various Ada compilers/Real Time Executives can vary in how well they handle this. Newmonics of Ames, IA has some very ambitious goals for predictatable garbage collection with Real Time Java. I'm interested in seeing just how well their implementation works out _____________________________________________________________________ Robert S. White -- An embedded systems software engineer e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-19 0:00 ` Stephen Leake 1997-09-19 0:00 ` Robert S. White @ 1997-09-20 0:00 ` Robert Dewar 1 sibling, 0 replies; 24+ messages in thread From: Robert Dewar @ 1997-09-20 0:00 UTC (permalink / raw) Stephe says <<<<In the context of an embedded system with (no virtual memory) that has to run forever? Then compacting (or not using dynamic strings) becomes a requirement.>> Well first of all, in real life, I cannot imagine embedded systems using dynamic strings in this manner at all. But even if they did, the conclusion that compacting is required is plain wrong. There are many ways of avoiding fragmentation. Here are a couple, there are many more sophisticated ones of course. Agree not to allocate strings longer than 100 characters Allocate all strings 100 characters space regardless of length Represent dynamic strings as list of characters or chunks of characters with fixed chunk size. End of story. Note that compacting has a lot of surprises. For example, people often write something like: c_routine_put (something'address, ....); and it is quite a surprise to have this blow up because the system happens to do a compacting garbage collection between taking the address of something and using it. Garbage collection is a very useful tool, but compacting garbage collectors are basically inconsistent with low level coding of the type that is often seen in embedded systems. So I think your idea that somehow embedded systems might be especially interested in compacting garbage collectors is quite wrong (and we have not even considered the issue of compacting intefering with hard deadlines). <<If I have a reasonable relationship with the compiler vendor, I should be able to get any information I need, without it being part of the Ada standard. But I feel strongly that this issue (compacting dynamic memory) is ignored by too many programmers, so I'd like to raise its visibility.>> Well certainly in the case of GNAT, this is information you can find out very rapidly by looking at the sources. The source of unbounded string is right there in your Ada library, it should not take more than a few minutes for you to see how it does things! You should demand sources of the runtime no matter whose compiler you are using. It is an unacceptable risk to incorporate library routines into your code without having access to the sources. We regard this access as critical. The adherence to free software principles of free availability of sources is critical for risk reduction in high reliability systems. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-12 0:00 ` Tristan Ludowyk 1997-09-12 0:00 ` Dale Stanbrough @ 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Matthew Heaney 1 sibling, 1 reply; 24+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) Tristan says (by the way, please follow newsgroup conventions and keep your line lengths under 80 characters, your message had excessively long lines, which will cause many people trouble reading your messages) <<Firstly, I would say that variable length string handling is something that all students should become accustomed to using the basic string type which teaches t he concepts of how a string is stored in memory and basic techniques for getting around these problems. This is how I was taught - it wasn't until I had been using these techniques for 1/2 a year that the concept of Unbounded_Strings was introduced to me. >> That's not unreasonable, but to me it misses the main objective in a beginning class on programming which is to teach program construction techniques, logical design techniques, and in particular abstraction. It is NOT about teaching 101 neat gizmos that you can use in w4riting neat programs. Indeed neat gizmos are basically a distraction to the much harder task at hand of learning how to program. <<I believe that this is not too "early" since it presents a cleaner way of handling strings, but the student still has the knowledge of how to handle normal strings. >> One thing to keep in mind if you are a student in a beginning course which uses programming language X is that the details of what language X can or cannot do are essentially completely irrelevant, and the skills you learn which are X-language specific are the lest important skills you will learn in the course if it is taught right. <<Secondly, is it really necessary for the student to understand all the inner workings of the Unbounded_String before they use it in their code? Surely they can safely use them and familiarise themselves without doing any harm to the development of their programming technique. >> As I mentioned in my earlier note, it is indeed valuable to show students how they can use an abstraction without understanding the details of the implementation, but I find it more instructive to use for this purpose abstractions where we *can* later look at the implementation and see how it relates to the specification. So I would not choose unbounded strings for this purpose, but rather bounded strings (as soon as I had introduced generics, which I do fairly early on, since genericity is such a critical aspect of abstraction. Or, if you did not want to introduce generics that early, you could use Strings.Fixed as the example abstraction. <<I found handling strings a pain at first, but quickly learnt what was involved. But now I would rather work with Unbounded_Strings for many applications because they provide a solution to some of the shortcomings of String. >> Fine, this is perfectly reasonable, but it is about specific Ada features, and is thus on the general scale of what one tries to teach, not particularly important. I cannot over-emphasize the importance of teaching early on the principles of abstraction, separation of spec and implementation, and incremental design. These are not easy subjects to teach (whereas teaching technical gizmos in any language is by comparison a relatively easy task). You can turn this around by the way, it is easy to learn technical gizmos, it is MUCH harder to learn what abstraction is about. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-12 0:00 ` Robert Dewar @ 1997-09-13 0:00 ` Matthew Heaney 1997-09-13 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 24+ messages in thread From: Matthew Heaney @ 1997-09-13 0:00 UTC (permalink / raw) In article <dewar.874117393@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >You can >turn this around by the way, it is easy to learn technical gizmos, it is >MUCH harder to learn what abstraction is about. Well stated. The sad fact is that many, many working programmers never really catch on to what abstraction is all about. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-13 0:00 ` Matthew Heaney @ 1997-09-13 0:00 ` Dale Stanbrough 0 siblings, 0 replies; 24+ messages in thread From: Dale Stanbrough @ 1997-09-13 0:00 UTC (permalink / raw) "Fine, this is perfectly reasonable, but it is about specific Ada features, and is thus on the general scale of what one tries to teach, not particularly important. I cannot over-emphasize the importance of teaching early on the principles of abstraction, separation of spec and implementation, and incremental design. These are not easy subjects to teach (whereas teaching technical gizmos in any language is by comparison a relatively easy task). You can turn this around by the way, it is easy to learn technical gizmos, it is MUCH harder to learn what abstraction is about." Ah, i guess that ~3 weeks on different list representations with an examination of linked lists implemented in arrays (2 weeks), only then followed by the dynamic memory gizmo, is the right way to go :-). Dale ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Tristan Ludowyk @ 1997-09-15 0:00 ` Richard A. O'Keefe 1997-09-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 24+ messages in thread From: Richard A. O'Keefe @ 1997-09-15 0:00 UTC (permalink / raw) [Dale Stanbrough said that 'Unbounded_String is a godsend' in teaching.] dewar@merv.cs.nyu.edu (Robert Dewar) writes: >I actually find such claims incredible. I would never introduce >Unbounded_String to students till quite late in the class, since >this kind of concentration on featurism is exactly what you do NOT >want to teach students. Sure you introduce examples of abstractions >to teach students, but this is a bad example, because it has too >much complexity (particularly the reliance on controlled types). The complexity *inside* Unbounded_String is totally invisible to students. >To me, the idea that a student can be turned off because of a lack of >some particular feature in a language is like saying that students >are turned off chemistry because they have trouble with the analysis >of one particular compound. >Dale, are you really speaking from experience here? In point of fact, he is. > your own perhaps? or from experience teaching. His experience teaching, as it happens. An obvious point here is that 'Unbounded_String' in Ada is, practically speaking, identical to the simplest kind of string there is in many languages (SNOBOL, for one). Using Unbounded_String means that students don't have to worry about - getting the size right (in String(1..N), what should N be?) - which uses of the identifier need parameters and which don't? (String parameters and results don't have bounds, but String local variables do; they all look the same with Unbounded_String) - partially undefined variables (if you call Get_Line, your variable is PARLY initialised and PARTLY uninitialised; uninitialised variables are tough enough for most students to deal with without having to worry about variables that are partly initialised and partly not) - how to make a string shorter (you _can't_ make a String shorter, the closest you can come is to carry around another variable saying how much of it to take seriously) Unbounded_String would be just about ideal, *except* that you have to introduce a lot of To_String and To_Unbounded_String conversions to deal with older stuff like Text_IO. Given that you have to deal with String anyway, I think it isn't a good idea to have students worrying about two kinds of string in the same program, and the things you have to deal with for Strings are things you have to deal with for arrays generally, so they are worth knowing. >My own experience is that the one thing >that turns on or turns off students most is the professor. A bad >professor can make Ada a catastrophe from the students point of view, >a good one could teach 1401 Autocoder, and the students would be happy. >Of course students are not the ones to be able to judge curriculum >content in any case. Unfortunately, here students _are_ about to dictate curriculum content. Ada has been judged 'not good on my CV, not sexy' and the department has decided to switch to Java next year because it will be popular with the students. (Given that one of my ex-students, _not_ one of the world's great programmers, is now getting TWICE what I do, writing Java for a bank, I begin to see their point.) >I do think that it is nice for students to be able to write interesting >programs without too much fuss, but unbounded strings are hardly a >prerequisite to this! When you are trying to stave off a Java takeover, you clutch even at strings. -- Unsolicited commercial E-mail to this account is prohibited; see section 76E of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation Amendment Act No 108 of 1989. Maximum penalty: 10 years in gaol. Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Please Help. 1997-09-15 0:00 ` Richard A. O'Keefe @ 1997-09-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1997-09-16 0:00 UTC (permalink / raw) Richard said <<Unfortunately, here students _are_ about to dictate curriculum content. Ada has been judged 'not good on my CV, not sexy' and the department has decided to switch to Java next year because it will be popular with the students. (Given that one of my ex-students, _not_ one of the world's great programmers, is now getting TWICE what I do, writing Java for a bank, I begin to see their point.) >I do think that it is nice for students to be able to write interesting >programs without too much fuss, but unbounded strings are hardly a >prerequisite to this! When you are trying to stave off a Java takeover, you clutch even at strings.>> I don't think you can stave off a Java takeover by featurism! Note incidentally that if salaries are the indication of what to teach, there is no question that we should teach COBOL, at least for the next decade while the Y2K mess is figured out. A competent student with good COBOL knowledge can write their own ticket at the moment -- of course not many universities could BEGIN to equip a student with the necessary knowledge! I perfectly well understand the phenomenon you are describing though. Very few professors of computer science know much about programming, or how to teach programming, and even fewer know about how to teach beginning programming. So the people making decisions about what language to teach to beginners are very much in the position of the blind (professors who don't know) leading the blind (students who don't know either). Under such circumstances, teaching the students what they think they might need to know, without knowing anything about how to make this choice, is not such a surprising outcome. Using salaries and/or popularity of programming languages as a guide is at least objective, but it leads to different results. By *far* the most widely used language for application development is Visual Basic. By *far* the best bet for salaries (given the Y2K mess) is COBOL. But of course most of the faculty who make the decisions know nothing about either of these two possibilities, so in fact that decision making mechanism does not work very well. Java is not such a terrible language for teaching. If you have some insrtuctors who are sufficiently enthusiastic about teaching Java, then it's an OK choice, certainly much better than C or C++. For me, the weakness of Java as a teaching language is that it has too narrow a view of the world, and in particular is too far committed to limited paradigms, but still, I think that enthusiasm on the part of the *teachers* is a crucial element. ^ permalink raw reply [flat|nested] 24+ messages in thread
* please help..... @ 2001-10-25 6:55 Phosphorus 2001-10-25 8:22 ` Preben Randhol 2001-10-25 12:35 ` Marc A. Criley 0 siblings, 2 replies; 24+ messages in thread From: Phosphorus @ 2001-10-25 6:55 UTC (permalink / raw) please i need an help about the use of graphic functions in ADA, it's very important... Thank you for your precious help Phosphorus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: please help..... 2001-10-25 6:55 please help Phosphorus @ 2001-10-25 8:22 ` Preben Randhol 2001-10-25 12:35 ` Marc A. Criley 1 sibling, 0 replies; 24+ messages in thread From: Preben Randhol @ 2001-10-25 8:22 UTC (permalink / raw) On Thu, 25 Oct 2001 08:55:20 +0200, Phosphorus wrote: > please i need an help about the use of graphic functions in ADA, it's very > important... Which graphic functions and what is ADA? P ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: please help..... 2001-10-25 6:55 please help Phosphorus 2001-10-25 8:22 ` Preben Randhol @ 2001-10-25 12:35 ` Marc A. Criley 1 sibling, 0 replies; 24+ messages in thread From: Marc A. Criley @ 2001-10-25 12:35 UTC (permalink / raw) Phosphorus wrote: > > please i need an help about the use of graphic functions in ADA, it's very > important... > Thank you for your precious help > Phosphorus No one here knows what you need help with. If you ask specific questions, you can get answers to them. We will try to help, but you have to be more specific. Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2001-10-25 12:35 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-09-09 0:00 Please Help Ken 1997-09-09 0:00 ` Stephen Leake 1997-09-09 0:00 ` Dale Stanbrough 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Tristan Ludowyk 1997-09-12 0:00 ` Dale Stanbrough 1997-09-12 0:00 ` Stephen Leake 1997-09-13 0:00 ` Robert Dewar 1997-09-15 0:00 ` Stephen Leake 1997-09-15 0:00 ` Dale Stanbrough 1997-09-16 0:00 ` Robert Dewar 1997-09-17 0:00 ` Stephen Leake 1997-09-18 0:00 ` Robert Dewar 1997-09-19 0:00 ` Stephen Leake 1997-09-19 0:00 ` Robert S. White 1997-09-20 0:00 ` Robert Dewar 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Matthew Heaney 1997-09-13 0:00 ` Dale Stanbrough 1997-09-15 0:00 ` Richard A. O'Keefe 1997-09-16 0:00 ` Robert Dewar -- strict thread matches above, loose matches on Subject: below -- 2001-10-25 6:55 please help Phosphorus 2001-10-25 8:22 ` Preben Randhol 2001-10-25 12:35 ` Marc A. Criley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox