On Mon, 1 May 2023 at 20:41, Andrew Lumsdaine via SG20
<sg20_at_[hidden]> wrote:

Some specific picks..

> It is inconceivable that they would be able to make any sense of the output from a sanitizer

Aye. I'm not convinced all that many professionals are able to make
sense of it. :)

> It is inconceivable that they would be able to make use of a command-line debugger (possibly something in an IDE, but I have strong doubts)

I have no trouble finding professionals who barely manage that, and
that's been the case for two decades, with various memes/jokes about
command prompts and shell windows being (literally) "the dark side". I
personally find it a bit curious that these people have no trouble
with other magical incantations being written for the computer to grok
(meaning whichever programming language they use) but any sort
of shell languages are somehow more magical to them. But that doesn't
change the fact that this is a very common issue.
Edit a source file in the language you use? No problem, mostly, to
whatever expertise extent. Edit a build configuration file? They
run away screaming.

> Namespaces are one of those things. Bjarne’s approach is to remove them for introductory treatment while I treat “std::” as just part of the name of things in C++.

I love this approach. At least for some things, I've found it much
more productive in software houses to say, when people ask
e.g. "how to make std::foo and boost::bar shorter?", "just don't, it's
much less trouble that way". That doesn't apply universally
to deeply nested namespaces, but it sure works great for those two
examples and more. It's unfortunate when one has to
unteach a desire to shorten as far as possible, because at some point
it's actually less readable.

> A bounds-checked vector class would be extremely helpful to students. If I were to use std::vector directly in my approach I would just put them in a separate namespace and tell them they need to use stdx::vector if they want bounds checking.

Or, say, ppp::vector.

I would seriously encourage considering that. I have no idea how
widespread the tolerance and even preference for just not trying
to get rid of short prefixes such as and especially std:: is, but I
have certainly seen it a lot, so it would certainly be fathomable that
students will run into it in "the real world".

There's also a fair amount of houses who never run into ADL woes
because their approach is "member functions, or if not that,
functions in namespaces, and qualified calls everywhere". That latter
bit makes it additionally more likely that students, if they
graduate and become programmers, will almost inevitably run into
namespace prefixes in C++.

I can understand that any namespace use can be seen as ugly, and that
there are concerns about learning curve and
causing hard-to-cure initial dislike in newcomers. But maybe one could
explain it a bit, and provoke a "but why would
there ever be multiple different but more-or-less similar looking ways
to do one thing?", and then show something like
https://www.twilio.com/blog/5-ways-http-requests-python :)

Personally, I'm so accustomed to std::names that when I see vector or
map, I become suspicious, and ask "which one might that be,
is there something peculiar going on here?" :) And if I then find out
that it is just std::vector and std::map with no intention of anything
different, I ask "well why didn't you just say so, would've saved the
trouble of checking whether there's some fancy indirections or
variability here".