Scratch

I agree. One of the reasons that Scratch is so great is that it doesn't try to do everything. I hope the Scratch team will be very judicious about adding new features and keep the target audience in mind.

There are lots of things you can't do in Scratch, but it has the key elements that people need to get an introduction to programming, logic, etc.

As a software engineer there are two things I really enjoy about Scratch. First, it's easy to do cool visual stuff that would be a lot more cumbersome in the languages I usually work with. Second, I really enjoy finding creative ways to do things in Scratch that would be easy in other languages (funny, after I wrote that I realized that those two things are the exact opposite of each other).

As someone who volunteers at an elementary school running an after-school computer club I'm really looking forward to using Scratch for its intended use - education. I haven't seen another free programming tool that I really felt would work well with that age group.

So remember, if you're a developer trying to write complex games or physics simulations, you're not exactly the target audience for Scratch. Not that you shouldn't do it, but don't expect the Scratch team to enhance the product to meet your needs. Now on the other hand if you're a 10 year old and you feel like you could learn more with a few key enhancements, by all means speak up.

Last edited by weissjd (2007-05-25 16:13:09)

I agree with Roberth.
Although creativity is the focus of Scratch, not complexity, Scratch should still have more functionalities than it does now.
For example, inheritance should definitely be included as it is very easy to visualize and it's one of the most important features of modern programming. 
When kids write programs, they want to learn the real way of writing it.  Not some weird way that will trick the program into doing it.  If they get into the habit of using those weird ways, it might be even harder for them to learn the real way later.

mungojelly wrote:

Whether or not to extend Scratch isn't an either/or question.  Scratch is going to be maintained by the team that's maintaining it, and if they stay focused on the goals they're on now, they'll keep it pretty simple.  Also, it's not going to be the last programming language ever invented in this style.  We should start thinking of our ideas not just as ideas for the next version of Scratch, but as ideas for all of the languages we can make next: More complex, simpler, or maybe just different.

One of the wildcards on this issue is to see what changes will happen to Scratch once the source code is released "into the wild".  And there are a small number of individuals who are both lurking as well as actively posting on these forums who are perfectly capable of rewriting major sections of the current implementation of Scratch to add these "extentions".  Myself included.

There is also a distinction that can be made between the particular implementation of Scratch that currently exists, and the specification of the computer programming language called "Scratch".  It is currently one and the same at the moment, but there is no reason to assume even this at the moment.  The issue is in some ways how to maintain the simplicity of Scratch and yet work to enhance characteristics of the spec here to allow for some of these more advanced software engineering concepts.

And while this may not be the last language developed along this line, Scratch does enjoy a few benefits at the moment which I find positive:  It has a working implementation (a rarity among a plethora of software language suggestions), a huge if usually silent sponsor on the part of MIT, acceptance by the target community, and a forum for discussing new ideas and directions of the language that is very inclusive and willing to seek people who otherwise have not been included in similar project in the past.  How successful they will be at accepting code contributions for changes to Scratch remains to be seen, however.

I'll also say that I have a bit of a selfish motive on this as well.  I wrote a modular multi-media development environment over 15 years ago that in many ways targeted the very same group of individuals that Scratch is targeting.  And my software was also very widely accepted, by at least those who had a chance to see it in the first place.  It was also sponsored by the U.S. Federal Government under a special 3-year grant targeting a particular implementation that strongly resembles what the LLK is doing now with Scratch... although the grant I worked under was from the Department of Education and not the National Science Foundation.  Unfortnately, the lead professor at the university where I worked on this software was adverse to the idea of open source software, and the whole project has been tied up for the past 15 years in a legal morass to even find the source code (I still have copies of it as the lead developer... but nobody has asked who cares).  BTW, the name of that software was called CID, and developed by the Nexus Group of the Department of Instructional Technology at Utah State University.

