Another thing I said but want to expand upon now: near the end, I
started blabbing about stack frame setup in assembly, something I
actually learned from C. (When I was writing assembly a bit more
seriously - always still just a hobbyist btw - I would just use
the registers, push/pop, and sometimes a global scratch buffer
inside functions for computations. Actually, that worked really
well, ideally compilers want to do that too with efficient
register allocation, but the stack frame is nevertheless a useful
concept to know.)
But anyway, the key point there isn't one specific technique, it
is rather that digging a bit deeper into a new language can teach
you new ideas in your existing languages. Of course, most
languages can do everything any others can do fairly easily (and
you can always do the x86 emulator and jit your other stuff to it
if not :P), but you don't always /consider/ doing something else
until a new language puts it in your face.
C got me thinking about stack frames in assembly. Assembly, in
turn, helps understand just what those C constructs do so you can
get a bit more out of them, e.g. a switch being a jump table
makes sense when you think about the code it generates as well as
other rationales in the standards like Scott Meyers talked about
- do it, iff there's zero runtime cost. With that idea and some
knowledge of the generated code, what previously looked like a
set of contradictory, arbitrary rules now fit together and make
sense. (You might still disagree with them, but at least now that
disagreement will have some common ground of understanding to
talk about instead of you thinking the authors are just idiots.)
Similarly, C++ was my introduction to virtual functions. Before
playing with C++, I rarely used function pointers at all in C.
They were always there; it was always possible to do that kind of
generic indirection interface stuff in C, but until using C++, I
just never even considered doing it.
Don's talk was fascinating to me on this same vein: slices are
extremely common in D and super super useful. True, you can do
the same kind of thing in C or C++ using a pointer and length
combo (and it isn't even all that uncommon), and with a little
care, you can handle memory ownership without the GC's help too
(BTW I stand by what I said there about liking the gc. It isn't
always right, but it really is so nice to have that standard
owner, to not worry so much about things like double free bugs.
It doesn't mean you can stop thinking entirely about ownership
since the data may be stomped - immutable gc objects more or less
do though lol - but it does really simplify a lot of things).
But anyway, I digress again, the point is yes you can do slices
in C++, but just like doing vtables in C, is that a paradigm
you'd have seriously considered if you didn't see it done so
easily in D?
Isn't the ease of use D offers still a nice advantage over
borrowing the concept in C++, just like how C++'s virtual keyword
is a nice addition to doign it in C?
I say yes. So bottom line, the new languages can teach us stuff
about our old languages and then if we really like idea, the new
language can be compelling anyway just because it is that much
easier to use.
So to sum up, I think it is a nice analogy to say D's slices wrt
C++ could be argued to be like C++'s virtual functions wrt C.