Date: Sun, 30 Apr 2023 17:00:06 +0300
[Sorry, sent with Reply instead of Reply-All. Resending].
The question is, if (when?) these novices get to the industry, wouldn't
they have a misconception that vector [] checks for out of bounds?
My view is that since outbounds is the case with C++ (or, as long as it
is), maybe it is better not to cushion them from the harsh reality, but
rather make them face it (yes, I understand that it wastes time, that may
be better spent for other stuff, but then why teach C++ and not Python? If
they are going to actually work in C++ they should get aware of the way
it works).
And I say that, while I still believe that "Teaching" shares the letters of
"Cheating" for a reason.
It's OK for teachers to cheat a bit, to make things easier for the students.
It's a choice question, when to cheat and when to go with the brutal truth.
(I also cheat when I teach, but not for vector []. I have my own other
cheats...).
Regardless of the teaching question, we should think of better approaches
in the language to avoid this issue (such as compiler profiles for turning
on bounds checking!), this should be an important drive for the language.
Something in the direction of Circle's feature directives
<https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives>
.
I'm in favor of that!
On Sun, Apr 30, 2023 at 4:26 PM Bjarne Stroustrup <bjarne_at_[hidden]>
wrote:
> Exactly. Thanks. We all (well, several of us) have many different target
> audiences, but in this particular case, I'm working for rank novices.
> Independently of that, I think that range checking would be a boon to
> most users. Only a minority - possibly a large minority - needs that
> last added performance that you get from not checking. My conclusion is
> that we need to find ways to serve both groups.
>
> For novices, range checking needs to work right out of the box.
> Installing *anything* is a deterrent.
>
>
> On 4/30/2023 3:11 AM, Ville Voutilainen wrote:
> > Because that's Bjarne's target audience, students who may not have
> > programmed before.
>
The question is, if (when?) these novices get to the industry, wouldn't
they have a misconception that vector [] checks for out of bounds?
My view is that since outbounds is the case with C++ (or, as long as it
is), maybe it is better not to cushion them from the harsh reality, but
rather make them face it (yes, I understand that it wastes time, that may
be better spent for other stuff, but then why teach C++ and not Python? If
they are going to actually work in C++ they should get aware of the way
it works).
And I say that, while I still believe that "Teaching" shares the letters of
"Cheating" for a reason.
It's OK for teachers to cheat a bit, to make things easier for the students.
It's a choice question, when to cheat and when to go with the brutal truth.
(I also cheat when I teach, but not for vector []. I have my own other
cheats...).
Regardless of the teaching question, we should think of better approaches
in the language to avoid this issue (such as compiler profiles for turning
on bounds checking!), this should be an important drive for the language.
Something in the direction of Circle's feature directives
<https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives>
.
I'm in favor of that!
On Sun, Apr 30, 2023 at 4:26 PM Bjarne Stroustrup <bjarne_at_[hidden]>
wrote:
> Exactly. Thanks. We all (well, several of us) have many different target
> audiences, but in this particular case, I'm working for rank novices.
> Independently of that, I think that range checking would be a boon to
> most users. Only a minority - possibly a large minority - needs that
> last added performance that you get from not checking. My conclusion is
> that we need to find ways to serve both groups.
>
> For novices, range checking needs to work right out of the box.
> Installing *anything* is a deterrent.
>
>
> On 4/30/2023 3:11 AM, Ville Voutilainen wrote:
> > Because that's Bjarne's target audience, students who may not have
> > programmed before.
>
Received on 2023-04-30 14:00:19