Exploring The Philosophy Behind Application Frameworks
In the past, when I have undertaken an exploration of what programming toolsets I will use when I "grow up", I have always evaluated them on the merits of what they promise they will deliver. I saw this as a useful exercise a few years ago when I felt like I would soon have to make a choice between Microsoft's .NET, Sun's Java, or something else. What I decided I wanted to use was "something else". It's what I called the "PyLJAM" platform-- Python, Linux, Java, Apache, and MySQL. This is not too different from the "LAMP" model used for web application development-- Linux, Apache, MySQL, and PHP/Perl/Python. The major differences in my forumulation are the focus on Python as the best scripting language tool I know of, and the inclusion of Java as a heavier-duty framework to enable remoting and other capabilities not available in Python.
It was three years ago that I made that formulation, and since then, we have seen the evolution of these same tools. The thing is, there was no mass migration from Win32/COM to .NET, nor from Win32/COM to Java, or from Java to .NET. The IT world has not changed enough to demand that we need to overthrow our existing tools and adopt a new framework to deliver applications. The action in IT has been in the arenas of telephony (voice over IP and mobile networks) and the advance of some web technologies such as RSS to syndicate web site content. There are some cases where it made a lot of sense to migrate to .NET, for instance, among ASP 3.0 developers, but on the whole, a lot of developers kept using the same tools they had been using. I, myself, have kept using Visual Basic 6 and ASP 3.0 to develop desktop and web applications.
Since I first came up with the PyLJAM formulation in September 2002, according to Netcraft, the percentage of web sites hosted using the open source Apache web server went from 60 percent of all sites to about 70 percent of all sites today. Among active sites, Apache's share of installations has gone from about 66 percent to 70 percent. In that same period, the percentage of all sites running Microsoft's Internet Information Server (IIS) has declined from 29 percent to about 21 percent. Granted, the total number of sites has about doubled in that time period, so the total number of IIS installs has grown quite a bit. But the number of Apache installs has grown even faster. What this tells us about .NET is that it hasn't gained as much traction as Microsoft had hoped for. If I were developing just for the Internet, the PyLJAM platform might have served a consulting practice very well. So would ASP.NET/SQL Server/Windows Server. Of course, the total Netcraft statistics don't tell us much about the breakdown between IIS and Apache on the bigger commercial sites, but you can use netcraft.com to check out a number of large web sites, and you will find a lot of them are running Apache on Linux or Unix.
The reason that I bring up statistics on web hosting is because of the continued focus on web applications as the source of growth in the business of writing software. It is because of the complexity of writing desktop applications for Windows or other platforms that writing web applications looks that much more attractive. It goes back to the matter of application programming interfaces I discussed on my blog entry yesterday: there are different APIs for different programming languages and operating systems. Win32/COM is different from Java, which is different from .NET, which is different from Linux, and so on. Instead of being preoccupied with writing to the API for a particular platform, or learning the object model for a particular platform, it is a lot easier to write a web application for a web-based framework, in the language of one's choice, that is delivered over a browser. It is only if one is trying to write a server program, as I was trying to write a Winsock server in VB 6, that writing to the API becomes important or useful.
Most of the time, though, developers aren't trying to write server applications that need to access the hooks provided by the operating system. What they usually need to do is access libraries that are provided by the application framework they are programming with, or libraries that are associated with the framework. For instance, a PHP developer can call functions to access a MySQL database from within PHP, if support for MySQL is built in to his install of PHP (and invariably it is). The same thing for an ASP developer calling ADO or ADO.NET library functions to talk to SQL Server. We are relying on libraries that are part of the framework we are writing the application with, whether web or desktop apps. The operating system API only comes into the picture when you are missing something from the framework, and there is no other way to accomplish what you want to do.
So if one were to look for an application framework, what would you look for? I thought about this question last night before retiring, and here are the things I would look for:
- Highly Customizable User Interface
- Open APIs
- High Performance
- Memory Management/Garbage Collection
- Flexibility-- you can perform high and low-level tasks
- Good Support or Extensibility
- Marketability of Skills With this Framework
For the sake of argument, let's take a look first at LAMP, assuming Python is the "P" component. It is just like PyLJAM without Java, but I am removing Java in this exercise because J2EE is a framework that will be examined in the next blog entry. How does LAMP fulfill our requirements for an application framework?
Customizable UI. Python fills the bill pretty well. For graphical user interfaces, you can choose to use Python's native Tk implementation, Tkinter. Also available is the wxWindows port to Python called wxPython, which requires installing wxWindows. If you want to use a web-based UI, you can write CGI scripts in Python, too.
Open APIs. Python has open and fully documented modules. The interpreter can be built from C source code.
High Performance. Python uses more CPU time than other frameworks, but it uses less memory. This is from benchmarks done with applications running on Linux.
Garbage Collection. Python comes with garbage collection built in. There should be no need to write destructors or manage memory. Garbage collection is not instantaneous but it is reliable.
Flexibility You can do a lot with Python, from writing pure object-oriented code for your own class libraries to using the os module to do low-level system commands. Coding style can be strictly procedural to strictly object-oriented. Python is touted as an ideal prototyping language (see below).
Support/Extensibility. Python is well supported by its community through such sites as starship python, with many modules and extensions available. Jython converts Python to Java bytecode, and Python has both an extending interface for running C modules in Python, and an embedding interface for running Python code in C programs.
Marketablility. This is where Python falls really short in the commercial software business. The developer community doesn't translate into large numbers of jobs programming with Python in the US. Often it is seen as one of several tools for a Unix/Linux-oriented environment.
I originally wanted to title this blog entry "In Their Own Words". That really pertains to this last part of the entry, where I will paraphrase Mark Lutz, the author of Programming Python. In the last chapter of that book, he talks about an approach to programming using Python as a prototype or front end. He also says this about Python:
Python is really more than a language; it implies a development philosophy. The concepts of prototyping, rapid development, and hybrid applications certainly aren't new. But while the benefits of such development modes are widely recognized, there has been a lack of tools that make them practical without sacrificing programming power. This is one of the main gaps that Python's design fills: Python provides a simple but powerful rapid development language, along with the integration tools needed to apply it in realistic development environments.
Lutz describes Python as a legitimate RAD tool because it excels in providing an immediate turnaround (since there is no compiling or linking); it is "executable pseudocode"; it is a simplified implementation of object-oriented programming; and it promotes hybrid applications, allowing the developer to migrate modules to other languages (specifically C or C++) over time. After I read this last point in his book, the thought crossed my mind that Python could serve as the bridge to C and C++ programming, if I chose to take that route. Its "non-curly brace, non-semi-colon" syntax is a lot closer to VB, and its use of white space and indentation as block delimiters promotes good coding style.
In my opinion, Python has about everything we're looking for in a framework, except a large developer base in the US. There is now a mod_python for integrated support on the Apache web server, and it has well-tested libraries for accessing MySQL and other databases. Python runs on several platforms including Linux, Windows, Mac, and most flavors of Unix. Its performance may lag that of strongly-typed and compiled languages, but it makes up for it in extensibility and rapid application timeframes.
Comments