Live data from Hacker News

Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

github.com

21–30 of 34 posts

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#21

I am divided on using Javascript as a first language to teach to children [Or second or first-and-a-half after Scratch] It's extremely useful, and does contain lots of good parts. But it's at times inconsistent,requires learning its quirks and may cause more frustration than other languages. I would also worry a little about pushing the students down a road of mostly frontend web development. Not that they can't esca…

I am curious - what languages do you think would be better for kids to start with?

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#24

I am divided on using Javascript as a first language to teach to children [Or second or first-and-a-half after Scratch] It's extremely useful, and does contain lots of good parts. But it's at times inconsistent,requires learning its quirks and may cause more frustration than other languages. I would also worry a little about pushing the students down a road of mostly frontend web development. Not that they can't esca…

I am curious - what languages do you think would be better for kids to start with?

I am actually not sure. Depending on the age, from those I know, I would prefer Python, but it has its own disadvantages, especially that it doesn't run (properly, yet) on mobile or web.

If I were to teach Programming to a particular age group, especially with students that aren't self-selected for interest, I would hope for a compelling and engaging experience, as free as possible from sources of frustration that aren't inevitable (js has many of those).

So in some situations some kind of special language would be best? Maybe something more similar to Basic?

Another issue is that teachers generally don't code well. Most don't have a lot of practical experience, some don't even have had relevant education. And if you teach programming to talented teachers, chances are that they discover how software development pays more for less effort.

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#25
post #20

Very interesting way of trying to bridge the gap from "blocks" to code. Part of my introduction to coding was using the Starcraft and Warcraft 3 map editors. At a base level, much of the scripting in the editor is very much block-like: choose an event, add actions, and apply conditions. It wasn't block-based programming but it was point and click nonetheless. However there were essentially "blank blocks", actions whi…

WC3 used JASS and the starcraft bug is known as EUD, theres a post about it here: https://news.ycombinator.com/item?id=16305769

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#26
This honestly seems like a big leap to ask kids to take from Scratch. I agree with some of the comments I'm seeing that the concept of "this" is a big one - but even other common JavaScript concepts such as callback functions seem like a stretch. What I wonder is why a variant of BASIC hasn't taken off. I think most Gen X and Millennial software professionals can point to early exposure to BASIC as an inspiration for their careers. The syntax of that language was meant to be for beginners - so why aren't we using it?

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#27
post #25
post #20

Very interesting way of trying to bridge the gap from "blocks" to code. Part of my introduction to coding was using the Starcraft and Warcraft 3 map editors. At a base level, much of the scripting in the editor is very much block-like: choose an event, add actions, and apply conditions. It wasn't block-based programming but it was point and click nonetheless. However there were essentially "blank blocks", actions whi…

WC3 used JASS and the starcraft bug is known as EUD, theres a post about it here: https://news.ycombinator.com/item?id=16305769

Oh awesome, thanks.

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#28

We talked to a lot of teachers, and it's a real problem going from block based programming to syntax heavy scripting - there's a chasm there which from a teaching standpoint is sometimes tricky to breach and keep students engaged with. We've gone for a different approach with Construct 3 which is so far resonating well in education, by mixing our block based programming system with Javascript itself helping to smooth…

What was the reasoning behind choosing Javascript as the language, rather than Go or something else?

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#29
post #10
post #8

It's a shame they decided to involve one of the worst parts of JavaScript and hardest to explain in all the examples: "this". I've written a lot of JavaScript code that doesn't use it and it's really easy to understand.

I agree that "this" may be hard to explain (especially, say if you find yourself interviewing at AMZN and some middle manager shouts at you over video to explain what "this" means) but in BlockLike it is, by design, pretty straight forward - "this" refers to the Sprite that invoked the function. "this" is me, the BlockLike Sheep (friend of Scratch Cat). There is a lot of discussion about the more technical details of…

> "this" refers to the Sprite that invoked the function

