What's your favorite year end method?

[Donald Allen]

On Dec 25, 2007 10:33 AM, Derek Atkins <warlord at mit.edu> wrote:
> Quoting Donald Allen <donaldcallen at gmail.com>:
>
> > All true. But I'm assuming that there will be some screening process,
> > perhaps embodied in people like Derek and Josh, that will insure that
> > only the work of people who know what they are doing will make it into
> > the SVN repository (perhaps this wasn't always true, having just read
> > Derek's comment that some of the reports are O(n^3) in the number of
> > transactions, but I'm guessing that this will not be an issue, given
> > the quality of the current lead developers). So if we assume good
> > programmers, then the issue boils down to not impeding them with
> > second-rate tools.
>
> I'm afraid to admit that the O(n^3) algorithms were introduced
> under our watch.  They were added in the 2.0 release.  I'd have
> to go look at who submitted the code.  But even clean code can have
> a stupid algorithm.
>
> In fact I would argue that clean code tends to LEND itself to doing
> things stupidly.  It just makes more sense to perform the types of
> comparisons that lead you to O(n^3) algorithms than using esoteric
> data structures like hash tables and such to store itinerant data
> in the middle of your processing.

I don't agree. Good programmers know that "clean" code is necessary
but not sufficient, and they know that good algorithms are the big
hammer of performance, not micro-second-shaving tricks. And the right
programming environment will make it easier to avoid the kind of
algorithmic issues that you are describing in some of the gnucash
reports. You use the word "esoteric" to describe hash tables. Yes,
perhaps, if you have to roll your own. But a good environment will
give you nice, easy-to-use hash tables (e.g., MIT Scheme, Python; even
Tcl has them), hiding the "esoteric" stuff. I used Python hash tables
(dictionaries) at the core of my report utility, and I'm quite sure
the program would have been uselessly slow (as some of the gnucash
reports are) had I used some other structure, e.g., lists, that
involved significant searching. And it was trivial to do.

>
> So, while you can expect Josh and I to make sure the code is relatively
> easy to read, you can't expect us to scrutinize every report to make
> sure the algorithms used are optimal.  We tend to only look for correctnes
> ;)   And the current reports (generally) are correct, if not optimal.
>
> Also, if the language choice is python you lose me as another set of
> eyes.

Well, that's certainly an issue that would have to be considered in
making the language choice. Care to elaborate on your apparent dislike
of Python?

I'm not married to Python, by the way. But I've now used it a fair
amount and am impressed both by the language, the environment, the
performance, and the documentation. I think it's a significant step
forward from languages like perl and tcl in a number of ways. But it's
not the only good choice.

/Don


>
>
> -derek
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
>
>