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

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

Attila Kinali writes:
 > On Fri, 19 Oct 2012 12:26:23 +0900
 > "Stephen J. Turnbull" <stephen@example.com> wrote:

 > > Next, type "python -m this" at any command prompt.
 > 
 > I know this. But this rather looks like an a posteriori, experience
 > based guidance on how to write better code. It doesn't give any
 > understanding why it is better or how I even can recognize better code.
 > The topic of making writing better code simpler is not tackled at all.

Well, my theory of how this stuff works at the lowest level is that
writing good code is basically a matter of writing code to do the same
thing many times in your head, until you find something you like.
Great programmers just weed out the junk faster and with less
conscious thought than the rest of us.  (You may have seen this same
theme come up in my discussions of why "git rebase" can't "destroy
history" -- it's all already there in the set of integers!  VCS just
selects the interesting ones so far. :)  So, having principles to
recognize good code when you see it does help you to write good code.

Now, there's a higher level to the Zen.  For example, "explicit is
better than implicit" has two practical consequences.  The first is
that you don't need to remember what the code does, because you can
read it in the source.  The second is that you write more modular code
both because it's easier to refactor out unnecessary coupling when
it's explicit in the source, and because the greater verbosity of
explicit code provides incentive to put less in each line of code and
in each function.

One of most important factors that makes Python easy (IMHO, YMMV,
FWIW, etc etc) is TOOWTDI: "there's one [and preferably only one]
obvious way to do it."  You can argue whether Python really makes it
easier to write good code, and whether it achieves the goals set forth
in the Zen, of course.  But what you can observe is that Pythonistas
put a lot of effort into discussing what's "Pythonic" code and passing
around "the Pythonic idiom".  To the extent that this succeeds in
approximating TOOWTDI, what it does is create a meta-vocabulary.  That
is really important.  Now, unlike English which has little inflection,
so the vocabulary (individual words) is crucial, this meta-vocabulary
is more like Latin, a highly-inflected language where each word takes
on a variety of meanings depending on "parameters".  Someone who
masters this vocabulary can build sentences with the same number of
"words," but with more powerful semantics.

The aphorisms about complexity are an attempt to attack Brooks'
"essential difficulty" (the complexity of the underlying problems) by
giving guidance on how to build large programs out of small ones.  To
the extent that a language succeeds in providing TOOWTDI solutions to
common lowlevel tasks, users (== programmers) are relieved of dealing
with the small problems of writing routines, and can concentrate on
the big problems.

 > I've read Beautiful Code, Beautiful Architecture, Masterminds of Programming
 > and a few others are stil waiting to be read. But for most of them the
 > above applies as well: They explain after the fact what they have done
 > and turned out to be a good idea. Not why it is a good idea or how

Really?  Maybe you need to read more "actively."  Many of the authors
aren't very good at explaining their philosophies, or why they're
good, I agree.  But that's why the collection is about programs
(mostly), rather than about languages, I think.  You're supposed to
look at the programs and figure it out for yourself.

 > i can design a system that makes me produce good ideas.

Heh.  If there was a system that could make people produce good ideas,
it probably could produce them itself, and you'd be out of a job!

 > I've heard also a lot about SmallTalk, but never had the chance
 > to have a look at it. Interestingly, it always seems to pop up
 > in discussions about language design.

Well, SmallTalk really takes object-orientation to its logical
extreme.  Everything is an object, and to a first approximation there
are no functions, only methods bound to specific objects
(implementation), and messages to invoke them (interface).

 > Can you give me a few pointers here? My google skills didnt turn up
 > anything related.. or at least nothing i think is related.

Well, I thought googling for '"design pattern" software" (note the
inside quote marks) came up with a lot of relevant looking links,
including several Amazon book links.  I was also reading a tutorial on
Twisted at http://krondo.com/?page_id=1327, which (sort of in passing)
mentions the Reactor Pattern.

As Curt says, a lot of design pattern talk is just BS.  But I think
there's more to it than just fuzzy descriptions of standard higher-
order functions in Haskell. :-)

 > Also one of the books on my list to buy.. I should finally buy and read it.
 > ^^;

Indeed you should.  I think you should fnd some answers to your
questions there.  Of course, you may decide those answers are
wrong. :-)

 > -- 
 > There is no secret ingredient
 >          -- Po, Kung Fu Panda

Oh, the irony!  There's the answer.  Why do you continue to search for
a secret ingredient?! :-)

Steve