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

[Curt Sampson <cjs@example.com>]

On 2012-10-18 23:16 +0200 (Thu), Attila Kinali wrote:

> ...[I] was thinking about how to make programming
> as a craft easier for Joe Average. And if possible at the same
> time give Joe a better understanding of what he is actually doing.
> ...
> Would someone lend me a hand and give me some pointers to stuff
> i could read about programming as a mental work and how people
> learn it? And how does the structure of programming languages
> simplify the task of programming and learning of programming?
> 
> Also, i wouldn't mind to read about your thoughts on this topic.

The heart of programming is, when it comes down to it, simply
manipulation of symbols according to strict rules of a logic that
you (or someone else) has made up. In other words, mathematics. This
discipline is in turn used (or, more frequently, misused, or not
infrequently hardly used at all) when practicing software engineering,
which is what most people in "the industry" do.

If you want to look at how people learn about programming and deal with
it as mental work when they're being or have been taught well, chasing
down the various uses of Racket[1], such as Bootstrap[2] and Matthias
Felleisen's TeachScheme![3] may be of help. Racket (previously DrScheme)
is a langauge that seems particularly associated with serious research
into the pedagogy of computing science.

[1]: http://racket-lang.org/
[2]: http://www.bootstrapworld.org/
[3]: https://en.wikipedia.org/wiki/TeachScheme!

If you're interested in what really gets practiced, The Daily WTF[4]
is as good a source as any of examples of how many (probably most)
developers don't really have a mental process, or possibly a brain at
all.

[4]: http://thedailywtf.com/

That's not particularly helpful for improving one's skills, of course.
For that sort of thing, whether you're working seriously on making
software or just playing around, I can recommend nothing more highly
than learning functional programming. Functional programming researchers
and language designers are, in general, far more concerned than anybody
else with the logical coherence and power of their languages, and that
comes out in making the languages both easier to learn and use and
more powerful than more popular languages, even if you exclude the
messes such as Perl and Ruby that were thrown together on an ad-hoc
basis. (It should be noted that many people damaged by extensive
exposure to ill-designed languages will vehemently dispute the "easier
to learn" portion of this statement, but these are people so far gone
that they don't even realise that the statement "f(); g();" includes a
flow-of-control structure, much less have any ability to recognise what
it is.)

As to specific references, I can only throw out a few random ones.

One of the classic texts in the area is _Structure and Interpretation of
Computer Programs_[5] (usually referred to as just "SICP"). However, one
thing you miss out on with that is the interesting and extremely helpful
stuff a good type system (such as that of ML and related langauges) can
give you. For that, Haskell may be the best route to go, using something
such as Graham Hutton's _Programming in Haskell_[6] or Paul Hudak's
_The Haskell School of Expression_[7] (though I would certainly do the
former before the latter). That said, I've just been looking into Scala
and it appears to be to be about as decent as Haskell in this area, and
has what looks like a good on-line course taught by Martin Odersky:
Functional Programming Principles in Scala.[9]

[5]: https://secure.wikimedia.org/wikipedia/en/wiki/Structure_and_Interpretation_of_Computer_Programs
[6]: http://www.cs.nott.ac.uk/~gmh/book.html
[7]: http://www.cs.yale.edu/homes/hudak/SOE/
[8]: https://class.coursera.org/progfun-2012-001/class/index
[9]: https://class.coursera.org/progfun-2012-001/

Regarding a few things others have posted:

On 2012-10-18 19:01 -0400 (Thu), jep200404@example.com wrote:

>    http://www.nand2tetris.org/

This is the first time I've come across this, but it looks absolutely
brilliant. It addresses at least part of a massive problem that I and my
other not-so-young friends have noted and discussed amongst ourselves
from time to time.

That said, I don't think it directly addresses your problem, since it's
not so much about how one thinks about programming per se, but simply
understanding what's really going on under the hood. That's somewhat
esoteric knowledge you will probably need from time to time if you're a
professional programmer, but is only used occasionally, as opposed to
something like knowledge of algorithms, and many people can get by just
fine without knowing it at all.

I've ordered a copy of the book, though, and if anybody happens to be
interested in putting together a group to basically do the course, I'd
be in for that. I've been thinking for some time I wanted to start
spending some time at Tokyo Hackerspace building up my own CPU from
TTL 7400 NAND gates, but I reckon I might be able to live without the
frustration of debugging timing issues and whatnot in actual physical
components.

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.

> 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," which upon being presented to you will lead you to
say, "all that because you didn't know about a function called 'fold'?"
(Well, actually the proper generalizations of map, fold, etc.[10]
Perhaps that's really where the language fell down.)

It's as if someone came up to you and started babbling on about this new
"composition pattern," where you could take several different variables
and treat them as a group, always passing them around together, and be
able to have a set of functions that operated on this group. Even a C
programmer would immediately think, "Err, you mean a struct?"

[10]: http://www.haskell.org/haskellwiki/Foldable_and_Traversable

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

It is easier to write an incorrect program than understand a correct one.
    --Alan Perlis, Epigrams on Programming (#7)