From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 64D76801D9 for ; Tue, 18 Jul 2017 15:28:28 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=jesper.louis.andersen@gmail.com; spf=Pass smtp.mailfrom=jesper.louis.andersen@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f53.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jesper.louis.andersen@gmail.com) identity=pra; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jesper.louis.andersen@gmail.com"; x-sender="jesper.louis.andersen@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jesper.louis.andersen@gmail.com designates 209.85.215.53 as permitted sender) identity=mailfrom; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jesper.louis.andersen@gmail.com"; x-sender="jesper.louis.andersen@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f53.google.com) identity=helo; client-ip=209.85.215.53; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jesper.louis.andersen@gmail.com"; x-sender="postmaster@mail-lf0-f53.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AtuWKghEYbXMuG1rtwISTrJ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ7zo8WwAkXT6L1XgUPTWs2DsrQf2rWQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDiwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85Kl3VhDnlC?= =?us-ascii?q?YHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWHBBU95eWCxPAIyy?= =?us-ascii?q?b4UBAekcM+hGs4bwvEEBoQekCAS2GO/j1j1Fi3nr1qM6yeQhFgTG0RQkEd0Qq3?= =?us-ascii?q?TUtMv6NL0PWu6zy6nI0DTDb+hL0jrh7ojHbw4uoeuXXb1ud8ra1E4iFwHbgVWL?= =?us-ascii?q?sYzqISmV2v4Js2ic8upgVPmvh3Q9pAF3vzeg2N0sipLXiYIT0V3E+iB5z5w0Jd?= =?us-ascii?q?28UkJ0fdmkEJ5JuiycKoB4QdsiTnl2tComzrAKo522cSgQxJg52hLSa+aLfoiG?= =?us-ascii?q?7x/lSe2fOy13hGh/d7K6nxuy8Vavyun7VsSs1VZFtCtFkt3VunAJ2Rzf9tGLSv?= =?us-ascii?q?V980qvwzqP2AfT6uZLIUAwi6XXMYIuwrk1lpYLsETDGDH5mFnugaOIakkp/vKk?= =?us-ascii?q?5ufnb7n8uJOQKo95hhv+P6kggsC/BP43MgkKX2iV4+S807jj8FX7QLpUlf02ir?= =?us-ascii?q?fWsIrAKcQfoa65Hg5V0p055xmlCTepzcoXnWMcLF1bfhKKlIfpO1TUL/D5Cfez?= =?us-ascii?q?mUijkDBux/zeJL3uHo3NLmTfkLfmZbty91RTyA83zdxG45JUC6oBIO7oV0/qtN?= =?us-ascii?q?3YCwc5PBauz+bmDtV9zIIeVniVDq+XKqOB+WOPs8UrKufERIIPuTDyY6wi4/fg?= =?us-ascii?q?pXY0gVEZcO+l0M1TIHuxG/AjJ0SCfVLthM0AGCEEpFkQVuvv3X+PSiZefT6WWL?= =?us-ascii?q?89/XkSDo6rF5zOQMj5grGaxCqhWJlRe2FdTFmKHXrybIiCc/gJYSOWZMRml2pX?= =?us-ascii?q?BvCaV4Y92ET250fBwL19I7+Ro3VAuA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAwCuC25ZhjXXVdFcHhgHDBgHg0cBg?= =?us-ascii?q?VKFKKNmhzqHPYIMgzsCg1FDFAEBAQEBAQEBAQEBEgEBAQgLCwgoL4IzJAGCQQM?= =?us-ascii?q?DIx0BGx4DDAYFBAc3AgIiAREBBQEcBgESihYBAxWhfj+MCoIEBQEcgwYFg2UKG?= =?us-ascii?q?ScNVoJwAQEBAQYBAQEBHAIGEoMWh0ZYNIRdgyCCYQEEnzSLFIkCggyJRYZelA8?= =?us-ascii?q?zgRU2gSsxISNeGoR5EAyBZ0A2hhuCPQEBAQ?= X-IPAS-Result: =?us-ascii?q?A0CFAwCuC25ZhjXXVdFcHhgHDBgHg0cBgVKFKKNmhzqHPYI?= =?us-ascii?q?MgzsCg1FDFAEBAQEBAQEBAQEBEgEBAQgLCwgoL4IzJAGCQQMDIx0BGx4DDAYFB?= =?us-ascii?q?Ac3AgIiAREBBQEcBgESihYBAxWhfj+MCoIEBQEcgwYFg2UKGScNVoJwAQEBAQY?= =?us-ascii?q?BAQEBHAIGEoMWh0ZYNIRdgyCCYQEEnzSLFIkCggyJRYZelA8zgRU2gSsxISNeG?= =?us-ascii?q?oR5EAyBZ0A2hhuCPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,378,1496095200"; d="scan'208,217";a="283881670" Received: from mail-lf0-f53.google.com ([209.85.215.53]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 18 Jul 2017 15:28:27 +0200 Received: by mail-lf0-f53.google.com with SMTP id z78so13813806lff.0 for ; Tue, 18 Jul 2017 06:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=a5qQmGpZpPHdotBd8IDZKiE+gRYQsBzb4jwLqo3B92U=; b=Niy14QNKQiy2d/GWwUVHnw44LUBxrdnOOqlAFkhU+WkdHh0WxKA0D8EeM3ai0MqWii BcMU0J3wqtq4VEChBy6HGbOHegzq3WEyaP5uXoEitDE7UbYdeLyJHFapNHyYPFFrfQnz JT6CTww3nSgueQ2gwH7VqnHxwMQv1IjpyTv81KaCWnUOpUDosl/9+s97CqY/kkitq2Yh HhAJrw2gPLU1K4uCwq9ZGUa1qmiZXttlCgja5Y2Ma+U6LnwZbCllxOnEiv0nKFQu67SX xYtLTn3ieLNQ9N2KS5QLHMwn6sM+Ma9MTUMsVDfmvsAi9KHGL6VsSPJhWJnYYFoX3PRF EAnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=a5qQmGpZpPHdotBd8IDZKiE+gRYQsBzb4jwLqo3B92U=; b=fePo+V8ShC7hSh9TXdpjmccR+RrUhK2FdQGfQlalzJgDkuEZlZ9hkTnXUt+TtGRCJB sCVl9uMVMtgylTx0+z22Leq4NbtRykv4VIbXkQNJKJp6JcMkT7+QAn3BF9YsnlZagsd8 4WCcoX20wvRTdK9sFvqKh9NTSsgXPkCN6B41GiCixhaGE6JL0MDmMRjARP/FWqMHSnGM SYOuWQhE5hMPZOayIpSL1BR54HdZvEO6aMNKsLwAdv3zXlYxAv1hygv1X/hodunMW3oS VaKM1Tl6iy+MiDrIMgByvYOPkF0RjozkquIlEb60KmlHNteFYP4MyA4JBR7o8a9ASqmi /+Ag== X-Gm-Message-State: AIVw1124ZAc4Sa3SjLEuoTjjZmVAT97y2oBkybrj4HqcEDJJ0F9Z9oAH 3+pWYmUj5XnQ1DsGfauL+6pgt9dmQ1b2 X-Received: by 10.46.7.9 with SMTP id 9mr754874ljh.108.1500384506716; Tue, 18 Jul 2017 06:28:26 -0700 (PDT) MIME-Version: 1.0 References: <20170718090258.GB2151@aepfle.de> In-Reply-To: <20170718090258.GB2151@aepfle.de> From: Jesper Louis Andersen Date: Tue, 18 Jul 2017 13:28:15 +0000 Message-ID: To: Olaf Hering , caml-list@inria.fr Content-Type: multipart/alternative; boundary="f403045ec30a8ca79d0554977d48" Subject: Re: [Caml-list] removal of C compiler variables in in 4.06 --f403045ec30a8ca79d0554977d48 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 11:04 AM Olaf Hering 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. --f403045ec30a8ca79d0554977d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 18= , 2017 at 11:04 AM Olaf Hering <olaf@a= epfle.de> wrote:
=C2=A0
But if their usage is legitime,
why the needless breakage?

I like to th= ink of software as sometimes hitting a local optima. That is, to move forwa= rd you have to stop the hill-climbing algorithm and =C2=A0start going in th= e "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 an= d moving forward. I'd expect some breakage between software releases. S= ome of these are potential incompatibilities, and in the unlucky case, an i= ncompatibility 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 l= ot of support for desirable features, revamped the systems core, and then a= dded those features which were truly needed later on. We also learn in hind= sight, so many changes eventually have to be reverted. The larger your inte= rface, the more brittle it tends to be.

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

[0] 4 years ago, the Erlang se= rialization "external term format" was changed to allow for certa= in symbols to be UTF-8 encoded. Releases would be able to handle the decodi= ng, but would not produce such terms. The recent 20.0-rc1 release enabled t= he feature since it was believed that backwards compatibility was in place.= Yet, it broke systems because they rely on things like the lexicographic o= rdering of the marshalled serialization, among other things. The final rele= ase 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 backwar= ds compatibility because upgrades to clusters tend to happen one machine at= a time.

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

--f403045ec30a8ca79d0554977d48--