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 the transition:

https://s1.construct.net/images/v721/refresh/features/learn-...

The above example is a mix of block based and Javascript, but it can go all the way to making games with pure Javascript in script files - we're hoping to cover the transition in education from between Scratch and other tools such as Unity. There's a big gap there.

This would be amazing. Every child want to make games, especially with a 'proper' engine like Unity (or maybe Godot, but I don't think that has as much street cred yet).

Going from either drag and drop in scratch, or very basic python to using a full game engine requires a lot, but if that can be crossed then I think there is a very clear motivation for students to start learning in the first place.

As our engine Construct 3 is written in HTML5 itself, Javascript was the natural language choice to integrate with our block system.

All languages have their up and downsides but we love Javascript and think it's suitable because it's used in many industries (not just making games) and is likely to have a growing demand going forwards. I think this is a much easier sell to education than other tools such as Gamemaker who use their own propitiatory language.

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 escape by learning something else, but still.

I guess it would take studies to compare the outcome of various languages and curriculi? A lot of apps and games nowadays are data driven, to optimize for onboarding, engagement and so on. I would like to see more of that in education.

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.

Python and Javascript do that, to an extend. You don't see the types in the code, and 99% of the time it's ok to have a vague notion of what value is what type. Especially for limited domains. Of course TypeScript can be used without any annotation or checking. But strict TypeScript, Dart, C# and Java are impossible to use without a lot of head space devoted to the formal type system.

I consider myself an experienced programmer, but TypeScript gives me headaches sometimes, especially if I try to be explicit about type annotations.

https://snap.berkeley.edu

With the above, and with Scratch 3.0 finally ditching Flash, I think the absolute-beginner-basic-concepts niche is covered. BlockLike is an attempt to imagine what the next step in a progression could be.

[1] https://www.microsoft.com/en-us/makecode

[2] https://developers.google.com/blockly

https://gpblocks.org/

For more background information about GP Blocks from the team that brought Smalltalk, Squeak, Etoys, Scratch 2.0 and Snap! read the following paper:

http://www.vpri.org/pdf/tr2015003_modsys.pdf

"this" is me, the BlockLike Sheep (friend of Scratch Cat).

There is a lot of discussion about the more technical details of the implementation in the FAQ (https://www.blocklike.org/faq) and you can look at this example (https://www.blocklike.org/example/10-patterns/functions.html) to see what emerges out of the implementation (code prints out to console)

>I've written a lot of JavaScript code that doesn't use it and it's really easy to understand.

In the example below the concept of a function that can be shared by two Sprites is introduced. (Scratch Blocks can not be shared by two Sprites).

https://codepen.io/BlockLike/pen/JpjVOp?editors=1010

It can be rewritten without using "this" (obviously). But can you make it easier to understand? Can you make it better at explaining the concept it does?

There is a reason JavaScript has "this" and I think this might be the reason ;)

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);

  addSpriteToStage(sprite, stage);

> 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);
    });

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

  sprite.addTo(stage);
  stage.addSprite(sprite);

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... ;)

Right. I guess that's the core of my problem. I don't think you should be teaching beginning programmers OOP. It pollutes their minds too early and they don't appreciate the separation of data and code. And yes, I am biased because I dislike OOP.

Though as I recall a lot of the really advanced and customized Starcraft maps actually used, I believe, some kind of overflow bug to add all kinds of arbitrary data that you couldn't normally. Off topic now, but interesting fact nonetheless, when Blizzard remastered Starcraft they essentially re-implemented the bug so old maps would still work.

I also think that typing the words out has an effect on fluency even though it seems like a menial form of practice.

https://github.com/ycatch/blockp5.js

It feels similar to how Khan Academy do their intro to JS which in turn is very like Processing.js and other Canvas based libs. This gives it a clear progression path which is an advantage.

BlockLike has a slightly different feel/direction mainly because it is DOM based. You can dive into CSS with it for example.

Generally, with JS, one should learn early that for every simple task there are multiple libs ;)

the first block programming tool i used is etoys.

it has an interesting feature, where each piece of blocks has a direct equivalent in smalltalk, so you can compare the block version with the code version.

the transition is therefore much smoother as you can reuse your existing block code.

in that vein it would be nice if blocklike had an import function to load scratch projects.

at least for simpler projects this should be possible, and it would further enhance the transition.

I actually played with a basic React app to do that and I scraped it for two reasons:

1) Practically Scratch projects are very visual beyond the code. They contain a whole lot of assets. After conversion, just the asset loading parts of the code looks scary. It is not really workable. (As a side note, Scratch IDE encourages duplication, and this also increases the complexity of the converted code).

2) Conceptually. The idea is to learn how to write code. So, use the exact pattern, but write it yourself...