Sunday, June 16, 2019

Should everybody learn to code?

I saw something on SlashDot that raised the question: should all school children learn to code?

Yes.

For the same reason all school children should spend some time learning to sing, learning to do long division, learning to paint, learning some physics, learning some literature, learning to use a wrench and screwdriver, learning some history, learning some chemistry, etc, etc, etc.  I believe that children who get a reasonably well-rounded, reasonable quality education grow up to be happier than those who don't, all else being equal.  I don't have thousands of pages of peer-reviewed scientific research to support my belief, but I still believe it.

This does not mean that we should try to teach all children to be *good* programmers, any more than we should try to teach all children to be professional-level singers.  We just need to introduce a wide-range of subjects so that they have a basic understanding of what the subject is about.  After that, let their natural talents and interest drive where they go in-depth.

I never knew that software was my calling until I had my first opportunity to try coding in ... was it 1975?  This introduction was *not* taught in school.  It was a group called "explorer scouts", which may or may not have been associated with Boy Scouts of America, I don't remember.  All I can tell you is that there were no uniforms, no camping, none of the trappings of Boy Scouts.  The only activity I can remember was the programming.  It was Fortran on a time-sharing system with a teletype.  The fire it ignited in my brain overwhelms any other memories of the Explorer Scouts.  THIS is what I wanted to do; my path in life was obvious.


HOW TO TEACH IT?

So, how should programming be taught?  I don't know.  I know there has been a lot of research and development in the area of programming systems for young people.  Drag-and-drop icons representing programming constructs.  I've glanced at them, and even used one briefly (it was a google doodle).  It's OK, I guess.  I think an important goal is to give a child early success and a feeling of accomplishment.  I don't think those systems actually teach *programming*, but I think they probably do teach some fundamental concepts that are needed for programming.

My concern is that those systems don't really give a flavor of what programing is like.  If you sing in music class, you get a sense of what singing is.  If you play touch football, you get a sense of what that is.  I actually consider myself fortunate that I wasn't introduced to programming that way.  I suspect I would have thought that it was kind of neat, but I'm not sure it would have lit the fire.  Part of what inspired me with my exposure was just the limitless possibilities.  I'm not sure you get that with drag-and-drop programming.

The problem with most languages is the sheer amount of infrastructure you need to master before you can do things.  To write a simple Java program, you need to define a namespace and a class.  To print something, you need to enter System.out.println("something");.  To read a line from the user will require several lines of junk that would require hours of explanation if you want the person to understand what the lines mean.  Granted, you could just boilerplate it and tell the student to ignore all that stuff till later, but I think that reduces engagement.  As does the edit/compile/run cycle.  I don't think Java is a good first language.

I have taught a few people to program.  Want to know what worked for me?

"NO!  DON'T SAY IT!  PLEASE FOR THE LOVE OF ALL THAT IS DECENT, NO!"

Basic.

"GAAAAAAAAAAAAAAH %@!&*$!!!"


BASIC???

Yep.  And I mean BASIC Basic.  Line numbers.  One or two character variable names.  No "else".

10 print "hello"
20 goto 10
run

I find that humor is a good teaching tool.  If your first program is an infinite print loop, it's kind of funny.  Not very funny, but a little.  Also, you definitely need a REPL (Read-Eval-Print Loop), which Basic is.  No edit/compile/run cycle please.

It takes me an afternoon to teach somebody to program.  We don't get sophisticated, but by the end of the afternoon we do end up writing a simple "text adventure" style game.

You are facing two doors.  Do you want the right one or the left one?
? right
A lion has just eaten you!!!
Try again?
? yes
You are facing two doors.  Do you want the right one or the left one?
? left
You found a gold coin!
Do you want to keep going?  Or turn around?  (answer "going" or "turn")
? turn
You are facing two doors.  Do you want the right one or the left one?

etc.  See?  More humor.  How many ways can you kill the player?  :-)

I feel that the Basic language didn't get in the way of seeing the simple algorithm.  Any other language would have obscured the simple beauty of what we were doing.

I did it with my daughter (she was ... I don't remember ... maybe 10?) and she did well.  Afterwards, she did ask me some questions and got a little help.  Later that year she gave me a birthday present.  It was a CD ROM with her updated adventure program.  It has maybe a dozen "rooms" and lots of jokes and little surprises in it.  She was VERY proud of herself.  (I still have the disk.)

And ... she also pretty much lost interest.  If she really been into it, I would have immediately switched to a different language and showed how much BETTER it is to have meaningful variable names, functions with parameters parameters, arrays, structures, etc. etc.  I don't know if I would use Java or Python; I would have to experiment creating lessons with each.

Anyway, I really think an afternoon of Basic is a good way to introduce programming to a newbie of any age.  I *know* it works.

Wednesday, April 17, 2019

Black Hole Revealed!

I am in awe of the results of the Event Horizon Telescope team in their image of M87*, the supermassive black hole at the center of a distant galaxy!  I can't help but be especially excited at the role that computer scientists played in the analysis and reconstruction of the data collected by the radio telescopes to produce the image.

Radio astronomers have been doing long-baseline interferometry for a while now to produce images.  But the challenges of the Event Horizon Telescope were beyond what the earlier processing algorithms could make sense of.  The software team led by Katie Bouman developed the CHIRP algorithm that kind of blows my mind.  It warms my heart that women in science are finally getting some of the recognition they deserve.  (It also depresses me greatly that misogynist trolls are getting some press; geeze, can't we just enjoy the accomplishment?)  Anyway, Katie did a Ted Talk a few years ago that gives some excellent explanation about the algorithm.

If you want some understanding of why the image looks the way it does, I think that Derek Muller's Veritasium video does the best job that I've seen.  He also has a good follow-up video.

I also really appreciated astrophysicist Becky Smethurst's video that explains why the results are important (it's more than just further supporting Einstein's theory of gravitation).

Thursday, January 24, 2019

Volatile considered harmful

I happened on this today.  The article is narrowly-focused on Linux kernel work, but in my mind it helps to clarify a lot of "volatile" debate I've seen over the years.

https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html


I will note that when Corbet (the author) says, "the 'volatile' type class should not be used", what he really means is that you should not declare variables with volatile (or rather, almost never).  Corbet says, "the kernel primitives which make concurrent access to data safe ... If they are used properly, there will be no need to use volatile as well."  Some of those kernel primitives use volatile, but not in variable declarations.  Instead they use volatile in carefully-selected casts.

For example, as described in another Corbet article, he talks about another kernel primitive, "ACCESS_ONCE()".  It is defined as:

    #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

The variable being accessed is temporarily cast to volatile to allow code to be written that violates threading assumptions made by the compiler's optimizer.  Like here, for example.  :-)

I only bring this up to point out that Corbet is not arguing that volatile should never be used at all.  Rather he is arguing that programmers (specifically kernel programmers) should not declare variables to be volatile.  Generally, programmers should use threading primitives to ensure correct code, and if the code's requirements prevent the use of the usual threading primitives, then lower-level primitives (like "ACCESS_ONCE()") should be used to precisely target volatile's use.