Eiffel now Open Source on 13 Mar 2007

0 views
Skip to first unread message

ryan...@gmail.com

unread,
Mar 13, 2007, 2:32:50 PM3/13/07
to tirania.org blog comments.
Bertrand Meyer is kind of obnoxious. Several years ago, he wrote an
article for Software Development Magazine condemning the open source
software movement and accusing open source advocates of perpetrating a
"campaign of hate" against proprietary software developers. The Eiffel
source code is being opened up now as a last resort because the
programming language has lost virtually all of its relevance.

Miguel de Icaza

unread,
Mar 13, 2007, 5:59:23 PM3/13/07
to tirania.org blog comments.
Hello,

Not everyone understood open source the day it was launched.

Look at Sun and Java, they have a history of decades of resisting the
open sourcing of Java, it took a long time, but they eventually
changed their mind.

Like someone said "wise people change their minds" ;-)

Miguel.

manu....@gmail.com

unread,
Mar 14, 2007, 12:33:21 AM3/14/07
to tirania.org blog comments.
If you read the original article till the end (http://www.apostate.com/
programming/bm-freesoftware.html) you will realize that Bertrand Meyer
was actually proposing a new way (thus the title of the article) to
embrace/recognize/encourage/promote a vision of open source software.

Manu

kno...@gmail.com

unread,
Mar 14, 2007, 5:07:48 AM3/14/07
to tirania.org blog comments.
And do we have an Eiffel# open source compiler?

alei...@gmail.com

unread,
Mar 14, 2007, 5:21:16 AM3/14/07
to tirania.org blog comments.
Dear Miguel,

fwiw, I vaguely remember that we had this discussion at the Laser
summer school in Elba last summer, but: in my understanding defensive
programing and design by contract are quite different beasts and I am
not so sure I am alone in this. To quote wikipedia on defensive
programming "A difference between defensive programming and normal
practices is that nothing is assumed. All error states are accounted
for and handled. In short, the programmer never assumes a particular
function call or library will work as advertised, and so handles it in
the code.". Also note how assertions and design by contract are listed
as "other techniques" in the article on defensive programming.

Let me try to clarify: with defensive programming you do not assume
anything, in particular that means as the called site you cannot
assume that the calling site is bound by any kind of precondition. For
example, the documentation says: "the argument to this function must
never be null". That's an informally stated precondition. A defensive
programmer must still write the function implementatoin so that it
handles the case where the argument _is_ null gracefully. Which seems
like a great idea, however it has several drawbacks. First, it has a
tendency to hide the error and push the symptoms further away from the
cause. Second, when several layers interact it is quite likely that
the same defensive checks need to be restated in many places causing a
performance degradation. Note that the defensive checks belong to the
program behavior (implementation) and cannot be disabled like
assertions checks.

On the other hand, with design by contract you _do_ assume certain
behavior and you use contracts to check breaches as early as possible.
In the case above where the argument to a function must not be null,
you state this as a formal precondition "arg != null" and be done with
it. The implementation (and note that the precondition does not belong
to the functions implementation) is no longer concerned with the
sitation in which the argument is null. This case is caught by the
debugger (or prover) instead. You establish a clear and formal basis
on which the calling site and the called site can interact. The
english words "the argument to this function must never be null" might
be quite unambigous, but we all know how ambigous human language is
and even this simple sentence cannot be verified by a machine
automatically. You also safe some performance since the checks, once
you trust that your code is reasonably correct, can be turned off.

Andreas

Miguel de Icaza

unread,
Mar 15, 2007, 6:16:52 PM3/15/07
to tiraniaorg-b...@googlegroups.com
Hello,

And do we have an Eiffel# open source compiler?

Manu touched on this subject on his blog entry (forgot the url, but its googable).

Basically, the Eiffel compiler currently uses Microsoft APIs to generate the CIL bytecodes.   This is an unmanaged API (I believe it is COM based), and since Mono does not provide this API it is not possble to run the Eiffel compiler today in Unix to generate Mono executables.

But the executables produced by Eiffel for .NET will run on Mono.

It sounds like a fantastic area for folks to contribute.


Miguel de Icaza

unread,
Mar 15, 2007, 6:18:13 PM3/15/07
to tiraniaorg-b...@googlegroups.com
Andreas,

    I agree with you.   But for those of us coming from a sloppier world, the use of assertions constitute a big step and is considered defensive.   You live in a crisper cleaner world and your standards are probably more elevated.

Best wishes,
Miguel.

alei...@gmail.com

unread,
Mar 16, 2007, 5:07:25 AM3/16/07
to tirania.org blog comments.
Dear Miguel,

On Mar 15, 11:18 pm, "Miguel de Icaza" <miguel.de.ic...@gmail.com>
wrote:

You mean ivory tower, right (; But you are perfectly right assertions
are already a very
very important step forward and I agree that they provide immediate
benefits. I just would also
call the step towards assertions a step away from defensive programing
(;

To answer another question from above, Eiffel# was a temporary
language. Eventually full Eiffel was
supported on .NET. And yes the .NET backend is just as open source as
the "classic" compiler backend.

Andreas

Reply all
Reply to author
Forward
0 new messages