made me hate programming
in [ADA]
|
Prev: When a conditional expression is static, where can it be used?
Next: Design problem: generic package vs tagged subtype
From: Georg Bauhaus on 1 Jul 2010 11:36 On 01.07.10 16:27, (see below) wrote: > On 01/07/2010 15:14, in article > 4c2ca2d2$0$7666$9b4e6d93(a)newsspool1.arcor-online.net, "Georg Bauhaus" > <rm.dash-bauhaus(a)futureapps.de> wrote: > >> Ada provides for a solution to the problem caused by the advanced >> technicalities in error messages, I think, using Ada's language profiles > > In my experience there are no such problems in teaching Ada, with GNAT at > any rate. GNAT's error messages are generally of high quality at the moment, > and in my experience quite understandable to beginners. I shouldn't have stressed error message so much. It's more about concepts that are advanced, and how they can get in the way when beginners know only beginners' concepts. According to findings of others, error messages become less understandable then. Indeed, GNAT's messages made me think "Fantastic!". For example, when I first saw a message that very clearly told me what was wrong. I had seen messages like file, l.N, Syntax error or Syntax error at end of file This is very different from file:L:C: ";" should be "is" In order to understand the first messages, a beginner might need help. It does not say what syntax error, or where the error is, in the second case. GNAT's message OTOH does not even presume knowledge of technical terms. In fact I call it a *message* rather then a scanner status indication. The message is helpful and specifically addresses what has been written. I find it encouraging. Much less so when the messages are like the ones Peter Chapin has quoted (about overload resolution). They make me think of a language profile that disallows overloading. Once you have it, the confusing messages are gone, or replaced with something that has meaning in the context of the language profile. (Lack of overloading is arguably a desirable quality of real world programming languages, if one includes SPARK and Eiffel. If someone feels artificially deprived of programming powers, you can say that once overloading is explained, we'll see some algorithms that use it.) >> Instead, compilers diagnose something more easily explained: >> file.ada:123: "X is not supported in This-Teach-Pack" > > Why do you think this would be comprehensible to beginners, or even > desirable? It is a message about a pedagogical meta-level that has nothing > whatever to do with the problems of learning algorithmic construction > through the medium of a language. I won't insist on the wording, on the contrary. It might seem preachy depriving students of advanced language features; this is not the goal, however. The goal is to gradually extend the set of included language features. The idea leads to a partial order of language concepts (TBD). Compiler messages would then mention the concepts of the current extent, and no others. For example, they will "talk" about overload resolution like other good compilers "talk", compilers, though, that translate languages not including overloading. No one's feeling are hurt in this scenario I should think. Or when the language profile does not include X, they print a nice, encouraging message about X being for a later date in the course or some such.
From: (see below) on 1 Jul 2010 14:54 On 01/07/2010 16:36, in article 4c2cb60f$0$7651$9b4e6d93(a)newsspool1.arcor-online.net, "Georg Bauhaus" <rm.dash-bauhaus(a)futureapps.de> wrote: > [mostly agreed] ... > Much less so when the messages are like the ones Peter Chapin has > quoted (about overload resolution). They make me think of a > language profile that disallows overloading. So you lose Ada.Text_IO and all the arithmetic operators? > Once you have it, the confusing messages are gone, or replaced > with something that has meaning in the context of the language profile. > (Lack of overloading is arguably a desirable quality of > real world programming languages, if one includes SPARK and Eiffel. That's not an argument I would support. > The goal is to gradually extend the set of included language features. > The idea leads to a partial order of language concepts (TBD). 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). -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Simon Wright on 1 Jul 2010 15:34 Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: > I had seen messages like > file, l.N, Syntax error > or > Syntax error at end of file My favourite was "Syntax error at line 0" (a Telelogic compiler from long ago).
From: Georg Bauhaus on 1 Jul 2010 18:00 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?
From: (see below) on 1 Jul 2010 18:11
On 01/07/2010 23:00, in article 4c2d0fec$0$6877$9b4e6d93(a)newsspool2.arcor-online.net, "Georg Bauhaus" <rm-host.bauhaus(a)maps.futureapps.de> wrote: > 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. What about +_*/ ? > 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. [...] I think this is all totally unnecessary. > 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? In other words: a good knowledge of Ada, and a good understanding of effective teaching methods? Of course. How could you think that that might not be the case? > 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? You'd have to ask them. > 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? The design of Ada can hardly be held responsible for subjecting students to incompetent or untrained teachers. -- Bill Findlay <surname><forename> chez blueyonder.co.uk |