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.

Reply via email to