[racket-dev] Removing Xexpr preference from Web Server

Going back to a point I'm sure others have made already... Perhaps you 
guys have a good sense of how many people would be affected by any 
incompatibilities in this case?

Most people use "open-output-file" and hash tables, so you wanted to 
migrate all those people gently somehow.  A relatively small percentage 
of people used mutable pairs, at least outside of textbooks, so a harsh 
migration path was more acceptable there.

I assume that the Web Server is somewhere between "open-output-file" and 
mutable pairs in popularity.  If the tradeoff costs of 
backward-compatibility work and moving the platform forward 
expeditiously are unclear, perhaps you could poll the stakeholders.

Neil Van Dyke wrote at 11/30/2010 01:11 PM:
> I don't have any important dependencies on the Web Server right now, 
> but just wanted to add that even small backwards-incompatibilities in 
> PLT/Racket have ruffled feathers of consulting clients of mine in the 
> past.
>
> When there are backward-incompats, it's *much* better that they be 
> detected at compile time.  Example: renaming the hash table procedures 
> was an annoyance when code wouldn't compile, but the changes to 
> "open-output-file" and friends to use keyword arguments resulted in 
> much more insidious runtime errors.
>
> (BTW, Not using Typed Racket yet.  Large code base that has been 
> evolving since PLT 1xx/2xx.)
>
> When thinking about how you want people to be alerted to incompats, 
> also remember that not everyone reads the release notes.  A few times 
> I've seen a programmer install the latest version of PLT to try, which 
> happens to constitute a jump of several versions, and s/he smoke-tests 
> their code with the new version *before* going and reading the release 
> notes for all the intermediate versions.  I think that having the 
> platform inform them of incompatibilities through compile-time error 
> messages or compile-time Java-like deprecation warnings gives more 
> confidence in the platform than errors that occur significantly after 
> time T0 in run-time.
>
-- 
http://www.neilvandyke.org/