This site's content was compiled from 1993 to 2006. Beyond that, Google is your friend.
I originally posted this article to comp.lang.eiffel in the year 2000, and have lightly edited it for this presentation.
I don't claim that this is a particularly deep article, but it still gets mentioned now and again so I thought I'd give it a permanent home. -- Roger Browne
In a comp.lang.eiffel thread titled "ISE makes me cross", Oliver Austin wrote:
Admittedly ranting does little good, nor does poor quality software....!
You just have to give the software a while to bed itself in.
Don't laugh - this explanation was really given to me; not by ISE but by an IT manager - and there's a grain of truth in it...
It's 1988. Back then, I ran a business that dealt in Microsoft products as a sideline (before Microsoft was so big). We sold a copy of Excel 1.0 (running under Windows 2.0) to a customer who had previously been using Lotus 1-2-3.
The customer found a few bugs in Excel, and I took them up with Microsoft New Zealand, who were very helpful. The customer reported more and more bugs, but his IT Manager put a stop to this.
"I know it sounds crazy", he said, "but software has to be bedded in. Use it for a month, then report any bugs that are troubling you."
A month later, the customer was completely happy with his copy of Excel, and had no bugs to report. "I know it can't be", he said, "but it's as if the software has somehow bedded itself down and become bug-free as I've been using it."
Of course, without realizing it, the user had simply been using the parts of the software that worked well, and had not further explored the parts with which he was not making progress.
It's around 1994 or 1995, at Software Development Conference in London. ISE has booked a stand for two days, and as (then) UK reseller for ISE products, I came down to help Bertrand Meyer and Darcy Harrison run the stand.
ISE had recently released "ISE Personal Eiffel for Windows with Graphics". I knew (from feedback from my customers, and from personal experience) that this was a very buggy compiler. By comparison, it would make today's Eiffel products look like paragons of stability. I wondered what lay ahead as we attempted to demo this software.
ISE had hired a PC. Much to my amazement, Bertrand inserted the CD, installed ISE Eiffel, and proceeded to demonstrate it for two whole days without a single crash or even the slightest blip. I didn't dare touch the demo machine. The software might have bedded in for Bertrand, but it certainly hadn't for me.
At various times, I have reported bugs to ISE. The response is usually "We are aware of that problem, and have fixed it in the next release". And indeed, when the next release arrives, the problem has usually been fixed.
However, occasionally I have reported a problem and received a reply such as "This cannot be so. We use it every day ourselves, and it works perfectly". Clearly, the software had "bedded down" for someone at ISE.
I don't for one minute condone buggy software. Indeed, I have written newspaper articles disputing the oft-heard claim that "modern software is so complex that it is necessarily buggy".
When my business was an ISE dealer, I saw many people try the product, of whom the vast majority didn't use it for long, but a minority used it and loved it and became extremely devoted users.
Over the years, many people try ISE Eiffel. Most of them don't stick with it, and other technologies are "stealing the thunder".
But now it's the year 2000, and we find that over the years lots of people _have_ used ISE Eiffel very successfully for important projects. Sure, they delete EIFGEN and *.epr every now and then, but for the most part the compiler has successfully "bedded down" on their system.
It's 1948, and British-made motorcycles dominate the market. Sure, they break down a lot. Sure, you have to prime them before they will even start, and you have to maintain the cantankerous beasts just right.
But that won't put off a true motorcycle enthusiast.
It's 1984, and Japanese-made motorcycles dominate the market. They "just work!". Of course, there's still a dedicated band of enthusiasts who stick with British-made motorcycles.
It's 2003. One of the existing vendors (or is it a new entrant?) comes along with an Eiffel system that "just works", and sweeps the marketplace. Eiffel takes its rightful place amongst popular and successful languages.
By the way, none of this is really specific to ISE. Object Tools and Halstenbach have had similar problems (and their users also get used to deleting the project directory when things get scrambled). ISE Eiffel and Visual Eiffel did both eventually "bed down" for me, and I used them very happily and successfully for important projects. Although Halstenbach Eiffel did not "bed down" enough before my time-limited license ran out, it probably would have if I had used it for as long as I had used ISE Eiffel and Visual Eiffel.
So what's the purpose of this rambling post? Not a lot, except to introduce the concept of "bedding down" which I've not seen mentioned in the Journal of Software Parapsychology.
Now I'll try to give some encouragement to Oliver. (An Eiffel user needs a lot of encouragement when they can't get their compilation to finish for days on end. I know, I've been there done that and got the T-shirt.)
Oliver wrote:
Crashes when load ACE file when we press System icon to load it first of all.
I've had this too, and I don't know what causes it. I just delete EIFGEN, *.epr, and the ACE file, then start again. Yeah, it's a pain having to rebuild the ACE file, but it doesn't happen too often. Once I think it was caused by a stray control-S in the ACE file (sometimes eiffelbench doesn't interpret control-S as "save", but passes it to the editing window).
Regular segmentation faults at compile time.
I've had this too. It seems to be caused by some construct that the compiler cannot cope with. I usually go back to a recent backup from a time before it stopped compiling, then redo the work since then. Yeah, it's a pain having to do the same work twice, but it doesn't happen too often. Once I think it was caused by an expanded class; regular ISE Eiffel users soon learn that non-trivial expanded classes can be troublesome.
Having to delete Eifgen directory and/or restart the software to overcome errant compiler errors
I always delete the *.epr file whenever I delete EIFGEN. It's almost worth setting up a batch file to do this.
Unhelpful syntax error messages (although admittedly they're often quick to spot)
The "syntax error" message is unhelpful, but as you say it's usually easy enough to fix these. On the other hand, the validity error messages are really good, when combined with their clickability. For example, if you get an error that a called feature didn't have appropriate export status, within two clicks you can get to the line of the feature call OR the line of the export clause OR a number of other relevant pieces of code.
Those who use ISE may be able to add more to this list.
Sure, but what's the point?
Instead, let me say that as you use the product more and more, you will discover more things that you love, than things that you hate.
