4 ms·

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Genericity https://en.wikipedia.org/wiki/Eiffe

by vram22 9y ago

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Genericity https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

pjmlp 9y ago
I liked using it at the university back in the day, and didn't had to repeat code. Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.
- vram22 9y ago
  Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic and industrial use perspective - so it seemed to me. There is also an interesting anecdote about use of Eiffel in the book, here: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction#Notation https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... That section shows the the 1st edition of the book did use Eiffel (as I said above).
  - pjmlp 9y ago
    With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries. So combining the easiness of interactive development with performance when it was time to ship the product. It was also available before Java was a thing. This is what I always kind of missed with Java and .NET, the previous generation of languages (Eiffel, Modula-3, Oberon(-2)) all had a mix of interactive development and AOT compilation for shipping release builds.
    - hota_mazi 9y ago
      You seem to imply that Eiffel's solution was superior to Java's but nothing could be further from the truth. The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). It was very hard to debug, with gdb routinely giving up on the complex .o generated. It was a very verbose language that implemented all known features under the sun, a bit like Ada and Scala. Eiffel didn't take off for some very solid reasons.
      - vram22 9y ago
        >It was a very verbose language (Haven't worked much on Java recently, but did use it a fair amount some years ago.) Isn't Java roughly equally verbose as Eiffel? >that implemented all known features under the sun At least based on looking at the Wikipedia article for Eiffel, it does not seem to have implemented functional programming, unless the article is out-of-date, or unless the agent mechanism supports FP somehow (not sure about that last bit).
      - rbehrends 9y ago
        > The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). This was not an inherent problem of the language, but one of the implementation. I know this because I wrote a compiler for an Eiffel dialect for my Ph.D. thesis and there have been other Eiffel compilers without these shortcomings. Also, EiffelStudio – which seems to be what you are talking about – generated C code, not C++ and had the option to generate an intermediate representation instead that could be mixed with compiled code. > It was a very verbose language that implemented all known features under the sun, a bit like Ada and Scala. It was actually pretty minimalist, not at all like Ada or Scala. Code was verbose because (1) programmers were encouraged to annotate methods with contracts and (2) exactly because it was minimalist and didn't have a lot of alternative ways of expressing the same functionality. Edit: There are two hard parts about writing an Eiffel compiler. 1. Getting the semantics of feature renaming during inheritance right. If you aren't careful, it's easy to introduce errors during this step. 2. Doing separate compilation for mutually dependent classes. This is where much of the complexity of the EiffelStudio compiler comes from. Java solved the problem by simply not allowing separate compilation in those cases. If class A has a member of type B and B has a member of type A, they need to be compiled together. Everything else that's involved in writing an Eiffel compiler does not require more than than what you learn in your typical compiler course. (Though, obviously, experience will get you better results.)
rbehrends 9y ago
The key difference between Eiffel and Java generics is that Eiffel allows for covariance by design. Obviously, this is unsafe and runtime type checks had to catch these cases. The goal was originally to resolve this through additional static constraints [1], but in the end the downsides always outweighed the benefits. In the end, Eiffel stuck with covariance and a type system that is technically unsound, because the simplicity of the type system outweighed any hypothetical gains from making it fully sound. Practical problems with Eiffel's generics arise mostly from the fact that, like Java, constrained genericity inherently relies on nominal subtyping, which makes it less expressive than it could be. [1] https://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node29.html https://www.cs.princeton.edu/courses/archive/fall98/cs441/ma...
- vram22 9y ago
  I'll check that out, thanks.
Sean1708 9y ago
Would you mind going into a bit more depth about Eiffel's generics? It's not obvious to me from Wikipedia how they differ from normal parametric polymorphism.
- vram22 9y ago
  Did you read this, which is linked to from my earlier link? https://en.wikipedia.org/wiki/Generic_programming#Genericity_in_Eiffel https://en.wikipedia.org/wiki/Generic_programming#Genericity... I may not be able to throw more light on it than that, sorry, since I'm not an expert on these areas, just interested.
  - Sean1708 9y ago
    Thanks, I completely missed that "Basic/Unconstrained genericity" was a subsection of "Genericity in Eiffel" when I first saw that page.
    - vram22 9y ago
      NP.

by vram22 9y ago

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Genericity https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

pjmlp 9y ago

