So I would probably focus on some more basic principles with them and focus on what is faster and *why*. I would also *NOT* use javascript if the point was to look at efficiency but instead something like C. To be fair you can teach an aspiring student enough C to write basic data structures very quickly if they already know javascript.
When learning basic data structures and algorithms as an example learning sympathy with them is *required* for really understanding them. Let me give an example, a linked list or unbalanced tree made up of malloc'ed nodes vs a linked list made up of nodes pre-malloced into an array. How does each perform? What are the trade offs? What happens when the array is filled? If just malloced what happens when we introduce *other* mallocs into our code as it runs? Even such a simple implementation which is < 200 loc can go a long way towards understanding some trade offs involved. Looking using a tool at things like cache misses can also show *why* things may be doing what they are doing (eg when array gets too big to fit in cache and you suddenly see a slowdown due to the misses!) You can get pretty deep into what the computer is actually doing *very* quickly in such an example. I might also take the example to show the same code in assembler (as output by the JIT or compiler), most compilers can output, or you can view assembler from higher level languages such as java/C# (how to view asm from java/C# is also a useful skill few java/C# devs even KNOW (most professional devs don't know how to do this!)). Doing such you can very quickly get into things like how memory locations, caching, and other thing cause differences in how code executes. Another obviously fun one here is to look at the JIT compiler in debug/poduction mode, what optimizations were applied, how things are laid out, etc. One thing to be careful about here is that each student's computer will have slightly different behaviour. As such the parameters where things "change" will be different. A great board exercise would be showing each students computer, where things "changed" and comparing it to their processor/memory specifications/etc to see if patterns can be found. As a side note when dealing with mechanical sympathy I would almost *never* use javascript you will be learning far more about javascript and how to *force* it to do things (and getting tons of false positives to weed through) than learning about underlying things. HTH, Greg On Thu, Oct 18, 2018 at 8:32 AM kedar mhaswade <[email protected]> wrote: > There have been some arguments about this topic. In general, we seem to > agree that kids should start programming at higher levels. Showing sympathy > for the machine rather too early is perhaps counter productive. But how > early is too early? > > I was thinking of introducing Jonathan Bartlett's Programming from the > Ground Up > <https://download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf> > to a high schooler who has been programming for some time (e.g. understands > constructs like loops and functions, data structures like arrays and stacks > and has written several programs in JavaScript). My argument has been that > Bartlett effectively uncovers the way the machine looks and works from the > inside just to the right level of detail and that may provide a favorable > *perspective* on programming. > > What do people think? What are the factors *against* such an > introduction? What does research suggest? > > Regards, > Kedar > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Studying for the Turing test -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
