mostly misalignment of priorities between my view and racket’s team. I want to write production-ready code, they want to write educational and novice oriented framework

I mean is syntax wrt its purely visual appearance (not talking about practical implications, like power of macro’s because of s-exp here) hugely selling point? To me it seems people pick up languages because they want to write web servers, games, UI, etc in it;

I agree with comment on the HN thread, that if you don’t want to use racket now, you probably won’t want to use racket with new syntax either

Agree. Racket has much more wenderful things besides the surface s-exp syntax: macros, syntax/parse, typed/racket, #lang, drracket. If these things cannot attract people, why can a not alien infix syntax attract them?

there was this thread on the mailing list https://groups.google.com/d/msg/racket-users/6ePaiAnqMtk/uwlPs81OAgAJ

related to production use of racket

some people are interested in those kinds of questions

but unfortunately they don’t tend to sit on tenure and promotion comittees

but all in all I view this who thing as a giant strategic mistake

and you can just see the bikeshedding

that has ensued

because it was broached long before there was in implementation

call the whole thing off

spend the next 5 years coming up with something that was not designed by comittee which is what the #lang mechanism actually enables

maintain the status quo

and then when you have some real data for #lang trapezoidal

have a real conversation

and allow people to focus on incremental changes that are needed to improve the runtime and tooling

for serious use cases (not to imply that education isnt serious, but most courses try not to put lives at risk with their problem sets)

but how the community is completely distracted by the bikeshed that is “things I dont like about programming languages, like, mutability”

ah well, time to go back to shut up and hack

@tgbugs I think you have some excellent points above. If #lang rhombus was handled in a similar way as other existing #lang’s, I doubt there would be any objections. But bringing it up in the context of Racket2 i.e. the successor to Racket is an entirely different thing.

General package question: has anyone written a package that draws Venn diagrams, preferably as as pict, and preferably where I could add labels inside the regions?

#lang racket
(require metapict)

(def x  10)
(def -x (- x))

(set-curve-pict-size 800 800)

