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

Mon Jun 26 12:28:09 CEST 2017

On Sun, Jun 25, 2017 at 11:14 PM, Tristan Sloughter <t@REDACTED> wrote:
> The main issue here looks to be that the dep is tied to the master
> branch of a git repo. So the dependency is defined as one that will
> continually change over time.

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.

>
> The version of ranch used when the code was written probably didn't list
> `ssl` as a dependency, now that it does `application:start(ranch)` will
> fail. So the quick fix is to add `application:start(asn1),
> application:start(public_key), application:start(ssl),` before the start
> of ranch. Or just `application:ensure_all_started(ranch)`.
>
> Moral of the story: lock your dependencies (even better if on a package
> and not just a git reference) and use a release or
> `application:ensure_all_started` for running a project :)

Trouble is you don't know what your dependencies are - in (say)
smalltalk you could at least state that the SHA checksum of your image
was XYZ
and the behaviour might be reproducible.

Given that my machine has 500GB of state 2 ^ (500 * 10^9 * 8) - is an
incredibly large number (exercise: compare to #atoms in Universe)

Did my program work when I tested it? and if it did work did it work
because my machine was in some weird state? Will it work on another
machine?

The answer is "who knows" - a decent guess is that if my program works
on my machine it should work on a similar machine.

Horror story:

Once I and Anders Danne bought "identical" machines (at work) - we
wanted the same software on both machines.

We did the following:

1) I installed on my machine, when the SW worked
2) He installed on his machine

After about 20 minutes an install that worked on my machine failed on
his machine.

Why? my attempts to install failed occasionally - he only repeated the steps
that worked so our machines were in a different states

OR

The chipsets / BIOS (whatever) of the two machines were different

We'll never know.

When people say "my program does not work" the obvious question is
"in what state was your machine" - but the latter question has no answer, so
instead we say "have you tried doing X" then we vary X until until the
program works or we give up trying. And if it does work we do not know
if the
last thing we did caused it to work, or all or of all the things that
we did before (which did not work) were also needed in order to make
it work.

The study of programs goes by the quaint name of  "computer science"
- "computer alchemy" might be a better name since we don't really know
why our magic spells sometimes work and sometimes don't.

Cheers

/Joe

>
> --
>   Tristan Sloughter
>   "I am not a crackpot" - Abe Simpson
>   t@REDACTED
>
> On Sun, Jun 25, 2017, at 02:00 PM, Joe Armstrong wrote:
>> Unfortunately cowboy (which I used) and the websockets standard have
>> changed since I wrote the book. I also used make and not rebar.
>>
>> You've now run into what is one of the biggest problems in the
>> computer world - code that used to work no longer works despite the
>> fact the code itself has not been changed.
>>
>> One way around this is to use zero dependencies - in fact several
>> programs I wrote 30 years ago in Erlang still work fine with no
>> changes because there are no external dependencies. (as an aside: this
>> is why I like code with zero external dependencies - it takes a lot
>> longer to write - but you don't have to support it into the future
>> when they things you depend upon change in a manner that is
>> incompatible manner)
>>
>> In this example the underlying websockets protocol changed -
>> websockets its is a crazy mess - websockets should have provided raw
>> socket transport instead they chose to scramble the data in a weird
>> manner to avoid problems with badly written proxies.
>>
>> The idea of "write once run anywhere" is a great goal - but we can't
>> even do this - "write once run forever with no changes to your code"
>> would be even better and things like NixOS are a step in the right
>> direction.
>>
>> Welcome to the world of broken software.
>>
>> In my opinion this (making sure software evolution does not break
>> existing functioning software)  is one of the biggest remaining
>> software problems - my guess is that this problem is getting worse
>> (due to the explosion in the numbers of programming languages,
>> libraries and frameworks and build systems) and will be even worse in
>> the IoT world.
>>
>> Lots for you guys to work on :-)
>>
>> Cheers
>>
>> /Joe
>>
>>
>> On Sun, Jun 25, 2017 at 10:02 PM, 7stud <7stud@REDACTED> wrote:
>> > I'm having trouble running the demos for the ezwebframe.  I installed the old rebar (v. rebar3), but I'm getting the error:
>> >
>> >     {badmatch,{error,{not_started,ssl}}
>> >
>> > I'm on Mac OSX 10.10.5.  Here is my output:
>> >
>> > ===========
>> > ../ezwebframe-master$ gmake
>> > ...
>> > ....
>> > Erlang/OTP 19 [erts-8.2] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
>> >
>> > a simple_demo of websockets....
>> > Load the page http://localhost:1456/ in your browser
>> > Starting:{ok,"/Users/7stud/erlang_programs/ezwebframe/ezwebframe-master/demos"}
>> > Eshell V8.2  (abort with ^G)
>> > 1> {"init terminating in do_boot",{{badmatch,{error,{not_started,ssl}}},[{ezwebframe,start_link,2,[{file,"src/ezwebframe.erl"},{line,22}]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
>> > init terminating in do_boot ()
>> >
>> > Crash dump is being written to: erl_crash.dump...done
>> > make[1]: *** [all] Error 1
>> > gmake: *** [Makefile:4: all] Error 2
>> > ===========
>> >
>> > Thanks for any help is solving this problem!
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions