[erlang-questions] where did my code come from?
Joe Armstrong
erlang@REDACTED
Tue Sep 13 11:08:45 CEST 2011
On Tue, Sep 13, 2011 at 10:37 AM, Michael Truog <mjtruog@REDACTED> wrote:
> On 09/13/2011 01:06 AM, Joe Armstrong wrote:
>> 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.
>
> Yes, I agree. There would need to be a tool that does dependency analysis that would aid in modifying the dependency versions across all the modules, since that would need to happen easily to facilitate testing (which should help back-propagation take place). This seems to require keeping a local copy of all versions of the remote source code, at least to avoid problems when dependencies disappear or change their location. It might be easier to manage the dependencies if they were held in a file separate from the source code.
Possible - I have taken to adding a file called meta.info to most of
my directories - it contains an erlang term saying what's in the
directory. Then I can rename and move the directory - and the meta file
moves as well - then I scan my disk and put all the meta data into a database
This is part of a long-term clean-up project - I have about 50K
directories to go
:-)
/Joe
However, I think separating the dependencies from the source code
would compromise the software reuse benefits (i.e., you copy the
module and you have all the dependencies). To really know what the
dependency is though, you would need to specify the version in the
same place.
>
>> /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