MIT's Scratch

[Bobmuhthol]

A Programming Language Like Playing With Blocks
http://graphics8.nytimes.com/images/2007/05/23/technology/24program.600.jpg
By WARREN BUCKLEITNER
Published: May 24, 2007
Scratch is a creativity tool from the M.I.T. Media Lab that turns abstract programming concepts like recursion into snap-together puzzle pieces. It is like a multimedia sandbox, where children 8 and up are welcomed as media producers, following the same philosophical blueprint that inspired software projects like Logo and Squeak.
Since it was introduced last week, demand for Scratch, which is available as a 36-megabyte download from scratch.mit.edu, has swamped the Massachusetts Institute of Technology’s servers. The price helps: free with registration. Development costs were covered by Intel and the National Science Foundation.
Scratch’s drag-and-drop programming technique demands experimentation, and the software’s programmable objects, called sprites, can take on the form of your pet dog in a maze, or haiku words that self-narrate when clicked.
Future versions are in the works for mobile phones and portable computers, while the current download works fine on Macintosh OS X and Windows Vista, providing a free digital toolkit for anyone with a creative itch to scratch.

[The Ponzzz]

Hah, that's pretty cool.

[Celephais]

http://www.kidsprogramminglanguage.com/

Microsoft's Kids programming language. I haven't used it but apparently it's the same concept... get kids heads wrapped around programming concepts. It's been out for a while, DirectX based, occasional articles pop up on Code4Fun. I don't think it's that graphical but it's probably the next step after this MIT prog.

[Kranar]

Goes without saying but I'm not a fan of this approach to learning how to program.

Seeing this especially coming from MIT, home of the Scheme programming language. I mean Microsoft doing it is one thing...

[Celephais]

I'm curious why? And what approach would you prefer? I started "programming" with LOGO... and if kids were able to get more than just a drawing turtle out of their programming they'd be more interested... I think any learning concept that promotes getting kids interested in things is a good thing.

[AestheticDeath]

Goes without saying but I'm not a fan of this approach to learning how to program.

Seeing this especially coming from MIT, home of the Scheme programming language. I mean Microsoft doing it is one thing...

Im interested to know what is wrong with it as well. I know squat about programming and would like to start learning sometime in the near future.

[Celephais]

Im interested to know what is wrong with it as well. I know squat about programming and would like to start learning sometime in the near future.

http://blogs.msdn.com/coding4fun

Real good place to start I would say... the "New, start here" link will get you the links to the free MS programming software, I'm going to highly recomend VB.NET for someone starting, it'll really make breaking in easy, and Visual Studio Express designers make making windows programs/web sites cake.

The site has some really neat articles on programming "fun" non-work related type things... DirectX, etc...

[AestheticDeath]

Thanks.

[Kranar]

Getting people involved in programming is great, kids or otherwise. But it must be done at the conceptual level as opposed to the static approach used by many "teaching" methods you see today at introductory programming courses in high schools and even some colleges. This is not LOGO, far from it in fact; LOGO is a incredibly powerful and conceptual programming language despite being very simple in appearance. LOGO today remains an excellent way to learn how to program as opposed to learning how to do so using Visual BASIC or Java. It's funny because I was actually going to recommend LOGO (another one of MITs great contributions to programming language theory) as the approach children (or heck adults too!) should take in learning how to program.

People who learn how to program with languages like Visual BASIC or Java don't actually learn how to program anymore than someone trying to learn Japanese using a phrase book that tells you how to pronounce and recognize popular sentences.

