Scratch

I have a suggestion:



As the image suggests, allow multiple inputs to be visible to the caller and each "made" variable renamed much like the SCRIPT VARIABLES block

With this I can make a script list block (I think), so that would be useful.

Sidharth wrote:

As the image suggests, allow multiple inputs to be visible to the caller and each "made" variable renamed much like the SCRIPT VARIABLES block

Hmm, maybe I'm missing something, but your picture looks to me just like the bottom of our long form input dialog box.

Do you mean that if a block's prototype includes a multiple input named FOO, and the user calls the block with three inputs, you want variables FOO1, FOO2, and FOO3?

If so, it doesn't make sense to me, unless the person writing the block knows that exactly three inputs will be given, in which case there's no need for a multiple input!  Otherwise, how will the block's script know that this time it has to look for a variable FOO27 because the user gave 27 inputs?

bharvey wrote:

Sidharth wrote:

In my opinion, Smalltalk is not the perfect language for a beginner because it is not like most "mainstream" programming languages (Again, that's my opinion).

Well, I have to admit, I've tried teaching myself Smalltalk three times with only limited success, but I don't think it's because of the syntax.  I think it's because all those other languages you mentioned aren't really object-oriented, and Smalltalk is:  Everything is an object.  Integers are objects.  (And, yes, I know, in Java you can wrap a class around an integer, but you can't do arithmetic on those wrappers; you have to pull out the actual integer first.  Smalltalk integers are objects that know how to do arithmetic.)  Programs are objects.  Rectangles are objects.  The debugger is an object -- a class, acually, I guess, of which you get a new instance every time a primitive blows up.  If you've been programming in languages that are mostly traditional with an object overlay, it's hard to wrap your mind around the real thing.

But, about beginners, the reason it's called "Smalltalk" is that it was designed for kids, and the Parc people taught it to kids (middle school, mostly) quite a lot.  And "it's not like other languages" isn't, imho, a reason to reject a language -- after all, BYOB isn't much like Java or JS either!  (Although it is like Scheme, but that's not exactly mainstream either.)

But I'm not trying to push you into Smalltalk, just pointing out that there are really good reasons for its design, and you should understand that it was the source from which everyone else got the idea of OOP.

The funny thing about the Smalltalk browser is that EVERYTHING CAN BE MIDDLECLICKED! Even the scrollbars, the minimize button, etc.

The reason I'm so big on structure is that languages like JS are very similar to English speech patterns (and so is Scratch!)

if (FOOBAR == "something") {return true;} else {return false;}

The above can be easily translated into English and not lose any structure:
"IF foobar is something, then I will return true, if it is anything ELSE I will return false."

(I think!) This is the Smalltalk equivalent: (I just learned Smalltalk today, don't laugh at my bad coding    )

foobar="something" ifTrue: [^ true] ifFalse [^ false]

Would you say "foobar is something and IF that is true, then I will return true, and if it is false, I will return false."?

Yeah, yeah you can just return the value foobar == "something" in both examples, but I was using this code to illustrate the difference between the structure of JS (and many other programming languages) and Smalltalk.

Sidharth wrote:

Would you say "foobar is something and IF that is true, then I will return true, and if it is false, I will return false."?

Ah, but you see, this is part of what I mean about taking OOP seriously rather than just splicing a few OOP-like features onto a traditional language.

Basically, the syntax of traditional programming languages boils down to

VERB OBJECT

or

VERB(OBJECT)

("Object" here in the English-grammar sense, a noun phrase.  In programming language terms, a variable or expression representing some datum.)  But the entire big idea of OOP is to reverse that, so instead of locating the intelligence in the verbs (the procedures) and treating the data as passive, you put the intelligence in the data -- the objects -- and you say

OBJECT MESSAGE

where "message" takes the place of the traditional procedures/operators, but a message is just a piece of text (plus maybe some additional objects), not an algorithm; the algorithm to handle that message is inside the object.

So, first we have

object: foobar
message: = "something"

and since every object knows how to test whether some other object is equal to itself, the result of this is another object whose value is TRUE or FALSE.  Then you send that object an

iftrue:iffalse:

message.  You're right that this is backwards from English (although not backwards from German, which puts the verb at the end of the sentence; maybe that's why Jens is so brilliant at Smalltalk?).  OOP is backwards from procedural programming!  That's why it was a decade between the invention of Smalltalk and the time when anyone in the Real World had a clue what Alan Kay was talking about.  And that was by way of C++, which, like all its descendants, didn't really provide OOP but instead provided generic functions -- functions of the same name that could take inputs of different types -- which is technically more or less equivalent in power to OOP but is very, very different in its underlying metaphor.

