Posts Tagged 'webservices'

Starting Python Again

After almost a three year break, I am starting to write some Python code again. I am experimenting on developing a RESTful part catalog web service. I last used Python when it was in version 1.5.2. I think that there have been many changes, because the page holding version 1.5.2 states quite frankly:

Do yourself a favor and get a more recent version!

Fair enough. I picked up version 2.5.1 for Windows. The install was quite painless. The most improved thing that I noticed was the revamped web site. There is a lot more information now. I find this quite refreshing. I should have no trouble picking it up again.

So, why did I pick Python? Well, it was a tough decision. For the most part, Python was the right tool for this job. It was a written in a language that I am somewhat familiar with, it is portable, and gave the flexibility that I needed. I love other languages, but I found that the others did not quite fit the mold. For example:

  • I rejected Java right away because Java would take a lot more time that C/C++ in my case. The language is certainly as good as C#, but I am not as familiar with it as Python or C/C++. Additionally, the core framework is significantly larger than I remember. Like Python, Java has added features since inception. I have not touched Java in about eight years, so my learning curve will be very high. Today, there seems to be a lot better tools and frameworks to have ease the development pains, but it is not enough for me to give Java consideration.
  • I use C# and ASP.NET for my day job, so why did I not pick them? Frankly, it is damn tough to make a truly RESTful web service in ASP.NET. ASP.NET likes SOAP web services. Forcing ASP.NET to do a RESTful web service is like fitting a square peg in a round hole while having a root canal. In retrospect, it’s a blessing in disguise to me, because I prefer to use open source tools anyway. I do not want to give the impression of bias. I honestly did try to make it happen fairly recently. It was just not meant to be. Again, the tool was not right for this job.
  • C/C++ requires more investment in time. I have been programming in C family for years. I love it for it’s speed of execution and it is right against the metal. If I was creating Unix tools where execution speed is critical, C/C++ will be my absolute first choice. However, the compile cycles and the debugging become a deal killer for a web prototype. When I am rapid prototyping, I have a need for development speed, rather than saving a few cycles. Like many other high-level languages, Python still gives me many options to integrate and optimize using C/C++. So, if I need it, I will use this feature.
  • What about Lisp? I’ve coded a lot of Lisp for other applications and experiments. I have been writing a lot about Lisp in this blog. It was my second language that I learned.  So, it would be natural for me to just use Lisp, right? Well, not in this case.  Most likely, the code for this experiment will be sent to other developers.  They are more likely to be receptive to Python than Lisp.  There I said it.  I still believe that Lisp is the best language out there. But, being the best language is not the only reason to use it. Sometimes, you need to give in for the greater good.
  • Ruby and it’s poster child framework, Ruby on Rails, came a very close second. I said that my choice in Python was a tough decision. I like the Rails framework.  Rails is very RESTful.  I was blown away when I first encountered it.  The framework make development easy.  So, why did Python win?  Again, I am more familiar with Python than Ruby…and that is it. Python has a similar framework to Rails, called TurboGears. I give props to the Ruby clan to developing a great framework. It is so innovative that many languages have came up with clones.  So, it boils down to language familiarity.  Python won by a nose.

So, there you have it.  I picked Python for this project.  Hopefully, it won’t let me down. I’ll try to keep regular updates for everyone who is interested.