Friday, February 03, 2006
Why Eiffel?
Several years ago a computer magazine had a huge cover article titled: "C++: The Language Wars are Over!" The article that research into new programming languages was at an end. With the recent addition of templates, C++ was now the language for all purposes. Of course, a year or two later, Sun announced Java, and since then there's been a flurry of new languages, from PHP to C#, and development of new versions of older languages such as Perl 6.
The trend appears to be towards more dynamic languages with greater flexibility and an emphasis on components and tools. (I use Perl a lot, and I believe it would be a dead language if it weren't for the breadth and depth of the libraries and tools that support it.)
Why then, should someone be interested in a language like Eiffel, that seems to go against modern language trends? While the trend is towards dynamicism, Eiffel emphasizes static analysis of code. It's criticized as being too verbose, a "bondage and discipline" language with minimal features, and for lacking the components and libraries available to other languages.
Let me tell you what it is that I like about the language.
Readability. Unlike many programming languages, you can pronounce almost everything you see in an Eiffel program. Indeed, I've even written haiku that will compile in Eiffel (though it doesn't accomplish very much.)
What contributes to its readability goes beyond this aspect. Many choices of design add to the readability of Eiffel, even though they are seen as limitations when writing in it.
One example is the design choice of Single Entry, Single Exit. This means there is no goto, break or continue statement. Procedures and functions always enter at the top and exit at the bottom. The loop statement has only one form, and there's no way to short-circuit the logic to jump out of the middle.
With other languages, you have to very carefully parse what you see to make sure you understand the flow of control. It's much simpler to follow the flow in Eiffel, since what you see is what you always get.
Scalability. Eiffel is often criticized for being a verbose language. I think of it as being verbose in the small, but efficient in the large. Other languages may have a very terse way of expressing a loop, or of incrementing an integer, but because they don't handle multiple inheritance very well (if at all) or generics very well (if at all) expressing complex concepts and designs becomes very tedious and can require a lot of code. Java code has been notorious for being the language of "casts of thousands". Similar casting or type coersion is very rare in well-designed Eiffel.
In essence because of limitations imposed on the programmer by the language, non-Eiffel languages can much less efficient for expressing the architecture and design of a program. At the design and architecture level, Eiffel programs can be more expressive and can accomplish more, in fewer total lines of code, than can other languages.
The design concept doesn't even have to be very complex. Take a very simple function like
The trend appears to be towards more dynamic languages with greater flexibility and an emphasis on components and tools. (I use Perl a lot, and I believe it would be a dead language if it weren't for the breadth and depth of the libraries and tools that support it.)
Why then, should someone be interested in a language like Eiffel, that seems to go against modern language trends? While the trend is towards dynamicism, Eiffel emphasizes static analysis of code. It's criticized as being too verbose, a "bondage and discipline" language with minimal features, and for lacking the components and libraries available to other languages.
Let me tell you what it is that I like about the language.
Readability. Unlike many programming languages, you can pronounce almost everything you see in an Eiffel program. Indeed, I've even written haiku that will compile in Eiffel (though it doesn't accomplish very much.)
What contributes to its readability goes beyond this aspect. Many choices of design add to the readability of Eiffel, even though they are seen as limitations when writing in it.
One example is the design choice of Single Entry, Single Exit. This means there is no goto, break or continue statement. Procedures and functions always enter at the top and exit at the bottom. The loop statement has only one form, and there's no way to short-circuit the logic to jump out of the middle.
With other languages, you have to very carefully parse what you see to make sure you understand the flow of control. It's much simpler to follow the flow in Eiffel, since what you see is what you always get.
Scalability. Eiffel is often criticized for being a verbose language. I think of it as being verbose in the small, but efficient in the large. Other languages may have a very terse way of expressing a loop, or of incrementing an integer, but because they don't handle multiple inheritance very well (if at all) or generics very well (if at all) expressing complex concepts and designs becomes very tedious and can require a lot of code. Java code has been notorious for being the language of "casts of thousands". Similar casting or type coersion is very rare in well-designed Eiffel.
In essence because of limitations imposed on the programmer by the language, non-Eiffel languages can much less efficient for expressing the architecture and design of a program. At the design and architecture level, Eiffel programs can be more expressive and can accomplish more, in fewer total lines of code, than can other languages.
The design concept doesn't even have to be very complex. Take a very simple function like
max(a, b)
that takes two objects and returns the greater of the two. It's very easy to implement an efficient and typesafe max() function in Eiffel, but to do so in C++ takes significantly more code, and I'm not sure it's even possible to write a version that's typesafe.posted by greg c @ 06:36 
