Name: Eiffel
ISBN: 9780132479257

What Hacker News says

fuzztesterJul 2025

What about Eiffel?

What are people's thoughts about it?

I know a little about its history, and had tried it out a bit, some years ago, via the EiffelStudio trial edition, IIRC. I had also read a good chunk of Bertrand Meyer's book, Object Oriented Software Construction. Thought the book was good.

thread

rramadassJun 2023

It is great that you are looking into OOSC2. Yes Meyer is somewhat difficult to read since he is so thorough, precise and detail-oriented that it can become tedious at times. Take your time going through the book to get the big picture of his OO design/implementation arguments rather than the details of the Eiffel language (not necessary during the first pass). It is a huge book so skip topics as needed to focus on the essential concepts.

You should also look into Meyer's "Design By Contract" technique for writing "correct" OO and other-paradigm programs. This is of great value in real-world programming.

PS: You might also find another Meyer's book Agile! The Good, the Hype and the Ugly quite instructive - https://learning.acm.org/techtalks/agile

thread

pjmlpApr 2021

https://www.amazon.com/Eiffel-Language-PRENTICE-HALL-OBJECT-...

> Quickly emerging as the language of choice for developers of quality software, this guide explains how the Eiffel language combines rigorous software engineering principles with advanced object-oriented techniques. It reveals the simplicity, consistency, and blend of various powerful mechanisms in Eiffel, including: an object-oriented structure based on classes ; multiple and repeated inheritance information hiding assertions to guarantee, document, and test the correctness of software components; strong typing backed by support for generic classes; dynamic binding a highly dynamic run-time model supporting garbage collection renaming and redefinition facilities . . . disciplined exception handling and support for persistent objects. As both an implementation language and a high-level notation for analysis and design, Eiffel emphasizes the industrial production of reusable software components. Written for software designers, analysts, and programmers.

https://www.eiffel.com/

thread

mhdFeb 2020

> I don’t think Meyer understood that the era of free compilers had begun.

It arguably hadn't. OOSC came out in '88, and that was probably the first big push of Eiffel. The dedicated book and the release of their IDE "EiffelBench" followed in '90. Free compilers weren't an issue for either commercial nor desktop customers.

But the market for the big OO language was still more open, so they would've needed to gain more ground in that era. Most of the other OO gurus of that time (and it was a fiercely personality-driven industry) favored either SmallTalk or C++. A few built other OO languages, like Oberon or Modula-3. Maybe Meyer should've collaborated/marketed more, maybe having an European background was a big downside from the very start. Maybe the whole purism was a bit too strong for an industry that likes sequels more than Hollywood does.

By the time OOSC2 came out in '97, MS heavily invested in C++ and Java was all the rage. If you wanted something alternate, you used something like Delphi. It was over by then. Small/Smart-Eiffel actually was pretty good and could've been used for even commercial projects. But no programmer used it in their day job, no killer app was written in it.

thread

nickpsecurityJul 2016

Here's some for you collection given I see some omissions. Cleanroom, always omitted (sighs), is a big one as it was doing agile-like development in 80's with code so reliable it was sometimes warrantied. Also one of first, formal methods that didn't require a mathematician to use. Fagan's Software Inspection Process came before that in the 70's. I throw in Praxis and 001 for good measure as they're engineered software methods with better results than Cleanroom albeit at higher cost. Leave off plenty of others too constrained for most software development but did prove out in smaller projects. The B Method & Chlipala's Certified Programming in Coq are examples if you want to Google around.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....

Note: An academic recently combined Cleanroom with Python for some nice results given how high-level Python is. I thought Haskell would be more ideal.

https://en.wikipedia.org/wiki/Major_Defect

Note: Describes Fagan process with relevant links.

http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct...

Note: Altran/Praxis Correct by Construction is a modern high-assurance method with numerous successes. Cost a 50% premium for nearly defect-free systems. SPARK Ada is GPL these days.

http://htius.com/Articles/articles.htm

Note: Margaret Hamilton, who helped invent software engineering on Apollo mission, deserves mention for the first tool that automated most of software process. You can spec a whole system... one company specified their whole factory haha... then it semi-automates design then automatically does code, testing, portability, requirements traces, and so on. Guarantees no interface errors, which are 80+% of software faults. Today's tools have better notations & performance but still can't do all that for general-purpose systems: always a niche.

https://www.eiffel.com/values/design-by-contract/introductio...

Note: Added Eiffel method to make up for fact that I have little to nothing on OOP given I don't use OOP. Meyer et al get credit for a powerful combo of language features and methodology in Eiffel platform with huge impact on software. Specifically, Design-by-Contract has so many benefits that even SPARK and Ada both added it to their languages. Just knocks out all kinds of problems plus can support automated generation of tests and such.

So, there's you some reading on methods of making robust software that might fit into your book or something else you do. :)

thread

haxeny1Aug 2015

Smalltalk was a great start, though, that should not have been the benchmark for implementing object oriented languages. There are some valid concerns about oo that were imo missing in mainstream languages such as Java/C++: uniform access principle (scala provides for that, but scala is a different type system) pre-conditions/postconditions as part of core language rather than annotated comments. weaker/stronger pre-conditions/postconditions in derived classes : this makes the use of methods quite obvious and what features are being inherited from the parent class. selective exports of features (this is a less known feature but can save a developer many a times). Repeated inheritance/multiple inheritance implemented right (so diamond hierarchies should be handled without having to resort to any ambiguities). Genericity (templates that understood hierarchy: this was missed in C++ at least in 2001. I havent programmed in C++ since then) Covariance (this was a direct side effect of method inheritance and I found it to be useful).

Without these features and many other features (I borrow this list from Bertrand Meyer's OOSC, 2nd edition), language compilers tend to shift the burden from the compiler to the programmer to manage types etc. It is probably too late to go back to Eiffel, though, I still think that it even today is far ahead of most oo languages, so if folks feel strongly against oo, I can understand that to some extent.

I recall a small exercise,where I was modeling Matrix using integers to do some basic addition and multiplication in Eiffel. It worked the code compiled, tested, assertions validated etc. All good. But how about determinants (I forgot the exact computation that needed that). I was still programming in java at my work and had that sinking feeling of change code at few places to make things Float and (read them as objects instead of primitives etc..you know the drill). It turned out, that the Number hierarchy in Eiffel was quite refined, I changed the declaration at one place and everything worked as expected. This was a small exercise, though it clearly outlined the power of the language.

As an aside, there was another feature that ensured that floating point numbers weren't being allocated on a heap: it was a keyword : Expanded: implying no references are created for the expanded objects. This feature alone can save a ton when decoding objects from a network etc, without me, the developer, having to worry about boxing/unboxing and the subsequent performance implications.

So, yes, OO was/is a great paradigm, though it is the details of implementation that matter. When I used to attend job interviews and was faced with one of the canned questions: which is better Java or C++, I started to take the "fifth" because I could not in all honesty compare truly bad implementations of the oo paradigm. The only reason I started to briefly look up scala was because Martin Odersky used Eiffel as one of his references : Uniform Access Principle to implementing the Scala type system. But that is as far as I could go, because, after looking at OCAML, it hit me that oo and functional can't safely mix.

thread