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!