[eeps] Proposal for /\ and \/ operators

[Ulf Wiger]

Adriano Bonat wrote:
> 
> This problem of breaking legacy code leads me to
 > the question: how does erlang versions work?
 > I mean what defines the change between the
> release 10 to 11, 11 to 12 (the current one).
> 
> IMO, I would priorize the language readability
 > instead of the backward-compatibility, so its
 > better implement the max/min in a new release
 > version and make it well documented to everyone
 > be aware. An example of this approach is used
 > by Python 2 to 3.

Having worked in a project that had nearly two
million lines of code for non-stop operation, and
products installed in remote places all over the
world, I've always been amazed at the willingness
of some language communities to break legacy code.

I can assure you that if the OTP team is unwilling
to sacrifice backward compatibility, we had something
to do with it. In the very early days of OTP (up until
R3, I think), it was rather the other way around, as
a lot of stuff needed fixing and extending. But when
we tried to do a proof-of-concept port of our code
(then much smaller, but still pretty large by most
standards) over to a new major version, it took us
three months to fix all the breakage due to
incompatible changes. As a result, project managers
would assume that bringing in a new OTP release was
impossible, until proven possible.

No one who was there is eager to return to that state
of affairs, I'm sure, and the OTP team has also
learned the hard way that paying customers who are
afraid to move over to the newest release, is likely
to request special builds with the old stuff they
trust along with the new bits that they can't do
without.

For many years now, you've been able to trust that
moving over to a new major OTP release is much more
likely to improve your system than break it, even if
you don't recompile. This is a very good thing.

It also means that even if you are working against a
deadline and you find problems that only a new version
of OTP will fix, making that move is actually a viable
alternative. If the new release breaks other parts of
your code in umpteen different ways, it isn't.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com