Optimally, there should always only be one way to do something. Or there
should be only one obvious way, which should be the best. And if you diverge from
that obvious way, it is "your gun, your foot, your choice".
But, sometimes there are just many ways to achieve the same goal. This is
when we have to step back and look at the options at our disposal, analyse
pros and cons of the different paths ahead, and develop insights and best
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.