Scratch

bharvey wrote:

IS THERE A POSSIBILITY OF A DELETE OPTION IN THE BLOCK CONTEXT MENU?

Are we still talking about variable blobs?  Or are you asking about undefining a custom block?  Or do you want to delete primitive blocks?  (And if the last of these, why do you want it?)

Sorry if in my blind rage I did not really explain what I meant. Basically I want to be able to right-click a block in a command stack and simply remove it from the stack.

say "Hello"
move 10 steps
draw a sand castle

So I could right-click "move 10 steps" and make it disappear without any dragging.

Wow. I never knew that...

It'd still be nice to have an option for it, though.

bharvey wrote:

fullmoon wrote:

Basically I want to be able to right-click a block in a command stack and simply remove it from the stack.

You can do this (in Scratch, too) by clicking on the scissors at the top of the window and then clicking on the block you want to remove.

I think I even made a changeset which does this for the delete menu item, too.

^ I like it better now 

Cool! What are the arrows for?

nXIII wrote:

I minified it

Maybe I should change mine to ?

nXIII wrote:

bharvey wrote:

fullmoon wrote:

Basically I want to be able to right-click a block in a command stack and simply remove it from the stack.

You can do this (in Scratch, too) by clicking on the scissors at the top of the window and then clicking on the block you want to remove.

I think I even made a changeset which does this for the delete menu item, too.

You did...I think I mentioned it in my post.

bharvey wrote:

ScratchReallyROCKS wrote:

bharvey wrote:

we might just start on 4.0 written in Javascript.

Wait, what?

Well. they're moving Scratch 2.0 away from Squeak, so there's no reason we have to stick with it.  They've been talking about Flash but only because at the time they looked into it, Javascript couldn't do the job.  So we're talking about trying a Javascript-based BYOB to see how far we can get.  The S.T. is looking on with interest.  (I think they don't like proprietary languages any more than anyone else does.)

We started talking about this at the MIT Scratch conference, but have been slow getting off the starting line partly because school started for me and I barely have time to sleep.  And Jens has been busy at his work too.  But we really should start getting serious about this.  (Yes, nXIII, you'll be involved too.)

What about HTML5?

bharvey wrote:

ScratchReallyROCKS wrote:

What about HTML5?

I don't really know much about it, but people tell me it doesn't have lambda.  That would make things harder.

JS + HTML5 are used in conjunction! And yes, Javascript does have first-class functions.

Oh great! Does that mean I can stop supporting Squeak-BYOB now? 

I've been researching somewhat into this HTML5/JS business and it is my impression, just as fullmoon has mentioned, that they're two parts of the same system, JS being the programming language, and HTML being the object model. We're also in an ongoing discussion with John Maloney about this. Currently my (and John's) preference goes in the direction of re-implementing Morphic (Squeak's GUI framework) ontop of a single CANVAS element. After that, of course, I'd love to represent JS itself in a Scratch-like way, something like Elements for JS.

So it's not for lack of ideas or guidance that we haven't started yet. What we're sorely missing is time.

Last edited by Jens (2010-09-20 02:44:48)

Jens wrote:

Oh great! Does that mean I can stop supporting Squeak-BYOB now? 
...
So it's not for lack of ideas or guidance that we haven't started yet. What we're sorely missing is time.

Jens, I think you expressed the ambivalence pointedly ... I've too both suspected and hoped for something like that. A change of the underlying interpreter will both solve known problems and create new ones. That's why the apparent focus on usability issues seems to make more sense.

Please allow me throw in two fundamental questions into the discussion at this time (if I'm thereby stepping on anybody's toes, forgiveness - it's unintentional and due only to my ignorance):

- Isn't this maybe a good time for both the active advisers and the developers (and maybe users as well) to reconsider the basic assumptions behind the current state of
    A. the development process cycle (and its scope, e.g possibly as a managed community project)?
    B. user/feature targeting (e.g. targeting both advanced/college students and current teachers of beginners, that is of 'plain' Scratch)?

These questions are not meant as a critique, but are rather based on the view that this (BYOB 4) constitutes a huge task requiring a lot of (time) resources and I consider it both important that it is successful and that it is accomplished within a reasonable time-frame - say, counting from Scratch 2 beta.

Jens wrote:

I'd be interested in your take on these two issues!

Oh, Jens you got really cautious ... well, no need for that: my eldest kid just turned 18 this year, so I know how it feels having an "adult" at your hands who isn't really grown up completely. You know that after years of care the time has come to at least "change" your mode of control, including (likely) to lose some. But there are many reasons why that can also be a good thing. For one, taking a step back show you a larger picture and allows to gain fresh insights! 

So, I'd like to throw the ball back    maybe to Brian (Hi!) ... what is "your take on these two issues"?

Seriously: Obviously there are a few delicate issues involved here which I lack the information even to consider let alone to (publicly) base concrete suggestions on ...

shadow_7283 wrote:

When do we start beta testing? 

Don't hold your breath.

marc_hr wrote:

So, I'd like to throw the ball back  wink  maybe to Brian (Hi!) ... what is "your take on these two issues"?

My own preferred approach would be to start with a Scheme interpreter (or even an incremental compiler) in JS, preferably one that somebody who really knows about programming languages (i.e., not me) has implemented already, so it'll be blindingly fast and rock solid, and then build the Scratch UI on top of that.  A script would be compiled into Scheme and there'd be a way for a program to get access to its own translation.  Proper linked lists would be built in from the beginning.  Then someone who likes UI programming (i.e., Jens) would handle making it look and behave like Scratch.  Or I guess like Scratch 2.0.

Maybe we can farm out something like first class sprites to nXIII, who's already done something similar for Panther.  As for opening up the development to the world Mozilla-style, my feeling is that that's best done after the core system has been written by a small group, and we're doing this project ab initio (using Latin to avoid a possibly confusing pun).

Since the BYOB code is open source, there's nothing stopping people from posting to our Bugzilla site "here's this bug I found and the code to fix it is attached" but that hasn't happened, so I don't see a great clamor out there to join the effort.

If I make it through this week (exams in two of my courses), I should have a little more time to work on BYOB.

As for the targeted user community, I'm sticking with my story: "no floor, no ceiling."  Specifically, we want to be accessible to Scratch kids 8-15 and also meet the needs of at least beginning CS students 15-20.  In developing BYOB we've tried very hard to remain faithful to the Scratch design philosophy.  AFAIK we've violated it only in one way: BYOB can create entities that aren't visible on the stage.  (But to make up for it we've made complex data types visible in speech balloons onstage and in the scripting area.)

Staying true to Scratch ideas does suggest a limitation on accepting code contributions from users; we'd have to be sure the contributors have absorbed the Scratch view of the world.  Otherwise we'll end up with drag-and-drop Perl or something.


P.S.  Maybe instead of BYOB 4.0 the result of this project will be called Snap.  We've been talking about changing the name but it makes more sense to defer that to coincide with a new version; less confusing for people.

If Jens takes charge of Morphic and I take charge of Scheme, then we can marry the two parts in the UI.