ArcPy and PubPy – extensibility done (mostly) right

Greenspun’s tenth rule of programming states: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Although I can’t say definitively what Philip Greenspun intended when he said it, but it’s always spoken to me since I first heard it whenever it was many years ago: if your program (or software system) is going to get to a sufficient size, it’s inevitable that you or someone who is using it will want to automate or extend that program in some language other than that in which it was implemented. Most folks will choose to roll their own, winding up with some sort of half-baked even if Turing-complete kludge, that works kinda sorta. However, it would be far better to start out with something that is a first-class programming language or system and use that to extend the system – or better yet implement substantial portions of that application in that language, blurring the distinction between implementation and extension language.

Back in the day, ArcView and friends had AML – the ARC Macro Language. It was better than nothing, but it left much to be desired when compared to a real programming language. Esri was hardly unique in falling into the tenth rule trap – even today Microsoft Excel can be extended by Visual Basic for Applications, one of the cruelest afflictions ever set upon people with even a passing interest in programming languages, their design, implementation, and use. Microsoft came to its senses introducing the C# programming language and its seamless integration into .Net. Esri came to its senses and chose to build on top of the widely used and supported “batteries included” programming language and system called Python. The practical meaning of this is that there is a first-class programming system available for automating and building applications for ArcGIS that allows Esri to focus on what Esri does best, and leave the language design and implementation to folks who do that well, leveraging in the process hundreds of man-years of library development and use in support. Esri’s ArcGIS-specific extensions exposed through Python are called ArcPy. Similarly, we at TerraGo have implemented Publisher extensions which we call – perhaps unsurprisingly – PubPy.

With PubPy, we have tried to adhere as closely as possible to the design and implementation of similar interfaces exposed by Esri through ArcPy, so that PubPy will be as familiar as possible to the ArcPy programmer. Also, we’ve provided some convenience functions to make the easy stuff as easy as possible. Of course, we’re still in the early phases of PubPy’s implementation, so there is much more to do, but what’s now possible is remarkable, due in no small measure to Esri’s decision to use Python, as will, no doubt, to contribute rapidly to what’s already there.  By saying it’s mostly right, we can only take partial credit in light of realizing it’s something we should have done years ago – or even from the outset; I’m pretty sure I knew of Greenspun’s tenth rule of programming when we started Publisher.

Tags: ArcPy, PubPy

Categories: arcgis, big data, esri, GeoPDF, geospatial, GIS, mapping, technology, terrago

This entry was posted on Tuesday, October 13th, 2015 at 7:40 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.