Comments on: Elements - a Scratch-like Smalltalk http://www.chirp.scratchr.org/blog/?p=24 experimenting with the Scratch Source Code from MIT Fri, 10 Sep 2010 01:16:50 +0000 http://wordpress.org/?v=2.3.3 By: Jens Mönig http://www.chirp.scratchr.org/blog/?p=24#comment-2870 Jens Mönig Thu, 18 Jun 2009 21:31:53 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2870 Hi, billyedward. Thanks for your interest. Yes, I wrote Elements. The "for Scratch" package contains the Scratch Source, so you can look at the Scratch Code kind of like in itself. Hi, billyedward. Thanks for your interest. Yes, I wrote Elements. The “for Scratch” package contains the Scratch Source, so you can look at the Scratch Code kind of like in itself.

]]> By: billyedward http://www.chirp.scratchr.org/blog/?p=24#comment-2869 billyedward Thu, 18 Jun 2009 21:17:52 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2869 Hi Jens! Great piece of software. Two questions: 1) Did you help develop elements? 2) What is the difference between normal and for scratch? Thanks. Hi Jens!
Great piece of software.
Two questions:
1) Did you help develop elements?
2) What is the difference between normal and for scratch?

Thanks.

]]> By: Jens Mönig http://www.chirp.scratchr.org/blog/?p=24#comment-2735 Jens Mönig Sun, 17 May 2009 14:45:34 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2735 Thank you, Charles! Coming from one of my most admired Scratchers I feel honored. Elements is still very much a work in progress, though. Currently I'm experimenting with type inferencing to hopefully come up with better ways to access the "right" elements for each blank. Thank you, Charles! Coming from one of my most admired Scratchers I feel honored. Elements is still very much a work in progress, though. Currently I’m experimenting with type inferencing to hopefully come up with better ways to access the “right” elements for each blank.

]]> By: personwithoutaname http://www.chirp.scratchr.org/blog/?p=24#comment-2734 personwithoutaname Sun, 17 May 2009 14:32:05 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2734 can you import these into scratch? can you import these into scratch?

]]> By: Charles http://www.chirp.scratchr.org/blog/?p=24#comment-2707 Charles Fri, 15 May 2009 18:04:43 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2707 Jens, thank you! When I first used scratch, I felt it's a life changing technology, and I tried straightaway to reveal serious things it can do, but you put your finger on it exactly with this implementation. Jens, thank you!

When I first used scratch, I felt it’s a life changing technology, and I tried straightaway to reveal serious things it can do, but you put your finger on it exactly with this implementation.

]]> By: technoguyx http://www.chirp.scratchr.org/blog/?p=24#comment-2494 technoguyx Thu, 02 Apr 2009 14:25:30 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2494 Seems nice, I'll consider trying it. Although I know almost nothing about Smalltalk. :| Seems nice, I’ll consider trying it. Although I know almost nothing about Smalltalk. :|

]]> By: Mike Thompson http://www.chirp.scratchr.org/blog/?p=24#comment-2466 Mike Thompson Tue, 24 Mar 2009 03:17:18 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2466 Thanks for the suggestion and the tip that Scratch 1.4 will support blocks to control WeDo. I've looked into WeDo, but really wasn't particularly impressed with it when compared to capabilities of the NXT. My kids have zero problems building NXT robots, but struggle with programming NXT-G (it's a burden even for me). The WeDo software look like a dumbed down version of NXT-G which seems to be going in the wrong direction. Knowing that Scratch will support WeDo I'll have to look more into it again. For the last few weeks I've been creating a Scratch work-alike GUI environment, but coded in C++ (using wxWidgets for potential Win/Mac/Linux portability) rather than Smalltalk. I'm about 80% complete on the GUI elements and the results are now so close to Scratch it's a little spooky. Not being familiar with Smalltalk, I figured it was easier for me to recreate the Scratch GUI in C++ than learn a whole new programming language/environment (I'm already doing this for other aspects of the project). Also, a C/C++ codebase will potentially give me greater flexibility when integrating with the various tools I'll need to use to compile and download byte-code to the Arm on the NXT and other embedded processors I hope to target. The major issue before me is what, if any, paradigm I should present to kids for controlling robotics. With Scratch, scripting is focused around around the sprite and stage -- tangible entities with concrete properties such as position, direction, color, costume, sound, etc... With robots, concrete and easy to conceptualize entities such as the sprite and stage in Scratch are harder to come by. Imagine what Scratch becomes when one takes away the stage and sprites. The mind of a robot is a bit more abstract than multimedia elements. Perhaps motors, sound output, display and sensors are easy to conceptualize physical entities that can stand-in for sprites, but I've come to believe this isn't quite case. It seems that these entities instead are instruments to cause or sense change to the robots environment, akin to changing the position or color of a sprite or having the sprite play a sound. However, they aren't a replacement for the sprite or stage with regards to serving as an anchor point for scripts. Anyway, lots of stuff to think about. I'll be very interested to see how Scratch 1.4 integrates the WeDo motors and sensors into Scratch as it may provide some additional ideas on the direction I should take things. I would very much like to communicate with others tackling similar issues with robotics. BTW, I did download Elements and play with it, but not being familiar with Smalltalk I was a bit lost. I guess I'll have to add Squeak/Smalltalk to my list of things to learn this summer :-). Thanks for the suggestion and the tip that Scratch 1.4 will support blocks to control WeDo. I’ve looked into WeDo, but really wasn’t particularly impressed with it when compared to capabilities of the NXT. My kids have zero problems building NXT robots, but struggle with programming NXT-G (it’s a burden even for me). The WeDo software look like a dumbed down version of NXT-G which seems to be going in the wrong direction. Knowing that Scratch will support WeDo I’ll have to look more into it again.

