Scratch

Some random thoughts...

The Alice programming language gets away with having one shape (sort of rounded-rectangley) for every command. I don't like this idea but I think that BYOB could get away with allowing reporter holes to accept either certain command blocks or command blocks in general. When you drop a command into a slot, it would simply become rounded. This way you maintain the structural niceness of having different shaped blocks but you also get to implement Array.push/pop/concat or whatnot. On the flip side, I think that IGNORE should be a default block in commands, because I am often wishing I could use a reporter as a command!

fullmoon wrote:

BYOB could get away with allowing reporter holes to accept either certain command blocks or command blocks in general. When you drop a command into a slot, it would simply become rounded.

Hmm.  It would have to be commands in general, I think, if we don't give any visual clue about which are which.  I suppose most commands could just return nil or something.  But, otoh. maybe it would be better if commands that don't have anything useful to return refused to fit into a reporter slot. People would then have to do a lot of guessing, or (gasp) read the manual, to find out which are which.

My guess is that Jens is going to reject the whole idea, because it makes learning the language harder.  What might be possible is give command blocks a "jacket" -- a reporter block with an inline command slot -- that reports an otherwise-hidden return value.  We could even have two of them to resolve nXIII's dilemma about reporting old vs. new values. 

And I guess if we did that it would make sense to have IGNORE next to it as the inverse kind of jacket.

shadow_7283 wrote:

WAIT A MOMENT! What happened to the merge BYOB and Scratch suggestion?!?!

Umm, it got officially rejected.  With thanks for our hard work and interesting ideas.  Except they are going to do some form of custom blocks.

EDIT: It'd be really hard for them to pick and choose among our features (as John once suggested) because so much depends on first class procedures -- specifically, the way we're doing cloning wouldn't quite work for them because they can't use getters to represent attributes.

Last edited by bharvey (2011-02-13 21:09:17)

bharvey wrote:

Umm, it got officially rejected.

shadow_7283 wrote:

Yeah.  I'm actually surprised they let it sit there so long before they rejected it!  For a long time it was the only one in the top ten without any official comment.

Hey, given the rejection, gang, how interested are y'all in BYOB 4 looking like Scratch 2?  I'm pretty fond of the good old Scratch 1.4 GUI.  Otoh uploading resources Scratch 2 style is even more appealing when custom blocks are among one's resources.

fullmoon wrote:

I am hoping for a more modular interface in the next version of Scratch, with resizable, movable, and detachable script/sprite/document panes that float above a canvas area with the visible stage in the center.

Yeah, I guess, especially since I want it to run on my Android phone! 

And if the sprites-as-data system in the 3.0.x versions is coming to 4.0, I think you could do some interesting things with the sprite corral that represent the sprites' prototype inheritance and parent/child relationships in a more visual way.

Coming soon!  Planned for 3.1.

Do you know how BYOB4 will do things like read and write project files and store images and sounds? What about the costume editor and sound recording functions?

Good question.  We may farm stuff like that out to you and nXIII.  (I personally am a text guy, the kind that does great in old-fashioned school, not the multimedia type; I'm always a little bemused that I've somehow gotten into the gui business.)

Well, the part about project files is more closely tied to the evaluation model.  It would make me very happy if a project were a text file, so I could debug in emacs!  At least the block and sprite part -- there are text representations for pictures and sounds but they'd make the files huge.  Hmm... didn't they solve that problem for the MIME format for email?  But anyway, the big issue isn't the detailed format of the file, but rather making sure that we handle circular structures correctly and maintain identity relations. (That is, two pointers to the same place in a project should still point to the same place after the project has been saved and then loaded, and two pointers to different places that happen to have the same value should still be separate.)  That's also a solved problem (we did it in Object Logo, for example) but that doesn't mean it's solved for us. 

Last edited by bharvey (2011-02-14 01:45:41)

nXIII wrote:

bharvey wrote:

nXIII wrote:

I would love to see the assignment operator become a reporter in BYOB

I think we could do that only if we abolished the distinction between commands and reporters altogether, or at least allowed a hybrid block type (an oval with attachment tabs!).  That would settle the argument about whether CLONE should report a value, too.

Up to now we've tried really hard to be backward compatible with Scratch, and not to do anything that would confuse a Scratch user coming to BYOB.  Changing the appearance of the SET block would, I think, be a huge break with that goal.

But since it's now official that they're never going to move in the direction of first class data, I'm open to discussion of this point as we start on 4.0 (in April).  (I mean, we can start discussing now, but nothing's going to happen as a result of the discussion until April.    )

Yep. It makes sense to allow users to ignore the return value of a function (such as CALLing a command) rather than provide them with two blocks that (should) do the same thing but have a different shape.

I would suggest that command blocks could have a subtly outlined oval shape on them when they have a return value. When they are dragged over an argument slot, the command-shape disappears and only the oval remains, indicating that the block will be inserted as a reporter. When they are dragged over a command slot, the oval will disappear and will remain hidden when the block is dropped there.

Some other blocks which I think should have return values:
- [delete (1) of (list)], [add (thing) to (list)], [insert (thing) at (1) of (list)], [replace item (1) of (list) with (thing)]: should return the value of the deleted/replaced/added item
- [set (var) to ()], [change (var) by (1)], [set (attribute) to ()], [change (attribute) by ()]: should return the new value
- [delete (object)]: should return the deleted object
- [go to front], [go back (1) layers]: should return the new layer
- [next costume], [switch to costume ()]: should return the costume number
- [turn () degrees], [point in direction ()], [point towards], [if on edge, bounce]: should return the new heading
- [go to x: () y: ()], [go to ()], [glide (1) secs to x: () y: ()]: should return something, but I don't know what

