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

[Joe Armstrong]

On Mon, Aug 3, 2009 at 8:28 PM, Christian<chsu79@REDACTED> wrote:
> On Mon, Aug 3, 2009 at 15:04, Joe Armstrong<erlang@REDACTED> wrote:
>> There's two kinds of stuff:
>>
>>    A) Stuff which doesn't break when you move it
>>    B) Stuff which breaks when you move it
>
> I'm not sure if you were just talking about general design but this example:
>
>> Experiment:
>>
>>    # cd /usr/local/lib
>>    # mv erlang globble
>>    # globble/bin/erl
>>    exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found
>
> This is surely just about the paths inside the script 'erl' itself.
> The ROOTDIR variable in there looks suspicious indeed.
>
> I actually quite like that erl stores the installation directory in
> itself. I prefer it over java's JAVA_HOME environment variable. If I
> want to use a specific java version i have installed I need to set
> JAVA_HOME correctly, AND start the right java binary. In erlang I
> point out what I want and that is what I get.
>
> Since argv[0] / $0 is unreliable for finding the installation dir, I
> think Erlang does the pragmatic best way for being insensitive to what
> its installation dir is.
>
> Also, about HTML, what some (you?) perceive as a disadvantage is
> someone else's advantage. If every HTML document would include the
> pictures, scripts and css, then you would have to load all that even
> if those parts were the same.

The great ones said  "verily verily I say unto you, premature
optimization is the root of all evil"

And this, my friend, is a premature optimization. Not only is it a
premature optimization
it is a widely spread notion that this is a good thing to do - but it
is practice that
causes incredibly large amounts of time to be wasted because HTML can
break when you relocate it.

If you *want* to optimize then it's easy - imagine storing two zip
files zip1 and zip2 on
 machine A. A remote machine B first downloads zip1, then it wants
zip2, a simple diff algorithm/protocol can be used to recreate zip2 on
B by asking A to send the diffs between A and B.

This should be totally invisible to the user.

If file A includes B then it is a law of nature that if you move A
from machine to machine you will
one day loose B. If the versions of A and B matter then one day you
will include the wrong
version of B in A unless you have a version control system that
guarantees correctness.

If you put all your HTML etc. in a revision control system (or
database) and have strong
guarantees on consistency then fine - but most systems I see are not
build this way - and
they break when you move them.

The (fundamental) difference between PDF and HTML is that I can send a
PDF file to anybody,
or put it in a storage system and retrieve it years later and still
see the entire document.

Sending an HTML file to a remote location (or storing it) in such a
way that the content can be reproduced years later is highly error
prone since it relies on an out-of-band mechanism to
ensure that *all* the sub-components are also stores in a consistent
way. Worse, this
out-of-band mechanism is not standardized. There are no such problems
with PDF everything
is self contained.

Software should not break when you move a file to a new directory - if
it does this is a
symptom of a deep-seated design problem. Go look at some HTML ages stored in
the Internet Archive (www.archive.org) already many pages lack
associated images.

Imagine you're a historian in 1000 years time - at least with PDF
files you have a chance
to recover the data because you've got all the bits.

If an application consists of a number of parts (and an HTML file with
links to images and javascript can be considered as such) then it
possible to break the application by moving
some of the parts. In a well designed system this should be impossible.

It should be impossible to move something without moving all the
component parts.

Another way to fix this would be to fix "mv" - ie  "mv" *sghould* move
zip files etc withouit complaining - but if asked to move an HTML file
it would also miove any relative components
in a consistent way so as not to break the application.

So something is deeply wrong - either "mv" or html (in this example) -
I guess this is
one reason why "putting everything into a database" is not such a bad
idea - since
your can move the database as a whole, and have strong consistency
checks on the data
when you change it.

/joe