10 ms·

Eiffel programming language

109 points by modinfo 7y ago

kbd 7y ago
Eiffel is the reason I always looked at Java as a horrible fad. In high school when I was reading everything I could about software development, I read Object Oriented Software Construction. Immediately after, I read a book on Java 1.2 to learn Java, and could only think how poor Java was in comparison.
- fishmaster 7y ago
  As a language Java is poor compared to most languages...
  - ncmncm 7y ago
    Yes. Some would say all languages, but there is Forth (which has its merits). Java is essentially C++ as of 1991, with GC and interfaces tacked on, no user value types, and a whole series of misunderstandings of fundamentals. It represented a marvelous opportunity, squandered: abandoning C compatibility, there are so many things that could be done better. Instead, they copied the mistakes and added new ones.
    - pjmlp 7y ago
      My major complaints, were lack of AOT compiler as part of the Sun toolchain and not having value types. Now they are on this major engineering effort trying to retrofit value types, without breaking jars compiled 25 years ago.
    - fishmaster 7y ago
      Exactly. Could have been great but isn't.
  - hota_mazi 7y ago
    When it came out in 1995, as a then-C++ programmer, I can tell you that Java was an absolute dream to program in and a breath of fresh air.
    - pjmlp 7y ago
      Indeed, we would even put up with it being interpreted hoping for better days, which eventually came. My pet peeve was trying to write portable C or C++ code, even across UNIX platforms, let alone when one would add Windows and or non-POSIX systems into the mix.
pjmlp 7y ago
Besides introducing "Design by Contract", Eiffel was one of the first languages to introduce non nullable references, a development environment that mixes JIT and AOT (via system C and C++ compilers). A bit too late I guess, but nowadays there is a community edition for open source projects.
stewbrew 7y ago
IMHO Eiffel's concept of simplicity is rather similar to what golang is aiming at today. It didn't serve Eiffel well.
- ofrzeta 7y ago
  I don't see much similarity there. Eiffel is much more a classic OOP language and has classes and generics.
- pjmlp 7y ago
  They are totally unrelated. Eiffel has generics, value and reference types, design by contract, non nullable references, pure OOP in Smalltalk linage, agents, it is designed for IDE based tooling, since the beginning had a mixed mode development workflow (VM inside the IDE and C or C++ compilers for release mode), uses dynamic loading for extensibility,... The only thing that killed Eiffel in the mainstream was the target audience of Eiffel Software, basically enterprise with deep pockets delivering projects in areas where Eiffel capabilities are relevant. The fact that Eiffel Software remains in business, kind of proves that there are enough companies willing to pay for such tooling.
  - magoghm 7y ago
    Actually, Bertrand Meyer (the creator of the Eiffel Programming Language) has always emphasized that the object oriented origin of Eiffel comes from Simula 67 and not from Smalltalk.
    - h8hawk 7y ago
      Yeah, according to his book OOP is mostly about inheritance (Java/c++ style OOP) rather than message passing or objects . Eiffel even support multiple inheritance.
      - pjmlp 7y ago
        Smalltalk supports multiple inheritance via traits, added to post Smalltalk-80 systems.
perlgeek 7y ago
As a teenager I read "Object Oriented Software Construction" by Bertrand Meyer, and was convinced that Eiffel was THE programming language of choice. However, that love didn't last long. Too many simple things just took way too much effort to do, and most damning of all, there was no working ecosystem of libraries. There were some libraries, but getting them to actually work with your version of Eiffel was a huge hassle (and not always successful), and there were, like 20 to 50 libraries in total. I'm still missing some of the language features in other languages though...
- pbowyer 7y ago
  > As a teenager I read "Object Oriented Software Construction" by Bertrand Meyer, and was convinced that Eiffel was THE programming language of choice. > However, that love didn't last long. Too many simple things just took way too much effort to do, and most damning of all, there was no working ecosystem of libraries. Same! I still have the book on my shelf.
  - amelius 7y ago
    Me too. If anybody would like to have a taste of the ideas of Meyer, then have a look at this paper: http://se.ethz.ch/~meyer/publications/acm/typing.pdf http://se.ethz.ch/~meyer/publications/acm/typing.pdf
- yawaramin 7y ago
  What was an example of a simple thing that took too much effort in Eiffel?
  - perlgeek 7y ago
    File IO, regex matching, printing a text table, making HTTP requests and so on.
- hinkley 7y ago
  I don’t think Meyer understood that the era of free compilers had begun. He continued to charge money for the compiler while Java was establishing itself. We were starting to see rules of language adoption (like “build Hello World in 10 minutes, something trivial in the first hour”). But by the time he learned these too, the Java train had already left the station. But one of the other things we were starting to learn is that most successful languages have a champion, in the form of a larger corporate backer (Java, Go, C), or an IDE company (Kotlin, Turbo Pascal). Once in a while a flagship application will serve (Rust, Elixir, perhaps Ruby). I don’t recall Eiffel having any of those. And I wanted to try Eiffel but could not afford the cover charge, by the time I could I had specializations that were still uncommon enough that switching languages seemed like a bad move. I still have it on my todo list to hunt up some of Meyer’s writing and spelunk for lost wisdom, but not for the language itself.
rb808 7y ago
Eiffel was always great, the biggest problem as I remember it was that the compiler was very expensive, like a few thousand dollars a license. Meanwhile C++ was much cheaper (and easy to pirate) and Java was free. You can see the resulting popularity.
- deleted 7y ago
  [deleted]
- bhaak 7y ago
  I was on the Java train in the 90s, so I didn't pay much attention to C++ compilers. Therefore my question, wasn't the GNU C++ compiler an option at the time?
  - rb808 7y ago
    Gnu C++ compiler was around but wasn't that good, it produced slow binaries and was slow with new features eg didn't have templates for a long time. Usually you had to use the compiler that came with your flavor of Unix which was usually free (then later they started charging for that too). Borland and MS Visual C++ were popular on Windows and just a few hundred dollars.
  - pmontra 7y ago
    My experience in the early 90s: the compiler from HP was better than gcc, but for some reason we were downloading each version of gcc from the Usenet, building it (hours) and using it. Maybe some of the servers at university (all HP) didn't have a compiler licence? Or gcc did something the HP compiler couldn't do: maybe it compiled all the GNU userland and the other free/open source and the HP compiler couldn't. I remember that the portability issues were quite big back at the time (BSD vs SysV derivatives, etc.)
  - goatinaboat 7y ago
    wasn't the GNU C++ compiler an option at the time? GCC wasn’t usable for serious C++ applications at the time because hardware costs would kill you. The SPARCworks binaries were so much better that the compiler licences paid for themselves 10x over (maybe more!) in the extra CPUs we didn’t need to buy. This was true up at least until the mid 00s. Even today many people find it worthwhile to pay for the Intel compiler for the same reason.
thiscatis 7y ago
Eiffel was THE language of choice at my university for the "commercial engineering" degree. It's a masters that mixes engineering with business courses and has IT too but is not Software Engineering focussed. I always wondered if there are actual large scale production systems using that language.
jaw 7y ago
I'm fascinated by the idea of first-class support for preconditions/postconditions and class invariants. Has anyone worked on a large code base (whether in Eiffel or not) that made extensive use of those constructs? Obviously it's common to put argument validity checks at the start of functions, and to check invariants at some critical points. But I'm curious how the existence of specially designated slots on every method/class for checking arbitrary invariants affects developer behavior and productivity.
- AdieuToLogic 7y ago
  I worked with a small team on a C# project which used Code Contracts[0] in one of its products and another small team which used DbC[1] macros in C++ code bases. Both enhanced the intrinsic quality of the code bases and served as a valuable augmentation to code documentation. They also served to enforce a "fail fast, fail loud" philosophy, which made defect identification quick to identify. The down-side is that the checks were usually compiled out of production builds (due to performance concerns, real or imagined), so interface contracts were sometimes violated due to divergence between actual and expected use. Typical resistance to using DbC was the same as other forms of code verification (such as unit testing). 0 - https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... 1 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract
- thesuperbigfrog 7y ago
  Ada 2012 supports preconditions, postconditions, type predicates, and type invariants directly in the language: https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... It is wonderful for tracing errors and detecting problems, but can be a royal pain if you are refactoring substantial parts of the code / design.
- troughway 7y ago
  @jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera. I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™. Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold. We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems. Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand. Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy. .NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.
pezo1919 7y ago
To me Eiffel and its pre/postconditions are clearly inferior to Dependently Typed languages like Idris. (Also check Agda, Liquid Haskell...)
- carapace 7y ago
  Why?
  - pezo1919 7y ago
    Because you can express these conditions and check compile time instead runtime.
    - pjmlp 7y ago
      Some contracts can be checked at compile time, if enough information is present. In fact one of the design decisions driving C++ contracts, which now will probably only show up in C++23 due to some last minute issues, is how the optimizer can take advantage of contracts while generating code. Languages like Idris are quite interesting for us on HN, but I seriously doubt that the kind of developers that languages like Eiffel are targeted to, would be able to take advantage of them with their current tooling state.
      - vyjcgtyjb 7y ago
        Contracts will not be in C++23 and certainly not in C++20.
      - ncmncm 7y ago
        C++26, if then. There were no actual issues. At the last minute a bunch of people came up with a bunch of incompatible complexifications in support of <1% uses, and that added enough confusion to kill it. Much of the confusion came from people afraid that the optimizations might be bad. Now the same people who came up with the complications are driving the redesign, with no clear goals or unifying architecture, and no participation by the original designers. Don't expect to see contract support anytime soon.
neilwilson 7y ago
NICE still exists - just about (Nonprofit International Consortium for Eiffel). http://www.eiffel-nice.org/index.html http://www.eiffel-nice.org/index.html Had a lot of fun with Eiffel back in the day. Being able to work closely with Bertrand on the language was a great privilege. For me the great innovation of Eiffel was the ability to turn off the pre-conditions once you'd shown the code works, thereby preventing your code methods wasting time verifying and validating the parameters needlessly at run time.
- zozbot234 7y ago
  > For me the great innovation of Eiffel was the ability to turn off the pre-conditions once you'd shown the code works So, like assert() and NDEBUG? Hard to describe that as an 'innovation', tbh. Though it's a nice feature indeed.
  - neilwilson 7y ago
    It was in Eiffel from the late 1980s. When did the assert macro end up in C? Eiffel and the OOSC book had a big influence.
int_19h 7y ago
One thing that I never understood about Eiffel is why, for all the focus on correctness, it has that gaping hole in its type system in form of catcalls (and IIRC there were also some implicit and not-always-safe variance assumptions for generics?). I know that Meyer insists that covariant redefinitions are necessary to model the real world. But that's only true with Eiffel's inheritance model intermingling types and implementation! In OCaml, for example, subclasses of a class need not be subtypes; and if you want both subtyping and catcalls, then you parametrize the base class accordingly.
- claudionaoto 7y ago
  Meyer did not know that the type system was unsound. This was discovered later by Luca Cardelli. Meyer said that he would correct it but it seems that existing libraries used this covariant feature too much and they instead made some ugly hack using whole program analysis.
alphakilo 7y ago
Funny to see this here on the front page of HN! I'm currently enrolled in a university level course in Software Design that uses Eiffel [0]. The Eiffel language makes sense for wanting to translate your design by contact (DbC) logic to code, but is very frustrating to work with. The tooling is quite old and outdated compared to modern IDEs. I will say that the course works very well fro demonstrating applications of EECS 3342 - System Specification and Refinement [1] that extends MATH 1090 - Introduction to Logic for Computer Science into the application world. In regards to modern usage, it is hard to think how we can validate preconditions and post conditions in a cloud native world without additional development of libraries. Overall though, the course has students struggling with learning the new tooling and syntax when the University has only taught Java and C thus far. I do find DbC interesting and I think it would be interesting to see it given first class support (Go Contracts draft [2]), but the reality is that TDD can accomplish the same at a much faster development speed. [0] - https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta... [1] - https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta... [2] - https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md https://go.googlesource.com/proposal/+/master/design/go2draf...

