This is a subject that interests me greatly, and I'm keen to hear people's
views on it.

My perspective is that of a working software developer (albeit with a
background in psychology), not an academic. I have no experience of ML, and
have worked only a little with functional languages.

I was a little taken aback by this line in the original post:


> Why can't I see the structure in a 3000-line module, or even
> a 1000-line module?


To me, a 1000-line module is a God Class. A 3000-line module is a complete
disaster.

Accepted best practice is that a file too big to view on your screen is too
long. Optimum file size is probably under 30 lines.

Of course, "best practice" is not the same thing as reality. I sometimes
work with files 10,000 lines long. In those circumstances, you spend entire
days figuring out the implications of one small change. Your mind ends up
paralysed.

I don't have any exact answers as to _why_ this should be. I strongly
suspect it relates to limitations of working memory.

Chunking strategies, allowing an entire module to be thought of as 7+/-2
concepts, will certainly help. Though only coupled with IDEs which allow
you to keep those concepts on screen simultaneously (because: out-of-sight
out-of-mind).

Even then, I struggle to conceive of a case where a 1,000 line file could
be broken down into 7 clear, comprehensible concepts.

Best,
Dan Sumption


On 28 April 2016 at 07:26, Richard A. O'Keefe <o...@cs.otago.ac.nz> wrote:

>
>
> On 28/04/16 6:15 PM, Gergely Buday wrote:
>
>> Then I suggest to look at
>>
>> http://mlton.org/MLBasisSyntaxAndSemantics
>>
>
> Please.  Don't try to teach your grandfather to suck eggs.
> I've had mlton on my machines since the first release came out.
> What part of that web page do you think has ANY RELEVANCE
> WHATEVER to what I'm talking about?  Is it the "ann" entries?
> Those annotations are for the *compiler*, not for *people*.
> "Annotations allow a library author to control options that affect
> the elaboration of SML source files."
>
>> About relations: you look for some specification language, when you state
>> the governing rules of the methods to each other. That brings program
>> verification of some sort.
>>
> Yes, but if you know of such a specification language, please tell me where
> to find it.  While I think program verification in general is interesting,
> that's
> not what this project is about.  It's all about making it easier for people
> (me, of course, but I don't mind if others are helped (:-)) to understand.
> "Governing rules" aren't what it's about.  It's *relationships* like
> "<this> is a special case of <that> for <reason>", or
> "<that> breaks <something> up and <this> reconstitutes it".
>
>> Or, some literate programming you strive for, but Real Programmers are
>> reluctant to do that.
>>
>
> I've addressed that in another reply.  Literate programming is great, but
> what
> use is something people don't use?  And literate programming makes modules
> even *bigger* and *more* in need of structural annotation.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PPIG Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ppig-discuss+unsubscr...@googlegroups.com.
> To post to this group, send an email to ppig-discuss@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "PPIG 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ppig-discuss+unsubscr...@googlegroups.com.
To post to this group, send an email to ppig-discuss@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to