axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Literate Programming


From: daly
Subject: Re: [Axiom-developer] Literate Programming
Date: Sun, 25 Dec 2011 02:36:09 -0500

On Sat, 2011-12-24 at 12:56 -0600, Jay Edwards wrote:
> Like this?  http://brighterplanet.github.com/flight/impact_model.html

My first reaction, after the first reading was "almost ok".

The task is reasonably mathematical so it seems useful to 
show the equations. Unfortunately, at the end, I have to ask
myself the "Hawaii question".... If someone sent me off to
hawaii (so I couldn't talk to the author), would I know enough
to maintain the program?

Well, maybe. 

I really liked that they embedded a link to the impacts web page.
That placed the problem in context.

And I especially liked
   "A multiplier to account for the extra climate impact of 
    greenhouse gas emissions high in the atmosphere.

    Use 2.0 after Kollmuss and Crimmins (2009)."

I was unhappy with:

=begin
  FIXME TODO date should already be coerced
=end

Really? Coerced to what, by what, for what reason, in what format?
I was just hired and asked to solve this problem.

=begin
  FIXME TODO deal with cities in multiple countries that share a name
  Tried pushing country, which works on a flight from Mexico City to 
  Barcelona, Spain because it does not include flights to Barcelona, 
  Venezuela BUT it doesn't work if we're trying to go from Montreal
  end up with flights to London, United Kingdom. Also pushing country
  breaks addition of cohorts - all 'AND' statements get changed to 'OR' 
  so you end up with all flights to that country e.g. WHERE 
  origin_airport_iata_code = 'JFK' OR origin_country_iso_3166_code =
'US'
=end

So why isn't this part of the dialog? Why does it break? Is the
database improperly structured? Do we need a schema change? Or
do we need program logic to handle this case?

The use of FIXME is horribly jarring. Get rid of it.

Think of a calculus textbook where the source code is the equations.
Now imagine that in the middle of an equation you see the above
comment. Something like:

   area = \sum_i^j x*3 =begin FIXME might be x^4 =end * y

The editor-in-chief would never let the above equation get into
the text. The FIXME should be discussed as part of the prose
rather than "in the equations". 

I don't think it would pass the code review phase with these
"FIXME" things hanging around. FIXME is the programmer's internal
dialog. Discuss the issue in the text as though you were talking
to someone other than yourself. Odds are good this is where a
design mistake (e.g. in the database schema) or a program bug lurks.

The meta-issue is distinguishing "communication" from "documentation".
Literate programming is about communication, not documentation.

Write with your audience in mind and assume that the audience is
NOT your shower committee (a shower committee is the group of people
you talk to in the shower who are not really there).

This example really skates along the border. Overall I think it is
wildly better than most examples I've seen. I'd much rather maintain
this program with the text than without it. I'd certainly place it
on the high side of the curve. 

Tim Daly









reply via email to

[Prev in Thread] Current Thread [Next in Thread]