109 points by modinfo 7y ago

kbd 7y ago

Eiffel is the reason I always looked at Java as a horrible fad. In high school when I was reading everything I could about software development, I read Object Oriented Software Construction. Immediately after, I read a book on Java 1.2 to learn Java, and could only think how poor Java was in comparison.

fishmaster 7y ago
As a language Java is poor compared to most languages...
- ncmncm 7y ago
  Yes. Some would say all languages, but there is Forth (which has its merits). Java is essentially C++ as of 1991, with GC and interfaces tacked on, no user value types, and a whole series of misunderstandings of fundamentals. It represented a marvelous opportunity, squandered: abandoning C compatibility, there are so many things that could be done better. Instead, they copied the mistakes and added new ones.
  - pjmlp 7y ago
    My major complaints, were lack of AOT compiler as part of the Sun toolchain and not having value types. Now they are on this major engineering effort trying to retrofit value types, without breaking jars compiled 25 years ago.
  - fishmaster 7y ago
    Exactly. Could have been great but isn't.
- hota_mazi 7y ago
  When it came out in 1995, as a then-C++ programmer, I can tell you that Java was an absolute dream to program in and a breath of fresh air.
  - pjmlp 7y ago
    Indeed, we would even put up with it being interpreted hoping for better days, which eventually came. My pet peeve was trying to write portable C or C++ code, even across UNIX platforms, let alone when one would add Windows and or non-POSIX systems into the mix.

pjmlp 7y ago

Besides introducing "Design by Contract", Eiffel was one of the first languages to introduce non nullable references, a development environment that mixes JIT and AOT (via system C and C++ compilers). A bit too late I guess, but nowadays there is a community edition for open source projects.

stewbrew 7y ago

IMHO Eiffel's concept of simplicity is rather similar to what golang is aiming at today. It didn't serve Eiffel well.

ofrzeta 7y ago
I don't see much similarity there. Eiffel is much more a classic OOP language and has classes and generics.
pjmlp 7y ago
They are totally unrelated. Eiffel has generics, value and reference types, design by contract, non nullable references, pure OOP in Smalltalk linage, agents, it is designed for IDE based tooling, since the beginning had a mixed mode development workflow (VM inside the IDE and C or C++ compilers for release mode), uses dynamic loading for extensibility,... The only thing that killed Eiffel in the mainstream was the target audience of Eiffel Software, basically enterprise with deep pockets delivering projects in areas where Eiffel capabilities are relevant. The fact that Eiffel Software remains in business, kind of proves that there are enough companies willing to pay for such tooling.
- magoghm 7y ago
  Actually, Bertrand Meyer (the creator of the Eiffel Programming Language) has always emphasized that the object oriented origin of Eiffel comes from Simula 67 and not from Smalltalk.
  - h8hawk 7y ago
    Yeah, according to his book OOP is mostly about inheritance (Java/c++ style OOP) rather than message passing or objects . Eiffel even support multiple inheritance.
    - pjmlp 7y ago
      Smalltalk supports multiple inheritance via traits, added to post Smalltalk-80 systems.

perlgeek 7y ago

As a teenager I read "Object Oriented Software Construction" by Bertrand Meyer, and was convinced that Eiffel was THE programming language of choice. However, that love didn't last long. Too many simple things just took way too much effort to do, and most damning of all, there was no working ecosystem of libraries. There were some libraries, but getting them to actually work with your version of Eiffel was a huge hassle (and not always successful), and there were, like 20 to 50 libraries in total. I'm still missing some of the language features in other languages though...

pbowyer 7y ago
> As a teenager I read "Object Oriented Software Construction" by Bertrand Meyer, and was convinced that Eiffel was THE programming language of choice. > However, that love didn't last long. Too many simple things just took way too much effort to do, and most damning of all, there was no working ecosystem of libraries. Same! I still have the book on my shelf.
- amelius 7y ago
  Me too. If anybody would like to have a taste of the ideas of Meyer, then have a look at this paper: http://se.ethz.ch/~meyer/publications/acm/typing.pdf http://se.ethz.ch/~meyer/publications/acm/typing.pdf
