Prev: When a conditional expression is static, where can it be used?
Next: Design problem: generic package vs tagged subtype
From: Warren on 30 Jun 2010 13:05
Gautier write-only expounded in news:98aa58b3-50fc-418d-9f72-
524b5a23c89d(a)t10g2000yqg.googlegroups.com:

> On 30 Jun., 07:23, mahdert <mahd...(a)gmail.com> wrote:
>> When I first started my undergraduate studies as a computer science
>> major, I was forced to use ADA in an introductory course.. Mind you I
>> was already familiar with C++ at that time..but after dealing with ADA
>> and compilet time errors for about a year, I decided to change my
>> major to mech eng..
...
> If you had compile-time errors with Ada, it was because you had bugs
> and bugs tend to be detected more at compile-time with Ada. As a
> reward, your programs tend to function earlier correctly once they are
> compiled. Kind of each time you lose 10 minutes fighting with the
> compiler, you gain 1 hour not fighting with the debugger. A good deal
> in the end, but as you say later, it requires some maturity to catch
> it.

I remember this when I was young. For some reason, students
get real hung up on compile time errors. It's like they are
horses bouncing around inside the gate, waiting for the door
to open.

They barely even read the error messages and simply
take in the one fact "error in line x". Not which kind of
error or any level of detail. They simply want to know the
quick answer for "getting past the error". They don't want
to know why it is an error, so long as they can "fix it",
and fix it now ("my assignment is due"). In otherwords,
the compiler is holding them back.

This rush to successfully compile has probably discouraged
many people. Yet as point out above, this is good in that
it saves you much debugging, which is usually much more
difficult.

Is the problem that debugging is more fun than fixing compile
time errors? There must be phsycological reasons.

Maybe students of Ada are best served by educating them on
this issue before they get too involved in using the compiler.
To read the error(s) carefully and to understand the nature
of the problems being exposed. It's like teaching unix
students how to read "man pages" and how to read between
the lines (as it was often necessary to do).

Then perhaps they won't bounce around in the gate so much
if they are taught to be more patient. Education might
avoid the frantic "what do I need to change to
make the compiler like my code" frenzy.

The compiler is your friend- only except when it
presents a 'bug box'. ;-)

Warren
From: Kulin Remailer on 30 Jun 2010 17:10
> I remember this when I was young. For some reason, students
> get real hung up on compile time errors. It's like they are
> horses bouncing around inside the gate, waiting for the door
> to open.

That was the questionable thinking behind a hilarious variant of PL/I
called PL/C, Cornell University's PL/I compiler. Students just want their
programs to compile and run, don't bother them with details like whether
it's correct or not. Not a good assumption but...it was enough for somebody
or some group of people to put out a pretty interesting compiler and get it
out there in academia, circa late 70s early 80s timeframe.

The purpose of PL/C was to take almost any input and hammer it until it
looked like a PL/I program, compile it, and generate an executable from
it. It certainly may not do what you intended, but by george, the damn
thing will almost always start running. What happens next...nobody knows.

It was hysterical to look closely at the diagnostics. I don't have a
listing handy but I remember it would be something like

Error on line ... (note the syntax error)
PL/C uses .... (what PL/C replaced your erroneous statement with)

If I had a dime for every cup of coffee that went out my nose working with
that compiler! Actually it could have been a very interesting aspect of AI
if they had intentions in that direction but I don't think it went any
further and I haven't seen anything like it since.


From: Peter C. Chapin on 30 Jun 2010 19:42
On 2010-06-30 13:05, Warren wrote:

> They barely even read the error messages and simply
> take in the one fact "error in line x". Not which kind of
> error or any level of detail. They simply want to know the
> quick answer for "getting past the error". They don't want
> to know why it is an error, so long as they can "fix it",
> and fix it now ("my assignment is due"). In otherwords,
> the compiler is holding them back.

My students are often like this as well. In fact, I notice they hardly
ever read any error messages regardless of the source. If an error
message box pops up in some application many of my students will dismiss
it at once automatically. It's almost like a reflex action. If they are
in the process of asking me for help the conversation goes something
like this:

Me: "So what did that error message say?"

Student: "I have no idea."

Me: "You should probably at least read those messages before saying you
are stuck."

It can be frustrating.

All that said, I do think that many novice programmer's find compiler
error messages baffling and largely unhelpful. The part that says "error
on line xx" they understand. The part that says something like, "no
suitable subprograms found to resolve yyy. Candidates are..." can be
hard for a complete beginner to digest. They don't really understand
what the message means so they look at line xx and hope for a flash of
insight. Obviously as an educator it's my role to help them learn what
such messages mean, but it takes time and it isn't always easy.

I will say GNAT has rather good error messages overall. I have had more
than one student tell me that he/she found GNAT error messages better
than "any other compiler I've used" (meaning g++).

Peter
From: Georg Bauhaus on 1 Jul 2010 10:14
On 01.07.10 01:42, Peter C. Chapin wrote:

> All that said, I do think that many novice programmer's find compiler
> error messages baffling and largely unhelpful.

Yes. Technical messages can definitely be unhelpful, and frustrating
when learning how to program. In fact, "unhelpful" and "frustrating"
are the two very qualities of communication that no teaching effort
can afford! They are necessarily damaging. Picture it this way,
among humans:

S, a student of some subject asks questions.
T, a teacher on the subject, understands the questions, or thinks he does.
Then T answers, but, to S, his answers are unhelpful and frustrating.
Because S simply cannot understand the answers, since they are full
of yet-to-be-learned notions.
T might say that the answers are correct.
So what?
This is not pedagogical!
The messages are incorrect if intelligibility of a message
is a measure of its correctness in a given situation.

"unhelpful" and "frustrating" will drive S away from the subject.
Depending on S's self-esteem, he/she might try harder, but to
no avail since the messages cannot improve. So S might give up
in the end and use a different language or choose a different
career. Without need...

Ada provides for a solution to the problem caused by the advanced
technicalities in error messages, I think, using Ada's language profiles
like Ravenscar, but with a focus on teaching:
define a profile to be a language subset a la "Teach Packs" in DrScheme.
Teach packs, IIUC, will let you use, teach, and hence understand just the
parts of Ada that some programming subject demands. Compilers that
are "aware" of the profile can then stop printing what is, in effect,
gibberish in a teaching situation.

Instead, compilers diagnose something more easily explained:
file.ada:123: "X is not supported in This-Teach-Pack"


I don't know how open GAP is, or how comprehensive in a teaching
society sense. But it looks like one place to look for things
to be included in a teach pack. Apparently, efforts like these can fail
when the result is known up front (by desire to teach X no matter what),
or if no impulse from outside computing departments creates resonance.
Psychology of teaching has some insight, and there is some empirical
evidence.

See e.g. the section titled "2. More is more" in:
"Seven Deadly Sins of Introductory Programming Language Design"
by McIver and Conway.


From: (see below) on 1 Jul 2010 10:27
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.

> ... like Ravenscar, but with a focus on teaching:
> define a profile to be a language subset a la "Teach Packs" in DrScheme.
> Teach packs, IIUC, will let you use, teach, and hence understand just the
> parts of Ada that some programming subject demands. Compilers that
> are "aware" of the profile can then stop printing what is, in effect,
> gibberish in a teaching situation.
>
> 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.

--
Bill Findlay
<surname><forename> chez blueyonder.co.uk


 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: When a conditional expression is static, where can it be used?
Next: Design problem: generic package vs tagged subtype