Those other languages do let you say

object.message(inputs)

though, and that's only a little different from

object message inputs

in notation, although it's a big shift in emphasis.

bharvey wrote:

Hmm, okay, I'm trying to read your mind and haven't done so well up to now, but I think what you're after is to pass the caller's own variables into your block, but that's not how upvars ("make internal variable visible to caller") work; the scope of the variable is restricted to the block itself.

I'm sorry, but either your mind-reading skills need a little bit of polishing (not likely), or my explaining skills need a LOT of polishing (99% of cases). What I meant is for the block-maker to create a block and allow the user to have as many input variables as he/she wants, but the block can handle all of them (preferably through a loop).

Think about the "script variables" block. That has an input field that lets the user "script" n variables to use. What the block does (I think) is just create them and initialize them, but after the script ends, dump them. Basically, if both the radiobuttons "multiple inputs" and "make variables visible to caller" are checked, then you can have a script that has a loop that creates lists and initializes them, ready to be used.


As you can see, the input field can take multiple inputs, but all the program does is initialize them so the program can access the empty lists and add stuff to them because the variables are visible to the caller.

If you didn't understand this, then say so, and I'll post an even more detailed explanation 

Oh, and

bharvey wrote:

<digression>I bet you've never even seen one of the old car radios with mechanical channel select buttons interlocked so that when you pushed one, any other one that might have been pushed would pop out.</digression>

<digression>
Not a car radio, but we have a radio/cd player/casette (did I spell that right?)  player (that was bought before I was born) that has some of the play/pause/stop/record buttons interlocked into groups. I have never actually seen one installed in a car.</digression>

Last edited by Sidharth (2011-08-01 02:36:14)

I had a [far-fetched] idea. How about, next to /Scripts\/Costumes\/Sounds\, you add /Text Code\. Text code reports the javascript for all scripts present, to simplify sharing/editing.

Sidharth wrote:

As you can see, the input field can take multiple inputs, but all the program does is initialize them so the program can access the empty lists and add stuff to them because the variables are visible to the caller.

This sort of thing makes mind-reading harder.  I'm pretty sure that the first "the program" means "the block's defining script" whereas the second "the program" means "the caller of the block."  If so, I can only repeat what I said a while back: the scope of an upvar is limited to the block's defining script.  The point of having upvars is that the caller can drag the variable oval into a script that's in the C-slot of a C-shaped block, or into a block that's in a reporter-type input slot.  More simply, you can only use an upvar within the context of the block itself; upvars are unreachable from outside that block.  So even if we let the caller make bunches of upvars, those variables you're initializing couldn't be used after you finish initializing them!

If you want your variables to be usable outside of the initializer block, then you have to create them outside of the block -- either with the "Make a variable" button or with a SCRIPT VARIABLES block in a script in the main scripting area.  And then you can provide those variables, as many as you want, to the initializer block using the technique in my previous message.

P.S.  Of course we could change the semantics of upvars so that they would be added to the caller's scope rather than to the block's own scope, but I think that would be bad for two reasons: (1) it would clutter the collection of permanent variables, and (2) we already have ways to create variables outside the block's scope, whereas there isn't another mechanism to do what upvars do now.  And I think it would be a real kludge to have upvars have two different semantics depending on whether or not you also clicked multiple inputs.

bharvey wrote:

Hardmath123 wrote:

I had a [far-fetched] idea. How about, next to /Scripts\/Costumes\/Sounds\, you add /Text Code\. Text code reports the javascript for all scripts present, to simplify sharing/editing.

We definitely want to make the JS code for scripts available, maybe not until 4.1 but absolutely something we're working on.  I don't like the fourth tab, though, because if users add JS code that we can't translate back into a script (probably our compiled blocks will use only a subset of JS capabilities) we won't know what to do with it.

It's more likely that we'll have a mechanism to see the JS translation of one script or one block, and maybe edit that.  By narrowing the scope that way, if the user edits the script into something we can't handle, we can just draw a red outline around that one script, or something.

And of course down the road it'd be great if we can provide a translation of the entire program, including the support code from Snap itself,  into JS that can run on its own.

You could make a whole library in JS and a move 10 steps block could be:

scratch.motion.moveSteps(10);

A forever block:

scratch.control.forever(function () {
    scratch.motion.moveSteps(10);
});

Then the Smalltalk code can parse it and if it sees something other than scratch.* it can get mad.

