From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,751d508677a5add1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!feeder.news-service.com!newsfeed.straub-nv.de!open-news-network.org!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 02 Jul 2010 00:00:11 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [Ada] made me hate programming References: <8f469661-370c-4484-82d8-f1b365455e0f@w12g2000yqj.googlegroups.com> <98aa58b3-50fc-418d-9f72-524b5a23c89d@t10g2000yqg.googlegroups.com> <4c2bd5e5$0$2366$4d3efbfe@news.sover.net> <4c2ca2d2$0$7666$9b4e6d93@newsspool1.arcor-online.net> <4c2cb60f$0$7651$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <4c2d0fec$0$6877$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 02 Jul 2010 00:00:12 CEST NNTP-Posting-Host: 3631cd93.newsspool2.arcor-online.net X-Trace: DXC=A0MlW7nGNY9RLigj];iP=8A9EHlD;3Yc24Fo<]lROoR18kFPCY\c7>ejV8VOY`hm<_F92mdWT_O_Wb50 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:12112 Date: 2010-07-02T00:00:12+02:00 List-Id: 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?