yawaramin 7y ago
What was an example of a simple thing that took too much effort in Eiffel?
- perlgeek 7y ago
  File IO, regex matching, printing a text table, making HTTP requests and so on.
hinkley 7y ago
I don’t think Meyer understood that the era of free compilers had begun. He continued to charge money for the compiler while Java was establishing itself. We were starting to see rules of language adoption (like “build Hello World in 10 minutes, something trivial in the first hour”). But by the time he learned these too, the Java train had already left the station. But one of the other things we were starting to learn is that most successful languages have a champion, in the form of a larger corporate backer (Java, Go, C), or an IDE company (Kotlin, Turbo Pascal). Once in a while a flagship application will serve (Rust, Elixir, perhaps Ruby). I don’t recall Eiffel having any of those. And I wanted to try Eiffel but could not afford the cover charge, by the time I could I had specializations that were still uncommon enough that switching languages seemed like a bad move. I still have it on my todo list to hunt up some of Meyer’s writing and spelunk for lost wisdom, but not for the language itself.

rb808 7y ago

Eiffel was always great, the biggest problem as I remember it was that the compiler was very expensive, like a few thousand dollars a license. Meanwhile C++ was much cheaper (and easy to pirate) and Java was free. You can see the resulting popularity.

deleted 7y ago
[deleted]
bhaak 7y ago
I was on the Java train in the 90s, so I didn't pay much attention to C++ compilers. Therefore my question, wasn't the GNU C++ compiler an option at the time?
- rb808 7y ago
  Gnu C++ compiler was around but wasn't that good, it produced slow binaries and was slow with new features eg didn't have templates for a long time. Usually you had to use the compiler that came with your flavor of Unix which was usually free (then later they started charging for that too). Borland and MS Visual C++ were popular on Windows and just a few hundred dollars.
- pmontra 7y ago
  My experience in the early 90s: the compiler from HP was better than gcc, but for some reason we were downloading each version of gcc from the Usenet, building it (hours) and using it. Maybe some of the servers at university (all HP) didn't have a compiler licence? Or gcc did something the HP compiler couldn't do: maybe it compiled all the GNU userland and the other free/open source and the HP compiler couldn't. I remember that the portability issues were quite big back at the time (BSD vs SysV derivatives, etc.)
- goatinaboat 7y ago
  wasn't the GNU C++ compiler an option at the time? GCC wasn’t usable for serious C++ applications at the time because hardware costs would kill you. The SPARCworks binaries were so much better that the compiler licences paid for themselves 10x over (maybe more!) in the extra CPUs we didn’t need to buy. This was true up at least until the mid 00s. Even today many people find it worthwhile to pay for the Intel compiler for the same reason.

thiscatis 7y ago

Eiffel was THE language of choice at my university for the "commercial engineering" degree. It's a masters that mixes engineering with business courses and has IT too but is not Software Engineering focussed. I always wondered if there are actual large scale production systems using that language.

jaw 7y ago

I'm fascinated by the idea of first-class support for preconditions/postconditions and class invariants. Has anyone worked on a large code base (whether in Eiffel or not) that made extensive use of those constructs? Obviously it's common to put argument validity checks at the start of functions, and to check invariants at some critical points. But I'm curious how the existence of specially designated slots on every method/class for checking arbitrary invariants affects developer behavior and productivity.

AdieuToLogic 7y ago
I worked with a small team on a C# project which used Code Contracts[0] in one of its products and another small team which used DbC[1] macros in C++ code bases. Both enhanced the intrinsic quality of the code bases and served as a valuable augmentation to code documentation. They also served to enforce a "fail fast, fail loud" philosophy, which made defect identification quick to identify. The down-side is that the checks were usually compiled out of production builds (due to performance concerns, real or imagined), so interface contracts were sometimes violated due to divergence between actual and expected use. Typical resistance to using DbC was the same as other forms of code verification (such as unit testing). 0 - https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... 1 - https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract
thesuperbigfrog 7y ago
Ada 2012 supports preconditions, postconditions, type predicates, and type invariants directly in the language: https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... It is wonderful for tracing errors and detecting problems, but can be a royal pain if you are refactoring substantial parts of the code / design.
troughway 7y ago
@jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera. I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™. Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold. We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems. Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand. Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy. .NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.