Sure, "this" is always what invoked the function. Why not just pass in the sprite to the function though and use the argument instead? That makes the learning more general for all languages and not javascript specific. IMO, there is no value in using "this".

I don't think OOP should be taught in the early stages of learning programming. Here is a simple example from the docs:

  let stage = new blockLike.Stage();
  let sprite = new blockLike.Sprite();
  sprite.addTo(stage);
Why are you adding a stage to a sprite instead of adding a sprite to a stage? Why does sprite have a method defined on it and why is stage the parameter? I think a more consistent way to do that would be to have a function that takes both as arguments:

  addSpriteToStage(sprite, stage);
Imagine that the person trying to learn programming is trying to come up with their own library to use. It wouldn't even occur to them to create free standing function. Instead they would have to waste time deciding which arbitrary class to put the method on.

> It can be rewritten without using "this" (obviously). But can you make it easier to understand?

Here is a simple change I would make for that example. I can't figure out how to share the codepen (I think creating an account might be the only way) so here's the code for the relevant part:

    function myFunction(sprite) {
      sprite.say('hi');
      sprite.wait(1);
      sprite.sayWait('bye', 1);
      sprite.say('')
    }

    sprite1.whenClicked(function() {
      myFunction(sprite1);
    });

    sprite2.whenClicked(function() {
      myFunction(sprite2);
    });
Unfortunately this doesn't work. I have no idea what magic that "invoke" function does, so I don't know why this doesn't work. What if you wanted the other sprite to talk when a sprite is clicked? Wouldn't you have to pass in an argument anyway. Getting a magical "this" when it happens to be the sprite that is clicked that is doing the talking seems arbitrary.

Anyway, I guess my biggest gripe is that it puts too much emphasis on OOP too early in the process of learning to program.

Re: Show HN: Blocklike.js Educational Library – So kids can level up from Scratch

#30
post #29
post #10

Earlier quoted context omitted.

I agree that "this" may be hard to explain (especially, say if you find yourself interviewing at AMZN and some middle manager shouts at you over video to explain what "this" means) but in BlockLike it is, by design, pretty straight forward - "this" refers to the Sprite that invoked the function. "this" is me, the BlockLike Sheep (friend of Scratch Cat). There is a lot of discussion about the more technical details of…

> "this" refers to the Sprite that invoked the function Sure, "this" is always what invoked the function. Why not just pass in the sprite to the function though and use the argument instead? That makes the learning more general for all languages and not javascript specific. IMO, there is no value in using "this". I don't think OOP should be taught in the early stages of learning programming. Here is a simple example…

  sprite.addTo(stage);
  stage.addSprite(sprite);
Are both ok. First is more intuitive cause everything else is of shape sprite.doThing

In Scratch the IDE does the creation/association. So the design choice here is - should a Sprite be “magically” added to Stage upon construction. I chose not to because removing a Sprite is also a thing and symmetry is important.

But those are semantics - the whole thing is indeed OOP because... Scratch is OOP.

Sprites on a stage interact.

BlockLike didn’t invent any of it, it just attempts to creat a syntax that is as similar as possible to Scratch, thus allowing kids to use the same concepts and patterns they already know as a basis upon which to acquire new ones.

So while passing sprites around is valid javascript and valid in BlockLike (your example doesn’t work only because to expect your function do do something javascript can’t do out of the box - you expect it to wait) this is not really the way to go here. The way to go is simple, the sprite that invokes is “this” and if you want a click on one sprite to have an effect on another sprite, let another sprite invoke. (For playful fun the example has been updated: https://codepen.io/BlockLike/pen/JpjVOp?editors=1010)

But, here’s the interesting thing that “emerged out of the design” and that I really like - one learns that one can pass around functions.

.say() gets a string, .wait() gets a number. whenClicked() gets a function (so does invoke()). Those are methods of the Sprite. What else is a method that gets a function? How about forEach()? and from there it’s off to the races... ;)

Post reply on HN