I liked using it at the university back in the day, and didn't had to repeat code. Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.

vram22 9y ago
Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic and industrial use perspective - so it seemed to me. There is also an interesting anecdote about use of Eiffel in the book, here: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction#Notation https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... That section shows the the 1st edition of the book did use Eiffel (as I said above).
- pjmlp 9y ago
  With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries. So combining the easiness of interactive development with performance when it was time to ship the product. It was also available before Java was a thing. This is what I always kind of missed with Java and .NET, the previous generation of languages (Eiffel, Modula-3, Oberon(-2)) all had a mix of interactive development and AOT compilation for shipping release builds.
  - hota_mazi 9y ago
    You seem to imply that Eiffel's solution was superior to Java's but nothing could be further from the truth. The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). It was very hard to debug, with gdb routinely giving up on the complex .o generated. It was a very verbose language that implemented all known features under the sun, a bit like Ada and Scala. Eiffel didn't take off for some very solid reasons.
    - vram22 9y ago
      >It was a very verbose language (Haven't worked much on Java recently, but did use it a fair amount some years ago.) Isn't Java roughly equally verbose as Eiffel? >that implemented all known features under the sun At least based on looking at the Wikipedia article for Eiffel, it does not seem to have implemented functional programming, unless the article is out-of-date, or unless the agent mechanism supports FP somehow (not sure about that last bit).
    - rbehrends 9y ago
      > The Eiffel compiler required four distinct sequential processes (note: not phases. I really mean that four programs needed to be run in sequence, and each of these four programs implemented who knows how many passes). Eiffel generated C++, huge executables, was incredibly slow (even with contract stuff turned off). This was not an inherent problem of the language, but one of the implementation. I know this because I wrote a compiler for an Eiffel dialect for my Ph.D. thesis and there have been other Eiffel compilers without these shortcomings. Also, EiffelStudio – which seems to be what you are talking about – generated C code, not C++ and had the option to generate an intermediate representation instead that could be mixed with compiled code. > It was a very verbose language that implemented all known features under the sun, a bit like Ada and Scala. It was actually pretty minimalist, not at all like Ada or Scala. Code was verbose because (1) programmers were encouraged to annotate methods with contracts and (2) exactly because it was minimalist and didn't have a lot of alternative ways of expressing the same functionality. Edit: There are two hard parts about writing an Eiffel compiler. 1. Getting the semantics of feature renaming during inheritance right. If you aren't careful, it's easy to introduce errors during this step. 2. Doing separate compilation for mutually dependent classes. This is where much of the complexity of the EiffelStudio compiler comes from. Java solved the problem by simply not allowing separate compilation in those cases. If class A has a member of type B and B has a member of type A, they need to be compiled together. Everything else that's involved in writing an Eiffel compiler does not require more than than what you learn in your typical compiler course. (Though, obviously, experience will get you better results.)

rbehrends 9y ago

The key difference between Eiffel and Java generics is that Eiffel allows for covariance by design. Obviously, this is unsafe and runtime type checks had to catch these cases. The goal was originally to resolve this through additional static constraints [1], but in the end the downsides always outweighed the benefits. In the end, Eiffel stuck with covariance and a type system that is technically unsound, because the simplicity of the type system outweighed any hypothetical gains from making it fully sound. Practical problems with Eiffel's generics arise mostly from the fact that, like Java, constrained genericity inherently relies on nominal subtyping, which makes it less expressive than it could be. [1] https://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node29.html https://www.cs.princeton.edu/courses/archive/fall98/cs441/ma...

vram22 9y ago
I'll check that out, thanks.

Sean1708 9y ago

Would you mind going into a bit more depth about Eiffel's generics? It's not obvious to me from Wikipedia how they differ from normal parametric polymorphism.

vram22 9y ago
Did you read this, which is linked to from my earlier link? https://en.wikipedia.org/wiki/Generic_programming#Genericity_in_Eiffel https://en.wikipedia.org/wiki/Generic_programming#Genericity... I may not be able to throw more light on it than that, sorry, since I'm not an expert on these areas, just interested.
- Sean1708 9y ago
  Thanks, I completely missed that "Basic/Unconstrained genericity" was a subsection of "Genericity in Eiffel" when I first saw that page.
  - vram22 9y ago
    NP.