Mechanical sympathy for high schoolers?

[kedar mhaswade]

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 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

[Greg Young]

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

--
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 mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[fni...@redhat.com]

+💯

[Martin Thompson]

Nicely put Greg. Building, debugging, benchmarking, and profiling data structures is a great exercise which teaches many skills. Placing emphasis on the debugging, benchmarking, and profiling will develop really useful tools of the trade. The data structures are a great vehicle for that. Discussing what is discovered at each stage really helps build understanding, as you nicely point out in the what has "changed" between computers point.

Martin...

[Henri Tremblay]

If he likes it, why not. Even something like https://projecteuler.net/ can be seen as a great game. I love https://codecombat.com/ for younger.

Then, in general, what I have seen is:

1. Code stuff. 
2. What to do something.
3. Get stuck on something
4. Learn whatever is needed to be unstuck

That's pretty much it. In general, mechanical sympathy comes far far far in the list. Even normal programmers can avoid it most of their career. But algorithmics gets useful quite quickly. When you hear him say "Why is it that slow?" then you know you can go teach it. Tests can be taught the same way.

However, learning about how a computer works does help. Kids love it. I liked TIS-100 (a game) for showing assembly. However, I never tried with a teen. Might be a bit complex. But sometimes we are surprised.

I do agree with Greg and Martin though, Javascript is a very bad language for explaining a computer. C is better indeed. But make sure that's what he wants.

My final word of wisdom would be: Please let him create. I tired of stupid questions like "Are lambdas faster than anonymous inner classes?" because the answer is in general: "For what you are doing, you don't %$# care". I don't want a kid to be stuck and slowed down in his creativity by these questions. Until he is blocked by one of them.

--

[William Pietri]

I don't deal with high-schoolers much, so take this with a grain of salt. But I have tried to teach mechanical sympathy to young engineers from non-traditional backgrounds, so I have one small suggestion to add to the excellent advice so far.

My mechanical sympathy started with working on machines where performance issues were visible. On an Apple II, you knew if disk access was the problem because the floppy disk made a lot of noise; you could hear the seeks and the steady reads. You knew about network activity because you could watch the modem lights blink, or pick up the phone and listen to the pattern of the bits flowing. So early on, when something was slow, I developed intuitions as to why.

My computers have since gotten very quiet, but I still have the right edge of the screen devoted to a gkrellm display with a dense display of indicators. And any time I'm waiting, I check it to make sure the displays match my intuition. When I'm wrong, I pull out richer tools to find out why.

So my suggestion is to provide visual or auditory indicators of what you want them to have sympathy with. Then, every time they are waiting on the machine, quiz them as to why. Get them in the habit of guessing as to what the machine is doing and then finding out whether they're right.

As to the finding out part, you also might want to get them some copies of Julia Evans' zines, which cover topics like perf, tcpdump, strace, and debuggers. They're lively, approachable, and excellent. Her enthusiasm is contagious.

The zines themselves are here: https://jvns.ca/zines/

She also has a blog that I like a lot: https://jvns.ca/


William

[Ben Evans]

Also - don't forget about the Raspberry Pi. They are a fantastic
platform for hobbyists, including teenagers.

They are surprisingly capable little machines, but it's still very
possible to run up against their limitations. In my opinion, they
provide the closest modern equivalent to the home computers of the 80s
(which I'm guessing that many of us cut our milk teeth on) that
required even a novice programmer to think about the machine and its
behaviour rather than the far-abstracted and extremely powerful /
well-resourced systems that modern laptops / desktops are.

+1 to the Julia Evans (no relation) suggestion too...

Ben

[kedar mhaswade]

Thanks everyone! I will start with introducing the book (I was mainly interested in your feedback on that one). I agree, Raspberry Pi is also useful! I was concerned with the timing of such a piecemeal introduction of the computer organization to budding programmers. Looks like now is an appropriate time. I talked of JavaScript only to give you a background of the subject (the high-schooler).

Regards,

Kedar