EDIT: Why was "parse" bleeped? I know what it contains, but really? Watch it get bleeped again...

Last edited by Sidharth (2011-08-01 14:30:51)

bharvey wrote:

Sidharth wrote:

You could make a whole library in JS

Yes, I agree, with luck the same code that runs on our web page will be exportable to other people's programs and the translation will be simple, although, as Jens said, it won't be SCRATCH.whatever but rather SPRITE1.whatever (because, e.g., you have to know which sprite to move 10 steps).

I was just looking for a way to be able to export/import scripts in a cool way from Scratch into text. Jens made a XML patch thingy, but I couldn't get that to work  . I really didn't care whether it ran online, or even was compilable, just wanted something nifty like that 

I overlooked the idea of using the name of the sprite as the name of the object.

Do you think the idea of making c-inputs as functions themselves is a good idea? I thought it was, but maybe difficult to impliment.

Again, all I wanted was a way to import/export scripts into BYOB so that I can type them somewhere else because in my big projects (text adventures), BYOB goes ultra-slow.

Another idea:
Make a way to export lists?

LIST foo[1, LIST[1, 2, 3, 4], 4]

As of now, exporting lists that have elements that are lists doesn't work, and with my text adventures I use a HUGE list to describe the area with exits for every room. It took a few hours to type it out with Scratch's minimal list-editing design. If I could type it, it would have taken half the time...

Exporting lists that have objects as elements (sprites) would be hard...

Last edited by Sidharth (2011-08-01 15:09:49)

Well I must say, you guys (sidharth & bharvey) seem to be having a very in-depth discussion about things I barely understand, but it's interesting to read! I do learn something from it (I think)

rookwood101 wrote:

Well I must say, you guys (sidharth & bharvey) seem to be having a very in-depth discussion about things I barely understand, but it's interesting to read! I do learn something from it (I think)

Yeah, from time to time we get into these implementation ideas.  But we've also had some fairly basic questions and answers about BYOB capabilities -- taking into account the fact that none of the added capabilities beyond Scratch are entirely "basic." 

bharvey wrote:

I don't see how that's any better than starting the script in the C-slot with a SCRIPT VARIABLES block.  That seems much more straightforward to me.  I'm probably being really dense but I'd have to see a complete example to understand what you guys are getting at.

It isn't, except if you need to do more than that. For example, if one wanted to inject a value into a list to reduce it using any number of previous values, he/she could use INJECT (any) AS {value} INTO (list) USING PRECEDING {values...} (commandSlot).
Another example would be (I know I use this example too much) to keep track of the context a program is run in for debugging purposes, etc. To do this you would need to know when variables were declared, using a custom C-shaped variable declaration block VARS {vars...} (commandSlot)

Last edited by nXIII (2011-08-01 21:49:40)

bharvey wrote:

Sorry, I have no idea what this example means.  Could you give an example of the example?

It's pretty much the JS "reduce" or the Smalltalk "inject", except it gives you previous values for interpolation or something else, e.g. (curly brackets { } show variables)
INJECT <0> AS {currentValue} INTO <list of numbers> USING VALUES {a} {b} < >
    the ( {currentValue} + ( ( {a} + {b} ) / <2>) )
adds the averages of consecutive numbers in the list. (Which is completely useless but demonstrates what it does.)
(Actually, this includes a correction; it should be "USING VALUES" rather than "USING PREVIOUS".)
EDIT: An implementation for this block might be:

inject <start> as <value ^> into <list> using values <v ^ ...> <reporter>
script variables <i>
set <value> to <start>
set <i> to <0>
repeat <length of <v>> [
    change <i> by <1>
    replace item <i> of <v> with <item <1> of <list>>
]
set <i> to <0>
repeat <<length of <list>> - <length of <v>>> [
    change <i> by <1>
    delete <1> of <v>
    add <item <i> of <list>> to <v>
    set <value> to <call <reporter>>
]

No, I don't believe this one.  Surely a debugger can't depend on users giving redundant declarations of variables just for the sake of the debugger!  It would have to be done Smalltalk-style: A process is an object and inspectable (including its stack); a procedure is an object and inspectable; a procedure invocation (a stack frame) is an object and inspectable.  The debugger is given the process that faulted as its input, and unearths all the information about variables from there.

It wouldn't be redundant, e.g.
VARS {a} {b} {c} [
    SET <a> TO 1
    SET <b> TO 2
    SET <c> TO 3
    INSPECT CONTEXT
]

Last edited by nXIII (2011-08-02 15:34:46)