Scratch

roijac wrote:

calling scripts without a report block still doesn't generate an error massage, instead it goes into an infinite loop 

it's not a bug in Snap, but to be expected, it's waiting for the missing return value. You can just stop the looping by either clicking on the running script or on "stop all" (or on the red stop sign once we have it).

Sidharth wrote:

Weird sprite bug:
I was messing with block specs [...]

I don't think it counts as a Snap! bug if you change the Snap! code itself in unplanned ways and something unexpected happens.   

Jens wrote:

Sidharth wrote:

Weird sprite bug:
I was messing with block specs and did that.

Block specs are not a user feature.

the Snap pre-alpha version is in developer mode, which is mainly for me to inspect and debug issues "live". You're not going to be able to fool around with the internals in the final release. Instead you're going to Build Your Own Blocks using the Block Editor.

That having said let me explain: Setting a sprite's heading expects a number resembling degrees, not a lambda (which is was c-shaped slots evaluate to). Type errors cause stuff to break. You can turn the sprite back into what it should look like by opening its inspector and by selecting "heading" in the left properties list pane, and then by overwriting "NaN" in the right value pane with a number and hitting edit... save.

well it can still happen if you put a blank ( in the () ) in [point in direction ()]

iTweak0r wrote:

well it can still happen if you put a blank ( in the () ) in [point in direction ()]

Yes.  Any reporter that doesn't report, or that reports a non-number (e.g. LIST), behaves the same way.  That does elevate it to a bug.      But not an urgent bug, compared with all the missing features that Jens is working on.  Expect lots of little bugs in the short term.

(But do keep reporting them!  You can use byobugs.com to do it.)

EDIT:  But don't bother reporting missing features, things that work in BYOB 3.1 but don't work in Snap! yet.  We know about those. 

Last edited by bharvey (2011-12-14 12:24:38)

nXIII wrote:

which is perfectly valid in Snap.

It's valid in Scratch, which is very confused about the relationship between Booleans and other data types (strings and numbers).  We should fix this, despite the fact that Javascript has a similar confusion.  We should have two atomic values True and False (which I think should be represented visually by the hexagonal reporter blocks, since if the reporter itself is used as a datum it'll have a grey border around its picture), and they should not be equal to any string nor any number.

By the way, "nil" in the Lisp literature means the empty list, the value returned by calling LIST with no input slots.  BYOB, following Smalltalk, uses it to mean no-value, as in the case of using a command script where a reporter script is needed.  I think that's something we should fix, too.  The user should never see "nil"; instead there should be a DID NOT REPORT error message.

nXIII wrote:

Wouldn't that break code written in BYOB3 or Scratch, though?

Oh, probably.  Maybe we need compatibility mode or something.

Sidharth wrote:

Was a kind of far-fetched idea, I know 

Not so far-fetched; it would work if you wrapped a CALL around it!  (In the regular unhacked block, I mean.)

joefarebrother wrote:

or it should report a blank string

I totally understand why Scratch, for its audience, tries to make it really hard to get an error message.  But for our (older, more experienced) users, I think it's a lot easier to debug an error message than to debug a mysterious wrong answer miles downstream from the actual problem.

Hey, I've missed a lot, but Snap! seems to have really advanced.    One thing though, is that the block palette scrolls slowly. That could probably be fixed if we added sections. ;D

nXIII wrote:

bharvey wrote:

joefarebrother wrote:

or it should report a blank string

I totally understand why Scratch, for its audience, tries to make it really hard to get an error message.  But for our (older, more experienced) users, I think it's a lot easier to debug an error message than to debug a mysterious wrong answer miles downstream from the actual problem.

I vote for "strict mode"

Me too.

"strict mode", come on (the website censored double-u-tee-eff here) ?! This is exactly what turns creative people off about programming, and about us nerds succumbing to being high priests of a low cult. Tech guys may be able to stomach being disciplined by a computer. Artists, writers and musicians will just walk away. It's okay for a professional optimizing compiler to throw all kinds of warnings and error messages, but it's a huge mistake for a beginners programming environment to complain to its users. Sure, you should be able to get the information you need for debugging. But given the choice between debugging and tinkering I'd opt for tinkering every time!

Last edited by Jens (2011-12-15 18:55:18)

Jens wrote:

Tech guys may be able to stomach being disciplined by a computer. Artists, writers and musicians will just walk away.

nXIII wrote:

"strict mode" would be an opt-in feature, and the environment would behave exactly as it does now unless it is enabled.

I really think these questions need a case-by-case analysis, not a one-policy-fits-all-errors approach (even if the policy is to let the user make a binary choice).

Let's take MathWizz's example about dividing by zero.  In the ancient days when I was learning to program, before anyone was thinking about user interfaces or usability, dividing by zero caused your program to crash, with a suitable error message.  The modern floating point standard's provision of "Inf" as a quasi-answer to 1/0 and "NaN" as a quasi-answer to 0/0 weren't invented to make computers feel more warm and fuzzy; they were added because the four people who actually understand floating point had a few cases in mind in which you could get a sensible final answer despite having one of these as an intermediate result.  Making sense of NaN is not a matter for poets; the math is way beyond me.  So I vote that dividing by zero should give an error message.

By contrast, I think we ought not to enforce the type declarations on custom block inputs.  I often find it useful to write a function whose actual domain or range is list-or-False, or number-or-list-of-numbers, and I would not want Snap! to have Java's straitjacket variable typing combined with the formal union-type mechanism that you need to be able to get work done in such a language.  What's more, the rare type errors I make (not that I don't make errors, just that they're more likely to be, e.g. fencepost errors) are about abstract types, which from Snap!'s point of view will still be putting a list argument into a list slot, hence uncaught.

On the third hand, I think it's peachy that Scratch/BYOB/Snap! won't let you put a command block where a reporter belongs or vice versa.  What makes this "the third hand" is that this is enforcement, but isn't precisely an error message.  You just can't drop that block into that slot.

So, in summary (how we dinosaurs say "TL;DR"), what is needed is neither a sweeping generalization nor an abdication of the choice to the user, but getting each case right, to make the best possible user experience.

Last edited by bharvey (2011-12-16 01:29:40)

Hi, Xavier.

I suspect there might be a slight misunderstanding about what it means to "declare" a variable. In "those other programming languages" (to quote Brian) like C or Java you have to declare a variable's type before you can assign anything to it. In BYOB/Snap - as in most "scripting" languages like Python, JavaScript, Smalltalk etc. - the type is a property of the data, not of the variable. The only thing that needs to be "declared" when creating a variable is its name.

Of course, not requiring variables to be bound to a specific type doesn't guard against type errors when using the variable in a context where the program expects it to be just that, a specific type. Scratch avoids type errors by silently type-casting strings to numbers and numbers to strings and by avoiding first-classness almost altogether. That's why Scratch (only) has named lists, which are really fixed-type variables, and only ever accesses lists by their name in special input slots. Personally I think that's a great decision for lowering the threshold for kids and beginners, and I do hope that our decision to abandon these special-cased list variables in favor of first-class lists doesn't put too much of a strain on our target audience.

Last edited by Jens (2011-12-16 04:37:29)