Re: Re[4]: Is Smart Eiffel ready for large-scale application ?

Hello everybody,

I'm new on this mailing-list, but I think I know SmartEiffel quiet a bit (I
learned it in my first year at ESIAL, a french computer science engineering
school, and I'm currently working with the SE team to rebuild the java bytecode
generation).


Selon Lothar Scholz <[email protected]>:

> Unfortunately it is completely different. If i would try to track down
> bugs like Dominique, Cyril, Philippe or any of the other team members
> i would be already out of business. Smalleiffel and SmartEiffel (i got
> it compilable on 2.1) crashs just to many times. Luckily i soon found out
> which constructs i must avoid so it happens not so often any more.

To me, SmartEiffel doesn't seem to crash *that* much. Considering the huge
number of compilers I used, SmartEiffel is a very good one (and does its job
well).
I don't know about SmallEiffel.

> I mean it's really stupid. It simply doesn't matter if a test case
> that crashs is 6 MB large or 25 lines. If you can put your finger on
> the line and tell you change this 'a' into 'b' and compile_to_c
> crashes it's the best bug report you can get from a user. With
> DbC the size of the testcase simply does not matter. This is something
> i learned very fast. And even if the crash report is not so
> reproduceable, does the team add special DbC and work with someone to
> track it down? No! The usual arrogance is shown and everything
> is rejected.

I think verbose error are useful.
Firstly, they are as a general principle in computer science. It is not always
critical, but it's a powerful to track your errors. I'm writing my own
operating system (but not with SmartEiffel:) and I *need* verbose errors. Ok,
this example is very typical.
Secondly, by printing the entire stack, the programmer can see why it crashes.
It's not always a programming error, and often it only violates a
require/ensure assertion. This also helps to learn programming-by-contract and
to learn how to program correctly.

When you see "the team",are you talking about the SE team ?
"The usual arrogance is shown and everything is rejected". The SE team shows
real interest in bug reports, because it's a good way to find bugs in the
compiler and to fix them. If it wasn't taking care of these, I don't know how
the team is able to produce better and better version.
Example : I have access to the CVS for some weeks now, and when any user, on
this mailing list for example, reports a bug, a test file is add by a member to
reproduce the bug and help find out why it's actually happening. The compiler
is regularly compiled and reports about the failed test are reported. So when a
new version is about to be release, every user that report a bug can consider
himself as having helped the version to be more efficient that the previous
one.

> That's why i can't take the team as serious anymore. They have this
> stupid "it works for me, so shut up and don't steal my time" attitude.
> SmartEiffel will never get very far if they don't change this.

From my point of view, this is not really the way the team is thinking. They
want things to be implemented the best way they could be. Their goal is not to
make a compiler for themselves, they want to build a compiler that people can
use. Remember that SmartEiffel is always in development. You can't seriously
expect any compiler (for any language) release to be "the perfect one".
Features are added, modified, removed because things can be done
easier/better/with more efficiency, so the SE team don't hesitate to to it,
i.e. to make SmartEiffel work better.
Sometimes, people are complaining about differences / incompatiblities between
SmartEiffel and the so-called "standard". This is because the team prefers to
implement things in the best the can, even if the standard says to do it in a
crappy way.

>
> It's a pitty for the eiffel community (is there still anyone ?). The
> smarteiffel project is killing the public opinion of the language.

I simply can't agree with you about this. The team is really aware of the public
opinion. See above for more info.

> Just because they don't care about practical issues and prefer
> a theorectical better system (even this i would doubt).

Practical issues are only isolated cases of a theory. The SE team don't care
about *one* practical issue, it cares about *all*, that's why it is necessary
to build a strong-theory based system.
And please, don't doubt about this. Believe me : I looked deep in the compiler
code and I have weekly meetings with members of the team, so I know about what
I'm talking about (on this point at least).

> But as long as
> SmartEiffel is alive there will be nobody working on another open eiffel
> system.

SmartEiffel is GPL and nobody prevents anybody from building another open eiffel
system. But maybe most eiffel users are happy enough with SE, who knows ?

> By the way is anybody out there using SmartEiffel > 2.1 for anything
> serious ? Something more then a small script project ? I really doubt
> it.

I'm currently working on a trinary-based computer architecture simulator, and
it's not really what one can call a "small script project". I'm using 2.1 (the
last release) and will 2.2 as soon as it's released :)



So, I hope I didn't flame to many people in this mail:)
I just wanting to give my opinion about what was said on SmartEiffel and the
team.


Best regards,

Pierre-Nicolas "Pini" CLAUSS