(with-window (window -x x -x x)
  (def r 5)
  (def s (/ r 1.8))
  (def -r (- r))

  (def c1 (circle (pt (- s) 0) r))
  (def c2 (circle (pt    s 0)  r))
  (def rev curve-reverse)

  ; we split the drawing window into a left and right part
  (def left  (rectangle (pt -x -x) (pt 0 x)))
  (def right (rectangle (pt  0 -x) (pt x x)))

  ; colors
  (def red  (color-med 0.2 "red"  "black"))
  (def blue (color-med 0.2 "blue" "black"))
  (def mag  (color-med 0.5 "red"  "blue"))

  (def font (make-similar-font (new-font)
                               #:size 40
                               #:face "Arial"))
  (text-color "white"
    (with-font font
      (draw
       ; filled areas
       (brushcolor mag                 (fill c1      c2))
       (brushcolor red  (clipped left  (fill c1 (rev c2))))
       (brushcolor blue (clipped right (fill c2 (rev c1))))
       ; outlines
       c1 c2
       ; labels
       (label-cnt "A"     (pt -r 0))
       (label-cnt "B"     (pt  r 0))
       (label-cnt "A ∩ B" (pt  0 0))))))

Thanks

Counts as my MetaPict pict of the day :wink:

I concur strongly with @tgbugs. There is an interesting contrast with Elixir, which has recently announced that “As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned.” As a very small time contributor to the Racket community, the choice between something stable and something in flux is a pretty clear one that pushes me away from Racket.

I’m also unconvinced Racket has the slack in its user base and community to navigate the transition successfully (witness, losing Greg H., who—along with Lexi—has been my most frequent guide when I hit questions). I also don’t think Racket has a unique value proposition that will make it—post change—any more attractive. Macros are great, ditto with #lang, but they are hardly unique and will be no more so if accompanied by infix notation. The unique value proposition I saw in Racket was precisely s-expressions and the relentless consistency they brought to the syntax and logic of a Racket program. Take them away and I’m better off with Elixir (might be Rust for others, whatever).

Regardless, I am dubious that Racket’s unique value propositions can carry it through a period of uncertainty in the face of more stable alternatives (compare to Python, which offered a huge established ecosystem and huge community, or Swift, which offered the lure of programming iThing apps).

So, my preferred route would be the same of @tgbugs: pull back and continue to improve Racket in its current form. Avoid the uncertainty. Let those so motivated design #lang trapezoidal that captures the improvements they feel are needed. They can bring it to the community, which will adopt it to the degree it serves them better. If it leads to a wholesale shift to #lang trapezoidal as the de facto default language in the ecosystem, the community can make the shift without the uncertainty—that is, it can move from a known to a known.

I recognise I have very little stake in Racket and have the luxury of not being responsible for steering the language or the community. So, I’ll offer the thoughts above to those who carry that burden, along with my best wishes and deep appreciation for the learning their work has allowed me to gain from Racket.

Thanks also to the many wonderful, warm and helpful members of the community!

@soegaard2 Is it possible to do the :racket-flat: in metapict?

Why not!

:racket-flat:

A project for tomorrows picture.

@sanchom you seem to continue to minimize others’ concerns. What you refer to as “a possible project” was what Matthew Flatt talked about as Racket2 i.e. the presumed successor to Racket complete with converting the official documentation to the new syntax, etc. Can you see why people who love #lang racket might be concerned about this? If not, maybe try going into some other language forum and suggest they switch their language’s syntax to s-expressions, and see what type of reaction you get :slightly_smiling_face:

While I still have some concerns, I do think I’ll be able to continue to program in #lang racket for a very long time. It would’ve been nicer if the core team treated the new syntax language in a similar manner to Typed Racket, but as Matthew has stated, Racket exists because of research and is still funded in part by research, and they have a research itch to scratch. In the end, the #lang racket community will be what we make of it, and I’m hoping Greg will re-engage at some point & the other folks who have contributed to Racket continue.

I’m just totally sold on Scheme at this point, and Racket is still the best Scheme implementation out there, so I don’t have much choice but to make a go of it :slightly_smiling_face:

Just to clarify the scope of my original statement. I did not mean to imply that soliciting community feedback and input about pain points, design issues, future dreams and desires, etc, in advance of upcoming changes, is a mistake at all. In fact, thinking deviously for a moment, depending on how big a set of changes the team really wants to pull off, leading with “change the syntax” is quite an effective strategy for moving the goalposts (though I do not think that that is at all what anyone had in mind, for better or for worse). In point of fact, the general openness and engagement of the core team with the community is one of the reasons why this discussion appeared in a public venue at all, and it is profoundly unfortunate that it was done in such a way that it left room for people’s imaginations to run wild. I think that the Racket community is quite open to seriously engaging with and discussing radical ideas at a high technical level (#lang radical anyone?) but I think that there are certain fundamental aspects that can only be discussed with very careful framing, and that now we know that syntax is one of them.

For example one very simple thing that might calm things down a bit would be a statement along the lines of “all RFCs that deal with systematic syntactical changes will only be considered if they are accompanied by a full working #lang othersyntax implementation and certain [to be specified] tooling” so that the burden of proof is placed on the proposer, and the community can ignore any other syntactic flights of fancy until there is a concrete implementation to consider.

I suspect that this is more or less what the process is intended to be, and again, needing to qualify this and tiptoe around it is unfortunate, because people ought to be able to talk about their ideas and share them freely without fear.

@tgbugs I think that’s a great idea. Would you consider writing an RFC in https://github.com/racket/racket2-rfcs to that effect?

Was there an issue yet about writing the meta-RFC?

I think there was, somewhere

or it came up in other issues

I forget

Yeah I couldn’t remember if I read someone request something on the mailing list or here or in one of the Github issues

¯_(ツ)_/¯

the issues and the mailing list threads have so much discussion that they might as well be considered ephemeral

opening pull requests with rfcs would be more durable

happy to start a draft for a meta general process one, but it might be a couple of days, I also wonder whether that was the sort of thing the core team was trying to set up with guidance from/consultation with the Rust guys who have done this before, not that would stop me ^_^

I think you ought to just go for it. As far as I can tell, there isn’t a secret process RFC being cooked up by the core team and they’re figuring this out as they go just as much as everyone else is (and they purposefully wanted to do things that way).

but that’s just my guess

my take from a few of Matthew’s emails to the list was that they had the Rust talk open Racketcon as a way to set the stage and were hoping to have the process a bit more worked out before ramping up

My read on it was to have more community involvement. So if someone from the community hashes out a workable process and a consensus (or whatever) sign on to it I think it would be a good.

indeed

Playing around with something like this: > (define (real<=> x y) (cond [(< x y) '<] [(= x y) '=] [else '>])) > (transduce (list 1 2 3 2 1 2 3) (filtering-on (increasing? real<=>)) #:into into-list) (list 1 2 3 2 3) > (transduce (list 1 2 3 2 1 2 3) (taking-while-on (increasing? real<=>)) #:into into-list) (list 1 2 3) > (transduce (list 1 2 3 2 1 2 3) (dropping-while-on (increasing? real<=>)) #:into into-list) (list 2 1 2 3)