Team Eiffel

Besides Eiffel, one of my favorite programming languages is Python. Python is an open-source, dynamically typed, object oriented interpreted programming language, which has become quite popular in the last years, and a significant community has formed around it.

As almost every community formed around a programming language, it has a set of design principles and way of solving development issues; this set of principles is directly related to the principles behind the language design and the facilities provided by the language. In the python community, a solution or piece of code conforming to these principles is said to be
"pythonic".

The Eiffel community is lucky to know the design principles supporting the language, thanks to the care that Dr. Meyer took in the "Object Oriented Software Construction" book to explain them and name them. Most Eiffel programmers can argue about the "eiffelishness" of some solution citing
named principles as "Open-Closed Principle", "Command/Query Separation", and several others. Other communities have not so clear notion of their guiding principles (for example, the Perl community has just a mantra "There is more than way to do it").

The Python community has no "official" list of principles like Eiffel has, but there is a list called "The Zen of Python" which is widely accepted as the list of "pythonic principles". It is even distributed with python, hidden like an easter-egg:

$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I wanted to introduce this list because a lot is shared in Eiffel, even when the languages have large differences. In some aspects I even believe that Eiffel is more pythonic than python itself. In later follow ups to this post I will take some of these items and look at them from an Eiffel perspective. There is a lot in common (so, I am not surprised that I like both languages a lot).