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

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.
  
- 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.

- 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.

I myself would go with 'D' as this has all the '+' and only one '-'
(the DLL generation).





  
  
  
  
  
  
  



  




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