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

Thu May 5 17:39:11 CEST 2016

Another thought.

I think we worry too much about the *inputs* to a program and not the
*output*

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
right, but there is not a single JavaScript in-line browser editor
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
involved.

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

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
(or not).

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

As I said I keep the inputs mainly because they might be useful for
something else.

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.

Cheers

/Joe

On Thu, May 5, 2016 at 12:07 PM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
>
>
> 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
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>