The following post has some very good thoughts about what languages to teach undergrads: Walking Randomly » Should Fortran be taught to Undergraduates?. Essentially he suggests starting with Python, NumPy & matplotlib which are both excellent and free.  He briefly mentions MATLAB in the post as well, but doesn't say much about whether or not to use it.  I would suggest that people NOT use it, unless it specifically has some sort of built-in functionality that you need and can't easily get elsewhere.  It's a member of a class of tools that while quite easy to get started with and providing decent performance lock you into a closed toolchain which you either have to pay quite a bit of money for or lose the value of the tools you've built on top of it.  For basic numerical work, there's not really much of an argument for needing to have MATLAB.  Python, NumPy & matplotlib are free, quite easy to work with, and expose you to the wonderful world of Python modules, where chances are someone has put together some quality groundwork for you to build upon for numerical work, networking, database, and a lot of other areas which are somewhat beyond the central expertise provided by tools like MATLAB.  Heck, you can even get support for it if you want to: Enthought.

LuaRPC has grown a few additional features again.  We are now able to handle calling functions that are registered on tables and not just in the global environment.  This is crucial to be able to use modules where where functions are registered at something like modulename.function or modulename.subtable.function.  I've also stripped out some now unneeded code that did some remote error handling since the functionality it was used for was just adding an extra static buffer.  We also are now set up to be able to register additional commands that can be issued to the remote side beyond function calls.  Initially this will be used to provide methods to serialize data on the remote server and return this data locally, other functionality may follow. I also struck up a conversation on the Lua List about how one might go about treating a remote lua universe as just another table (do function calls, get data, handle metamethods, etc..), and there appear to be a number of problems in the way of doing all of that simply.  I think that the added command extensions will be used to add some sane portions of this functionality, and more complicated-to-implement functionality will be tabled until solutions can be found that aren't miserably hackish.  If you're interested in reading the exchange, you can find it here.

I've got a few more issues to attend to before I'm going to put the LuaRPC code into the eLua trunk.  One thing that I'm thinking about that I've not yet come up with a satisfactory solution for is dealing with connection state.  The original code used sockets, and therefore the protocol makes some assumptions that, in most cases, data arrives in order with no errors, unless some exception is thrown. One advantage of all of this is that the code is reasonably simple and is minimal on CPU usage.  However, I think it's a little too minimal to handle serial communications where a client might hangup or one simply gets a bad read, and there are only the TXD and RXD lines to indicate physical/data link state.  So far what I've done is padded out each buffered read & write (one or many bytes) with a header and tail byte (different) so that either the client or server can complain and jump back to waiting for fresh requests on error.  I may consider following HDLC a little more closely in terms of asynchronous framing, but this may be OK for now. It should be easy to layer checksums, addressing, retransmission or other assurances on top of this implementation by simply wrapping the functions that read and write chunks of data.