Scratch

I would say "No, not until the stable release", but ultimately it's Lucario621's decision.

XenoK wrote:

since everyone is talking about snap now, shouldn't this be renamed to snap discussion thread?

We're going to start a new thread as of the first official release, which is planned for June 1.  The idea is that people new to the topic should join in at that point, and don't have to read the whole backstory.

bharvey wrote:

roijac wrote:

OOP is what good programmers do.

Is this sarcasm, or do we have to have an argument?

Wait! And OOP is bad because...?

XenoK wrote:

roijac wrote:

Jens wrote:

... but that's what is already supposed to happen now ...

i kinda just noticed that o.o
but i suggest i you hover over it it should change, not after you dropped (if that's possible) because this is a bit hard to explore 

how'd you change the text color on the link in your signature?

lol
just [color =something][ /color]

edit: you have to put the url outside the color tag

Last edited by roijac (2012-04-20 01:00:32)

Hardmath123 wrote:

Guys... file drag 'n drop is still not working! 

EDIT: Safari, latest version, if you were curious.

Exactly the same, only I'm not sure if it's the latest version of safari, but I know it's the latest version available for Mac OS X Snow Leopard.

what i saw: weird string weird string
what i'd like to see:

the script
    wait 1 secs
    wait 1 secs

Last edited by roijac (2012-04-23 14:30:35)

roijac wrote:

what i'd like to see:

Pfui.  The domain of JOIN is text strings.  You're right that what you saw was wrong; it should have been a red halo around your JOIN block (and a good error message, as for all errors).

P.S. But you're right that you should be able to manipulate scripts somehow.  My off-the-cuff idea is that they should behave like lists, so you could ask for ITEM 3 OF a script and get the third command in it; then you could APPEND your scripts.  OTOH I'm not sure why I'm happier about overloading list blocks than about overloading text string blocks.  Maybe I'm overreacting to my hatred of languages in which + is overloaded to mean string concatenation, unless the strings happen to be full of digits. 

Last edited by bharvey (2012-04-23 16:43:40)

bharvey wrote:

roijac wrote:

what i'd like to see:

Pfui.  The domain of JOIN is text strings.  You're right that what you saw was wrong; it should have been a red halo around your JOIN block (and a good error message, as for all errors).

P.S. But you're right that you should be able to manipulate scripts somehow.  My off-the-cuff idea is that they should behave like lists, so you could ask for ITEM 3 OF a script and get the third command in it; then you could APPEND your scripts.  OTOH I'm not sure why I'm happier about overloading list blocks than about overloading text string blocks.  Maybe I'm overreacting to my hatred of languages in which + is overloaded to mean string concatenation, unless the strings happen to be full of digits. 

i've no idea what's wrong about overloading +, but this is not the case here, because join is not the + operator

btw, in lisp (ur fav language...) text and lists are handled the same way 

@taneb, if i try to open your project, it freezes. #reportingbugs

joefarebrother wrote:

roijac wrote:

i've no idea what's wrong about overloading +, but this is not the case here, because join is not the + operator

In alot of programing languages + can mean addition if both oparands are numbers or it can mean join if one is a string.

bro, im programming python 
i just dont get what's bad with doing that...

bharvey wrote:

"23" + "10" --> 33

"23" + " 10" --> "23 10"

It's just wrong to use the same operator for unrelated things.

But in Python, for example, it only adds using arithmetic, instead of concatenation, when operating specifically on number types (int, float, etc). So "23" + "10" = "2310", but 23 + 10 = 33. Is that an improvement?

PS  What if ASK AND WAIT were a reporter, instead of having a separate ANSWER block?  Would that be harder to understand?

That'd be nicer, I think; and just as understandable.

Important new change to Snap! alpha

Today's new version implements rings, a replacement for THE BLOCK and THE SCRIPT.  They are at the top of the Operators palette and look like this:



You aren't supposed to think of these as blocks, because, in addition to being in the palette, they are also the representation of a procedure-type input slot in a primitive or custom block:




Here are the problems we're trying to solve with this:  (1) Everyone hates the drop-position-sensitive treatment of blocks dropped onto procedure-type input slots, where you might or might not get a grey border added.  (2) It's confusing that there are two different notations for lambda, the green operators and the grey borders.  (3) From a teaching standpoint, it would be better to be able to teach higher order functions before teaching lambda.  (In Lisp you do this by starting with named procedures as the inputs to the HOFs, but that isn't an option in Scratch syntax.)

One possible solution would have been to drop grey borders altogether, but it's a pain in the neck having to switch to Operators to pick up a THE BLOCK block, and that solution leads to very long lines of code.  And that would make it even harder, not easier, to teach HOFs before lambda.

So, the idea is, you drop a block onto a ring, and it Does What You Mean.  To make this DWYM really be true most of the time, we have a special case:  If the thing you're dropping onto the ring is a variable, then the ring disappears.  (Almost always, when you do that, the variable's value is a procedure and it's that procedure you want as input to the HOF.)  (Jens hates this part but is humoring me.  )  If you really did want a ring around the variable, there's a "ringify" option in the context menu for the slot.

So, in summary, there's only one notation for lambda; it comes free in the context of a procedure-type input slot, or can be grabbed explicitly from the Operators palette when, say, you want to add a block to a list, or set a variable to a block.

The visual presentation is meant to be as thin as possible.  I wanted to label it in Tengwar (because it binds the formal parameters), but Jens isn't a Tolkien fan.     You're supposed to think that ringing an expression protects it from being evaluated.

Sadly, this change breaks old saved projects; sorry, xly, but Jens thinks this is the last time.

Please don't decide you hate it without playing with it for a while!  And try to imagine you haven't learned about lambda yet, and you're doing things like



The hope is that you'll barely notice the ring at all, at first, and only after you see how having a function as a value is useful do you learn the details.

Enjoy!

Ooh... I support rings on each palette. 

Hardmath123 wrote:

Why does an empty ring report itself? Also, nice touch by adding rings into run/call by default. 

RUN/CALL isn't a special case; any block (including a custom block) that has a procedure-type input will have a ring for that input.

About empty rings, the jigsaw-shaped one (the one whose inside is jigsaw-shaped, I mean) should report an empty script, which is perfectly meaningful, but what would you like the other two to report?  There's no such thing as an empty reporter block; a reporter has to report something.  I suppose they could give an error message.