<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 26, 2017 at 6:28 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
</span>But there is a deeper issue - the websockets standard *changed* so<br>
even if I pointed to a version of cowboy/ranch (whatever) that I<br>
tested against in 2013 it still would not work - to get it to work<br>
you'd have to get a browser from 2013 and pray that the OS hasn't<br>
changed that much.<br>
<br>
This is only 4 years ago - now consider the problems people will have<br>
in 200 years time trying to make programs written hundreds of years<br>
ago work.<br>
- or in 10,000 years time.<br>
<span class="gmail-"><br>
</span></blockquote></div><br></div><div class="gmail_extra">Ah, but Joe! It is not just the software that changed; the world also changed.<br><br>I'd like to refer to <em>Programs, Life Cycles, and Laws of Software Evolution</em>, 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:<br><br>----<br><h4>I. Continuing change</h4><p>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.</p><h4>II. Increasing Complexity</h4><p>As
 an evolving program is continually changed, its complexity, reflecting 
deteriorating structure, increases unless work is done to maintain or 
reduce it.</p><h4>III. The Fundamental Law of Program Evolution</h4><p>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. <br></p><h4>IV. Conservation of Organizational Stability</h4><p></p><p>The world the program evolves in and/or its complexity tend to limit how useful the program can remain through change<br></p><h4>V. Conservation of Familiarity</h4><blockquote><p></p></blockquote><p>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.</p><p>----</p><p>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.<br></p><p>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 <i>pretty much nobody else</i> 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!<br></p><p>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 <i>wanted </i>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, <i>unless it is able to remain useful when running in isolation already. </i><br></p><p>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.<br></p><p>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.<br></p></div></div>