[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?
Lloyd R. Prentice
Thu May 5 16:51:32 CEST 2016
Pertinent to the discussion:
PROGRAMMING BY POKING: WHY MIT STOPPED TEACHING SICP
Sent from my iPad
> On May 5, 2016, at 6:07 AM, Vlad Dumitrescu <> wrote:
>> On Thu, May 5, 2016 at 1:19 AM, Richard A. O'Keefe <> 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,
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions