Scratch

DigiTechs wrote:

What happens when you click share->share this sprite when Stage is selected?

I think I crashed my BYOB while doing it.. AGH?

Well, then, I guess that means it doesn't work. 

Seriously, of course it shouldn't crash, but it's not a meaningful request and should just be rejected.  Sprites (in Scratch, too) are a defined data file format, but stages (as opposed to backgrounds) aren't.  Typically if you have scripts in the stage, they're specific to the particular project and it doesn't make sense to share them separately.

bharvey wrote:

henley wrote:

Although, FTW could always mean "For The Win", which is what I was taught it meant.

I'm assuming that's what it does mean, but that still doesn't settle whether it's meant sarcastically.  (Although on second thought, given that the election is over, and there's no way the Republicans will nominate Romney again, I guess it has to be.)

I understand the six-years-no-repeat part, but why the two presidents?  Is NAFTA, for example, domestic or foreign policy?

EDIT:  Nobody is going to understand this conversation after you two change your sigs. 

Two presidents because it is really hard for one person to be really skilled in dealing with both. It'd be better if we just had two different presidents that were voted on accordingly with the 'job' they were 'applying' for. Also, the more divided the power is, the better.

kiwi29 wrote:

-and I want a weekly snap podcast

What a great idea!  "... and come back next week as we interview Fullmoon, Hardmath123, and John Maloney."

and I want some genius to port morphic to Python

Luckily we have a genius on hand.

http://www.chirp.scratchr.org/blog/?p=30

bharvey wrote:

henley wrote:

Two presidents because it is really hard for one person to be really skilled in dealing with both. It'd be better if we just had two different presidents that were voted on accordingly with the 'job' they were 'applying' for.

That's an interesting idea.  OTOH, I would argue that skill isn't what's most important about a president.  S/he can hire skill, which is what the Cabinet and all those career employees are for.  It's policy that matters most.  For example, in your plan, if the foreign-affairs president is blowing millions of dollars a day on blowing up peasants in Afghanistan, that's going put a crimp on the ability of the domestic-affairs president to fix the schools and the health care system and so on.

Also, the more divided the power is, the better.

Yes, all else being equal, I agree with that.  Thus the bicameral legislature.  But it doesn't work out so well when judgeships go vacant because one party won't confirm the other party's nominees.

And I'm afraid that, things being how they are, in your system the most aggressive, macho candidate will win the foreign-affairs slot if he (it'll always be a "he") doesn't also have to run on his domestic policies. 

P.S.  Happy Massacre of Indigenous Peoples Day, everyone!   

Ah, but it's the people who make the system not work in your example, not the system itself.

And personally, as bad as it sounds, I don't believe we should focus on health care and schools just yet. The task at hand is the economy. Once we fix that, health care and schools will be much easier to support.

Woah.


That's not the nicest way you could have stated your point, was it? Remember who your audience is.



Who said my foreign affairs president is going to blow people up? You could just vote for the foreign affairs president who isn't going to blow things up. The majority of people probably would anyways. After all, Obama is president now, and we voted for him. Anyways, you seem pretty strongly opinionated on this subject and won't change your mind about anything no matter what anyone says. I'm not going to argue anymore. It doesn't benefit me, and arguing over the Internet with a 13 year old boy you don't know about politics probably isn't benefitting you. What are you trying to get at anyways? I can't even vote.

Last edited by henley (2012-11-23 02:29:38)

Sorry that should have read "karma ducting".  Karma ducking is my day job.

turning Snap! projects into standalone web apps is technically trivial and can be done in much the same way as BYOB projects can be turned into standalone executables. If you're interested in contributing it, go ahead! I think the real beauty lies in sharing persistent links instead of apps, but we'll just have both 

I don't see any benefit in turning blocks into type-in code. Why even bother? Blocks are a much higher abstraction at the level of a parse tree. But the real argument is that Snap (and Scratch) is a microworld with a stage, sprites, events, multi-threading, graphic effects, pens, mouse and keyboard interaction etc. How would you go about turning that into plain Scheme (or Python, C, Smalltalk, JavaScript or any other programming language)? You would need to first create a "runtime" environment that offers all of that, and then add custom objects and procedures to work with it in your "type-it-up" language. The result wouldn't look like anything your 'real' language usually looks like, it would be full of proprietary stuff that only works in your microworld or "runtime". IMO the whole idea just totally sucks and only reflects the limited mindsets of uninspired instructors. 

Again, I believe the real beauty lies in hooking up Snap! with other environments, such as other computers, 3D worlds, robots, cameras, the Cloud... (and we're working on that!)

Last edited by Jens (2012-11-23 08:18:12)

Jens wrote:

turning Snap! projects into standalone web apps is technically trivial and can be done in much the same way as BYOB projects can be turned into standalone executables. If you're interested in contributing it, go ahead!

Well, a few pages ago I wrote some code for that.Not sure if anyone has tested it yet, but here it is:

I wrote:

Code:

var projects = document.getElementsByTagName("script").filter(
                   function (script){ return script.getAttribute("type") = "text/snap"; }),
      worlds=[] 

projects.forEach(function (project){
   var  canvas = document.createElement("canvas"),
        world = new WorldMorph(canvas),
        ide = new IDE_Morph(),
        control = ide.controlBar,

        appModeButton = control.appModeButton,
        pauseButton = control.pauseButton
        flag = control.children.filter(
                  function (morph){ 
                                    return morph instanceof PushButtonMorph 
                                        && morph.action = 'runScripts';
                                  })[0],
        stop = control.children.filter(
                  function (morph){ 
                                    return morph instanceof PushButtonMorph 
                                        && morph.action = 'stopAllScripts';
                                  })[0],

        contents = project.innerHTML,
        start = contents.indexOf("!"),
        end = start ? contents.indexOf("!", start + 1) : 0,
        options = start ? contents.substring(start + 1, end).split(",") : [],
        projCode = start ? contents.substring(end + 1) : contents,

        hideEdit = options.contains("noEdit"),
        hideFlag = options.contains("noFlag"),
        hideStop = options.contains("noStop"),
        hidePause = options.contains("noPause"),
        controlBarHover = detect( options, 
                                  function (str){ return str.substring(0, 7) = "hover:" }
                                ).substring(7),

        oldHash = location.hash;
 
  project.parentNode.replaceNode(canvas, project);  

  //open project
  location.hash = "#open:" + projCode;
  ide.openIn(world);
  location.hash = oldHash;

  ide.isAppMode = true;

  //hide the buttons the user wants to hide
  if (hideEdit){
    appModeButton.hide();
  }
  if (hideFlag){
    flag.hide();
  }
  if (hideStop){
    stop.hide();
  }
  if (hidePause){
    pause.hide();
  }

  if (controlBarHover){
    var shownYPos = controlBar.topLeft().y, hiddenYPos;
    controlBar.setPosition(new Point( controlBar.topLeft().x,
                                      (shownYPos + 2) - controlBar.height()
                                    ));
    hiddenYPos = controlBar.topLeft().y;

    controlBar.fps = 12;

    controlBar.mouseEnter = function (){ 
      controlBar.step = function(){
        controlBar.setPosition(new Point( controlBar.topLeft().x, 
                                          controlBar.topLeft().y + controlBarHover
                                        ));
        if (controlBar.topLeft().y > shownYPos){
          controlBar.step = nop;
        } 
      };
    };
    
    controlBar.mouseLeave = function (){
      controlBar.step = function(){
        controlBar.setPosition(new Point( controlBar.topLeft().x, 
                                          controlBar.topLeft().y - controlBarHover
                                        ));
        if (controlBar.topLeft().y < hiddenYPos){
          controlBar.step = nop;
        } 
      };
    };
  }

  ide.runScripts

  worlds.push(world);
  
});

setInterval(loop, 1);

function loop(){
  worlds.forEach(function (world){
    world.doOneCycle();
  }
}

Syntax:

<script type = "text/snap">
!options!embedded XML or project URL
</script>

For the options, write a comma-separated list (without spaces) with 1 or more of the following options: (if there are no options, you can omit the options bit altogether: don't put in the !s)
noEdit - hides the edit button
noFlag - hides the green flag
noStop - hides the stop sign
noPause - hides the pause button
hover:### - makes the control bar slide on and off screen mouse hover, at a speed specified by ###
Don't put any whitespace between the closing ! of the options bit and the start of the URL/XML.

Untested.

Last edited by joefarebrother (2012-11-23 09:27:01)

henley wrote:

That's not the nicest way you could have stated your point, was it? Remember who your audience is.

Henley, I'm really, really sorry I upset you.  Perhaps foolishly, I didn't even think we were having an argument!  You posed this very unusual idea and I was exploring it with you.

My message was abrupt, I guess, but please remember its immediate context.  (I'm not trying to continue an argument, by the way -- I'm trying to get you to forgive me!)  I had said

bharvey wrote:

For example, in your plan, if the foreign-affairs president is blowing millions of dollars a day on blowing up peasants in Afghanistan, that's going put a crimp on the ability of the domestic-affairs president to fix the schools and the health care system and so on.

You replied that schools and health care aren't your highest domestic priorities.  And all I meant to say was that, fine, whatever your domestic priorities, the foreign-affairs president can torpedo them by spending all the money on war.

I didn't even mean that that would necessarily happen!  Just that it's not so easy to make a clean separation between foreign and domestic because there are only so many resources to go around, so someone is going to have to make a meta-decision about how to divide them among foreign and domestic goals.  This is the classic "guns or butter" problem beloved of political economists.

In retrospect I can see why you read my "fine" as dismissive of your whole idea, but all I meant by it was "schools and health were just an example, I'm not insisting on those domestic priorities."

Forgive me?

henley wrote:

What are you trying to get at anyways? I can't even vote.

I guess this didn't come across very well, but I meant the conversation to be respectful of your opinions independent of your age.  Plenty of people who are old enough to vote seem to choose based on who "looks Presidential" without thinking about issues at all.

Hardmath123 wrote:

I would also suggest Snap! -> Standalone HTML5 app, just to give new programmers a sense of power (Scratch feels kiddish because of the lack of ways to distribute it "professionally"). I can write it. 

joefarebrother wrote:

Well, a few pages ago I wrote some code for that. Not sure if anyone has tested it yet, but here it is:

Go for it, you guys!  Put an option in the File menu "export as standalone" or something.  Or one more choice in the radio-button dialog that I want for "save as."

I'm guessing you're going to have to pick a free-software standalone Javascript engine that supports Canvas, and then wrap some interface code to that engine around the Snap! code.

Anyway, make all the design decisions, make it work, send Jens a diff.

Hardmath123 wrote:

How about the reverse — Snap! to Scheme, so that you can compile to a more "real world" language (for whatever it's worth), and maybe learn some Scheme?

jens wrote:

I don't see any benefit in turning blocks into type-in code. Why even bother? Blocks are a much higher abstraction at the level of a parse tree. But the real argument is that Snap (and Scratch) is a microworld with a stage, sprites, events, multi-threading, graphic effects, pens, mouse and keyboard interaction etc. How would you go about turning that into plain Scheme (or Python, C, Smalltalk, JavaScript or any other programming language)? You would need to first create a "runtime" environment that offers all of that, and then add custom objects and procedures to work with it in your "type-it-up" language. The result wouldn't look like anything your 'real' language usually looks like, it would be full of proprietary stuff that only works in your microworld or "runtime". IMO the whole idea just totally sucks and only reflects the limited mindsets of uninspired instructors. 

This is a discussion we've had several times before.  I think it would really be useful to disentangle the political sub-discussion (which is what generates the heat) from the technical sub-discussion (which has some interesting points to it).

Starting with the technical one, there are three points I want to make.

1.  Almost always, when people try to describe a language, what they end up describing is the library associated with the language.  So, for example, describe Scratch:  Well, it has sprites with costumes, and collision detection, but it's not so good at displaying text outside of speech balloons.  Describe Java:  It's for making software that runs in web pages.  Describe Alice:  It does 3D graphics and you can use characters from The Sims.

Those things are very important in practice.  In fact, sometimes the most important things about a language have nothing to do with the language, really, at all; arguably the most important thing about Scratch is the web site with two million (or is it three yet?) projects and half a million user accounts.  And the people who decided we should teach our intro CS course using Python (instead of Scheme  ) say that what's important about Python is the vibrant community of free software projects that has developed around it.

But any library can be provided for any language.  Morphic was invented as a central component of Squeak, but we can have Morphic in Python, Morphic in Javascript, and, if we want, Morphic in Scheme.  Or COBOL.  Same with Logo's turtle graphics, now widely available in any language.  The things that are truly part of a language are its syntax and associated semantics.  Logo is dynamically scoped; Scheme is lexically scoped.   Pascal allows procedure definitions inside other procedures; C and Java don't.  Scratch provides multiple threads with lockstep scheduling rather than timeslicing.  Smalltalk uses class/instance OOP; Javascript uses prototyping OOP.

Sometimes small details of the notation turn out really important.  Algol and APL used ← as the assignment operator.  Pascal, which wanted to stick with ASCII, retained the spirit of a visibly asymmetrical assignment operator with the := digraph.  But Fortran, C, and all their progeny use = for assignment, introducing a totally unnecessary conceptual difficulty for beginning programmers.  This bad idea has become so ingrained in programming culture that some academic idiots famously "proved" that making sense of something like

x=10
y=x
x=20

before learning anything about programming predicts everything about future success studying computer science.

But more often, it's the semantics that make one language importantly different from another -- things like, to pick a random example out of the air, first class procedures.

From this point of view, Scheme and Javascript and Snap! are all very similar languages.  It's much easier to translate from one of those to another than to translate any of them into Java, which doesn't have first class procedures.  Libraries can be provided for things like graphics.

2.  Having said all that, the 400 pound gorilla of Scratch and Snap! as language designs is that the syntax takes the form of brightly colored blocks that are explicitly meant to suggest the metaphor of Lego, which is a toy for kids.  There is nothing insulting in saying so; appeal to kids was, after all, the central design goal of Scratch.  This is why people contrast our languages with "real world" languages -- nothing to do with the good or bad semantics.

I think the Scratch syntax is absolutely brilliant, not only for kid appeal, but for ease of learning even for adult beginners.  Not everyone can touch-type, and for those who can't, just the mechanics of making letters appear in a row correctly is a big obstacle to programming.  (And it doesn't help that those red squiggly lines everyone's software puts under spelling errors aren't based on a Scheme or Javascript dictionary.)  The C-shaped blocks physically enclosing the range of a loop or conditional is self-teaching in a way text notations such as braces or BEGIN/END can't match.

But, Jens, if I'm writing a really big program, I'm going to do it in Emacs.  Once you do learn to type, it's a lot faster than mouse gestures.  This is why they have keyboard shortcuts for menu items!  Harder to learn when you're getting started, but way faster once you've learned them.

This leaves open the political question, coming later, of whether and why one might want to translate between notations, as opposed to just using each in its place.

3.  I've said this before, recently, but to bring everything into one place:  Every language has an internal representation, as well as its surface representation.  In the early days each language implementor invented his/her own internal format, but pretty quickly people figured out that all languages, no matter how different on the surface, lend themselves to pretty similar internal form.  This is the form that the unwashed call "a parse tree" and the cognoscenti call "a Lisp program."      Regardless of the name used, what's meant is a recursive data structure, in which an expression is made of expressions.  This insight gave us the universal compiler, both in the form of formal BNF-based parser generators and in the form of GCC, with hand-crafted front ends for different languages but a single, highly optimized, parse tree compiler.

This is why a Snap!-to-Scheme translator isn't just easy; it's trivial, in the sense that a Snap! program already is a Scheme program inside the interpreter.  This is why Jens was so pleased when I taught him about call⁄cc -- continuations were already in the evaluator's data structures, just as they are in every implementation of every nontrivial language.

Snap!-to-Javascript is slightly harder, because Javascript's surface notation doesn't present the underlying recursive expression tree as cleanly as Scheme's notation.  But Javascript is prototype-based, is lexically scoped, and has lambda, so the semantics are compatible.

-------

Okay, on to the political issues.

1.  Let's talk for a moment about Alice, which is Scratch's main competitor as a blocks-based teaching language.  Everything about Alice's design is predicated on the fact that one of their central design goals is to help teach people Java.  The syntax of Alice mirrors the syntax of Java.  You can "look behind" every Alice script to see the exact line-for-line equivalent Java code, and you can even edit the Java and see the corresponding change in the blocks.  Alice is a set of training wheels, but you're not a real bike rider until you take the wheels off, and you're not a real programmer until you code in Java.

That's very different from Scratch's goal.  Scratch doesn't want to make you a Smalltalk programmer, although Scratch is implemented in Smalltalk.  Scratch wants to make you a Scratch programmer!

But even that misstates the case.  The Scratch Team is perfectly happy if you're more interested in drawing sprites, rather than programming as such; one of their classic success stories is MyRedNeptune, who became a Scratch superstar by drawing sprite costumes to order for other people's projects.  They routinely take heat from more advanced programmer kids for choosing Featured Projects that tell a good story with essentially no programming at all, because they want kids who work in that style to have role models too.  The goal of Scratch is to promote creativity, in whatever form, as opposed to media-consumer passivity.

Importantly, the Scratch Team don't care whether you become a professional programmer when you grow up, whereas the Alice team are explicitly in the business of Computer Science education.

2.  We Snap!pers have a foot in both camps, and that makes our needs more complicated than those of either Scratch or Alice.

Jens and I have, from the beginning, consistently and loudly expressed our view of ourselves as being in, and wanting to be in, the Scratch community.  We originally hoped that we'd talk the Scratch Team into adopting our ideas -- and, lately, we've accomplished some of that, although not as quickly as we'd like.  We are terrified that a result of our work might be to divide the Scratch community with the big kids using Snap! and the little kids in the Scratch kiddie pool; we think that would hurt both halves of the community.

And the creative community is what really matters about this whole enterprise.  Speaking just for myself now, I didn't think much of Scratch when I first saw it at the Media Lab; it was supposed to be the successor to Logo, but where were the procedures?  What kind of language doesn't let you define procedures?  What won me over was the web site, and also getting to know some Scratch kids when the S.T. made me come to the first Scratch conference.  The Internet had enabled something the pre-Internet Logo community could never manage, namely, appealing directly to kids without teachers as intermediaries.

But, having said all that, the whole point of extending Scratch with first class procedures, lists, and sprites is that we want to teach computer science too.  What happens when a kid who gets interested in programming through Scratch ages out of their 8-to-14 prime demographic, and wants to learn more?  Does the kid "move on to an adult language"?  Or does the visual metaphor still have something to offer?

We think the answer is that this picture:



really is worth at least a thousand words.  And we're doing a big research project, working with high school teachers and, indirectly, high school kids, trying to prove it.

3.  Having said that, I have to admit that so far, as far as I know, every kid who's a Snap! first-class-procedures expert is also a programmer in more than one "adult" language, and was already before BYOB came along.  So I can't say that anyone who would otherwise not have reached that level wouldn't have done it without the graphical assist.

4.  Why do people want to translate visual languages into text languages, anyway?  I think they have multiple reasons, and this is where the heated part of the discussion comes from.

To the Alice people, I believe, a text language is a "real" language, and a visual language isn't.  This is what makes Jens angry, and I think it's just wrong.  Snap!, which has lambda, is much more a "real" language than Java, which doesn't.

(That word "real" always seems to raise emotions, in every context.  I'm an adoptive parent.   When my (now 25 years old) kid refers to his birth parents as his "real" parents, it eats me up.  He doesn't say it in order to upset me, and when he was younger I tried hard not to let him know that it did upset me.  But it leads me to say, bitterly, to my adult friends, that I'm a lot more "real" than the parents who abandoned him.  Having a more neutral language like "birth parents" available makes it possible for me, in my calm moments, to appreciate that Heath wouldn't describe what happened with a word like "abandoned," and I really can see the full complexity of the situation.)

5.  On the other hand, there are perfectly good practical reasons to want to have a text form for a Snap! program.  One is the desire for standalone executable projects.  Turning a Snap! program to a Javascript program would be one way to achieve that.  Keeping the Snap! program as Snap!, and embedding the Snap! interpreter in a standalone environment, would be another way, equally good.

Another reason, which I've mentioned before, is that text is straightforwardly searchable.  The Smalltalk IDE shows how you can make a program searchable without having it as a big text file, but, sorry, Jens, I find it too hard to learn.  It's wonderful that the tools I use to search a text-based program are the same tools that I use to search any other kind of text!  Besides Emacs, consider Google!  That's a pretty important text search tool that works for code, too, if you put the code in a web page.

----------

So, to sum up, and with apologies for going on so long:  Hardmath, you're going to push Jens's buttons if you suggest that Snap! isn't "real."  And I don't think that there are any more deep computer science ideas in Scheme than there are in Snap! -- since semantically, Snap! is Scheme already.  And I don't think learning a lot of languages is particularly educative if you aren't learning new deep ideas in the process.

But I'll be very happy when we have the self-reflection tools that would enable you to write a Snap!-to-Scheme translator in Snap! itself, because I think the translator as an artifact can express deep ideas.

And we all agree that, one way or another, Snap! projects should be able to run on the airplane (i.e. not on the net).

blob8108 wrote:

I think I've done it! 

Yay!  That's terrific.

I'm not sure if using variable names makes sense, though.    What if you have two variables with the same (list) value?

Yeah, precisely.  What you have to do is create a license plate -- a unique identifier -- for the point in the list that will be reused circularly.





Note that the point of circularity may not be the head of the list!

So, finish it up and send Jens a diff!

EDIT:  Note also that the circularity can be in the cdr of a pair as well as in the car:



I was suggesting to Jens that a horizontal bar and a different-color final item slot be used for improper lists:



Note also that the length of such a list isn't well-defined.

EDIT2:  Note that improperness and circularity are independent:

Last edited by bharvey (2012-11-23 16:32:43)