Re: [tlug] Making programming easier... or something like that

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2012-10-19 12:26 +0900 (Fri), Stephen J. Turnbull wrote:
 > 
 > > Start with The Mythical Man-Month, of course....
 > 
 > That seems to me not really related to programming but to the other
 > parts of software engineering, particularly project management. The
 > same mostly goes for the agile stuff you mention.

True in one sense.  However, these folks have strong opinions about
the cognitive aspects of programming per se.  For example, Brooks'
elegant distinction between the essential and accidental difficulties
in programming is crucial for understanding language design.  Of
course Brooks will immediate go on to deduce that not only will NASA
never hire two programmers in a garage to write software for the space
shuttle, but it will never happen that two programmers in a garage
will accidentally produce shuttle-ready software.  (At least not until
IBM releases IC.ASN![1])  All of which fits your statement exactly.
But that doesn't mean his asides on cognition aren't relevant to
Attila's concerns.

For example, in "The Category Design Pattern"[2] Gabriel goes on at
length about composition.  Haskell provides very compact notation for
expressing this, but compositional programming is at the center of
most of the years-long debates in Python (eg, the on-going thread
mentioned earlier about expressing asynchronous programs).[3]  Glyph
of Twisted Matrix has this[4] to say about it all. :-)  Ahem, back to
Brooks and cognition, well, the point being that figuring out what is
being composed, and expressing that elegantly with an appropriate type
and morphisms is an important way to deal with the _essential_
difficulty of programming.  OTOH, the notation Haskell uses for
monadic programming looks like Perl one-liner noise on Symmetroid, but
that's a merely _accidental_ difficulty that you should not allow to
distract you from the power of Haskell.

 > > There's a recent literature on "design patterns" in programming
 > > (sprouted from design patterns for architecture AIUI) which I admit I
 > > haven't read.
 > 
 > You're not really missing all that much. The design patterns literature
 > seems to have grown out of an undefinable ache for better abstraction in
 > languages with poor support for high levels of it. This led to somewhat
 > incoherent and hand-wavy little articles about things such as "the
 > visitor pattern,"

I was thinking more about stuff like MVC.[5]  I suppose *you* could
express that in terms of foldr, but *I* ain't even gonna try. ;-)

 > Even a C programmer would immediately think, "Err, you mean a
 > struct?"

Or any other product type in _Set_. ;-)


Footnotes: 
[1]  The IBM Classes for Automatic Space Navigation.

[2]  http://www.haskellforall.com/2012/08/the-category-design-pattern.html

[3]  As the Seabees say, "The merely difficult we do at once.  The
impossible takes a little longer."

[4]  https://glyph.im/blob/EC0C1BF9-F79E-4F3D-A876-9273933E2E78.jpeg

[5]  http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller