Please Help.

Please Help.

[Ken]

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.

Re: Please Help.

[Dale Stanbrough]

"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

Re: Please Help.

[Robert Dewar]

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!

Re: Please Help.

[Tristan Ludowyk]

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"             ^^^             \_

Re: Please Help.

[Dale Stanbrough]

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

Re: Please Help.

[Stephen Leake]

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

Re: Please Help.

[Robert Dewar]

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.

Re: Please Help.

[Stephen Leake]

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

Re: Please Help.

[Dale Stanbrough]

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

Re: Please Help.

[Robert Dewar]

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!

Re: Please Help.

[Stephen Leake]

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

Re: Please Help.

[Robert Dewar]

<<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!)

Re: Please Help.

[Stephen Leake]

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

Re: Please Help.

[Robert S. White]

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

Re: Please Help.

[Robert Dewar]

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.

Re: Please Help.

[Robert Dewar]

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.

Re: Please Help.

[Matthew Heaney]

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

Re: Please Help.

[Dale Stanbrough]

"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

Re: Please Help.

[Richard A. O'Keefe]

[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.

Re: Please Help.

[Robert Dewar]

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.

Re: Please Help.

[Stephen Leake]

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

please help.....

[Phosphorus]

please i need an help about the use of graphic functions in ADA, it's very
important...
Thank you for your precious help
Phosphorus

Re: please help.....

[Preben Randhol]

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

Re: please help.....

[Marc A. Criley]

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