[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?

[Vlad Dumitrescu]

On Thu, May 5, 2016 at 1:19 AM, Richard A. O'Keefe <ok@REDACTED>
wrote:

>
> On 4/05/16 6:49 PM, Vlad Dumitrescu wrote:
>
>>
>> I don't disagree with you, it's just that for projects larger than toys,
>> I don't know how to browse the history for something that i don't know what
>> it looks like and that might or might not be there. Taking erlide as an
>> example, there are 6000 files in 7000 commits in the main branch, going
>> back 13-14 years and if i would have saved all experiments I'd probably
>> have a tree of at least 5 times that much. I am certain that I wouldn't be
>> able to find anything faster than I would write it again from scratch.
>>
>
> With 6000 files of totally unfamiliar code, there's no way I could find
> anything without a map and ground approach radar.  (find . -type -f -print
> |
> wc  actually counts 2774 files; it did report 6186 before I got rid of all
> the '._*' junk files you get on a Mac.)  OK, so 1344 Java files, 38 Erlang
> files, 2 Ruby files, 1 XSLT file, and 50-odd Xtend files (which I can't
> read
> yet), even hamcrest (oh don't get me started on hamcrest)...
>

Yeah, I think I forgot to filter out the binary files. Anyway, the point
was that at that size, having a multitude of alternative histories, many of
which might not be relevant at all any more, it gets exponentially harder
to be able to find anything in there.


> With the ._* junk removed, I measure 33.6 MB.  This one Eclipse plugin
> is bigger than the whole Quintus Prolog system, including manuals.
>
> Not only that, it's more than half the size of Pharo, which is a complete
> Smalltalk system including the refactoring browser.  There seems to be
> something about Java that forces systems to grow exceeding large.


Yes, and most of the important stuff (the Erlang implementation of the
kernel functionality) is located in another repository. I also had to
include some third party libraries as sources, in order to not depend on
external stuff whose availability was unreliable.


> We would need an index of the important experiments, with a reason why
>> they didn't were chosen for implementation and maybe a brief description of
>> the design, and a reference to the commits. This requires a lot of
>> discipline to maintain (especially when a team is working on the project,
>> with each person doing its own experiments).
>>
>
> Such a thing would, however, be extraordinarily useful for someone in my
> position, with NO idea of where to look for ANYTHING, and a dead link to
> documentation.  The README.md file contains this line:
>
>     Documentation may be found at
>     [the project site](http://erlide.org/erlide.html).
>
> That site isn't supposed to expire until next year, but right now it's not
> accessible. So yeah, I'd find lots of history very helpful. And lots of

advice for the traveller.
>

Thanks for pointing that out, I fixed the link. I will try to keep such a
high-level history from now on, I'm sure there will be a lot to learn for
myself too.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160505/f6a3bd05/attachment.htm>