
Thoughts on Racket2 - spraak
https://beautifulracket.com/appendix/thoughts-on-racket2.html
======
acbart
One of the biggest problems is that these language designers, who want to
design an "idealized" language, continue to make big decisions without regards
to any kind of actual data collection. I just had the chance to meet and talk
with Andreas Stefik, who summarized the utter and embarrassing lack of
research by the PL community about actual language usability[1]. I'm not
exactly jumping into line to adopt his evidence-based language "Quorum", but
thank goodness that someone cares enough to do actual HCI research instead of
just arguing theoretical merits. My own history and feelings about Racket are
with regards to its connections with the controversial "Program by Design"
curriculum - feelings that are both complicated and narrow (all revolving
around introductory computing contexts). But I certainly resonate with this
quote from the article:

"But in the last 60 years, simply grab­bing these dissenters by the lapels and
fumi­gating them with the stinky garlic breath of paren­the­sized
S-expres­sions has not been a winning strategy. If Lisp parti­sans want
different results in the next 60 years, we need to try some­thing new."

[1]
[https://quorumlanguage.com/evidence.html](https://quorumlanguage.com/evidence.html)

~~~
fouric
Anecdotally, I spent five years writing C, C++, and Python before trying a
Lisp, but after I got used to them, I found parenthesized s-expressions (with
sufficient indentation and coloring - but that should be a given) to be
significantly _more_ readable than C-style syntax.

You can reasonably make the argument (and I do) that the reason why mainstream
programming culture hasn't adopted parenthesized s-expressions is not because
they're inherently less readable, but because of massive bandwagon effects +
inertia of C-style syntax due to the proliferation of...C-style languages,
which trains peoples' minds to prefer said syntax, even if their steady-state
characteristics are worse than that of s-expressions.

------
traderjane
> Of course, it’s the core team’s prerog­a­tive to run the project as they
> wish. The rest of us are, after all, free­loaders. But proce­dural
> trans­parency isn’t just a mech­a­nism for gath­ering commu­nity feed­back,
> nor is it bureau­cratic foofaraw. It’s also a tool for convincing users,
> espe­cially industry adopters, that Racket has proce­dures and values that
> are worthy of time & money commit­ments—that there is a “rule of law” that
> guides outcomes.

> I may be a visible user and fan of Racket—and even a teacher at Racket
> School—but I don’t have any influ­ence on the direc­tion of Racket. I think
> the Racket commu­nity is now big enough, however, that pulling off this kind
> of major change in Racket requires a stronger proce­dural foun­da­tion. The
> absence of this foun­da­tion is, in this fan’s opinion, a greater risk to
> the success of Racket2 than any tech­nical hurdle.

~~~
neilv
I disagree with that quoted bit about freeloaders. A lot of people have
invested a lot of time and energy to building Racket and the community, over
close to 20 years.

I fully agree with the bits about transparency, and would add to that...

The best outcome I can imagine from the recent would be if the leadership
articulates unambiguously what I've been calling the "top-level requirements"
that guide everything else in Racket. (I have a pretty good guess at the top-
level requirements thus far, based on history. I'm also pretty sure that much
of the user community still has mistaken ideas about that. Another reason for
articulating these top-level requirements is that they might be changing now,
as it seems a few things are changing.)

After the top-level requirements, as a guide and to also let people know where
they stand, then it would be good to have a well-considered model for whatever
input (and possibly decision-making) is wanted from the non-leadership.

------
lacampbell
_But in the last 60 years, simply grab­bing these dissenters by the lapels and
fumi­gating them with the stinky garlic breath of paren­the­sized
S-expres­sions has not been a winning strategy.If Lisp parti­sans want
different results in the next 60 years, we need to try some­thing new._

Given the rapid increase in programmers across the globe, I'd bet on there
being more LISP programmers now than at any other time in human history. So
why the obsession with popularity?

~~~
protomyth
The sad truth from a corporate / enterprise perspective, popularity (or
perceived popularity) means safety and checklist fulfillment. Management knows
it can find people to plug into its empty slots, and HR has a easy thing to
look for on the resume. People like comfort and safety.

Now, you could say you are a startup and need the advantage. Good, you can do
it, but you might have to supply more code to fill the gaps and deployment
might require some extra knowledge (ecosystem problems). Its a value judgement
as developer productivity isn't the only part of your development. Still, you
can have a heck of an advantage. Look no further than the founder of this
board, but remember the second part of the story. The Lisp got rewritten
because it wasn't a comfortable choice for the new owners.

Perceived popularity means comfort and ecosystem.

~~~
neilv
Exactly. I've been arguing this for awhile.

I'd go more specific than startups, to narrow in on those who are doing
something unusual, such that they know they'll have to implement nontrivial
stuff from scratch, no matter what language and off-the-shelf
libraries/frameworks they use. That's one of the places that Racket can be a
win.

Related to that, I've also been trying to get people to stop saying "batteries
included", because that's misleading, and sends the wrong message about what
the actual relative strengths are.

In practice, I suspect the initial startup adoption will largely be
chance/serendipity, until there's at least one great startup success story, to
interest and inspire confidence in other startup efforts. (I have one great
success story, which was due to such serendipity, but it's a non-public
system, and I've been milking that one way too long already in promoting
Racket.)

------
xixixao
I love reading these ideas, similar in "otherwordliness" to Rich Hickey's, but
the silent majority goes against them. Giving every programmer the ability to
create a language of their own does not work out well. (similarly, on Rich's
ideas, having library authors forever support old implementations to avoid
breaking clients does not work out in reality)

The truth seems to be closer to having to endure the constant pain of rewrites
and reimplementions, imperfect abstractions and systems, that slowly etch us
towards some shitty golden medium, something everyone hates but everyone
agrees is the best we could come up with so far. The next iteration of that is
most likely not gonna come from something completely different, genius, but
from something just slightly different, slightly better.

~~~
didibus
Rich's idea is not to forever support old implementation's, but to never
mutate an existing one in a breaking way. In the Clojure community, that's
actually been working pretty well, and you seldom have to deal with the kind
of rewrites other languages forces upon you.

------
sigwinch28
A talk about rebuilding Racket is being given tomorrow (Monday 19th August) at
ICFP'19 (10:30am local Berlin time):

[https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuil...](https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuilding-
Racket-on-Chez-Scheme-Experience-Report-)

This _should_ be live-streamed, with online Q&A:
[https://icfp19.sigplan.org/attending/Remote+participation](https://icfp19.sigplan.org/attending/Remote+participation)

~~~
disconcision
To clarify, this talk is about racket-on-chez, a chez-scheme-based rebuild of
the racket compiler, which is live now (but optional) as of racket 7.4. This
is entirely separate from 'racket2', a loose term for a variety of breaking
changes which are beginning to be considered, prompted by matt flatt's state
of racket talk at last month's racketcon.

~~~
tux1968
To save a google search for anyone else interested in watching his talk:

[https://youtu.be/dnz6y5U0tFs?t=392](https://youtu.be/dnz6y5U0tFs?t=392)

------
ansible
As a programming language dilletante, who has poked around in most interesting
languages and dipped into many communities, a major syntax change seems like a
very bad idea.

That said, if you're going to get rid of parens, look at Haskell. It is
actually a very Lisp-y language, where the parens are mostly optional.

------
_hardwaregeek
I attended Racket School and I genuinely want to like Racket. It has utterly
fantastic language oriented features like macros and syntax objects, really
awesome people behind it and some surprisingly solid tooling. But it's just so
hard to do anything "useful" in it. It's the Haskell problem. It's too fancy,
too nice to do any nitty gritty work with it. It's a gilded shovel. Writing
something as banal as a web server in Racket just seems like a waste. And
anything "nice" enough to write in Racket is too niche to really gather wide
appeal.

Compare this to Ruby, which, while not super popular, has gained a respectable
following after a period of hype. Ruby can trick people into thinking that
it's a nice, normal scripting language that you can show your parents. And you
can treat Ruby as a normal scripting language. Only after a period does Ruby
reveal its insane metaprogramming and dynamic features.

What I'm saying is Racket needs a little more stupidity in it. It needs to
project an image of a good ol' language that you can have a beer with. That
you can write a web app in. If that requires removing s-expressions, then
fine. If that requires removing conceptual purity, then fine.

Racket certainly still has potential. There's quite a lot of DSLs in modern
programming. Whether it's the adhoc configuration based DSLs of Docker and
DevOps in general (I hate Docker's weird pseudolanguage so so much), or
GraphQL in web servers, there's definitely places for Racket to shine. It just
needs to get sullied by the messy, imperfect, stupidity that is industry.

~~~
michaelmrose
I don't think you made a remotely adequate case for getting rid of s
expressions nor even a good explanation of what changes you think ought to
happen.

What does it mean to make the language stupider?

Ruby is popular because of rails. I don't think the making racket stupider or
more familiar will create an analogous scenario to ruby and rails.

~~~
_hardwaregeek
Fair enough. I didn't really explain that. I'd start with deemphasizing Dr.
Racket. Sure it's great and all, but most people aren't gonna use special IDE
for your language. They want to use VSCode or whatever. Besides I can't think
of a single good experience I've had with a language that encourages using its
own custom IDE.

Next, start building good interops. If you can figure out a way to get Racket
to interop with JS, then boom, you suddenly have access to all of the JS
ecosystem. Does this potentially create issues in your type system? Yeah,
probably. Does the JS ecosystem kinda suck? Yeah, but people use it. Right now
Racket doesn't have a great package ecosystem, so stealing packages from other
languages is probably the next best thing.

Ruby is popular because DHH was having enough fun in Ruby to build a web
framework and get shit done with it. Do you think DHH could have done that in
Racket? I'm not so sure.

Making a language worse just means killing your darlings. Language designers
tend to be very smart and into very interesting, very powerful, but very hard
to understand features. Which can be great in small doses. But if your
language's idiomatic style relies on said interesting, very powerful but hard
to understand features, you're a little screwed when you try to teach people
_cough_ monads. Making a language worse means moving off these really amazing
features and onto slightly worse, but easier to understand features.

~~~
fouric
You still haven't named a single Racket "darling" that needs to be killed off,
nor suggested any changes to make it "stupider".

Yes, DrRacket is the developer-suggested editor, but VS Code, Atom, Emacs,
Vim, and Sublime Text all have Racket integration [1][2][3]. More options for
tooling is Not A Problem. In addition, you didn't even point out any problems
you had with DrRacket in particular.

Interoperability is completely irrelevant to any problems of the language
being "too smart" \- FFI is a near-universally-desired feature that is only
not present because the devs haven't gotten around to it yet.

Racket does not rely on monads, conceptually or otherwise, to do anything
critical. What "very powerful but hard to understand features" are you
referring to?

[1] [https://docs.racket-lang.org/guide/other-
editors.html](https://docs.racket-lang.org/guide/other-editors.html) [2]
[https://atom.io/packages/language-racket](https://atom.io/packages/language-
racket) [3]
[https://marketplace.visualstudio.com/items?itemName=karyfoun...](https://marketplace.visualstudio.com/items?itemName=karyfoundation.racket)

~~~
_hardwaregeek
Geez someone's a little grumpy. I'd appreciate a little more civility.

I don't have any problems with Dr. Racket itself. It's a very useful, very
powerful IDE. But from a marketing perspective Dr. Racket just looks and feels
bad to developers. It's a special IDE that you need to boot up, which is
reminiscent of Matlab or worse, an educational language like Scratch. In fact,
most people I talk to about Racket consider it a language for kids to learn
how to code. Dr. Racket certainly doesn't help with that. Especially when the
tutorials for Racket ask for you to download Dr. Racket. So yes, Dr. Racket Is
A Problem.

Interop may be a problem that developers haven't gotten around to solving.
However, I have a distinct memory of sitting in Racket School, hearing someone
ask about features that Racket needs to be mainstream ready, and having the
creators of Racket shrug and say "we're already mainstream ready". Perhaps
they were exaggerating. Perhaps I misheard. But that's the impression I got
having gone to Racket School

I'm sorry that I didn't spell out the "very powerful but hard to understand
features" part. I mistakenly figured it was pretty clear if you understand
Racket's paradigms. The very powerful but hard to understand feature is
macros. Macros in Racket are more than a little tricky to understand. You have
to get a mental model of syntax objects and compile time vs run time (this is
actually harder than it sounds, cause iirc there's like 3 or 4 separate
passes). You need to understand how to develop domain specific languages that
are well designed and well scoped. You need to understand how to override
function application and when that needs to happen. And so on.

I'm not saying get rid of macros. That'd be absurd. But step back from
language oriented program and foster a more traditional form of development,
while pitching language oriented programming to library developers (like Rails
has it's own DSL essentially).

------
liability
LOP is cool and interesting, but I'm much more interested in a _" batteries
included"_ scheme dialect. Is there another language with devs more aligned to
that interest?

~~~
_emacsomancer_
I think Racket is probably a good bet for a 'batteries included' Scheme
dialect (and I think rather than Racket2, including more batteries would
attract more people to Racket, but I digress...) - it has good crossplatform
GUI options, for instance.

~~~
liability
Yeah, I've been using racket/gui a lot and it would be a real drag to use GTK
ffi bullshit or whatever instead.

