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...
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.
> 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.
Even in the mid-late 90s IBM was still backing Smalltalk as the next big thing, with its (expensive) VisualAge products. By the end of the 90s they had ditched it entirely and pivoted to Java Java Java.
That was slightly before my time in the industry, do you have any indication on how hard they were backing it? I mean IBM brings out a lot of stuff and was quite aimless in the late 90s/early '00s. They were supporting SmallTalk for quite a while, but on the other hand, so they did with RPG and PL/I…
> I don’t think Meyer understood that the era of free compilers had begun.
That's right, and something I had totally forgotten.
I started with a shareware version (?) of Eiffel Studio, and later it was made free as long as you used it either for non-commercial purposes, or released your software as GPL.
Looking back at it, that just sounds quaint.
I think the IDE was actually written in Eiffel, and was pretty good for that time, but not good enough to stand out, like Turbo Pascal did back in the days.
Ah, yessss, Cepage, or "seepage". At the very first talk I went to, to find out about Eiffel, in 1986, Meyer spent 3/4 of his alotted time talking about Cepage. Soured me.
It was an interesting language, in some ways, and could have been extended enough to be useful but, like Modula-3 and Oberon, even at the time obviously would not supplant C++. Rust could still suffer the same fate if it can't fix its compiler-speed problems. It's the only candidate on the horizon, with its Drop trait, for those places where nothing else will do.
Wirth has mentions in one of its articles, not sure which, that he just expected too much from mainstream.
He was convinced, that by building such systems, mainstream programmers that cared about quality engineering would just flock to Modula-2 and Oberon, and in retrospect some advertising effort could have been done.
Modula-3 was killed by Compaq and HP, after their cascade acquisition from Olivetti research labs, they never cared about this kind of research.
Rust might have better chance, because just like it happened with C++ vs C, there are a couple of big names that care about it nowadays. Microsoft just had an internal Rust Summit.
Also Ada is still around, NVidia and Genode OS being two relevant names that have recently adopted it for security critical software layers.
I went through the same thing, and I think that may be why I prefer Ruby over Python. I still have a soft spot for Eiffel and checked it out recently, but the tooling situation and library ecosystem is still not great, and I can’t see myself actually using it for anything practical.
> 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.
What langugage features are you missing? When I learnt about Eiffel, Contract Oriented Programming was the thing, but these contracts are easily done in Elixir, so they aren't that special. Oh yeah, the tooling was horrible.
Apparently you can generally assume x = x, which seems like a very nice feature and one that's perversely absent in all other programming languages I can think of.
My first 2 years of university were using Eiffel in a NeXT lab. The professors had built up their own standard libraries. Some of the preconditions and postconditions got a little annoying, but probably staved off a lot of bugs.
Junior year they switched everything to Java. The CS lab switched to macs, but the main computer labs were mostly all windows, but CS students could finally work on their CS programs there if they didn't have their own computer (but everyone did anyways)
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.
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).
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Enterprises supporting their sunk costs supports a lot, that by itself isn't a good judgment of quality. I wouldn't be surprised if more enterprises use Clipper than Eiffel...
Eiffel had similar issues that Pascal had: Appearing too much like an educational, purist language and having "good enough" more popular alternatives on the market (C/C++ vs. C++/Java).
And authors that don't compromise to sell stuff.
The crappy "SmallEiffel" situation didn't help either. It started out pretty great (good feature set, quick and cross-platform compiles via C), but then, erm, FOSS nature took its course. Which is why I'm a bit ware of similar language and their situations since then, e.g. Nim.
Man, there was a time in the 90s where I was hoping that we'd get Eiffel (or Sather) as the next big open source desktop language. Instead we still have walled garden C++ and reinvent-the-wheel C.
Had forgotten about Sather. Was too poor to afford Eiffel itself, but I remember really liking Sather and using it some.
That said, that was about the time I started realizing just how pointless it is to learn niche languages, as anything other than an amusement. I can't recall the wording, but trumpet players have a saying that you can learn flugelhorn for fun, but trumpet is always going to be what pays your bills.
I was just talking about Linux/BSD desktop apps and their implementation languages/libraries. Not a lot changed there, and the RESF seems to focus on more fashionable/achievable things (The only non-C++ option for Qt right now seems Python, and the most popular non-C language for gtk is probably Vala).
Right now not enough hubris for either Go or Rust to do a build their own thing right from scratch.
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.
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.
Except that Simula allows free functions and Eiffel does not, while Eiffel also supports metaclasses and Simula does not, additionally using MELT feels like having a Smalltalk image, so it is a bit strange his point of view.
They're unrelated but their stance towards simplicity seems similar to me. Listening to golang core developers makes me remember (Smart)Eiffel developers.
Golang is rather a brain child of Oberon-2, not Eiffel. But you hit it insofar that Bertrand Meyer, the inventor of Eiffel, was professor of software engineering at ETH Zürich on the same chair as Niklaus Wirth, the inventor of Oberon.
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.
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.
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...