Why learn Racket? A student's perspective (opens in new tab)

I've spent some time looking at Racket open source projects, and I did not come away with the impression that one must start by creating one's own #lang. There are a lot of custom DSLs out there, but it seems to me that most of them come about, not because using Racket compelled the author to create a DSL, but because creating a DSL compelled the author to use Racket. No other platform I know of (not even MPS) seems to even come close in terms of ease of use and number of batteries included.

I could admittedly be projecting here. Wanting to create a DSL is what brought me back to Racket after a long hiatus. But I don't think so. Exhibit B is that, if you go to Racket's Discord or Slack, you'll see that people are mostly discussing how to solve concrete problems with standard language features. The volume of talk about macros and #langs is much, much smaller.

Thanks! I found some type providers docs [0] which is at some level an ML version of my Racket blog post. I had no idea type providers existed. The closest inspiration I had was probably Kotlin SQLDelight or Hibernate java codegen which (probably unnecessarily) requires in-code annotations. Anyway, that's very cool!

The F# type provider looks so stateful ;) Although they are pretty similar, I think the racket pattern syntax is very beautiful. Once you grok the pattern variables vs syntax objects vs quoted lisp data anyways.

Racket actually generates code. It could generate Typed Racket type expressions too. It makes me wonder how LINQ is implemented--my lisp hubris makes me guess it's not as simple as the equivalent Racket macro, but I could be wrong.

I guess Protocol buffers are a mainstream similar system to all this--take CSV file input instead of proto file input. Of course that requires an external compiler for most languages, whereas the racket protocol buffer plugin basically just converts the .proto file to S-expressions and all the codegen happens within Racket ;p

[0]: https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...

It's not really dynamic typing, because it's happening at compile time. Really type providers are just a specific, restricted form of code generation.

Not really. I'm just saying the same stuff in a different #lang-- I mean in different words :p

https://alex-hhh.github.io/2021/09/screenshots.html is a nice gallery of one person's apps.

It's great to have support for tail recursion when implementing recursive solutions, but it is a tall order to add to more traditional languages. However tail recursion is not the only trick Racket has up its sleeve.

In Racket you can't get a stack overflow.

At the time a potential stack overflow is detected, the oldest parts of the current stack is copied to the heap and a fresh stack is introduced. When the stack underflows the saved stack is reinstated. [At least this is a rough idea of how it works - implementation details differ to make it process efficient.]

This means that you can rely on recursive solutions even when the recursive call occurs in a non-tail context.

This idea (no stack overflows) could be used in more traditional languages too. As you write in traditional languages there is a real risk to bump into the stack limit.

In web/gui programming it’s a good fit. Your data is a tree that you render on a screen, so it’s by default relatively shallow and not very big. It’s never going to blow the stack and the benefit of using recursion, closures and functional composition is you get clear, dense code and tend to make fatter data structures and more general code.

> And frankly, lots of programmers don't have a good handle on it, even the ones who studied CS in college, so asking them to maintain recursive code written by someone else usually ends pretty poorly.

Honestly that speaks to the caliber of programmers at play here. Sure, the average bootcamp grad probably can’t use a recursive function, but a real software engineer should have mastered it during any serious intro class. Without recursion I’m not sure how we would even be programming (think of all the parsers and grammars relying on it!).

> So when we consider that, actually, no, it's not true that using an explicit stack takes "a lot more code" (it's like, three extra lines), recursion starts to look more and more like a code smell, a smell indicating the originating programmer is more a temporarily-embarrassed mathematician than an engineer.

It sure is a code smell if the average programmer in a given org can’t understand it.

>it's not true that using an explicit stack takes "a lot more code" (it's like, three extra lines)

I don't know if you mean that literally or just as a rhetorical exaggeration, but it's absolutely false. The first example that came to mind is Quick Sort, search for the iterative version of the algorithm and compare it with the traditional recursive version, easily a 10x factor. The increase in complexity isn't linear in code size either, the code that replaces the simple recursive calls is full to the brim with loops, state and conditional mutations, i.e. Free Bugs, yummy yummy.

>Few languages offer tail-call optimization.

I was hacking on a (non-tail-) recursive solution to a problem a couple of days ago in a repl.it container, and a buggy solution exploded after consuming 15000 stack frames. The repl had 1024 MB RAM as a max limit. The point is, absence of tail cail optimization is rarely if ever a real problem in a language that has loops, its a big, big problem if the language doesn't have loops, but as long as the language has loops and relegates recursion to the "Side Role" its so good at, its just not that of a big deal.

