In Reset: The New Normal I explored the reasons that business apps have to run on multiple types of devices and on multiple OS’s within 3 years. That in turn led me to a sea change in how I view my development tools. I alluded to that change in direction in that blog entry. In this entry I flesh out major details. Well, not just the details, which can be pretty boring. The rationale for choices that lead to the details are pretty interesting (read: it’s possible to argue each choice at least 2 ways). And because the choices reflect a choice I thought I would never make, the act of declaring the choices is a bit scary.
Farewell, .Net, I Hardly Knew Ye
Well, I knew you a bit, and there are certainly tools you have that I will miss being able to use. But you are controlled by a brilliant guy who thinks static is good, and dynamic is bad. That developers must be controlled. And that’s from his asides during presentations, the unscripted comments. And then there’s the impedance mismatch between data and objects, papered over (clumsily) with LINQ and various ORM’s, that will persist. For apps that do the data manipulation that I know from our experience to be necessary in full-featured business apps, this mismatch would be a tremendous liability that would not go away. I found ways to work around it, but these are pretty convoluted, and most importantly would not help us get to “everywhere,” which is where we need to be.
Hail Python, My Good Buddy
Working with complex domains requires complex code. And that in turn means that the feedback loop of code-observe-code gets taxed. Simple things that you’ve done 20 times don’t tax the feedback loop, but expert apps, designed for Tier 1 and Tier 2 businesses (largest and next-to-largest, on a scale of 1 to 4), by definition are complex. If they were simple, or even sort-of-simple, anyone could and would do them.
Nobody gets complex creation, in any field, right the first time. Even The Masters covered up their painting mistakes. The difference with software is that it can always be changed. But to change it the feedback loop has to be engaged. And there is nothing more beneficial in enhancing feedback loop efficiency than working in a dynamic language that allows observing and changing values during runtime. And that’s where Python (and other dynamic languages) fit.
Python is a very clean, straight-forward, dynamic and object-oriented language, with a huge base of users (#6 on the Tiobe index and rising, and in fact rising faster than C#, which is #5 by .2% over Python –- at the present rate, Python will overtake C# early in the coming year). It is one of the “official” languages at Google (the Google App Engine has Python and Java SDK’s), Yahoo, Nasa, etc. It has easy-to-use libraries for every purpose imaginable. It runs everywhere. While there are other like languages (e.g., Ruby, also with a huge user base, but is at #11 on the Tiobe index, and actually falling in relative place), none are as clean and straightforward, and as complete, as Python. Most importantly, Python has available established (V 1.0 or later) frameworks for getting applications everywhere, as mentioned above.
A VFP programmer used to programming in objects can learn enough Python to be productive in a weekend.
Going Everywhere With Python
The big change has been Google: their goal has been, and is, to supplant what we think of as the Operating System with what is essentially a Browser. The Google Netbook, running the Chrome (as in Browser) OS, on a reference hardware implementation, was released 3 days ago (2010/12/7). It has no hard drive. It is, they hope, the Microsoft Windows killer. It will have ( “will” because 3rd-party implementations of the hardware spec will arrive in the Q1-Q2 timeframe next year) Citrix and Terminal Services clients. At first, those clients will be needed to access Windows apps. But over time, the middleman always gets eliminated, elipsed. Over time, apps will be written to write to the Google App Engine, or equivalent, because there is no reason not to, and good reasons (TCO for The Enterprise) to do so.
There’s More, Of Course
There’s a lot more to the Python story, of course, but this blog entry has been about why not .Net, and why Python. I’ll dig into more details in the next blog entry or two in this series.