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: Randy Brukardt on 1 Jul 2010 19:50 "Georg Bauhaus" <rm.dash-bauhaus(a)futureapps.de> wrote in message news:4c2cb60f$0$7651$9b4e6d93(a)newsspool1.arcor-online.net... .... > 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.) I don't see any particular need for such a profile, at least in the case of overloading. Janus/Ada produces error messages ignoring overloading when that is possible. For instance, if there is only one Put_String routine, the call: Put_String (10); would get the message: "Unable to resolve - parameter has wrong type" with the arrow pointing at "10". The error handler also tries to make sensible messages for predefined math operators. Thus, the reason you get unintelligible messages is that you are using heavily overloaded routines in student programs (like Text_IO). Don't do that and the problem pretty much goes away (at least until the students are taught about overloading, but hopefully by then they'll be better equiped to handle the complexity). [Unfortunately, if we can't make a sensible message, we fall back on "Unable to resolve" with no other information, which is frustrating even to someone that has been programming in Ada for 25 years [that is, me]. We could never figure out a way to present the possibilities that made any sense; AdaCore has done a better job here.] Randy.
From: Georg Bauhaus on 2 Jul 2010 03:39 On 7/2/10 1:50 AM, Randy Brukardt wrote: > I don't see any particular need for such a profile, at least in the case of > overloading. > > Janus/Ada produces error messages ignoring overloading when that is > possible. For instance, if there is only one Put_String routine, the call: > Put_String (10); > would get the message: "Unable to resolve - parameter has wrong type" with > the arrow pointing at "10". The error handler also tries to make sensible > messages for predefined math operators. > > Thus, the reason you get unintelligible messages is that you are using > heavily overloaded routines in student programs (like Text_IO). Don't do > that and the problem pretty much goes away (at least until the students are > taught about overloading, but hopefully by then they'll be better equiped to > handle the complexity). Frankly, and with all due respect, your argument is exactly that of a C programmer when he denies advantages of using Ada: "Don't do that and the problem pretty much goes away..." That's true, but it doesn't happen. The int problem won't go away and continues to affect IT at large. Does this make anyone switch? Continuing the analogy, the advantages of Ada's fundamental type system are undeniably demonstrated in a comparative setting such as McCormick's. Yet once people start to like int, or Ada I guess, they won't let go. There may be evidence that char and int etc. don't work well. But rather than give up the first plan (C) and switch to a different plan (Ada) they proudly defend their property (C)... Profiles don't require switching languages. But if (and only if) one feature of Ada turns out to be an obstacle to early learning, is it not better to keep the language as is and bridle it with a profile that removes the obstacle as needed? (It need not be overloading, if overloading does not cause the teaching problems or learning problems that Peter Chapin reported.)
From: Georg Bauhaus on 2 Jul 2010 04:28 On 7/2/10 12:11 AM, (see below) wrote: > 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 +_*/ ? Later. There are only integers now. >> 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. OK. >> 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? Experience has made me and others think, that generally, statistically, teachers are not language experts and not teaching experts (some of them, see below). They nevertheless (must) act as language teachers and this is the fact from which to start. One inevitable problem with teaching quality is generated by a contradictory moment in the life of many university teachers, as is cautiously mentioned here and there: at the time you prepare for being a doctor, you start being a teacher already. But, in general, there is no formal education that could have introduced you to the subject of teaching, only good will and attempts at informal advice. Reason: PhDs are several years older than others who study to become a (school) teacher, yet they would have to study the very same subjects. But do PhD candidates and first year students sit in the same room? Unthinkable. Even offerings made especially for PhD candidates seem to pose a threat ... whatever it is that PhDs fear when they are supposed to learn how to teach. Maybe it is status inconsistency. (This is from some Australian teaching association IIRC, but the observation is not restricted to the continent, I think.) >> 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. They simply cannot see things the same way an expert sees them. > The design of Ada can hardly be held responsible for subjecting students to > incompetent or untrained teachers. The suggestion is to start from the design of Ada, as is, and not change it a bit. Have experts create profiles that help countervail any venial incompetence on the part of teachers. The latter is a fact. One can point at teachers, say some truths about how good or bad a language is taught at some school. Sure, but it seems easier to equip Ada with optional, field-tested teaching profiles. We cannot run tools that create different teachers as output, but we can have compilers that optionally offer guidance as to which features of the language to include in teaching at this or that stage. The task, then, is a valid survey.
From: Georg Bauhaus on 2 Jul 2010 06:35 On 03.07.10 10:35, Dmitry A. Kazakov wrote: > Profiles are bad, they create many new languages and require a deep > language understanding as for what must be in and out of the profile. When students study only the sequential parts of Ada they are not learning a new language by not starting with tasks. Learning sequential algorithms is one example where experienced teachers may or may not want to draw attention to concurrent algorithms. It's their say. They compiler can assist with a profile. I'm not advocating this particular profile for teaching. It happens to be an identifiable subset and may or may not be the preference of experienced teachers. Experienced teachers can identify these subsets and test them. It's *not* programmers (in this role) who have to find teaching profiles and wonder how they are consistent with what. As a teacher, you may request that a sequential profile be turned on leading to simpler error messages should a tasking construct slip into a student's program. The message then simply complains that this is a concurrency construct. Messages involving the details of tasking may make students even more curious. If you want this, don't turn on the profile. If you think that curiosity should find an object withing the subset you are teaching, turn the profile on.
From: Georg Bauhaus on 2 Jul 2010 09:24
On 03.07.10 14:51, Dmitry A. Kazakov wrote: > On Fri, 02 Jul 2010 12:35:06 +0200, Georg Bauhaus wrote: > >> On 03.07.10 10:35, Dmitry A. Kazakov wrote: >> >>> Profiles are bad, they create many new languages and require a deep >>> language understanding as for what must be in and out of the profile. >> >> When students study only the sequential parts of Ada >> they are not learning a new language by not starting >> with tasks. > > So, what would the reason to forbid tasks then? As I said earlier, one reason for restricting the language to some subset for teaching is error messages that should not refer to advanced concepts (yet to be studied). Error messages of this kind have been reported to create frustration. > You can > mark the manual pages about concurrency as "adult content." But I doubt > students read anything anyway. If student don't read, there is more reason to have the compiler indicate a clear sectioning of the language. That's what compilers do anyway, be it by not supporting some annex or be it by following the rules of an existing standardized profile. > Besides that the example is unrealistic, Absence of tasking in first programs is unrealistic? > how the message "tasks are > forbidden by the profile X" were better than "limited object cannot be > initialized". A more pedagogic, yet accurate(!), message is better than undecipherable advanced tech talk for professionals. Did you notice how GNAT's message ";" should be "is" does not mention the word "syntax"? Teaching profiles are to help those who do not yet know anything about task or limited. foo.ada:14: "`task' is a concurrency construct; \ concurrency is turned off in this teach pack" To me, this seems better to me than any message that requires an understanding of words having to do with tasking. It isn't easy for me to make GNAT emit a rather technical message about tasking. Here is an attempt: 6. Job : Task; | >>> subtype indication expected >>> missing ";" That's all logical seen from the compiler's perspective, I guess. But it does require some explanation by the teacher (remember: the student might think, quite legitimately, that there exists a type named "Task"). Explanations by teachers is the stuff from which to make "teaching profile messages". The example above might seem a lame attempt at an example, since, perhaps, a teacher has no trouble wiping away all questions by noting that "task" is a reserved word, and more about it later. Just get rid of it. But that's the point! That is what error messages can strive to be like in a "teaching compiler". Notice how the message at foo.ada:14 says just this. |