Subj : Re: Writable source equals Reusable source
To   : comp.programming
From : websnarf
Date : Fri Aug 19 2005 12:02 pm

James Dow Allen wrote:
> In earlier threads I've tried to espouse a key idea:
>
>   Modifying Flexible Source-Code is the Key to Reusability
>
> Perhaps I should rephrase this as
>
>   Source = Writable Source = Reusable Source = Force
> [...] snip

Ok, but it sounds like you are generalizing a lot from a single
example.

1) Are you sure that your solution of simply mutating some old source
code is the best possible example for what you were doing?  Or is it
just the best you happen to have on hand?

2) Is solving some programming contest comparable to solving real world
programming problems?  (Where code might need to be documented,
maintained, or fit some other criteria.)

3) Can you generalize this strategy to other programming structures?
If so how scalable is the idea of having "demo source" lying around
that you just customize as required to all programming problems?

4) Does your approach make unwarranted assumptions about programmer
skill level?  If someone wanted to use your custom hash table sources
to make their own, for example, what kind of learning curve would they
have to go through?

5) Let me propose a very simple problem for you.  I want to implement a
cookie database for my webbrowser.  The cookies will come in the form
of the following 4-tuple: (file, host, key, value).  So what I want is
a sequence of nested hash tables that indexed first by the filename,
then the host, then the key, which will finally yield the value to me.
Does your hash table design, which as I recall was based on static
instances, scale to solve a problem like this?  Note that this is not 3
hash tables -- its 3 *LEVELS* of hash tables.  (I think CBFalconer's
can do this, so long as you have fewer than about 8 million of any
given index.)

> When I was first exposed to Unix wizards I was impressed
> with some of their magical powers.  Soon I realized they
> were making a copy of standard BSD sources and modifying
> them, thereby producing custom software quickly.

This, BTW, is how the thoroughly obsolete System V malloc libraries
temporarily made it into the Linux kernel before being summarily
expunged (and one of the discredited examples of "copying" in the SCO
versus IBM case.)

> The key point is that the object files were not the reusable
> components; instead modifying the source files for reuse
> was the key for rapid development.

This is a very old style C-centric way of thinking.  C++'s STL, for
example, does not primarily present static .obj files as part of its
base interface.  Very dynamic data structure description is quite
feasible because of the fundamentally source-level template system that
the STL is.  Even in C, you can always use macros as a direct
substitute for this exact same thing.
 
-- 
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.