Successfully Learned Racket

2024-02-17

During the Chinese New Year holiday when I went back home with nothing to do, I solved several problems from Advent of Code 2023 using Racket. In the past, I struggled with languages like Scheme, facing setbacks repeatedly. However, this time it went smoothly. As I wrote the code, I suddenly felt very adept, even managed to write hygienic macros. Perhaps I had a sudden enlightenment.

At first, I intended to tackle these problems using the C language. However, as expected, using C to write them started to become a bit tedious as the problems gradually became more complex; especially when it came to string manipulation, which is just not suitable for C.

In comparison, Racket is much easier, at least it doesn't require flipping through many pages of documentation just to convert a string to a number. However, at the same time, Racket, or Scheme to be precise, is as concise as C, if not more so. Just looking at the page count of the standard documentation, ISO C is around 200 pages, while R5RS has only about 50 pages, and the much criticized "too complex" R6RS has just over 100 pages. Racket is a "batteries-included" variant of Scheme, with extensive functionality, but the core of the language still maintains the simplicity of Scheme. I have a half-page R5RS cheat sheet on hand, which is sufficient for the majority of daily needs.

"The Zen of Python" mentions:

Explicit is better than implicit.
Simple is better than complex.

However, it is evident that nowadays Python has not achieved this, but has instead gone against it. I have never quite understood Python's metaclass, and there are subtle pitfalls in OOP that make me feel apprehensive. Additionally, with features like gradual typing, await/async, etc. I am now hesitant to say that I can write Python proficiently. JavaScript also has similar issues. As for C++, it goes without saying. Racket emerged from academia and also pursues new features and functionalities, but the core part of the language remains stable. When using Racket, one can choose to use only the most fundamental part similar to R5RS, or utilize the vast standard library along with complex features like contracts, Typed Racket, etc.

I am not incapable of complex syntax; in fact, I once had a keen interest in being a "language lawyer" in C++. However, if these skills are not used for an extended period, the memory gradually fade away, and picking them up again requires significant effort, akin to the task of Sisyphus. Life is short, and now I am even less inclined to waste precious time on perplexing and seemingly useless details.

Racket's performance is also remarkable. While it may not match up to languages like C/C++ or Rust, it generally falls in a similar league as Java and NodeJS (albeit slightly slower in many cases), and far superior to scripting languages like Python and Ruby. This is likely attributed to the work of "Racket on Chez Scheme" in recent years.

One last advantage of Racket is its suitability for developing "cold-blooded software". This concept was introduced in this blog post. Here, "cold-blooded" does not refer to a "cold-blooded killer" but rather to "cold-blooded animals", suggesting the ability to hibernate. Even been shelved for many years, it's still able be picked up without major issues. This prevents scenarios where APIs and SDKs undergo drastic changes, or where even development environments become obsolete after just a few years (a common occurrence in languages like Python and JavaScript; messy dependencies and build systems in C++ can lead to similar issues). However, I have reason to believe that Racket is unlikely to face such problems (due to its concise core). I recall downloading code of a Scheme interpreter from the 1980s, a time when even the ISO C standard did not exist. Yet, with slight modifications, this code could compile and execute smoothly on modern Linux systems, leaving a deep impression on me.

These are roughly my thoughts after recently learned Racket. I have some ideas for side projects and plan to use Racket to experiment with them.



Email: i (at) mistivia (dot) com