[erlang-questions] Stuff that breaks when you move it
Tue Aug 4 09:23:23 CEST 2009
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:
>> # 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 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
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
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
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
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
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.
More information about the erlang-questions