SmartEiffel officially announced that they will fork
Berend de Boer
Hash: SHA1
Hello All,
People not reading the SmartEiffel mailing list might not be aware
that they officially announced to fork Eiffel:
From: Colnet Dominique <Dominiqu...@loria.fr>
Subject: Re: ECMA standard or forking the language?
Paolo Redaelli wrote:
> Jokes apart I'm sure that this question has been discussed many times
> among the SE team. What's SmartEiffel's team judgement about incoming
> ECMA standard?
Yes this was discussed many times.
We have no other reasonable choice than to fork.
But don't be afraid, we are ready to do so.
In practice SmartEiffel forked already with 2.x. The SmartEiffel team
are playing this as: they departed, not us. But everyone who tried to
use SmartEiffel 2.x already detected that it did no longer compile the
old stuff.
It was SmartEiffel who forked and created an incompatible compiler. To
my knowledge there is no Eiffel library that has any sort of
widespread use that supports SmartEiffel 2.x.
Unfortunately this leaves those wanting to use a Free Eiffel Compiler
just SmartEiffel 1.x to work with. It is reasonably stable, but it is
unfortunate that its garbage collector doesn't work.
SmartEiffel 1.x was the fastest Eiffel compiler for small projects,
and definitely produced the fastest code. I think it still is an
excellent piece of work that with some maintainance can last for many
years.
Would there be any interested in forming a group to at least maintain
the last 1.x release? The target would not be to add major
functionality, just to fix known bugs.
Your comments appreciated.
PS: at this point in time I think it's not helpfulp to hurl any stones
towards the SE team. They've made the decision, there research
produced a good compiler, but they moved on. My guess is that the
community surrounding SE 2.x is definitely too small to survive long
term, but I reckon the SE 1.x community can still grow significantly.
- --
Live long and prosper,
Berend de Boer
(PGP public key: http://www.pobox.com/~berend/berend-public-key.txt)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCdy/aIyuuaiRyjTYRAm/HAKDVfVXflGrtI4+tH8BKIzcgrdyjigCeL8ea
y36Aa9N73zL9tQbZjYF62q0=
=SOhp
-----END PGP SIGNATURE-----
Roger Browne
> Unfortunately this leaves those wanting to use a Free Eiffel Compiler
> just SmartEiffel 1.x to work with.
Not true! Visual Eiffel is also available under the GPL.
> It is reasonably stable, but it is
> unfortunate that its garbage collector doesn't work.
That's easily solved - SmartEiffel 1.x also supports the BDW
conservative GC.
Regards,
Roger Browne
Cyril ADRIAN
Berend de Boer wrote:
>
> In practice SmartEiffel forked already with 2.x. The SmartEiffel team
> are playing this as: they departed, not us.
Please don't extract a small sentence from context. For those who don't read the SE list, please let me make clear our position:
We fork from ECMA Eiffel. We don't feel ECMA Eiffel will bring what it should have: instead of a common Eiffel we all know, ECMA Eiffel has designed a whole new language. We won't follow that path.
In that respect, we think that indeed ECMA Eiffel has forked from Eiffel.
ECMA Eiffel is not Eiffel. (Please note that I don't judge here, if it is a good or bad language. That's another topic.)
SmartEiffel is not old Eiffel either, but it looks more like old Eiffel than ECMA Eiffel ever will.
There is indeed a fork: TWO branches.
Best regards,
Cyril.
Roger Browne
> In that respect, we think that indeed ECMA Eiffel has forked from Eiffel.
In January 2002, Emmanuel Stapf wrote (to the Board of NICE):
"we [ECMA TG4] will be trying to standardize Eiffel as it
exists now ... if we just standardize what ISE feels
Eiffel should be, that will be not good for the standard."
Clearly, the ECMA process has cast adrift from this tether.
Regards,
Roger Browne
Georg Bauhaus
> Please don't extract a small sentence from context.
For those who don't read the SE list, please let me make clear our position:
>
> We fork from ECMA Eiffel. We don't feel ECMA Eiffel will bring what it should have:
instead of a common Eiffel we all know, ECMA Eiffel has designed a whole new language.
We won't follow that path.
Hi Cyril,
do you know of a summary text about possible differences of the
future Eiffel languages, something that can be read in an afternoon
or so?
Georg
Berend de Boer
Hash: SHA1
Roger Browne <ro...@eiffel.demon.co.uk> writes:
>> It is reasonably stable, but it is
>> unfortunate that its garbage collector doesn't work.
>
> That's easily solved - SmartEiffel 1.x also supports the BDW
> conservative GC.
But bdw doesn't call dispose. But it certainly works.
- --
Live long and prosper,
Berend de Boer
(PGP public key: http://www.pobox.com/~berend/berend-public-key.txt)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD4DBQFCd8K0IyuuaiRyjTYRAmJyAJdgTAamKv4wOh1sP9xnIU8CbGIcAJ9ugnZD
WHj6CQcoqZ1O0Qgaryq6+Q==
=ZOCn
-----END PGP SIGNATURE-----
Berend de Boer
Hash: SHA1
Cyril ADRIAN <cyril....@laposte.net> writes:
>> In practice SmartEiffel forked already with 2.x. The SmartEiffel team
>> are playing this as: they departed, not us.
>
> Please don't extract a small sentence from context. For those who
> don't read the SE list, please let me make clear our position:
> We fork from ECMA Eiffel. We don't feel ECMA Eiffel will bring what
> it should have: instead of a common Eiffel we all know, ECMA Eiffel
> has designed a whole new language. We won't follow that path.
What has ECMA Eiffel to do with the whole discussion? No one could
take their SE 1.x code and compile it with 2.x. Code that worked with
ISE Eiffel 5.x, VE 4.x/5.x and SE 1.x doesn't work with SE 2.x.
ECMA Eiffel is completely irrelevant to this discussion.
> SmartEiffel is not old Eiffel either, but it looks more like old
> Eiffel than ECMA Eiffel ever will.
It doesn't. That's the whole point and that's what library writers
have been telling you for more than a year.
Don't bring up ECMA Eiffel as SE 2.x doesn't compile ETL2 Eiffel any
longer.
This is not a discussion about the virtues of ECMA Eiffel.
- --
Live long and prosper,
Berend de Boer
(PGP public key: http://www.pobox.com/~berend/berend-public-key.txt)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCd8OPIyuuaiRyjTYRAg9XAKCYbLmElY4b2YmcUzSS2P+c5yovAQCgt8M1
EJoSHae6dnaCQ80KxJbDqTc=
=1qiy
-----END PGP SIGNATURE-----
Cyril ADRIAN
Georg Bauhaus wrote:
> do you know of a summary text about possible differences of the
> future Eiffel languages, something that can be read in an afternoon
> or so?
There is no official text, but Rechard O'Keefe did a good job at summarizing some points:
http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2005-04/msg00174.html
Maybe it's not exhaistive, but that's a starting point.
The ECMA standard (draft) is available from Mr. Meyer's etl3 page (look at section VII in the table), but it's quite long.
Best regards,
Cyril
peter_...@hotmail.com
> ECMA Eiffel is not Eiffel.
By that logic, C# 2.0 is not C#!
ECMA Eiffel sure looks like Eiffel to me. There are additions to the
language and a few incompatibilities, but it's definitely Eiffel.
- Peter Gummer
Cyril ADRIAN
> ECMA Eiffel is completely irrelevant to this discussion.
I just fixed what you said with our FULL statement.
That's all I wanted to say.
For as long as I knew Eiffel (that will be ten years in September) there have always been a very bad spirit with very vindicative people. I'm happy to get free of all that.
The show will not go on. I quit this newsgroup, and good riddance.
Ciao
Friedrich Dominicus
> Berend de Boer wrote:
>> ECMA Eiffel is completely irrelevant to this discussion.
>
> I just fixed what you said with our FULL statement.
>
> That's all I wanted to say.
>
> For as long as I knew Eiffel (that will be ten years in September)
> there have always been a very bad spirit with very vindicative
> people. I'm happy to get free of all that.
Well you feel happy? Well it's easy to blame others. The question is
what is the real point. The point you cloud is the fact that
Small/SmartEiffel always was and still is a subject of
research. What's interesting and "promising" is implemented and well
all the "crufty" thinks like backward compatability is dropped. It's
ok for me to do that but then you should not have to keep a name of a
"sort-of" standardized language in your name. It was agreed upon even
by the SmallEiffel people that the standard is what NICE proposed,
everyone was free to put in requests for improvements there. NICE base
line was, "the language described in ETL 2". So if you can not compile
stuff from ETL2 you do not have an Eiffel.
>
> The show will not go on. I quit this newsgroup, and good riddance.
Do as you like. Good luck with your language development
undertakings and "proof-of-concept" software.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Georg Bauhaus
>>do you know of a summary text
> There is no official text, but Rechard O'Keefe did a good job at summarizing some points:
Thanks for the pointers.
-- Georg
Philippe Ribet
> [...] So if you can not compile
> stuff from ETL2 you do not have an Eiffel.
>
As the latest compiler incorporates some incompatibles changes from
ETL3/ECMA, you'll for sure not be able to compile all ETL2 valid programs.
Regards,
--
Philippe Ribet
The README file said
"Requires Windows 95, NT 4.0, or better."
So... I installed it on Linux!
Thomas Beale
> Hi Georg,
>
> Georg Bauhaus wrote:
>
>>do you know of a summary text about possible differences of the
>>future Eiffel languages, something that can be read in an afternoon
>>or so?
>
>
> There is no official text, but Rechard O'Keefe did a good job at summarizing some points:
>
> http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2005-04/msg00174.html
>
> Maybe it's not exhaistive, but that's a starting point.
from the thread on the SE group, Richard O'Keefe said:
> But eliminating !! creation syntax, ?= assignment attempt, << >> array
> literals, and (x + y).f plain-parenthesised targets in calls, amongst
> other things, DO break lots of code, without sufficient reason.
I can't imagine the first or last of these breaking much code, and <<>>
is not commonly used, but losing it will certainly break code. But ?= -
is this really disappearing? What replaces it? This will break a lot of
code...
but then again, being forced to revisit old code and make it better
might not be a terrible thing?
- thomas beale
peter_...@hotmail.com
> ?= - is this really disappearing? What replaces it?
I believe the plan is that assignment attempt will be replaced by
"object test":
if {x: SOME_TYPE} some_expression then
-- x is not void, so do something with it
end
Object test is part of the new void-safety mechanism. I personally
would have found this more legible:
if {x: SOME_TYPE} := some_expression then
I highly recommend reading Richard O'Keefe's post to the SmartEiffel
mailing list. Richard listed 8 or so changes in ECMA Eiffel that he
believes will break existing code. Cyril Adrian posted the link earlier
in this thread.
Personally I think this is the price of progress, and I trust ISE
Eiffel and Visual Eiffel to introduce these changes with care, to avoid
breaking code as much as possible. All of the changes listed by Richard
look good to me, except the new (|...|) target expression syntax which
I think just looks ugly and confusing without really solving the
problem it was intended to fix.
- Peter Gummer
Paolo Redaelli
> On Tue, 2005-05-03 at 20:01 +1200, Berend de Boer wrote:
>
>> Unfortunately this leaves those wanting to use a Free Eiffel Compiler
>> just SmartEiffel 1.x to work with.
>
> Not true! Visual Eiffel is also available under the GPL.
I suspect it isn't that simple.
Visual Eiffel's authors haven't really
understood what GPL means. Infact I think they have misunderstood it!
Read GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html and then Visual
Eiffel FAQ at http://visual-eiffel.org/Faq_license . I'm sure you will
spot many incongruences as I did; infact it says:
>In what ways can I use VE-OS? You can freely use VE-OS for any purpose
>except to produce proprietary software applications. The kernel library
>of
>VE-OS is GPL-licensed, and every application produced by VE-OS depends on
>the kernel library. Therefore, applications produced using VE-OS can only
>be distributed under the GPL.
True.
>Specifically, you must also distribute the
>source code.
Wrong. GPL does not require you to distribuite the sources, even if it
often done. Read
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
>What if I want to produce proprietary software?If you want to produce
>proprietary software, you should purchase Visual Eiffel Enterprise. The
>license for Visual Eiffel Enterprise allows you to distribute proprietary
>software. Visual Eiffel Enterprise is also eligible for enhanced support
>offerings
It is an interesting byproduct of the kernel library being released under
GPL and a proprietary license (in the Enterprise version).
>Can I use VE-OS to develop in-house commercial applications?No - this is
>explicitely forbidden by the Visual Eillel License. Even it this would
>not be the case, it would not be appropriate as the GPL would allows you
>to do this. Those in-house commercial applications would themselves be
>subject to the GPL, and you would have to make the source code available
>(to anyone that you distribute the binary to). That person could then
>redistribute the application (under the GPL), which might put them in
>conflict with their terms of employment.
This is at least debatable. A GPL compiler with a GPL kernel library CAN
be used for in-house commercial application. Note that they seem to
misunderstand that GPL is not the opposite of commercial. There are GPLed
commercial software; AFAIK the GNU ADA compiler it's an example of this.
Again GPL FAQ helps here.
>Can I modify the VE-OS compiler or libraries? Yes. If you distribute your
>modifications, you must distribute them under the GPL.
True
>Can I port VE-OS to a new operating system? Yes. If you distribute your
>port, you must distribute it under the GPL.
True
> Can I contribute my enhancements back into VE-OS?Yes, we welcome
>contributions. But Object Tools can only accept your code into our Visual
>Eiffel codebase if you give us permission to include the code in both of
>our editions - Open-Source and Enterprise. We will ask you to confirm
>this by email or webform before we can accept your patch.
Oh nice; it seems to me that they basically ask you to give up all the
advantages that GPL offers the users over a BSD like license.
>Can I use VE-OS in order to learn and to teach programming ?Yes:Using
>Visual Eiffel in order to teach or to learn programming technology can be
>done under the GPL license unless programs developed are used for
>commercial purposes as described above
Again GPL does NOT mean anti-commercial.
>I use VE only for private, non commercial applicationsIf you are a
>private
>individual you are free to use Visual Eiffel for your personal
>applications (not those of your employer) as long as you do not
>distribute
>them. If you distribute them, you must make a decision between the
>Commercial License and the GPL.
Another byproduct of the choose of GPL license for the kernel library....
Beside this fact VE is good AFAIK; sadly it produces only x86 code....
Paolo
Roger Browne
> > Visual Eiffel is also available under the GPL.
Paolo Redaelli wrote:
> I suspect it isn't that simple.
> Visual Eiffel's authors haven't really
> understood what GPL means. Infact I think they have misunderstood it!
I'm pretty sure that Frieder Monninger (head of Object Tools GmbH)
understands the GPL. I think a lot of what you consider to be
misunderstandings arises simply from language issues (for example they
say "commercial" for what you and Richard Stallman might call
"proprietary").
VE FAQ:
> >Specifically, you must also distribute the
> >source code.
Paolo:
> Wrong. GPL does not require you to distribuite the sources, even if it
> often done.
It's true that you only need to make the sources available, not actively
distribute them. But in these days of cheap bandwidth there's no reason
not to distribute the sources through the same channels as the binary.
> >Can I use VE-OS to develop in-house commercial applications?No
...
> This is at least debatable. A GPL compiler with a GPL kernel library CAN
> be used for in-house commercial application.
This is an interesting and subtle point. Clearly, Object Tools wants to
forbid this. Although, as you say, OT can't physically (or legally) stop
companies from writing in-house software using Visual Eiffel, they can
point out that it is a commercially unsafe practise. Any employee
> Note that they seem to
> misunderstand that GPL is not the opposite of commercial. There are GPLed
> commercial software; AFAIK the GNU ADA compiler it's an example of this.
I guarantee you that OT understands this.
> > Can I contribute my enhancements back into VE-OS?Yes, we welcome
> >contributions. But Object Tools can only accept your code into our Visual
> >Eiffel codebase if you give us permission to include the code in both of
> >our editions - Open-Source and Enterprise...
> Oh nice; it seems to me that they basically ask you to give up all the
> advantages that GPL offers the users over a BSD like license.
Yeah ... Object Tools would like to retain some chance of deriving an
income from the Enterprise edition. That's fair enough.
Remember that this policy only applies to the Object Tools distribution
of Visual Eiffel, so you can still maintain and distribute a pure-GPL
version yourself if you want "all the advantages that GPL offers the
users over a BSD like license".
> >Can I use VE-OS in order to learn and to teach programming ?Yes:Using
> >Visual Eiffel in order to teach or to learn programming technology can be
> >done under the GPL license unless programs developed are used for
> >commercial purposes as described above
> Again GPL does NOT mean anti-commercial.
Sure. The "as described above" just means that you have to make the
sources available for proprietary applications. The assumption in this
question/answer pair is that the educational use of the software is not
intended to produce proprietary applications.
> Beside this fact VE is good AFAIK; sadly it produces only x86 code....
For me the disappointment is that incompatible licenses means that the
VE and SmartEiffel kernel libraries cannot be intermingled and thereby
made compatible with each other. The SmartEiffel kernel is under a very
permissive license, but one which is not GPL-compatible.
Regards,
Roger
Georg Bauhaus
>>Specifically, you must also distribute the
>>source code.
>
> Wrong. GPL does not require you to distribuite the sources, even if it
> often done.
It is important to be precise here and not to read any of these
sentences out of context. From the perspective of the producer
of software it is important to know their obligations WRT source
code availability to others. Saying plain "Wrong" here is IMHO adding FUD.
It is in general better to have these matters decided by competent
lawyers.
> Read
> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
That's not enough. Besides, these partial statements talk spcifically about
modified source text only, AFAICS.
regards
- Georg
William James
> QEIF: What is Eiffel?
>
> Eiffel is an advanced object-oriented programming language and
> method that emphasizes the design and construction of
> high-quality and reusable software.
Berend de Boer wrote
> It was SmartEiffel who forked and created an incompatible
> compiler. To my knowledge there is no Eiffel library that has
> any sort of widespread use that supports SmartEiffel 2.x.
> Code that worked with ISE Eiffel 5.x, VE 4.x/5.x and SE 1.x
> doesn't work with SE 2.x.
> ....
> ... SE 2.x doesn't compile ETL2 Eiffel any longer.
In another thread Roger Browne wrote
> When SmartEiffel 2.0 was released, I posted to the SmartEiffel
> list, lamenting that Gobo would not run on it. Dominique Colnet
> suggested that I should write my parser by hand instead of
> using gelex/geparse.
So the implementors of SmartEiffel have no desire to make it
possible to reuse software. They don't care whether programmers
are able to use existing libraries. It doesn't bother them that
they are forcing users of SE and writers of libraries to reinvent
the wheel over and over and over.
At wwsympa.loria.fr/wwsympa/arc/smarteiffel/2005-04/msg00176.html
Richard A. O'Keefe says
> All the changes to the Eiffel language, all the failure to grow
> a standard library or support the de-facto one, all these
> things are so much in Java's favour that a conspiracy theorist
> would be sure there was a fifth column...
>
> To be honest, I am very strongly reminded of the ISO Prolog
> effort, which I was (and remain) on the fringes of. I proposed
> that the committee adopt the ANSI C committee's wise policy,
> which was that the language belonged to the people who were
> already *using* it (programmers, teachers, textbook writers,
> and so on) and not exclusively to the vendors; the committee
> explicitly rejected any such constraint on their inventiveness.
> I've checked the ECMA web site, and they only seem to have
> provision for organisational members (businesses, basically),
> which makes me suspect that Eiffel *users* as such may have
> little representation and their needs little influence.
One's enthusiasm for learning Eiffel is dampened by the knowledge
that the best libraries will not work with SmartEiffel (and may
soon cease to work with commercial Eiffels) and that one would
have to pay $4799 for ISE Eiffel or 695 Euros for Visual Eiffel.
Is there a compiled, object-oriented language that actually would
facilitate the production of reusable software and that would be
a better choice than Eiffel?
Pascal Obry
"William James" <w_a_...@yahoo.com> writes:
> Is there a compiled, object-oriented language that actually would
> facilitate the production of reusable software and that would be
> a better choice than Eiffel?
Ada. I'm not going to say it is better or not. But at least in Ada you can
built reusable software. It is a standard and closely designed with users
around the world. I must say that I like Eiffel much and I'm sad hearing what
is happening to Eiffel.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Philippe Ribet
> The comp.lang.eiffel FAQ states:
>
>
>>QEIF: What is Eiffel?
>>
>>Eiffel is an advanced object-oriented programming language and
>>method that emphasizes the design and construction of
>>high-quality and reusable software.
>
>
>
> Berend de Boer wrote
>
>
>>It was SmartEiffel who forked and created an incompatible
>>compiler. To my knowledge there is no Eiffel library that has
>>any sort of widespread use that supports SmartEiffel 2.x.
>
>
>>Code that worked with ISE Eiffel 5.x, VE 4.x/5.x and SE 1.x
>>doesn't work with SE 2.x.
>>....
>>... SE 2.x doesn't compile ETL2 Eiffel any longer.
>
SE 2.x introduce some latest incompatible changes from ETL3. You can
either continue to use SE 1.1 and ETL2 definition, and reuse all the
code you already wrote, either move to SE 2.x and adapt some old code to
match the current rules.
Please note that moving from 1.1 to 2.1 or 2.2 should be easier than
using 2.0
>
>
> In another thread Roger Browne wrote
>
>
>>When SmartEiffel 2.0 was released, I posted to the SmartEiffel
>>list, lamenting that Gobo would not run on it. Dominique Colnet
>>suggested that I should write my parser by hand instead of
>>using gelex/geparse.
>
>
>
> So the implementors of SmartEiffel have no desire to make it
> possible to reuse software. They don't care whether programmers
> are able to use existing libraries. It doesn't bother them that
> they are forcing users of SE and writers of libraries to reinvent
> the wheel over and over and over.
>
NO NO NO! Please read original Roger Browne's comment up to the end. I
remember it said something like writing his parser by hand is one of the
best advice he never had and was thanking Dominique for that.
Writing parser by hand is not reinventing the wheel at all. It's easy to
do, and it's the possibility to write using a very different parsing
technology, with much better capabilities in error messages handling. Of
course, only those who already wrote both ascending and descending
parsers (or parsing rules) and tried to add fine error messages really
understand.
> Is there a compiled, object-oriented language that actually would
> facilitate the production of reusable software and that would be
> a better choice than Eiffel?
>
As long as you use the same compiler generation, your software is
reusable. As SE is GNU, using 1.1 is 10 years is not a problem.
Best regards,
Roger Browne
> ... the ANSI C committee's wise policy,
> which was that the language belonged to the people who were
> already *using* it (programmers, teachers, textbook writers,
> I've checked the ECMA web site, and they only seem to have
> provision for organisational members (businesses, basically),
> which makes me suspect that Eiffel *users* as such may have
> little representation and their needs little influence.
There have been times when it was different. In the late 1990's, the
Nonprofit International Consortium for Eiffel (NICE) -- which was set up
by Bertrand Meyer to be the Eiffel Standards body -- was making good
progress standardizing some of the library classes.
This work was largely user-driven, but all of the vendor representatives
co-operated, and we did succeed in getting to the point where a useful
subset of ARRAY and STRING was 100% compatible across libraries from
different vendors.
Then Bertrand Meyer announced that he was working on the next revision
of Eiffel outside of NICE (the ETL3 project), and later he announced
that he was pursuing an ECMA (and eventually ISO) standard for the
language described by ETL3.
The draft ECMA standard is the product of a process that involved
extensive (but, as you say, not inclusive) consultation. Therefore, it's
not surprising that there are some aspects of ECMA Eiffel that the
SmartEiffel team can't stomach, and it's not surprising that there
doesn't seem to be much enthusiasm amongst Visual Eiffel users for
implementing some aspects of ECMA Eiffel either.
But deep down I'm an optimist. Eiffel is a three-vendor language (more,
if you count niche products such as Eiffel for the Mac), and that's
pretty good for a non-mainstream language. ECMA Eiffel will sink or swim
on its merits. But Eiffel isn't going to go away.
Regards,
Roger Browne
Berend de Boer
William> One's enthusiasm for learning Eiffel is dampened by the
William> knowledge that the best libraries will not work with
William> SmartEiffel (and may soon cease to work with commercial
William> Eiffels) and that one would have to pay $4799 for ISE
William> Eiffel or 695 Euros for Visual Eiffel.
I don't think that will be the case. SmartEiffel 1.x is still used by
most people.
Note that SmartEiffel is a research project so naturally 2.x is on the
bleeding edge.
William> Is there a compiled, object-oriented language that
William> actually would facilitate the production of reusable
William> software and that would be a better choice than Eiffel?
Pure OO? No.
--
Regards,
Berend.
** you're welcome to the #eiffel irc channel on irc.freenode.net
peter_...@hotmail.com
> William James wrote:
> > ... the ANSI C committee's wise policy,
> > which was that the language belonged to the people who were
> > already *using* it (programmers, teachers, textbook writers,
> > and so on) and not exclusively to the vendors...
> > I've checked the ECMA web site, and they only seem to have
> > provision for organisational members (businesses, basically),
> > which makes me suspect that Eiffel *users* as such may have
> > little representation and their needs little influence.
Hey Roger, William didn't write that. It's a quote from one of Richard
O'Keefe's posts to the SmartEiffel mailing list.
Richard's suspicion is way off beam, isn't it? The draft standard lists
11 ECMA committee members, of whom only 4 are vendors: 3 from Eiffel
Software plus 1 from SmartEiffel.
-- Peter Gummer
Roger Browne
> Hey Roger, William didn't write that.
Sorry I messed up the attribute. Let's try again:
Richard O'Keefe wrote (on the SmartEiffel mailing list):
> > ... the ANSI C committee's wise policy,
> > which was that the language belonged to the people who were
> > already *using* it (programmers, teachers, textbook writers,
> > and so on) and not exclusively to the vendors...
> > I've checked the ECMA web site, and they only seem to have
> > provision for organisational members (businesses, basically),
> > which makes me suspect that Eiffel *users* as such may have
> > little representation and their needs little influence.
Peter wrote:
> Richard's suspicion is way off beam, isn't it? The draft standard lists
> 11 ECMA committee members, of whom only 4 are vendors: 3 from Eiffel
> Software plus 1 from SmartEiffel.
Well let's see. We have Dominique Colnet (SmartEiffel). We have Bertrand
Meyer, Alexander Kogtenkov and Emmanuel Stapf (ISE Eiffel). Then there
are Eric Bezault, Paul Cohen, Mark Howard, Roger Osmon and Kim Walden
(who all work for significant ISE Eiffel customers). Christine Mingins
and Karine Arnout are academic colleagues of Bertrand Meyer. By the way,
Eric Bezault is there as Mr Axa Rosenberg, not as Mr Gobo. And Eric
Bezault and Karine Arnout have also previously worked for ISE.
So although the committee includes some representatives of
commercial/industrial users, there are no "grassroots" Eiffel users. It
would be nice to see some people like Berend de Boer, Brian Heilig,
James McKim, Darren Hiebert, Dustin Sallings, Franck Arnaud, Frank
Boehme, Greg Compestine, Hubert Cater, Ian Joyner, Lothar Scholtz,
Michael Schweitzer, Jim Weirich, Joseph Kiniry, Lyn Headley, Neil
Wilson, Paul Crismer, Steve Thompson, and all the others who have
written commercial Eiffel applications, distributed free Eiffel
libraries, evangelized and taught Eiffel, helped the vendors to debug
their products, helped Bertrand Meyer to refine Eiffel over the years,
helped NICE to standardise the library classes, etc etc.
But Bertrand Meyer doesn't like to work that way. Time and time again he
has strenuously rejected ideas suggested by "free thinkers", only to
adopt those same ideas many years later.
I'm pleased to see, for example, that the ECMA draft specifies that if
evaluation of an "old" expression would raise an exception, the
exception must not be raised immediately but is "stored away" until the
postcondition is evaluated, and the exception is only raised if the
failing sub-expression is actually needed (e.g. is not blocked by "and
then"). This issue was discussed several times in NICE. Everyone else
could see its merits - but Bertrand argued so strongly against it that
no-one was game to push the issue. Now, ten years later, this finally
gets fixed.
Anyway, I'm not going to worry. Contrary to all the spin about language
simplification, ECMA Eiffel is a hugely bigger language. Great swathes
have never been implemented. It's going to be years before much of the
new stuff is implemented. Some parts will never be implemented, and some
will be found to be unimplementable.
I'm happy to devote my energies to real Eiffel products that are here
and working today.
Regards,
Roger