Robby, I'm still not certain we all have a shared understanding of some
of the concerns and where we all stand, so please let me try to get at
that some of that:
As for adopting-new-syntax vs backwards-compatibility, does it help if I were to tell you
that anything new will always be "opt in", in the sense that existing programs
will continue to work completely unchanged with no special annotations or anything else
like that required?
I suspect, to many industry software engineers, this phrasing sounds
like "deprecated", which is something we understand. It's not something
anyone likes to hear, unless we've already moved away from it, and we
think that deprecating that is a positive sign.
There are piles of lecture notes (in the form of slide presentations written in
Racket) from the late 90s (so not in any continuous integration system
anywhere, as far as I know) that still run fine in today's Racket for example.
I think this argument doesn't address the concerns of software engineers
who know the history of Racket (and of countless possible parallels
elsewhere).
For one example, from Racket specifically, how the change to pair
mutability was done meant that some of those modules in "compatibility"
dialects no longer interoperate well with modern modules. That's a big one.
For a lesser example, which nevertheless was a problem in real-world
practice: one of the changes to C extensions meant being locked to the
old, non-default GC (missing out on enhancements, and concern it was
more likely to break in the future, since most people had been pushed
along to using the new thing, until that scary C extension code could be
disturbed again).
Another example was people who were using PLaneT's
multiple-installed-package versions and SemVer-like updating, when that
was deprecated and the functionality lost.
From an engineering perspective, over the last couple decades, Racket
has done a good job, overall. And an outstanding job, as academic-led
projects go. But, at this point, I think software engineers should want
a clear understanding of top-level requirements for Racket, so they have
an idea of what to expect.
Some degree of trust factors into assessments of whether adopting or
staying with such-and-such tech makes sense, and I'd think that arguing
"some old CS101 lecture slides probably still work" is going to increase
concern rather than reduce it. :)
Some people (here, and in other venues) are skittish or turned off by
various recent commotion. At this point I could allay some of their
concerns by mentioning multiple mitigation/transition options to them,
but I'd prefer to keep all the value of the community we've built around
Racket.
Moving forward... Software engineers have learned to expect modern
platform pitchers to often be disingenuous, or at least
over-enthusiastic. If core states, utterly unambiguously, and speaking
as one, the top-level requirements that will guide Racket, and
everything else clearly follows from those requirements, then I think
that will increase confidence. (Even if some of the articulated
priorities are not ideal for our needs, we know what to plan with, with
some confidence.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/35d7b52a-abd7-e593-bcec-7f25ecde8f8d%40neilvandyke.org.
