pyARS - from python to ARS
##########################

=========================
Why Python Is Your Friend
=========================

Do you have concerns using a scripting language?
################################################

Many people, especially those who used to develop C programs to
talk to a Remedy server, confront us with their fears of slow or memory
hungry programs. In this document, I'd like to give you a couple of
reasons, why there is no need to fear Python :-).

So let me start by explaining, why we chose Python as preferred
language. Throughout this document, please bear in mind, that
we do not think, that one size fits all, or that Python is the hammer for
every nail out there. Having said that, however, we have not yet found a
problem in the ARSystem space that could not be solved this this hammer.

We came to Python from a very different angle, originally: We were
searching for a document management system, found ` <http://www.plone.org>`_,
which runs on ` <http://www.zope.org>`_ which is built in ` <http://www.python.org>`_. Exploring the python websites some more,
we found many interesting `projects <http://www.python.org/about/success/>`_ and stumbled across many useful libraries and tools.

But what we found the most interesting things about Python, are the
following:

- For us, the most important aspect is, that you can write your
scripts and applications in an interactive manner; using Python's shell, you
simply call one function (e.g. ARSystem API function), look at the
result and continue your next step from there. This makes life so much
easier than the traditional edit, compile, run, debug cycle. This is
especially true for short scripts that you quickly develop during your
daily life as a devloper or maintainer. Writing applications, we prefer
a decent design over trial and error, but still, quickly trying something
out in a very intuitive manner, is extremely helpful.

- Writing programs in python is extremely productive (and fun, btw).

- As the identation of the program code is part of the semantics, everybody
needs to adhere to the same style guide. Which results in a highly readable
code that anybody can read and understand, even months later.

Success Story
#############

Let me give you one success story from real life: we had a C program
monitor the status of the logged in users and update the information in a
Remedy form every 20 mins. This program had been in use for a couple of years,
the only complaint was that it would crash when you limited the search result.

When the company merged with another, user numbers exploded, and all
of a sudden this C program would take forever to complete: a single run
would take nearly 43 mins, and still it was run every 20 min.

The deeper analysis showed, that the runtime of the algorith would
grow with the square of the number of registered users.

When we rewrote this program in python, we:

- could reduce the algorithm very easily to be linear

- could reduce the runtime from 43 mins to 30 secs

- could reduce the code from 15 pages to 3 pages, making it much
more readable and maintainable

I hear your questions: could you not have done this in C as well?
Of course, you could have done it (at least addressing the first two
bullet points above). But who has this hashing library hanging
around that just comes naturally with Python? And then still, you would
have needed all the glue code that makes reading the code so hard.

Speed
#####

most often, people will ask us if the programs don't run
too slow? There are a couple of ways to answer this.
- One possible answer goes like this: We are talking about
tools and applications that have something to do with an ARSystem server in the
background that we want to talk to. Therefore, we have communication
between our application and the ARSystem server, most often across a network.
Thus, network latency, network bandwidth, network jitter and the ARSystem
response time usually play a much bigger role in determining your perceived
application performance than this little Python script on your computer. On top of that,
the python interpreter compiles your script into a bytecode on the first run,
that will be directly executed in following runs.

- The other way to answer this question: Granted, you cannot compare the
execution speed of python with that
of C. You give a little bit in terms of execution speed, but you gain
massively in term of developer productivity. However, if you have learned
enough about Python, you can develop with speed in mind and use data
structures and code fragments, that are directly implemented or mapped in C,
resulting in C similar performance (e.g. list and list comprehension).

- Yet another possible answer is, that speed concerns have been the main driver
for us to connect python to the C API directly and not go through other
layers in between.

- Another possible answer is: use the power to develop your software
quickly in python, optimize it, and if this still is not enough, resolve to
e.g. C and code your module as an extension that you call from within python.

- However you slice and dice this, there will always be people who
bring this performance issue as an excuse not to try something new. There
are enough pages on the web that deal with python and performance, that you
can consult should you really need it. And always beware of pre-mature
optimizations!