This also fails to consider why recursion is such an attractive algorithmic construct, tail recursion is absolutely trivial, it can be transformed to loops mechanically, it rarely adds anything of value to the readability and expressiveness of code.

The vast majority of interesting and useful uses of recursion is the non-tail-recursive variety, where you have to use a stack anyway, at this point the whole argument reduces to whether you can maintain a stack more efficiently and readably than the machine, which in my view ends in you losing to the machine 9 times out of 10.

>And frankly, lots of programmers don't have a good handle on it, even the ones who studied CS in college, so asking them to maintain recursive code written by someone else usually ends pretty poorly.

If those programmers were asked to instead maintain the explicitly iterative version of the code, I bet it would end even more badly. Recursion, after the initial cost of watching a few tutorials, is less confusing than loops. It's about hiding state, how on earth is explicitly managing all that state yourself better? This is like saying that "2+46/(3+1)4" is best calculated as a long sequence of 2-argument assembly instructions because its more explicit that way, its more explicit, true, but - paradoxically - way more obscure.

>Many safety regulations covering vehicles from cars to spacecraft explicitly ban recursion because of these issues.

Embedded Systems safety regulations and conventions ban a lot of things, recursion is not special at all. One thing is dynamic allocation, another thing is multiple returns out of a subroutine. Are you ready to give up those 2 things?

It makes no sense to take the conventions of a very specific and idiosyncratic industry like that and try to derive from it universal rules that should govern all software.

And your non-recursive solution will usually be faster too.

It Will usually offer simpler opportunities to parallelise too.

I think this still, somewhat, misses the point.

Sure, Racket has facilities to make implementing languages easier (that's the whole point), but that simply makes it _easier_ to implement BSL, etc. I could certainly, with more effort, implement BSL in Java or in any other language: the language that students are using really has nothing to do with the _host_ language. Things are somewhat confused by DrRacket (or, made simpler, depending on your perspective); the IDE is somewhat mixed up with everything else, but again, this functionality can and does exist in other editors: I could implement a mode for my BSL implemented in Java in, say, VS Code, with comparable features to DrRacket.

Or, to take a completely different tack, implement the IDE via the web a la WeScheme or, if you want an actual concrete example of something that isn't Racket hosted, Pyret.

I know Shriram very well, he and Kathi do excellent work and as I said they are focused on more valuable projects than trying to prove one language is superior to another for CS1. They are building tools and curricula, and have done some research that sheds some light on the tradeoffs in using certain languages like Racket. Kathi's "Rainfall Accumulates" paper is one of the few papers that gets close to work in the space I am talking about. Shriram's analyses often leave me stunned at just how sharp that guy is, and helps remind me that CS Ed really needs to level up its game.

That said, the HtDP curriculum that they were involved in, and led to Bootstrap and a host of their other projects, was not grounded in any kind of data collection or treated as an empirical research project. Smart people with good intentions built something and threw it into a classroom. Intentionally so, by design [1].

Their subsequent work with Pyret is much better grounded and well-informed, and I've been absolutely fascinated by it. Their data science curriculum delights me, and I have often thought that if I had more time I'd translate it to Python. I think their more recent proposal about a Table Abstract Data Type is just inspired. But we are still VERY far from ever proving things like, "Racket is easier for students to learn". I'm fairly sure it's not even worth doing.

I appreciate the original article was just one student's perspective. It's a perspective I don't entirely disagree with. Nonetheless, they make interesting claims not backed by any kind of published, empirical data. They hypothesize that Racket is virtuous to learn because of how it presents recursion, and because of its simplistic syntax. Cool theory, but not proven using Randomized Controlled Studies. I mean, most things in CS Ed aren't, so I don't think it's a surprising thing to point out. But that doesn't mean we should just sit back and accept these claims.

Personally, I have seen the HtDP curriculum do damage. I have also seen it firsthand do a lot of good. My Racket relationship is complicated [2]. The author makes a great point of the potential value of these models, and also mentions how this whole debate is sort of pointless. I believe that at the end of the day, the CS1 language is simultaneously very important and yet somehow unimportant - it's all just the psychology of the people involved. That, too, is an unsubstantiated claim.

But please, tell me more about how I have not done my due diligence. Would you like to cite some actual RCT papers that back up the claims founding all this stuff? Or do you want to keep citing textbooks like that somehow proves something?

[1] https://felleisen.org/matthias/Thoughts/Measuring_education.... [2] https://github.com/acbart/myracketrelationshipiscomplicated....