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]