[racket] Poll: Does anybody besides Doug use 'plot'?

Hi,

sorry for adding more noice. My message concerns the "meta" side of the
discussion, i.e. whether to preserve functional compatibility or the
original name. This is a central issue in Liitin (
http://liitin.finndesign.fi ), so I've given a lot of thought about it,
but this topic/noise served as an excellent opportunity to study this
aspect even deeper. Thanks everyone contributing!

The thinking process was extremely fruitful, so I thought I'd better
document it somehow, and maybe sharing it could benefit others as well,
regardless whether agreeing or disagreeing with it. These thoughts are
mainly common-sense reasoning and usability related, and Liitin centered
in places.
( http://en.wikipedia.org/wiki/Law_of_the_instrument :)
I'm likely to be wrong in many places so please correct me. Thoughts so far:


I've often found it very useful method to exaggerate things when trying to
extract the essence out of too vague or too close situations. In this
subject, rather than
thinking about a few people needing to update near-history programs, think
about a million people needing to update a hundred years old programs. The
referred code,
again has been changed 1000 times during the hundred years.

Which approach feels more comfortable and enduring; keeping the old name,
but changing it whenever some other approach feels better, or stick to
strict
compatibility and occasionally create renamed variants, if it would break
compatibility otherwise (e.g. change the order of arguments, add remove
arguments,
change the format of arguments...)?

Both are inconveniences, but in a different ways. However, adding new
variants and finding them seems to stay as an inconvenience, whereas
braking the compatibility
soon escallate problems until unmanageable.

Side note:
Any improvements (such as little tweaks, optimisation, bug fixes, total
rewrite) no matter how small or grand, fall into category 'update' as long
as there are no
changes in the interface that would break the compatibility.

Of course, these are just recommendations which anybody could either
follow or not. The good thing with Liitin, however, is that even in cases
that the recommendations
are not followed (the interface changes under a single name), you can
easily deal with it by simply ignoring dynamic changes ('latest') and use
timestamped versions
instead.
E.g. (function-x arg1 arg2 arg3) > (function-x arg3 arg1 arg5)
>> (function-x:timestamp-a arg1 arg2 arg3) (function-x:timestamp-b arg3
arg1 arg5).

Eventhough still inconvenience, it is way smaller than needing to change
your or somebody else's code(s). And on the next abstration level it
doesn't really matter;
it's already hidden.

Or, you could use your own namespace to give new names to objects, yet
referring to other's code, either timestamped or allowing dynamic, future
updates from the
original author.

Keeping the name as well as the interface as intuitive and practical as
possible is very important, so I'd rather see evolutionary variants as
needed, rather than
strictly stick to the originals (say, car & cdr). Eventually, best
practices will settle down. None ot the code versions (within the same
name) or variants (similar
functions under different names) are ever lost in Liitin, but there's a
need for especially good search mechanisms.

Experimentation should by no means be limited by these measures, on the
contrary. Codes and names should evolve, but being ably to safely harness
both wider and
time-wise deeper range of others' work, will allow much greater level of
abstraction to experiment with.

To apply this to case 'Plot':
If the compatibility cannot be preserved, pick a new name for the new
variant (intuitive for a new-comer rather than resembling the old one),
and be especially careful not to break compatibility with the existing
code base (retrospectively). And of course, inform about the existence of
the new variant.

Now it is easy to see the pointers in the discussions, but in the
beginning it was quite blurry. To me, at least.


br, jukka


 |  J U K K A   T U O M I N E N
 |  m a n a g i n g   d i r e c t o r  M. A.
 |
 |  Finndesign  Kauppiaankatu 13, FI-00160 Helsinki, Finland
 | mobile +358 50 5666290  jukka.tuominen at finndesign.fi
 | www.finndesign.fi