Message in the meantime?
760 views
Skip to first unread message
Greg Hendershott
Jul 23, 2019, 12:55:40 PM7/23/19
to Racket Users
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.
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.
Neil Van Dyke
Jul 23, 2019, 2:19:32 PM7/23/19
to Racket Users
I want to take a further step back, and say it would help for everyone
to be really-super-clear on what's motivating Racket2, and what we
really want to accomplish. (I know a good effort has already been made,
but I get the impression not everyone has the same idea yet, and I think
even more is needed.)
Putting on my software engineering hat... If we ever did a really
rigorous requirements analysis, inevitably percolating up to and refined
at the top would be what are the root goals (not far below general
happiness and truth) that everything else ultimately served. If we know
this, we can skip the (absolutely grueling) full analysis, and focus on
the root goals.
It might turn out that things like "improve basic education and CS
education", "advance PL research", "have greater impact on industry
practice", and "career development"... are a few steps above "needs of
the current developer community", and so, in a sense, the current
community would only be a resource in service of those other, higher goals.
In that case, the current non-core developer community would certainly
remain useful for promotion/buzz, impact validation including on grant
proposals, sounding board and useful input (Aaron Turon mentioned this
sometimes happened), and potentially labor. But the requirements
decomposition would be clear that the relationship was *not* like city
councilors representing the interests of the current constituents, *but*
more like a volatile network of mutually-beneficial relationships among
independent companies.
Were it a network of multually-beneficial relationships, then, given
that this is Racket, I think we can safely soften it a bit with some of
those independent interests being altruistic
for-the-greater-good-of-humanity, but I doubt those are the community
member's only interests.
Or maybe the needs of the current/legacy community are a top requirement
(truly separate from how that would serve those other goals), and we
should be clear on why, and what importance that has relative to the
other top requirements, and then maybe ask why again, to be sure that
makes sense. (I emphasize the why, because, as a "community member"
most of the time since PLT v103, I'd have difficulty arguing that my own
interests should be a consideration to anyone else at this point.)
In any case, this might be a little time for everyone to reflect on
their interests, and then we could try to be really-super-clear that we
all have identical shared understanding about what's motivating Racket2.
to be really-super-clear on what's motivating Racket2, and what we
really want to accomplish. (I know a good effort has already been made,
but I get the impression not everyone has the same idea yet, and I think
even more is needed.)
Putting on my software engineering hat... If we ever did a really
rigorous requirements analysis, inevitably percolating up to and refined
at the top would be what are the root goals (not far below general
happiness and truth) that everything else ultimately served. If we know
this, we can skip the (absolutely grueling) full analysis, and focus on
the root goals.
It might turn out that things like "improve basic education and CS
education", "advance PL research", "have greater impact on industry
practice", and "career development"... are a few steps above "needs of
the current developer community", and so, in a sense, the current
community would only be a resource in service of those other, higher goals.
In that case, the current non-core developer community would certainly
remain useful for promotion/buzz, impact validation including on grant
proposals, sounding board and useful input (Aaron Turon mentioned this
sometimes happened), and potentially labor. But the requirements
decomposition would be clear that the relationship was *not* like city
councilors representing the interests of the current constituents, *but*
more like a volatile network of mutually-beneficial relationships among
independent companies.
Were it a network of multually-beneficial relationships, then, given
that this is Racket, I think we can safely soften it a bit with some of
those independent interests being altruistic
for-the-greater-good-of-humanity, but I doubt those are the community
member's only interests.
Or maybe the needs of the current/legacy community are a top requirement
(truly separate from how that would serve those other goals), and we
should be clear on why, and what importance that has relative to the
other top requirements, and then maybe ask why again, to be sure that
makes sense. (I emphasize the why, because, as a "community member"
most of the time since PLT v103, I'd have difficulty arguing that my own
interests should be a consideration to anyone else at this point.)
In any case, this might be a little time for everyone to reflect on
their interests, and then we could try to be really-super-clear that we
all have identical shared understanding about what's motivating Racket2.
Brian Adkins
Jul 23, 2019, 8:57:50 PM7/23/19
to Racket Users
On Tuesday, July 23, 2019 at 12:55:40 PM UTC-4, Greg Hendershott wrote:
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.
Option #1 is the only viable option from a community perspective. And I think it will demonstrate the value of language oriented programming more clearly.
I chose Racket for many reasons, but one important reason was that the age of the language allowed me to examine the history of how the community operated over a *long* period of time to get an idea of what I might expect in the future. I didn't even consider languages that I felt were too young.
If anything other than option #1 is our course of action, then any (current, or hypothetical future) users would be right in assuming the possibility that sometime later, the new official language might also be deprecated for something very different than what they expect. This is how *not* to build a community.
I'm sure people disagree with this line of reasoning, and I respect your different perspective, but hopefully we can all at least agree that expectation management is important, and that expectations a currently a bit muddled.
If the core team and/or community wants something other than option #1, I would much prefer to know sooner rather than later. It would make me sad, disappointed, frustrated, etc., but I suppose I would then reluctantly take a cue to consider Chez Scheme given it was chosen by Racket people I respect to be their foundation, just as I considered (and eventually chose) Racket, via PLT Scheme, when I discovered Paul Graham chose it for the foundation of Arc (after he abandoned his language community).
Brian
Alex Harsanyi
Jul 23, 2019, 9:28:53 PM7/23/19
to Racket Users
On Wednesday, July 24, 2019 at 12:55:40 AM UTC+8, Greg Hendershott wrote:
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.
I had a look at the proposals at https://github.com/racket/racket2-rfcs/issues, and they seem reasonable changes which, in my opinion, would improve the Racket language. Most of these changes, if they are implemented, would also allow a relatively easy transition of existing Racket code.
I can see only one proposal for changing the syntax and it is no more radical than "#lang at-exp", which is already part of Racket, and seems to be popular.
On the other hand, anyone who is reading the posts on racket-users list, would think that the Racket is a risky language to learn and use at this time. Perhaps it is time to stop the speculation and comment on the actual proposals being made?
Alex.
Brian Adkins
Jul 23, 2019, 9:46:57 PM7/23/19
to Racket Users
Alex:
Given that options being considered include converting official documentation over to the as-yet-to-be-defined new syntax and relegating #lang racket to a similar status as #lang mzscheme or #lang scheme, I don't think it's unreasonable to feel there is some risk as things stand *currently*.
I expect more clarity to come which may reduce the risk, but it does seem like the majority of people who are downplaying the risk (or the perception of risk) are those in favor of the proposed changes. I suppose that's a natural response.
Brian
Matthew Flatt
Jul 24, 2019, 4:41:55 PM7/24/19
to Greg Hendershott, Racket Users
At Tue, 23 Jul 2019 12:55:37 -0400, Greg Hendershott wrote:
> 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:
This looks difficult to me. While choices in syntax can make this
> 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:
problem easier or harder --- and a lot of existing work on alternative
Lisp syntax focuses on making it easier --- even in the ideal case, it
seems difficult to make switching syntax automatic and pervasive. I
think there would end up being a lot of overhead to maintaining
documentation and tools that can reliably toggle between notations.
There are many points into between completely incompatible and
trivially convertible syntax. If we decide on a syntax change, we will
certainly create transformation tools, and the only question is how
automatic they can be.
> 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.
syntaxes. We could have different language names, parallel
documentation and tutorials, different entry points on the web, and
separate distributions. Those would share the same core implementation
and package system, so they'd interoperate, and maybe some other
parallel products could have shared sources.
Actively maintaining two complete faces of Racket in that way would
incur a significant cost, both in the short term and long term --- not
the same cost as supporting switchable syntax, but still significant.
Anyway, Option 1 read that does seem within the realm of possibility.
For now, I'm still advocating option 2.
> TL;DR: How would we promote Racket in the meantime??
> Example worry: Something similar to an "Osborne Effect".
solutions, and, obviously, I can't close the technical question;
someone might come up with a great idea. My sense so far, though, is
that the potential technical solutions would be too difficult and/or
expansive.
As others have noted, if we end up changing Racket's syntax, it
wouldn't be the first time that Racket has embarked on a difficult
transition with concern about how that transition appears. I've learned
the importance of starting a discussion within the community earlier
rather than later. I have not drawn the lesson that we need to be
guided (technically or strategically) by outside impressions along
these lines.
David Storrs
Jul 24, 2019, 5:26:55 PM7/24/19
to Matthew Flatt, Greg Hendershott, Racket Users
There have been multiple threads going around about this change, so maybe this has been answered and I've just missed it; if so, apologies. Still, I would love the answer to this:
What value are we trying to capture by changing the syntax?
So far, my understanding for the change is "Some people dislike parentheses, therefore getting rid of them will help Racket gain more users."
Is this in fact the sole reason for the change?
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d38c291.1c69fb81.9f608.bddbSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Brian Adkins
Jul 24, 2019, 5:37:22 PM7/24/19
to Racket Users
On Wednesday, July 24, 2019 at 5:26:55 PM UTC-4, David Storrs wrote:
There have been multiple threads going around about this change, so maybe this has been answered and I've just missed it; if so, apologies. Still, I would love the answer to this:What value are we trying to capture by changing the syntax?So far, my understanding for the change is "Some people dislike parentheses, therefore getting rid of them will help Racket gain more users."Is this in fact the sole reason for the change?
Matthew Flatt
Jul 24, 2019, 6:15:33 PM7/24/19
to Neil Van Dyke, Racket Users
At Tue, 23 Jul 2019 14:19:27 -0400, Neil Van Dyke wrote:
> In any case, this might be a little time for everyone to reflect on
> their interests, and then we could try to be really-super-clear that we
> all have identical shared understanding about what's motivating Racket2.
Your post strikes me as a clear-eyed analysis. I hope I read it as
> In any case, this might be a little time for everyone to reflect on
> their interests, and then we could try to be really-super-clear that we
> all have identical shared understanding about what's motivating Racket2.
intended when I see "identical shared understanding" as different from
"identical shared opinion".
Some posts have come across as suggesting that a core development team
(tricky to define) can ultimately do whatever it wants, independent of
what anyone else thinks. It doesn't work like that. But it's also the
case, as you say, that there are interests and goals competing with the
goals that we might extract from just taking a poll of Racket users.
There's going to be some difference of opinion.
I'm offering one potential shared understanding and trying to explain
it clearly. I read some posts as describing a different understanding,
which is good and definitely the point of the discussion. I like to
think I know the community well enough that I wouldn't put out an idea
that's a complete non-starter, but we need to hear enough voices to
know what's possible.
Matthew Butterick
Jul 24, 2019, 6:16:25 PM7/24/19
to Matthew Flatt, Greg Hendershott, Racket Users
On Jul 24, 2019, at 1:41 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:it seems difficult to make switching syntax automatic and pervasive. I
think there would end up being a lot of overhead to maintaining
documentation and tools that can reliably toggle between notations.
Support for alternative notation in the documentation system is a missing piece in Racket's LOP tooling:
1) We can make languages with alternative (= non-S-expression) notation.
2) We can integrate these languages with DrRacket pretty nicely, through automatic means (e.g., propagation of source locations) and manual (e.g., the `get-info` function)
3) But we can't document these languages in Scribble using their native notation. That is, primary forms like `defproc` assume that the language uses S-expressions.
Examples: `#lang datalog` [1] and `#lang lindenmayer` [2].
[2] https://docs.racket-lang.org/lindenmayer/Simplified_Lindenmayer_System_Language.html?q=lindenmayer
Philip McGrath
Jul 24, 2019, 6:34:24 PM7/24/19
to Matthew Butterick, Matthew Flatt, Greg Hendershott, Racket Users
On Wed, Jul 24, 2019 at 4:16 PM Matthew Butterick <m...@mbtype.com> wrote:
Support for alternative notation in the documentation system is a missing piece in Racket's LOP tooling:
… primary forms like `defproc` assume that the language uses S-expressions.
Examples: `#lang datalog` [1] and `#lang lindenmayer` [2].
Another, kind of ironic example: `#lang scribble/base` [3]. As it says in the docs, "Although the procedures are mostly designed to be used from @ mode, they are easier to document in Racket mode (partly because we have `scribble/manual`)."
But there's also a counter-example, C, as in "Inside: Racket C API."
I have hacked on this a bit for documenting both XML and Python. It is certainly possible, but it requires too much wading in and replicating the implementation of `defproc` and friends (especially if you want to try to work with things like `deftogether`), and I don't know an answer that's as elegant to write as Scribble for s-expressions. (I also just don't know another syntax that's as elegant to write as s-expressions, but maybe we'll find one!) (Some of my efforts for XML are at [5]. My Python attempts aren't public yet, but hopefully they will be soon.)
Reply all
Reply to author
Forward
0 new messages