Earlier quoted context omitted.
> An awesome lisp, a top successor for Common Lisp and a playground for experiments and initiating people into Lisp. As good as its development environment might be for learning purposes and research, it is no match for neither LispWorks nor Allegro Common Lisp, so it is hard to be a top successor. In fact there isn't a single commercial Scheme has successful in the market as those Lisp environments, with exception o…
Not to be rude, but apart from Clojure, other Lisps are non-existent in production compared to the software world at large. One could even consider Scheme as more widely used than CL. The biggest production use case for Lisp today is to learn Lisp. The biggest use case for Scheme, CL, or Racket is to use to learn Lisp. Racket that way was quite successful. With all this going on now. Scheme is the only serious Lisp f…
Racket-on-Chez Status
51–53 of 53 posts
Re: Racket-on-Chez Status
#52In Common Lisp, one has pthreads-like concurrency capabilities which seem very well suited for fine-grained parallelism as well as for server tasks. I am thinking in such things like parallel backtracking and optimization algorithms for robotic control or board games, for example.
However, threads are notoriously difficult to handle cleanly and safely in larger programs. Here, Clojure (which in my eyes is a very Scheme-like Lisp) offers a very elegant solution with its concurrency primitives of Futures, Atoms, Agents, and STM. After some experimenting, I believe they are very, very attractive for many concurrent server tasks (like a web server), but not that well suited for computing-intensive parallel algorithms like the ones I mentioned above, which I am highly interested in. Part of the reasons are that such algorithms can become quite GC-heavy. Also, the Clojure compiler has limits on how much primitive types can be passed as parameters in one functions. This means that a complex backtracking algorithm in Clojure can still be two orders of magnitude slower than in C (which is somewhat disappointing, but one has to remember that Clojure was not designed for this).
Racket has had, so far, only limited concurrency capabilities. It had Futures, however they could easily become blocked by GC. It also has Places, which are a very safe and clean solution of splitting parallel computations into separate processes. However, I think that places are not the first choice for heavily parallel algorithms with strong interdependencies.
Now, Racket can run on top of Chez, and Chez has fine-grained concurrency capabilities on top of pthreads, which seem to be on par with Common Lisp. Also, Racket has strong support for functional and side-effect free programming, including some data structures. In my impression, this seems to open a wide range of new possibilities, including providing look-alike primitives for Clojure's Futures, Agents, and Atoms. I would be very interested to know more whether this impression is correct.
Re: Racket-on-Chez Status
#53Earlier quoted context omitted.
A bit of Googling landed me here: https://groups.google.com/forum/#!msg/racket-users/-x_M5wIht... From there: Phase 1: Brainstorming (months) Phase 2: Iterative Design (years) Phase 3: Conversion (months or years) Phase 4: Transition (years) I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: https://en.wikipedia.org/wiki/Second-system_effec…
> I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: I think you are mistaking working time for bloat; they can be inversely related; it's easier to add lots of ideas, it's harder to pare things down. > Plus as a former Perl programmer having watched Perl 5 lost almost everything, chasing a never to have come to reality Perl 6. I can say, g…
Indeed. And even Perl 6 is not Perl 6 anymore: it has been renamed to Raku (https://raku.org using the #rakulang tag on social media).