Isla, a programming language for young children(isla.herokuapp.com)
isla.herokuapp.com
Isla, a programming language for young children
http://isla.herokuapp.com/
52 comments
I thought the example was intriguing, but it would be nice to have some minimal installation instructions for someone with no Clojure experience.
Often the initial investment in getting something to function the first time is the biggest obstacle to using it. I'd like to play around with this language with my son (age 11), but I've got a ton of other things on my plate and he's got a ton of distractions (Roblox, WoW, etc.), so having to go off and look up a Clojure reference moves this pretty far down the queue for me, unfortunately.
But, it's bookmarked for revisiting later.
I stuck an executable jar on my server just for you: http://classifyr.com/~zak/isla.jar - run this with
java -jar isla.jar
Thanks a lot. I've added a hastily compiled quick start readme to the repo: https://github.com/maryrosecook/isla/blob/master/README.md
It's not as complete as I would like, but I am working on it.
Is that enough to get you started? I'm happy to help out if you email me at [email protected] or tweet @maryrosecook
It's not as complete as I would like, but I am working on it.
Is that enough to get you started? I'm happy to help out if you email me at [email protected] or tweet @maryrosecook
from your third point above I immediately wanted to be able to write 'maybe' clauses, like 'if door is red then maybe door opens' :)
Do you think that a professional programming language based off a spoken language would be feasible if it were based off of something like lojban? It would be pretty neat if the distinction between code and language could be blurred.
While it's relatively easy to define a grammar for a severely restricted subset of a natural language that's both unambiguous and, given appropriate "vocabulary", sufficient to describe a wide variety of programming tasks — AppleScript is a readily available example — that's only a small part of the problem.
For instance, you also need to allow users to define "vocabulary words", including some way to import it from one or more external libraries that haven't necessarily been designed either well, or together. To remain unambiguous without sacrificing capability or becoming unnecessarily verbose, you then end up needing the same sorts of features for scoping, renaming, and qualified names you'd have in a more traditional language, versioning problems if you allow anything beyond fully qualified and explicitly imported vocabulary terms. AppleScript does little to prevent terminology conflicts — if anything, certain aspects of its design seem to encourage them — leading to unexpected behavior and hard-to-find bugs.
Also, you may as well introduce "unnatural" syntax like parentheses for regrouping arithmetic and conditional expressions, as all the ostensibly "natural" alternatives I can think of (requiring a series of assignments to often arbitrarily chosen variables to force subexpression evaluation, say) seem worse.
Furthermore, the simplest side effecting subexpressions can easily lead to hopelessly "unnatural" situations: suppose I have two objects "Alice" and "Bob", each with an integer property "age", defined as follows:
And so on. Seems to me that starting with a less ad hoc natural language would, at best, only help with the easiest parts.
For instance, you also need to allow users to define "vocabulary words", including some way to import it from one or more external libraries that haven't necessarily been designed either well, or together. To remain unambiguous without sacrificing capability or becoming unnecessarily verbose, you then end up needing the same sorts of features for scoping, renaming, and qualified names you'd have in a more traditional language, versioning problems if you allow anything beyond fully qualified and explicitly imported vocabulary terms. AppleScript does little to prevent terminology conflicts — if anything, certain aspects of its design seem to encourage them — leading to unexpected behavior and hard-to-find bugs.
Also, you may as well introduce "unnatural" syntax like parentheses for regrouping arithmetic and conditional expressions, as all the ostensibly "natural" alternatives I can think of (requiring a series of assignments to often arbitrarily chosen variables to force subexpression evaluation, say) seem worse.
Furthermore, the simplest side effecting subexpressions can easily lead to hopelessly "unnatural" situations: suppose I have two objects "Alice" and "Bob", each with an integer property "age", defined as follows:
Bob's age is twice Alice's age.
Alice's age is 35 minus the number of previous calls to Alice's age.
the sum of Alice's age and Bob's age
(2 * 35) + 34
35 + (2 * 34).
the sum of first getting Alice's age, then getting Bob's age.
And so on. Seems to me that starting with a less ad hoc natural language would, at best, only help with the easiest parts.
Honestly I think the more you make stuff "for" kids, the more complexity they have to deal with in addition to learning the programming concepts. With natural language languages, there's an uncanny valley where some of the dialect they are already working, and some doesn't, and it becomes a guessing game.
Another problem with natural language languages is they can be very tricky to localize, because grammar can be highly variable across different languages.
Exactly, Haskell for instance, would be fantastic as it just relies on symbols that can be commonly read by everyone, we don't have to grok the meaning of "function" and "and". The only time you'd need to learn English to program Haskell is using the functions from the STL or Prelude.
I don't understand the purpose of this. Stories are best read, written and told. Using a computer to do it would be rather restricting. I wonder if kids would get the point either.
The best way to interest kids seems to be to show them ways to do things better. Like draw perfect circles and rectangles with very little effort using a program like logo. Or show them how to write python programs to solve their math homework at top speed.
The best way to interest kids seems to be to show them ways to do things better. Like draw perfect circles and rectangles with very little effort using a program like logo. Or show them how to write python programs to solve their math homework at top speed.
I don't like these natural language programming languages
you see that it makes grammatical sense and then the brain infers that it can understand anything that makes gramatical sense. In the end, it's just as hard to remember what subset of the english language it can understand as it is to learn a new grammar.
you see that it makes grammatical sense and then the brain infers that it can understand anything that makes gramatical sense. In the end, it's just as hard to remember what subset of the english language it can understand as it is to learn a new grammar.
I agree. Kids get taught math symbols "+", "-" and "=" pretty early and don't write equations as full sentences.
Using symbols is a vital skill and makes things easier to understand, not harder.
Using symbols is a vital skill and makes things easier to understand, not harder.
I think it might be useful if your objective is only to write interactive fiction.
http://inform7.com/
I agree. This language is too far abstracted from the standard paradigms, hell I even have trouble bending my brain to this structure. I've been programming for 12 years.
When I was eight we had a turtle in our classroom, driven by Logo on a BBC Micro. No child had trouble understanding Forward 30, Left 10 and seeing the physical turtle make those moves. Adding in recursion was pretty straightforward too, and you could see the results (right or wrong) straight away as the little guy makes his moves.
I'm not suggesting Logo is right, but kids shouldn't be underestimated. This language seems patronising. App Inventor is much more in the right direction http://www.appinventor.mit.edu/.
When I was eight we had a turtle in our classroom, driven by Logo on a BBC Micro. No child had trouble understanding Forward 30, Left 10 and seeing the physical turtle make those moves. Adding in recursion was pretty straightforward too, and you could see the results (right or wrong) straight away as the little guy makes his moves.
I'm not suggesting Logo is right, but kids shouldn't be underestimated. This language seems patronising. App Inventor is much more in the right direction http://www.appinventor.mit.edu/.
I think not actually.
I think it's pretty helpful to get young kids to understand the logic first and then get introduced to programming operators and other weird characters.
It would be interesting to see if there's any research or papers on this.
I think it's pretty helpful to get young kids to understand the logic first and then get introduced to programming operators and other weird characters.
It would be interesting to see if there's any research or papers on this.
There is plenty.
http://www.papert.org/works.html
http://www.papert.org/works.html
I think you are thinking about this exactly the wrong way.
You don't start with the abstract. You start with the concrete.
You don't start with the abstract. You start with the concrete.
I disagree. That approach might work for teaching CS to college students, but most young children would find it boring. A much larger percentage would find the idea of making an interactive story fun than would enjoy learning about the low-level mechanics of a computer.
Why do you think they would find it boring?
In part, because I did.
I started with BASIC, but didn't really get in to it before being introduced to Hypercard. With that, I could make cool stuff almost immediately. A year or so later, I was told that real programming meant programming in C, so I tried that. It made me lose interest in programming for quite some time, as I couldn't imagine making any of the things I wanted to make with it.
It's more or less the same issue that affects technically cool products that don't actually address the needs of consumers.
I started with BASIC, but didn't really get in to it before being introduced to Hypercard. With that, I could make cool stuff almost immediately. A year or so later, I was told that real programming meant programming in C, so I tried that. It made me lose interest in programming for quite some time, as I couldn't imagine making any of the things I wanted to make with it.
It's more or less the same issue that affects technically cool products that don't actually address the needs of consumers.
You are asuming that everyone is like you? Bad premise to begin with.
There are a lot of children to whom programming isn't even in their vocabulary, but storytelling is.
There are a lot of children to whom programming isn't even in their vocabulary, but storytelling is.
I also remember other kids learning to program as pre-teens or early teens. Most of them wanted to learn to program so they could make things, not for its own sake. Most things that were interesting to them would be burdensome to write in C.
So, teach them ARM9/Arduino/PIC/X86/other assembly? (I wonder how many people here as kids first learned to program by typing in assembly programs from magazines.)
Just because we used to do something does not mean it's the most effective way to do it.
The point here is to teach children (not just hacker wiz kids) some basic premises of programming without making it about programming.
It's pretty clever IMHO and it allow children to create exactly the world they want to create whether that is vampires or bunny land.
The point here is to teach children (not just hacker wiz kids) some basic premises of programming without making it about programming.
It's pretty clever IMHO and it allow children to create exactly the world they want to create whether that is vampires or bunny land.
"Just because we used to do something does not mean it's the most effective way to do it."
True, but the fact that we used to do it also doesn't mean that it must be broken. I doubt many of would be better programmers if we had a more child-friendly programming language to learn when we were young.
True, but the fact that we used to do it also doesn't mean that it must be broken. I doubt many of would be better programmers if we had a more child-friendly programming language to learn when we were young.
Instead of thinking about this as a way to learn programming think about it as a way to internalize the principles of programming by removing some of the abstraction.
Think of this as php for children. An easy to use forgiving environment that welcome everyone not just the few who have the stamina and interest to learn assembler.
And think of this as the future of programming languages as they will become more and more abstracted from the core.
Those who want to dig deeper can.
Think of this as php for children. An easy to use forgiving environment that welcome everyone not just the few who have the stamina and interest to learn assembler.
And think of this as the future of programming languages as they will become more and more abstracted from the core.
Those who want to dig deeper can.
This example might work if they implement a rich grammar, since a generation of people who are now in their 20-30s were used to text adventures. If you knew text adventures I think you'd understand the scope of this.
But yes, if you're new to programming you'll probably be quite frustrated by the limited grammar.
But yes, if you're new to programming you'll probably be quite frustrated by the limited grammar.
Isn't there an advantage to just being able to intuitively read it, even if there is no advantage when writing?
You can't intuitively know what it does without understanding the logical flow of the "program" and what the commands do. I had no idea what this program did until I saw the output.
If someone learns the logical meaning of these words, they are better off learning a proper programming syntax.
If someone learns the logical meaning of these words, they are better off learning a proper programming syntax.
But you can test it in a very forgiving environment and thus learn about variables, input and output.
Current programming languages already use English words. I believe we already have experiences that demonstrate that it helps. If the syntax of the language also match English, my intuition tells me it will probably work.
Care to experiment?
Care to experiment?
I'm not necessarily drawing a direct parallel here, but this example of teaching programming through the concrete example of telling a story reminded me of this paper[1], in which the authors show that teaching math through abstract concepts leads to better understanding of material than teaching through several concrete examples in undergraduate students.
[1]: Kaminski et al., "The Advantage of Abstract Examples in Learning Math", 2008 — http://www.physics.emory.edu/~weeks/journal/454.pdf
[1]: Kaminski et al., "The Advantage of Abstract Examples in Learning Math", 2008 — http://www.physics.emory.edu/~weeks/journal/454.pdf
Anecdote warning:
I'm not going to get the abstract unless you start with a concrete example and then head for abstract territory. "Learning abstraction" is memorization. Until you can tie it in to something real, the concepts aren't. Coincidentally, I suspect this is the difference between "computer scientists" and "programmers."
I'm not going to get the abstract unless you start with a concrete example and then head for abstract territory. "Learning abstraction" is memorization. Until you can tie it in to something real, the concepts aren't. Coincidentally, I suspect this is the difference between "computer scientists" and "programmers."
hackers learn by tinkering :). I'd personally learn as little as possible in a way suggested by the paper. I'll do it even if it takes 3x longer, because for me it is more fun to learn by tinkering. I'll learn the deep stuff after I get my feet wet. The real question is what fraction of the class has the patience to soak in the abstraction for years together so that they can apply it once they have have become experts.
I've also encountered people who prefer abstraction over concreteness and it works for them. So the best is for each student to learn according to his preferred style. I hope courses like udacity and coursera slowly evolve into something where each student learns by his/her preferred method.
I've also encountered people who prefer abstraction over concreteness and it works for them. So the best is for each student to learn according to his preferred style. I hope courses like udacity and coursera slowly evolve into something where each student learns by his/her preferred method.
This allows you to tinker.
Exactly.
There is a reason we don't start with the most complex. Learning a language like this teaches you symbolic manipulation. Each word is a variable. You intuitively get that as you start playing around with it.
This serves as a bridge for later.
There is a reason we don't start with the most complex. Learning a language like this teaches you symbolic manipulation. Each word is a variable. You intuitively get that as you start playing around with it.
This serves as a bridge for later.
Reminds me of Inform 7: http://inform7.com/
People keep bringing up Inform 7, I think this is closer to the mark:
http://comments.gmane.org/gmane.comp.lang.smalltalk.fonc/317...
http://www.michaelslevinson.com/satevepost.html
http://comments.gmane.org/gmane.comp.lang.smalltalk.fonc/317...
http://www.michaelslevinson.com/satevepost.html
Logo has been successfully taught to 4 year olds.
It has very simple syntax (lisp without parentheses), and the imperative style is easy to reason about. Direct control of the turtle has a lot of appeal-- probably more than making a text adventure.
[How to train your robot](http://drtechniko.com/2012/04/09/how-to-train-your-robot/) is a programming game that follows similar ideas.
It has very simple syntax (lisp without parentheses), and the imperative style is easy to reason about. Direct control of the turtle has a lot of appeal-- probably more than making a text adventure.
[How to train your robot](http://drtechniko.com/2012/04/09/how-to-train-your-robot/) is a programming game that follows similar ideas.
I can't believe we're 30 comments in and nobody has mentioned Scratch yet! (http://scratch.mit.edu/ or http://en.wikipedia.org/wiki/Scratch_(programming_language))
If you're not familiar with it, Scratch was developed by the Media Lab and heavily influenced by Logo. It's used in thousands (tens of thousands?) of elementary schools to teach programming concepts. It's a really great language, and is incredibly visual.
One of the great things about Scratch is that whilst it's certainly heavily slanted towards children it's not exclusively for them. Actually, Scratch is used at Harvard for the first week of their Intro CS course. If you're interested in programming languages for children and those new to CS then Scratch is well worth a look.
If you're not familiar with it, Scratch was developed by the Media Lab and heavily influenced by Logo. It's used in thousands (tens of thousands?) of elementary schools to teach programming concepts. It's a really great language, and is incredibly visual.
One of the great things about Scratch is that whilst it's certainly heavily slanted towards children it's not exclusively for them. Actually, Scratch is used at Harvard for the first week of their Intro CS course. If you're interested in programming languages for children and those new to CS then Scratch is well worth a look.
Yep. I introduced my little brother to Scratch and he quite enjoyed playing with it for a week or two, making a little game or three in the process with a bit of help from me. It's a great experience.
I think it might be slightly confusing for younger people, because it's almost 'real' programming, especially once you try implementing things like side-scrolling animation. But it's certainly powerful, and the way the code is created by dragging and snapping parts together is neat.
Give it a try with your young cousins, and give them an early taste of programming! When they're modding their games in the future they'll thank you for it.
I think it might be slightly confusing for younger people, because it's almost 'real' programming, especially once you try implementing things like side-scrolling animation. But it's certainly powerful, and the way the code is created by dragging and snapping parts together is neat.
Give it a try with your young cousins, and give them an early taste of programming! When they're modding their games in the future they'll thank you for it.
I agree that the turtle is good but again remember Paperts point is to allow children to assimilate knew knowledge into their already existing library of models.
The power of the computer is that it can simulate virtually everything and thus allow for children (or anyone else) to build their knowledge by using models they already have an intuitive understanding about.
The power of the computer is that it can simulate virtually everything and thus allow for children (or anyone else) to build their knowledge by using models they already have an intuitive understanding about.
Reminds me of http://www.cc.gatech.edu/~asb/thesis/ although it's not really clear to me where they're trying to go with this.
This is IMHO the correct way to do these things. Seymore Papert wrote a brilliant book on the subject.
Here is the forword to his book:
http://www.papert.org/articles/GearsOfMyChildhood.html
From the link:
* One day I was surprised to discover that some adults--even most adults--did not understand or even care about the magic of the gears. I no longer think much about gears, but I have never turned away from the questions that started with that discovery: How could what was so simple for me be incomprehensible to other people? My proud father suggested "being clever" as an explanation. But I was painfully aware that some people who could not understand the differential could easily do things I found much more difficult. Slowly I began to formulate what I still consider the fundamental fact about learning: Anything is easy if you can assimilate it to your collection of models. If you can't, anything can be painfully difficult. Here too I was developing a way of thinking that would be resonant with Piaget's. The understanding of learning must be genetic. It must refer to the genesis of knowledge. What an individual can learn, and how he learns it, depends on what models he has available. This raises, recursively, the question of how he learned these models. Thus the "laws of learning" must be about how intellectual structures grow out of one another and about how, in the process, they acquire both logical and emotional form.*
This kind of programming environment despite the stars in here scolding it is exactly how to teach IMHO.
What this allow children to do is to tinker with words and through an input/output model allow them to learn about variables.
There is no right or wrong output here (perhaps besides gramatically) there is only input/output.
The basic of computer-science is it not?
Here is the forword to his book:
http://www.papert.org/articles/GearsOfMyChildhood.html
From the link:
* One day I was surprised to discover that some adults--even most adults--did not understand or even care about the magic of the gears. I no longer think much about gears, but I have never turned away from the questions that started with that discovery: How could what was so simple for me be incomprehensible to other people? My proud father suggested "being clever" as an explanation. But I was painfully aware that some people who could not understand the differential could easily do things I found much more difficult. Slowly I began to formulate what I still consider the fundamental fact about learning: Anything is easy if you can assimilate it to your collection of models. If you can't, anything can be painfully difficult. Here too I was developing a way of thinking that would be resonant with Piaget's. The understanding of learning must be genetic. It must refer to the genesis of knowledge. What an individual can learn, and how he learns it, depends on what models he has available. This raises, recursively, the question of how he learned these models. Thus the "laws of learning" must be about how intellectual structures grow out of one another and about how, in the process, they acquire both logical and emotional form.*
This kind of programming environment despite the stars in here scolding it is exactly how to teach IMHO.
What this allow children to do is to tinker with words and through an input/output model allow them to learn about variables.
There is no right or wrong output here (perhaps besides gramatically) there is only input/output.
The basic of computer-science is it not?
Excellent reference. Papert created his own theory called constructionism based on the tenants of learning by doing and accumulated knowledge acquisition (genetic epistemology). He emphasized making learning tools meaningful and relevant to children, so that they could use their prior experiences to help model new concepts. With LOGO, children used imperatives to command a turtle around on screen. When things went wrong, children could "act like a turtle" to debug, often by physically acting out the commands themselves. He called it body syntonic learning, as opposed to the more traditional disassociated learning we typically see. Shameless plug: I recently wrote more about this in a review of the book "Mindstorms" that this was an excerpt from: http://bsumm.net/2012/07/01/mindstorms.html
Dammit! Can you people please stop adding to my reading list! ...sorry, two very good reads in the lat two posts.
I am currently teaching a Saturday morning LOGO class at my daughters school. Who'd a thunk kids (and parents) would forsake Saturday morning in the mall to futz with a little turtle on a screen... But they love it and for once the kids are learning a non-consumptive use of computer technology.
I am currently teaching a Saturday morning LOGO class at my daughters school. Who'd a thunk kids (and parents) would forsake Saturday morning in the mall to futz with a little turtle on a screen... But they love it and for once the kids are learning a non-consumptive use of computer technology.
Great writeup.
And yes that book is great if anyone want to understand and truly develop ways to better teach children (and adults).
So many insights it's almost sickening.
And yes that book is great if anyone want to understand and truly develop ways to better teach children (and adults).
So many insights it's almost sickening.
I always thought REBOL was quite a word like language that kids might 'get'.
Check out... http://www.rebol.com/docs/reference.html
You can even use 'add' instead of '+' if it helps. http://www.rebol.com/r3/docs/functions/z-plu.html
It also has a neat gui dialect, although a little retro looking.
You can even use 'add' instead of '+' if it helps. http://www.rebol.com/r3/docs/functions/z-plu.html
It also has a neat gui dialect, although a little retro looking.
Just get them indestructible python-controlled helicopter (ages 7+) or slower moving car (ages 5+). Once they've get the connection between car movements and writing statements in iPython it'd be a lot of fun for them. And time to find some cover.
Don't worry about trying to simplify modern general purpose language. Modern languages are already as simple as they could get. [And whatever you do, don't make them write machine code in binary. Although it is a lot of fun for a kid, that could seriously screw them up. Don't ask me how I know...]
Don't worry about trying to simplify modern general purpose language. Modern languages are already as simple as they could get. [And whatever you do, don't make them write machine code in binary. Although it is a lot of fun for a kid, that could seriously screw them up. Don't ask me how I know...]
I agree with the people who say that a programming language that apes natural language can be frustrating. Inevitably, it cannot support even a fraction of the constructions that a human brain can parse. What made me try a natural language approach is the following (contentious) ideas:
* Children find it hard to type punctuation. Natural language can be parsed without punctuation.
* Someone new to programming probably knows nothing of conditionals, loops, logical operators and functions. So, a language that codifies these concepts as jargon in the form of keywords is going to be alien.
* If you ruthlessly constrain the features of a natural language-like programming language, it's possible that you can keep the advantage of human readability and dodge the disadvantage of the "uncanny valley", as `antihero` succinctly put it. In Isla, the only expressions are instantiations, assignments (with support for objects), `if this then that` style rules (maybe), and invocation of built in functions.
* The joy of programming is in building something. To get children interested in programming, the language they use needs an application. Children love telling stories, so why not make the application a story-telling environment? This gels nicely with the sparse feature set of the language: writing a story is mostly a matter of data definition.
This is the first programming language I have ever made. All these ideas are theories. Isla is just my first shot in the dark.