SmartEiffel shortcomings?

Lothar Scholz wrote:

[1:]
> ... If you use exception handling you
> simply can't develop code anymore as you will not get any information
> about the crashing position anymore.

Yeah, this limitation really stops us from taking full advantage of the
power of Design by Contract. For my amber compiler I have two versions
of the root class - one with exception handling and one without. If I
get a contract failure I switch to the version without exception
handling so that I can get my stack trace. Having to do that does suck a
bit.

[2:]
> A standard library that still does not let you do a fseek and many
> other things.

If I had a dollar for every time someone had asked for that over the
past 10 years!

[3:]
> 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).

My applications tend not to be memory-intensive, so I haven't had this
problem myself. But I've certainly heard others apart from Lothar
mention it too.

[4:]
> A missing "storage" implementation.

Yeah. Something like this is more-or-less expected nowadays.

[5:]
> 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...

An embedded debugger has some advantages if compiling to multiple
backends (JVM, C, etc). Certainly there's vast room for improvement to
the current debugger.

[6:]
> 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.

We had Miguel Oliveira e Silva's "ThreadSafe SmallEiffel -0.74" which
could have been used as a starting-point:
http://eiffelzone.com/esd/threadse/index.html

[7:]
> A useable compiler speed when your source code exceeds 150.000 lines

There is considerable potential to improve the speed of SE2.

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

OK. But you've got to decide what it is that you want compatibility
with. Do you want compatibility with SmartEiffel 1.1? Do you want
compatibility with other Eiffel compilers so that you can run more
libraries? Do you want compatibility with other _future_ Eiffel
compilers? You can't have compatibility with everything at once.

To Lothar's points, I add two more:

[9:] A decent GUI library, and
[10:] Smooth support for dynamic library generation and use

> FC> Why not to help the present SE team to "polish" its compiler, rather
> FC> than doing a new one?
> They refused any help in the past. And there is no sign that they want
> to change it now.

I wonder where SmartEiffel would be now if the team had adopted a more
open attitude towards outside contributions?

> We need a useable real world compiler and not a research project

Fair enough, but it's not loria's job to deliver usable real world
compilers. We are very lucky to get a somewhat-usable compiler that's
part real-world and part ivory-tower, for free.

> And if we
> continue in this way nobody needs Eiffel anymore in two or three years.
> ...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.

And it's going to get much worse with the coming fragmentation as various
Eiffel compilers implement various bits of ECMA Eiffel in various
incompatible ways.

So let me throw open a question to the readers of this list:

   If a credible, very open, fork of SmartEiffel became established,
   what would YOU contribute?

I especially ask that of Lothar :-)

Regards,
Roger
-- 
Roger Browne <[email protected]>