At 12:40 PM 1/20/01 -0800, Jeff wrote:


>   Howdy, Senator Racko:
>
> > #1) I consider that most of you overlooked a biggie.
>
>   Likewise:
>
>   Some of us (me) had no idea this was intended as a
>   Programming Challenge (way too busy to read the whole
>   thread), and was only paying attention when they noticed a
>   bug in some posted code.

I am grateful for the help.

Yes, I see that early on in the thread the conversion happened to time! 
from the unspecified obj/time form.   Looks to me like the olde gossip game 
(where noise introduced early on gets amplified) happens here too.



>   Of course, it's best to always post code that you think is
>   well polished...

I see now where my own "polishing" may have broken my example!!
(smile)



>   A suggestion: Threads that are Programming Challenges should
>   put "[PROGRAMMING CHALLENGE]", or something like that, in
>   the subject line so I can avoid accidentally posting in
>   those threads. (-:

EEK! if you stop posting then many of us will not really learn from you.

Every thread I post with "How do I" subject is designed to be saved for 
training others.
in fact it seems we are on the anniversary of this thread-prefix ...
>I am activating this thread and others like it
>with the same prfix to solve some real problems.
>Likely someone (hint) will capture these for the knowledge base.
>
>What will follow on this thread set are
>pieces of functionality I am taking advantage of
>in some other language or some other real-world app.
>
>I code in lots of things.
>You should expect to see stuff on this thread
>in C, squeak, expect, python plus a few more
>as I am the custodian of at least 2 other rare languages.  ...1/18/00


Though I have to filter a lot of email that comes generally to the list, I 
keep filters on this prefix wide open and read them all.  Sometimes the 
responses I get back are not appropriate.
For several I have injected, there hasn't been much discussion 
stimulated.  For this I blame myself but rather than pester, I have decided 
to actively-listen.

I would rather deal with some crankyness or upset than ask questions on a 
prefix that
nearly guarantees that the people who can make a difference about it will 
ignore it.

They aren't all programming-challenges either since I have plenty of 
material to cover
that deals with issues and conventions for which I believe there is not a 
pleasant programmable solution.  Eye openers for people who design the 
language and its environment.

For this ampm example I was able to start with a program that worked (maybe 
a bit quirky).
I could tell when writing it that I could do better but I was already 
applying the best
series of principles at my disposal.  So, with an interest of becoming a 
better coder myself,
I introduced it as a "make my code succinct" thread.   Meanwhile something 
even deeper bothered me -- That there are many ways to incorrectly 
construct such a simple function.
I was counting on the fact that in other areas, RT has put in their own 
code in subsequent
releases to head off common errors before they bite someone.

In addition I felt I could get the real advocates (those with time) to 
think about the deeper problem as a lead-in to an eye opener about 
refinements to basic types and how they evolve.
If I start small with a real-world example I get even better attention.

Among the things I was trying to stir up was discussion about how
folks (inside or outside RT) decide what is a (possibly contributed)
mezzanine function, what goes into a datatype-refinement and what gets
left out altogether.   That exact decision strategy is one I think
others (outside of RT) would like to know so we can more appropriately 
pitch our suggestions.

Of course I could infer one -- and after writing an elaborate paper about 
it discover that
the answer is simply:  "oh, Carl decides that! :)"
which is only funny up to the point
you start thinking about buying more Carl-insurance.



Jeff, you have demonstrated great flexibility in adapting and understanding the
snips posted which is to your credit.  Yours was also the easiest to decouple
into separate refinements.

I am sorry you are so pressed for time to not be able to
go back to the first thread in a series.


  

-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to