Sunday, June 11, 2006
SmartEiffel is dead. Long live SmartEiffel!
It's not surprising that SmartEiffel has lost much of its user base over the past few years.
After the release of version 1.1 everything went quiet for over a year. The SmartEiffel team promised that those who waited patiently would be rewarded with something fantastic.
When this fantastic thing arrived, the download was much bigger than SmartEiffel 1.1, and took much longer to compile our projects. And, most importantly, it broke virtually every existing library and tool. In response to the despair that this generated, Dominique Colnet suggested that we didn't need to worry about outside libraries anymore, because pretty much everything useful was now included with SmartEiffel.
By a herculean feat, Eric Bezault eventually got Gobo to work with SmartEiffel 2.1. As if to kick sand in his face, the SmartEiffel team then removed the case-insensitive option upon which Gobo depended. This was enough to drive Gobo and ePOSIX away from SmartEiffel 2.x. It didn't help that the SmartEiffel Public Relations spokesman wrote this:
The show-stopper for me is licensing. I am hoping that Amber for Parrot can be included with the Parrot Virtual Machine. That requires my contributions to use a license compatible with both the GPL and Perl's Artistic License. Furthermore, the license must cover the Eiffel runtime too, because I distribute the C-package generated by the Eiffel compiler - and it includes runtime code.
The SmartEiffel team kindly modified the licensing for SmartEiffel 2.2 to make this possible (thanks!).
Also, in my opinion, the SmartEiffel team have done some great things (in addition to disasters such as the smiley operators and the loss of the case-insensitive option).
The "select" keyword is gone, together with the anomalies that it entailed. Anchored declarations have been cleaned up nicely. Expanded types have been reworked in a way that is a little less expressive but much safer.
And all this is being done in a way that simplifies the language. A nice achievement! I look forward to the publication of the paper that documents the new type system.
I'd much prefer that Bertrand Meyer and Dominique Colnet had seen eye-to-eye about the evolution of Eiffel. Given that they couldn't reach agreement, I think it has turned out as well as it could have under the circumstances, for both SmartEiffel and EiffelStudio.
SmartEiffel is dead. Long live SmartEiffel!
After the release of version 1.1 everything went quiet for over a year. The SmartEiffel team promised that those who waited patiently would be rewarded with something fantastic.
When this fantastic thing arrived, the download was much bigger than SmartEiffel 1.1, and took much longer to compile our projects. And, most importantly, it broke virtually every existing library and tool. In response to the despair that this generated, Dominique Colnet suggested that we didn't need to worry about outside libraries anymore, because pretty much everything useful was now included with SmartEiffel.
By a herculean feat, Eric Bezault eventually got Gobo to work with SmartEiffel 2.1. As if to kick sand in his face, the SmartEiffel team then removed the case-insensitive option upon which Gobo depended. This was enough to drive Gobo and ePOSIX away from SmartEiffel 2.x. It didn't help that the SmartEiffel Public Relations spokesman wrote this:
I think it is better for you not to rely on Gobo. By using the library provided with SmartEiffel, you'll have less broken code in the future.
Knowing that Eric Bezault is a major actor of the definition of ECMA Eiffel, relying on Gobo means that you prefer ECMA Eiffel. So, if you go for Gobo, do not complain after that that Gobo is no longer supported by (Smart)Eiffel.
So, you have two possibilities: Gobo+ISE or SmartEiffel.
Trying Gobo+SmartEiffel is a bad mixture.
Have a good day,
PS: what is missing in our library ? As far as I know, you got more than Gobo.So why would anyone use SmartEiffel 2.x for any non-academic purpose? Well, I'm using it for my Amber for Parrot project, and for me it's the best of the available options.
The show-stopper for me is licensing. I am hoping that Amber for Parrot can be included with the Parrot Virtual Machine. That requires my contributions to use a license compatible with both the GPL and Perl's Artistic License. Furthermore, the license must cover the Eiffel runtime too, because I distribute the C-package generated by the Eiffel compiler - and it includes runtime code.
The SmartEiffel team kindly modified the licensing for SmartEiffel 2.2 to make this possible (thanks!).
Also, in my opinion, the SmartEiffel team have done some great things (in addition to disasters such as the smiley operators and the loss of the case-insensitive option).
The "select" keyword is gone, together with the anomalies that it entailed. Anchored declarations have been cleaned up nicely. Expanded types have been reworked in a way that is a little less expressive but much safer.
And all this is being done in a way that simplifies the language. A nice achievement! I look forward to the publication of the paper that documents the new type system.
I'd much prefer that Bertrand Meyer and Dominique Colnet had seen eye-to-eye about the evolution of Eiffel. Given that they couldn't reach agreement, I think it has turned out as well as it could have under the circumstances, for both SmartEiffel and EiffelStudio.
SmartEiffel is dead. Long live SmartEiffel!
posted by Roger Browne @ 14:53 
Comments:
<< Home
I miss a little the ability of writing "like Result" in local entities or create instructions. But yes, I'm using SE 2.2 too...
And I also miss a little having a transparent way of mixing non expanded types with expanded ones in moments when I really need it.
But overall I am happy using SE. My only fear is how long will our programs last; SmartEiffel has a long tradition of breaking compatibility with itself that should be broken if they want to have more users trusting it.
And I also miss a little having a transparent way of mixing non expanded types with expanded ones in moments when I really need it.
But overall I am happy using SE. My only fear is how long will our programs last; SmartEiffel has a long tradition of breaking compatibility with itself that should be broken if they want to have more users trusting it.
Don't forget the SmartEiffel 1.2rX releases. They work perfectly well with Gobo and eposix and I use them a lot.
Until I suppose the Gobo Eiffel compiler works for me.
But the results of the latest International Eiffel Programming Contest were telling: almost no one uses SmartEiffel anymore.
Let's face it, SE has retreated in its own world with people all writing their own libraries. A bit like Sather.
A pity really.
Until I suppose the Gobo Eiffel compiler works for me.
But the results of the latest International Eiffel Programming Contest were telling: almost no one uses SmartEiffel anymore.
Let's face it, SE has retreated in its own world with people all writing their own libraries. A bit like Sather.
A pity really.
Berend: I can't use SmartEiffel 1.2 for my project because its licensing causes problems if you want to distribute the generated C code.
The change to a BSD license for the libraries and runtime in SmartEiffel 2.2 has solved that problem for me.
Daniel: I'm not worried about how long my programs will last. Now that the licensing is unrestrictive, I'll fork SE2.x if necessary.
What DOES worry me is that, with two incompatible Eiffel dialects, half of the cool tools and libraries are only going to be available for whichever compiler one is not using. And that's going to make BOTH platforms less commercially viable.
Berend: Very perceptive about the similarities with Sather. Sather showed how to fail by choosing a dialect different from that of the market leader, even with a leaner, faster compiler plus better libraries.
The change to a BSD license for the libraries and runtime in SmartEiffel 2.2 has solved that problem for me.
Daniel: I'm not worried about how long my programs will last. Now that the licensing is unrestrictive, I'll fork SE2.x if necessary.
What DOES worry me is that, with two incompatible Eiffel dialects, half of the cool tools and libraries are only going to be available for whichever compiler one is not using. And that's going to make BOTH platforms less commercially viable.
Berend: Very perceptive about the similarities with Sather. Sather showed how to fail by choosing a dialect different from that of the market leader, even with a leaner, faster compiler plus better libraries.
Colin: Please be serious! GEC is not (yet) a production-grade compiler.
Also, I don't think the C-code generated from EFL2-licensed source code is compatible with the Perl Artistic License, a requirement which I have for this project.
Also, I don't think the C-code generated from EFL2-licensed source code is compatible with the Perl Artistic License, a requirement which I have for this project.
Colin: The generated C code is a derived work. The terms of the Eiffel Forum 2 License require that the copyright notice is retained unchanged in the derived work (unless the derived work is a binary).
But the Eiffel compiler takes all the sources and weaves them into a C-system without being able to attach the right copyright notice to the right pieces of the derived work.
Even if that were somehow not a problem, the Parrot guys aren't going to want to have yet another license to scrutinise. The interaction between SmartEiffel's BSD license and the licenses used by the Parrot project is already well-understood and non-problematic.
But the Eiffel compiler takes all the sources and weaves them into a C-system without being able to attach the right copyright notice to the right pieces of the derived work.
Even if that were somehow not a problem, the Parrot guys aren't going to want to have yet another license to scrutinise. The interaction between SmartEiffel's BSD license and the licenses used by the Parrot project is already well-understood and non-problematic.
> The terms of the Eiffel Forum 2 License require that the copyright notice is retained unchanged in the derived work (unless the derived work is a binary).
The license says "any distribution of this package, whether modified or not, includes this license text."
This clearly does not cover the generated C code, as it is not a re-distribution of GEC. One might argue that the C runtime (included in your C code) is a modified re-distribution of a portion of GEC, but only if they are a scum sucking lawyer, because that's a false interpretation of "distribution of this package".
But I'm no lawyer, and I don't think you are either Roger. How did you come to your conclusion based on the text of the license?
If it truly is a problem, and you can show good evidence to Eric that it is, then I'm sure a solution can be found. For example, maybe the C runtime can be under a different license?
The license says "any distribution of this package, whether modified or not, includes this license text."
This clearly does not cover the generated C code, as it is not a re-distribution of GEC. One might argue that the C runtime (included in your C code) is a modified re-distribution of a portion of GEC, but only if they are a scum sucking lawyer, because that's a false interpretation of "distribution of this package".
But I'm no lawyer, and I don't think you are either Roger. How did you come to your conclusion based on the text of the license?
If it truly is a problem, and you can show good evidence to Eric that it is, then I'm sure a solution can be found. For example, maybe the C runtime can be under a different license?
Brian: It's well-established in copyright law that distribution of a derived work is protected in the same way as distribution of the original work.
The Perl Foundation has to contemplate dealing with what you call "scum sucking lawyers", which they do by being choosy about the licensing of code proposed for inclusion in Parrot.
The generated C code is a derived work whose original works are the application's source code, the library source code, and the runtime source code.
That's why the Eiffel Forum License makes special provision to allow liberal binary distribution - and similar special provision would be needed to allow liberal distribution of the generated C-code.
The GEC license is not an issue for me. There are other reasons why GEC is not mature enough for use in this project.
Post a Comment
The Perl Foundation has to contemplate dealing with what you call "scum sucking lawyers", which they do by being choosy about the licensing of code proposed for inclusion in Parrot.
The generated C code is a derived work whose original works are the application's source code, the library source code, and the runtime source code.
That's why the Eiffel Forum License makes special provision to allow liberal binary distribution - and similar special provision would be needed to allow liberal distribution of the generated C-code.
The GEC license is not an issue for me. There are other reasons why GEC is not mature enough for use in this project.
<< Home
