Re: [Caml-list] removal of C compiler variables in in 4.06

[Jesper Louis Andersen <jesper.louis.andersen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

On Tue, Jul 18, 2017 at 11:04 AM Olaf Hering <olaf@aepfle.de> wrote:

>

But if their usage is legitime,
> why the needless breakage?
>

I like to think of software as sometimes hitting a local optima. That is,
to move forward you have to stop the hill-climbing algorithm and  start
going in the "wrong direction" in order to hit a better spot later on.

Every feature in a system is also a liability later on. Hence, any change
is a balancing act of keeping backwards compatibility and moving forward.
I'd expect some breakage between software releases. Some of these are
potential incompatibilities, and in the unlucky case, an incompatibility
which noone foresaw sneaks in[0]. The goal is to manage the amount of work
it takes to upgrade systems, and possibly provide automated tools to help
doing so[1].

Removing features is a great way to move forward. I've often salvaged old
code by removing a lot of support for desirable features, revamped the
systems core, and then added those features which were truly needed later
on. We also learn in hindsight, so many changes eventually have to be
reverted. The larger your interface, the more brittle it tends to be.

That said, it certainly sounds like a too eager change since 4.06 is not
slated for release for a while. But I wanted to ramble a bit about
controlled change in a software system.

[0] 4 years ago, the Erlang serialization "external term format" was
changed to allow for certain symbols to be UTF-8 encoded. Releases would be
able to handle the decoding, but would not produce such terms. The recent
20.0-rc1 release enabled the feature since it was believed that backwards
compatibility was in place. Yet, it broke systems because they rely on
things like the lexicographic ordering of the marshalled serialization,
among other things. The final release had to avoid producing the new UTF-8
encoded form if the symbol (atom) was representable in the old (ASCII)
form. Erlang highly values its backwards compatibility because upgrades to
clusters tend to happen one machine at a time.

[1] The Go language used a tool 'go fix' to upgrade breaking changes to the
syntax before release 1.0 of the language. This enabled change, yet
provided an upgrade path for existing code. 'go fix' is simpler in Go
because all code has a default formatting through 'go fmt' so you can just
read the AST, change it, render it, and run 'go fmt' on it. The fixes are
also rather crude and syntactical. This was no Cocinelle.

[-- Attachment #2: Type: text/html, Size: 3048 bytes --]