With the right controller hardware, you can do robotics with Perl. The
LM629 chip I mentioned implements a PID control algorithm. I've found that two or three of these work fine for robotics with multiple motors running simultaneously, even from a high-level language. You just program them so that their trapezoids are the same length and have the same duration of acceleration, then start them simultaneously (you'll probably want hardware that's set up for simultaneous starting).
More and more, it doesn't make sense to have a single central program/processor running everything from low-level control (motors and limit switches) to high-level control (scheduling, receiving commands from the network, UI). Processors (and specialized controllers like the LM629) are cheap; they should be put into hardware that needs them. It almost never makes sense to have a general purpose computer controlling motor hardware directly (i.e. reading encoders and controlling PWM or steps). You want an embedded system that can present a reasonably high-level interface (like the one that was described in the original post, or like my semiconductor machine robots).
Where Perl is somewhat weak for robotics and other embedded systems work (IMO) is in its lack of threading, and in its lack of a standard idiom for handling exceptions. With die/eval you have one option: to abort the operation (you can, of course, retry the whole eval block if you want). Other languages offer better control on exceptions.
For instance, Smalltalk allows you to retry the method call that threw the exception (as opposed to the whole block in Perl), or to resume it as if nothing had happened. This has been helpful in my embedded systems work for handling robot errors like timeouts, and in situations where there could be some chance of human-assisted error recovery.
