racket VS coalton

This reminds me a bit of the octree quantization implementation I hacked up to improve speed of generating Racket's animated gifs.

* https://github.com/racket/racket/commit/6b2e5f4014ed95c9b883...

Racket! https://racket-lang.org/

“Whenever an engineer changes one of these programs, we run all the programs through our custom model checker (written in Racket + Rosette)”

- pipe operator

It compiles to either erlang or JavaScript, so I was able to jump right into building something fun with a new language.

>I previously gave Clojure a try, that was a pretty good fit, but the JVM / ecosystem put me off.

I felt similarly w/ leiningen (too much boilerplate) but was lisp-curious still so gave racket (https://racket-lang.org/) a try and appreciated the batteries included philosophy of the standard library and was inspired to learn more about writing a programming language (also see: https://beautifulracket.com/)

Biased recommendation: Try racket https://racket-lang.org/ It's not pure functional, but the preferred style is to use mostly functional constructs. (But you can cheat when it get's too difficult or you need some extra speed.) (And you can download packages like Qi that enable a new language inside Racket that has more support for functional style.)

(Most Schemes have a similar mostly-functional style, so you can also try one of them.)

It's a replacement for make, but definitively not a drop in replacement. To understand why, it's better to read the initial announcement/pull-request by Matthew https://github.com/racket/racket/pull/4179

Racket—the Language-Oriented Programming Language—version 8.12 is now available from https://racket-lang.org

See https://racket.discourse.group/t/racket-v8-12-is-now-availab... for the release announcement and highlights.

Thank you to the many people who contributed to this release!

Feedback Welcome

Type declarations in ANSI CL are promises you make to the compiler in order to allow it to generate faster code. The compiler can also use this information to generate compile-time warnings and errors, but it is not required to. This makes CL's native compile-time type system good for making your code fast, not so much for making it reliable. But it's straightforward to layer a proper modern type checker on top of CL, and in fact this has been done. It's called Coalton:

https://coalton-lang.github.io/

IMHO this is the Right Answer: types when you want/need them, dynamism when you don't. It seems like a no-brainer to me. I've never understood why so many people think it has to be one or the other. It seems to me like arguing over whether the window on the bike shed should be on the left or the right. If there is disagreement over this, just put in two windows!

Common Lisp has Coalton [1]. It's basically a language embedded within Common Lisp which has HM types and a bit more modern constructs than CL.

[1] https://coalton-lang.github.io/

It's still… not the same. In CL (and specially with SBCL), we get compile time (type) errors and warnings at the blink of an eye, when we compile a single function with a keystroke (typically C-c C-c in Slime).

And there's also been improvement, see Coalton for a ML on top of CL. (https://github.com/coalton-lang/coalton/)

For the parenthetically inclined among us, there's also an implementation in Coalton: <https://github.com/coalton-lang/coalton/tree/main/examples/t...>

Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples:

1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors. One of them is a parallel collector written by a university student (!!) which blows my mind.

2. SBCL has better and better support for deploying Liwp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python.

3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged, and interestingly, they're implemented purely in Coalton [1]. That means Clojure-like seqs.

It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc.

[1] https://github.com/coalton-lang/coalton/blob/main/library/se...

Use an editor that auto-inserts parens and that indents the code correctly. Now nothing bad can happen. And the parens are used to edit code structurally.

re typing: Coalton brings Haskell-like typing on top of CL. https://github.com/coalton-lang/coalton/ Other lisps are typed: typed racket, Carp… and btw, SBCL's compiler brings some welcome type warnings and errors (unlike Python, for instance).

If you like type safety, this project would be perfect for using https://coalton-lang.github.io/ so your REPL supported Common Lisp out of the gate.