The Eiffel programming language
en.wikipedia.org
en.wikipedia.org
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...
> 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.
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.
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.
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.
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.
Ada has had RAII since Ada95.
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.
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)
https://bertrandmeyer.com/2010/02/06/reflexivity-and-other-p...
Another thing I miss is well thought-out inheritance, with method renaming, conflict resolution and all that.
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.
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-trac...
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.
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.
As for method_missing, what do you miss from IDynamicMetaObjectProvider and related classes?
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.
Therefore my question, 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.
A bit too late I guess, but nowadays there is a community edition for open source projects.
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.
So, like assert() and NDEBUG? Hard to describe that as an 'innovation', tbh. Though it's a nice feature indeed.
Eiffel and the OOSC book had a big influence.
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/sta...
[1] - https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta...
[2] - https://go.googlesource.com/proposal/+/master/design/go2draf...
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.
Do you know different?
My last commercial Smalltalk was Smalltalk/V, just before Java got released, so not much I can state here.
Where-as for some reason I seem to imagine Pharo classes have been re-organized to use traits?
Any details why he thinks that way?
Same type of thing killed Ada in the mainstream.
NVidia has adopted Ada/SPARK for security critical firmware, for example.
Likewise, Genode is now replacing C++ with Ada on the security critical OS layers.
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.
The RESF might take issue with that statement. Though it was of course largely true as late as the 2010s, not just in the 1990s.
Right now not enough hubris for either Go or Rust to do a build their own thing right from scratch.
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.
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.
What I've read about Eiffel on many sites is only runtime check (on more advanced constraints).
Agda first release was in 2007 Idris also in 2007 Liquid Haskell thesis was published in 2016