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

[Richard A. O'Keefe]

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.
Well, I did ask if anyone was interested in collaborating on some research.
"I don't know how" is what you say just before "Can I have some grant 
money to
investigate how".  (Joke.  I don't know anyone who'd give me that money.)

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)...

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.
>
> 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.