Is there an expanded form of the Racket2 purpose declaration?

[David Storrs]

The discussion on Racket2 seems to have moved offlist to the RFC list on github (https://github.com/racket/racket2-rfcs/issues); are there other locations?

There is one question that I had back at the beginning of the process that I didn't manage to get clarity on, which is the rationale behind the whole thing.  I've gone back through some of the email discussion and gone through all 4 pages of the issues lists and read everything that seemed relevant.  The most apropos thing seems to be this:  https://github.com/racket/racket2-rfcs/issues/105 but it still doesn't really speak to my question.

My current understanding is that the rationale for the Racket2 effort looks something like this:

"We, the core developers, many (all?) of whom are also academics with a lot of experience teaching Racket to new programmers, have noticed that parentheses and prefix notation are a stumbling block for many students.  We would like to help the ideas of Racket spread into the larger community.  Therefore, we want to produce Racket2, which will have all the power of Racket but will get rid of parens and use infix notation, which will be more familiar and intuitive to students.  We also see this as a great time to improve existing elements of the language based on what we've learned since they were added, and potentially add new features."

Is this in fact correct?  Is there more specific discussion of it somewhere that I've missed?  I don't want to make people retread the issue if it's already clearly laid out elsewhere.

[Jay McCarthy]

My thoughts are in the thread you linked to:

https://github.com/racket/racket2-rfcs/issues/105#issuecomment-521446706
"""
I see Racket2 through the rubric of "We almost never break backwards
compatible and insist on gradual evolution as the only way to make
progress; but, now we are willing to make some radical changes: What
can we do to make Racket drastically better that can't be expressed as
an evolution?" In other words, I feel like Racket2 is defined as the
goal, "Whatever makes Racket a lot better" and the design constraint,
"It's okay to be incompatible."
"""

When it comes specifically to syntax, which is what you seem to be
asking about by reading the quote, here's a quote from my attempts to
write this up before:

https://github.com/racket/racket2-rfcs/pull/109/files#diff-f609e36bab3cb71c8829f58a5f9b2455R16
"""
The uniformity of S-expressions limits the amount of information at
the notational level of reading Racket programs. A small amount of
extra notation can go a long way with a small number of mores on its
use. For example, in Racket brackets are used in S-expressions when no
function or macro application is implied (like in the cases of a
`cond`); reading Racket programs without this notational affordance is
more difficult. On the other hand, it is awkward to embed arbitrary
fragments of code not in S-expression format, such as when quoting a
program in another language. The only effective option is to embed a
string. The Racket @-reader is helpful at this, but it is not
uniformly available and the standard structure of Racket's
S-expression based languages do not allow macro-specific reading of
such syntaxes.
"""

I'll add that I see S-expressions as obviously limited and it would be
nice to make a more powerful syntactic extension system that does not
say, "You can have anything you want, provided it is a parenthesis."

So for me, I don't see the syntax mission as having anything to do
with students or getting people to like me, I see it as a way to go
beyond the limitations of S-expressions and do something more powerful
and interesting. I think people will like us more after in as much as
I think people like awesome things, and I want to make something
awesome.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

> --
> 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/CAE8gKodAh%2BdO3v8bx0bmPJYUhtDmVgX2KrxH8N3QwtG43aX%2BYg%40mail.gmail.com.

[Breck Yunits]

I'd recommend investing work to make the problem of porting Racket1 code to RacketN painless. Hopefully as simple as one method call.

If translating Racket1 code to RacketX is made an easy problem, then you can do what is best for RacketX without worrying about how backwards compatibility.

That would pay dividends in other areas as well, regardless of what direction Racket2 goes in.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJYbDan4dqov1uswGhpe_Q7Tmh%3DyO6zQ6FwyU7XY6fnqXPgdfg%40mail.gmail.com.

[Robby Findler]

I'm not sure this was clear, but I think the clear goal for backwards
compatibility is that code that used to run continues to run
indefinitely. With no changes. That's certainly what the Racket core
developers mean by "backwards compatible". In other words "requiring
porting" is the opposite of "backwards compatible", at least in my
mind.

Robby

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAOgHByt6B55NfD6sY-gkh%2B01XP0xUy7Cb5t-uVWTSqq4gR0sSA%40mail.gmail.com.

[Jay McCarthy]

Exactly. We don't change anything about Racket 1 in a way that makes
any adaption needed. That's why putting a new "#lang" at the top of
new programs is such a big deal, because we can have a new level to
have backwards compatibility with for the NEXT 25 years.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOOrSZ1zSvP-5L7HhaPFrtqqE8AnX-UDKVUKq1H8u4uyag%40mail.gmail.com.

[David Storrs]

Thanks, Jay.  I've responded to the RFC.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJYbDan4dqov1uswGhpe_Q7Tmh%3DyO6zQ6FwyU7XY6fnqXPgdfg%40mail.gmail.com.

[Hendrik Boom]

On Wed, Aug 28, 2019 at 06:33:02AM -1000, Breck Yunits wrote:
> I'd recommend investing work to make the problem of porting Racket1 code to
> RacketN painless. Hopefully as simple as one method call.

We already have such a mechanism.

The Racket 1 code is prepended with

#lang racket

whereaas the Racket 2 code is prepended with

#lang racket2

and everything is interoperable.

Simple enough?

-- hendrik

[Neil Van Dyke]

> and everything is interoperable.

That it will be interoperable is something that must be committed to,
unambiguously -- it is not something #lang implementors get for free.

(Based-on-a-true-story example of bad interoperability... Your Racket
module naturally uses lists, the Racket language is then changed to make
lists immutable (and let's say it gets a new #lang for that), your old
module #lang still works, but now you can only use new modules in the
new #lang with difficulty and bug-prone-ness, and then an old
third-party package you use is moved to the new #lang, so you are stuck
on an old version of that or have to modify your code, or give up and
rework all your code in the new #lang. There are ways that could've been
avoided, but it didn't come for free, and didn't happen.)

[Breck Yunits]

> I'm not sure this was clear, but I think the clear goal for backwards compatibility is that code that used to run continues to run indefinitely. With no changes. That's certainly what the Racket core developers mean by "backwards compatible".  In other words "requiring porting" is the opposite of "backwards compatible", at least in my mind.

I get this, but I think it's a strategic mistake. I think the goal should be to move people forward to the new versions (whenever they come out) as quickly as possible (think Apple and the rapid adoption of new iOS versions, compared to Microsoft). NEVER break people's stuff, but make it dead simple for them to upgrade to the new stuff, by changing their code for them. I think the success of Apple has proved this is the better long-term strategy.

If Racket's truly a Language Oriented Programming language, than parsing it and upgrading it should be dead simple. Otherwise, why would I want to use a language that's difficult to upgrade?

--
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/20190828180751.ynkjzz2w3icf5vdw%40topoi.pooq.com.

[Robby Findler]

On Wed, Aug 28, 2019 at 1:44 PM Breck Yunits <bre...@gmail.com> wrote:
>
> > I'm not sure this was clear, but I think the clear goal for backwards compatibility is that code that used to run continues to run indefinitely. With no changes. That's certainly what the Racket core developers mean by "backwards compatible". In other words "requiring porting" is the opposite of "backwards compatible", at least in my mind.
>
> I get this, but I think it's a strategic mistake. I think the goal should be to move people forward to the new versions (whenever they come out) as quickly as possible (think Apple and the rapid adoption of new iOS versions, compared to Microsoft). NEVER break people's stuff, but make it dead simple for them to upgrade to the new stuff, by changing their code for them. I think the success of Apple has proved this is the better long-term strategy.
>
> If Racket's truly a Language Oriented Programming language, than parsing it and upgrading it should be dead simple. Otherwise, why would I want to use a language that's difficult to upgrade?

I'm not sure I agree with this position, at least in the strong sense
it is written here.

In my opinion, it is essential that a good programming environment (by
that I mean the language, libraries, community, IDE, the whole ball of
wax) should support what the programmer needs -- that's the primary
goal. Things like making people move forward to new versions are good
for the developers of the language (eg, less to maintain etc) but a
programmer has needs that are often driven by their bottom line and if
the programming language/environment gets in the way of that decision,
programmers will stop using it ... in the worst case as they run out
of income because they're busy satisfying things other than their
bottom line.

Of course, it is good to make it easy to move to new versions of the
language, but if there is no real benefit to the transition for the
programmer (eg they aren't planning to touch that code for the next N
months anyway as it does its job well) then I think we should let them
leave it alone and come to it when they need to.

Robby

[Benjamin Yeung]

On Wed, Aug 28, 2019 at 12:28 PM Jay McCarthy <jay.mc...@gmail.com> wrote:
>

> I'll add that I see S-expressions as obviously limited and it would be
> nice to make a more powerful syntactic extension system that does not
> say, "You can have anything you want, provided it is a parenthesis."
>
> So for me, I don't see the syntax mission as having anything to do
> with students or getting people to like me, I see it as a way to go
> beyond the limitations of S-expressions and do something more powerful
> and interesting. I think people will like us more after in as much as
> I think people like awesome things, and I want to make something
> awesome.

I think this point tends to get lost in all the existing material.
It's already in the threads listed in the relevant posts section, but
if people aren't "primed" to look for this particular point in there,
it's easy to miss. That's one of the takeaways I get when I hear
questions about the Racket2 purpose/goals/etc. Perhaps it's coming as
part of the leadership team's meeting, but I think it would help
reframe the syntax experiment if this was put forward more explicitly.

Benjamin Yeung

[Konrad Hinsen]

Robby Findler <ro...@cs.northwestern.edu> writes:

> Of course, it is good to make it easy to move to new versions of the
> language, but if there is no real benefit to the transition for the
> programmer (eg they aren't planning to touch that code for the next N
> months anyway as it does its job well) then I think we should let them
> leave it alone and come to it when they need to.

I very much agree with that point of view!

Programmers come in so many varieties these days that it's hard to make
generally valid statements about them. Apple's approach has worked well
for them indeed, but that's in the context of commercial application
development for a dominantly technophile user base. Different contexts
(open source, educational, in-house software, ...) and different user
categories (banks, lawyers, scientists, ...) require different
approaches.

On the other hand, I am not sure that it is possible for a development
environment to stay completely neutral on the issue of mandatory change
and please everyone. But I'd love to be proven wrong about this.

For an in-depth analysis of this question in the specific context of
scientific computing, see

https://hal.archives-ouvertes.fr/hal-02117588

Konrad.