Interestingly enough, there was an effort with even interest by the then Governor of the state of Utah to establish a research community similar to the MIT Media Lab, but I also saw the whole effort implode due to political considerations that in retrospect seemed petty and downright childish.  Especially once the big money started to show up with a Department of Defense training contract routed through TRADOC and the Army.  I have no idea what ever really happened with that proposal, but it was very real and generated quite a bit of interest.

In all this time, I've been lurking to find something that even comes close to the vision that the development team I once worked on, and I think I've found it with the LLK and specifically Scratch.  Yes, there are other modular GUI development environments, but this is a really unique set of confluence of ideas and timing in terms of getting mindshare of people with similar ideas and people who are bright enough to appreciate really good yet elegant in both artistic and mathematical sense with a design.  This is a rare talent indeed to do both at the same time.

I can't wait for the source to scratch to be released... then we will see an evolutionary soup of programming languages of the 'lego brick' style (tm - no doubt).

I no... I can wait... but hurry along with it please ;-)

And thanks to fandebiao for posting to my thread on dynamically creating sprites... that is surely the biggest single missing feature atm.

One of my main beefs with the EX version of MicroWorlds (a logo product) is that is goes too far.  There is all sorts of cool stuff that you'd use if you knew what you were doing, but it makes things visually more complicated when you work with elementary school students and sometimes slows things down. 

So, I second the request to keep in mind the target audience.  Scratch works nicely for kids.

The advanced tab on Scratch is called "Squeak."  After using it for a few days, I've realized that we hardly need Scratch's source code.  The GUI of Scratch isn't original: It's a GUI called "Morphic" which has become the central user interface concept of Squeak.  The blocks on the left are Morphs that know how to click together, and the sprites on the right are Morphs that follow instructions coded by those blocks.  In fact, most of the things that sprites know how to do are standard methods shared by all Morphs!!

I don't mean to minimize the importance & power of Scratch.  It adds a lot that isn't in Squeak, for instance the whole infrastructure for sharing projects.  Perhaps even more importantly, Scratch functions as an effective filter.  By selecting a very limited range of options, they've made the program more comprehensible-- not only to children, but also to the media, which is truly simple minded.   

It's all well and good to say that you wouldn't be scared off by Scratch having advanced features, but the facts are that Squeak has been "Scratch but with advanced features" for years and no one has paid any attention.  It's slightly scary, and that's more than enough.

So, Roberth, anyone else who's interested, I think what we need to do is go into Squeak and make more entryways, more different views on the power of this set of objects.  Squeak is ready & waiting for an influx of energy aimed at making their objects friendly for children & strangers.  They've been trying to make it happen in various (perhaps sometimes contradictory) ways for years, but I think that Scratch demonstrates what could be a much more effective way of getting it going.

Squeak has been ignored for a long time, but maybe Scratch won't be the last big metaproject that comes out of that box of tricks, and that'd be something pretty hard to ignore.

<3

mungojelly wrote:

The advanced tab on Scratch is called "Squeak."  After using it for a few days, I've realized that we hardly need Scratch's source code.  The GUI of Scratch isn't original: It's a GUI called "Morphic" which has become the central user interface concept of Squeak.  The blocks on the left are Morphs that know how to click together, and the sprites on the right are Morphs that follow instructions coded by those blocks.  In fact, most of the things that sprites know how to do are standard methods shared by all Morphs!!

<snip>

So, Roberth, anyone else who's interested, I think what we need to do is go into Squeak and make more entryways, more different views on the power of this set of objects.  Squeak is ready & waiting for an influx of energy aimed at making their objects friendly for children & strangers.  They've been trying to make it happen in various (perhaps sometimes contradictory) ways for years, but I think that Scratch demonstrates what could be a much more effective way of getting it going.

I would like to study Squeak a little bit more than I have so far, although from first glance at how that language is put together, it appears to be something more akin to Python and Ruby.  That something like Scratch can be built upon Squeak does seem to be as a clear demonstration of ability of that language.

But at the same time, I would make the idea that Scratch is as related to Squeak as BASIC is related to FORTRAN.  And for many of the same reasons.  Many of the original language constructs of the original Dartmouth BASIC (I've brought this dialect up in several posts now... as I have used this explicit dialect in addition to the versions on microcomputers) were lifted directly from FORTRAN.  Indeed, some of the early literature called BASIC merely FORTRAN for kids.

I think there is an elegance to Scratch in both aesthetics and on a mathematical level that make it worth exploring how to make this language specification, regardless of the implementation, more powerful but still retain the basic simplicity that has given it the current popularity that it enjoys.  I have seen enough computer languages come and go, with hardcore supporters of each language that I hesitate to get into any sort of religious war over "what language is best".  I've also seen several "teaching languages" turn out to be powerful enough that some professional developers make entire careers using these languages.

I also don't agree with the philosophy that you need to artificially remove functionality for a teaching language.  And often because computer languages focused on instruction really concentrate on syntax and core ideas, they turn out to be better designed language specifications as a whole.  And designers aren't afraid to throw out features which destroy the simplicity, not to mention that more "eyeballs" concentrate on the specification rather than the implementation after the fact.

I absolutely agree with mungojelly and Martin: Scratch is cool and probably the best way for kids to get introduced to programming, but if you really want to build powerful, complex and advanced software project, do it like the Scratch-Team and check out Squeak!

Mungojelly, you seem to be referring to the Etoys-gui of Squeak, in which you can assemble morphs using the mouse and change their properties using viewers. Squeak, however, - as Martin pointed out, is a lot more, namely a fully featured professional Smalltalk environment.

It does seem strange that Squeak has virtually gone unnoticed for the past 10 years, while Scratch - being build on top of it and featuring only a very limited subset of its functions and ideas - really takes off. But it is a point in study about how to build a nice and simple gui, something that Squeak/Etoys has always had problems with, and which just now seems to be fixed for the OLPC.

Also, I do like the Scratch java player and the web 2.0 style site.

But I can't wait for the Scratch source code to be posted. I really believe, it's going to warp interest in Squeak. So many ideas could be checked out: How about blocks with graphical labels instead of titles texts?, how about creating tools to inspect and follow broadcasts throughout your code, how about implementing subroutines etc etc.

Again: If you're after powerful Scratch, go for Squeak!

Last edited by Jens (2007-06-14 03:15:27)

Etoys is another language in the ladder, a bit above Scratch.  The only rung above that on the Squeak path is to learn to talk to the objects directly in Smalltalk-80.  By reading the source.  (It's not nearly as hard as it sounds!  But it's still hard.)

If reading & writing source code were still the only meaningful way possible of programming a computer, then it might be just as well to leave it this way.  But I think that the intermediate languages we could create between toy languages like Scratch and full languages like Smalltalk could be useful in themselves.  If there were more rungs in the ladder, then someone who climbed up just halfway to Smalltalk wouldn't be merely an incompetent Smalltalk programmer-- they'd be a fully competent Half-Smalltalk programmer!

I don't think that it's even necessary to create particular software tools in order to do the filtering that's necessary.  A different way to do it would be just to define a subset of Squeak.  Squeak is presently overfeatured by just about any standard, and certainly too complex for a simple introduction-- but it has plenty of subsets which are fully featured and simple enough.  If a group of people just agreed on what to teach first, there could be the simplicity necessary for an active community of learners.

<3

DrJim wrote:

is there a simple and brief description of the Scratch/Squeak relationship somewhere?

For getting from Scratch to Squeak see:
http://scratch.mit.edu/projects/Jens/22355
You will have a very fascinating Scratch experience
(Thank you Jens for finding "the Matrix like Redpill" to get to the other side)

Last edited by MartinWollenweber (2007-07-25 14:13:35)

I agree that the Scratch team is doing a really good job developing Scratch, however I think that they should gradually try to expand Scratch.  I think that the team should make a version of Scratch with more advanced features, like true/false variables and possibly arrays. 

Scratch PRO

Richiepoo, that is not a good idea. Scratch was made for everyone to use. There shouldn't be a pro version that only experienced users can use.