I've been working on an educational programming language for children called Kalimat. One of the ideas about its design is "different concepts for different levels".
Some languages are quite easy to learn, like 80s Basic, while others try to still be easy but add structure or discipline. There's this famous Dijkstra quote (probably made in jest) about Basic ruining children's minds beyond all repair.
Well, Kalimat goes the other way by assuming "all repair" is possible, even a good thing: it starts with a language very similar to QBasic; a child can write interesting programs using only global variables, If conditions, and goto. They can learn with flowcharts if it benefits them, and they can use graphics routines.
We can call this "Level 1". Gradually, these primitive features are shed in favor of more advanced, more abstract features.
Kalimat is Arabic-based, but I'll use a hypothetical English version for the example. This is the typical 'guess the number' game:
n = random(20)
label begin
read "Guess the number:", #g
if g > n :
print "too high!"
goto begin
else if g < n :
print "too low!"
goto begin
else
print "good job!"
done
The benefit of this model is that almost everything is visible. The child doesn't need to know the abstractions of procedure calls, or keep in their head the semantics of such calls when thinking about what to do. Commands are executed, sometimes execution jumps. Variables store numbers and sentences, and that's more or less it. Now let's move stuff on the screen or write short quiz programs.
If the child outgrows the kind of programs this model allows, they can learn looping with
for and
while, and further learn procedure calls. Procedures are separate from functions: this allows the teacher to talks about procedures as "taking some lines of code and giving them a name", and then enter the realm of local variables and parameter passing, and finally talk about "defining our own functions" similar to built-in functions like sin, cos, or random. Let's call that level 2.
Level 3 is OOP. While OOP is now all about abstraction, there's some bit of "concreteness" left: There is no implicit "this" or "self" reference, and like, say, Python this reference is explicit. We also borrow the "send a message" metaphor from Smalltalk. An object can
respond to a message or
reply to it. Mirroring procedures and functions (I admit this part looks clumsy, needs experimentation to see if it turns to actually make the teaching easier).
class Point:
has x, y
responds to draw( )
end
responseOf Point p to draw( ):
drawPixel (x of p, y of p)
end
You've probably noticed the usage of cues from natural language to make reading programs flow more naturally. We are not trying to emulate COBOL or SQL; but we believe such cues in the right dosage could help with teaching and conversations about the code. I intend for Kalimat to have something of a canonical reading form, that is when reading code aloud, there is a known way to voice expressions, definitions, ...etc
Anyway, I like the result in the code snippet: "the response of a point P to 'draw!' is to invoke drawPixel at the x and y of P".
How about other levels? Now that the child's programming knowledge has matured, they can learn more: like for example concurrency. Kalimat uses the CSP model. First we have the
launch command that takes a procedure invocation and runs it separately. It's easy to take a program that draws an animated ball and transform it into 50 concurrently moving balls, with the simple addition of a loop and a
launch statement.
To coordinate between processes, we have channels and their usual operations:
send,
receive, and
select. Those same channels are also used for the GUI library; in my opinion this simplifies GUI programming in many situations. For example to create a program where the user draws lines you could do:
while true:
receive p1 from mouseClickChannel( )
receive p2 from mouseClickChannel( )
drawLine (x of p1, y of p1)-(x of p2, y of p2)
loop
The flow of execution matches the flow of user actions, no need to separate program state, and in larger programs the need for some design patterns is minimized.
Other than concurrency, Kalimat has (explicit) tail-call elimination for any ambitious teacher who wants to go into functional directions, and currently I'm working an a language-hosted PEG parsing, for people who want the children to create e.g NLP user interfaces, text-adventure games, or whatever they fancy. Kalimat is all about teaching thinking, computer science, and the fun of programming.
I did the design of Kalimat on intuition and from memories from my childhood days of programming, but I've recently found out about Piaget's well-know theory of child intellectual development stages. I'm not so sure about this, since I'm far from being a development psychologist, but there might be some fit between Kalimat's primary, abstraction-free, levels and the operational model of early childhood learning. This might be able to explain the exploding success of 80s Basic among children and allow us to take advantage of some of its characteristics.
Kalimat is open source, hosted on
http://code.google.com/p/kalimat
It is Arabic-based, but I hope to have an English version for better discussion and experimentation with the global programming education community, if anyone turns to be interested.
I once made a buggy, half complete English release (here's a
screenshot of it). I don't want to publicly release it at this stage, but I'd be happy to give it to anyone who requests. My email ID is samy2004 on Gmail.
