When discussing the design and integration of systems on chip and models of systems on chip, the Lego analogy is often brought up. The idea being that with Lego, anyone can put together anything and every component can be combined with all other components. Right. My recent building of Lego set 21327, Typewriter, makes me wonder if the people who talk about Lego-like construction have actually built anything from Legos in the past few decades.Continue reading “Easy to Assemble, just like Lego – Right…”
Yesterday, I saw the Lego Movie with the entire family. I enjoyed it. Sure, it was a gigantic product placement for Lego – but that was kind of a given from the start, right? The story moved on at a good pace, and both the visual style and the storyline was a bit surprising.
LEGOs seem to be a favorite analogy for people bemoaning the state of software development today. “If only it would be as simple as putting Legos together” is a common enough statement, along with various proposals to make software that is Lego-like. Sometime, I wonder if people making these statements have actually tried to build anything non-trivial from Lego recently. Here, I will look a bit closer at the Lego-programming analogy. There is indeed quite a lot to it, but it is not all about child-level simplicity. I think there are some good lessons that can be learnt from analogizing Lego and programming.
Legoland is full of cool and interesting Lego models, built from millions and millions of Lego bricks. The creations don’t have too much in common with the standard Lego kits sold in stores. Rather, they are advanced uses of Lego bricks that look like something from the real world — especially at a distance. Up close, they are very blocky and not as smooth and polished as regular Lego models.
Essentially, they are voxel graphic representations that must be very hard to plan and execute. The standard single-stud 1×1 Lego brick is their smallest unit, or maybe its 1/3 height flat version. Here are some examples that I photographed in Legoland during my visit this Summer.
I have now torn down the Kindergarten Robot, as I wanted to build some other things. However, before tearing it down, I did take a few more movies of its critical functions.
Today I finally got to try my MEPROM-equipped Lego Mindstorms robot with a larger group of kids. As expected, this did not go quite as expected.
When I got the Lego Mindstorms robotics kit that I have been blogging about before (1,2,3), one of my goals was to try my hands on some graphical “model-driven” programming. Thanks for the various tips for other more traditional programming environments that I have received over comments, Facebook, and personal email. But my main goal was really to try to use the NXT environment as a graphical, domain-specific, rapid programming environment. Having played around with some simple projects for a couple of months now, it is clear that somethings are easier to do than others.
As discussed in my previous blog post about Kindergarten robots, I wanted to see if I can teach kids the core idea of programming. This project has now progressed to the point that I have a working prototype of a programmable robot.
Essentially, the robot is programmed by putting colored Lego bricks in a sequence on top of the robot. This should be accessible and direct enough to work with kids — and with no computer needed, just direct physical interaction with the system. For some reason, I think the extra level of abstraction from a screen to a robot is just an unnecessary obstacle at this level.
One of my little projects while on parental leave has been to play around with my Lego Mindstorms NXT 2.0 robotics kit. Apart from being fun for a serious dad like myself, I always had in mind how I could use it with kids to get them interested in technology.
When I was a PhD student in Uppsala back around 2000, we bought a pile of the Lego Mindstorms RCX kits, for use in real-time courses. Obviously, the students loved the opportunity to play with Lego (including the few females). What was less obvious and much more interesting was what happened when we brought in a bunch of children from a local kindergarten to visit — they really took a liking to our little yellow robots running around a classroom. They treated the robots as little animals, wondering what they were doing and why…
With that in mind, I decided to try to reprise this myself with my own son and his kindergarten friends. Last week, I took my robot kit with me and went to meet the kids.
For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.
It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…
During the Christmas holidays, I got the chance to compare my oldest child’s brand new Lego set with some from the mid-1980s. It is quite striking how much larger the things in the sets have become, and how much more affordable (in relative terms) Lego has become since then.
This might appear as a stretched analogy, but it struck as me as obvious when I tried playing the Lego Racers boardgame with my 3-year old this weekend. The game is ranked pretty low on Boardgamegeek, and deservedly so. The promise and premise is great: use Lego cars to race around a track and pick up new pieces to modify the powers of your car… sounds like great fun. Right? But it is not, and that’s where my analogy with the age of software comes in.