Future of Racket

S-expressions were the one thing that held me back from Racket. I like a lot that I've heard about the language, and I'm a believer in keeping syntax as simple and regular as possible, but in my book a language that doesn't allow infix expressions is not usable, while a "language" that requires users to implement text-based macros to work productively in it is incomplete.

The article doesn't link to the syntax proposal, so I don't yet know what it looks like. But for the first time I now hope that Racket might become a practical language that I could use. No S-expression language has ever gone beyond niche. I'm glad Racket is willing to step past them.

He also wrote what I suspect is the de facto Markdown parser for Racket, which is used in Pollen. (I thought I recognized his name dimly, and it's because I reported a bug in Pollen a few years ago relating to Markdown smart quote handling that turned out to be a bug in his Markdown processor -- which he fixed virtually instantly. https://github.com/greghendershott/markdown/issues/45 for the curious.)

To me, Flatt's proposal for Racket2 smells more like adding tools to better facilitate infix languages than depricating S-expressions. Given Racket's pedagogical mission, it looks more like a move toward migrating the HtDP series of languages (Beginning Student, Intermediate Student, Intermediate Student with Lambda, and Advanced Student) to infix syntax than anything else. Not really the end of the world or a big change to the larger Racket community. Just another extension of an ecosystem that remains s-expression based despite Algol and Datalog shipping in the box. It's hard to see Flatt's work porting Racket to Chez Scheme as a prelude to abandoning Scheme as the basis for the Racket ecosystem.

On the other hand, the reality is that Racket's syntax makes for an uphill fight when it comes to adopting the HtDP curriculum. Anyway #lang racket syntax is just sugar on the more important concepts in the HtDP methodology. The HtDP engineering principles are matter much more than which language is used at the top level.

The mailing list traffic on this topic took the wind out of my sails for wanting to spend my tinker time in Racket. On the one hand, it’s probably overreacting for me to throw in the towel on Racket at just the suggestion of this change. On the other hand, part of what makes me interested in writing Racket for projects where I have broad latitude is the sense that I’m both using an exciting technology, and a technology with a history of relative stability.

By signaling a switch to some bland surface syntax I feel that it’s eroding the exciting part as well as the stability benefits of the language. For data science (the domain I’m most invested in) Julia has attracted a decent mindshare, is lispy (even if not as much as I want), and is fast. Racket with a bland syntax is likely to be about as lispy as Julia, much slower, and have fewer of the data science libraries I care about.

I only have so many hours in my life to dedicate to not-making-money programming endeavors. I was sort of hoping that Racket would be the vehicle for those hours. But right now, I’m worried that Racket is Perl 6-ing itself, and that’s a hard place to spend hours. Especially with people like Greg leaving the community.

A while back there was a thread about a prominent member of the Common Lisp community saying that he’d probably eventually leave CL for Racket. But then later he signaled that he’d settled on Gerbil Scheme. Maybe that’s the right life raft from Racket.

Greg Hendershott has contributed a lot of software development, and also a lot of community participation. The latter doesn't appear on one's CV, but makes a big difference, and has network effects.

The community of Racket has long been one of its selling points, which new adopters often mention, and people like Greg are why.