I read, that Smalltalk was designed for kids or for education. So was it good at it? Better than the other languages? Was it good/easy also for average kid (I read that bright kids enjoyed). Is there any study to back it up? Or is Your experience it is good?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as primarily opinion-based by Ixrec, MichaelT, durron597, Snowman, jwenting May 11 '15 at 7:12
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
Silly user, Trix are for kids, not advanced concepts like OO programming and design. :)
Any language that focuses on starting small, being simple, easy to start a project on, and gives instant results is a good language for kids to start with. That language for me was pre .NET Visual Basic. It was easy for me to draw forms, throw pictures up, easily write simple conditional logic within events and being able to press the Play button to see my masterpiece come to life before my eyes. As a kid writing my own video games was a bragging right and got me passionate enough to pursue this as a career. (now that I have an actual successful career the joy I once held for software development has been brutally mutilated by the reality of the business world).
Introduce kids to visual programming languages that teach them basic concepts while keeping things fun and interesting. Scratch looks like a promising project. http://scratch.mit.edu/
Otherwise if you have time and money look into Mindstorms, it is a robotics programming kit offered by Lego. Simple programming concepts can easily be taught by writing custom programs from custom built robots. http://mindstorms.lego.com/en-gb/history/default.aspx
I'm generally and advocate of introducing OOP and concurrency earlier in instruction than it is generally done (or at least was done in my time), BUT...
Kids (I'll assume we're talking about pre-teens) need to learn the absolute basics first, things that we take for granted so much that we don't even realize we know them. For those of us who first learned at an older age, these might even be things we knew before we learned programming, but things kids may not really grok too well yet.
The idea of sequence is the most basic. Instructions are run in order. The idea that instructions cause determinisitic changes in the program, and need to be exact. The idea of branching and looping in instruction sets. The idea that variables hold a value but can be changed and copied. (I still remember that light-bulb moment in seventh grade algebra when I understood what a variable was). Life experience gives us enough to intuit these things, to pick them up quickly once pointed out, but kids might not have the necessary life experience. They can understand them once explained and demonstrated, but they will often need that explanation.
To start, I think they need something where they can be guided to the most basic instructions and very quickly see things happening. Let them get a feel for the relationship between code and actions. Create an environment that allows them to expand the instruction set ("I want to make the turtle go in a circle!") and allows them to move at their own pace such that easy changes can be made easily, but there's a lot of space for more complexity depending on how far and how fast they're able to go.
After they understand the concrete relationships, then I would fairly quickly (letting him set the pace, but nudging him forward as he looks ready) move to more abstraction, such as dividing code into functions, grouping data, connecting functions to state (encapsulation), then objects and polymorphism. If the kid is still with you, he'll be well on his way and once he gets a solid feel for abstraction, things like concurrency and other advanced programming concepts can be introduced.
Smalltalk does not seem to be easier to learn or use than any modern language.
May be for the time it has been designed in the 70s... compared to LISP, yes.
Programming has little to do with the used language constructs, and much more to do with concepts like loops, functions, recursion etc.
Object Oriented programs might mach better real-world objects, but this is misleading, as good OO design introduces its own set of design problems.
Any revolutionary feature of an older language compared to a modern one, is either expected to be present, or already discredited.
To finish with an anecdote: While I was little (as English is not my first language), my friends thought 'If you learn English, you've already almost learned to program'. Even then I knew they are so far from the truth.
Fifteen years later, I am fluent in English. Still learning programming, and enjoying it.
Talk to the good programmers you know about how they got started in programming. For programmers of a certain age, my guess is that over 100X more got started with some form of bad-old "street" Basic than anything like Smalltalk, or even Logo.
It depends. The basic of idea of object oriented design, that of objects being something you send messages to, can be taught rather nicely. When I saw the researcher behind the project that eventually became Microsoft Kodu talk at Ignite Seattle several years back, any lingering doubts I had about object-oriented designs being a problem for children were eliminated. Some aspects of OO are quite intuitive, after all. There are very specific ideas that map nicely to domains that children (and other curious people) can relate to.
The broader question of whether the abstractions common in good OO designs are well-suited to teaching children? A much harder one. I started with imperative languages (and Logo), and I know plenty about the language of patterns that make OO designs more flexible, but even as a professional I have a little trouble knowing, for any given problem, which abstraction is best. But that balancing act is a large amount of what professional programming is about, and I didn't need to know all of this stuff when I was a hobbyist until a problem I didn't know how to solve nicely came up. So I'm not sure it's a problem, depending on what your aims are in teaching.
As for your specific questions about Smalltalk, I can't answer them, but Squeak, a Smalltalk implementation, could be fun for kids that want to move beyond the basics that they encounter with something like Kodu or, for example, Logo. The only real way to answer whether it's effective for teaching OO is to try.
Since most of my coding as a child was self-directed, and the availability of any community around me was nearly nonexistent, I used the tools that were available with the system I had, which basically meant Basic, Logo, and a modest amount of Assembly (TMS9900 and 6502/8502). It's fair to say that a suitably curious and determined child will surprise you if you provide tools that make simple things fun and hard things possible, and provide adequate mentorship when they get stuck on something. So I am fairly convinced that you could hand the right child Lisp or Perl or C# or Processing or Ruby and they'd figure out lots of things out on their own, and become incredibly frustrated with things you wouldn't necessarily expect to be an issue (which is where an experienced adult can help). But many kids, at least after a certain age, won't even be curious or determined enough to move beyond printing their name a few hundred times on the screen. I'm not really sure how much the language itself matters at the earliest stages of learning about computers, other than it should be relatively low friction to get something visual to happen.