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

I wasn't going to press the send button, but now that Neil brought it
up... (read: Neil's fault!)

...


> First, I apologize. I play "catch up" on the weekends with this list, and
> sometimes find myself responding to threads that have long ago gone far
> afield...
>
> Second, sarcasm is used far to little in this field.
>
> Instead of "plot/compat", call it "plot/old". When "plot3000" comes along,
> then the geezers like me still using the old old plot should have to ask
> for
> "plot/old/really-dude?", and at some point,
> "plot/old/really-dude?/you-have-been-warned".
> _________________________________________________
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/users


>>
>> On Oct 2, 2011, at 12:07 AM, Neil Toronto wrote:
>>
>>
>>
>>> A tad more seriously, if we had a death date for the old one, I could
>>> put it in the library name. You'd have to put
>>>
>>>     (require plot/supported-until-2013-01-01)
>>>
>> I really like this one a lot. -- Matthias
>>

This works nicely up-hill as well (atleast in folder naming). Say...

new, new2...new13, latest, latest2... and then find these after decades.

Or, if you're really clever, you could keep renaming the module like...

module/no-changes-here.update-all-your-code-to-reflect-this-none-change
module/still-no-changes

Another note-worthy detail: I think the functions (libraries) should be
left as if the development was never ended. This leaves the door open to
actually have somebody publishing an update later on; either by the same
or a different author, no matter how weird it may feel at the time. Those
using the function simply benefit from that, without needing to make yet
another change in the 'require'.

plot/back-in-business

But as Grant pointed out, these are (presumed) best practices for
repository type of functions/libraries. In Liitin, however, functions are
always this type and they are treated individually rather than as
libraries.

br, jukka


>
>
> So long as nobody thinks that this is necessarily a best practice
> for breaking API in the future, IMHO.
>
> In the case of "plot", the API breaks at the time users have to change
> their "require" form to include this expiration date (and then the API
> may break a *second* time, on or after that date).
>
> I'd see this as not a best practice, but a one-time deal: for the
> special case of the "plot" library that few people use, and which
> library we really want to get rid of because of the C code, combined
> with a desire to steal the old API's "(require plot)" for the new API.
>
> In the future, we all will have had the benefit of the "plot"
> experience, which teaches us that API breakage will cause a huge amount
> of discussion, which costs the developers time/energy/morale before we
> even get to what API breakage costs users.  So we will consider breaking
> API only when the win is so big that we are willing to endure
> discussion.  I love that discussion can be used not only for
> collaborative design and problem-solving, but also as itself a painful
> stick to discourage misbehavior.
>
> By all means, just move forward on getting the new "plot" goodness to
> the users, however the API migration is done.  Learning experience has
> been achieved.
>
> --
> http://www.neilvandyke.org/
> _________________________________________________
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/users
>