Scratch

nXIII wrote:

Hardmath123 wrote:

Would you change it if I wrote a Morphic local virtual keyboard for you? I think it won't be too hard, I can do it. 

I already did that.

So how come we still have the glitchy local keyboard? Jens, didn't you specifically want to escape local device-specific stuff? 

Jens wrote:

more like Catroid

Is that the result of App Inventor?

shadow_7283 wrote:

Is that the result of App Inventor?

No, Catroid is an independent project.  In App Inventor you do the actual programming on your computer, not directly on your phone.  The research goal of Catroid is to find ways around the severe lack of room on a phone screen.

shadow_7283 wrote:

I read something a while back that the App Inventor project at Google had been discontinued and passed on to researchers at MIT for further development. I thought this might have been what it turned into.

It's true that App Inventor moved to MIT (although that's a little misleading because Hal Abelson, an MIT professor, started App Inventor while on sabbatical at Google), but it's still App Inventor.

Catroid is developed at the Institute for Software Technology at Graz University of Technology in Austria.

P.S.  Nothing to do with this message, really, but Adobe CS6 finished downloading in the middle of the night, and I started the installer at 8:30 this morning, and it jumped up to 13% done right away and has been sitting at 13% done for four hours.  The estimated number of minutes to completion keeps growing; right now it's at 2231.  I hate Adobe.

Last edited by bharvey (2013-01-03 15:52:12)

What logging in do right now?

shadow_7283 wrote:

www.catroid.org wrote:

developed by the Lifelong Kindergarten Group at the MIT Media Lab

[/offtopic]

www.catroid.org wrote:

Catroid is a visual programming language for Android devices that is inspired by the Scratch programming language for PCs, developed by the Lifelong Kindergarten Group at the MIT Media Lab.

The subject of "developed" in that sentence is Scratch!  If you click on the "Imprint" link at the bottom of the catroid.org site, you'll find the sentence I quoted.

Haven't you learned yet, Jack, that I'm never wrong?   

Digimath wrote:

an explanation of the intended audience

Good idea.  I added "These added capabilities make it suitable for a serious introduction to computer science for high school or college students." to the first paragraph.

The audience for the manual is a tricky question.  Clearly not eight-year-olds, but maybe people who haven't used Scratch (hence Chapter 0) but also maybe computer science professors!  Ideally we'd have a wider range of documentation with more specific targets.  We do have the Berkeley course materials, which are way more detailed of course.  It's called a reference manual because you look things up in it, but I couldn't avoid some tutorial parts about things like continuations that nobody outside the programming languages research community has heard of.

bharvey wrote:

Haven't you learned yet, Jack, that I'm never wrong?   

Schooled in Computer Science, English, Math, Politics... I should know better. 

EDIT: Having difficulty reproducing the Baskerville issue. Adobe Reader, Chrome's PDF viewer, and the built in Win 8 app all display it correctly (probably because its included in Windows). What operating system are you on Roijac?

Last edited by shadow_7283 (2013-01-05 11:24:25)

joefarebrother wrote:

Suggestion: A way to the user to provide their own block colors (and maybe even categories) for user-created data structures.

I dunno.  There are only so many distinguishable colors, and we cut that space in half with zebra coloring.  I could imagine adding one or two colors that could be user-definable (in addition to the existing grey).

Also when we get first class pictures, a way to change the picture displayed in variable watchers/speech balloons for user created data structures.

I've always wanted this (see the original BYOB3 propaganda movie).  It doesn't depend on first class pictures; the representation would be a procedure that, when called with the datum, draws its representation.  My canonical use case is exact rationals, which would be represented internally as a list of two integers p and q, and would be drawn as a text string, p/q.

But of course this feature could be the poster boy for things that Jens doesn't want to hear about right now. 

joefarebrother wrote:

OK, but what if it drew outside of the boundary in which it should be displayed?

If you think about how values are displayed now, you'll see that it's the other way around; the object draws itself and the surrounding boundary figures out how big to be in response to that.

I guess the way I'd implement it is to have an invisible stage on which the object could draw itself, then find the convex hull of what it draws and work with that to transfer the picture to the visible stage.

Also, what would you do if you wanted a display which, like lists, is scrollable and resizeable.

In principle this could be done by having the drawing procedure clone scrollbar sprites and resize-corner sprites that have "when I am clicked" scripts, and use those along with sprite nesting [and, by the way, you can see how committed Jens is to not adding any more features to 4.0 by the fact that he's refrained from working on this, his favorite BYOB feature  ] to make "active" pictures.

But a more plausible solution would be for the object to draw itself in its entirety on the (infinite size) invisible stage, and separately provide scrolling hints such as the minimum size etc.

Or else we'd be forced to invent a "lightweight" sprite that has a picture and one "when clicked" script and nothing else, probably, to make it efficient.

But, you know, I think users are more likely to want simply to be able to nest an actual list in the object's picture, and let the list worry about the scrolling stuff.

Another thing: we need a block to write text with the pen.

I'm not sure what you mean by "with the pen" but we for sure need a way to write text onto the stage that's better than stamping sprites like a typewriter.  My guess is that we'll end up inventing a "text box" object, or perhaps a text box "smart costume" for a sprite, so that the text box can be clickable and movable, etc.

bharvey wrote:

Another thing: we need a block to write text with the pen.

I'm not sure what you mean by "with the pen"

I mean a pen block that writes text on the stage at a given x and y position. Of course, you can do this yourself like this but it would be quicker, easier and neater to have a primitive to do it in "real" fonts.

shadow_7283 wrote:

Embedding fonts into Snap! to ensure compatibility would quickly make it bloated.
I honestly don't mind writing my own text printing, as long as Snap! has the speed to support it.

Ah, no, there has to be text support in some form eventually.  Everyone wants that, especially me.     If people get fussy about fonts, we can embed the font in their projects, and make them bloated!

@Jens & bharvey & others

I dont share the view of many Byob forumers asking for more features.
1 - Millions of different projects have already been created with the plain Scratch.
2 - Snap! already offers much more features than Scratch.
3 - And at its final stage, with OOP, it will offer still more.

Snap! is not designed to be an all-purpose programming language.
In addition the switch to Javasript will offer in a near future many possibilities of extensions, libraries, applications.
By comparison with other new programming languages, it can be considered that it takes roughly 5 years between the official "birth" of a new language and the moment when it is a full-fledged one with programmers, teachers, books writers, conferences etc Be patient !