On 2/7/2020 4:05 AM, Bjarne Stroustrup wrote:
> Have you actually tried teaching that early? and if so, how early? I
> find that beginning programmers and even slightly experienced students
> recoil from "undefined"; how can anything be undefined except though
> incompetence? This is not just computer science, but a world view:
> everything must have a definition. Every question must have an answer.
> That's not true, of course, but is a teacher of novice programmers the
> one to shatter that certainty? I don't think that I can, on average,
> explain "undefined" effectively unless the students have a solid
> background in machine architecture and compiler technology.

This short comment triggered my brain for thoughts to talk several
hours... It would be great discuss the subject by a pint or on a SG20
session, formal or informal. (not just the UB-releated part but the
broader subject from the original thread on ext).

A very abbreviated answer.

I might have mentioned "first thing" earlier, I really meant it as
priority, not chronology. In chronological order certainly indeed it
shall happen after you established a foundation and lines of
communications. But after that it is supposed to come early. For the
very reason that it takes time and iterations to grok, so can not be
left as the last item.

I did not work with complete blank-state students. M people had either
some programming or zero programming but finished some real university
(being civil engineer, chemical engineer, doctor or something). With
them I found a solid foundation without a problem. I do agree that
otherwise it must be built first, and I would also start with a fully
defined model.

I don't think you need to spend a lot of time with that, neither that
switching is a problem. It even fits with the general mission: the
student must be taught to work with different models and practiced in
shifting focus without losing the frame of reference.

One of the (IMO) successful courses for programming is SICP. It starts
with the substitution model. And right when it reaches the peak, it
introduces mutability. That requires to abolish that whole model and
create a brand new one. And it happens on maybe the third lesson?

We could ask why it did not stay with the first. Or if rendered
unusable, why not just skip and start with the other? (A thing kinda
every other school follows...) I ship the long discussion here just
state that it is f-ing brilliant that way and create the major benefits.

Just as in science, models that worked are not discarded, and remain
useful in the circumstances they worked fine. We still use the Galilei
transformation everyday and switch to Lorentz only when we need to put a
satellite in orbit of Jupiter or similar tasks. The primary school model
of electricity based on pipes and water basins is fine just to switch on
the light. Knowing about Maxwell equations and Poynting vector is not
necessary. But if you work in the field, it IS. And students that are
meant for programmers are like that.

You just can't leave them with the simple models and cover the
complexity of the real world. As you say, it is part of the world view
really, if it solidifies in the head that way, it created a defective
product. That hurts both the customer and the product.

In my interview practice, I have no problem passing an engineer with no
programming at all -- just look for being bright and good in his
profession. It doesn't take too much to ask. But for candidates with
"CS" I go pretty deep to see how they think. About programs, as
unfortunately that branch appears to miss teaching any science or
engineering -- or with a very low bar. I look for the amount on
un-training I have to apply. And whether it looks possible at all.


The fully-defined model is pretty hard to crack. A fast example of the
impact, from experience: reading indeterminate value. In C++ it is UB.
I see people auto translate it to "reading and unspecified value". For
other some other flavors, like writing to a dangling pointer they appear
to get it pretty fast that poking random bytes into something already
there is as undefined as it gets. But for this they keep thinking it is
okay to pass some variable around, even do operations as long as the
final result is not used later. And this creates serious danger.

As an unrelated comment, like a month ago I read the MS bulletins, and
yey, they just fixed another buffer overrun. In jscript.dll. Good
present on the 20th anniversary of the security push movement. We
should find ways to be better.


>
> On 2/6/2020 2:19 PM, Balog Pal via Ext wrote:
>> TLDR; I beg those who teach the next generation, please cover this gap
>> in knowledge, it is way more important than the nuances mentioned in
>> the attached document. (it's pretty long and has 0 instances of
>> undefined and 1 unrelated instance of behavior... silence may indicate
>> students can not be surprised -- or the very opposite.)
>