Time for action choosing a server-side scripting language

When developing web applications, you have a virtually unlimited choice of programming languages you can use, so we have to consider what is important for us in our project and make a tradeoff if necessary.

  • Consider how important development time is compared to performance. Compiled languages like C# or C++ might be used if CPU power is scarce or if you do not want to distribute the source code in a readable format. But when development time is at a premium, using scripting languages often saves time as they make it easier to develop applications in an incremental way, even to the point where you can type in commands interactively to see what is possible and later incorporate these trials in your code.

    Performance is generally not an issue, especially when using scripting languages that are compiled to intermediate byte code, as is the case for languages like Python and Perl, for example. And while it is true that scripted languages are compiled each time they are run, this has a negligible effect when the program is a long running web application.

  • Weigh the importance of debugging. Interpreted languages are often simpler to debug as compiled languages, both because the debugger has access to more information that you may explore interactively if something breaks and because you can try out any modules you have written by interactively calling functions to see what happens.
  • Think beyond the project. Once implemented and deployed, your application might have a long and happy life, but that inevitably means that there will be requests for smaller or larger changes and choosing a suitable language can help to reduce the maintenance effort. Compared to compiled languages that in general have quite low-level instructions and language constructs, interpreted languages have (very) high level constructs that make for condensed code that packs a lot of meaning in a few statements. That is not only easier to read but also faster to interpret and in the end these high level constructs, once interpreted, run at (almost) compiled speed making the performance difference sometimes hard to spot. More meaning and less code do make for easier reading and this is a huge benefit when maintaining code.

In the end, the choice for the language to implement the web application is at least in part a matter of taste, but in this book we opt for Python as it offers an optimal tradeoff between the different considerations.

What just happened?

Now that we have chosen Python as our server-side scripting language, let's have a good look at the arguments:

  • Python is easy to read and therefore easy to learn and maintain. Although Python is relatively unique among programming languages in treating whitespace as meaningful in many places, this does enhance readability quite a lot.
  • Python is a very high level language, incorporating concepts like list comprehension and functional programming. This allows for compact programs that pack a lot of functionality in little code, enhancing readability and reducing maintenance.
  • Python comes "batteries included". Python is distributed with a vast amount of well designed and well maintained libraries (modules) that provide anything from access to .csv files and parsing XML, to building an HTTP server with a handful of code and these modules are at least as well documented as the language itself. This all means we can cut down on development time as in many cases we do not have to reinvent the wheel ourselves.
  • Python has many third party modules. Even if a module is not included with the distribution, chances are somebody has written just the module you are looking for.
  • Python is an object-oriented language. This is widely regarded as a good thing as it aids in data abstraction but its main attraction to people developing database-driven applications is that it allows for a natural way of mapping tables to types (classes). Records in a table of cars can be mapped to a 'Car' class and instances of this class can then be manipulated in much the same way as native classes like strings or lists. This again makes it easier to read the code and therefore maintain the code.
  • Python is available on many cloud platforms. To run a Python program on the server, you need Python deployed on that server. If you have full access, this might not be an issue and indeed hosting companies provide (virtual) machines with Python already installed but for very lightweight cloud platforms like Google Gears, your choice of available languages might be limited. However, Python (together with Java) is fully supported by Google Gears and although this is not a consideration for the example applications in this book, it might be for your applications.

The version of Python we use in this book is version 3 (version 3.2 at the time of writing). Although not all third party modules are (yet) ported to this new version, it is the best version to use if you want to develop in a future proof way.

Note

Python's multi-threading capabilities at the moment do not allow for optimal usage of multi-core processors. Most implementations of Python do not allow running separate threads truly in parallel. This is by far not as bad as you may think though, as this restriction is mainly valid for interpreted python code, not necessarily for code running in, for example, the OS kernel. And because in a web server a lot of time is spent waiting for packets to be sent or received over the network, this mostly does not affect the performance of your Python code. In the future, the multi-threading implementation of Python may change, but this is a hotly debated subject. More on this subject can be found by searching for "Python 3 GIL".

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.48.204