Scratch

kiwi29 wrote:

Should we start on Scratch, with BYOB in our back pocket if we need more headroom  -or am I short-changing  BYOB's ability to scale-down? Is BYOB4/Snap likely to be an option in Feb 2013?

I've spent some time with middle schoolers recently and I just threw everything at them at once.  BYOB was especially valuable for the overly-precocious-impertinent-young-man[*] who wanted to know why I wasn't teaching them Java.  But the one thing we can't offer kids is the ability to upload projects to the huge audience of the Scratch web site!  That matters a lot for kids.

I think Snap! is an option right now!  It's already way faster and way more reliable than BYOB3.  The handful of still-missing features are coming quickly.

What is the status of Scratch 2 (are they really going to hang-tough on flash or will they cave in the face of slavering iPad fans and do html5?  More importantly, how limiting is 'procedures, but only in stack blocks').

The Scratch Team have no ideological bias in favor of Flash; quite the opposite.  They went with Flash because of a handful of things HTML5 doesn't quite do yet, most notably playing MIDI music and providing access to the computer's camera.  When/if those problems are solved, I imagine they'll switch eventually.

As of the last Scratch conference in May, John Maloney has promised that custom reporter blocks will be in a (not too much) later version.  He's starting to favor first class lists, too.  It's really just first class procedures that aren't likely to show up in Scratch.

Oh and, if you do that two president thing  -could perhaps us non-us citizens get to vote for the 'president of the world' position?

That's a great idea!  Given the power of the US, the whole world ought to be allowed to vote for the President as it is, and henley's idea would make the point that much clearer, while still allowing isolationists to maintain US-only voting for the local part of the job.

[*] Hoping not to get in trouble again, and realizing that y'all don't know the people involved, let me hasten to explain that I love Josh very much, and enjoy being with him, and he himself takes pride in being an overly-precocious-impertinent-young-man.  So, no disrespect intended.

@P2S: How's that? 

Last edited by bharvey (2012-11-24 13:36:55)

DigiTechs wrote:

bharvey wrote:

Grr, it's 1:33pm and I haven't had breakfast yet and it's all you guys' fault.

Lol. Atleast you're not me, and you have to goto school at 8:00AM to 3:00PM - I have NO time to do the stuff I'd like to do. But I usually don't have breakfast... So yeaah.

At least you aren't me, and have to get up at 6:00 to get ready for school which is a 45 minute drive, which is from 7:00 to 3:00 and openly has a minimum homework amount of two and a half hours.





Oh, and bharvey, all apologies are accepted.

Last edited by henley (2012-11-23 19:04:29)

bharvey you are Great. I've the impression to become more intelligent each time I read you.!
I am -slighty -over my 70 years and it's a great pleasure to see my grandson,13 years, playing with Snap! rather tnan losing its time and intelligence with stupid activities ! Snap! "nourishes" his creativy as well as his education in good CS practices. Which is not the case IMHO for Scratch.

xly wrote:

bharvey you are Great. I've the impression to become more intelligent each time I read you.!
I am -slighty -over my 70 years and it's a great pleasure to see my grandson,13 years, playing with Snap! rather tnan losing its time and intelligence with stupid activities ! Snap! "nourishes" his creativy as well as his education in good CS practices. Which is not the case IMHO for Scratch.

To be honest, to an experienced programmer, programming in Scratch is a bit of a challenge. Take my dad for instance. Having grown up with boring old languages, he really doesn't get how simple Scratch is! I had to explain how sprites worked, how forever loops didn't crash the program, etc. I think programming in Scratch has many merits, the biggest being a good platform to let out some creativity.

joefarebrother wrote:

Hardmath123 wrote:

xly wrote:

bharvey you are Great. I've the impression to become more intelligent each time I read you.!
I am -slighty -over my 70 years and it's a great pleasure to see my grandson,13 years, playing with Snap! rather tnan losing its time and intelligence with stupid activities ! Snap! "nourishes" his creativy as well as his education in good CS practices. Which is not the case IMHO for Scratch.

To be honest, to an experienced programmer, programming in Scratch is a bit of a challenge. Take my dad for instance. Having grown up with boring old languages, he really doesn't get how simple Scratch is! I had to explain how sprites worked, how forever loops didn't crash the program, etc. I think programming in Scratch has many merits, the biggest being a good platform to let out some creativity.

It can be quite a challenge as only numbers and strings are first class and there's no procedures that most languages have, so you have to work around these things.

Not to mention rather slow speeds and only 1-D lists.

Hardmath123 wrote:

Out of curiosity, why aren't you using JSON for the file format? The ST is using it in Scratch 2.0, and it's actually quite cool looking. Not to mention it's much smaller and easier to parse/dump with JavaScript than XML, though XML is probably (minutely) more portable.

Interestingly, the Scratch 2.0 file format is much, well, cleaner than the XML produced by Snap! — probably because of not being buried in <block>s.

P.S. Somehow can you make Google avoid making the search result for Snap! be "Your browser doesn't support canvas"? It's not too flattering. 

maybe there could be an image that says "your browser doesn't support canvas"? That way google can't read it.

xly wrote:

bharvey you are Great. I've the impression to become more intelligent each time I read you.!

Thanks!  That makes up a little for putting my foot in my mouth with henley. 

But...

as well as his education in good CS practices. Which is not the case IMHO for Scratch.

I squirm when I see this.  "Good practices" makes it all sound like skool.  I'd say that providing named procedures makes it easier to express your ideas by letting you expand the vocabulary in which you express them, and of course it opens up the world of fractals by enabling recursion.  But nobody should have a sense of duty about it!

Scratch deliberately left out file I/O blocks so that, even in a world full of malware, there's no way you can do any real harm with a program you write in Scratch, no matter how buggy.  That's liberating!

The big problem in early CS education isn't that kids are learning bad habits.  The big problem is that kids aren't choosing to learn CS at all, especially (in the US, anyway) female and minority kids.  Used to be that was true for technical subjects in general, but over the last decade the number of kids taking advanced placement courses in math, physics, chem, bio, even (the deadly dull imho) statistics, have all been growing exponentially, while the CS AP population has gone slightly down.  We (the Snap! gang) are part of a big NSF effort to turn that around by developing CS classes that make the connection between programming, which everything thinks is only for nerds, and all the things that kids love about computers: games, social networking, web search, etc.

The last thing we need is an army of teachers with rulers standing ready to whap kids' wrists if they don't put in comments documenting their pre- and post-conditions.  The minority who decide to become professional programmers will get that all too soon in college.

There. now I've put my foot in my mouth with you, too.

(EDIT: But at least you're an adult.)

Last edited by bharvey (2012-11-24 11:47:07)

Hardmath123 wrote:

Out of curiosity, why aren't you using JSON for the file format?

Oh, dear, we went back and forth on this (in the sense of rewriting code, not just thinking about it) twice already.  If I had my druthers, we'd serialize into Scheme code!  But if I can't have that, then I have no strong opinion between JSON and XML, I guess.  You can argue this one with Jens and nXIII.

joefarebrother wrote:

It can be quite a challenge as only numbers and strings are first class and there's no procedures that most languages have, so you have to work around these things.

To be fair, BROADCAST AND WAIT serves some of the purposes of procedures in organizing code, using the broadcast name as a quasi-procedure-name.  I'm with you on the first class stuff, though.  (And, yeah, BROADCAST AND WAIT doesn't allow for inputs or reporting.  But Scratch 2.0 will have custom command blocks.)

Hardmath123 wrote:

Not to mention rather slow speeds and only 1-D lists.

To be fair, Scratch 2.0 will be quite fast.  I'm with you on the lists, though.

Last edited by bharvey (2012-11-24 12:33:24)

bharvey wrote:

Hardmath123 wrote:

Out of curiosity, why aren't you using JSON for the file format?

Oh, dear, we went back and forth on this (in the sense of rewriting code, not just thinking about it) twice already.  If I had my druthers, we'd serialize into Scheme code!  But if I can't have that, then I have no strong opinion between JSON and XML, I guess.  You can argue this one with Jens and nXIII.

I think I already asked this a few pages back...    Jens said XML's nice because of attributes, iirc.

Ah, here it is!

Hardmath123 wrote:

How about the fact that Scratch 2.0 is in JSON? Not only does it mean someone probably thought it through at MIT, is also means we can compile 2.0 to Snap! (and maybe vice-versa in a future Scratch release).

Last edited by blob8108 (2012-11-24 13:12:55)

bharvey wrote:

The Scratch Team went with Flash because of a handful of things HTML5 doesn't quite do yet, most notably playing MIDI music and providing access to the computer's camera.

The strange thing to me is that most people don't realize JavaScript CAN do those things. MIDI and Webcam (well technically, this plugin utilizes Flash, but...). People have invested a lot into JavaScript, and its capabilities are equal to that of nearly every programming language I know.

Jens, I know you like writing things from scratch, but those are two very well documented plugins that do all of the dirty work for you. 

EDIT: Minor usability suggestion for Snap! After an initial click on a menu button (like the settings gear), a second click on the button should close it.

Last edited by shadow_7283 (2012-11-24 15:42:12)

I'm making a native Mac OS X binding for Snap!, called Sn (get it?). It allows you to run Snap! offline in chromeless windows, and automatically updates its local version of Snap! when you have an internet connection. It also adds a bunch of features which help Snap! integrate with the OS X platform, including:

– Native context menus
– System open/save panels
– Autosave
– Versions
– Document windows
– Fullscreen support
– UTI declarations & document icons
– Native menubar integration
– Fullscreen presentation mode
– Native project notes editor

It's still in its early stages of development, and is missing a couple of key features (e.g. undo/redo and preferences), but if you try it out now you can catch all the bugs  . You download it here (application + source — about 1.2MB) or here (just the application — about 350KB).

Last edited by nXIII (2012-11-25 11:45:11)