Re: Liberty-eiffel Digest, Vol 53, Issue 9

[Raphael Mack]

Hi,

thanks for all your comments! This kind of discussions (at least if we
go one step beyond) is what make a mailinglist useful and are a sign of
a vital community.

In my eyes SmartEiffel had a lot of issues and maybe the biggest was in
communication. Breaking compatibility cause a lot of people leaving and
as it was an academic project it was somehow understandable, though not
excusable, that making things "good" was counted higher than making
what users need and want.

The beauty of Eiffel lies - in my eyes - in its clarity and the
principle to provide only one way of doing it was somehow there. We
don't need !! and create and it is better to change some code to bring
it to a new style. On the other side, at least a refactoring tool would
be good in such cases. For non-conforming inheritance I personally
prefer the "insert" syntax over "inherit {NONE}" but on the other side
it should not be a big deal to accept both in the parser.

ECMA brought quite some nice improvements which make the language more
modern, but clearly at a cost. While I extremely like the comfort of
dynamic type conversion I hate its side effect that we suddenly get two
objects of different classes for the same thing and even worse, that a
simple assignment suddenly could crash with an out-of-memory-exception.
So it is hard for me to decide whether I want to use that or not, but I
clearly would want it to be implemented for the sake of compatibility
and ECMA compliance. - Ideally with an additional compiler flag to put
it into a conservative mode that works without.

I would wish that Eiffel is used on embedded systems - not big things
like a RaspberryPi but really the small things where we don't do
dynamic memory allocation. Maybe we would need to put a "MISRA-like
ruleset" to constrain the language to fit there but on a desktop
machine I would clearly live with the side effects of conversion.

For a discussion about covariant vs. contravariant agent conformance I
prefer the SmartEiffel dialect from the theoretical point of view -
while I would be perfectly fine in accepting the ECMA version in the
standard mode, keeping our variant in the conservative mode and forcing
in "our MISRA-style ruleset" that we shall not use critical cases in
our libs.

All that said, I would even conclude in a pragmatic approach: If there
is feature a user needs and we can easily do it, then we should discuss
it and if not too problematic implement it, because an Eiffel compiler
without users is as useful as a brainfuck compiler.


You see, I try to discuss technical topics more like than the question
"Will Liberty get "ISE-like?", as this is not important for me. If the
technical topics bring Liberty to be ISE or ECMA-compatible, then be it
so, if not it's also fine for me.

Looking forward to a new Liberty Spring with fruitful and interesting
discussions and code contributions!

Rapha

