Scratch

Paddle2See wrote:

Does the Scratch license allow porting to another language?

I hope so. But I don't know for sure. Scratch Team?

dbal wrote:

Greenfoot [...] does not have a drag and drop interface.

The drag and drog interface (the Scratch's one) is what makes Scratch appealing to me.

dbal wrote:

It strikes me that it might be easier to make Greenfoot look more like Scratch than to port Scratch to Java

That could be good news. And StarLogo people are making available the source code of their drag and drop interface.

dbal wrote:

folks at CMU release Alice 3.0, it will not only provide a 3D drag and drop interface, it will also expose the full power of Java.

I'm not fond of Alice. It gets very nice results, but the interface is far from being run-and-use as Scratch's one. Maybe Alice 3.0 will be fine. Unfortunately I have seen that it won't be released before summer 2009.

Last edited by s_federici (2008-06-21 11:42:44)

I believe Squeak is cross-platform (the image files are, anyway). I'd love to see Scratch's capabilities extended. I don't even see why we'd have to contain it to Scratch, why not write an interface that lets you write in other programming languages using blocks?

Hi, s_federici.

Scratch is slow, but it's actually by design, not because it is written in Squeak.

Scratch tries to make it easy for beginners to understand how their programs work by giving costant graphical feedback. When you run a Scratch script, it pauses after nearly every command to redraw the screen. That means you see all the intermediate results, even if only as a brief flicker. For example, if you run:

  forever
    move 10
    move -10

you'll see the sprite flickering between the two positions. In other programming languages, this might result in your program hanging with no display at all (an "infinite loop error") or it might appear that the sprite does not move since the two move commands cancel each other out.

In presentation mode, Scratch does a few more commands between display updates, but it always does at least one display update for each iteration of the innermost loops. Since the Scratch frame rate is limited to roughly 30 frames/second (deliberately), your loops can't run any faster than about 30 iterations/second. That's only about 10,000,000 times slower than a C++ program can run a loop! But that's because the C++ program isn't trying to help the user understand how it's working.

So, you are quite right in your intuition that a blocks-based programming language could go faster than Scratch. In fact, since blocks are just another syntax that can be compiled, a blocks-based programming language could generate code that ran just as fast as C++ or Java. As a computer scientist, I would love to see someone experiment with such a programming language. But if there were such a language -- a compiled blocks language optimized for speed -- it would not be as easy to use or understand as Scratch.

What about getting better performance in Scratch? Well, once you've gotten part of your program working well you might want to turn it into a "black box" that acts the way the build-in commands do: that is, it runs fast and doesn't let you see the intermediate steps. There has been a lot of discussion, both in the forums and within the Scratch team, about adding a "build-a-block" facility to Scratch. If we had such a facility, blocks you built would run as fast as they could without any intermediate displays. That would allow you do to run complex computations involving many loop iterations much faster. Something like Canthiar's Ray Tracer, for example, could run much faster with a few carefully chosen "custom-built blocks".

I'm can't say for sure if or when we'll add "build-a-block" to Scratch -- that depends on finding a way to do it that does not make Scratch significantly harder to understand -- but we're definitely planning to give it a shot over the next year or so.

And you really want to create a high-performance blocks-based programming language inspired by Scratch, go for it!  I think that could be a very fruitful research area.

  -- John

P.S. If you try this, I strongly suggest building on a language/platform that already has good cross-platform support for multimedia. Two platforms you might consider are Java and ActionScript 3. Java is close to C++ in performance. WIth the new Flash VM in Flash 9, ActionScript 3 is close to Java in performance, and it has a great vector graphics engine. The Actionscript command line developer tools are now available as a free download (called Flex); you don't need to buy Flash. Microsoft Silverlight is another possibility to consider, although not as well-established as the other two.

Last edited by johnm (2008-06-24 19:51:31)

I was wrong! The don't have an educational version as Flex (I mean, also the   Adobe® Flex™ Builder 3 Pro IDE) is COMPLETELY free for education! That is owesome!!!

Hi, i'm a new-b! in the programming world 

I've searched the Net for decades trying to find the gateway to programming - 2 days ago I stumbled across Alice and then was absolutely foored by the veritable awesomeness of Scratch !!!

In the first 3 minutes of using Scratch I was able to do what I couldn't do after 10+yrs of trying 'real-world' stuff, simply because my brain is wired as an artist / dancer.

The interface is the absolute Treasure of Scratch. I FEEL how the flow of information should flow and the blocks ARE the syntax!!! GENIUS!!  The way they look and feel and work makes profound sense and difference to my mind. For the first time in EVER I actually feel that I am programming! My natural curiousity for how things work and desire to know how to practically affect my world is finally being addressed.


IDEAS:

I think that the speed of Scratch can be looked at and its functionality expanded. This, surely can only be a good thing because it will introduce people to the mindset of a problem solver and give them more tools to work with.

PROCESSING:

I believe this is dedicated experimental Java-esque environment that runs fairly fast and is not so hard learn.  Could Scratch make use of Processing in any way?

MIDI:

I also wrote a post on future additions to Scratch, namely MIDI IN/MIDI OUT + ADSL blocks.

I think that the Java cross-platform idea is very strong, but it would also be very nice to see Scratch open up internally to interfacing with standard MIDI (e.g Ableton Live, VSTs, Keyboards etc). This will make it very appealing to a lot of 'hip-hop' culture kids and young adults who would use it to write music and control lights/animations.

EIFFEL:

Eiffel is the ground up object-oriented language that is gets very little exposure. From what I understand SmartEiffel (mini Eiffel) is open source, is very robust and designed to get the job done (design-by-contract), can be compiled into C or JAVA, and runs fast, with lots of graphical add-ons and such.

INTERACTION:

I also think that Scratch is paving the way for a new paradigm in programming. It also very Star-trek and taps into the emmersive user friendly multi-media mentality which is really just starting out. In the future I cannot see professional programmers just 'hacking' away through the digital jungle of code.

Scratch has style! If it were possible, and I think it will be in the future, I would be first in line to use its jelly-blocks to learn any other language on the planet.

.. Well done the Scratch team  MIT.. you are an inspiration.. I hope to visit one day � �

Ps. I did a MA in 3dDigtalDesign, and worked specifically with the concept of "Synaesthesia, Visual-Music and Harmonizing the Senses. It makes complete and natural sense to me that we should be able to Feel and interact with maths and logic and give this feeling expression in the 'land of the real'.

I'm very happy to hear from anyone working on the cross-sensory/intuitive interface ideas and projects.
markunya@hotmail.com

Thank u v much. mark

Eric Klopfer, Lead Designer of StarLogo, told me just now that StarLogo TNG 1.0 will be released within the next week or two. After that they will turn their attention to the release of the "blocks" with an open source license. Blocks are the grasp-and-snap interface of StarLogoTNG, similar to Scratch's but not identical. Being StarLogoTNG written in Java (at least it should, and in the blocks folder I saw several JARs), I guess it could be a good starting point to rewrite Scratch to Java.

Stay Tuned.

Last edited by s_federici (2008-06-25 12:43:19)

I don't thing StarLogoTNG exposes any Java. At least as far as I can tell. But I can try to ask to the list. Can you give me some more detail about what you were thinking of?

dbal, this is what Daniel Wendel from StarLogo TNG Team says

StarLogo TNG is programmed primarily in Java [...] but the programs are actually run in a virtual machine that is programmed in C [so] blocks do not have any kind of Java equivalent [. It] is not possible to program the [StarLogo] agents themselves using Java.

So... no natural move from StarLogo to Java.

Personally I'd go for Actionscript. While a speed increase would be nice, the real benefit from a Flash based scratch would be the ease of publishing and distribution. Flash works across a wide range of platforms (including phones) and the user experience is much simpler than Java. This is why youtube and most web games use Flash. An added bonus would be the built in vector engine and bitmap smoothing which would avoid the "squashed bitmap" look a lot of Scratch projects have.
Adobe has been showing an internal demo of an automatic C++ to Actionscript convertor which if they release it would make it possible to port the Squeak VM straight to actionscript:
More details here: http://www.onflex.org/ted/2008/02/extending-adobe-flash-player-and-adobe.php

(BTW I don't work for Adobe but I do think there's an opportunity for Scratch to become a truly mass market tool for media creation)

For Flash, you need to separate the tools from the language (AS3), although the tools are clearly a reflection of language/platform aspects. 

You can program in Flash/AS3 in a very 'Java Like' manner -- using either the free SDK of the not-free (but quite good) Flex Builder environment within Eclipse.  When using this kind of tools, you have source files that look Java-ish and compile them into an executable.  There are lots of examples on the web, but I will just point here:
   * http://chimu.wordpress.com/2008/09/02/a-taste-of-flex-part-6/
as an example since I have a Scratch project that does the same thing:
   * http://chimu.wordpress.com/2008/09/08/a-taste-of-scratch/
so people can compare them if they are interested.  Note you don't have to use the 'Flex' extensions to program this way for Flash -- Flex is basically just a library to Flash and the core concepts (AS3 and the player) are the same.

You can also "program" Flash in Flash CS3.  Flash CS3 used to be called Director, which is a much more informative name.  "Director" is not at all like programming in Java or other languages.  But "Director" is designed for "Movie Makers" with the programming capabilities being secondary -- and it appears it makes a lot of sense to "Movie Makers" because it is highly successful.  You draw and animate in Director as the primary activity and you program if you really need to.  Flash CS3 is both somewhat expensive and also totally proprietary -- the source files are unreadable to non-CS3 tools [AFAIK]. 

So given your interests, I would recommend going the SDK route and work with Flash/AS3 directly in a very Java-like environment.

Now it is also true that Flash/AS3 has a particular execution model that affects how programs have to be written.  But that programming model is very similar to Scratch in certain ways: (1) Programs are written to respond to events as the only way anything happens (2) Programs are single threaded and have to yield so other work can get done.  Scratch basically has both of these rules as well (plus some more like yielding within loops and not having method calls) so the migration for a new programmer might be more straightforward than going to a non-event-based and multi-threaded language like Java.