3 ms·

I have a slow-moving side project in Racket. I picked it up for its reputation for being the Python of the Scheme world, but I think the analogy doesn't hold u

I have a slow-moving side project in Racket. I picked it up for its reputation for being the Python of the Scheme world, but I think the analogy doesn't hold up and you're better off accepting Racket on its own terms. Racket doesn't have the standard library of Python, nor does it have the syntax, nor would you structure a program in the same way. Indeed, I think the idea of bringing a more Python-like syntax to Racket would only delay the realization that Racket is not Python with an inferior standard library, but a totally different animal. I'm excited about Chez for the performance gains, and I think it's really nifty that it allows more of Racket to be written in Scheme.

bjoli 6y ago
Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results. Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not. Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness. I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations. I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)
- jnxx 6y ago
  > I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs. However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives: 1. Concurrency in servers 2. Graphical user interfaces 3. exploiting multiple cores for complex parallel computations, like number crunching It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors). However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector. And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure. This is a drawback which is rooted by the implementation. But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.

bjoli 6y ago

Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results. Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not. Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness. I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations. I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)

jnxx 6y ago
> I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs. However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives: 1. Concurrency in servers 2. Graphical user interfaces 3. exploiting multiple cores for complex parallel computations, like number crunching It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors). However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector. And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure. This is a drawback which is rooted by the implementation. But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.