Could we use EiffelBuild for large project or should we restrict its use for prototyping?

Question

EiffelBuild is the ISE GUI-building graphical tool dedicated to Eiffel.

I try it and I find it very user-friendly, but I'm a little bit concerned about using such a tool for a large project. The use of a GUI-building tool could be restrictive.

Because Eiffel inheritance makes it very easy to create components, for the long term, it may be better to use our own specialized versions of the graphical objects that to use the standard ones.

Are you aware of any limitation of EiffelBuild that would justify to avoid its use for large projects.

Answer 1

I try it and I find it very user-friendly, but I'm a little bit concerned about using such a tool for a large project. The use of a GUI-building tool could be restrictive.

How is this "restrictive"? And how does the size of the project come into play?

If you mean that it's a code generator, and you don't understand the code that's coming out of it completely, then I agree completely. Code generation only works in those cases where you have writing the code by hand down cold, and the generator is giving you a lift by saving grunt work. You feel fully confident in modifying and maintaining the generated code in that case.

Because Eiffel inheritance makes it very easy to create components, for the long term, it may be better to use our own specialized versions of the graphical objects that to use the standard ones.

What is the specialization that you're adding? I'd think carefully about doing this, because it means writing, debugging, and maintaining a large class hierarchy in perpetuam. Be absolutely certain that the specialization is necessary, worth the cost, and unobtainable by any other means before you take this step. Make an honest effort to quantify the cost before you decide.

I'd vote for writing your own code generator once you've done enough hand coding using the library GUI classes. That's a solution that is sustainable, IMO.

UPDATE:

I learned Eiffel in a graduate program that decided in the middle 90s that it was the best object-oriented language available. At the time, C++ was pre-eminent but considered complex, Java hadn't made it out of Sun's labs, and C# wasn't even a glimmer in Anders' eye. The faculty at this establishment was enamoured with design by contract and the verneer of academic rigor it implied.

I've read Meyers' "Object Oriented Software Contruction". The first edition introduced DbC, and made Meyers something of a star in the object-oriented world. In my opinion, the second edition was a bloated thing that put an end to his ascent.

Honestly, if you're writing this large system for an employer, I'd counsel you to drop Eiffel and change over to a more mainstream language for their sake and yours. C# could be a good choice if you're on a Windows platform; use Java if you've got a heterogeneous environment or can't afford the Microsoft stack.

SO has all of four tagged questions about Eiffel. I think the volume says something. You might be right that popularity isn't always the best indicator of quality. I'm told that Beta was a better technical solution than VHS, but the fact is that it lost out in the marketplace and is nowhere to be found today. Same with Eiffel. I'd drop it if I were you.

UPDATE 2:

Very good - I couldn't tell from your original post what your experience with other languages was.

"High expectation of quality" implies that you believe Eiffel will support quality at the language level in a way that you can't duplicate with other languages. I would disagree with that. The quality of the code has more to do with the skill and practices of the developers than the language itself.

Design By Contract is entirely oversold, IMO. I've read that it's often turned off in production because it does represent a performance hit. If that's true for you, how else do you expect Eiffel to contribute to quality?

I'd make sure that the client you're writing this application for understands the full consequences that a decision to go with Eiffel will bring: limited pool of developers to maintain it, a staff that's marginalized by use of a dead language, etc. Be sure you don't oversell it because of a subjective wish.

Answer 2

I would restrict EiffelBuild use to prototyping. It's a nice tool, but in the long run it will get increasingly complicated to manage EiffelBuild projects (and this is true for most designers):

• New versions of estudio are released every 6 months, making it a burden to have to keep your EiffelBuild projects still working as expected from one version to the other, expect to have to deal with migrations every once in a while. Now all your Eiffel code will be subject to the same challenges, but with projects in EiffelBuild you will have to deal with both changes to the language AND EiffelBuild (and sometimes both at the same time...)
• If version N+1 and N are not compatible, you'll have to make a branch of your EiffelBuild projects to support both versions, be it only during the transition period
• It can be difficult to integrate several EiffelBuild projects
• Some graphical components could be difficult to reuse in EiffelBuild, such as a specialized chart component (ie set of classes...) for example, especially if that component isn't an EiffelBuild project itself
• I found it difficult to reuse parts made from one EiffelBuild application into another, whereas with fairly well designed components it's much less of an issue

Hope this helps.