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

On Sat, Apr 09, 2005 at 01:31:43PM +0200, Lothar Scholz wrote:
> Hello Arnaud,
> 
> Wednesday, April 6, 2005, 2:05:51 PM, you wrote:
> 
> AP> Hello everybody, 
> 
> AP> Do you think SmartEiffel is currently useable for a large commercial
> AP> project? (I think about few dozens thousand lines.). I am looking for
> AP> a language as efficient as C++ (if not more) and really object
> AP> oriented. I like the idea of contract programming and all the Eiffel
> AP> stuff but I am a little bit scared because I am currently reading a
> AP> lot of your mail on the Smarteiffel mailing list and you seem to
> AP> hesitate on very basic problems like the implementation of REAL /
> AP> INTEGER type. Can you say me if Smart Eiffel is useable for
> AP> large-scale application?
> 
> Okay, you have to talk to me :-)
> 
> No matter what other people tell you, as far as i know i'm the only
> one who ever did this. A large commerical system (no 280000 lines
> without counting the used smalleiffel/gobo/eposix libraries) that has
> to be __competitive__ with other desktop programs.
> 
> What the other people do is small tools, none of them outside the
> small server, pure algorithmic (ie: compiler) range.
> 
> So would i do it again:  No.
> 
> There are a few pluses of smalleiffel (i'm still not upgraded to
> smarteiffel) and smarteiffel.
> 
> + excellent performance, almost the best you get in OO now
>   (especially if you switch the GC with the boehm weisser
>   implementation) i think in a game you must do this as this GC
>   is incremental where SE is a very primitive non incremental mark and
>   sweep
> 
> + very good error reports when the application crashs.
>   I don't know any tool for C/C++ where you can almost immediately fix
>   a bug send as 14 kB stack trace by a customer.
> 
> but the minus are important:
> 
> - don't expect that your code runs on tomorrows new compiler release
>   anymore. Dominique and the team always pointed out that this is a
>   pure research project and they are not interested in any users
>   problems with backward portability.
> 
> - speed of the new smarteiffel compiler is terrible slow.
>   Your team members will curse you every day if they must use it on a
>   daily base. You will also loose a lot of money because the
>   edit-compile-debug cycle takes time, it is not better then C
>   compiler in the early 80'th of last century.
>   While you can speed up the C compilation stage very easily with a
>   short script on a dual CPU system and using for example Borlands C
>   compiler you are doomed in the Eiffel->C phase.

Question about this:  Do you find bugs so much faster that you don't
have to do as many compiles?  That might make up for it.

>   
> - Eiffel is very verbose. I found myself always putting as much
>   functionallity into one class to avoid the handling of 100 files,
>   for compiler and editor performance. Java has the same problem so
>   maybe this is not a problem for you.

The verbosity is what really gets to me.  Same in Modula-3, which I've
had extensive experience with.

Why is it that every object-oriented language is so wordy?  Java escapes
the long-keywords plague, but uses long standard-library names instead.

> 
> - Very few useable runtime libraries. Prepare yourself that you have
>   to write anything on your own. You can use eposix or the new net
>   cluster but they are acient technologies, dated back into the 70ies
>   of last century forcing you to do something like "select". I doubt
>   that you can use "select" in a game application. To many problems,
>   especially when you must incorporate a millisecond precise event
>   loop.
> 
> - No DLL generation.
>   This is maybe a knock out criterium in team programming and
>   distribution of programs. But i think it's okay for a game where
>   you must garantee that it runs and can't distribute patches.
> 
> - No shared memory Threading.
>   This is definetely a knock out critierum for any serious
>   programming like a game. I prevent this problem with the fact that
>   i call out to python when i need threads. Not elegant but okay.
>   It eats up money because you must put a lot of time into lot of
>   design.
> 
> So decide yourself.
> 
> Unfortunately there are not so many options left.
> I would suggest looking into 'D', 'Object-C++' and maybe even 'Visual
> Works Smalltalk'. A few games are written with VW.

Just to round out the list:  Have a look at Modula-3.  It is NOT,
I repeat NOT, the same as Modula-2.

Oh yes.  Modula-3 does do shared libraries, garbage-collection, and
shared-memory parallelism.  I think it even does all this with native threads.
I've heard that the 911 emergency response system in Montreal
was implemented using Modula-3, and that they are quite happy
with it.  It does seem to be quite good for reliability.

And it's available on a lot of platforms.  On Windows, though, it uses
the Microsoft linker, so you already have to have a Microsoft
compiler installed (but it doesn't seem to matter much what language
the Microsoft compiler compiles, as far as I know.  Modula-3 just
uses the linker.)

-- hendrik

> 
> I myself would go with 'D' as this has all the '+' and only one '-'
> (the DLL generation).
> 
 
> -- 
> Best regards,
>  Lothar                            mailto:[email protected]
>