[erlang-questions] where did my code come from?
Joe Armstrong
erlang@REDACTED
Tue Sep 13 10:06:54 CEST 2011
On Tue, Sep 13, 2011 at 9:57 AM, Michael Truog <mjtruog@REDACTED> wrote:
> This sounds like a very interesting approach to aid collaboration across different software projects and avoiding fragmentation of effort (i.e., avoiding siloed development efforts, without any sharing). I think this is important because much software seems to be perpetually rewritten, just due to difficulties locating the proper dependencies.
Yes^100
I also imagine some quite complex software in the background
trying to nail down the precise dependencies.
When software gets cloned copied and modified the changes are often not
back-propagated to the original source - so the idea of a definitive
version gets
lost. We need to think of how to automate the back-propagation of
changes to code. Forward propagation is easy - back propagation is far more
difficult - some code vanishes from github and reappears two years later
in a soureforce project with significant improvements. You google for
some code and find ten different versions and haven't a clue which is best.
At least writing down the exact dependencies would allow this to be tracked
and analyzed.
/joe
With explicit dependencies at a per-module level, it would be easier
to manage and track source code dependencies. My hope is that, you
can explicitly reference a particular version of each dependency so
your source code remains stable while the other dependencies change
independently (so I would want a version referenced somehow within the
location specification). Within Erlang modules, this could be handled
with the vsn, but this type of version might need to be separate, just
since that may complicate code upgrades. I am tempted to think this
would benefit from integration with version control, but that would
not provide a
> flexible system unless there was a large integration effort to handle all major version control systems.
>
> Either way, I think this is a good way of managing external source code dependencies which should encourage the reuse of Erlang source code and accelerate the iterations to make source code stable. This type of development would benefit both proprietary development and open source development and may become a more natural way to develop source code over a Wide Area Network (WAN, so, both any intranet and the Internet).
>
> On 09/13/2011 12:19 AM, Joe Armstrong wrote:
>> I had an idea on my way to work ...
>>
>> When you write code, you have *implicit* knowledge of where the
>> external code comes from.
>>
>> When I write the following:
>>
>> -module(foo).
>> ...
>> start() ->
>> X = lists:reverse(...),
>> Y = elib1_misc:zap(...)
>> Z = misultin:request(...)
>> ...
>>
>> I "know" that lists is part of my local OTP install, elib1_misc is my
>> own library installed
>> in ~/code/elib2_1/ebin and misultin is an imported project stored in
>> ~/imports/misultin
>> I also know that my paths etc are setup so this code will work when I
>> run the program.
>>
>> The problem is the *nobody else* knows this.
>>
>> I could tell the system like this:
>>
>> -module(foo).
>>
>> -location(lists,
>> "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").
>> -location(elib1_misc,
>> "https://github.com/joearms/elib1/blob/master/lib/src/elib1_misc.erl").
>> -location(misultin,
>> "https://github.com/ostinelli/misultin/blob/master/src/misultin.erl").
>>
>> ...
>>
>>
>> The location annotation give a *definitive source" for the module I
>> am using in the module
>>
>> What could you do with this information?
>>
>> Answer - a lot - for starters
>>
>> - automatically check for "latest versions" of libraries
>> download them when they change
>> - provide "who uses my code" feedback to the authors of the code
>> - publish (globally) lists of "definitive" versions of code
>> - recursive track and code dependencies (What do I mean)
>> when my system discovers that I use misultin - it
>> downloads misultin.erl
>> misultin.erl will have location dependencies which I can
>> follow, thus the libraries
>> that misultin calls can be fetched.
>> - automate code loading
>>
>> Most often this kind of "additional" information is kept "outside
>> the program" by strictly
>> annotating the program with the location dependencies we bring this
>> information *into* the program
>> in a form where it cannot be detached from the source code.
>>
>> Comments?
>>
>> /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
>
More information about the erlang-questions
mailing list