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.
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.
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.
> 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.
I suspect the first impression of DrRacket has been scaring off real developers since the start (as it initially did to me, ~18 years ago).
DrRacket was designed for students with no programming experience at all (and then some nice pro features were added atop that).
Put DrRacket first thing in HtDP, but be very careful about first impressions elsewhere. (And this doesn't mean adding an additional explanatory paragraph, or an additional manual about all your IDE/editor options. Racket already has a massive wall of documentation manuals, with the useful stuff scattered all over. People tend to not read stuff on the Web under even the best of conditions.)
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?
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).
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.