thanks for the light-sabers - you can enter as many times as you like.
We’ve has some great entries! Dont forget to enter by 1-Sep
if you have any issues that are good-first-issue’s please label them so they can be found https://racket.slack.com/archives/C09L257PY/p1565255893113200
ended up writing a draft for the rfc, mostly about criteria for evaluating syntax proposals, it needs editing before it is fit for public consumption, so will probably get a pr up friday or saturday
The criteria for evaluating syntax proposals could include reference to this file: https://github.com/racket/racket2-rfcs/blob/master/syntax-considerations.md
@alexknauth Besides “macros / language extensions feel natural next to existing forms” I think an additional consideration is important. It’s important for macro writers than the syntax leads to “syntax patterns” and “syntax templates” that are easy to use.
Then maybe that bullet-point should be added to the file
I hadn’t thought of that
but it is important
Thanks
@mflatt I think it may be time to provide some clarification regarding the roadmap for Racket. I just happened to notice a statement from ecraven in the #scheme IRC channel: “given that racket seems to be moving away from s-expression, I’d not suggest it any longer”. This type of sentiment is far from an isolated one. There has been a mixture of messages from core team members that include statements such as "#lang racket won’t go away" and "#lang racket will fade to the background", etc. I think it’s accurate to say that there is some amount of fear, uncertainty & doubt (FUD), and in my opinion, that’s to be expected given the way things have been handled. I’ve resolved (possibly naively?) that I will be able to continue to develop in #lang racket for a long time, but if enough others in the community don’t come to that resolution, then I can see how continuing to develop in #lang racket may not be desirable.
It really doesn’t help that when anyone expresses this type of concern, the response is typically a condescending dismissal. The choice of a language & ecosystem is a long term one that requires nearly impossible foresight and a fair amount of faith. I know that Racket “exists because of research and is funded by research”, but I think industrial programmers can bring a lot of value to the community - including helping to answer the question of students, “if I invest a lot time to learn this language, what will I be able to use it for in the future?”
I’m particularly frustrated because I felt like Racket was really on the cusp of critical mass, and then bam. Maybe the answer is to have a cutting edge, research branch, and a more stable practical/industrial branch. Regardless, waiting too long to bring clarification can only have a negative impact IMO.
@sanchom just out of curiosity, would you classify the #lang scheme and #lang mzscheme communities as thriving? I’m referring to "#lang racket is not going away and will always have its current parenthesis-oriented syntax. In the same way that Racket still supports #lang scheme and #lang mzscheme and even (module <name> mzscheme ....)" from your link.
Exactly my point :slightly_smiling_face:
Think of scheme and mzscheme like racket and racket/base.
Actually I imagine many of the people in those communities transitioned to the Racket community.
The language scheme was used before The Great Renaming (and the switch to immutable lists).
Having these languages meant that the transition was seamless. So seamless that a few modules still used mzscheme.
@samdphillips I totally agree, and I think #lang racket was an attractive option to move to for those communities, so now I’m just wondering how that works when the option is unattractive.
I think some of the tension is some want a BDFL and I think the core team would like to see the project become more community led
I think it might simply be a matter of communication, but here’s a statement in the #scheme channel just a few seconds ago: “badkins: from what I read on the mailing list, it isn’t entirely clear that #lang racket will be supported for a long time, as I understood it they left that open”
That is an increasingly common sentiment.
@j.tecca has joined the channel
I’m personally bullish on Racket’s future, but if Greg & Neil & others start pulling back, my personal feelings become less relevant. I think it’s impossible to deny that there is a fair amount of misunderstanding/confusion currently.
Programs in #lang racket will continue to be supported in the sense that they will continue to work and the forms in them will continue to be documented, etc. The primary change contemplated for those languages (besides the general improvements that are always being made) is that if there’s a new, improved #lang, that would be presented as the default in the documentation/tutorials/web page.
I agree that there’s a fair amount of confusion at the moment and I hope we can do more to clear this up.
@samth yes, that’s the message that keeps being repeated, but I have to say I can totally empathize with the folks that are wondering what the day-to-day future of programming in #lang racket might actually look like. After reading so many threads/comments, and having personal discussions, I’ve resolved that the future can look great; however, I’m really not at all surprised that the wider community and outsiders have not gotten that message.
If I read between the lines, it seems that Matthew really wants to move on the new syntax, and he really wants everyone to just jump on board with him, and he isn’t really all concerned if existing lovers of #lang racket are casualties. I kind of doubt that’s reality, but the written messages seem to conclude that.
An “official” statement on the blog (perhaps timed the new release) would be welcome.
@soegaard2 strongly agree
I personally think it’s possible to have two flourishing communities that share a lot in common, and I’m not sure that’s ever been done in quite the same way. However, if the official view is that #lang racket (while continue to be nominally supported) is, in essence, deprecated, then we will have lost a lot.
I know Racket made a decision to be able to diverge from Scheme, but it’s still the best Scheme implementation by far, and it would be nice if that aspect continued & grew stronger.
Speaking just for myself, my hope is that a #lang racket2 ends up having the same relationship to #lang racket that it does to #lang scheme today — everyone wants to use #lang racket because the whole community agrees that it’s better. I think that right now there are lots of people who don’t think that will be the case with additional changes, and so they’re worried. But that’s where I’m coming from — a belief that we can make Racket compellingly better in a way that brings along basically everyone. I don’t know what I think the right thing to do is in the event that we can’t do that.
Bingo @samth - you nailed it, and that’s the problem! Some of us have literally spent years researching languages, and we have concluded that we like s-expressions. All of the folks who have condescendingly dismissed the concerns are either open to the new syntax, or already know they’d prefer a non-sexp syntax. Simply wanting people to agree with the new syntax idea won’t make them do so. I can assure you it will not bring everyone, so I hope there is a plan for both to flourish, or you’ll just take a step back to a smaller community and start building from there.
My fear is that too many things are changed at once.
If the core team is so sure of the appeal of the new language, just treat it like Typed Racket or another #lang, and build it, then if everyone flocks to it, rename it #lang racket2 if you must. Declaring it Racket2 before it’s even successful is presumptuous.
And I’m actually fine if Racket wants to discard its Scheme heritage; I’d just prefer to know sooner than later. I’d have a lot of work to do to get the 2nd best Scheme implementation to the point of productivity of #lang racket, but 5 years from now I could be better off. What I’m not fine with is the current uncertainty and lack of vision.
@samth you said you were speaking for yourself, but it really does seem like the core team feels this way (possibly with the exception of @jeapostrophe) - if so, maybe you all could get together and just state it officially, so the rest of us aren’t wondering for 4 years…
@mflatt has been pretty consistent with that message - both with written language & the subtleties of face-to-face communication.
“New” commercial use of Racket: > Well, my 10 year old spaghetti-code rewrite of my 22 year old password manager is > written in Racket [1], but I don’t think about 1/3 sales per year qualify as commercial. > If I ever have the time, I’ll rewrite it in another language with proper memory locking > and better password stretching. > [1] http://peppermind.com
The issue is that I’m not willing to just accept that we have to give up appealing to people who like the way #lang racket currently works. I know you think you wouldn’t like a significantly revised version of Racket, but I genuinely think we should aim for something that will bring you along. I’ve been using Scheme for almost 25 years at this point, I like it a lot, and I don’t want to cast off that heritage — I want to build on it. It’s clear to me at this point that lots of people won’t be persuaded without building something real first, so I think that has to happen before any kind of definitive decisions get made. But, as I said, I think clarifications in the short term are definitely needed.
To clarify, I wouldn’t at all mind a significantly revised version of Racket, and I’d be willing to port my applications to the new version - for example, when moving from mutable to immutable cons cells. However, introducing an infix syntax to a Scheme is in a different category than most changes. I would even keep an open mind that I might like the new syntax - naturally, it would have to be different enough from all the current syntaxes I’ve rejected :slightly_smiling_face:
The problem is the "might". I can’t continue to invest a lot of money into my applications using #lang racket knowing that the might could turn into a definitely not.
It’s particularly painful with Racket, because one of the very important factors I considered when choosing it is the very long & good history. I never would’ve anticipated an entire syntax change! I suppose the change from PLT Scheme to Racket might have hinted at it, but wow.
@alexknauth will be sure to include it
since many of those points and considerations are on the list of things that can have quantitative metrics
which is one thing I will propose
GitHub recently introduced a ‘template repository’ functionality https://help.github.com/en/articles/creating-a-template-repository
I’ve created a draft of a Racket version.
I’d appreciate your feedback.
draft: https://github.com/spdegabrielle/racket-package
‘generate’ link: https://github.com/spdegabrielle/racket-package/generate
This is awesome! I encourage you to write a post on the Racket blog about it.