Quora - What is a pointer?

95 views
Skip to first unread message

Ian Joyner

unread,
May 11, 2019, 7:44:14 PM5/11/19
to Eiffel Users
I just responded to a question on the meaning of pointers. Ended up being another long essay. While I don’t explicitly mention Eiffel, it does explain why pointers in C and C++ are not desirable.

I’m sure you guys will point out any guff.


Ian

Bertrand Meyer

unread,
May 12, 2019, 3:33:56 AM5/12/19
to eiffel...@googlegroups.com, me...@inf.ethz.ch

> While I don’t explicitly mention Eiffel,

 

Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.

 

-- BM

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8D497762-C02E-4658-B3C7-DD81CD962173%40acm.org.
For more options, visit https://groups.google.com/d/optout.

Woland's Cat

unread,
May 12, 2019, 6:39:18 AM5/12/19
to eiffel...@googlegroups.com
On 12/05/2019 08:32, Bertrand Meyer wrote:

> While I don’t explicitly mention Eiffel,

 

Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.

 

At the moment I think there are too many non-language limitations to Eiffel for it to gain much traction with today's younger programmers - for now. I have pointed out many of these in the past, but essentially, the following are problematic:

  • not well connected to JavaScript or TypeScript app programming languages
  • no connector to the JVM; witness the popularity of Kotlin, a 'new' language that is JVM-targetted; there are other VMs that Eiffel could target, these could be thought about
  • not easy to make applications for the Mac (I have gave up on publishing our tool 2y ago on Mac)
    • not sure where we are with this
  • doesn't have a connector or replacement for the big Java (and probably C#) frameworks like REST (a dumb concept, but like XML, the industry loves it)
    • EWF would need to get better to address this
  • doesn't have a modern dependency-injection model
    • IRON would need to get better to address this
  • not connected to IntelliJ, which is becoming a defactor IDE for every language

Unfortunately the IT industry sails along on foundations of poor quality, but thinks they are good enough - Java, C#, XML, XSD, REST, JSON, UML, JS,  etc. It's all low quality stuff based on weak thinking. Economically, apparently they are good enough, if you consider the IT to be sustainable (it's clearly horribly inefficient, but so is the entire economy...). To work around that probably means creating a whole technology development stack, including language, diagramming (UML replacement), network / web programming framework, server/DB framwork, integrated IDE, mobile app programming, virtualisation tools etc.

It's not totally out of the question. In my openEHR work, we replaced UML/XML with BMM, JSON with ODIN (well, ODIN was 10y earlier than JSON), and then we had to invent some new things not properly covered by anything in industry, e.g. archetypes (Schematron and ICL might be the closest attempts). Replacing the much longer list of poor quality industry standard technologies is going to be a serious task.

But being more realistic I think entails finding solutions to making some of the connections I list above. These are the technological connections that all /most new languages have out of the box.

If I were going to start on a path of investigating where to go with Eiffel, I'd probably start looking at Kotlin: how does it generate code for the JVM from its relatively advanced constructs (e.g. FP)? What does it take to plug a language into the IntelliJ tool? How does one connect an AngularJS app to it? etc

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog | The Objective Stance

Ian Joyner

unread,
May 12, 2019, 10:01:24 AM5/12/19
to Eiffel Users
Well, I have plenty of Eiffel mentions. Here are some:







Bertrand Meyer

unread,
May 13, 2019, 4:36:27 AM5/13/19
to eiffel...@googlegroups.com, me...@inf.ethz.ch

Dear Ian,

 

Yes, I know… It’s unfair to pick on just this one time.

 

-- BM

Bertrand Meyer

unread,
May 13, 2019, 4:51:39 AM5/13/19
to eiffel...@googlegroups.com, me...@inf.ethz.ch

Dear Thomas,

 

Not very encouraging. Your suggestions are all correct, of course, in the sense that having all these interfaces would help, but we cannot be chasing the next “in” thing all the time. We prefer to work on the basic engine with the expectation that its superiority will convince people and that the rest will follow.

 

We have to choose what to interface to. The JVM was tried and the project hit a dead end because of multiple inheritance – doable in .NET, not doable in the JVM. Maybe we should try again but I see no evidence that the conceptual roadblock is gone.

 

.NET is an example of why interfacing to important technologies is not enough. Eiffel’s .NET implementation definitely helps, but my impression is that most people who use Eiffel on .NET pretty soon switch to native (non-.NET) Eiffel/EiffelStudio.

 

As a sign of the danger of focusing on the trendy interface du jour, here is a list of detailed suggestions for Eiffel you sent on 6 March 2005 (I don’t always answer your detailed suggestions, sorry, but I do read them and I have a 4-TB disk):

 

2. My list of things that are needed today for Eiffel are mostly to do
with integration:
- name spaces (allowing multiple libraries to be integrated)
- connection to UML that works
- integration to OCL (near future)
- automated java integration
- automated generation of XML-schemas from models (today I have to write
this myself)
- automated generation of IDL and WSDL from models
- upgraded document generation, like javadoc
- an inbuilt reflection mechanism is needed. This allows for much more
flexible information- and knowledge-driven computing.

 

These were all good suggestions at the time, and several remain applicable today, but I don’t think that focusing on IDL and OCL would have made much of a difference.

 

Interfacing to many tools is important but we need to choose. What underlies your suggestions is the need to create an ecosystem in which more than one source contributes the elements. Any suggestion to build it is welcome.

 

With best regards,

 

-- Bertrand Meyer

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

Finnian Reilly

unread,
May 13, 2019, 6:20:08 AM5/13/19
to Eiffel Users
Upvoting

I have visited each of these links to upvote them. Hope others will do the same.

Finnian

On Sunday, 12 May 2019 15:01:24 UTC+1, i.joyner wrote:
Well, I have plenty of Eiffel mentions. Here are some:






On 12 May 2019, at 17:32, Bertrand Meyer <Bertra...@inf.ethz.ch> wrote:

> While I don’t explicitly mention Eiffel,
 
Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.
 
-- BM
 
From: eiffel...@googlegroups.com [mailto:ei...@googlegroups.com] On Behalf Of Ian Joyner
Sent: Sunday, May 12, 2019 02:44
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Quora - What is a pointer?
 
I just responded to a question on the meaning of pointers. Ended up being another long essay. While I don’t explicitly mention Eiffel, it does explain why pointers in C and C++ are not desirable.
 
I’m sure you guys will point out any guff.
 
 
Ian
-- 
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel...@googlegroups.com.

Woland's Cat

unread,
May 13, 2019, 6:56:29 AM5/13/19
to eiffel...@googlegroups.com

Hi Bertrand,
well I don't disagree with the thrust of your reply. But... although the specific targets I mentioned back then (please note, I posted many more recent lists of key features needed) include things like UML, OCL, IDL, WSDL which are now arguably passe, it is clear that a generalised capability to target other formalisms would be needed anyway, so whatever the current flavour of the month should not be too much beyond a new serialiser on top of such an engine.

But today, I think it is inescapable that new developers will absolutely assume that when starting a new language, most of the following capabilities are available:
  • you can easily do web/mobile application programming in it
  • it will be properly portable, which either means the JVM or another solution that has the same results
    • I read that GraalVM will run LLVM-based languages including C and C++ ... MI?
  • you can easily do modern network programming (REST API-based)
  • dependency-injection

I say 'most' because some newly popular languages like Rust seem to concentrate on server-side programming, and maybe don't include the first capability above; similarly, front-end languages like TypeScript may not do everything in the 3rd category, but certainly satisfy 1. and 2.

On the problem of MI and a VM, I would have thought the directions of investigation might be:

  • see what GraalVM can offer via LLVM
  • look for a theoretical trick to abstract away MI to SI

The second is an idea I have often wondered about but never had time to investigate: applying the curried function idea to converting an MI lineage to an SI one, i.e. by progressively synthesising classes that each inherit from only one other class, while defining a set of features of one parent of each class that originally had multiple parents. I assume this has been thought about and analysed, probably years ago, but I have never seen any discussion about it. Maybe it can't be shown to work. In any case, quite a bit of Eiffel MI is to do with inheriting classes full of constants; some is also pure abstract inheritance. Is there no way to map this onto the single inheritance extends/implements system required by Java?

I also don't make any assumption that all or any work implied by my comments should only be done by one party.

One other thing that all new programmers expect, probably since at least the days of Python, is a community, with meetups, conferences, hackathons and other very practical ways of engaging.

regards

- thomas

Ian Joyner

unread,
May 13, 2019, 8:07:51 AM5/13/19
to Eiffel Users
Dear Bertrand,

Yes, but I’m following the subtlety of the master! A couple of questions tonight on tuples and derived classes so I referred them to relevant sections in Touch of Class. Hopefully by reading it they discover for themselves something about Eiffel.

Ian

Ian Joyner

unread,
May 13, 2019, 8:11:06 AM5/13/19
to Eiffel Users
Maybe Eiffel MI is not implementable on top of the raw JVM. But I just realised you could probably write an Eiffel runtime on top of JVM that handles dispatch to MI tables. Of course this is another layer of indirection (isn’t there a saying about that?).

Ian

Peter Gummer

unread,
May 13, 2019, 8:58:18 AM5/13/19
to 'Alexander Kogtenkov' via Eiffel Users
Ian Joyner <i.jo...@acm.org> wrote:

Maybe Eiffel MI is not implementable on top of the raw JVM. But I just realised you could probably write an Eiffel runtime on top of JVM that handles dispatch to MI tables. Of course this is another layer of indirection (isn’t there a saying about that?).


The old SmartEiffel compiler used to claim that, "it can be used to write programs that run on virtually any platform for which an ANSI C compiler or a Java virtual machine exist."


If that's true, perhaps there was some low-level difference in SmartEiffel’s implementation that enabled this.

- Peter

Bertrand Meyer

unread,
May 13, 2019, 9:03:42 AM5/13/19
to eiffel...@googlegroups.com, me...@inf.ethz.ch

ANSI C *or* JVM – true of EiffelStudio too.

 

-- BM

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Peter Gummer
Sent: Monday, May 13, 2019 15:58
To: 'Alexander Kogtenkov' via Eiffel Users <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Quora - What is a pointer?

 

Ian Joyner <i.jo...@acm.org> wrote:

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

Eric Bezault

unread,
May 13, 2019, 10:35:45 AM5/13/19
to eiffel...@googlegroups.com, Peter Gummer
On 13/05/2019 14:58, Peter Gummer wrote:
> The old SmartEiffel compiler used to claim that, "it can be used to
> write programs that run on virtually any platform for which an ANSI C
> compiler or a Java virtual machine exist."
>
> http://smarteiffel.loria.fr
>
> If that's true, perhaps there was some low-level difference in
> SmartEiffel’s implementation that enabled this.

All Eiffel compilers can use C as intermediate language.
And C does not have multiple inheritance. It's not even OO.
So yes, we can make an Eiffel program work on many VMs.
The issue is more about whether we want the translated
Eiffel code look nice and reusable from other languages
on the same VM, or if we keep it obscure and ugly like
it is currently when translated to C.

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

Ian Joyner

unread,
May 13, 2019, 7:34:48 PM5/13/19
to Eiffel Users
I don’t know if Frieder’s direct-to-machine-code compiler still exists, but it doesn’t have to generate C. I still think you could write the dispatch mechanism in Java, not using the JVM’s dispatch, but then any dynamic dispatch would be done as interpreted code, not directly using the JVM’s dispatch facilities. Might be too slow, but worth an experiment to try.
> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
> Visit this group at https://groups.google.com/group/eiffel-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/6f1b1df2-6b2b-1f17-cb80-3da3d42bef78%40gobosoft.com.

Ian Joyner

unread,
May 14, 2019, 7:11:28 AM5/14/19
to Eiffel Users
Have you looked at GraalVM?


Eric Bezault

unread,
May 14, 2019, 8:42:08 AM5/14/19
to eiffel...@googlegroups.com, Ian Joyner
On 14/05/2019 1:34, Ian Joyner wrote:
> I don’t know if Frieder’s direct-to-machine-code compiler still exists, but it doesn’t have to generate C.

As far as I know, the compilers which are actively maintained are
ISE EiffelStudio and the Gobo Eiffel compiler. Liberty Eiffel is
not maintained that much (last commit was in October last year).
All other compilers are not maintained anymore.

The good thing is that ISE Eiffel and Gobo Eiffel aim to support
the same Eiffel language (as defined by the ECMA standard) and use
the same kernel classes. So it makes interoperability much easier
than it used to be in the 90's when I first developed the
Gobo Eiffel library classes.

I didn't want to state that an Eiffel compiler has to generate C.
I wanted to emphasize the fact that what makes things difficult
when targeting VMs is to make the generated code friendly for
other languages on the same VM. If we don't care about being good
citizens, then Eiffel can be compiled on these VMs in the same
way it is translated to C. Just give me the money and I'll do it :-)

Anthony W

unread,
May 15, 2019, 12:49:54 AM5/15/19
to eiffel...@googlegroups.com
Hi Dr. Meyer -

I realize your response was to Thomas, but I just wanted to interject my experience to one of your points:

I've tried on a number of occasions to build  Eiffel/C# hybrid apps to leverage my understanding of the C# libraries, while learning the intricacies of Eiffel. All except one has failed, and that was only partially successful, in that I had a larger set of features I wanted but could not get working.

In my situation of using Eiffel on .NET, I soon switched to full .NET and dropped Eiffel. I didn't want to, and I fought desperately to "make it work", but in the end I simply couldn't and so went with what was already productive for me.I believe I'm not alone in my struggle; I've seen posts from Jimmy John and Larry Rix which seem to echo the same hurdles I've run into.

I would be surprised to find a company in this day and age developing a solution which doesn't leverage multiple technologies - whether that be from lowly libraries to interfacing with full COTS packages. I think Eiffel will ultimately fall to the wayside unless it continues to make itself capable of interfacing with other technologies, such as .NET, the JVM, and web and mobile apps.

But that's only half of the story. A big part of the reason why C# and Java have such a huge developer base is because of the ease with which you can learn both of them. If I want examples on how to leverage threads, graphics, or networking, I can pull up thousands of hits of sample code and tutorials from google. I can't say the same about Eiffel - even more so when you start looking for how to interface Eiffel with other technologies.

TLDR; Eiffel really needs provide more code samples and tutorials for mid and advanced levels of expertise, with a particular focus on integration with other mainstream technologies. Don't add more depth or breadth; leverage your existing capabilities by providing better teaching/training platforms for developers to discover the beauty of Eiffel.

My two cents :)

Best Regards
Anthony

On Mon, May 13, 2019 at 3:51 AM Bertrand Meyer <Bertran...@inf.ethz.ch> wrote:

Dear Thomas,

...

 

.NET is an example of why interfacing to important technologies is not enough. Eiffel’s .NET implementation definitely helps, but my impression is that most people who use Eiffel on .NET pretty soon switch to native (non-.NET) Eiffel/EiffelStudio.

.... 

Finnian Reilly

unread,
May 15, 2019, 9:41:51 AM5/15/19
to Eiffel Users

Bootstrapping a language to popularity

What does every popular language have in common? I would argue that they all first successfully occupied a niche for a while, and then after building up a solid base of support, overflowed the niche to gain popularity. Building up a solid base is essentially a question of economics. Success in the niche is initially established by a superior design for that niche. This create the conditions for an economy to emerge of many paying jobs requiring  knowledge of the language. Once enough developers are being financially rewarded for developing with the language, it creates a strong incentive to contribute libraries of a professional standard. A critical mass of libraries then paves the way for more widespread acceptance as a general purpose language.

Here are some examples, with niche being understood to mean original niche. (Some languages occupied a number of niches either successively or simultaneously.)

Ada

Niche: super robust language for Pentagon projects that must not fail


C

Niche: a compact portable high-level language that had similar performance to assembly

C++

Niche: a language that is backwards compatible with C but has OO features.

Java

Niche:

  1. A VM language with a C like syntax that compiles once and then runs on many platforms
  2. A compiled development language that runs in a browser hosting a VM.

C#

Niche: a VM language exhibiting many of the advantages of Java, but controlled by Microsoft and therefore guaranteed to work better on all Windows platforms and tools

Python

Niche:

  1. A language superior to the ABC language that ran on the Amoeba operating system
  2. A scripting language that was better than Perl with support on Windows and Unix and Mac.

Eiffel

Niche: ???

Has Eiffel ever fulfilled an original niche? I am not sure that it did. It seems to me that Eiffel tried to leapfrog past being in any niche, and become a general purpose language from the get go. Consequently it failed to build up a large enough base of paid developers who could create a critical mass of libraries to catapult it to widespread popularity.

What would be a natural niche for Eiffel? I was reading this FAQ from a company offering training in the DO-178 standard for avionics coding.

Which software language is best for avionics software?

High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178 emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.

Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++.

I find that last statement quite jaw dropping!

"emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability,"
This sounds like the natural competitive strength of Eiffel. Based on the above, I could imagine some subset of Eiffel conforming to DO-178 and being marketed to the avionics industry as the language that combines the best of Ada, C and C++ and then some.


Larry Rix

unread,
May 16, 2019, 5:14:28 PM5/16/19
to Eiffel Users
What is a pointer?

It's either a big foam hand that is mounted on the end my arm or that thing the teacher used in school at the blackboard, yes? :-)

Larry Rix

unread,
May 16, 2019, 5:18:51 PM5/16/19
to Eiffel Users
Finnian—sounds like some marketing money and effort needs to be applied!

Ian Joyner

unread,
May 16, 2019, 6:59:09 PM5/16/19
to Eiffel Users
Hi Finnian,

I had to reread this today. Jaw dropping? In many ways. Yes, considering C and C++ as safe is worrying. Boeing has had software problems lately with tragic results of two plane loads of people killed.

I think what I find concerning about C and C++ people is (without generalising to all) that they are focussed on using just C and C++ like it is their tribal culture while ignoring the real software quality issues which I think boil down to correctness and safety. If that applies in aerospace, the most important thing to them is writing C and C++ code, before aircraft safety.

The C mindset is to put performance ahead of other factors. As I tell my students – it does not matter how fast you do a computation, if the result is wrong, speed counts for nothing.

On correctness and safety, someone on Quora the other day responded to one of my answers/comments saying those are not the major concerns of modern software development. I agreed that not modern software, but software at least since 1950s. Why are these still being ignored as if it comes down to some nefarious and misguided notion of ‘programmer freedom’?

Ian

On 15 May 2019, at 23:41, Finnian Reilly <frei...@gmail.com> wrote:

Which software language is best for avionics software?

High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178 emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.

Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++.

I find that last statement quite jaw dropping!


"emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability,"
This sounds like the natural competitive strength of Eiffel. Based on the above, I could imagine some subset of Eiffel conforming to DO-178 and being marketed to the avionics industry as the language that combines the best of Ada, C and C++ and then some.



--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

Finnian Reilly

unread,
May 17, 2019, 10:06:35 AM5/17/19
to Eiffel Users
Marketing money and effort needs to be applied!

Finnian—sounds like some marketing money and effort needs to be applied!

Yes indeed, so how about this somewhat naive idea for Eiffel Software.

I remember that ES once made a custom version of Eiffel, for Hewlett Packard to support the development of a printer driver. I think it involved a stripped down runtime, and maybe other things. So why not study the DO-178 specs and come up with a new product: Eiffel for Avionics. Perhaps it might involve a new way of managing memory similar to Ada.

Funding
Perhaps here the EU commission can help. They have an organization called Creative Europe whose mission statement is to "support Europe cultural and creative sectors". I think a good argument can be made that Eiffel is a European cultural artifact that deserves support and in fact they already have a long history of funding European video games. So why not European development languages. This is the budget for video games for 2019


https://www.creativeeuropeireland.eu/media/funding/production/development-of-video-games

Available Funding

The total budget for 2019 is estimated at €3.78 million. The total grant awarded can range from €10,000 to €150,000 and must be 50% match funded.

Eligible Applicants

This scheme is for companies who have produced at least one recently published video game who wish to invest in the development of a new video game concept or prototype. 

This scheme supports European independent video games companies with proven experience who want to develop up to an alpha or beta version of a narrative-led video game.


OR
perhaps a new company could be setup in Europe to develop Eiffel for Avionics with funding from the European Investment Fund

Larry Rix

unread,
May 17, 2019, 11:06:41 AM5/17/19
to Eiffel Users
Without a doubt, Eiffel is a European child! America and other countries have contributed only a small part of the whole, but the origin and idea are wholly and fully European! So—if the EU has funding that could be tapped, then I am all for folks in Europe to make that happen.

Apparently, Kotlin is a German animal. I'd love to see elegant French technology find its proper success!

Eric Bezault

unread,
May 17, 2019, 11:18:29 AM5/17/19
to eiffel...@googlegroups.com, Larry Rix
On 17/05/2019 17:06, Larry Rix wrote:
> Without a doubt, Eiffel is a European child!

French parents, but born and grown up in California
in the 80's and 90's.

Eric Bezault

unread,
May 17, 2019, 11:36:23 AM5/17/19
to eiffel...@googlegroups.com, Ian Joyner
On 17/05/2019 0:58, Ian Joyner wrote:
> The C mindset is to put performance ahead of other factors. As I tell my
> students – it does not matter how fast you do a computation, if the
> result is wrong, speed counts for nothing.

Agreed. But it may also happen that getting the right result
too late is as bad as getting a wrong result.

Finnian Reilly

unread,
May 17, 2019, 12:01:14 PM5/17/19
to Eiffel Users

Apparently, Kotlin is a German animal.
German???, I always heard that Kotlin is a Russian animal and named after an island near St Petersburg. When I checked on the official Kotlin site the personnel names have a decidedly Russian ring to them. The lead designer's home page is in Russian.
 

President: Andrey Breslav (JetBrains)

Secretary: Max Sills (Google)

Board of Directors:

  • Andrey Breslav (JetBrains)
  • William R. Cook (University of Texas at Austin)
  • Stephanie Saad Cuthbertson (Google)
  • Anwar Ghuloum (Google)
  • Maxim Shafirov (JetBrains)

Lead Language Designer: Andrey Breslav (JetBrains)

Language Committee:

  • Andrey Breslav (JetBrains)
  • William R. Cook (University of Texas at Austin)
  • Jeffrey van Gogh (Google)

r...@amalasoft.com

unread,
May 17, 2019, 12:09:26 PM5/17/19
to eiffel...@googlegroups.com
Yup
I call it the GRT triangle - and equilateral triangle whose sides are Goodness, Richness and Timeliness.  Each has equal importance in achieving a successful outcome.  Devaluing any one leads to a flat line.
That's the _objective_ view, but individuals and organizations seem to miss that important concept, and will invariably favor one side over another.
R
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

Finnian Reilly

unread,
May 17, 2019, 12:18:24 PM5/17/19
to Eiffel Users
Kotlin Design Decisions
While checking the nationality of Kotlin I came across an interesting interview in the Russian edition of Forbes with the lead designer Andrey Breslav. He reveals many interesting tidbits on the design and dev cost. (15 million USD apparently). It's in Russian but mysteriously Google translate on Chrome seems to produce an actual human translation.


The most interesting bit

What should be the features of the new language? What did you decide to bet on? What should have been a competitive advantage, since there have already been attempts to create an “alternative to Java”?

- There are several key aspects of the language on which the cost of its "operation" depends, that is, the costs of companies that will write in this language. First, if the language is very complex, then programmers who write on it will have to pay a large salary. Secondly, if programs are difficult to understand, if they are difficult to look for errors in them and make changes, then development is delayed and becomes more expensive. Thirdly, if programs turn out to be slow due to the properties of the language, you have to invest in their acceleration (from hiring expensive optimization specialists to buying faster hardware).

Therefore, Kotlin is a fairly easy-to-learn language, and the average programmer who works for the average wage can easily master it. The syntax of the language, the type system and the instrumental support make it easy to use, so the productivity of developers is very high (higher than in Java). For example, data classes, properties, type inference, and many other features of the language allow you to write (and therefore read) less code for typical tasks, the built-in control of null references and the smart casts mechanism help earlier and faster to detect errors, and flexible abstractions (extension functions , functional types, etc.) allow you to reuse more code. In addition, programs are as fast as Java (sometimes even a little faster).

Among the pre-existing languages ​​for the Java platform, this combination did not occur: other languages ​​are too expensive for a wide class of projects. Java is too “verbose”, so the code is harder to read, write and modify, and Kotlin also eliminates some types of errors that are often found in Java programs. Scala is too complicated, only expensive specialists can use it well. Groovy is too slow for many tasks and error prone. Each language has its own niche, in which it is very good, just a question about the size of this niche. For Kotlin, it is very large, for other alternative languages ​​- somewhat already.


Ian Joyner

unread,
May 17, 2019, 7:33:34 PM5/17/19
to Eiffel Users
On 18 May 2019, at 01:06, Larry Rix <lar...@moonshotsoftware.com> wrote:

Without a doubt, Eiffel is a European child!

As I learnt from reading Dijkstra, there is a big difference between the two sides of the Atlantic in thinking about computing. American computing is more about hardware and electronics and European thinking more on software and producing quality software. Maybe that explains the US predilection for HW orientation in languages such as C, whereas European thinking is more about providing pure computing environments. Of course, one can easily slip into too much generalisation.

I’m not sure if this is the original article I read from Dijkstra (which I think was an interview), but I just found this one.


Maybe it was this interview:


I certainly think that USAans like Bob Barton (Burroughs B5000, B1000), John Backus (FORTRAN, ALGOL, FP), Alan Kay (Barton’s star pupil), Steve Jobs understood the need to build hardware to support software and not the other way around.

It seems that Dijkstra and Backus were friends with a rocky relationship:


I remember the guy I was working with at Burroughs saying they had brought Dijkstra out to Australia and Arthur Sale apparently brought him down a peg or two. Perhaps this atmosphere has set the industry back as a reaction against “Discipline of Programming”. I have never met Arthur, but have inherited several of his books, one of which was JK Iliffe’s Basic Machine Principles (1968). Apparently Iliffe is still around but is disillusioned with computing. Indeed, I think computing is in a lamentable state, and arrogance certainly seems to rule (but maybe that is a product of the kind of people that are attracted to it). Mind you his and Barton’s ideas probably originated in the US:


Barton’s papers



Ian


On 18 May 2019, at 01:06, Larry Rix <lar...@moonshotsoftware.com> wrote:

Without a doubt, Eiffel is a European child! America and other countries have contributed only a small part of the whole, but the origin and idea are wholly and fully European! So—if the EU has funding that could be tapped, then I am all for folks in Europe to make that happen.

Apparently, Kotlin is a German animal. I'd love to see elegant French technology find its proper success!

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

r...@amalasoft.com

unread,
May 18, 2019, 8:51:49 AM5/18/19
to eiffel...@googlegroups.com
Thanks Ian.  Good stuff.