What this type of "teaching" does is inbue people with very fixed and static notions of what programming is, and yes, they will very quickly in a week (or I think it's now "21 days") be able to write a "GUI" or some website or even draw pretty things on the screen or write yet another program that has been written thousands of times before them and is really nothing insightful or new... just as our fellow Japanese learner will be able to quickly learn to say "Hello, how is your day," "Where's the bathroom," and "I am hungry."

But what our learner of the Japanese language will not be able to do using his phrase book is learn how to think in Japanese; he will constantly think in English and then try and translate to Japanese using the static stuff he learned from his phrase book. This will make him very clumsy when it comes time to actually carry out a conversation in Japanese and it will take him much longer to become fluent at it.

Similarly, our Java/VB programmer, while a master of writing yet another GUI accounting program or software that just glues together libraries and functionality written for him by Microsoft or some other third party, will struggle when it comes time to write either highly scalabe software or extend the libraries or the language in new ways as different technologies emerge. He will constantly be there relying on Microsoft or Sun Microsystems or some other company to provide him with more and more powerful "phrase books" because while he is really good at pulling out phrases and inserting them into what are virtually templates, he is unable to actually come up with the phrases himself.

This, in my opinion, is why I've observed as a TA for introductory computer science courses, a lot of students who thought they were excellent computer programmers in high school writing some GUI program they point and clicked together in Visual BASIC... go to university, learn the conceptual approach to computer science, and then get bitter about it and either switch/fail out, or have to really struggle and work their tail off to keep up.

That's 0.02 cents.

[Celephais]

I think of it as a good start... I don't know exactly how you would teach someone japanese without first teaching them a few common phrases, if they're struggling to get out even the simplest of phrases and see no progress they'll quit just as quickly as the person who thought they were a wiz and find themselves crushed by concepts.

I might have started with LOGO and BASIC as a kid, but I then moved to C and didn't really find myself making a lot of progress... more or less I would end up finding code samples and copy paste them, occasionally I would delve in and tweak, but I found myself pretty overwhelmed and a lot of times it was a poke and hope approach (not actually understanding what I was doing, just changing things around). When I moved into the VB world I found myself making progress, this actually motivated me to go back and write some more code at the C level (as my VB experience taught me more concepts), and I would slowly replace API calls and built in controls (in VB again) with my own, to the point where I don't need them as a crutch anymore but I use them to accelerate development of things that are truely original.

I think a combination of both is important, writing bubblesort algorithms and data trees just isn't a good entry point for someone interested in learning programming (especially at a younger age)... especially considering video games are the biggest motivators for wanting to learn programming these days :)

[Kranar]

Of course that argument assumes I think C is a good starting point, which it isn't. I personally think it's much worse than VB as a starting point.

What's a great way to learn how to program that lets you apply and understand concepts, and also create video games at the same time? Try something like Python or LISP/Scheme or LOGO or some other incredibly flexible language that treats learning how to program in a way similar to playing with Lego...

You have a set of very primitive building blocks that are incredibly simple that a 6 year old could understand them. In programming these are statements/expressions. Heck LISP has only about 8 expressions you need to learn and you know the whole language, I wonder how many basic blocks of Lego there are, but I bet it's more than 8! You then have ways of taking these primitive building blocks and putting them together to create bigger building blocks and experimenting with how these blocks fit together. In LISP it's called composition and other languages have similar notions (ie. structured blocks). And then finally once you create a monster of a building block that it becomes too complicated to understand, or too big to carry in the palm of your hand, you do something that programming lets you do, that unfortunately Lego does not... you abstract it away. For those unfamiliar with that term... an abstraction is the process of taking something incredibly complex, and treating it as if it was something just as simple and basic as the built in primitives. It's like taking a massive Lego structure and using/manipulating it as if it was as simple as the 1x1 Lego block. Abstraction is THE most fundamental concept to understanding both programming and mathematics, and without it, you will find yourself lost and confused very quickly.

In languages like VB, C, Java etc... your means of abstraction are incredibly limited so you can find yourself swamped in complexity and details that become difficult to manage. What these languages by Microsoft/Sun Microsystems try to do to compensate for their lack of abstraction is provide a lot of "phrases", a lot of built in features and libraries (.NET is a prime example) so that they do all the abstraction for you and you just use whatever they provide to write your programs (it's good business for them). Instead of 8 expressions you need to learn to understand all of VB or Java, you need to learn like 30 or 40 just to get started, and every new version that comes out adds another 10 or so new phrases to the language that you need to learn. Seriously, what the heck is up with "public static void main(String[] args)", that was most likely a joke back from the 70s that went over people's heads.

In LISP/Python/LOGO... you can abstract absolutely anything; you can even abstract away the very process of abstraction itself to create meta-abstractions and so on so forth (in LISP its known as the meta-circular evaluator)... and when you do so you will feel a profound sense of insight and beauty in programming that unfortunately just isn't really found in languages where you're so confined and restricted by syntax as you are in C/Java/BASIC/etc...

The beauty of learning LISP as opposed to VB, is that when you learn VB you really are just learning whatever was provided to you by Microsoft and their implementation. When you learn LISP, you learn how to actually develop the language as you go, because LISP itself so darn simple you come to experiment with ways of extending the language itself and manipulating the very core of the language to suit your own purposes. That's the key difference between conceptual learning and static learning... are you really learning what it means, fundamentally, to write a program, to compute something?

The Lego analogy would be as if you became so good at building stuff with Lego, you understood conceptually what it means to take Lego and piece it together, that you manage to make a machine out of Lego that could then build other stuff out of Lego, possibly even other such machines (that is what the meta-circular evaluator does). You come to write programs that write programs that write pro... ... ... and you get the idea.

That, in my opinion, is where the really cool stuff happens. When you can write a program that can write a program, which is done all the time in LISP/Scheme/Python because it's at the core of understanding them as a language... then you've demonstrated a true understanding of what programming really is all about. And yes, once you do that... using DirectX or writing a GUI becomes much easier, in fact you do what Microsoft does... you write programs that do most of it for you.

[Celephais]

I've never worked with LISP or python and I know you've worked with the CLR based languages so I will certainly defer on the value of them as starting languages. But it sounds to me like you would like this program Bob mentioned from what you said about LISP... it uses fundamental blocks to start building a program... So it's graphical instead of typing those fundamental blocks, but short of programming in assembly you're using a program to write a program anyway. Now you're just using this graphical program to write the file (in whatever intermediate language it uses) used by a program that writes the program...

I see what you're saying I just think given such a small subset of "build blocks" can really restrict beginners, if you gave that kid who wants to build a lego car a chemistry set, some moulds and told him to make the legos himself before he could start putting together his car he might be a bit offput.

Kids might start building with just basic blocks, but before they're building anything good they start using those "api" blocks that really can't be built with the basic blocks they start with... so you start them with some good general purpose blocks that can't "do everything", and then you give them the pre-made specialized blocks they use to make things even better, and when they're ready to move to the real world they break out the chemistry set and make anything they want.

[Kranar]

To simplify my argument as much as possible... there is a distinction, between learning how to program, and learning how to write a GUI. Learning how to program, and learning how to use DirectX. Learning how to program, and learning how to move a cat around on the screen. It is a very subtle distinction, but it is important and it is similar to the distinction between learning how to speak Japanese, and learning how to say "Hello, I am hungry, where's the bathroom." in Japanese.

Now one might claim that in order to learn how to program one is best to start learning how to create a GUI, or how to use DirectX, or how to move a cat around on the screen... but in my own experience I find when people begin "learning" programming in that manner... they never actually learn how to program in general, all they do is learn how to use APIs or libraries and they stay at that level. When they reach a point where it is no longer sufficient to continue in this manner, they get frustrated and bail or they have to really struggle hard to catchup. It is so fundamentally different to learn programming than to learn GUIs or DirectX, they are entirely seperate and while I'm no speaker of Japanese, I would even go so far as to say it is much more difficult to go from GUIs/DirectX/APIs to general purpose programming, than it is to go from phrase book to full blown Japanese, but clearly I could be corrected on that.

Very few C/VB/Java programmers can stand to learn LISP... however LISP programmers learn Java without a problem, they just tend to dislike it.

[Celephais]

I'm not missing the distinction, I just think anyone who can't survive the leap from using APIs to really programming, in no way in hell can survive the leap from nothing to programming. And people who might not survive the leap from nothing to programming might be able to survive nothing to APIs to programming.

If you jump from nothing to real programming, using APIs is clearly already under your belt. You seem to be (correct me if I'm wrong) advocating a "send them to Japan, let them figure it out" approach where I'm saying "let them listen to a few tapes, pick up the basics, then send them to Japan"... for languages your method probably results in someone having a better undestanding, due to necessity, except in the programming world no one "Needs" to learn to program to the degree you would "Need" to learn japanese to survive, so throwing them in the deep end will just cause more people to give up, who might have made it if they inched in and learned the basics in the shallow end.

[Kranar]

Yes, you are absolutely correct about my analogy and it's actually a good way of putting it... I am advocating that if you are serious about learning Japanese properly, you do so in Japan with no phrasebook. I also believe that especially for kids, that this is the best way to learn it. With programming, it's actually not even frustrating, it's actually kind of magical because you have something like the LISP interpreter that acts as a genie of sorts, and you can probe it with questions and run experiments and make it do stuff for you... you learn how to program when you actually manage to program your own genie who is more powerful than the genie provided to you, and you then literally have armies of genies who can create one another and do all sorts of magic (in LISP this concept is known as Reflective Towers). That's not frustrating at all... it's wizardry. And it's something very few people who learn Java or C or VB ever learn how to do or even know is possible.

Whereas you believe that going from the phrasebook to the full blown language is easier than going from nothing to fullblown, I believe the opposite. I believe learning something statically institutes bad habits that are very difficult to unlearn later on, restricts your domain of thinking in that you become incapable of coming up with really creative and inventive ideas because everything that you ever learned was told to you. When for so long you depended on a phrasebook to study the Japanese language, it becomes really frustrating thereafter to actually have to come up with new and creative Japanese phrases on your own, because afterall, you had a book do it for you all this time.

Learning a new language, just like learning programming, and they are not that much different... should be done from scratch and properly from the very beginning via immersion within the language itself and not with a GUI library... The very position I hold is that going from the phrase book to the full blown language is virtually impossible and only unless you're willing to unlearn everything you learned from the phrasebook can you really come to appreciate what programming is all about.

[Celephais]

Whereas you believe that going from the phrasebook to the full blown language is easier than going from nothing to fullblown

In a way... no one goes from nothing to full blown, in your case there is still a learning process where you get stronger, I think the sum of going from nothing to phrases to full blown is greater than the sum of going from nothing to full blown, but I think the steps are smaller if you go to phrasebook first, then take some unlearning steps and relearning steps etc... You might end up having to go through more to get to the end, but you'll see accomplishments along the way that seem more meaningful than your accomplishments going entirely immersive.

People who have a hard time "breaking the bad habits" I don't feel would have been able to grasp the good habits from the start.

I also don't think that a lot of people getting into development really need or want to get to the point where they truely understand what's happening or the whole of the concepts.

Some people are just going to develop one ups from excel apps and that's about as far as they need to go... If I'm just planning on making a couple for pleasure trips to Japan, it might be nice to be fluent and "understand" the language, but I certainly don't need it. It doesn't take a whole team of "architect" level programmers to write a product, sometimes it even hurts when you've got too many developers understanding things.

And these genies just sound like APIs... or even more so "code snippets", what with them "helping" you write code.

[Kranar]

I also don't think that a lot of people getting into development really need or want to get to the point where they truely understand what's happening or the whole of the concepts.


And this is what I'm against because its a root cause for why so much software is poorly written and why the software industry is riddled with bugs, inefficient design and projects that are years and years overdue or that go beyond its budget.



Some people are just going to develop one ups from excel apps and that's about as far as they need to go... If I'm just planning on making a couple for pleasure trips to Japan, it might be nice to be fluent and "understand" the language, but I certainly don't need it.


And hence why I said there is a difference between learning programming, and learning how to write a GUI. Of course some people want to go visit Japan and all they need to learn is how to say "Where's the bathroom" or other key phrases... but people like those never cared to learn Japanese and if you asked those people if they speak Japanese, they would tell you no. More importantly, such people would never apply to become actual translators of the Japanese language or involve themselves in any kind of professional or substantial manner that involves the Japanese language. It's not the same with programming... you have way too many programmers who read the phrase book, can throw up a GUI and then think they're on top of the world until the time comes when they have to write something new and innovative at the company they work for or whatnot, and then end up writing incredibly poor software that is a nightmare to maintain, isn't properly tested and is just plain ugly... These bad habits do not go away, and it's not just a minority of programmers who cling on to bad habits, its the vast majority of them.



It doesn't take a whole team of "architect" level programmers to write a product, sometimes it even hurts when you've got too many developers understanding things.


If you're interested in this read The Mythical Man Month by a software engineer from IBM who documented his experience with what you describe. I'm of the personal opinion that only very small teams of 2-3 people should work on any given project, and thankfully that's how software gets written here at Google. In fact, historically some of the most influencial software was written just by one or two people (DOS, both Unix and Linux, C/C++ compilers, heck even Google's search engine was started by two guys in a garage), and then more people were added to the project way later on mostly for maintenance or to write supporting code or fix bugs. In general, more developers working on a project is usually a sign of poor architecture but this really doesn't have anything to do with either of our points.



And these genies just sound like APIs... or even more so "code snippets", what with them "helping" you write code.


Heh, the genies are neither APIs or code snippets nor anything remotely similar to one. The genie is the very essense of what computer science and programming is all about. Indeed, the genie is the Universal Turing Machine (http://plato.stanford.edu/entries/turing-machine/) itself.

[Kranar]

I think it's worthwhile to post an essay by a very influential figure in the history of computer programming, especially programming language theory. It's a good essay to read for general interest but also because he wrote it as a warning of the current state and development of programming and where it's currently headed:

Can Programming be Liberated from the von Neumann Style? A Functional Style and its Algebra of Problems (http://www.stanford.edu/class/cs242/readings/backus.pdf)

The author's name is John Backus, and he recently passed away but he is best remembered as the inventor of the FORTRAN programming language. For those unfamiliar with the history... FORTRAN (for Formula Translator) was the first programming language to be implemented back in the early 50s.

FORTRAN was the language widely in use in computer programming throughout the 50s to the 60s, and was adopted in a later incarnation by Bell Labs into a language called B (B for Bell obviously), then was re released as the C programming language in the 70s, which as we know is where C++ later came from in the late 80s, which became Java and C# and a bunch of other similar languages... all of them have their roots in FORTRAN, the Formula Translator. A brief history of computer programming in one paragraph...

But of course the issue is far more complex than that because in a parallel fashion another language happened to also be developed in the 50s, a language called LISP. Unfortunately, however, LISP which was developed at MIT, was designed as a language for doing advanced artificial intelligence and studying computational theory, whereas FORTRAN was designed to compute numerical solutions to mathematical equations.

Which of the two languages do you think would have received mass funding from the military or the telecommunications industry? Today you may be of the opinion that AI would be a no brainer, or not... but back then it was a sure thing that a language designed to do things like solve matrices which are of crucial importance to telecommunications, or solve differential equations which are of crucial importance to engineering was the no brainer and so FORTRAN got all the attention and infiltrated the industry and LISP was all but forgotten.

In this essay, John Bauckus, the inventor of FORTRAN himself, and who wrote this essay in acceptance of the ACM's Turing Award (the highest honour in computer science), describes why this is single handedly the greatest mistake we have made in our approach to understanding how to effectively use computers and how we can go about rectifying this problem. FORTRAN, as he explains, was never designed to do anything beyond solve mathematical equations and it most certainly was not designed to evolved into a general purpose programming language like C/C++/Java.

But, as we ought to know... bad habits just don't go away. When people get comfortable thinking and doing things in a certain way, and worse when INDUSTRY does it, the last thing they ever want is to then be told that they need to change.

So you'll read why he advocates an approach to programming similar to that of LISP, which as a language has gone on to develop Scheme, ML, Haskell, O'Caml, LOGO too (which actually is just LISP) and a vastly different world of programming languages that only now are beginning to see a re-emergence with the growing popularity of multi-core processors (which since the 50s they were designed to take full advantage of).

Bad habits have a way of sticking around way longer than they should. It was only in the 1990s that the telecommunications industry adopted a language called Erlang, which is also based on LISP and redesigned their entire network around it.

So anyhow... I stand firm in my position that our attitude towards programming really needs to change at the most fundamental level and that means learning how to program from the ground up in a rigorous and conceptual manner.

[Bobmuhthol]

Haha, the second I read the first clause without seeing anything else, I thought, "John Backus..."

So glad you posted that.

[Kranar]

Just the fact that you know the name John Backus actually impresses me a lot because very few people do.

I hope you enjoy the essay.