Re: Algorithms-HOWTO draft 0, take 2

[Andrew P Moise <moise+@andrew.cmu.edu>]

Excerpts from mail: 1-Nov-100 Re: Algorithms-HOWTO draft .. by Harvey J.
Stein@bfr.co.i 
> I refrained from commenting earlier because I only had bad things to
> say.  

  Praise the lord.  The list thus far has been so unfailingly polite to
me (even in the face of my blatant incompetence with Docbook) that I was
afraid that no one would offer up criticism.

> It seemed pointless to me to have an Algorithms HowTo given that
> there are lots of excellent textbooks (Aho, Hopcroft & Ullman being my
> favorite, Knuth being a comprehensive reference on what he covers) and
> I couldn't imagine anyone writing a HowTo which is even competitive
> with the standard texts.

  There are also superior books about Linux security, Oracle, PHP...
from my introduction:
  "You'll notice that most of the examples are seriously incomplete --
you may well find yourself unable to figure out how to initialize or
destroy a data structure properly, or wondering how to implement some
obvious operation that wasn't needed for the imaginary task at hand. ...
My intention is for you to be able to read the HOWTO proper and wind up
knowing what techniques are out there and what they're called, so that
you know (at least) what to do a Google search for if you find yourself
unable to do something."

> It also lies out of the realm of documentation and as such is somewhat
> more controversial.  For example, different people have different
> beliefs as to which hash table technique is better to use in a given
> situation, as well as whether hash tables or balanced trees are
> preferable.  There are also lots of sticky little points regarding the
> implementation of these things which can have a major impact on how
> well they actually perform.

  While I've done as well as I could to present as many flavors of the
algorithms as possible and mark opinions as such, I agree that an
Algorithms-HOWTO is uncomfortably far from the mark of a HOWTO, in that
it is necessarily much more of a textbook than a cookbook.  I will leave
it to the LDP elders to decide if this is a fatal flaw.

> The only advantage I can think of in having a is having a free version
> of such a textbook, but there already are free ones available, as in
> http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/ds_ToC.html,
> http://hissa.nist.gov/dads/, http://www.epaperpress.com/s_man.html,
> and http://www.mich.com/~serenget/source/, to point out a few I found
> through google & yahoo.

  More is better, right?  Heh.  Point taken.  Obviously the stuff I've
written seems to me to be aesthetically better and more practically
useful than those, but hey.

> You can see how negative this is, which is why I avoided bringing it
> up.  I felt that if you want to go write such a thing, you should go
> ahead and do it - you don't need my approval so I shouldn't bring up
> my own objections.

  Hell, no.  The sooner you tell me you think it sucks, the sooner I can
fix it (or scrap it) based on what I agree with out of what you say...
my ego doesn't hinge on this thing getting published, much less met with
unanimous approval.

> I'm only bringing up these objections now because, looking at your
> document reminded me of something I think really *would* be important
> & useful - namely a Linux programming guide to these algorithms.  This
> wouldn't be a document about the algorithms & data structures
> themselves, but a document explaining *where* the libraries are which
> implement each of said algorithms, *how* to use them, and details
> about their implementations.
>  
> For example, sorting & searching should point out & detail the unix
> sort command, qsort in libc, sort in guile, Tcl, ....  The section on
> hash tables could point to the implementations available in Tcl, scm,
> etc.
>  
> This is something that could potentially help lots of people make much
> better use of what currently exists, rather than just telling everyone
> enough to go and do it themselves.

  Sounds like an excellent idea... I'm a C junkie myself, so I didn't
think to mention anything beyond qsort()/lsearch() (yeah, it's not in
yet, but I really did plan to exhort people never to write their own
sorting & searching in "Sorting and Searching/Don't do it yourself,"
honest...) and Java's horrible hash table implementation, but something
is clearly needed besides "many languages will do many of these things
for you."  I don't think turning each algorithm's section into a big
switch statement depending on which language you're using is a good
idea, though, and I don't think good language support for these
algorithms is universal enough that it can be assumed that no one needs
to know the implementation.
  So I'll count this as a vote that I should go the "copious links"
route for pointing to full documentation rather than trying to write an
STL and include it in an appendix, and I thank you for pointing out that
I need links to language-specific documentation in the case where the
language does it for you.  If any further revision (or reading) of this
beast bothers you, please let me know. 


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org