[erlang-questions] Rhetorical structure of code: Anyone interested in collaborating?
Thu May 5 17:39:11 CEST 2016
I think we worry too much about the *inputs* to a program and not the
To me something like Markdown is a terrible tool since it cannot
produce beautiful output.
Markdown is popular since the *input* is easy and the output is
tolerated by most people.
I find the output horrible - getting quotes right (ie using proper
"curly" quotes) is a mess (or impossible) - Even Gutenberg got this
that gets this right (please tell me if I'm wrong).
My Erlang book was authored in XML and transformed to PDF - and while
not perfect the typography is acceptable for the amount of effort
Once the book project is over the result is a single PDF file
containing the book - all the inputs can in principle be thrown away.
The directory structure and files used to create the book was a mess
by the time the boom was ready.
I keep all the files and so on in case they might be useful in the
future. They are meaningful to me but probably not understandable by
I am personally fascinated to learn how artists/muscians/authors
create their works - If I see a great painting, I think "I wonder how
they did this?" and I like reading descriptions of how they
worked. Why? I guess it's because I think "If I understood *how* they
had done XYZ" then I myself might be able to do XYZ.
I don't really understand how I write programs - I gather information,
do experiments, then "something happens" and I can write the program
To an outside, all they can see is (in the case of my book) - the
output (one PDF file) and 6365 files used to create the book (many
were generated - this is just the *total* number of files in the book
As I said I keep the inputs mainly because they might be useful for
As well as keeping files in "dustbin" directories (which are project
specific) I have taken to storing these *outside* the project
directory structure - but in a global directory. I have one directory
with a very-large number of sub-directories - I think of this as being
in "dictionary" order - ie it's like a dictionary.
When I start new projects I botanise among my previous projects
collecting stuff and editing into shape - I virtually never reuse code
(apart from some very stable libraries) but make small changes to
existing code - usually my libraries do almost, but not quite exactly
what I want so need small changes.
Logs of what I did, and seeing all the inputs and the output would not
help at all. Since the relationship between the inputs and outputs is
"what happened inside my head" and I haven't a clue how this works.
All I know is that if you study a problem, and think a lot, and do
loads of experiments then often you'll go "Eureka" and suddenly see
how to solve a particular problem.
The "Eureka moment" when it comes is highly pleasurably - which is why
I guess, I still enjoy programming.
Tools in all their glory provide us with information but it's a
mystery to me how the brain processes this information. I've been
wondering what goes on in my brain when I program for 47 years and
still don't know.
On Thu, May 5, 2016 at 12:07 PM, Vlad Dumitrescu <> wrote:
> On Thu, May 5, 2016 at 1:19 AM, 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.
>> 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
>> 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
More information about the erlang-questions