pezo1919 7y ago

To me Eiffel and its pre/postconditions are clearly inferior to Dependently Typed languages like Idris. (Also check Agda, Liquid Haskell...)

carapace 7y ago
Why?
- pezo1919 7y ago
  Because you can express these conditions and check compile time instead runtime.
  - pjmlp 7y ago
    Some contracts can be checked at compile time, if enough information is present. In fact one of the design decisions driving C++ contracts, which now will probably only show up in C++23 due to some last minute issues, is how the optimizer can take advantage of contracts while generating code. Languages like Idris are quite interesting for us on HN, but I seriously doubt that the kind of developers that languages like Eiffel are targeted to, would be able to take advantage of them with their current tooling state.
    - vyjcgtyjb 7y ago
      Contracts will not be in C++23 and certainly not in C++20.
    - ncmncm 7y ago
      C++26, if then. There were no actual issues. At the last minute a bunch of people came up with a bunch of incompatible complexifications in support of <1% uses, and that added enough confusion to kill it. Much of the confusion came from people afraid that the optimizations might be bad. Now the same people who came up with the complications are driving the redesign, with no clear goals or unifying architecture, and no participation by the original designers. Don't expect to see contract support anytime soon.

neilwilson 7y ago

NICE still exists - just about (Nonprofit International Consortium for Eiffel). http://www.eiffel-nice.org/index.html http://www.eiffel-nice.org/index.html Had a lot of fun with Eiffel back in the day. Being able to work closely with Bertrand on the language was a great privilege. For me the great innovation of Eiffel was the ability to turn off the pre-conditions once you'd shown the code works, thereby preventing your code methods wasting time verifying and validating the parameters needlessly at run time.

zozbot234 7y ago
> For me the great innovation of Eiffel was the ability to turn off the pre-conditions once you'd shown the code works So, like assert() and NDEBUG? Hard to describe that as an 'innovation', tbh. Though it's a nice feature indeed.
- neilwilson 7y ago
  It was in Eiffel from the late 1980s. When did the assert macro end up in C? Eiffel and the OOSC book had a big influence.

int_19h 7y ago

One thing that I never understood about Eiffel is why, for all the focus on correctness, it has that gaping hole in its type system in form of catcalls (and IIRC there were also some implicit and not-always-safe variance assumptions for generics?). I know that Meyer insists that covariant redefinitions are necessary to model the real world. But that's only true with Eiffel's inheritance model intermingling types and implementation! In OCaml, for example, subclasses of a class need not be subtypes; and if you want both subtyping and catcalls, then you parametrize the base class accordingly.

claudionaoto 7y ago
Meyer did not know that the type system was unsound. This was discovered later by Luca Cardelli. Meyer said that he would correct it but it seems that existing libraries used this covariant feature too much and they instead made some ugly hack using whole program analysis.

alphakilo 7y ago

Funny to see this here on the front page of HN! I'm currently enrolled in a university level course in Software Design that uses Eiffel [0]. The Eiffel language makes sense for wanting to translate your design by contact (DbC) logic to code, but is very frustrating to work with. The tooling is quite old and outdated compared to modern IDEs. I will say that the course works very well fro demonstrating applications of EECS 3342 - System Specification and Refinement [1] that extends MATH 1090 - Introduction to Logic for Computer Science into the application world. In regards to modern usage, it is hard to think how we can validate preconditions and post conditions in a cloud native world without additional development of libraries. Overall though, the course has students struggling with learning the new tooling and syntax when the University has only taught Java and C thus far. I do find DbC interesting and I think it would be interesting to see it given first class support (Go Contracts draft [2]), but the reality is that TDD can accomplish the same at a much faster development speed. [0] - https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta... [1] - https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta... [2] - https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md https://go.googlesource.com/proposal/+/master/design/go2draf...