[erlang-questions] Stuff that breaks when you move it

[Joe Armstrong]

On Mon, Aug 3, 2009 at 8:20 PM, Dave Pawson<dave.pawson@REDACTED> wrote:
> 2009/8/3 Joe Armstrong <erlang@REDACTED>:
>
>> I consider them broken in the sense that they will not display the same
>> thing if moved - I'm comparing them with PDF files which do  not break
>> when moved. Now you can embed js, css and even jpgs into the html
>> so that they do work if moved but nobody does this.
>
> Hopefully.
> And for good reason Joe.
> The 'cascade' provides for users to override CSS for such
> as accessibility reasons.
>
> Embedded CSS (and js for that matter) should be history by now.

M'lord I object, the witness is not a historian, the history of HTML
and why is was a bad idea
has not yet been written.

Judge: Do you have any other comments? Try to keep them short, we will recess in
twenty minutes.

I will try, M'lord, if the court will permit ...

Judge: get on with it ...

Ladies and Gentelmen of the Jury,

Image I have a a single web page with some js. I *never* intent to
reuse the js in
a second page. This is a one-off application.

You are saying that I should store this in *two* pages - not one. This
will have the
following consequences:

    - One day I will move one of the files but not the other (I'll
lose the js, for example)
    - the two files will live lives of their own and I'll get into
version nightmares
    - fetching the file has not got transaction semantics. I might get
the HTML and then
      get a link failure before fetching the js. I'd like to "either
fetch both and it works"
       or "fetch nothing" - the thing I use (firefox) doesn't have
transaction semantics.

<< suppose the HTML always assumes the js will be downloaded -
       the HTML prints some static content, then calls the JS - but
the JS is not loaded
       the net consequence of this is that some text is displayed and
this  has disasterous
       consequnces, somebody dies or something. This is because the JS
was not executed.

       Learned council can check if this has actually happened >>

    To avoid these things I have to set up a revision control system
to make sure the parts
cannot be separated - I have to change web browsers for transaction semantics.
pending this we should ask for a court injunction to stop all browsers.

     My solution is to put the js in the file. With one file all the
above problems disappear.

      It's a fundamental law of physics - if you have two things in
two different places
it's impossible to agree if they are in a consistent state - it's
mathematically impossible
(see http://en.wikipedia.org/wiki/Two_Generals'_Problem).

    There are *pragmatic* benefits of including css, js files - but
this is a premature optimization
and the net effect of include files can be achieved by a different
(and sound) mechanism

    I rest my case M' lord.

Cheers

/Joe



> regards
>
>
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>