Perhaps I have just been exposed to too much Python in the recent months. But somehow, I feel like I have to express the qualities that I expect from a good programming language. Eiffel has these, most others don't.
Programs have to be easier to read than write: Code not only communicates a solution from a programmer to a computer.
Designing a programming language is an difficult task. During my time in academia, I had the great pleasure to meet some language designers. Listening to their stories is highly educating. Things that look simple or arbitrary at first become deep insights into the way humans understand problems and model solutions. There is nothing trivial in deciding names of keywords or punctuation.
The search for a type-safe version of Eiffel is a never-ending story in the development of the Eiffel language. Recently, Helmuth Brandl has created a series of blog entries with a nice description of is needed to make Eiffel type-safe. There have been others posting blog entries (including me) and it also had been a constant topic during the ECMA process of Eiffel standardization.
Interestingly, a question that was seldom raised was: why do we need type-safety? As absurd as it seems for all the mathematicians to raise this question, the Eiffel community has understood for a long time that mathematical soundness is not a reason in itself. Instead, it serves a purpose in the enterprise of language design: giving software developers means to express themselves in ways that reduce the number of defects in his/her programs and enable him/her to master complex problems he/she would not be able to master without.
In a previous blog entry, I related how I modified my code to split classes in two parts, separating commands and queries. In the conclusion I was suggesting that Eiffel could be extended to provide support for this. I will now formalize the language extension, and demonstrate how to use it to write even more solid code.