Scratch

bharvey wrote:

I don't have a good sense of the timing of Scratch 2.0, nor of the time it'll take us to develop BYOB 4.0.  (It'll be in a language I understand, so I can help this time.    )  So I don't know whether or not it'll turn out that we base our code partly on theirs or vice versa or neither.

Oh... I better brush up on my JS too! 'Course you won't need a teenager to help you with code, but it'd be nice when/if I help with testing! I keep meaning to learn it, but as I said before, I'm experiencing a lack of free-time lately.

Oh, to take over the world, of course!  In the best possible scenario, the Scratch Team see the light and put lambda in Scratch 2.0, or maybe 2.1, and I can get out of the software business altogether. 

0_0 You're brilliant at software design (from what I've seen so far)! Don't stop after BYOB! I fully expect you to take my on as an intern when you start your next software project! 

Then every high school kid in (at least) the US learns BYOB!

That'd be SO COOL! I hope it's available before I leave high-school!

But even if we never touched BYOB again (not going to happen, don't panic, shadow!)...

Thanks for the side-note. 

(Not fishing for compliments, y'all don't have to say "I agree"!  Just, my hopes for BYOB are mostly already met.)

But you deserve compliments anyway.
BYOB is great! 

What are your plans/hopes for BYOB/Scratch?

Let me chime in here... I'm still very much hoping that the Scratch Team will incorporate BYOB's core ideas of custom blocks, recursion, lambda and first-class lists into Scratch 2.0, and then we'll all be happy    but I don't have any confirmation about this. There are many, many features for BYOB on our list that I'd love to implement, but I'm currently very much involved in my professional work, and have very little time for hacks. But I do agree with Brian that we'll want to develop a 3.1 version with first-class sprites and some other tricks. I'd also love to integrate sprite composition better with the language, and - of course - I want prototypes and inheritance for sprites.

In the meantime I'm checking out various alternatives for what Brian calls BYOB 4.0, mostly JavaScript / Canvas and the Lively Kernel. I've started to write a Morphic framework for JavaScript and Canvas that I'm confident will someday let us create a multithreaded blocks-based language in a web browser. But we might just opt for the Lively Kernel or even something totally different (e.g. Scheme), we'll see...

bharvey wrote:

The current plan is to write it in Javascript, because everyone seems to want things to run in the browser (for reasons that escape me, but I'm a curmudgeon)

Why in a browser? Gee, I dunno, 'cos everybody sayz it's the cool thing to do.     

Anyway, I'd love to get the JS-Morphic framework developed to a stage where it's reasonably complete within the next weeks (or possibly months) and then go back to enhance our Squeak version for 3.1. You can be sure that we will be using (and supporting) the Squeak version for a long time before anything else (BYOB 4.0) will be ready (at the moment it's just a bunch of ideas and experiments).

bharvey wrote:

fullmoon wrote:

I've been thinking about how to represent Java/Flash-style, dot-operator OOP with blocks...

You want macros!  That is, you want something that can turn
dot operator stuff into calls to dispatch procedures, BYOB-OOP style.  A macro is a block or script that, when called, returns a block or script (respectively) that replaces the original call in its context to be re-evaluated.

Naw, I'm sure I want actual dot-operator style OOP.    Interesting story, though: I tried writing a macro evaluator for Haiku (that scripting language I'm working on) to replace access operator calls at parse time with BYOB-style global CALL commands. That is:

net Socket("localhost",42001) writeUTFBytes(theBroadcast)

becomes:

$call($call($call($native("net::","Socket"),["localhost",42001]),"writeUTFBytes"),$value_in_context("theBroadcast","selfObject"))

This was originally because I thought it would be easier. As it turns out, I found a much more elegant solution, but it was an interesting foray into the world of BYOB's OOP, which undoubtedly has a formal name that I can't recall at the moment...

fullmoon wrote:

Naw, I'm sure I want actual dot-operator style OOP.

My point is, if we had macros, the user of your language could write dot-operator OOP and it would get syntactically translated into BYOB oop.  So, the user would say

object.message(arg1,arg2)

and you'd macro-translate that to

call (call <object> with inputs <message>) with inputs <arg1> <arg2>

... except that I'm not sure what a Scratch-GUI-like notation would be for the "object.message" part.

@bharvey
Yep, I understand what the macro does, but it's not what I'm looking for. If I built a Scratch mod from the ground up, I'd just create an object primitive. This would eliminate the need for using CALL as an access operator, since scripts could then also be properties of an object returned by a function rather than just results of a lambda like in BYOB. This isn't necessarily as pure as BYOB, but it's just how I would do it. So...you wouldn't loose any lambda capabilities, but I think you'd gain in terms of convenience.

bharvey wrote:

... except that I'm not sure what a Scratch-GUI-like notation would be for the "object.message" part.

That's the the interesting part.    If I ever get time I'll create some mockups.

bharvey wrote:

fullmoon wrote:

So...you wouldn't loose any lambda capabilities, but I think you'd gain in terms of convenience.

I'll be really interested to see it.  I'm afraid you might be following in the footsteps of Java, where, yeah, you can get something technically equivalent to lambda with anonymous classes, but it's pretty hideous.  The thing I want to see you do is

http://cs.berkeley.edu/~bh/compose.bmp

Anonymous classes are the stupidest thing I have ever encountered. Ever.
In this hypothetical world I'm imagining, where I have the time and the programming skill to create something resembling BYOB, the first thing I would do would is make scripts and blocks first-class. If I, hypothetically, did create something resembling BYOB, the only noticeable change would be that instead of:

call(the script{}) with args[]
say(length of (my list))

You'd have:

[the script {}] -> call(args[])
say(my list -> length)

I think that if this imaginary, hypothetical Scratch 2.0 mod were expanded to include first-class sprites, scripts, sounds, sockets, whatever, I would prefer style the syntax this way. But there'd be nothing stopping someone from creating classes BYOB style with lambdas.

Jens wrote:

what Brian calls BYOB 4.0

Oh yeah, I'm supposed to call it Snap.  I forgot!

fullmoon wrote:

Naw, I'm sure I want actual dot-operator style OOP.

Interesting discussion!

Why wouldn't the "dot" just be an empty argument slot into which you could drop the object (or the expression that returns the object) that receives the block's expression? That's how I did it for Elements. The problem with this approach is that it doesn't avoid errors where the receiver doesn't understand the message (or, in ECMA-script-ese - where the object's property is undefined).

I guess the "Scratch" way to resolve such issues is to not allow direct inter-object messaging at all, just "sensing" in the OF block. Another way to avoid such errors would be drop-down menus with all possible messages/properties. But that would quickly clutter up everything to a point where it becomes hard to handle.

Last edited by Jens (2010-11-04 04:55:23)

Jens wrote:

Why wouldn't the "dot" just be an empty argument slot into which you could drop the object (or the expression that returns the object) that receives the block's expression?

There's no "dot" block, or anything...instead, blocks can be taken from the palette and tacked to the end of object reporters. This block here is neither a command nor a reporter...it fits in wherever you want to put it. These triangle-tipped block fragments form a statement, and at any time you can click the end of the statement to get a searchable list of properties of that object (maybe a floating blocks palette?).

This sounds ridiculous, but more mockups to come.

nXIII wrote:

Wait, from a Morphic point of view, who's the child here?

I haven't the foggiest idea. This is all assuming that Scratch 2.0 is released as Flash or JS, so I'd be able to do some decent tinkering with it.

(...of former message)

Create a variable-method distx to report x^2 (with THE BLOCK)
Same for disty
Create dist which calls the 2 methods <distx OF sprite1> and <disty OF sprite1> and takes the sqrt of their sum

Call dist with parameters xposition and yposition and you get the distance from the origin. It proves probably nothing more than you can pass "methods" to "methods"

fullmoon wrote:

Jens wrote:

Why wouldn't the "dot" just be an empty argument slot into which you could drop the object (or the expression that returns the object) that receives the block's expression?

http://i302.photobucket.com/albums/nn10 … bj-msg.png
There's no "dot" block, or anything...instead, blocks can be taken from the palette and tacked to the end of object reporters. This block here is neither a command nor a reporter...it fits in wherever you want to put it. These triangle-tipped block fragments form a statement, and at any time you can click the end of the statement to get a searchable list of properties of that object (maybe a floating blocks palette?).

This sounds ridiculous, but more mockups to come.

I like this idea. Am I the only one?

bharvey wrote:

P.S.  Hey, fullmoon, want to do the BYOB3 OOP tutorial?  I don't seem to be getting around to it.  What we need is an example with class variables, instance variables, methods with and without extra inputs, and delegation.  I mean, working up to that starting with a simple instance-variable example like counter. 

I'd be honored. I'll have to think about the best way to approach writing it, though, because as you said, BYOB is not my native OOP style. The thing I stumbled on while figuring out BYOB OOP (I just know it has a formal name...) was the idea that the variables defined by "script variables" are persistent when working with classes. I get that all the references to these variables in the class's lambdas are very tightly bound, but it's difficult to explain to someone else.