I had to track down the bugs from embedded "gcc -O3" multi-#define-expanded C calling into Lua. Highly perverse definition of fun that would be, yet it was some

I had to track down the bugs from embedded "gcc -O3" multi-#define-expanded C calling into Lua. Highly perverse definition of fun that would be, yet it was somehow. :-) I read from your comment that the "kids should start with building their own CPU". The Java abstraction disease has eaten far too many souls who think the magic just happens, without regards for the sweaty chaps who make this magic come true :-) I would beg anyone to try to program as many languages as they find around. Both Python and Ruby have their strong traits, though integration with C is not one of them. But "12345.to_s(21)" is a construct that is nowhere else, much like "python -m SimpleHTTPServer". Then Haskell can be fantastic in it's mind-numbing math-derived domain-specificity (This, to me, is the biggest power of C and the biggest drawback of any meta-capable language - anyone new onboard needs to learn the custom shortcuts. C sucks at this so it is relatively easy for onboarding). But all the languages you try leave a useful imprint in your brains. For FFI, however, in my experience nothing can beat the http://luajit.org/ext_jit.html http://luajit.org/ext_jit.html. So, for something that may in the future benefit of low level offload, start with Lua, then move to Luajit, then move to Luajit+C. C being used for (preferrably) purely functional demonstrably performance critical parts. If you do not benefit first of a better TTM if used Python/Ruby... But really it all boils down to using the best tool for the job. Starting your education with assembler (mine was the 16x16 matrix of instruction codes of 8080 back in the day mapping onto bytes of raw data) gives you the insight of what is going down the curtains, and a possibility to keep the higher level languages in check. Sorry for verbosity, bit tired to write in a more terse fashion.