Tuesday, April 01, 2014

Teaching Forth Programming to kids... is really dangerous...

Teaching Forth Programming to kids is irresponsible and may hinder their progression into the professional programming industry.

So, let's do it.
One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools.   - Donald Knuth, Computer Programming as an Art 

Forth doesn't have a lot of modern facilities, but that forces you to figure them out yourself.  Better yet, Forth encourages that you solve the problem at hand (rather than build elaborate frameworks).

I've been called out, in this blog somewhere, for promoting archaic old principles that don't apply to modern development.  But, I don't actually want to force people to learn this stuff. Find your tool and if it helps you do amazing things, stick with it.  

I've been programming in Forth since 1984.  I've learned a dozen languages since.  Forth is still the one that focuses my attention on problem solving better than any other.

Why am I writing this now?  I'm a bit late, but I just discovered this: Gforth for Google Chrome.

It's a toy right now (apparently no persistent file I/O), but I want it to be real.  I want to fire this up in a classroom full of kids and get them hacking.  I want them to build their own abstractions. I want them to see what middleware really is (a bunch of layered restrictions with the goal of making things more structured and easy, while in reality making you conform to things they want to keep hidden -- okay a rant for another day).

Sure, underneath Gforth for Google Chrome there are layers upon layers.  But there is a lesson there too: Its all about simulation.  It's Turing machines all the way down.

Tuesday, March 18, 2014

Statically Typed Languages like C++ and Haskell are good for lazy programmers (like me)

I've seen my errors in production code. I'm doing a forensic analysis of some "embedded" software I shipped to a customer.  By embedded I mean there is no UI and it is supposed to run unsupervised 24x7.

Server (Cloud) software often meet this criteria, but sometimes we cheat and log in (to see how things are going) or restart the OS when things aren't quite right.

But, that's not quite embedded. By embedded I mean "It has to run without me or the user intervening." and "There is no such thing as rebooting to fix a problem."

Now, I love developing code in Lua, so this isn't a Lua criticism, but when I review my daemon logs and see that the process died because I was trying to add a number to a "nil" value, I cringe.

On this same system I have a Haskell process also running.  The only time I saw it had died was when I didn't handlebeing fed bad data from a corrupt database.  Not exactly the same class of bug...

The Lua code problem could have been caught with unit tests or code review (maybe), but I am sort of a lazy programmer.  I can fall back on lazy habits such as "this is so obvious it can't be wrong".

Haskell doesn't let me do this.  It won't let me go on tossing untyped variables here and there . It won't let me assume that I never pass a string as a number (or vice versa).  It forces me to be precise.

Compiling modern C++ (C++11) with warnings on (in clang++ or g++) is similar.

I hate to say this, but after continually abandoning C++ (in cycles: 1992, 1997, 2002, etc), I am back again and I like what I see in C++11.

I'm writing deliverable code at work using C++11 and I just tried my hand at using it, *instead* of a scripting language, to do some configuration file handling.  C++11 for scripting?  Yes. And it seems to work.  Not a pointer in sight. (Actually that would be the only sane way to do this in C++: rely on RAII.)

All that being said, and especially to any potential employer who may be reading this: I am not really a lazy programmer.

Monday, January 20, 2014

The IDE called Forth, or.. Forth I wish I knew how to quit you.

I've been playing with OpenFirmware. Yep, booting it off of a thumb drive (via Grub2). It takes less than a second to boot on a "fast" laptop up to the Forth "ok" prompt.  At that point, I can start playing around with low level hardware.  Open Firmware went so far as to provide a "GNU readline" like capability where I can use Emacs-like command line editing and completion of words.

But, wait, there is no command manual!  What does this word do?  Enter "see" and the word you are interested in and view disassembled source code.

People (still) underestimate the innovations built into a "classic" Forth.   Gforth still has some classic capability built in.

Here is what I had with Forth during the 1980s (on Commodore 64 and then Atari ST):
  1. Full screen block editor.
  2. "See" or equivalent for looking at source.
  3. The ability to ask the block editor to locate the "real" source and let me edit it (i.e. Tags).
  4. The ability to play around with graphics and other hardware facilities.
  5. Very fast start up (or restart for when I crash the machine).
This was the basic Forth IDE.

I'm a long time Emacs user (25+ years)  and I still not at that same IDE productivity level I was with Forth back in the day.

Smalltalk (in particular Squeak) has been the only other things that has come as close (for me).

I know that machines are bigger and software is a lot more complex these days, but why can't I have that same feeling of "being one" with the machine?

Here is what I want:  I want to load up an interesting library (e.g. libpcap, OpenCV, etc) into a Forth (e.g. Gforth) and explore.  I want to play.  Lua, Perl and Python can get me half way there (i.e. bindings), but I still have to grapple with a REPL that doesn't seamlessly integrate with the editor.  

Yes, yes I know you can bend Vim or Emacs to do these things, but the resulting IDE isn't as natural (IMHO). You are still piecing together a generic editor, a command line (linux shell) and a programming language. (For example, how do you list a directory in the chosen language? Oh, you use the shell or editor? Are the results first class elements for the language?). 

Some would say that Visual Studio is a great example of a seamless IDE, but it is still working with a language that isn't naturally "interactive".

This is why I still hang onto Forth. It isn't about Forth building better apps. I don't care what an app is built in.   It isn't about the destination, its all about the journey.

Thursday, January 02, 2014

Todd's 1 question test for all new "advanced" dynamic scripting/programming languages.

Whenever a new language comes out I have a simple test to see if it is worth looking at.  I came up with this test back in the 1990s after being frustrated by the state of "advanced programming languages".

In the 1980s, as a lowly FORTH programmer, twiddling 8-bit bytes, I was blown away with my first experience with Lisp. It was on a DEC2060 (running TOPS-20) and was called "Standard Lisp".

As a student, back in 1984, I coded up a small lisp function to compute the factorial of 120.

The terminal presented me with:


My mind was sufficiently blown.

Of course, the largest factorial computed by a programming language where the number/integer type is matched to the machine word size is much smaller.  I had already programmed in Pascal, FORTH, a bit of C and BASIC.  But, this was the first language implementation I had seen that wasn't bound by that machine word limitation.

(I quickly followed that exercise by coding for the factorial of increasing numbers until, by the time I was in the hundreds of thousands, the terminal responded with a message saying that it was taking too many resources and that the process was being "spooled" -- whatever that meant.  I went home and the next morning I was greeted with an email from the sysadmin requesting that I come get a "print job" from the ops center.  I rang the ops center door buzzer, the admin came to the door and asked what I wanted. I told him him who I was and he then frowned, told me to wait and closed the door. A few minutes later he showed up with a hand truck loaded with a big box of green bar printer paper.  Apparently, "spooled" meant the result was being submitted as a print job).

A couple of years later and I discovered that Smalltalk too had this "big num" (or arbitrary precision) feature.  Why wouldn't every language have that? (Yeah, I know... performance...but, still...)

Now, when I am presented with a programming language that is supposed to be the "next step",  I look to see if it supports bignum.  Now, when I say support, I don't mean surrounding the number by quotes and submitting it to a bignum library. That's cheating. I want to say something like:

X=6689502913449127057588118054090372586752746333138029810295671352301633557244962989366874165271984981308157637893214090552534408589408121859898481114389650005964960521256960000000000000000000000000000  / 19;

I don't want to type it as a string. That's saying that there is something "special" or "hard" about large numbers.  Why, in 2014, should I be concerned about whether a number fits into 32 or 64 bits (or in the case of Lua and Javascript: a 52 bit mantissa)?  I want tnative/natural support.

So, what other programming languages pass this bignum test?

  • Erlang does. 
  • Haskell does... sort of... got to choose the right type.
  • Perl does (and has for a while.. just type "use bigum;"  and all following numbers are not bound by machine word size.

Now, don't get me going about native/natural support for rational types.


Thursday, December 19, 2013

Perl is 26 years old?

I just read on Hacker's News that Perl turns 26 years old today.  My oldest piece of open source software is written in Perl. AFT.  AFT was coded in Perl 5 back in 1996 (which makes it over 17 years old).

I originally wrote AFT in awk (sometime during the early/mid 1990s) . I ported it to Perl by using the awk to perl translator (a2p) as a starting point.

Every once in a while I revisit AFT to see if there are any new tricks to add or just to clean up the code and make it a bit more Modern Perl.  AFT is still in the Ubuntu software repository, so you can install it under Ubuntu by simply doing   sudo apt-get install aft.

I'm still using Perl. I am doing some funky stuff with the AWS cloud (EC2 instances) and find Lincoln D. Stein's VM::EC2 package fits my needs.  Perl is still great for replacing nasty bash/sh scripts (although some would say I am replacing the nastiness of  bash with nastiness of Perl).

I'm not much of a CPAN user, but those who know me understand that I am very selective of libraries and frameworks. I prefer to avoid layering and loading lots of dependencies. What I find attractive about Perl is how much the basic distribution can get accomplished  (e.g. I don't have to resort to libraries so quickly as when I program in Lua).

I'm particularly interested in investigating Mojolicious for use in my elderly monitoring project.  I use LuaJIT primarily on the base station (with a bit of Erlang).  The cloud side is currently a fair amount of Perl.  But aren't there better languages to do cloud/web development?  Isn't Perl old hat?

For those folk who think that Perl is old hat and doesn't have a place in the modern Web, do you use DuckDuckGo?  It was developed primarily in Perl....

Tuesday, October 01, 2013

Power Considerations for an HVAC Thermostat (10 years off a couple of AA batteries?)

Hear a tick coming from your thermostat every time it turns on the heat or AC? Well, assuming you have an electronic/digital thermostat, you are hearing a latching relay.

Latching relays are wonderful power miserly switches. Unlike a solid state relay, which requires control current (anywhere typically between .25mA and 20mA depending on what you choose), a latching (mechanical) relay will latch (hence it's name) when pulsed.  A short burst of 100mA or so and you are done.  If your thermostat is switching the HVAC once an hour per day (which is pretty excessive), then you are still using a lot less power than a solid state relay.  Another potential problem with solid state relays is heat. They generate heat. They can overheat and if you don't choose and place your components wisely, they can affect the temperature sensor.

With latching relays,  your modern latching thermostat is not consuming that much energy.

Interestingly, I believe that the NEST uses solid state relays.

A quick google shows that some NEST customers are having battery issues. Here is an interesting one:

This is the kind of issue I want to avoid.  The two household gadgets that I don't want to think about (battery) power problems are my smoke detectors and my thermostat. I'll check once a year, but beyond that...

Here is a target: Ignore UI and wireless for a moment. Once a temperature schedule has been set, can you design a thermostat that will run for 10 years off of a couple of Lithium AA batteries?  That is my starting point.

So, as boring as "Thermostat design" sounds, it poses an interesting power problem.  Add sophisticated 'internet-of-things' functionality and now you have two problems.

Saturday, September 28, 2013

An Alternative Take on Thermostats

For most thermostats (including NEST), there seems to be a power/location problem.   At best you have 24VAC control lines you can parasitically suck for power or (worse case) you have some AA batteries that you hope will last a couple of years.  With batteries you start to seriously limit what your thermostat can do (a reminder htat your thermostat is NOT a general purpose computer).  With parasitic sucking off the control lines you start playing games with how to ensure that you always have enough power (OMG,  HVAC off for maintenance or power outage and what should the thermostat do?).

So okay, we've got a power management problem.

A question:

Why is your thermostat's primary User Interface (UI) mounted to a wall (and often in a place not where you are comfortably located)?

The location of your thermostat probably has a lot to do with the "best" place to measure room temperature (out of the sun) and where you can run HVAC wires.  There are other factors, but it doesn't matter.  I have to get up and go there to read or adjust the temperature. (Of course, with NEST and other networked thermostats you can change temperature from almost anywhere).

A proposal:

Don't put the UI into the thermostat.

What?  But where do we put it?  Surely not rely on the smartphone, right?  Yes. But consider this:

The thermostat will now consist of a small discrete box (hide it behind a picture frame or paint it to blend in) with a temperature sensor (maybe), the required solid state relays to control the HVAC, a couple of AA (or AAA) batteries, and an small RF transceiver (433MHz if you desire).

Pick a convenient location (or two) and install the UI there (and a temperature sensor too). It can be on the wall, on the kitchen counter, maybe a shelf, etc.  The only requirement is that you have AC power (see where I am headed?).

Now, let's rename this UI a "control center". This control center (still very small) can not only host the UI but can also support Bluetooth and/or Wi-Fi, so you can use your phone to control the HVAC from your bed or couch.

If we do the RF correctly it can be safe (validated/encrypted) and reliable.  Because the control center is plugged into AC, we don't have power management issues. The thermostat itself is running off of batteries or even parasitic power.  We still have some power mgmt issues, but we can duty cycle the RF to reduce the overall power consumption. (A thermostat's control loop is *never* under immediate control of your thermostat's UI -- you "advise" the control loop what to do, so a couple of second lag is okay).

Now, with this setup we can put a lot of sophistication into the control center. It can be a (shudder) computer and suddenly our thermostat can become something much more interesting...

Thoughts of a Haskell (or Erlang or Lua) powered thermostat starts to become more of a possibility.