Maybe BYOB should just remove almost all stack blocks and make them reporters. Then use IGNORE (which is now an official block) to run it.

MOTION

move () steps
go to x: () y: ()
go to []
glide () secs to x: () y: ()
>>report x/y list.

turn () degrees
point in direction ()
point towards []
if on edge, bounce
>>report new direction

change x by ()
set x to ()
>>report new x pos.

change y by ()
set y to ()
>>report new y pos.

LOOKS

switch to costume []
next costume
>>report costume #

change [] effect by ()
set [] effect to ()
clear graphic effects
>>report list of effect values

change size by ()
set size to ()
>>report size

go to front
go back () layers
>>report new layer

SOUND

set instrument to ()
>>report instrument

change volume by ()
set volume to ()
>>report volume

change tempo by ()
set tempo to ()
>>report tempo

PEN

change pen color by ()
set pen color to ()
>>report pen color

change pen shade by ()
set pen shade to ()
>>report pen shade

change pen size by ()
set pen size to ()
>>report pen size

CONTROL

broadcast []
broadcast [] and wait
>>report last broadcast

SENSING

ask [] and wait
>>report answer

VARIABLES

set [] to []
change [] by ()
>>report new amount

LISTS

add [] to []
delete () of []
insert [] at () of []
replace item () of [] with []
>>report new list

So now there would be no need for these reporters:

x position
y position
direction
costume number
size
volume
tempo
answer

And since I'm sure you're wondering how to get these, just set a variable!

Last edited by scimonster (2011-02-14 03:51:20)

ProgrammingFreak wrote:

Jens wrote:

ProgrammingFreak wrote:

What is the code for the thing on a block like: [+] on it? I'm making a block that has that, but I don't have that code.

Hi ProgrammingFreak, are you asking how to add an expand/collapse toggle to a custom block in BYOB? That happens when you set the argument slot in the long form slot dialog to "Multiple inputs".

Or are you asking how to do it in Squeak, because that's hard to answer, since BYOB uses its own block formatting and rendering mechanism (e.g. for inner-block line breaks) which is quite different from Scratch's (but designed to make BYOB's block look and behave like Scratch's). But you're welcome to take what you need from the source code! 

I'm talking about the squeak code. I'd like to make a certain block that would use it. Is it possible to share?

maybe  if  could contact you somehow i could tell you my idea for a block.

Are you ready for this?



Well, neither are we, quite -- this is a custom block I made using the new experimental version's new Object-type input slot.  But it's how the official OF block will look pretty soon! 

Jens wrote:

this build sports a new object type input slot, as well as the correspondent variadic slot. It also rearranges the long form input dialog accordingly.

I had to make deep modifications to the internal command spec parser over the weekend in order to enable more slot types than there are characters in the alphabet, and I hope that this doesn't affect anything else, otherwise please tell me about it :-)

Enjoy!
--Jens

scimonster wrote:

If you added color sensing like Panther, then it could have a color insert! 

Panther's handling of colors has been an inspiration to me and we'll certainly do something along those lines (trying to cut down on the number of blocks    ) in 4.0.

For 3.1, the plan is to represent a pixel as a list of four numbers (RGBA) and to try to make invisible how that pixel is actually stored in a bitmap.

Jens wrote:

I'm not even sure if moving to JavaScript is such a good idea at all, if we're just going to port or reimplement BYOB from Squeak to JS, because - let's face it - Squeak is a lot faster than JS for graphics and incomperably more flexible and agile to develop in. IMO moving to JS can only be justified if we're going to do things differently or support kinds of activities that we can't support in Squeak, which, believe me, is a tough call.

Although it matters very little to me personally, it turns out that being able to run in a browser is important to high school teachers whose district IT people are uncooperative about installing software from untrusted (i.e., not Microsoft) sources such as the University of California.

(OTOH some districts don't even allow connecting to the Scratch site because it allows uploading and downloading.  Among other things they worry about copyright liability from all those projects in which some kid uses a ripped MP3 as the background music.  This is why the ability to support local -- inside the firewall -- sharing sites is more urgent than building a general sharing site like the Scratch one.)

Oh -- I think this implies something about the project save format: it'll be a folder with an index.html that loads an included foo.js and separate .jpg and .mp3 or whatever for the media.

@ bharvey & Jens

IMHO Byob as it is now with all its new features fills perfectly its role : support for learning/teaching the basiss of algorithmic/programming languages, be a support of creativity for kids/teens/young students, simple to use

...continue

...and pleasant to use, for all ages from 7 to 77 years. This is the basic project of Scratch , raisen at a much higher level by Brian/Jens without losing the original principles of Scratch. (Consider for example the millions of Scratch projects whereas not a single book has been edited to support this language. Compare with the hundreds of books of many hundred of pages dedicated to JS !!)

To me the applications of BYOB in its 2011 version are more limited by the creativity of Byobers rather than by its lack of technical "bells and whistles" .

OTOH there is no doubt that the team Brian/Jens is perfectly able to invent a new JS-killer "programming language", but this is a totally different story. BYOB should be finalized like it is now, in line with the Scratch spirit...And from then on, up to the 2 genial parents of BYOB 2 to start with a new adventure by inventing (not from scratch !) a new project with a totally different agenda, for example Pad-Web applications.

In the meantime I've improved my initial project at - http://www.xleroy.net/ByobTuto/New/Thumbnails.html - by using most of the new BYOB features.