Although I'm still skeptical that changing the surface syntax will be a
sufficiently big net gain, and ought to be the next, highest priority?
I'm running with that idea for the following.
It seems like there are at least two "flavors" or "strengths", of giving
Racket a non-sexpr syntax someday:
1. The new syntax will be a choice, fully co-equal with sexprs. Both are
"first class", "forever". Any great new Racket features work with
either.
2. The new syntax will become the preferred syntax, used in
documentation and advocacy. ("Change the culture" is the phrase I
thought Matthew used initially -- but I welcome him
clarifying/correcting/revising.) Sexprs and #lang racket will get a
status that's not as weak as "deprecated", but not really as strong
as co-equal with the new syntax.
Regardless of how it might turn out, years from now -- it seems to me
there are some pretty big gotchas with the latter choice in the
meantime. Especially for "advocacy" or "marketing" during the N years
until the new thing is ready.
TL;DR: How would we promote Racket in the meantime??
Example worry: Something similar to an "Osborne Effect".
- Effectively we'd be telling not-yet users, "You're right not to like
sexprs! Go away and come back in N years after we've fixed that flaw."
We're "validating the objection" -- justifying any inclination not
even to try Racket, yet, despite everything it offers, already.
- As for existing users, they might hear, "Yes, some of you might not
like this change. Or even if you don't hate it, might be disappointed
we're changing that instead of doing something else you feel is a
higher priority. We realize we might lose some of you. But we feel we
have so little to lose, it's worth that risk." So, yeah. Effectively
telling existing users they're "little to lose" isn't great. (Even if
that's not the intent, that's what some people will hear/feel. There
will be somewhat greater attrition.)
- During the years' wait, who would invest time doing more tutorials and
books and advocacy, using the old syntax? Some might. Many would say,
why bother; I'll wait.
In short, it seems like the "strong" version would freeze advocacy and
adoption during the N year transition.
Whereas I think something like the first version -- fully co-equal
syntaxes -- would be easier to talk about and minimize short-term harm.
---
Ignoring the implementation difficulty (which I realize is a ridiculous
thing to ignore, but just for a thought experiment): I've seen some SDK
or API docs with a "choose your language" UI that changes function
signatures and code examples.
- Could there be some reasonably good mechanical two-way enforestation /
deforestation? Maybe I'm misusing those terms. I mean, convert
documentation between the two syntaxes, on the fly.
- Even better, could this work well enough not just to display usable
documentation, but to transform actual source code? (I don't know if
this would need to impose something like the Go printer, to "enforce"
coding styles, for acceptable round trips. I don't even know if that
would be unfortunate or fortunate.)
If any of this is feasible, then talking about it now and during the
long wait, would help send a more positive message:
People could keep on keeping on, knowing that someday there will be
tools to help them convert (or not convert, as they wish). As opposed to
worrying they're investing time on something scheduled for cultural
deprecation.
---
Again, I'm still skeptical whether new syntax is the most effective,
highest priority. At the same time, I'm trying to contribute
constructively to refining that plan, in case it is chosen. In
particular I'm concerned about what happens to the community in the
meantime.
--
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/87muh4n112.fsf%40greghendershott.com.
