BBC Micro:bit computer now available to all for £13
engadget.com
engadget.com
Is this enough to get kids interested in computers and programming? I have the feeling that they would need something where the distance between what they can do as users and as developers is much smaller. Otherwise they still may not see it as "the same thing". The iPad will still be an opaque thing they use to consume content.
I'm coming from growing up in the 80s with a ZX Spectrum. The distance between users and developers was so much smaller - you turned on the Spectrum and landed on a BASIC interpreter. A device that "has leds" and you need to program using some IDE outside of the device fails to convey the idea that "using" and "programming" are not separate things, but different points of a continuous spectrum (pun not intended).
I'm all for demystifying programming and computers for kids. There's this false belief that kids nowadays are "so good with tech" because they're 4 and they an use an iPad, but makes kids no better at tech than using a remote control makes them good at cinematography.
Maybe what we need is more like the Spectrum Next? http://www.specnext.com
EDIT: This may be closer to what I have in mind: http://uk.kano.me/products/kano-kit
Bravo. It just makes no sense: in 1980 you could have a tiny device you could program on that device itself. In 2016, you have to use a PC with an IDE, without which it is just a brick. Where is the progress?
An interactive programming language on that phone or tablet is better.
On the other hand, this separation between using and programming is good for teaching embedded development; but the focus of that should be the surrounding tinkering: we program the device, and it fits into some context where it does something on its own as part of something else. The program isn't the whole project, and the device isn't the whole system.
It doesn't have to be either/or; an embedded device can be interactively programmable somehow.
As far as hooking up to a PC goes, there should be a dumb serial interface, which is just a way to have a better keyboard and bigger screen: but all the interaction going on within the device rather than "build image, upload, flash, reboot".
Maybe, we can load this thing up with something that will boot up into Basic, Logo, or Pascal. All the kid have to do is connect a monitor and keyboard to it.
I grew up using an Atari 800 with a cassette tape drive connected to my TV. I switched it on and have fun coding.
Yet another site that shows crap all without JS enabled...
Anyways, the Ello M2 recently popped up on my RSS reader.
https://www.crowdsupply.com/knivd/ello-2m
It seems very much in tune with the early micros.
I think (not 100% sure though, but also see other comments and https://github.com/ntoll/microrepl) it can run micropython so that means you turn it on, run something to connect to it on the client and it drops you to a REPL. Not exactly the same principle as with the ZX but pretty close.
Future versions of the device may come with 32k RAM which would be sufficient. However, until such time it’s highly unlikely MicroPython will support BLE." [1]
That's a shame. I mean, I know it can be accessed by programming the hardware directly, but for most of the kids receiving these that puts BLE out of reach, when remote sensor, remote control & mesh network type capabilities would have opened up another whole class of projects that these could have been used for.
Would another 16K of memory really have pushed the price out of range, or was this more a question of the hardware design being finalised before the software stack?
[1] http://microbit-micropython.readthedocs.io/en/latest/ble.htm...
The beauty of the BBC Micro is the stark hardware specification -- the limits are the point. That scarcity leads to different usage, different behavior, different learning patterns.
If one wants to go poking around with modern languages, multi-tier applications, color-coding IDEs, etc. there is no shortage of modern computers available.
But instead, if one wishes to learn the fundamentals of computing, and the joys of working around the limits to extract the most performance possible, I would argue the BBC Micro is a superior choice to modern systems inherently due to the low spec.
It was a mere 40 years ago that 16kbyte of RAM was a luxury item.
IIRC, Wozniak wrote Applesoft Basic interpreter in 2k for the Apple ][ ROMs. He lost the source, re-wrote it, and saved a few bytes.
Learning assembly was a necessity for the purpose of speed and efficiency (which are often inseparable). Understanding what's happening at a low level -- all the way down to the metal -- is key. Single thread. No real OS. Flat memory model, all addressable (anyone remember the fun of self-rewriting code? or direct-memory mapped graphics or I/O ?)
I've rambled enough. Hopefully I've made a point.
On the contrary, it seems you have missed my point, or at least, nothing that follows that statement directly contradicts it.
Speaking of which, you state that the BBC micro:bit (the BBC Micro was a very different computer) is good for education, which I would certainly hope, since that's what it was designed for. However suggesting that teaching assembly language to 11 year olds is a good way to encourage them to explore and engage with the platform is missing the point (of the micro:bit).
Your best chance is if someone can optimize the BLE stack to use less RAM. After all, people have written ipv6 stacks that need a fraction of that.
I imagine the main reason for going with the cheaper chip is that micropython was a pretty late entry to the list of supported coding environments, and the hardware was probably already pretty settled before the port started. Also BLE+4K of ram is probably usable in the other official (compiled) languages, and micropython does otherwise work aside from something that's a fairly advanced feature. So it would have been a tough sell increasing the cost of every board when most students and lesson plans will never use BLE and there are other languages available if they do want it/need it.
MicroPython is right out; it would almost fit Lua, but as it is it looks like your only option for independent development would be Forth.
http://www.trustedreviews.com/opinions/raspberry-pi-2-vs-bbc...
Their conclusion:
> As you can see, there really is no comparison between these two devices. If the Raspberry Pi 3 is a 'my first proper computer,' then the BBC Micro Bit teaches the raw building blocks of coding at the heart of it. It's even more fundamental.
> The Raspberry Pi 3 is a much more advanced and practically useful device, but if you or your kid is starting at the very beginning of your programming journey, the BBC Micro Bit looks hard to beat.
We definitely see the two platforms working hand in hand nicely for some interesting projects!
We're one of the launch re-sellers who are offering pre-order with shipping in late June: https://shop.pimoroni.com/products/microbit
But consider this: we have quite a lot of those "not quite computers" a.k.a. microcontrollers around us nowadays - there is one in a washing machine, several in a car, complete with a network to talk to each other [1], etc... Many are to be found in quite unexpected places: inside an SD card [2], in every PC keyboard, in a bluetooth headset, inside your phone's touchscreen controller [3], or same phone's wifi/bluetooth chip, etc..
Would it maybe be a good thing to expose kids (and adults alike) to a general idea of having deeply embedded turing-complete devices, together with giving some hands-on experience with them?
[1] https://en.wikipedia.org/wiki/CAN_bus
[2] http://www.bunniestudios.com/blog/?p=3554
[3] http://www.atmel.com/products/touchsolutions/touchscreens/
In the face of this problem the BBC and a bunch of commercial partners have effectively donated one million BBC micro:bits to every year 7 student in England and Wales. This means that there are now one million kids in the UK aged 11+ who at the very least understand that programming is a thing and with any luck have experimented with it.
My kid is only two but regardless I'm going to buy one of these now they're commercially available and see if I can get him to engage with it and me as we program it to do various things.
Again, this is a huge step forward for teaching kids to code...great news :) I'd love to hear if any other countries have launched similar strategies to get their children to understand programming.
Btw the best way to program these (if you want to do it the 'real' way) is using Yotta.
http://yottadocs.mbed.com/tutorial/tutorial.html
You can get started really quickly:
1. Install yotta
2. Start->Run Yotta
3. mkdir mything
4. cd mything
5. yt init
6. Paste some code in source/main.cpp
7. yt target bbc-microbit-gcc
8. yt install ble
9. yt build
Then find a file called mything-combined.hex in the build directory and copy it to the mBed USB drive.
It's all very command-line based and Yotta is Python/CMake-based which is quite slow and very IDE-unfriendly. But it does work well.
1. sudo apt-get install gcc-arm-none-eabi
2. make
Instead, we have this extreme tool-bloat where a tiny tiny executable is produced using python, python-setup, cmake, libffi, libssl, clang, pip and finally yotta in addition to GCC and binutils (which is really all you should need).Can someone please explain to me this new trend of in-house tools and tool-bloat?
How do you install the BLE dependencies?
How do you use apt-get on Windows?
I agree it could be easier and also agree that Python and CMake are the wrong tools for the job, but frankly apt and make would be worse.
At least they seem to have designed the module description system fairly nicely so it could potentially be rewritten with a better architecture in future.
Also, apt-get works just fine on Windows 10 nowadays :)
edit: For the record, there is nothing wrong with a new tool system. But adding layers of layers of complexity and dependencies to something simple just because you couldn't care to learn to do things the standard way only creates problems for you and your users.
Make > Yotta > Cmake > Ninja > GCC
I've been through this fun, and it's just not worth the fun.
On a related note, The micropython stack for the microbit is currently:
Bare metal > mBed HAL > microbit-dal > micropython_hal > micropython
so three hardware abstraction layers! and this is on a device with only 16k RAM. Now Damien did a great job on getting micropython ported so quickly, but there /must/ be a better long-term solution to the mBed/yotta approach.
I've seen a few reports online* mentioning this was specifically removed. Given the target market (11 year olds, many of whom are likely to have younger siblings) exposed coin cell batteries are a potential risk the BBC had to consider and chose to avoid. I do wonder what the cost of a basic plastic case would be.
* http://www.theregister.co.uk/2015/07/07/bbc_microbit_final_s...
This is very different to what we're used to. For tiny programs it is great, anything non-trivial might be difficult to debug.
Someone had to ask [further](http://forum.espruino.com/conversations/284474/#comment12898...)
I would hate to spend money and yet another windows exclusive gadget.
Gives you a REPL, but you lose Bluetooth
Preordering has started.
'For delivery in July'
CPC Farnell for bulk (school etc.) orders: http://cpc.farnell.com/bbc-microbit
Other stockists:
Kitronik: https://kitronik.co.uk/microbitpreorder
Pimoroni: https://shop.pimoroni.com/products/microbit
The Pi Hut: https://thepihut.com/collections/microbit
Technology Will Save Us: https://www.techwillsaveus.com/shop/microbit/
Sciencescope: https://sciencescope.uk/product/bbc-microbit