ay 2, 2016 7:55 PM
To: Richard A. O'Keefe
Cc: Dan Sumption ; PPIG Discuss
Subject: Re: [ppig-discuss] Rhetorical structure of code: Anyone interested in
collaborating?
Richard is writing extensively, and making lucid arguments. His willingness to
discuss big programming problems in terms of pr
Possibly of interest
https://groups.google.com/d/msg/eve-talk/di-a-d0NJpE/fz40MrzhCAAJ
http://leoeditor.com/
--
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
On 2/05/16 4:17 PM, Mark Levison wrote:
Richard - thank you signalling contempt for anyone us who help their
clients simplify their code.
I will take the hint and sign off this list.
Dear Mark. I did not express contempt for ANYONE AT ALL.
Still less did I express contempt, disdain, dista
I would separate Richard's query into two aspects:
(1) how do we reason about and enforce semantic structure, e.g. that files
are closed once (and only once) upon opening, that handshakes are completed
in the correct order, etc..
(2) how do we align semantic structure with syntactic/visual/physic
> No doubt it could be construed as either-or rather than both-and. Having
> relevant media to support professional development is necessary. However, it
> seems rather too easy to end up with a cultural reduction toward the
> technological means rather than the ends (and thus we end up mantras
Hi Raoul,
No doubt it could be construed as either-or rather than both-and. Having
relevant media to support professional development is necessary. However,
it seems rather too easy to end up with a cultural reduction toward the
technological means rather than the ends (and thus we end up mantras
Personally, I would place value on the development of these
organisational / design skills rather than certain means to achieve them.
Note that these originate as professional / ethical concerns rather than of
any given business or organisation. I would be wary of the valuation of
visualisation too
Richard is writing extensively, and making lucid arguments. His willingness
to discuss big programming problems in terms of programming minutiae is
also commendable.
Here are some of my own observations and thoughts with respect to certain
themes I discern in this thread.
i) Files can be producti
Richard - thank you signalling contempt for anyone us who help their
clients simplify their code.
I will take the hint and sign off this list.
Cheers
Mark
On Sun, May 1, 2016 at 10:12 PM, Richard A. O'Keefe
wrote:
> It's clear that Dan Sumption is not interested in collaborating
> with me on f
It's clear that Dan Sumption is not interested in collaborating
with me on finding structure in files, because he thinks files
should never be large enough to *have* internal structure, so
this is my last reply to him in this thread. I wondered about
just ignoring the message, but maybe someone h
>
> 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.
>>
> Really? I've heard that said about *function* size, but not abou
On 28/04/16 7:15 PM, Dan Sumption wrote:
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
On 29/04/16 11:12 AM, Mark Levison wrote:
I'm still a practitioner, to the extent a consultant can be.
Visualations need to be derived from the code and not the annotations
since I've never met a programmer who voluntary updated their JavaDoc
or other annotation.
Why are we even talking
I'm still a practitioner, to the extent a consultant can be.
Visualations need to be derived from the code and not the annotations since
I've never met a programmer who voluntary updated their JavaDoc or other
annotation.
I've seen literate code on rare occasions, mostly from teams doing BDD/TDD.
> Richard,
>
>> I've been thinking for some time of writing a paper with the
>> title "Why can't I see the structure?" based on the idea that
>> modules in every programming language I know look like blobs.
>
> The most obvious answer is lack of practice:
> http://shape-of-code.coding-guidelines.co
Richard,
I've been thinking for some time of writing a paper with the
title "Why can't I see the structure?" based on the idea that
modules in every programming language I know look like blobs.
The most obvious answer is lack of practice:
http://shape-of-code.coding-guidelines.com/2016/03/24/h
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 li
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
On 28/04/16 5:09 PM, Flavius Aspra wrote:
Do you have any real-life example where complex stuff do not look like
blobs?
Literate programs. I'm thinking of the book about LCC, where I never
felt lost
at all.
I'd start with this.
Unfortunately, while literate programs help a lot, they
Then I suggest to look at
http://mlton.org/MLBasisSyntaxAndSemantics
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.
Or, some literate programming you strive for, but Real P
On 28/04/16 5:04 PM, Gergely Buday wrote:
I am not sure if it matters for you but how about Standard ML modules?
Suffice it to say that I've been well aware of ML for a long time and have
the latest release of SML/NJ installed on my desktop and laptop machines
for a reason, think that SML's s
Do you have any real-life example where complex stuff do not look like
blobs?
I'd start with this.
On 28 Apr 2016 5:52 a.m., "Richard A. O'Keefe" wrote:
> I've been thinking for some time of writing a paper with the
> title "Why can't I see the structure?" based on the idea that
> modules in eve
I am not sure if it matters for you but how about Standard ML modules?
- Gergely
On Thursday, 28 April 2016, Richard A. O'Keefe wrote:
> I've been thinking for some time of writing a paper with the
> title "Why can't I see the structure?" based on the idea that
> modules in every programming l
Hear, hear!
(I don't know what the solution is.)
--
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 grou
I've been thinking for some time of writing a paper with the
title "Why can't I see the structure?" based on the idea that
modules in every programming language I know look like blobs.
I'm aware of visual notations like UML, BON, SDL, and what
was it, Visual Erlang? But for me, those are just spa
25 matches
Mail list logo
