[erlang-questions] Programming Erlang: Chap 18, Websockets

[Fred Hebert]

On Mon, Jun 26, 2017 at 6:28 AM, Joe Armstrong <erlang@REDACTED> wrote:

>
> But there is a deeper issue - the websockets standard *changed* so
> even if I pointed to a version of cowboy/ranch (whatever) that I
> tested against in 2013 it still would not work - to get it to work
> you'd have to get a browser from 2013 and pray that the OS hasn't
> changed that much.
>
> This is only 4 years ago - now consider the problems people will have
> in 200 years time trying to make programs written hundreds of years
> ago work.
> - or in 10,000 years time.
>
>
Ah, but Joe! It is not just the software that changed; the world also
changed.

I'd like to refer to *Programs, Life Cycles, and Laws of Software Evolution*,
a paper by MM. Lehman from 1980. For the vast majority of software (i.e.
not programs implementing a formal specification nor those for a limited
game, like chess), five laws of program evolution are proposed:

----
I. Continuing change

A program that is used and that as an implementation of its specification
reflects some other reality, undergoes continual change or becomes
progressively less useful. The change or decay process continues until it
is judged more cost effective to replace the system with a recreated
version.
II. Increasing Complexity

As an evolving program is continually changed, its complexity, reflecting
deteriorating structure, increases unless work is done to maintain or
reduce it.
III. The Fundamental Law of Program Evolution

The work output of a project is independent of the amount of resources
employed -- the ability to be productive when maintaining a program is a
function of the program’s environment. How you begin your project, how you
build the code, refraction to change by programmers who feel changes are
making the platform unstable and whatnot will lead the project to have a
stable, predictable rate of change.
IV. Conservation of Organizational Stability

The world the program evolves in and/or its complexity tend to limit how
useful the program can remain through change
V. Conservation of Familiarity

Similar to the fourth law, but based on the understanding of developers. If
the system becomes too complex, developers slow down. Managing complexity
and actively maintaining software is essential to help with this.

----

The idea that you can freeze software in time is a difficult one. Google,
for example, vendors not only their own code and its dependencies, but also
the compilers that were used to produce them. Of course, the compilers as
they are may require specific operating systems, configurations,
environments, or hardware to run. Maybe they keep enough of those around
just in case.

Rebar3, even if we wanted to keep it as backwards compatible as we could,
can no longer be useful on Erlang/OTP R15, because the SSL libraries coming
with that version are no longer are considered secure enough to even talk
to the package index it uses. It's interesting that even if the program
compiles and behaves right, it cannot inter-operate safely with the real
world anymore. The problem of course being that even if the standards for
the crypto it uses are still supported, the package index evolves with the
rest of the world, and the attackers for such a product in the rest of the
world keep improving. The ecosystem in which the system runs makes it
impractical to maintain old versions because *pretty much nobody else* runs
older software along with you. They'd have to go through the effort of
making and maintaining their own index to avoid upgrading software for
which updates are available, while increasing their risks when it comes to
security. That's a losing proposition!

We cannot reasonably decouple the program from the environment that
contains it for a very long time: the environment is what likely defined
what the best solution to a problem was in the first place; it likely even
defined the problem itself. And if the program is good enough, it will
impact the environment itself. MS Paint was real cool until everyone
imagined making fancier drawings and then someone *wanted *Photoshop. As
the environment changes, so the programs become irrelevant or impossible to
run. You can delay the inevitable, but you can't isolate software forever
and keep it useful, *unless it is able to remain useful when running in
isolation already. *

If not maintained, it will at best remain a curiosity for future
generations. Some people are too young to have ever seen a floppy disk in
person, much less used one. They'll be more likely to think an actual 3.5"
floppy is a 3D-printed rendition of the 'save icon' than a storage device.

So the true question is maybe: if I want to write a book that will be
useful in 4 years, 200 years, or 10,000 years time, what should the book
contain? The exercises and solutions will have to adapt themselves to
changing contexts and environments. What do you assume is going to be
around in 200 years? What will need to adapt? If that's not useful for the
book you have in mind, then maybe a shorter time expectation is warranted.
Maybe a more flexible medium is warranted. Who knows, it depends on what
your objectives are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170626/7d8d392c/attachment.htm>