Per popular demand, here are Adam D Ruppe's presentation slides

[Adam D. Ruppe via Digitalmars-d-announce]

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.