Re: [Ada] made me hate programming

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 7/1/10 8:54 PM, (see below) wrote:

>> language profile that disallows overloading.
>
> So you lose Ada.Text_IO and all the arithmetic operators?


I'd be using a different library. One use case is when output should
be as simple as possible. I learned that working with just
digits seems to be a good way to get started with programming
in Ada. What is needed in this case is quick output of results, of
integers (or digits) and strings.  Since (Integer_)Text_IO has
more than is needed, it might be OK to introduce a simpler I/O package,
defer the introduction of "&" (and, of course, abstain from
Integer'Image). This leaves two I/O procedures: I/O of a string,
and I/O of an integer (or digit).  Only two types as yet,
no floats, no characters.  Then, use them like in

   Put_String ("Time of day is     ");
   Put_Integer (H);  Put_String (":");
   Put_Integer (M);  Put_String (":");
   Put_Integer (S);
   New_Line;

I am sure I don't like this approach for real programming, but
since they are just two subprograms, they can serve to explain
some basics no less than overloaded Put, I think.  (And be
justified by absence of funny messages about candidates, if that
is an issue.)
Characters can be introduced later, without loss for printing
text.
(An O-O approach---allegedly working well at ETH Z�rich---could use
overriding of Put if Ada offered it for its numbers and strings.
Not sure whether overriding vs overloading of 1-ary procedures
is such a big issue, though. But certainly things are simpler when
there is only one mechanism that associates arguments and
subprograms?)

Another use case is when printing composite objects.  Is Text_IO
the package you need here?  With overloadings?   Might one not just
as well form a sequence of statements from the "primitives" above.

Another, hypothetical, reason for excluding overloading at the
beginning (besides the overload resolution messages that seem
not so easy to understand) is keeping focus.
When the model of subprogram calls is less detailed due to
lack of overloading, then calls might appear less convenient,
but also exhibit a more regular construction principle.

Influence of overloading on understanding programs has been
studied a bit, AFAICS, both syntactic overloading and overloading
of subprograms.  Syntactic overloading seems to be misleading
learners when used excessively---a result contradicting
the very intent of the teaching language Turing, they say.
It is in this sense that I am nagging about the possibilities
of language profiles for teaching.  They can make the compiler
act like a language guide.


> Of course, "diminishing deception" is the essence of teaching complex
> material. Ada supports it very well already: the various advanced features
> are quite independent of each other, so the student is unlikely to stumble
> into them (very unlikely, in my experience).

That's good news and opposes some of what I have read so far.
Is it possibly good instructions that have made it unlikely
for students to stumble into advanced features?

Does good teaching require a good understanding
- of the independent features of Ada
- of the independence of features of Ada
- of how to combine them and when?

An then, when a teacher has different assorted backgrounds, picking
up the language of the day because that seems required, has he/she
got a chance to see all this clearly?  And to form instructions
accordingly?

Mentioning Ada and teaching 16 year olds has quite reliably provoked
laughter among teachers others and I have met. I can't imagine that
this laughter is caused by knowledge of how the language can be used
in teaching.  What about compiler messages then, if these teachers start
teaching Ada from their own perspective, which may seem plausible to
them, but not to experienced Ada teachers?