Make It Compatible

I’m probably as guilty as anyone of reinventing the wheel for a subpart of a project. Heck, sometimes I just feel like working on a wheel design. But if that’s the path you choose, you have to think about whether or not it’s important that others can replicate your project. The nice thing about a bog-standard wheel is that everyone has got one.

The case study I have in mind is a wall-plotter project that appeared on Hackaday this week. It’s a really sweet design, and in many ways would be an ideal starter project. I actually need a wall plotter (for reasons) and like a number of the choices made. For instance, having nearly everything, including the lightweight geared steppers on the gondola makes it easy to install and uninstall — you just pin up the timing belt from which it hangs and you’re done. Extra weight on the gondola helps with stability anyway. It’s open source and based on the Arduino libraries, so it should be easy enough to port to whatever microcontroller I have on hand.

But the image-generation toolchain is awkward, involving cutting and pasting into a spreadsheet, which generates a text file in a custom plotting micro-language. Presumably the designer doesn’t know about Gcode, which is essentially the lingua franca of moving machines, or just didn’t feel like implementing it. Where in Gcode, movement commands are like “G1 X100 Y50”, this device expects “draw_line(0,0,100,50)”. They’re essentially equivalent, but incompatible.

I totally understand that the author must have had a good time thinking up the movement commands and writing the spreadsheet that translates SVG files into them. I’ve been there and done that! But if the wall plotter spoke Gcode instead of its own dialect, it would slot instantly into any number of graphics processing workflows, which would make me, the potential user, happier.

When you are looking at reinventing the wheel, think about your audience. If you’re the only person likely to see the project, go ahead and scratch whatever itch you’ve got. You’ll learn more that way. But if you want to share the project with as many people as possible, adhering to the most widely used standards is a good choice for your users, even if it is less fun than dreaming up your own movement language.

AI Maybe Revives Dead Languages

While Star Trek’s transporter is hard to imagine — perfect matter movement across vast distances with no equipment on one end — it may not be the most far-fetched piece of tech on the Enterprise. While there are several contenders, I strongly suspect the universal translator is the most unlikely MacGuffin. After all, how would you decipher a totally unknown language in real-time? Of course, no one wants to watch 30 episodes of TV about how we finally figured out what Klingons call clouds, so pretty much every science fiction movie has some hand-waving explanation for speaking the viewer’s language. Farscape had microbes, some aliens have telepathy that works with alien brains of any kind, and still others study English from afar for decades off camera. Babelfish anyone?

I was thinking about this because of an article I read by [Alizeh Kohari] about [Jiaming Luo’s] work using AI to decode dead languages. While this might seem to be similar to Spock’s translator, it really isn’t. Human languages change over time and distance. You only have to watch the BBC or read something written by Thomas Jefferson to see that. But there is still a lot in common, at least within certain domains.

Continue reading “AI Maybe Revives Dead Languages”

Running LISP On An ESP8266

LISP is a polarizing language. Either you love it or you hate it. But we’ll put aside our personal preferences to bring you a good hack. In this case a LISP environment running on an ESP8266. [Dmitry] is on the “love it” side of the fence — he’s been waiting for an excuse to code up a LISP interpreter for a while, and he found one in the ESP8266.

there-is-always-a-way-2Actually, [Dmitry] is running LISP inside JavaScript, which is itself presumably coded up in C, before it’s assembled to run on an ESP8266. (It’s turtles all the way down!) This means that he can piggy-back on JavaScript’s garbage collection and console handling and so on. After picking a suitably small LISP implementation (actually a Scheme dialect for those of you who know the difference), he went to work.

One weekend bled into the next, but he got the system running, connected to the network, and had LEDs blinking! In the end, he even managed to squeeze in some optimization for memory’s sake. Pretty cool, and because it takes advantage of an already complete system, it can even be made pretty useful. Not bad for a few weekends’ work!

And finally, if Lots of Irritating Silly Parentheses is your idea of a good time, but the wealth of computing resources available on an ESP8266 seem overkill, have a look at Microlisp, running on an AVR. Or go to the opposite extreme, and run a LISP OS on a Raspberry Pi. Whatever you do, don’t forget to close your parentheses! (We’re told that’s a traditional LISPer farewell.)