For the last few weeks I’ve been creating a Scratch work-alike GUI environment, but coded in C++ (using wxWidgets for potential Win/Mac/Linux portability) rather than Smalltalk. I’m about 80% complete on the GUI elements and the results are now so close to Scratch it’s a little spooky. Not being familiar with Smalltalk, I figured it was easier for me to recreate the Scratch GUI in C++ than learn a whole new programming language/environment (I’m already doing this for other aspects of the project). Also, a C/C++ codebase will potentially give me greater flexibility when integrating with the various tools I’ll need to use to compile and download byte-code to the Arm on the NXT and other embedded processors I hope to target.

The major issue before me is what, if any, paradigm I should present to kids for controlling robotics. With Scratch, scripting is focused around around the sprite and stage — tangible entities with concrete properties such as position, direction, color, costume, sound, etc… With robots, concrete and easy to conceptualize entities such as the sprite and stage in Scratch are harder to come by. Imagine what Scratch becomes when one takes away the stage and sprites. The mind of a robot is a bit more abstract than multimedia elements. Perhaps motors, sound output, display and sensors are easy to conceptualize physical entities that can stand-in for sprites, but I’ve come to believe this isn’t quite case. It seems that these entities instead are instruments to cause or sense change to the robots environment, akin to changing the position or color of a sprite or having the sprite play a sound. However, they aren’t a replacement for the sprite or stage with regards to serving as an anchor point for scripts.

Anyway, lots of stuff to think about. I’ll be very interested to see how Scratch 1.4 integrates the WeDo motors and sensors into Scratch as it may provide some additional ideas on the direction I should take things. I would very much like to communicate with others tackling similar issues with robotics.

BTW, I did download Elements and play with it, but not being familiar with Smalltalk I was a bit lost. I guess I’ll have to add Squeak/Smalltalk to my list of things to learn this summer :-).

]]> By: Jens Mönig http://www.chirp.scratchr.org/blog/?p=24#comment-2463 Jens Mönig Mon, 23 Mar 2009 19:30:47 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2463 Thanks, Mike, for your enthusiasm about Scratch and Elements. You know, if you're interested in an intuitive start into robotics for your children, you might be interested in LEGO WeDo, all the more because the upcoming Scratch 1.4. Release will have new "motor blocks" supporting WeDo. Thanks, Mike, for your enthusiasm about Scratch and Elements. You know, if you’re interested in an intuitive start into robotics for your children, you might be interested in LEGO WeDo, all the more because the upcoming Scratch 1.4. Release will have new “motor blocks” supporting WeDo.

]]> By: Mike Thompson http://www.chirp.scratchr.org/blog/?p=24#comment-2462 Mike Thompson Mon, 23 Mar 2009 18:21:40 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2462 Jens, you wrote: "Few pieces of software have inspired me the way Scratch has..." I'm finding this myself as well. My inspiration comes from how easy it has been for my kids (7 and 10) to understand, play and be successful with Scratch programming. Much more so than anything else I've found for them. My interests are to take Scratch in the direction of programming robotics such as the LEGO NXT Mindstorms. Despite being such a wonderful learning tool, the current programming environments for LEGOs seem to be much more geared towards serious hobbyists with some professional software experience than kids. My dream is to combine the ease of Scratch programming with versatility and sophistication of the LEGO so that kids can successfully program their creations in minutes. Given that getting code to run on an embedded robotics device is in many ways dramatically different than multimedia on a desktop (and in some other ways similar) I'm on the lookout for inspiration on how to best successfully combine Scratch or a Scratch-like environment with robotics. Scratch certainly seems to point the right direction, but many of the details need to be fleshed out. I'll be taking a look at Elements to see if there are ideas that are applicable to the goals I have before me. Thanks for sharing this wonderful work. Jens, you wrote:

“Few pieces of software have inspired me the way Scratch has…”

I’m finding this myself as well. My inspiration comes from how easy it has been for my kids (7 and 10) to understand, play and be successful with Scratch programming. Much more so than anything else I’ve found for them.

My interests are to take Scratch in the direction of programming robotics such as the LEGO NXT Mindstorms. Despite being such a wonderful learning tool, the current programming environments for LEGOs seem to be much more geared towards serious hobbyists with some professional software experience than kids. My dream is to combine the ease of Scratch programming with versatility and sophistication of the LEGO so that kids can successfully program their creations in minutes.

Given that getting code to run on an embedded robotics device is in many ways dramatically different than multimedia on a desktop (and in some other ways similar) I’m on the lookout for inspiration on how to best successfully combine Scratch or a Scratch-like environment with robotics. Scratch certainly seems to point the right direction, but many of the details need to be fleshed out.

I’ll be taking a look at Elements to see if there are ideas that are applicable to the goals I have before me.

Thanks for sharing this wonderful work.

]]> By: Jens Mönig http://www.chirp.scratchr.org/blog/?p=24#comment-2447 Jens Mönig Mon, 09 Mar 2009 18:55:08 +0000 http://www.chirp.scratchr.org/blog/?p=24#comment-2447 It's great and encouraging that you're giving Elements a try and seem to like it! I absolutely agree with you that the current tentative prototype of Elements is not suitable for beginners, hardly so for experts. The aim of the prototype is to find out if something like a full-blown object-oriented blocks programming language is feasible at all. It came as a surprise to me that there might be less effort involved for this than I first anticipated. However, there are lots of issues on the agenda before Elements really can be used for productive programming, e.g. - type assertion (visually avoiding data-type errors) - better visualization and manipulation of class hierarchies - better (perhaps even context-sensitive) messages-palette - comments in the code - general user-interface improvements - deployment facilitation (saving/opening projects) I plan to experiment profoundly with all of these issues while publishing only the meaningful results :-) In the meantime please hang on for more detailed and documentation: It's not done yet by far! It’s great and encouraging that you’re giving Elements a try and seem to like it! I absolutely agree with you that the current tentative prototype of Elements is not suitable for beginners, hardly so for experts. The aim of the prototype is to find out if something like a full-blown object-oriented blocks programming language is feasible at all. It came as a surprise to me that there might be less effort involved for this than I first anticipated. However, there are lots of issues on the agenda before Elements really can be used for productive programming, e.g.

- type assertion (visually avoiding data-type errors)
- better visualization and manipulation of class hierarchies
- better (perhaps even context-sensitive) messages-palette
- comments in the code
- general user-interface improvements
- deployment facilitation (saving/opening projects)

I plan to experiment profoundly with all of these issues while publishing only the meaningful results :-) In the meantime please hang on for more detailed and documentation: It’s not done yet by far!

]]>