Perhaps we (and I very much include myself in this) techno-geezers need to step back from our walkers for a moment and smell the <whatever dumb-ass coffee-like abomination is popular today>.
The state of computing might have differed with geography and politics, at some point, somewhere, but the state of computing today (lamentable most certainly) has nothing to do with those factors, and has not for quite some time.
If you were to ask the typical "software professional" (and not our FOG*), what they know about hardware, or computing in general, and you'd get a very sad response.  We have, I fear, succeeded in creating abstraction to the point of absurdity (see: ifttt.com) and as such, there is a small percentage of the profession that can be called "system programmers" simply because most have either retired or died, and fewer are needed.  The ranks of scripters, in contrast, has swollen.
We have achieved the dream of "software ICs", and it's a nightmare (for some of us).
It's not that there is no value in such grunt-and-point-and-Voila programming.  There is a lot of value to its consumers, and good salaries for its practitioners.  The problem is, it's not the value some of us seek.
Timeliness is the fashion, and fashion drives the planet these days.  There are, I hope, a few islands of awareness; pockets of resistance, where the Goodness of software still matters.

R

* FOG = Flock of Geezers
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?

Woland's Cat

unread,
May 18, 2019, 10:42:55 AM5/18/19
to eiffel...@googlegroups.com
On 18/05/2019 13:51, r...@amalasoft.com wrote:
Thanks Ian.  Good stuff.

Perhaps we (and I very much include myself in this) techno-geezers need to step back from our walkers for a moment and smell the <whatever dumb-ass coffee-like abomination is popular today>.

That I believe is the scientific description of what is found in places like you-know-where...

The state of computing might have differed with geography and politics, at some point, somewhere, but the state of computing today (lamentable most certainly) has nothing to do with those factors, and has not for quite some time.
If you were to ask the typical "software professional" (and not our FOG*), what they know about hardware, or computing in general, and you'd get a very sad response.  We have, I fear, succeeded in creating abstraction to the point of absurdity (see: ifttt.com) and as such, there is a small percentage of the profession that can be called "system programmers" simply because most have either retired or died, and fewer are needed.  The ranks of scripters, in contrast, has swollen.
We have achieved the dream of "software ICs", and it's a nightmare (for some of us).
It's not that there is no value in such grunt-and-point-and-Voila programming.  There is a lot of value to its consumers, and good salaries for its practitioners.  The problem is, it's not the value some of us seek.
Timeliness is the fashion, and fashion drives the planet these days.  There are, I hope, a few islands of awareness; pockets of resistance, where the Goodness of software still matters.

Agree... the signs of bad software and poor languages are very simple: a) too many lines of code for a given task, b) unmaintainability and c) lack of correctness (bugs, or catastrophes, in Ariane 5 or Boeing 737 Max). Everything else stems from those things. They more or less define the unnecessary inefficiency of the IT economy.

I was just studying Kotlin's idea of inheritance, constructors etc, and I kept thinking: this is unnecessarily complex to do a relatively simple job. And it doesn't even have MI (crippled by the JVM). There seems to be a level of hacking that goes on in language design, just like in normal code, which results in mess like Scala, Java 8+, Kotlin (slightly better) and so on. Lots of useful features, but badly designed, badly integrated, too many alternative syntax options ... apparently language designers don't study formal logic anymore.

In my domain (health information systems and standards) it's exactly the same, and I have no doubt that most people here see the same in your respective domains - most things are badly done, with little concern for anything other than local islands of work and functionality. It simply doesn't matter to most people that doing things properly would probably reduce the cost of software globally by a factor of 10, while greatly improving the quality.

The fact is, most people don't care about quality. Or possibly, even know what it looks like. This I put down to the lack of ability for abstraction, and particularly to see negative downstream consequences of poor languages, code etc being built today The latter requires a mental ability to infer from specific kinds of bad code, constructs etc, what the results in running systems and maintenance effort will be over the next 5+ years. Most people it seems can't do that. It's probably no mistake that the main character in Zen and the Art of Motorcycle Maintenance is more than slightly crazy by the end - no-one else seems to care about quality.

So this is the world we live in. Which is why I think that the popularity of Eiffel rests on mundane considerations of being more easily able to write a web app in TypeScript (or why not EiffelScript?) for a mobile device on an Eiffel back-end, deploy it in a modern virtualised container, and (somehow) make it work on the *%&^ JVM.

- thomas


Larry Rix

unread,
May 18, 2019, 11:55:28 AM5/18/19
to Eiffel Users
Eric,

Spot on! Apparently, in this on-going software tools environment, beta-test-by-consumer plus "mostly-works" is good enough. People have an emotional toleration for problems and issues as long as they see A) Immediate benefit B) Acceptable Work-arounds C) Bugs being steadily fixed and updates delivered.

r...@amalasoft.com

unread,
May 18, 2019, 12:34:56 PM5/18/19
to eiffel...@googlegroups.com
All nicely put.
As much as I'd love to be able to web-app my way to happiness with Eiffel, I worry that only a handful of the faithful would care.  It might be a better use of resources to build on what Eiffel does best, to create conspicuous value in contexts where that matters (objectively, and in the minds of its denizens).
While avionics and autonomous vehicles demand (we hope) the qualities that Eiffel brings, they are also near-real-time, or actual real-time systems, and that has, traditionally, been an area where things like garbage collection were seen as the spawn of Satan.
Practitioners of RT and NRT systems know that it ain't the reality or or time that's the issue; it's the predictable latency.  A slower, but predictably so, system can be managed, but an unpredictable one (w/r/t latency) cannot.
A GC system, including Eiffel's could be made to be more predictable, assuming that the memory consumption patterns are also.  That's a tall order.
More reasonably, perhaps, would be the GC moral equivalent of Void-safety.  It might be more like a profiling operation than a compiling one, but it should be possible to analyze a system to find its GC behavior and what patterns are perturbing it.  Sure that too is a tall order, but without something like that, I doubt we'd see a whole lot of traction in those otherwise very appropriate contexts.
Of course, I could be wrong.
Thanks
R
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.

Woland's Cat

unread,
May 18, 2019, 1:12:33 PM5/18/19
to eiffel...@googlegroups.com
On 18/05/2019 17:34, r...@amalasoft.com wrote:
All nicely put.
As much as I'd love to be able to web-app my way to happiness with Eiffel, I worry that only a handful of the faithful would care.  It might be a better use of resources to build on what Eiffel does best, to create conspicuous value in contexts where that matters (objectively, and in the minds of its denizens).
While avionics and autonomous vehicles demand (we hope) the qualities that Eiffel brings, they are also near-real-time, or actual real-time systems, and that has, traditionally, been an area where things like garbage collection were seen as the spawn of Satan.
Practitioners of RT and NRT systems know that it ain't the reality or or time that's the issue; it's the predictable latency.  A slower, but predictably so, system can be managed, but an unpredictable one (w/r/t latency) cannot.
A GC system, including Eiffel's could be made to be more predictable, assuming that the memory consumption patterns are also.  That's a tall order.

well there are different classes of 'real time'. I first ordered Eiffel in 1988 for the company I worked for (Leeds and Northrup, now Foxboro) to experiment with it, for distributed real-time control (SCADA) systems. The time domain of the scanning remote units is usually in the 1 second area, occasionally in high ms range. This is because most of these systems are scanning things like gas pressure changes, transformer tap changes, circuit breaker state changes, train movement changes. The O(1sec) is fine for most things, with O(10ms) - O(100ms) occasionally needed. All this is far slower than the cycle time of any modern GC running on a normal processor. Eiffel would be perfect for this. After I left the company, they went for C++ (from C, which was what I wanted to replace). Now, C++ is an evil language (like Portuguese, Russian, Vietnamese and a few others) but can be spoken well by those with the right schooling, so you can do what you need in C++, you just have to be super-careful, and build a team just around GC/memory leaks.

For telecoms / network switches etc, the time domain is certainly in the micro-seconds - low milliseconds range, so knowing what the GC is doing does start becoming a question. For on-board avionics you're definitely in the time domain where an interruption by the GC at the wrong time might be a problem. But, as with anything there are practical heuristics. For example, it's not that hard to determine when a plane is in steady, stable flight, and a GC and some other things could be allowed to run and consume a few ms of CPU.

Does it mean Eiffel Software should be pitching to control systems, avinics and telecoms companies? Maybe... it would be an interesting question as to how Eiffel would rate compared to what ESA or NASA currently use for example.

- thomas


Peter Horan

unread,
May 18, 2019, 7:38:24 PM5/18/19
to eiffel...@googlegroups.com

Garbage collector accelerators are on their way. See IEEE Micro Vol 39 Issue 3 may-June 2019, p 38

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Woland's Cat
Sent: Sunday, 19 May 2019 03:12
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Quora - What is a pointer?

 

On 18/05/2019 17:34, r...@amalasoft.com wrote:

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.


For more options, visit https://groups.google.com/d/optout.


Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.

Ian Joyner

unread,
May 18, 2019, 8:56:12 PM5/18/19
to Eiffel Users
Where to start?

Yes, it was the EWD611 paper I read before when I saw the title "On the fact that the Atlantic Ocean has two sides.”

What I think is behind this paper is the analysis of why the message about system and software correctness was not getting through. Whether the paper is right or wrong in its analysis seems beside the point. It is still a question we are trying to answer.

Eiffel came along as a clear example of how a language could be clear and implement all the good stuff, done in such a way that the average programmer could understand without a degree in higher mathematics. And with support material that was easy to read and understand why. Over several years, I have attempted to read the so-called “Easy intro” to Haskell. These are all written in ways that assume a high degree of mathematical sophistication.

But the highly political C/C++ hatchet job was done on Eiffel. But what are the faults on Eiffel’s side? Some comments have been made on a question on Quora. I don’t vouch for their correctness or not.


Maybe Eiffel needs to be more open. I don’t know what the exact current status is.

