The November/December 2011 issue of IEEE Software has a good article by Markus Völter titled, "From Programming to Modeling—and Back Again". In it, the author asks, "What's the difference between programming and modeling? And should there be one?" His answer to the second question is no: instead of today's sharp divide between describing the problem domain, and telling a computer what to do, we should use extensible environments that support a continuum between the two. I like his description of what's wrong with things today: we shouldn't use concrete syntax as a storage format. But as with so many other articles on extensible programming, I think he glosses over the biggest practical obstacle such systems face: debugging. An abstraction's usefulness is limited by how fixable it is when it breaks; if you give me a way to program in pictures, in natural language, or in some domain-specific notation, but then require me to wade through automatically-generated spaghetti code to figure out why my description of what I want isn't doing the right thing, you haven't really helped me very much. I'm still trying to figure out how to reconcile this with the "pile of crap" problem I ranted about in my previous post, though. If my editor/compiler/debugger are all extensible, then everything I try to do will trip over installation and configuration snags...