Closures -- a Simple Explanation

Closures are simple.  They are functions that carry state that are in scope when a function is called.

I think a lot of confusion arises because there is no need for closures in popular imperative OO languages like Java which many, if not most, developers are most familiar with.  The state is carried in the containing object that every function must have.  But for functional or hybrid languages where functions do not necessarily have a containing object, they are vital.  In hybrid languages like Scala or Javascript they allow access to state that can be seen by other functions and objects as opposed to state that is contained just within the function's scope without the need of a containing object.  This is powerful but dangerous in that you can change the state of these variables and, without great care, they can change in surprising ways.   In purely functional languages like Haskell where state is immutable closures are useful to pass around necessary "write once" state with the function with no worries about side effects while ensuring the function has everything it needs to work when necessary. 

Google App Inventor No Threat to Professional Developers

This past weekend I fulfilled a promise to my 3 yr old son.  I told him we'd make a game for Android out of a few of his favorite drawings.  He is very curious about what I do so I wanted him to be as directly involved as a three yr old can be in this kind of thing.  I also wanted to try out App Inventor so I signed up and got to work.

For those that don't know, App Inventor is a Google project that is designed to bring programming to non-programmers through an intuitive, visual interface.  Here is an example of the code 'Blocks Editor':

As you can see, there are different types of blocks for functions, control structures variables and what have you.  Overall a very nice and very intuitive interface.  Even my three yr old was starting to get it (at least which shapes fit together).

There is also a screen where you drag and drop visible UI objects and non-visible objects you'd like to have 'Staged' and ready to use.

Google has done a very nice job.  I can definitely see a teacher or student with little background programming experience diving in and creating relatively simple apps and games.  Importing external resources like pics was a breeze and using the 'Code Blocks' interface was fun up to a point.

But there are serious limitations that were somewhat frustrating:

• First and foremost:  No dynamic object creation!  Everything you want to manipulate in the program must be staged and loaded at program initialization.  For such a simple project this was not insurmountable; I just reused objects as I needed them and for UI objects I made them invisible when not needed.  As a practiced programmer this seemed very non-intuitive.  For example, if I wanted to make more enemies, I could not define an enemy class and initialize one on demand. I had to stage separate enemies from the get go and just have them not interact with the rest of the game until called upon.
• Second:  The 'Code Blocks' IDE was really, really slow.  It is a slow paradigm anyway, clicking and dragging visual components to build code, which is expected, but the refresh rate and the lag was absolutely terrible.  This is on a machine with 6GB RAM.
• Third:  The 'Code Blocks' canvas cannot be dynamically sized, the individual code blocks within a method block cannot be folded and parts of the method block cannot be dragged off-canvas.  This puts an effective limit on the size of your methods.  You can break your method up using sub procedures but because there are only so many control structures available (for example:  there is no switch statement) it is very easy to have a very long chain of 'if' statements that go beyond this limit.  Also, I don't think re-factoring a logical unit of work into smaller sub-statements would be obvious to the novice target audience.

That sums up what I consider the preventable problems with AppInventor that I have run into so far that would keep it from becoming a threat to practiced programmers.  That is to say, limitations that are not inherent in the visual programming model.  There are a number of more intrinsic design features that also keep the threat level low:

• Programming by dragging visual bits around is tedious.  In my situation this worked out well because it gave me a chance to slow down and explain what I was doing to my son but for belting out useful programs it does not cut it.
• Limiting the available methods to make the visual aspects easier to navigate cuts out a lot of flexibility in the API you have to work with.  The flip side is that it makes common actions more obvious and intuitive to implement...less getting lost in the nitty-gritty details of an API that you will never likely have to use anyway.
• Limiting your vocabulary to visual bits make obvious design improvements as you code impossible -- for example, you can't subclass an object or compose built-in objects within a custom object etc....there is just no way to define your own complex objects.

So no one is going to be losing their job because of the flood of awesome App Inventor applications anytime soon.  But there might be some larvae stage hackers making some fun games and applications and getting hooked on programming!

Alternative to JRebel

The Dynamic Code Evolution VM promises an open source alternative to JRebel that will allow redefinition of loaded classes at runtime!  Exciting stuff if well executed.  JRebel has done wonderful work in this area, it will be interesting to see if this team has anything that compares to the comprehensive support of hot swapping that JRebel does.

I have not gotten a chance to try it but I will and I will  post an update.

Software Patent Defense for the Little Guy

It is no secret that the end of the software patent détente has come. It seems like all of the big players in software are suing each other these days [1].   All of these companies have big budgets for lots of lawyers and many patents with which to threaten each other.  But what happens to the little guy who gets sued or even just  threatened with a suit over patent issues?  Well, considering the high cost of fighting such suits, the risks involved, and the lack of counter-suit options, that business owner generally rolls over and pays a licensing fee to the accuser,whether it is truly warranted or not, or they simply stop the potentially infringing business activity...sometimes the overall business organization survives such a blow, sometimes not.

What if the little guy had a patent portfolio to fall back on, to bring counter-suit to the accusing party or invalidate the held patent with an earlier patent or prior art?  What if the little guy had some legal help on retainer so that a simple threat would no have so much weight on its own?  What if there was a cheap way to patent software that would not only protect the innovator's interests but the interests of all of those in our industry that believe that implementation (protected under copyright) is much, much more valuable than ideas (protected by patents)?

There are over a million software engineers and computer programmers in the U.S. If 15% were convinced to give $30 a month (or their employers) that would be over $50 million a year for operations for such an entity. That is not including other donations that would be solicited, or fees payed by other interested parties such as hardware manufacturers, venture capitalists and the like.

Now will $50 mil. be the death knell for the pro software patent lobby or patent trolls? No, there are some very deep pockets that would fund the other side well, but it is a fine start.  My hope would be that the $50 mil. would mostly go to crushing trolls in court, sucking up tasty patents, building and maintaining a solid resource of precedent and prior art in this area and setting good precedent in the courts and perhaps a bit of lobbying with what is left...mostly, the point would be to give the little guys protection through sheer numbers that right now only the largest companies and organizations enjoy through the size of their tresuries.  A non-profit SMB NATO for deterring the patent-troll menace with its own patent arsenal and defense infrastructure.

So there are patent defense companies like Allied Security Trust, RPX and the Open Invention Network but these are for major players and/or have very limited scopes.

I'd love to see the patent system overhauled.  Bilski gets pretty far into defending folks from the overreaching grasp of bad patents but we could wait for decades for reform and wielding Bilski still requires substantial individual legal investment.  This is just my two cents on some positive action that can be taken today so that we can operate and innovate in an business environment with just that much less fear.

More Groovy Weirdness

I love Groovy.  There is no telling how much time it has saved me in scripting simple tasks.  I do stumble over groovy sometimes though, and it seems it mostly relates to scoping rules.

I am the first to admit, I do not write scripts very 'Groovily'.  It looks more like Java that uses some nice closures when convenient (but, boy are those /really/ convenient).  So I am sure that if I stuck to a more Groove like style I would not run into these problems but today I wrote a simple script.  I put a bunch of variables at the top of the script and ran it and --- Whoops I tripped over a groovy.lang.MissingPropertyException: No such property:  for class exception.

Turns out, in a Groovy script, variables that are not defined within methods /cannot/ have either an explicit type or a def.  This is easy to fix, of course.  Just let Groovy handle the duck typing or turn the script into a class but still, a little surprising.