On the exchange between Backus and Dijkstra (https://medium.com/@acidflask/this-guys-arrogance-takes-your-breath-away-5b903624ca5f), I had more time to read it last night, while throwing bricks through the TV!) – it seems they ended up being civil to each other and maintaining a friendship. But it seems to me that at higher-level discussion about what languages should be that we beat each other up and divide (Douglas Crockford noted this phenomenon). I know break-away dialects of Eiffel were tried when others did not agree with some design decision (covariance). This seems to be the mark of the 1960s – languages were sprouting up everywhere – no one could agree on the right improvements to ALGOL. So FORTRAN retained its dominance, and then C slipped in almost unnoticed. My question is: how much were Kernighan and Ritchie aware of these issues and once C was settled on (from CPL and BCPL) were keen to keep it from splitting, which was a very successful thing until C++ split away?

I read something in “The C Programming Language” that made me think this once, and was determined to read the whole thing to analyze that – but then couldn’t find the original remark. I know C was sold to its followers as "the ultimate language why would anyone want anything else”. This has effectively killed language progress. Maybe a lot of it was a reaction against the didactic approach of Dijkstra, certainly the suspicion that Pascal just had training wheels for beginners was a strong idea (although Kernighan did have some valid points about the weaknesses of Pascal). But maybe Wirth had to completely replaced Pascal with Modula and Oberon without providing a way forward. So industry programmers had a gutful of ‘language improvement’.

Probably enough for this post.

Ian Joyner

unread,
May 18, 2019, 9:30:42 PM5/18/19
to Eiffel Users
On 19 May 2019, at 02:34, r...@amalasoft.com wrote:
an area where things like garbage collection were seen as the spawn of Satan

Countering widely held beliefs like this is difficult. Essential bounds checking for correctness and security put down as training wheels. Nefarious notions of ‘programmer freedom’. These are all arguments I have tried to identify and argue against. People don’t like exploring what the alternatives are or considering to a sufficiently deep level. I quoted John Iliffe’s paper yesterday – from personal correspondence with someone who corresponds with Iliffe it seems he withdrew from computing very disillusioned. I’m glad to see that others like Bertrand, Tony Hoare and others stick to the same message. But how to break down this wall, which adversely affects everything, not just Eiffel.

I heard a radio program the other day researching how to change people’s opinions. This has certainly been more than demonstrated in this country yesterday with the election here. It showed that all the party that won had to do was to put around a lot of lies, misinformation, fake news to scare people off. It is very sad this worked – and democracy is considerably weakened. I certainly observe that in discussions (arguments) I have on Quora that opponents defending their cherished beliefs (GC spawn of satan) quickly become abusive and it seems they discuss in the tactic that loudest person wins – just like the continuing PM here. It is sad that such tactics have a habit of prevailing.


Stan Hendryx

unread,
May 19, 2019, 12:50:23 AM5/19/19
to eiffel...@googlegroups.com
I have been following this thread with considerable interest. Thank you! This photo -- of a poster I saw in a developer cubicle of a client a few weeks ago -- epitomizes attitudes I heard you describe. I had to share it! 

I, too, would like to see Eiffel work on the full stack with other technologies. A lesson learned in kindergarten is apt here--play nice with others. Many good ideas have been put forward. Find a niche (avionics, autonomous vehicles, health care...?), efficient GC, run on the VM, ... How to make them blossom? 
Please keep the conversation going! 

Stan Hendryx 
Sunnyvale, California

image1.JPG

Iordan Chahanov

unread,
May 19, 2019, 2:31:53 AM5/19/19
to Ian Joyner, Eiffel Users, ior...@jsexperts.com
Hi all,

It is an interesting discussion.

I think that Eiffel fans are more professionals than marketers.

To boost something, one needs an association with a buzz word, positioning the language as "the solution for XXX"

C - fast and embedded,
JAVA - virtual machines,
Android - smart phones, etc.

and of course, one needs to find a big company as a driving force and backer.

Eiffel is the best language, but 80% of the people simply don't need it.

The way to go ahead - in addition to already present features of Eiffel, we need to make it "The best" for specific applications.

There are three markets that definitely will grow in the near future:
- Internet of thinks (embedded) - for example there are LoRa modules now you can program at Python (no need to know any other language)
- Autonomous "everything"
- AI/Machine learning

An possible example:
An easy to use Eiffel library for all growing Raspberry PI, Orange PI, Thinker board, etc. Linux based devices.

This is very strong marketing - you start from simple examples at home and go to complex connected solutions.

Best regards,

Iordan Chahanov
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Woland's Cat

unread,
May 19, 2019, 5:19:52 AM5/19/19
to eiffel...@googlegroups.com
this is also how standards development at ISO and HL7 work: everything is consensus-based +loudest voice wins (well ISO also has bloc-voting like Eurovision - to create technical standards!). Problem is the consensus usually only has a weak relationship with truth or reality,  unless it's only surgeons, pilots or nuclear power station employees in the room. The result of this is that there are official standards in e-health that are objectively just wrong in the terms of their own technical formalisms.

I find good quality red wine sometimes helps ...

- thomas

Ian Joyner

unread,
May 19, 2019, 8:43:51 AM5/19/19
to Eiffel Users
On 19 May 2019, at 19:19, Woland's Cat <wolan...@gmail.com> wrote:
this is also how standards development at ISO and HL7 work: everything is consensus-based +loudest voice wins (well ISO also has bloc-voting like Eurovision - to create technical standards!). Problem is the consensus usually only has a weak relationship with truth or reality,  unless it's only surgeons, pilots or nuclear power station employees in the room. The result of this is that there are official standards in e-health that are objectively just wrong in the terms of their own technical formalisms.

I find good quality red wine sometimes helps …

Indeed. Frank brought quite a few bottles from his winery near Jerilderee lately:


A mere $500 a bottle! Tonight’s red < 100th the cost!

- thomas

On 19/05/2019 02:30, Ian Joyner wrote:
On 19 May 2019, at 02:34, r...@amalasoft.com wrote:
an area where things like garbage collection were seen as the spawn of Satan

Countering widely held beliefs like this is difficult. Essential bounds checking for correctness and security put down as training wheels. Nefarious notions of ‘programmer freedom’. These are all arguments I have tried to identify and argue against. People don’t like exploring what the alternatives are or considering to a sufficiently deep level. I quoted John Iliffe’s paper yesterday – from personal correspondence with someone who corresponds with Iliffe it seems he withdrew from computing very disillusioned. I’m glad to see that others like Bertrand, Tony Hoare and others stick to the same message. But how to break down this wall, which adversely affects everything, not just Eiffel.

I heard a radio program the other day researching how to change people’s opinions. This has certainly been more than demonstrated in this country yesterday with the election here. It showed that all the party that won had to do was to put around a lot of lies, misinformation, fake news to scare people off. It is very sad this worked – and democracy is considerably weakened. I certainly observe that in discussions (arguments) I have on Quora that opponents defending their cherished beliefs (GC spawn of satan) quickly become abusive and it seems they discuss in the tactic that loudest person wins – just like the continuing PM here. It is sad that such tactics have a habit of prevailing.




--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
Reply all
Reply to author
Forward
0 new messages