Friday, February 09, 2007
Roger F. Osmond on Eiffel
A post from Roger F. Osmond on Why Eiffel deserves a wider audience than the ISE mailing list. It is copied verbatim below.
It is important to consider the tools, certainly, but we must also consider the whole process. I believe this is your point, in fact. In my experience, the best big-think benefit of using Eiffel as a tool, is that it's more than a tool. I have been responsible for some pretty big projects over the years and I have learned that Eiffel pays dividends beyond the initial phases of product development. With the Eiffel approach (and yes, the Eiffel tools), the real-world model you develop (the one in your head and on the white board) translates into Eiffel implementation without the semantic chasm that is inherent in all other mainstream approaches.
As good a tool as java is for slapping together something from parts (face it folks, it's popular for a reason), a huge problem with using it for anything non-trivial is in that the implementation doesn't reflect the real-world model. Even die-hard java folks will admit this (after some friendly persusion, possibly aided by beverage of choice).
The up-front sales pitch for using Eiffel includes all the quality arguments, the reuse and such, but the clincher for me is the fact that the product you build, all the way down to the feature signatures, reflects faithfully the problem you tried to solve in the first place. This is more than an academic nicety. It translates into real life benefits for your organization. It means that when the requirements or the problem change, you know where to go to make the changes in your design and code (they're the same thing in Eiffel of course). When there is an error in the code (a semantic error), you will know where and why because the product as implemented doesn't accurately reflect the solution you modeled, and you'll know what to do.
With every other tool/language that I have used, this just isn't the case. The best organizations might have some documentation to map the gap, so to speak, but you know full well that this documentation, by being out-of-band, is by defintion out-of-date by the time it is written. Eiffel well written really does give you what you need to sustain your product and your organization, better than the other tools available.
This is not to say that the other tools are without merit. Entity relationship diagrams, state machines and even DFDs all have a place, but they are not, nor can they ever be the in-band toolset that Eiffel is.
As for BON itself, it's a good notation, but it's still just a notation. I have found that using a subset of it (pretty much the bubbles and arrows) to describe relationships is very effective and requires no learning time. DFD folks might have trouble with the arrow direction at first, but that oinly lasts for a few minutes. If you're thinking in an object way, then it works very well.
In practice, I (almost) never go from diagram-to-code in estudio. I go the other way around, when using a computer at least. My design work is invariably done using a kind or BON-light and a whiteboard. This is true for every Eiffel practiioner with whom I have worked. It's whiteboard to code and back.
Having the diagramming built into estudio is a nice thing sometimes. When teaching beginners, I will use the class construction facility in estudio, but the rest of the time, I simply write the class in my (external) text editor. I take the same approach when building user interfaces, in Eiffel Vision or in HTML/js/java or whatever. I find that the graphical tools (the grunt-and-point interfaces) are great until you're comfortable, and then they get in the way. It's important to have such tools for ramp-up, but you and the problems you are trying to solve will quickly outgrow them.
Apart from maybe being ridiculed by the ignorantia, you will never regret moving to Eiffel. Even if you must work in other languages, your Eiffel experience will stay with you. It will make you a better programmer and a better designer. Let's face it, you will be a better person, and even your hair will take on a healthy sheen (OK, that was a little over the top). You will, however, never be content using other language tools again, so consider this fair warning (really). A good friend of mine once confided "How am I supposed to work with these other tools now that I have known Eiffel. I don't want to go back." He was quite serious. The cold truth is that you will have to use non-Eiffel, maybe most of the time. It can be frustrating, but that's why they pay you the big bucks. Despite this inevitable lament, it's worth it. It's like finally getting an eyeglass prescription that really works. Sure, you could get around OK before, but now, you can really see! Eiffel's like that.
It is important to consider the tools, certainly, but we must also consider the whole process. I believe this is your point, in fact. In my experience, the best big-think benefit of using Eiffel as a tool, is that it's more than a tool. I have been responsible for some pretty big projects over the years and I have learned that Eiffel pays dividends beyond the initial phases of product development. With the Eiffel approach (and yes, the Eiffel tools), the real-world model you develop (the one in your head and on the white board) translates into Eiffel implementation without the semantic chasm that is inherent in all other mainstream approaches.
As good a tool as java is for slapping together something from parts (face it folks, it's popular for a reason), a huge problem with using it for anything non-trivial is in that the implementation doesn't reflect the real-world model. Even die-hard java folks will admit this (after some friendly persusion, possibly aided by beverage of choice).
The up-front sales pitch for using Eiffel includes all the quality arguments, the reuse and such, but the clincher for me is the fact that the product you build, all the way down to the feature signatures, reflects faithfully the problem you tried to solve in the first place. This is more than an academic nicety. It translates into real life benefits for your organization. It means that when the requirements or the problem change, you know where to go to make the changes in your design and code (they're the same thing in Eiffel of course). When there is an error in the code (a semantic error), you will know where and why because the product as implemented doesn't accurately reflect the solution you modeled, and you'll know what to do.
With every other tool/language that I have used, this just isn't the case. The best organizations might have some documentation to map the gap, so to speak, but you know full well that this documentation, by being out-of-band, is by defintion out-of-date by the time it is written. Eiffel well written really does give you what you need to sustain your product and your organization, better than the other tools available.
This is not to say that the other tools are without merit. Entity relationship diagrams, state machines and even DFDs all have a place, but they are not, nor can they ever be the in-band toolset that Eiffel is.
As for BON itself, it's a good notation, but it's still just a notation. I have found that using a subset of it (pretty much the bubbles and arrows) to describe relationships is very effective and requires no learning time. DFD folks might have trouble with the arrow direction at first, but that oinly lasts for a few minutes. If you're thinking in an object way, then it works very well.
In practice, I (almost) never go from diagram-to-code in estudio. I go the other way around, when using a computer at least. My design work is invariably done using a kind or BON-light and a whiteboard. This is true for every Eiffel practiioner with whom I have worked. It's whiteboard to code and back.
Having the diagramming built into estudio is a nice thing sometimes. When teaching beginners, I will use the class construction facility in estudio, but the rest of the time, I simply write the class in my (external) text editor. I take the same approach when building user interfaces, in Eiffel Vision or in HTML/js/java or whatever. I find that the graphical tools (the grunt-and-point interfaces) are great until you're comfortable, and then they get in the way. It's important to have such tools for ramp-up, but you and the problems you are trying to solve will quickly outgrow them.
Apart from maybe being ridiculed by the ignorantia, you will never regret moving to Eiffel. Even if you must work in other languages, your Eiffel experience will stay with you. It will make you a better programmer and a better designer. Let's face it, you will be a better person, and even your hair will take on a healthy sheen (OK, that was a little over the top). You will, however, never be content using other language tools again, so consider this fair warning (really). A good friend of mine once confided "How am I supposed to work with these other tools now that I have known Eiffel. I don't want to go back." He was quite serious. The cold truth is that you will have to use non-Eiffel, maybe most of the time. It can be frustrating, but that's why they pay you the big bucks. Despite this inevitable lament, it's worth it. It's like finally getting an eyeglass prescription that really works. Sure, you could get around OK before, but now, you can really see! Eiffel's like that.
posted by Berend de Boer @ 00:14 
Comments:
<< Home
An excellent article that very nearly matches my experiences in academia and industry.
The core concepts of the Eiffel method are easily applied to languages and platforms other than Eiffel. I have successfully taught classes in several languages using OOSC2 and Walden and Nerson.
Core ideas like command/query separation and the open/closed principle are easy to understand, lead to better software designs, and students adopt the practices throughout their careers.
While I have occasionally taught with Eiffel, these days I mostly use Java with JML, though this term I am also using Smalltalk (Squeak) and BASIC---using the same principles!
-Joe Kiniry
Post a Comment
The core concepts of the Eiffel method are easily applied to languages and platforms other than Eiffel. I have successfully taught classes in several languages using OOSC2 and Walden and Nerson.
Core ideas like command/query separation and the open/closed principle are easy to understand, lead to better software designs, and students adopt the practices throughout their careers.
While I have occasionally taught with Eiffel, these days I mostly use Java with JML, though this term I am also using Smalltalk (Squeak) and BASIC---using the same principles!
-Joe Kiniry
<< Home
