I've never really understood the desire to have high level programming environments for the micro:bit - blocks and such. I've nothing against those sorts of environments themselves. My son has hugely enjoyed Scratch and I think it has been educational for him. I just think it's missing out on what makes micro:bit awesome.
With a high level programming environment a Micro:bit is just a very limited, cheap bit of hardware you can do a few fun things with. There's novelty to it but it can do much less than the desktop computer you use to program it.
But the Micro:bit is an absolutely genius bit of kit for exploring low level programming!
AIUI, the Micro:bit has 2 microcontrollers on it, not one. The one you program is actually the less powerful of the two. The second microcontroller, which you can't program, is there to control the USB port, implement mass storage and feed anything you put there to the programmable microcontroller.
This means you have an extremely simple RISC chip, with extremely simple hardware (leds, beepers and stuff) attached that you can control, and you can program it in assembler or C just by copying files to USB mass storage.
I haven't started with this yet, but when he's ready I plan to explore this in detail with my son. It seems like a perfect opportunity to explore how computers actually work and how software and hardware interact, without the huge complexity of more powerful hardware.
I've run dozens of summercamp sessions and afterschool classes where we introduced Arduino to all ages - I don't see how block or frane based editing is incompatible with learning low level hardware - the C-ish code is already removed from how "computers really work", you're left with pin labels, read and write, conditionals, loops, and subroutines. There's an extraordinary variety of applications to build with these tools, game controllers, music makers, HID, sensor networks...
I took a few classes that get into the nitty gritty of registers and bitmasks, and the outcome after all that trouble was to bitbang a serial connection, I wasn't really inspired to keep digging in that direction, although now I'm trying to teach myself 6502 assembly because I am inspired by how far you can go on such ancient hardware.
anyway, most of the arduino and micro:bit code I've seen in the classroom consists of taking code someone else has written and making just a few changes. I'd say 1 in 50 of our students moved on to understanding how to write programs from scratch - if Strype lowers the barrier of entry so you don't have to learn arcane syntax or the meaning of "void", I think it will be hugely successful in lowering the cost of software development by embiggening the talent pool, making a more accessible on ramp to being productive with computers.
I think a huge power in frame-based programming, that is super under-appreciated, is how you can make errors a lot more obvious by limiting input.
Left side is a number? Right side's gotta be one too!
You can also stop `if foo = bar` style errors as well.
Of course those errors show up anyways when you run a program, right? But being shown the error in context quickly, and having UI space to be able to add links to documentation and other details is a real boon to learning in my opinion.
And you can provide autocomplete that only provides "good" options. This can help with discoverability (though it's tough to get a "why is this not showing up" answer, granted).
Imagine if our shells actually worked like this! There's reason everyone installs all of the cool bash/zsh completions for all these tools.
This looks really great, people have been exploring AST editors but I feel like this "frame" concept strikes a balanced between the structure an AST editor provides, and the need for free form text editing our normal text editors provide--I'm really interested to see how this feels in practic.
I didn't realize the "Scratch" interface was called "frame based editing" [1]. Interesting.
My experience with novice programmers is that they have the most problems with code syntax and formatting. The fact that one misplaced comma or semicolon can prevent the whole program from running is incredibly frustrating and for many, is a significant obstacle that prevents further progress. I've seen with my own eyes, 10 year olds break down crying in frustration over a missing semicolon.
But I think it's too early to "standardize" on this particular solution to the problem just yet. I feel we need a few more iterations before it is fully baked.
Millions of people around the world code every day at all levels of ability. When a better development system is devised, it'll just naturally take over and we'll see it everywhere. This isn't it yet.
Generally Scratch-like languages can be referred to as "visual" programming languages, or "block based" languages. "Frame based editors" would be this new combined approach.
I started programming around 5th or 6th grade with a language called Kids Programming Language or Phrogram it was sort of like an Actionscript-y language. When I was younger I always found it really frustrating to use Scratch and I think that using that more realistic coding environment helped me build my foundation of skills as I learned the basics of syntax, branching, booleans, loops and debugging. I think syntax errors, reading coding and structuring code are all core skills that a young programmer should learn which I think these visual languages hide.
I personally recommend teaching kids with a more realistic but visual language like Processing.js: https://p5js.org/ It allows them to stay motivated by making games or other visual projects but it provides the realistic experience of programming in a more simplified language. There's also some great books and resources to teach out of like https://p5js.org/books/ and http://learningprocessing.com/
Heh. My son is now in college so it'll probably be at least a good 10 to 20 years or so before I need to teach programming to a pre-teen again, and by then I truly hope we've worked some more things out.
It's more that in casual conversation nerds will struggle.
"Did you check out Strype? It's great for kids!" "... I don't think my kids are into payment processing yet...?" "Oh I meant the editor." "The editor...?"
"I spent the weekend debugging the damn Stripe" "Man, your kids must be keen!" "Kids? Why would I involve them? They hate me for not doing anything with them already." "Oh, so you're using Strype yourself? What for?" "what do you mean what for? What else can you use Stripe for?" "That's what I was asking, afaik it's just meant for the microbit" "The microbit? Ahh, no no, I meant the other Stripe..."
"Oh, Strype gives me an error, I'll just google for it" <autocorrect kicks in, turning Strype into stripe> "... what is all this payment crap?"
The last scenario is going to be particularly common among Stryped's target demographic. And let's not even go into the furry porn, that's going to trip a few school firewalls...
It has nothing to do with frame-based editor, that's the point. How are you supposed to convince someone to try "Strype" it even sounds the same. There is so many words and op landed on the exact same as an existing company with a y rather then i.
Might as well just call it "Gougle" or "Macrosoft" or "Yahou"
Interesting. Haven't tried it myself but looks neat.
And here my 2 cents:
I would be seriously surprised if Strype didn't have any intention of integrating some visual based machine learning algorithm to help automate coding. Actually I'm quite surprised I haven't seen any project doing that. Github copilot comes close but is text-based only. So no end-to-end software design. For that you need GUIs and thus more visual-based networks. Strype could be helping with that.
With a high level programming environment a Micro:bit is just a very limited, cheap bit of hardware you can do a few fun things with. There's novelty to it but it can do much less than the desktop computer you use to program it.
But the Micro:bit is an absolutely genius bit of kit for exploring low level programming!
AIUI, the Micro:bit has 2 microcontrollers on it, not one. The one you program is actually the less powerful of the two. The second microcontroller, which you can't program, is there to control the USB port, implement mass storage and feed anything you put there to the programmable microcontroller.
This means you have an extremely simple RISC chip, with extremely simple hardware (leds, beepers and stuff) attached that you can control, and you can program it in assembler or C just by copying files to USB mass storage.
I haven't started with this yet, but when he's ready I plan to explore this in detail with my son. It seems like a perfect opportunity to explore how computers actually work and how software and hardware interact, without the huge complexity of more powerful hardware.
I mean, this should be educational for me!
This book looks like a potential starting point (not published yet, though): https://spivey.oriel.ox.ac.uk/baremetal/Bare_Metal_micro:bit