Re[2]: ANN: SmartEiffel 1.2 (transitional) project

Lothar Scholz <[email protected]> Thu, 26 May 2005 12:18:59 +0200
Newsgroups gmane.comp.lang.eiffel.smalleiffel
Organization Scriptolutions
Message-ID <[email protected]>
Hello Francois,

Thursday, May 26, 2005, 10:54:24 AM, you wrote:

FC> Daniel F Moisset a écrit :

>>
>>The second best option (to me) after an standard, is a high-quality
>>open-source implementation. It has to be so good that it establishes
>>itself as a defacto standard. There is no such thing today; SE has a lot
>>of unpolished edges, 
>>

FC> could you please develop this point and enumerate which are these 
FC> "unpolished edges" ?

FC> I had the impression that the purpose of the SE team was also to have a
FC> "so good"
FC> compiler " that it establishes itself as a defacto standard".

FC> What did they miss ?

For example exception handling. If you use exception handling you
simply can't develop code anymore as you will not get any information
about the crashing position anymore.

A standard library that still does not let you do a fseek and many
other things.

A garbage collector that is garbage (it runs into endless invokation
loops in a lot of use cases eating up to 90% of a total program
running time).

A missing "storage" implementation.

A useable (not that slow) debugger. Emiting C line directives would be
enough to use a c level debugger but this was never considered for some
unkown reason, Friedrich Dominicus and Jacob Navia had something like
this with the wedit environment but this was once more removed because
Dominque didn't care and broke backward compatibility once again.
After this they gave up.

Missing Multi Threading. Like it or like it not. We don't need a
fucking theoretical SCOOP we need something that works and we need it
now. Also SCOOP has nothing to do with multithreading (shared memory),
its a multiprocess implementation. So they are disjunct.

A useable compiler speed when your source code exceeds 150.000 lines
(easy even for smaller projects when you use gobo,eposix and a gui library excessively).

Compatibility for years, even if it gets ugly. We don't need a nice
language but a language that protects investment.

FC> Why not to help the present SE team to "polish" its compiler, rather
FC> than doing a new one?
FC> Is it so badly written ?

They refused any help in the past. And there is no sign that they want
to change it now.

Lets face reality, there is no way to work with the Smarteiffel team.
We need a useable real world compiler and not a research project that nobody
cares about (just the few people who want to get a Ph.D at loria). And if we
continue in this way nobody needs Eiffel anymore in two or three years.

Seems that you didn't follow this newsgroup or other eiffel resources.
All people are so pissed off with the current situation that no
promising new project was started in the last two years. The serious
warning after losing the WxEiffel project was completely ignored. SmartEiffel
now just less then a toy language as too many things are missing and the gap
is getting larger and larger every day when you compare it to other languages.


-- 
Best regards,
 Lothar                            mailto:[email protected]