How Effective is Design by Contract?
Kevin McFarlane
remember reading an article about a framework, called BetterC, which employs
DbC.
http://www-scf.usc.edu/~moissetd/betterc/
The author claimed not that he produced bug-free code with his framework but
that pretty much any bug uncovered resulted in a contract violation.
Some have said in this forum that EiffelStudio has had a buggy reputation in
the past. Why is this? Is it because the software is so complex that it is
just impractical to test a sufficient number of pathways through the code?
It would be interesting to know what proportion of these bugs are
subsequently exposed as contract violations when full DbC is enabled.
Kevin
Friedrich Dominicus
> i.e., in practice, what percentage of bugs are caught by contacts? I
> remember reading an article about a framework, called BetterC, which employs
> DbC.
>
> http://www-scf.usc.edu/~moissetd/betterc/
>
> The author claimed not that he produced bug-free code with his framework but
> that pretty much any bug uncovered resulted in a contract violation.
Well how do you expext logical errors to show up?
>
> Some have said in this forum that EiffelStudio has had a buggy reputation in
> the past. Why is this?
Well you better ask this ISE. They know their customers, I'm just one
of those.
Search for Roger Brownes settling in. EiffelStudio still is a new
product. Before the .NET hype there were Eiffels available. And there
still are ISE Eiffel has two major drawbacks. The first was from
Version 2.3 to 3.x. Eiffel has changed more between those two versions
than ever after IMO. The User Interface was not done as the usual IDEs
you had to relearn a lot of things, this has not suited all too much I
guess. Now with EiffelStudio this step was more or less taken back
It's not happy-happy-click-me-and-forget-the-rest... I guess it suits
more people now, but I have ot admit I do have liked the old
handling.
The software which probably has done more harm to ISE than others is
ecase. But I doubt that many have used it. It was told me that there
have been customers just because of ecase, which is a bit hard to
believe for me. I would say they have used Eiffel *despite* ecase ;-(
> Is it because the software is so complex that it is
> just impractical to test a sufficient number of pathways through the
>code?
Sheer mass of code with too few developers maybe?
> It would be interesting to know what proportion of these bugs are
> subsequently exposed as contract violations when full DbC is
>enabled.
DBC will not help if your bug is on the C side. And probably that is
the greatees weakness of ISE-Eiffel, very much code is written in
C. Even code which one could easily written in Eiffel. Writing
Eiffel/C is not difficult but gets difficult if you have to look that
things are not GCd too early. I suggest you check out the
interface Eiffel/C and just look at how memory handling is supposed to
work.
Another thing which I think has been problematic, is that they rewrite
things completly (not in the Base library but in the GUI section
e.g.). And well the forget to provide any decent documentation for
that software. Well you had to figure out way too much for those
things, some assumptions probably have turned out to be wrong. Well
than it's a bug....
Another probably neglected syndrome was NIH. (not invented here). Will
say it seems that they have re-invented some wheels just because they
thought they had to, add that to the sheer amount of code and you'll
get an idea.
Eiffel is a tool for software development, but software development is
way more than spitting out code. Every project can fail if it's not
well managed (I know from my own learning experience), there are so
many things which can lead to havoc. Programmers do not like each
other, they do not share ideas and thoughts. Development is not
goal-oriented with sub-goals defined and checkable etc etc. You'll
find more than one book about what things all could go wrong.
Well I can tell you they all are right. Management is the biggest
problem. I know I've managed a now put besides product (which
sort-of-works, but lacks much of the functionality it was supposed to
have, the most amazing thing I can say about it is that the things
which have been implemented have worked. I would argue this is while
we have used DBC intensivly). Well I know whom to blame, myself. But Eiffel simply has worked
(with some glitches) but that was not really the problem. I guess
there are some other out there with the same experience. Could it be
that the Eiffel development managment was not up-to-date?
I can see some hints which suggest that this has been the case. I bet
they started as enthusiastic than we did but have not keeped an open
eye on what they undertake. Than after x years of lateness, they
though (probably correctly) that they had to deliver. Well the
software was not ready to that time. But they thought it was.
Well I hope this message give you some food for thought and be a bit
more careful nexttime about things "one has heard".
Regards
Friedrich
Kevin McFarlane
"Friedrich Dominicus" <fr...@q-software-solutions.com> wrote in message
news:87smz8h...@fbigm.here...
> "Kevin McFarlane" <ke...@atech.globalnet.co.uk> writes:
>
> > i.e., in practice, what percentage of bugs are caught by contacts? I
> > remember reading an article about a framework, called BetterC, which
employs
> > DbC.
> >
> > http://www-scf.usc.edu/~moissetd/betterc/
> >
> > The author claimed not that he produced bug-free code with his framework
but
> > that pretty much any bug uncovered resulted in a contract violation.
> Well how do you expext logical errors to show up?
You misunderstood me here. Perhaps I did not express myself clearly enough.
What I meant was how many bugs are uncovered for which contracts have not
previously been written?
[snip]
> > Is it because the software is so complex that it is
> > just impractical to test a sufficient number of pathways through the
> >code?
> Sheer mass of code with too few developers maybe?
That's what I expect.
>
> > It would be interesting to know what proportion of these bugs are
> > subsequently exposed as contract violations when full DbC is
> >enabled.
> DBC will not help if your bug is on the C side. And probably that is
> the greatees weakness of ISE-Eiffel, very much code is written in
> C.
Ah, now I was told in the past by someone commenting on the bugginess of the
software that it was written in Eiffel.
> Even code which one could easily written in Eiffel. Writing
> Eiffel/C is not difficult but gets difficult if you have to look that
> things are not GCd too early. I suggest you check out the
> interface Eiffel/C and just look at how memory handling is supposed to
> work.
I don't actually program in Eiffel. I'm just interested in the ideas.
[snip]
> Programmers do not like each
> other, they do not share ideas and thoughts.
We all seem to be nervous about letting other developers look at our code!
This might be because whenever we have to maintain code (usually after the
original author has left) we spend most of our time cursing and swearing
about how badly written it seems to be! This is not necessarily the case but
it often seems that way until we understand what's going on. So we're
frightened about our own code receiving similar treatment.
[snip]
> Well I hope this message give you some food for thought and be a bit
> more careful nexttime about things "one has heard".
>
> Regards
> Friedrich
I wasn't intending to knock anyone. I was just curious.
Kevin
Berend de Boer
> i.e., in practice, what percentage of bugs are caught by contacts? I
> remember reading an article about a framework, called BetterC, which employs
> DbC.
>
> http://www-scf.usc.edu/~moissetd/betterc/
>
> The author claimed not that he produced bug-free code with his framework but
> that pretty much any bug uncovered resulted in a contract violation.
I very much doubt it. Take for example SmartEiffel's recent effort to
provide a 64 bit integer. As SmartEiffel generates C code, I think they
output something as long long. However, not all C compilers accept this.
You don't detect this error, unless you actually try to compile the
generated C code.
Is this a contract bug? It's more a question of things you don't know.
Large parts of software making is learning about something.
> Some have said in this forum that EiffelStudio has had a buggy reputation in
> the past. Why is this? Is it because the software is so complex that it is
> just impractical to test a sufficient number of pathways through the code?
I suppose so. The problem is of course in the specification of the
dialog box: it's to low level. If you try to catch all behaviour at the
when this happens, do that, if'll cost you loads of time to debug that
into correctness. Unfortunately, we don't have something for that.
For GUIs like that (whether EiffelStudio, Delphi or VB), the number of
users (or beta-testers) determines how solid it appears. As Eiffel IDEs
have less users than the other tools, you sometimes get the feeling you
are the first user of a product. And that might be the case, because
you're following a pathway nobody had done before.
> It would be interesting to know what proportion of these bugs are
> subsequently exposed as contract violations when full DbC is enabled.
Not many. It would if the GUI was written in a radically different way,
such that DbC really would expose the bugs. But currently I've no idea
how to express such a GUI.
But despise these remarks, I think nobody who ever has tasted real DbC
like Eiffel can give you, would want to do without!
Regards,
Berend. (-:
Vincent Bousquet
That is to say when I do not use class the way they are meant to.
This covers most of the bugs I encounter.
The second type of bugs are design / algorithm bugs.
Design bugs are less frequent in Eiffel, since the language enforce some
design principles.
Algorithm bugs are just as frequent as they used to be.
Anyway, I did not participate in a project as big as EiffelStudio.
I think that a big project always need a test suite (like getest) for going
through most of its possibilities automatically and performing non
regression test. The fact is that you can still leave holes...
I think you should try Eiffel. I used to porogram C/C++ for years and I've
been trying Eiffel for a year now. I can't imagine going back to C/C++ !
Regards
Vincent Bousquet
"Kevin McFarlane" <ke...@atech.globalnet.co.uk> a écrit dans le message de
news: cuWcnYXQKoN...@News.GigaNews.Com...
Friedrich Dominicus
>
> You misunderstood me here. Perhaps I did not express myself clearly enough.
> What I meant was how many bugs are uncovered for which contracts have not
> previously been written?
Depends on you as a programmer.
> > > It would be interesting to know what proportion of these bugs are
> > > subsequently exposed as contract violations when full DbC is
> > >enabled.
> > DBC will not help if your bug is on the C side. And probably that is
> > the greatees weakness of ISE-Eiffel, very much code is written in
> > C.
>
> Ah, now I was told in the past by someone commenting on the bugginess of the
> software that it was written in Eiffel.
Well I again can just suggest you check out the Base libraries from
ISE. Than see how much Eiffel code is really a wrapper around some C
>
> > Even code which one could easily written in Eiffel. Writing
> > Eiffel/C is not difficult but gets difficult if you have to look that
> > things are not GCd too early. I suggest you check out the
> > interface Eiffel/C and just look at how memory handling is supposed to
> > work.
>
> I don't actually program in Eiffel. I'm just interested in the
>ideas.
Well, why don't you try it out yourself? Ideas in progrmaming
languages by reading what other write is af if I told you how swimming
works, without practicing it won't be helpful. You can dicusss some
things which you actually do not do. But I don't think programming
falls under that category.
>
> [snip]
> > Programmers do not like each
> > other, they do not share ideas and thoughts.
>
> We all seem to be nervous about letting other developers look at our
>code!
Well I do not know why you say. If I wrote something I always ask
others on what they think about it. Now I do not like to hear that I
wrote a mess. But that has hardly ever happened. We may have different
opinions about it and I probably will not hear on a suggestion, but
beeing nervous that someone else reads my code? No? The opposite is
true, I hardly dare (besides some really small examples) to ship my
stuff before someone else has at least had a look at it.
> This might be because whenever we have to maintain code (usually after the
> original author has left) we spend most of our time cursing and swearing
> about how badly written it seems to be!
Well I feel this is not entirly true to me. Sometimes I would argue
yes, but other times I see that completely different. Well and more
often than I like I dislike things which turned out to be perfectly
ok.
> This is not necessarily the case but
> it often seems that way until we understand what's going on. So we're
> frightened about our own code receiving similar treatment.
Well that's not true for me. At least I do not feel that way. I try to
write my code alway in a way that I think another programmer can take
over really soon.
Regards
Friedrich
Roy MacLean
As I recall from a previous project, one area where you can't say much
using DbC is across an asynchronous interface. That is, a routine of
class C makes a 'one way' call through an interface; some time later a
result comes back via a call to another routine of C. Unless one
explicitly matches up request-response pairs, you can't state
contraints over arguments and results, or even whether a request
receives any result at all. This might be an issue on the boundaries
between Eiffel and non-Eiffel parts of a system.
/Roy
Rod Chapman
We have lots of people using SPARK - an annotated Ada subset that
strongly supports DbC (more strongly than Eiffel in some areas...)
Informally, we find SPARK simply prevents very large classes of
error - e.g. dataflow errors, information flow errors, and
buffer overflows are all statically detectable in SPARK.
Latent (i.e. post-delivery) defect rates in SPARK programs can be
very low indeed - e.g. 0.04 defects per kloc in the MULTOS CA
(which is 100kloc, only 30% of which is SPARK anyway...)
See IEEE Software Jan/Feb 2002 for more info.
We have similar data coming from Lockheed from the C130J programme
(which is DO-178B Level A).
- Rod Chapman, Praxis Critical Systems
Kevin McFarlane
"Vincent Bousquet" <vbou...@netcourrier.com> wrote in message
news:3dab2a70$0$29909$79c1...@nan-newsreader-02.noos.net...
> For my experience, design by contract catch all "misuse" errors.
> That is to say when I do not use class the way they are meant to.
> This covers most of the bugs I encounter.
>
> The second type of bugs are design / algorithm bugs.
> Design bugs are less frequent in Eiffel, since the language enforce some
> design principles.
> Algorithm bugs are just as frequent as they used to be.
>
> Anyway, I did not participate in a project as big as EiffelStudio.
> I think that a big project always need a test suite (like getest) for
going
> through most of its possibilities automatically and performing non
> regression test. The fact is that you can still leave holes...
My reason for asking this question on the forum is because I'd like to get a
handle on Eiffel Software's claim that Eiffel is the way to go if you want
to produce bug-free code. From everyone's comments it seems that there's
still a long way to go. However, DbC must have some effect. The question is:
how much? If it doesn't produce a significantly better effect than not
having DbC how can Eiffel be sold as a compelling improvement over C++,
Java, etc?
>
> I think you should try Eiffel. I used to porogram C/C++ for years and I've
> been trying Eiffel for a year now. I can't imagine going back to C/C++ !
>
I wrote a HelloWorld app. about 4 years ago. But I find it more effective to
invest my time in tools that will earn me a living which, right now, is
Microsoft stuff, as that's what I have commercial experience in. Here in the
UK you see about one Eiffel job advertised every 4 years!
However, I do find it valuable reading stuff such as OOSC and Objects
Unencapsulated. These help even if you don't use Eiffel.
Kevin McFarlane
I wrote a HelloWorld app. about 4 years ago. But I find it more effective to
invest my time in tools that will earn me a living which, right now, is
Microsoft stuff, as that's what I have commercial experience in. Here in the
UK you see about one Eiffel job advertised every 4 years!
However, I do find it valuable reading stuff such as OOSC and Objects
Unencapsulated. These help even if you don't use Eiffel.
> Ideas in progrmaming
> languages by reading what other write is af if I told you how swimming
> works, without practicing it won't be helpful. You can dicusss some
> things which you actually do not do. But I don't think programming
> falls under that category.
>
> >
> > [snip]
> > > Programmers do not like each
> > > other, they do not share ideas and thoughts.
> >
> > We all seem to be nervous about letting other developers look at our
> >code!
> Well I do not know why you say. If I wrote something I always ask
> others on what they think about it.
I was speaking generally.
> Now I do not like to hear that I
> wrote a mess. But that has hardly ever happened. We may have different
> opinions about it and I probably will not hear on a suggestion, but
> beeing nervous that someone else reads my code? No? The opposite is
> true, I hardly dare (besides some really small examples) to ship my
> stuff before someone else has at least had a look at it.
>
> > This might be because whenever we have to maintain code (usually after
the
> > original author has left) we spend most of our time cursing and swearing
> > about how badly written it seems to be!
> Well I feel this is not entirly true to me. Sometimes I would argue
> yes, but other times I see that completely different. Well and more
> often than I like I dislike things which turned out to be perfectly
> ok.
I've worked mostly in C++. If you work in Eiffel you may well find that the
discipline it imposes means that you more often look at nice code. This is
not so with C++.
>
>
> > This is not necessarily the case but
> > it often seems that way until we understand what's going on. So we're
> > frightened about our own code receiving similar treatment.
> Well that's not true for me. At least I do not feel that way. I try to
> write my code alway in a way that I think another programmer can take
> over really soon.
>
So do I.
Friedrich Dominicus
>
> My reason for asking this question on the forum is because I'd like to get a
> handle on Eiffel Software's claim that Eiffel is the way to go if you want
> to produce bug-free code. From everyone's comments it seems that there's
> still a long way to go.
Well DBC surly helps just FYI I've written recently a library using C,
GEF (General Exception Facility) and CUnit. And I have to admit I
won't miss any of the used tools. It probably looks a a bit strange
but I found it very readable and easy to understand, the code looks
like this:
/** Access contents of @a string as wchar_t Array.
@param string will get yielded as an wchar_t * Array.
@returns A propper zero terminated wide character string.
*/
wchar_t * Strwide (String &string){
wchar_t * result = NULL;
gef_try {
result = string.content;
} gef_preconditions {
gef_assert_precondition (Strvalid(string) &&
(str_type(string) == WIDE));
} gef_end;
return result;
}
I probably like it because it remainds me of Eiffel code the
only. During development this library has revealed itself as quite
stable. I have to admit I have a good feeling with this code. GEF
forces you into a regular coding. I would expect other C users would
have written it way different. So DBC has influences my way of
thinking about programming considerably. I feel good if I have found
nice pre/postconditions every assertion check which acutally has
fired reminds me at least that I've overlooked something or that my
"internal logic" was flawed. Add to this quite some tests and it
should be clear that I feel way more confidence while using all the
nifty things :-)
>However, DbC must have some effect. The question is:
> how much?
This depends on you. I just can suggest try it out yourself.
>If it doesn't produce a significantly better effect than not
> having DbC how can Eiffel be sold as a compelling improvement over C++,
> Java, etc?
Well it has an influence on how you develop software. Eiffel software
without Assertion is simply unthinkable, one does not think about
should I use it or not. You use it! There are some side-effects which
are not neglactable. Assertion do comment code. Assertions do give
clear hints on how a feature is supposed to be use. You won't get
suprised by invalid return values or the like if suits you
postconditions you "know" that it has been used right.
Eiffel lead to a different mind-set. It's not programming alone. It's
thinking along Contracts. The only experience I've met is while having
learned Common Lisp. Lisp let you though about programming again
completly different. Anayway you can do OO in Lisp too and Eiffel
could gain from some things in Common Lisp and the other way round.
Regards
Friedrich
Vincent Bousquet
> My reason for asking this question on the forum is because I'd like to get
a
> handle on Eiffel Software's claim that Eiffel is the way to go if you want
> to produce bug-free code. From everyone's comments it seems that there's
> still a long way to go. However, DbC must have some effect. The question
is:
> how much? If it doesn't produce a significantly better effect than not
> having DbC how can Eiffel be sold as a compelling improvement over C++,
> Java, etc?
>
The improvement is great since 99% of errors I encounter are misuse of
classes.
The other type of bugs are less often and DbC helps you to solve them.
Most of the time, I do not need a debuger to debug my code since the DbC
assertion tells you the reason of the bug.
And the final point is that Eiffel make you think a lot more on your design.
When you have to write an object contract, you have to ask yourself a lot of
questions.
This is not the case in C/C++.
Bye
Vincent Bousquet
Lothar Scholz
reuseable part) just crossed the 100.000 lines border so i think i can
say something about the benefits of eiffel.
My first hard experience was: Don't use eiffel for GUI based
applications because everything in this area sucks. This was the
reason why i developed my own FOX wrapper. This took 3-4 month. When
you use eiffel you often have to start from scretch.
The second one was: Never use eiffel for projects less then 50.000
lines and if you expect little maintainace work after the project
officially ends. This eliminates a lot of contract work. In projects
that are small and fast to develop, eiffel DbC does not provide enough
power to beat the better IDE's and developing tools out there. This is
the main problem of eiffel marketing: most people have not written
complex applications with another then the Java or C++ style so they
can't see a real benefit that compensates the current weaknesses.
Large Open Source projects would be a good field, but because they try
to give quick solutions to current problems most of them are not
driven by a long term plan and it is extremly hard to find persons who
can program in eiffel, most of them get only people that think they
can C++.
The larger your application grow, the more you see the benefits
against C++ and Java. Refactoring is easy. I changed the basic data
storage of the application two times and had to change nearly every
module. But this wasn't as complicated as it would be in C++
applications. I would say that 95% of the bugs are found immediately.
I can guess the location of 80% of the bugs by looking at the
SmartEiffel stack trace. A good debugger could increase this to 90%.
The interfaces are much easier to read when you come back a few month
later because the "require" give you a better specification of you
main thoughts.
The next is, believe it or not, in the first time i tried to build an
automatic test suite but i gave up quickly. The necessary cost to keep
this upto date is economical nonsense - at least if you do complex
GUIs. The embedded DbC covers most of the problems that are normally
done by test suits. I compile and run the program in the average after
every change of 30 lines. Remember that writting tests is extremely
boring and for this reasons very errorous. If you are writing tests
for your own code i found it mostly nonsense because you again testing
the things that you covered with DbC before.
Then there is the problem that most eiffel programmers will teach you
that you should use DbC and not defense programming. I believe that
this is wrong. In complex software you can only test a few cases of
all possible paths. And DbC only helps you with finding the
presence/location of errors. So you have to catch a lot of errors and
react in a non fatal way.
I see another, psychological problem of DbC. Most people who use this
(or to much theory in the field of functional programming) are very
bad in finding heuristics. You often have to approximate a problem you
don't need to solve it. This can be the basic algorithm or the way you
handle errors or very rare race conditions.
The next problem is - as mentioned by Friedrich earlier - the small
size of the community. Its hard to believe that i was for month the
only one who could not use the SmallEiffel GC because of some errors.
Its more worse, the core team were not even interested in helping to
find the error they did not even send or reply to any message off the
mailing list.
Beside all this i really have to ask myself if i would again use
Eiffel. But now i made the decision and must live with it. I will
develop for at least 2 more years on my application and hope that the
benefits are still increasing. The signs look promising.
Sorry if i made a lot of english grammer errors in this article but i
don't have time to reread it it already took me too long to write it
down.
Jason Voegele
> "Kevin McFarlane" <ke...@atech.globalnet.co.uk> wrote in message news:<cuWcnYXQKoN...@News.GigaNews.Com>...
>
>>i.e., in practice, what percentage of bugs are caught by contacts?
>
>
> We have lots of people using SPARK - an annotated Ada subset that
> strongly supports DbC (more strongly than Eiffel in some areas...)
Just curious - could you provide an example of what you mean by this?
--
Jason Voegele
"We believe that we invent symbols. The truth is that they invent us."
-- Gene Wolfe, The Book of the New Sun
Peter Horan
> My reason for asking this question on the forum is because I'd like to get a
> handle on Eiffel Software's claim that Eiffel is the way to go if you want
> to produce bug-free code. From everyone's comments it seems that there's
> still a long way to go. However, DbC must have some effect. The question is:
> how much? If it doesn't produce a significantly better effect than not
> having DbC how can Eiffel be sold as a compelling improvement over C++,
> Java, etc?
My experience of using DbC is that I can capture design information about
program structure that cannot readily be captured otherwise.
I have written a paper which relates to this, "Eiffel Assertions and the
External Structure of Classes and Objects". It is in the September edition of
JOT:
http://www.jot.fm/issues/issue_2002_09/article1
--
Peter Horan School of Information Technology
pe...@deakin.edu.au Deakin University
+61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter
-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)
Friedrich Dominicus
> Today the core of my library (that means the application specific non
> reuseable part) just crossed the 100.000 lines border so i think i can
> say something about the benefits of eiffel.
>
> My first hard experience was: Don't use eiffel for GUI based
> applications because everything in this area sucks. This was the
> reason why i developed my own FOX wrapper. This took 3-4 month. When
> you use eiffel you often have to start from scretch.
Nope, just in areas not covered before. But we are even improving
there.
>
> The second one was: Never use eiffel for projects less then 50.000
> lines and if you expect little maintainace work after the project
> officially ends.
This is way too much. Eiffel is even good for prototyping. When you
just write a few classes which you know will be evolving over time.
> Large Open Source projects would be a good field, but because they try
> to give quick solutions to current problems most of them are not
> driven by a long term plan and it is extremly hard to find persons who
> can program in eiffel, most of them get only people that think they
> can C++.
Well I don't thik this is really so problematic. I can imagine that
many would like to use Eiffel but have to stick with other tools. And
large open source projects. Well this would mean that at least one
person keeps going on working on it. Who can afford that?
Well if anyone is interested in someone quite capable in Eiffel and is
willing to pay for the development, I would not be the last to ask if
I could work on it ;-))
Well I even do think I have an idea about what to develop. An tool for
the whole lifecycle of program development. But hey this is probably a
bit too large ;-). Anyway Eiffel would be good at this because.
- Eiffel code is IMHO one of the easier ones to develop, maintain
- The OO features are quite strong, which means one class for things
and one feature to carry out a specialiced task :-)
>
> The larger your application grow, the more you see the benefits
> against C++ and Java. Refactoring is easy. I changed the basic data
> storage of the application two times and had to change nearly every
> module.
Refacorting is easy in Smalltalks too and if you take care of a few
things it's not too difficult in nearly any language.
>But this wasn't as complicated as it would be in C++
> applications. I would say that 95% of the bugs are found immediately.
> I can guess the location of 80% of the bugs by looking at the
> SmartEiffel stack trace. A good debugger could increase this to 90%.
> The interfaces are much easier to read when you come back a few month
> later because the "require" give you a better specification of you
> main thoughts.
This is a good point the ratio of 95 % seem a bit too high but, I
missed to keep tracking of that.
>
> The next is, believe it or not, in the first time i tried to build an
> automatic test suite but i gave up quickly. The necessary cost to keep
> this upto date is economical nonsense - at least if you do complex
> GUIs.
Well I have a problem to even find tools for testing GUIS. Does anyone
has any suggestion?
>The embedded DbC covers most of the problems that are normally
> done by test suits. I compile and run the program in the average after
> every change of 30 lines. Remember that writting tests is extremely
> boring and for this reasons very errorous.
This is not true for me. I like to write tests as I like to write
assertions. I will use both. And I will happily write more test-code
than actual code for the applicaton if necessary. BTW you suggestion
is the complete opposite of XP. And I think they have very good
arguments for their strategy.
> If you are writing tests
> for your own code i found it mostly nonsense because you again testing
> the things that you covered with DbC before.
DBC and Tests are not exclusive.
>
> Then there is the problem that most eiffel programmers will teach you
> that you should use DbC and not defense programming. I believe that
> this is wrong.
No it is not. Because doing defensive programming means too, to
intervene error handling tighly with normal control flow. Keep thos
things as far apart as possible. DBC is the right tool for doing that
job.
>
> The next problem is - as mentioned by Friedrich earlier - the small
> size of the community. Its hard to believe that i was for month the
> only one who could not use the SmallEiffel GC because of some errors.
> Its more worse, the core team were not even interested in helping to
> find the error they did not even send or reply to any message off the
> mailing list.
Sorry Lothar they do not have any obligation to help you. It's their
service, have you considered asking for support and have been willing
to pay for it?
>
> Beside all this i really have to ask myself if i would again use
> Eiffel. But now i made the decision and must live with it. I will
> develop for at least 2 more years on my application and hope that the
> benefits are still increasing. The signs look promising.
This is a two-folded paragrapho. The first suggests you regret to have
choosen Eiffel the last sentence tells the opposite. Nothing prevents
you from not using Eiffel and nothing prevents you from using Eiffel
with another language together. A choice pro Eiffel does not mean you
leave it all behind. Quite the opposite. If the foundationsa are
strong (probably while using Eiffel) than it could be a very good idea
to combine it wich languages with "scripting" facilities. The closes
scripting language in the Eiffel spririt is probably Ruby. So why not
use Eiffel *and* Ruby?
Regards
Friedrich
Rod Chapman
> Just curious - could you provide an example of what you mean by this?
Sure...the main differences are:
1) SPARK contracts include specification of global data access,
the "mode" of that access ("in", "out" or "in out), and a specification
of required information flow (e.g. "final value of A depends on initial
values of B and C but not D")
2) SPARK pre- and post-conditions have extended visibilty over
"normal" Ada expressions (so you can get at and refer to remote
state for instance) and also have an extended syntax which includes
quantifiers, logical implication, equivalence, and multiple updates
to structured objects.
3) SPARK contacts are always checked statically (by information flow
analysis, generation of verification conditions, and theorem proving),
rather than by a dynamic run-time check. If a SPARK contract is true,
then it's true for _all_ input data.
4) On the other hand, SPARK has a more limited model of OO than
Eiffel - rather obviouisly, SPARK does not allow dynamic dispatch,
since we don't know how to statically analyse those kinds of call!
SPARK _does_ insist that a sub-class always respects its parent's
contracts, though, (the "covariance" rule?) - again, this is done
by VC generation and theorem proving rather than by a dynamic
check.
- Rod Chapman
Chris Ambarian
> Today the core of my library (that means the application specific non
> reuseable part) just crossed the 100.000 lines border so i think i can
> say something about the benefits of eiffel.
>
> My first hard experience was: Don't use eiffel for GUI based
> applications because everything in this area sucks. This was the
> reason why i developed my own FOX wrapper. This took 3-4 month. When
> you use eiffel you often have to start from scretch.
>
> The second one was: Never use eiffel for projects less then 50.000
> lines and if you expect little maintainace work after the project
> officially ends. This eliminates a lot of contract work. In projects
> that are small and fast to develop, eiffel DbC does not provide enough
> power to beat the better IDE's and developing tools out there.
...
> Then there is the problem that most eiffel programmers will teach you
> that you should use DbC and not defense programming. I believe that
> this is wrong. In complex software you can only test a few cases of
> all possible paths. And DbC only helps you with finding the
> presence/location of errors. So you have to catch a lot of errors and
> react in a non fatal way.
As a follow-up to Lothar's excellent post, I would like to say a
couple of things just to keep the pot of thoughts stirring...
Regarding the GUI stuff, I think part of Lothar's comment could be
qualified. There's a lot of man-years of experience and work in the
ISE EiffelVision libaries. Not perfection, and in criminal need of
docs, but there's a lot there -- and certainly among the best truly
multi-platform stuff. (I'm only saying that "everything in this area
sucks" might be a _little_ harsh. :)
Regarding project size-appropriateness for using Eiffel: while I
agree that there is often a threshold below which it might make sense
to use VB (for example), I think that setting it at ~50kloc of initial
intent might not be a thorough enough guideline.
First, many (if not most) large projects started out as a humble small
project, then grew. Assuming that you can predict whether a project
will ever be expanded upon, you may want to make the decision of what
language to use based on projected size... But if there is any
question about this at all, one might be best advised to just do it
right, from the beginning...
Second (still on this subject), there is the question of reuse. If
you are a contract developer in a particular space, then you can
create reusable objects that will allow you to go out and secure more
work in that space that
reuses what you did on your little <50kloc project. So if you have it
in mind that you might reuse it in the future, then you might want to
do it in Eiffel. The next time, instead of spending a week or two
rewriting what you already have, you only spend a few minutes reusing
it. We have a very recent example of a customer who reused and
extended some previous Eiffel work in 4 hours -- after a colleague
tried to replicate it in C# and gave up after 3 weeks.
Finally, a thought about DbC and defensive programming. It is simply
a matter of when to use DbC vs. when to use defensive... If you write
a contract, it likely means that the contract should exist. If you are
unsure about the contract, then you probably should use defensive
programming.
Cheers all
Chris Ambarian
Kevin McFarlane
> The closes
> scripting language in the Eiffel spririt is probably Ruby. So why not
> use Eiffel *and* Ruby?
>
In scripting languages, I've used VBScript, JavaScript, Perl and Python. I
discovered Python after being frustrated by a Perl maintenance project I was
working on. (Perl is the worst language for readability and maintainability
that I've ever used- makes C/C++ look like a model of clarity!) I've started
to see the odd bok on Ruby in my local bookshop. I was very impressed with
Python. Do you think Ruby is better? If so, do you think it will have a
significant market?
Lothar Scholz
> > against C++ and Java. Refactoring is easy. I changed the basic data
> > storage of the application two times and had to change nearly every
> > module.
> Refacorting is easy in Smalltalks too and if you take care of a few
> things it's not too difficult in nearly any language.
I did no large refactoring in dynamic typed languages other then C++.
And there i got a lot of errors so it took a long time. But perhaps i
just missed some tools because i did it with XEmacs :-(.
I really like the refactoring features of IntelliJ's idea IDE.
> This is not true for me. I like to write tests as I like to write
> assertions. I will use both. And I will happily write more test-code
> than actual code for the applicaton if necessary. BTW you suggestion
> is the complete opposite of XP. And I think they have very good
> arguments for their strategy.
Yes but they are not bound to eiffel. Do you remember the discussion
in this group a year ago where Mr. Meyer said that the XP process is
not easily portable to Eiffel ? He also had a lot of good arguments.
And i think i got a lot of good experiences. Of couse i have some
testprograms but they check for whole subsystem, not on a feature or
class base. And i'm not really interested in 90% code coverage of my
test cases and other metrics like this. I did this in my C++ days and
i didn't liked it.
> > Then there is the problem that most eiffel programmers will teach you
> > that you should use DbC and not defense programming. I believe that
> > this is wrong.
> No it is not. Because doing defensive programming means too, to
> intervene error handling tighly with normal control flow. Keep thos
> things as far apart as possible. DBC is the right tool for doing that
> job.
But then you have to leave at least "require" checkings on in your
final executeable. With the terrible performance penaltiy you get from
SmallEiffel this has never been an option for me. Perhaps in days
where we have 10 GHz Pentium XIV
machines with 8 processors i would use it but currently: no.
> > Its more worse, the core team were not even interested in helping to
> > find the error they did not even send or reply to any message off the
> > mailing list.
> Sorry Lothar they do not have any obligation to help you. It's their
> service, have you considered asking for support and have been willing
> to pay for it?
I think if they have a bug in such a fundamental place a little more
cooperation would be helpful. If i were only a normal guy doing
SmallEiffel in my spare time this would be the reason to switch to
another language, simply because the community is not a community.
They not even send a mail like "Sorry we can't reproduce it". And for
the payed service: i would not hessitate one minute to send them a
fair amount of money for the compiler when i could get some support,
but i can't affort to buy support on a per incident or per hour
(60-80$) base. I believe something like 250$ would be a fair price for
a compiler. But if i'm the only one who has this problem, do you think
they would really spend time on it. This is the problem with a small
community (or customer base if you sell something).
> > Beside all this i really have to ask myself if i would again use
> > Eiffel. But now i made the decision and must live with it. I will
> > develop for at least 2 more years on my application and hope that the
> > benefits are still increasing. The signs look promising.
> This is a two-folded paragrapho. The first suggests you regret to have
> choosen Eiffel the last sentence tells the opposite. Nothing prevents
Yes, i'am two-folded. At the moment everything seems fine. My
application is growing with a 9000 LOC per month rate and its getting
really stable at the moment. New errors are only found in places which
i modified/added last. But then i'm afraid about new compiler problems
with new features that kills SmartEiffels stability or the compilation
speed. Or the simple fact that my product is successful and i have to
find an employee that is able to read and understand eiffel :-)
Jason Voegele
> I've started
> to see the odd bok on Ruby in my local bookshop. I was very impressed with
> Python. Do you think Ruby is better? If so, do you think it will have a
> significant market?
You can find some comparisons on my site:
http://www.jvoegele.com/software/langcomp.html
As a gross generalization, I would say that those who prefer Python come
from a C++ and Java background, while Eiffel and Smalltalk programmers
prefer Ruby.
I vastly prefer Ruby to Python, but I cannot say whether or not it will
have a significant market. In Japan, at least, it is more popular than
Python.
Peter Horan
> But then you have to leave at least "require" checkings on in your
> final executeable.
Why?
Friedrich Dominicus
>
> Yes but they are not bound to eiffel. Do you remember the discussion
> in this group a year ago where Mr. Meyer said that the XP process is
> not easily portable to Eiffel ? He also had a lot of good arguments.
Well there alway pro/contra arguments. I can not see anything in
Eiffel which should really come into the way. You can compile a class
add a feature and test it immediatly after that. This works obviously
better in interpreted languages but it works for Eiffel too.
> And i think i got a lot of good experiences. Of couse i have some
> testprograms but they check for whole subsystem, not on a feature or
> class base.
I think this is not a good idea. Obviously you see that differently. I
would argue you need both. But as you told me you get along without it
so I guess you do you software development in another way than I do.
>
> > > Then there is the problem that most eiffel programmers will teach you
> > > that you should use DbC and not defense programming. I believe that
> > > this is wrong.
> > No it is not. Because doing defensive programming means too, to
> > intervene error handling tighly with normal control flow. Keep thos
> > things as far apart as possible. DBC is the right tool for doing that
> > job.
>
> But then you have to leave at least "require" checkings on in your
> final executeable. With the terrible performance penaltiy you get from
> SmallEiffel this has never been an option for me. Perhaps in days
> where we have 10 GHz Pentium XIV
> machines with 8 processors i would use it but currently: no.
Well yes I think they should be checked. I can't tell for Smalleiffel
what the penalties are but I bet even with full all assertions checked
we got at least as fast as so popular Java. That obviously is enough
speed for many programmers.
>
> > > Its more worse, the core team were not even interested in helping to
> > > find the error they did not even send or reply to any message off the
> > > mailing list.
> > Sorry Lothar they do not have any obligation to help you. It's their
> > service, have you considered asking for support and have been willing
> > to pay for it?
>
> I think if they have a bug in such a fundamental place a little more
> cooperation would be helpful. If i were only a normal guy doing
> SmallEiffel in my spare time this would be the reason to switch to
> another language, simply because the community is not a community.
I disagree and I don't see a common base here. If you use Eiffel in
commercial surrounding why don't you buy Eiffel compilers than? Why
don't you support your toolsmith. You may have your reasons but that
it's your business to get along with _you_ decision.
> They not even send a mail like "Sorry we can't reproduce it". And for
> the payed service: i would not hessitate one minute to send them a
> fair amount of money for the compiler when i could get some support,
> but i can't affort to buy support on a per incident or per hour
> (60-80$) base.
if you want professional help you must be willing to pay professional
prices. If I would ask you for you software would you give it to me
for free and offer support too?
>I believe something like 250$ would be a fair price for
> a compiler. But if i'm the only one who has this problem, do you think
> they would really spend time on it. This is the problem with a small
> community (or customer base if you sell something).
Well you do not have to use SmallEiffel. Have you tried Visual Eiffel
or Halstenbach Eiffel or ISE Eiffel?
>
> Yes, i'am two-folded. At the moment everything seems fine. My
> application is growing with a 9000 LOC per month rate and its getting
> really stable at the moment.
Ths is an extreme high rate. which mean around 400 LOC/DAY which is
that is awful and frightning much.
> New errors are only found in places which
> i modified/added last. But then i'm afraid about new compiler problems
> with new features that kills SmartEiffels stability or the compilation
> speed.
Sorry I can't see why you rely on Small/SmartEiffel than. I can't tell
about the long-term stability of it, but I'm quite sure it's high on
the priority list of commercial offerings.
>Or the simple fact that my product is successful and i have to
> find an employee that is able to read and understand eiffel :-)
That should hardly be a problem. I know quite few Eiffel programmers
willing to work for a decent payment. If you run in the mentioned
problem don't hesitate to contact me ;-)
Regards
Friedrich
Friedrich Dominicus
> As a follow-up to Lothar's excellent post, I would like to say a
> couple of things just to keep the pot of thoughts stirring...
>
> Regarding the GUI stuff, I think part of Lothar's comment could be
> qualified. There's a lot of man-years of experience and work in the
> ISE EiffelVision libaries. Not perfection, and in criminal need of
> docs, but there's a lot there -- and certainly among the best truly
> multi-platform stuff.
Halstenbach Eiffel on Windows too and I think they got a very decent
Toolkit too.
But I know quite some other language where you can do GUI Programming
over system boundaries (of course if you stay within one implementation)
>(I'm only saying that "everything in this area
> sucks" might be a _little_ harsh. :)
Well he was probably talking about the "free" offers. I was thinking
that VeGTK was quite usable, but it's a long time ago since I tried it.
>
> Regarding project size-appropriateness for using Eiffel: while I
> agree that there is often a threshold below which it might make sense
> to use VB (for example), I think that setting it at ~50kloc of initial
> intent might not be a thorough enough guideline.
Definitly.
>
> First, many (if not most) large projects started out as a humble small
> project, then grew.
Exact.
> Assuming that you can predict whether a project
> will ever be expanded upon, you may want to make the decision of what
> language to use based on projected size... But if there is any
> question about this at all, one might be best advised to just do it
> right, from the beginning...
Well yes, but doing it right from a beginning what does it mean. I can
think of quite some alternative to Eiffel. It very depends on what you
want to do with the software.
> So if you have it
> in mind that you might reuse it in the future, then you might want to
> do it in Eiffel.
Reuse is not an Eiffel-bound thing.
> We have a very recent example of a customer who reused and
> extended some previous Eiffel work in 4 hours -- after a colleague
> tried to replicate it in C# and gave up after 3 weeks.
The advice is good but it does not help much if documentation is poor.
>
> Finally, a thought about DbC and defensive programming. It is simply
> a matter of when to use DbC vs. when to use defensive... If you write
> a contract, it likely means that the contract should exist. If you are
> unsure about the contract, then you probably should use defensive
> programming.
Well I just can see one place for defensive programming in Eiffel:
"Checking user input and external sources of information"
I would think a good idea would be even in Eiffel having a layered
product. The core should be the "pure" application, that's the area of
DBC, than around it write the needed stuff for checking the
input. It's IMHO no a good idea to rely on DBC stuff for things which
come from "the outside".
Regards
Friedrich
Emmanuel STAPF
> with new features that kills SmartEiffels stability or the compilation
> speed.
Then you should switch to an implementation that has more constraints toward
its user. Usually this is the case with commercial implementation and to
quote one, why don't you try the one from Eiffel Software
http://www.eiffel.com ?
Manu
Lothar Scholz
> discovered Python after being frustrated by a Perl maintenance project I was
> working on. (Perl is the worst language for readability and maintainability
> that I've ever used- makes C/C++ look like a model of clarity!) I've started
> to see the odd bok on Ruby in my local bookshop. I was very impressed with
> Python. Do you think Ruby is better?
I would see it a a different flavour. Its the same discussion as
between C++ and for example Delphi-Pascal. There is simply no winner
because there is no real gap between them.
> If so, do you think it will have a
> significant market?
I compare the number of postings in comp.lang.ruby and
comp.lang.python every week and they get more an more the same, but
the ruby groups has less topics with larger threads. If you see this
as a sign i would say that the community is really significant enough
to be one of the leading script languages. But at the moment perl is
growing much faster (from all the people who left java - for a lot of
reasons).
And (some marketing) there is great IDE on the way for
Ruby/Python/PHP, expect it in the middle of the next year, it is
written in Eiffel (the source just crossed the 100.000 LOC border :-)
So i'm really sure that there is a future.
Kevin McFarlane
"Lothar Scholz" <llo...@web.de> wrote in message
news:6ee58e07.02101...@posting.google.com...
[snip]
> But at the moment perl is
> growing much faster (from all the people who left java - for a lot of
> reasons).
Don't you mean Python? If you really mean Perl that's bad news!
>
> And (some marketing) there is great IDE on the way for
> Ruby/Python/PHP, expect it in the middle of the next year, it is
> written in Eiffel (the source just crossed the 100.000 LOC border :-)
>
> So i'm really sure that there is a future.
What about the Komodo IDE? That supports Python and PHP. Could it support
Ruby?
Kevin McFarlane
> Kevin McFarlane wrote:
> > I've started
> > to see the odd bok on Ruby in my local bookshop. I was very impressed
with
> > Python. Do you think Ruby is better? If so, do you think it will have a
> > significant market?
>
> You can find some comparisons on my site:
>
> http://www.jvoegele.com/software/langcomp.html
>
Looks interesting at first glance!
Greg C
Lothar Scholz wrote:
>[...]
>The second one was: Never use eiffel for projects less then 50.000
>lines and if you expect little maintainace work after the project
>officially ends.
>
Actually, I've had a lot of success using Eiffel with relatively small
projects -- like the kind that
runs a couple hundred lines and gets slapped together in a couple hours.
When you have a
library written with good contracts, you're leveraging those contracts
to perform testing of
your application as it's being built.
Eiffel lends itself particularly well to certain XP concepts, like
frequent testing and refactoring.
Good contracts can be effective test suites for your client code.
I think one of the reasons DbC hasn't caught on with other languages is
because the libraries
for those languages don't have contracts built into them. So you're only
getting DbC's benefit
in your part of the code, which these days amounts to a very small part
of the average
application. I think this is reflected in the GUI libraries you
mentioned earlier.
Greg C
Greg C
>[...]
>
>
>Well I even do think I have an idea about what to develop. An tool for
>the whole lifecycle of program development. But hey this is probably a
>bit too large ;-). Anyway Eiffel would be good at this because.
>- Eiffel code is IMHO one of the easier ones to develop, maintain
>- The OO features are quite strong, which means one class for things
>and one feature to carry out a specialiced task :-)
>
I'd add to that the very nice support for generics in Eiffel. Far better
than C++ templates.
>>The larger your application grow, the more you see the benefits
>>against C++ and Java. Refactoring is easy. I changed the basic data
>>storage of the application two times and had to change nearly every
>>module.
>>
>Refacorting is easy in Smalltalks too and if you take care of a few
>things it's not too difficult in nearly any language.
>
It can be very difficult with C++, in large part because of such
"features" as header files and
function overloading.
Greg C
Greg C
Lothar Scholz wrote:
>>>[...]
>>>
>
>Or the simple fact that my product is successful and i have to
>find an employee that is able to read and understand eiffel :-)
>
That's the problem to have! Would you accept applications from
telecommuter programmers?
Greg C
Philippe Ribet
>
> > The next is, believe it or not, in the first time i tried to build an
> > automatic test suite but i gave up quickly. The necessary cost to keep
> > this upto date is economical nonsense - at least if you do complex
> > GUIs.
> Well I have a problem to even find tools for testing GUIS. Does anyone
> has any suggestion?
>
Working with X11 ?
man xvfb
Best regards,
--
Philippe Ribet
The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!
Philippe Ribet
Latest ***BETA*** releases have problems due to massive changes in both
expanded types and integer classes. But this is BETA release! Stable releases
are provided too.
I guess that commercial implementation from Eiffel Software has bugs in beta
release, if there are such ones...
Lothar Scholz
> What about the Komodo IDE? That supports Python and PHP. Could it support
> Ruby?
The last offical statement from Active State is that they will not
support Ruby - they only provide some syntax highlighting in the
komodo editor - because they don't think it has a large enough user
base (corporate user, those who spend money for tools).
This was a little while ago, but now i think they wouldn't do this
because i guess they are also hit by the current economical crises -
which in my opinion will continue for years :-(
Lothar Scholz
> I think this is not a good idea. Obviously you see that differently. I
> would argue you need both. But as you told me you get along without it
> so I guess you do you software development in another way than I do.
As mentioned before i think we do different tasks. I'm really heavy
GUI bound, i guess your development is not.
> I disagree and I don't see a common base here. If you use Eiffel in
> commercial surrounding why don't you buy Eiffel compilers than? Why
> don't you support your toolsmith. You may have your reasons but that
> it's your business to get along with _you_ decision.
The main reason is the fucking incompatibility in the libraries and
the external binding. Now my code base is so large that porting it is
extreme expensible and i will defer it until there is a no go
showstopper in SmallEiffel.
> > They not even send a mail like "Sorry we can't reproduce it". And for
> > the payed service: i would not hessitate one minute to send them a
> > fair amount of money for the compiler when i could get some support,
> > but i can't affort to buy support on a per incident or per hour
> > (60-80$) base.
> if you want professional help you must be willing to pay professional
> prices. If I would ask you for you software would you give it to me
> for free and offer support too?
I know this and i would also not work for less. But i can't afford it
so i have to go on my own. If i can see my company becoming successful
then it wouldn't be that big problem. But if you could see my (private
only) venture capital you would start crying.
Lothar Scholz
> Well I just can see one place for defensive programming in Eiffel:
> "Checking user input and external sources of information"
I'm also using this for subsystem boundaries where the contract is to
complicated and computing intensive to check. I just converted my GUI
Builder to the new GOBO 3.0 staff and the XML parser is unuseable. In
my application it takes 1 second to parse 1 byte of an XML file (on a
Athlon 1600XP under Linux). When you remove some of the DbC staff like
UC_STRING.is_valid_utf8 then its okay again.
I also like the Delphi philosopie that reuseable applications should
be fault tolerant if the error is recoverable (and should use a
"check" instruction which helps to find this error during development
time).
So in my programing style defensive programming is a kind of fallback
security that lives behind DbC.
Eric Bezault
>
> Friedrich Dominicus <fr...@q-software-solutions.com> wrote in message news:<87smz6w...@fbigm.here>...
>
> > Well I just can see one place for defensive programming in Eiffel:
> > "Checking user input and external sources of information"
>
> I'm also using this for subsystem boundaries where the contract is to
> complicated and computing intensive to check. I just converted my GUI
> Builder to the new GOBO 3.0 staff and the XML parser is unuseable. In
> my application it takes 1 second to parse 1 byte of an XML file (on a
> Athlon 1600XP under Linux). When you remove some of the DbC staff like
> UC_STRING.is_valid_utf8 then its okay again.
>
> I also like the Delphi philosopie that reuseable applications should
> be fault tolerant if the error is recoverable (and should use a
> "check" instruction which helps to find this error during development
> time).
The problem with 'check' instructions is that contrary to pre- and
postcondition they do not appear in the flat-short forms.
> So in my programing style defensive programming is a kind of fallback
> security that lives behind DbC.
Do you mean that `is_valid_utf8' is too expensive as a precondition
so you removed it (BTW, why not just use assertion monitoring?), but
then for defensive programming you added it back to the body of the
routine?
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com
Friedrich Dominicus
> Friedrich Dominicus <fr...@q-software-solutions.com> wrote in message news:<87wuoiw...@fbigm.here>...
> > I think this is not a good idea. Obviously you see that differently. I
> > would argue you need both. But as you told me you get along without it
> > so I guess you do you software development in another way than I do.
>
> As mentioned before i think we do different tasks. I'm really heavy
> GUI bound, i guess your development is not.
Well that is true, I have tried to find a way to test GUIs but I
really have no clue what things could be used there.
>
> > I disagree and I don't see a common base here. If you use Eiffel in
> > commercial surrounding why don't you buy Eiffel compilers than? Why
> > don't you support your toolsmith. You may have your reasons but that
> > it's your business to get along with _you_ decision.
>
> The main reason is the fucking incompatibility in the libraries and
> the external binding.
Well I know what you mean (now). Anyway we got around this while using
GOBO. It's more than "good enough" and we have used it and hardly have
had any problems switching from ISE to Halstenbach Eiffel and back
(well ISE and Halstenbach have a common base and their interface to
external libraries is very simular)
However I would dare to say if you have encapsulated the mentioned
stuff thant porting should be not all too hard if you did not have
done it well, than I would think the design was not quite right.
>Now my code base is so large that porting it is
> extreme expensible and i will defer it until there is a no go
> showstopper in SmallEiffel.
I do not know you code base, but you should not have cluttered all
sort of classes with SmallEiffel specific stuff, otherwise you must
have had a reason for doing it. It now bites you.
>
> I know this and i would also not work for less. But i can't afford it
> so i have to go on my own. If i can see my company becoming successful
> then it wouldn't be that big problem. But if you could see my (private
> only) venture capital you would start crying.
I know that we were in contact before about that. I just suggest
re-contact me and let's see if we can find a base. We for our part are
at the moment working on a quite interesting thing which I hope will
be able to offer here not all to far in the future.
Regards
Friedrich
Friedrich Dominicus
> However I would dare to say if you have encapsulated the mentioned
> stuff thant porting should be not all too hard if you did not have
> done it well, than I would think the design was not quite right.
sorry for following-up myself. I think the last sentence is
arrogant. Anyway it seems you have decided to put all effort on a
seamless Smalleiffel intergration. Well I try to use and write Eiffel
which works at least on two diffrent compilers. The last things I've
written usually have worked on all supported ones. You problem
probably is that you now have wrappers which work for SmallEiffel but
do not work elsewhere. Anyway this could be avoide a bit using gepp,
and I would argue you could have checked how it has been done in GOBO.
Regards
Friedrich
Berend de Boer
> I'm also using this for subsystem boundaries where the contract is to
> complicated and computing intensive to check. I just converted my GUI
> Builder to the new GOBO 3.0 staff and the XML parser is unuseable. In
> my application it takes 1 second to parse 1 byte of an XML file (on a
> Athlon 1600XP under Linux). When you remove some of the DbC staff like
> UC_STRING.is_valid_utf8 then its okay again.
You can selectively enable parts of DbC with SE, can't you?
I see no point in enabling postconditions and invariants for Gobo,
except when you're not trusting it or debugging it.
Regards,
Berend. (-:
Lothar Scholz
> The problem with 'check' instructions is that contrary to pre- and
> postcondition they do not appear in the flat-short forms.
Yes this is the disadvantage. But as a sideeffect i can get around
VAPE errors which otherwise force me to open the access restrictions
or introduce new API calls. I know this is what some people would call
bad design, but it works good in the real world.
> Do you mean that `is_valid_utf8' is too expensive as a precondition
> so you removed it (BTW, why not just use assertion monitoring?), but
> then for defensive programming you added it back to the body of the
> routine?
Not 100% correct. I did not add this in the body of the routine.
The main problem is that most checks are called much to often. If you
build strings with extend(character) then "is_valid_utf8" is called on
every character addition and this kills your performance. So i do a
lot of assertation checkings only from time to time.
For example: my application fires an "check_invariant" event every 2
seconds where all datastructures are validated. This can take some 100
millisecones. Normally this is good enough to find errors. When i find
out that there is an error i turn on more and more assertations,
normally by simply uncommenting lines. I use the check instructions
mostly to check simple things in the dataflow, for example calling
features in the wrong order.
The main reason is that i want to build an executeable that i can run
with all assertions turned on and which is still useable in real life.
So i must ensure that the results runs at least with 1/10 the speed i
want for the boosted executeable. With this i can find much more
errors than with syntetic tests.
If i had to disable most of the assertions (ensure, invariant) it does
not help very much in finding errors. I do this normally only with the
well tested libraries GOBO and the Smarteiffel runtime but i don't
trust everything else.
There is a large gap between DbC in the academic sense and the use in
the real world. Applications like ISEs IDE (<= 5.0) is a proof for
this theorem. I'm not sure if there is an optimal way - i tried my own
and it works for me. Other persons have other error hotspots and
therefore need other ways to use it to protect them from there human
failures.
Jim Cochrane
Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
>amba...@aol.com (Chris Ambarian) writes:
>> ...
>>
>> Finally, a thought about DbC and defensive programming. It is simply
>> a matter of when to use DbC vs. when to use defensive... If you write
>> a contract, it likely means that the contract should exist. If you are
>> unsure about the contract, then you probably should use defensive
>> programming.
>Well I just can see one place for defensive programming in Eiffel:
>"Checking user input and external sources of information"
I would not call this defensive programming*. But you all might find that
coming up with a precise definition of defensive programming will allow
more effective discussion of its virtues/flaws.
(*I would call it fulfilling the requirements.)
>
>I would think a good idea would be even in Eiffel having a layered
>product. The core should be the "pure" application, that's the area of
>DBC, than around it write the needed stuff for checking the
>input. It's IMHO no a good idea to rely on DBC stuff for things which
>come from "the outside".
>
>Regards
>Friedrich
>
--
Jim Cochrane
j...@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
Berend de Boer
> 3) SPARK contacts are always checked statically (by information flow
> analysis, generation of verification conditions, and theorem proving),
> rather than by a dynamic run-time check. If a SPARK contract is true,
> then it's true for _all_ input data.
This is a thing I would like to see for Eiffel as well. That would be
really innovative. You probably get it in limited form only, but if you
just get 80% of this, that would already be amazing.
Any paper that describes how this works? I think I remember the IEEE
paper, but thought that didn't give much, if any, detail on this. Will
look it up though.
Regards,
Berend. (-:
Rod Chapman
> Any paper that describes how this works? I think I remember the IEEE
> paper, but thought that didn't give much, if any, detail on this.
1) IEEE Software, Jan/Feb 2002 - "Correctness by Construction: Building a
Commercial Secure System" by Hall and Chapman.
2) CrossTalk Journal, March 2002 - "Correctness by Construction: Better can
also be Cheaper" by Amey. www.stsc.hill.af.mil
There's also lots of stuff on www.sparkada.com, of course, including PDF
of these two papers.
The best technical reference for information flow analysis is
"Information-flow and data-flow analysis of while programs" by
Bernard Carre and Francois Bergeretti. ACM TOPLAS Vol 7, no. 1.
January 1985. (No PDF unfortunately...)
I am very interested in forging better links between the Eiffel and
SPARK communities - the design goals of the two are very close, and
we could probably learn a great deal from each other.
- Rod Chapman, SPARK Team, Praxis Critical Systems