
Eiffel programming language - modinfo
https://en.wikipedia.org/wiki/Eiffel_(programming_language)
======
perlgeek
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...

~~~
hinkley
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.

~~~
perlgeek
> 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.

~~~
ncmncm
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.

~~~
pjmlp
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.

Ada has had RAII since Ada95.

------
jaw
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.

~~~
troughway
@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.

~~~
pjmlp
Agree with you

As for method_missing, what do you miss from IDynamicMetaObjectProvider and
related classes?

------
int_19h
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
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.

------
rb808
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.

~~~
bhaak
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?

~~~
pmontra
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.)

------
pjmlp
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.

------
kbd
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.

------
neilwilson
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
> 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
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.

------
thiscatis
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.

------
alphakilo
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/sta...](https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start)

[1] -
[https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/sta...](https://wiki.eecs.yorku.ca/course_archive/2019-20/W/3311/start)

[2] -
[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft-
contracts.md)

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

~~~
pjmlp
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.

~~~
mhd
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.

~~~
zozbot234
> ...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.

~~~
mhd
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.

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

~~~
elviejo
Except for the little fact that Eiffel has had those features since 1986.

Agda first release was in 2007 Idris also in 2007 Liquid Haskell thesis was
published in 2016

~~~
pezo1919
Note the words "to me".

