March 8th, 2017
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
An incredible assertion that would be dismissed if it was coming from someone less talented than Joe Armstrong. It is interesting to think that RAM is a key value store, and so anything that updates RAM is altering the values of a key value store.
He starts by saying that he often ends up with miscellaneous code:
When I’m programming I often get to the point were I say there shoulda function foo/2 in lists.erl but their isn’t. There should be but there isn’t – foo/2 is a small self contained thing. Why should it bein lists.erl because it “feels right”.
Strings are lists, so why do we have two modules lists.erl and string.erl how should I decide in which module my new string/list processing function should go.
To avoid all mental anguish when I need a small function that should be somewhere else and isn’t I stick it in a module elib1_misc.erl.
This happens to every programmer, and this is one of the arguments against Object Oriented Programming. In this case, Armstrong feels it raises questions about whether a functional language like Erlang needs to have modules.
Does the idea of a module come from the idea that functions have to be
stored somewhere, so we store them in a file, and we slurp the
file (as a unit) into the system, so the file becomes a module?
If all the files were store by themselves in a database would this
I am thinking more and more that if would be nice to have *all* functions in
a key_value database with unique names.
When programs are small we can live with “just the code” in “a few
modules” the ratio of code to meta data is high.
When programs are large we need a lot of meta-data to understand them.
I would like to see all functions with all meta-data in a data base.
I’d like to say:
lookup(foo,2,Attribute) when Attribute =
code|source|documentation|type signatures|revision history|authors|…
The more I think about it the more I think program development should
viewed as changing the state of a Key-Value database.