Something to keep in mind while you debate $FAVORITE_LANGUAGE is that the environment is just as important as the programming language. I seriously doubt it is a coincidence that many individuals, who started programming on the 8 bit machines of yesteryear, are today actually quite accomplished at what they do. Yes, BASIC may not be the preferred choice, but those machines had:
*) Concurrency. You needed to tinker with and understand interrupts, meaning concurrency, in order to do many of the seriously interesting things back then. Interrupts may not be feasible today, but multi-threading is, possibly with message passing as IPC. (That would be hard(er) to mess up, compared to most other IPC mechanisms I can think of.)
Considering how bad many new programmers are at thinking about concurrency, combined with the importance of the subject on modern programming architectures, I'd say this should be a must-have, through library support or some such.
*) Low level access in assembler. Use $PREFERRED_HIGH_LEVEL_LANGUAGE for the overall program structure, and low level assembler for the super time critical bits, including easy integration of assembler snippets calls from within the primary language. The assembler-for-kids could have a (much) simplified machine model, which shaves off most of the complexity of the full CPU. Think a simplified assembler like a 32 bit 6502 (A, X, Y, SP, PC, Status), no multiplication nor division, very few addressing modes and limited number of OP codes/instructions. This seems relatively easy to do on an ARM CPU.
Many new programmers seem to have difficulties with optimization and refactoring of existing code, or even to think about speed/memory optimal code to start with. Doubly so if they have to invent new and non-trivial data-structures in order to do so. I believe this key skill in part comes from being forced to think about weird optimizations and tinkering with 'funny' algorithms in assembler, like binary division or a square root on a 6502...
*) Easy hardware access, if possible. The environment should provide easy access to hardware, possibly virtualized, so that no real setup need to be performed by the programmer. GPIO pins for use with external hardware interface and 'bitmapped' (probably 32 bit per pixel on the Pi?) screen area are the two primary ones needed. First one for flashing LEDs and whatnot, which will be very important to encourage further exploration, and the second to have something for your assembler subroutines/methods/functions to show off in. May need a library call to initialize, but once set up the environment should provide a *completely* transparent memory mapped I/O. PEEK and POKE calls the 21st century!
*) Graceful simplification. Must be *really* easy to get started with. I must confess I am not convinced I would have grokked functional programming back when I started out. It is fine to facilitate OO and more, but for starters you want:
10 print "Hello!"
20 goto 10
Quote from tufty on November 4, 2011, 21:14
* In case you've never seen it :
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
I have always wondered if this quote was written along the same vein as Newton's comment about his predecessors: "If I have seen further it is only by standing on the shoulders of giants." (Meant sarcastically as his view of his contemporaries was fairly low, and one of his most outspoken opponents was of low, physical stature.)
In any case the quote is funny, as the majority of programmers starting out in the eighties, started learning in BASIC. At least a few of them turned out not too badly.