Friday, February 01, 2008

Python 3.0 Compatability

I just tried out a beta version of Python 3.0. It looks pretty good so far. I read on Slashdot how it isn't backward compatible, so I figured I'd give it a spin.

I tried a 200 line script I had built with 2.3.4, and the results weren't all that bad, really. don't get me wrong, some work is required to get code to work in 3.0, but I think some people are getting a little too worked up about this.

Minor problems I experienced:

1. It complained a number times about my indentation, namely the mixing of spaces and tabs. This isn't a big deal, because this is a thing that has been long known as being an issue within the development community. Python was just less strict about it in the past.

2. The "print" statement has been changed to be a method (ie. print()). This requires the changing of some code. But then again, a well-designed project shouldn't have print statements liberally scattered all over the place anyways.

3. I've noticed that the way floating point results are presented (in relation to division operations) has changed. Some printed results that formerly were nicely rounded to two decimal points, now have 10 digits to the right of the decimal point.

I also tried running some other code, and I found in my anagram generator that some code related to maps and lambdas isn't working anymore. A good guide to evaluating what changes are present in 3.0 is this.

That's it! I'm pretty impressed. I had low expectations because of all the people potificating over this. But the result is pretty good.

Sure, these issues will be compounded on a big project, but I don't think this is nearly as bad as it sounds. With good development tools, the cost of these changes can be minimized.

My advise is still conservative: If you have a somewhat larger project (over 1000 lines), just stick with 2.x, as it will still be maintained. However, if your project is smaller, or if you are starting a new project, I'd consider using 3.0 instead (once a stable version is released, of course, which should happen towards the end of 2008)

All you Python developers out there, have you made any attempts to run code in 3.0 beta?

Labels: , ,

Tuesday, May 15, 2007

The Ideals of Open Source

Increasingly, the "Open Source Software" movement is proving to house some of the best software projects. Increasingly, open source software is proving to be superior to proprietary alternatives. This new philosophy regarding software licensing is proving not only to be appeal, but also wildly successful.

As open source software becomes more common, the general public's conception of what it is remains murky. Many people think that "showing the source" is the essence of what open source is. That is not true. Microsoft has been "showing the source" for a long time, if you sign draconian contracts that prevent you from doing anything useful with it, that is. The key concept of open source software is not the availability of the source, per-say, but rather the TERMS on which the source is made available. It is really built on the "hacker ethic" (not "hacker" in the bad sense) mixed with FSF's idea of "copyleft" (a novel idea in which copyright protects the user not just the vendor).

While various projects reach the ideals of the open source model with varying degrees of consistency, the basic practical, logistical, and philosophical ideas involved are these:

- The internals (source code) of programs should be available to everyone. And not only available, but "tinkerable" in the event that a user wants to modify it. The "tinkerable" part of this is critical because seeing source code without being able to use it, while perhaps being slightly educational, is counterproductive.
- Software should be "free" (perhaps as in "free beer", but most certainly as in "free speech").
- Copyrights should not be one-sided. They should protect both the vendor and the user. The vendor to user relationship ought not be us-verses-them. The activities of vendors can be very useful to users. And the activities of users can be very useful to vendors. There ought to be cooperation. Instead of initiating an antagonist relationship of mistrust, there is a middle ground where one can glide successfully. The vendor should be able to find ways to make money without seeking to subvert their users. Success in software should not be defined as crippling and locking in the user, but rather in empowering them.
- Competition, derivation, and distribution ultimately work for the good of the whole. To spend a good part of ones existence trying to stamp out these things is frustrating and will ultimately be futile. Rather, we seek ways to piggy-back others innovations while giving back to the community to further push forward innovation.
- A sort of "tempered anarchy" can be a very successful model in growing complex software products.

The forces that are fighting against the open source movement have their reasons. They are trying to protect their bottom line, their cash cow. However, they must see that their days are numbered. If your only way to make money is by threats, limiting what others can do, etc., you are on the slippery rope to obscurity. The open source movement may seem anarchic and revolutionary. To some degree, it is. Sort of like desegregation, the end of slavery, the Protestant Reformation, or the American Revolution. I guess that puts it in good company of social upheavals.

The basic foundation of open source is something that has been part of our society as long as history has been recorded. It is something we has humans intuitively know, but "unlearn" because we think that is the only way we can make money. However, there is much money to be made in an open source landscape. It is not communism, but rather the "free market" at its best. It is the best way to foster innovation and work towards a non-monopolized win-win situation.

If I would concur with the nay-sayers that the success of open source solutions will shrink the amount of money out there in software development and cause things to go haywire (of which I am totally not convinced), I as a programmer can rejoice. Why? Because I want a *good* profession, not just a successful one. If there is no money in programming for the good of others (with no crippling licenses), then perhaps its better if the art of software development rest in the halls of irrelevance. If software is limited either a commodity bartered in the hands of a few elite companies or not a workable proposition at all, I'd rather it go away, permanently. However, I'm inclined to believe that the open source and/or free software ideals put forward by bright minds such as Bruce Perens, Eric Raymond, Richard Stallman, Linus Torvalds, etc. are actually workable--both in principle and in practice (over the last 10 or 15 years).

Labels: , ,

Saturday, August 19, 2006

Remembering Pascal

For those of you who don't know, today is the day that philosopher and mathemetician Blaise Pascal died. On this day in 1662, the great genius died. When I say "Remembering Pascal", two things come to mind: Pascal as an individual, and Pascal as a programming language named after him.

As a programmer, my earlier years were mainly spent working with the Pascal language, usually working in the Borland Pascal environment. Pascal was really a good match for me at that time. I was good enough to be somewhat stiffled and insulted by the simplicity and occasional absurdities of the Basic language. However, I wasn't nearly knowledgable enough to master C or Assembly. So, Pascal seemed to be an obvious choice: it was simple enough for me to learn easily, but at the same time it was complex enough for me to see it as a useful tool. Now I probably wouldn't touch Pascal with a 10 foot pole, but I still have some fond memories of it and I believe it helped me learn how to program.

Moving along to Pascal the person, there is much to be remembered. He certainly didn't live very long, maybe at most 40 or so years? He made a lot of contributions, especially to natural sciences, probability, and study of fluids. His name has been attached to a theorem, a programming language, and a unit of measurement.

This is not intended to be a biography, but I would like to list some other interesting things about Pascal that you may have not known:


  • Before Pascal turned 13 he had proven the 32-nd proposition of Euclid and discovered an error in Rene Descartes geometry.

  • He wrote letters against the Jesuits

  • He claims to have had a mystical vision

  • He wrote criticizing the prevailing ethical philosopies of his day

  • He used a lot of satire in his writings

  • He died of a brain hemorrhage

Labels: , , ,

Tuesday, December 20, 2005

Python Programming Conference

I just found a nice collection of audio files from conferences dedicated to the Python programming language. Very cool!

Take a look here.

Labels: , ,