Am Freitag, dem 18.02.2022 um 09:09 +0100 schrieb Patrick CLOAREC via:
> Hello Peter,
> Le 18/02/2022 à 03:37, Peter Lubke a écrit :
>  
> >  
> > Hello all.
> > 
> > Now, I'm going to ask a serious question.
> > Have you thought about all the ramifications and effects of "being
> > just like ISE"?
> I don't intend to be just like ISE. Actually, by "interoperability" I
> mean at least "share the same language definition", even with
> addition. A compiler with language extension is not the same at all
> than a compiler for a different language.
> I would not try to follow ISE in all its tools, to ensure a full
> project file interoperability. If possible, why not, but that's a
> different job. I don't focus on running directly ace or ECF, or any
> other development tool.
>  
> > 
> > "Interoperability" was an original (1990's) Eiffel
> > principle/goal/dream. 
> > But not a 21st century position at all - at least not from the
> > dominant commercial vendor. No, no, no - very very far from it. And
> > while that makes sense from a business perspective, competition is
> > usually a good thing.
> I worked of years on embedded SW, and one of our first concern was
> the C compiler deviations form standard. Actually, there exists
> standard (such as MISRA) that defines tons of rules to ensure
> portability between compilers and libraries. One of the first rule is
> : "define and use only a subset of the C standard, so you will avoid
> incompatibility between compilers that comply with the C standard".
> Wow.. That is something I would like to avoid with Eiffel
>  Concerning Project files and tools, all IDE have an option "import
> project from xxx IDE". that is a way to deal with environment
> compatibility
>  
> > In full disclosure, the reason I stopped using Gobo Eiffel was that
> > it began to be "just like ISE". It does not compete, it just
> > provides unpaid support. While I think Eric has always done a great
> > job, I just don't agree with the direction of the last many several
> > years, and taking Liberty Eiffel in the same direction - well, you
> > can see where I'm going here.
> I could not blame Eric and gobosoft contributors for  not having
> built something better than ISE. Gobo is different from ISE while
> being compatible, that's a very good thing. I don't like the idea of
> "all development environments do the same things in the same way",
> but I don't like the idea of "2 compilers = 2 languages".
>  
> > 
> > So Liberty Eiffel has been my go to Eiffel compiler in recent
> > years. Not that I use it a lot. Viva la difference! I'm mostly on
> > linux, so gnu is my main compiler set.
> > 
> > The Eiffel community shrunk drastically when "standard" Eiffel was
> > created. 
>  True, but, in my opinion, the SmartEiffel community shrunk
> drastically with the concept of "True Eiffel", which sounded (at
> least to me) a bit like "we are the true believers".
>  
> > 
> > Sometimes, when you get lost the best thing to do is go back to the
> > last place where you knew where you were (if you can).
> > 
> > So I put it to you that if you want to pursue "interoperability",
> > you should do it with something like Rust, Scala or [sacrilege]
> > C++23. 
>  please don't use rude words :-)
>  
> > 
> > Finding a common direction to row in is important for the Liberty
> > Eiffel group if it wants to be active. 
>  I agree, and I'm totally open to discussion.
>  
> > It's just a small fish in a small pond. Do you want to escape to
> > the ocean? or join a larger fish in another small pond? or play
> > with sharks? or just safely build the pond a little larger? It's
> > also important to have a unique direction.
> My point of view is :
> What is the cost of having and keeping a compiler compatible (at
> language level) with ISE ? or even just ECMA-compliant ? (I don't
> like the ECMA document, by the way)
> if that's a doable job, let's do it, so we will have a clear basis
> for further developments, while keeping a language-level
> compatibility within the three compilers. By "development", I mean
> optimization, new tools or language extensions
>  
> > 
> > However, that's just my 20 cents worth (adjusted for inflation).
> > 
> > 
> > 
> >  On Friday, 18 February 2022, 03:03:40 am AEST,
> > liberty-eiffel-request@gnu.org <liberty-eiffel-request@gnu.org>
> > wrote: 
> > 
> > 
> > Send Liberty-eiffel mailing list submissions to
> >     liberty-eiffel@gnu.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> >     https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> > or, via email, send a message with subject or body 'help' to
> >     liberty-eiffel-request@gnu.org
> > 
> > You can reach the person managing the list at
> >     liberty-eiffel-owner@gnu.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Liberty-eiffel digest..."
> > 
> > 
> > Today's Topics:
> > 
> >   1. Re: Liberty-eiffel Digest, Vol 53, Issue 8 (Hans Zwakenberg)
> > 
> > 
> > -------------------------------------------------------------------
> > ---
> > 
> > Message: 1
> > Date: Wed, 16 Feb 2022 18:26:38 +0100 (CET)
> > From: Hans Zwakenberg <hz@ocean-consulting.de>
> > To: liberty-eiffel@gnu.org, liberty-eiffel-request@gnu.org
> > Subject: Re: Liberty-eiffel Digest, Vol 53, Issue 8
> > Message-ID: <1629935351.23456.1645032398447@ox.hosteurope.de>
> > Content-Type: text/plain; charset=UTF-8
> > 
> > Welcome Patrick, soyez bienvenue !
> > 
> > Very cool to see new faces around here :)
> > 
> > Cordialement
> > Hans
> > 
> > 
> > > liberty-eiffel-request@gnu.org hat am 16.02.2022 18:00
> > > geschrieben:
> > > 
> > >   
> > > Send Liberty-eiffel mailing list submissions to
> > >     liberty-eiffel@gnu.org
> > > 
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >     https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> > > or, via email, send a message with subject or body 'help' to
> > >     liberty-eiffel-request@gnu.org
> > > 
> > > You can reach the person managing the list at
> > >     liberty-eiffel-owner@gnu.org
> > > 
> > > When replying, please edit your Subject line so it is more
> > > specific
> > > than "Re: Contents of Liberty-eiffel digest..."
> > > 
> > > 
> > > Today's Topics:
> > > 
> > >     1. one more on board (Patrick CLOAREC)
> > > 
> > > 
> > > -----------------------------------------------------------------
> > > -----
> > > 
> > > Message: 1
> > > Date: Wed, 16 Feb 2022 07:46:03 +0100
> > > From: Patrick CLOAREC <patrick.cloarec@laposte.net>
> > > To: liberty-eiffel@gnu.org
> > > Subject: one more on board
> > > Message-ID: <ba60695d-2372-6a18-505a-9d070b78e9c5@laposte.net>
> > > Content-Type: text/plain; charset=UTF-8; format=flowed
> > > 
> > > Hi all,
> > > 
> > > I'm a software engineer. I closely followed the development of 
> > > Smalleiffel at the end of the 90's but never contributed to it.
> > > 
> > > Now, I'd like to be involved in LibertyEiffel, as well as Gobo.
> > > 
> > > I have a strong professional background in C (not by choice,
> > > actually), 
> > > I have used many languages, mainly Eiffel, Erlang, C, C++, Java
> > > and 
> > > assemblers, for 30 years, but I definitely consider Eiffel as the
> > > best 
> > > designed language by far.
> > > 
> > > I have rediscovered Liberty Eiffel last week, and I'm really
> > > happy to 
> > > see it as an active project again.
> > > 
> > > I think that the priority is the one Eric Bezault has pointed out
> > > : 
> > > interoperability between ISE, Gobo and Liberty.
> > > 
> > > I'd be really glad to contribute to Gobo's and Liberty Eiffel's
> > > next 
> > > developments !
> > > 
> > > Patrick CLOAREC
> > > 
> > > 
> > > 
> > > 
> > > ------------------------------
> > > 
> > > Subject: Digest Footer
> > > 
> > > _______________________________________________
> > > Liberty-eiffel mailing list
> > > Liberty-eiffel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> > > 
> > > 
> > > ------------------------------
> > > 
> > > End of Liberty-eiffel Digest, Vol 53, Issue 8
> > > *********************************************
> > 
> > 
> > 
> > ------------------------------
> > 
> > Subject: Digest Footer
> > 
> > _______________________________________________
> > Liberty-eiffel mailing list
> > Liberty-eiffel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/liberty-eiffel
> > 
> > 
> > ------------------------------
> > 
> > End of Liberty-eiffel Digest, Vol 53, Issue 9
> > *********************************************
>